Дело за обфускацией кода?

Каковы основные причины написания запутанного кода с точки зрения реальной выгоды для людей, разрабатывающих код, и для бизнеса, который запускает этот код (если рассматриваемый код на самом деле является коммерческим кодом)? Существуют ли документированные случаи (доступные онлайн в некоторых местах), в которых описывается, когда запутывание приносит больше пользы, чем вреда? Существуют ли общеизвестные примеры, когда, например, было доказано, что обфускация содержательно задерживает проникновение злонамеренного третьего лица в код? Кажется, что точно так же, как закатывание окон в вашем автомобиле не остановит людей от их взлома и кражи вашей стереосистемы, запутывание вашего кода просто делает честных людей честными.

=========

Фон:

Это попытка намеренно оспорить мои предположения по этой теме.

Я против использования обфускации кода в целом, но мне любопытно, что я что-то упустил. Я понимаю, почему в таких случаях, как JavaScript, минимизация помогает вещам загружаться быстрее и всем (в этом есть реальное, функциональное преимущество), но я не могу придумать единственную причину, по которой запутывание кода является препятствием обнаружение того, что делает секция кода / алгоритма , фактически эффективно для любых целей.

С открытым исходным кодом, популярным сумасшедшим, вопрос, кажется, «поделиться кодом или сохранить его в собственности?» Когда дело доходит до коммерческого кода, я могу понять, почему вы не можете делиться всем, и у вас есть закон, чтобы бороться с воровством.

Кстати, если причиной, по которой кто-то пишет обфусцированный код, является «безопасность работы», то я бы уволил любого программиста, уличенного в последовательном и целенаправленном использовании обфускации, с единственной целью помочь сохранить свою работу, если только он не смог разумно доказать, что у него были какие-то деловая выгода. Это настолько противоречивая команда, что это нелепо, и указывает на кого-то, кого больше заботит сохранение своей работы с помощью ошибочных практик, а не потому, что они пишут классное программное обеспечение.

Я упоминаю только этот конкретный случай, потому что, хотя я понимаю, что люди обычно шутят, я бы хотел сдержать любые ответы, основной смысл которых заключается в том, что обфускация для обеспечения безопасности работы - это хорошая идея.

Один очень интересный случай использования для обфускации - отслеживание происхождения незаконных копий. Предполагая, что запутывание является относительно дешевой операцией, первоначальный автор может предоставить каждому клиенту по-разному запутанные версии приложения, если найдена нелегальная копия, автор может сравнить с предоставленными версиями и отследить источник пиратства.

Это форма стеганографии , вдохновленная и изменяющая криптографические схемы «отслеживания предателей» . Я понятия не имею, является ли это общим ¹ , или даже если это хорошая идея, но я видел, как это применяется на практике при следующих параметрах:

• Высококонкурентный общенациональный рынок с двумя поставщиками,
• Около 50 внедрений охватили рынок,
• Среднее время разработки для обоих приложений составляло пару лет (более или менее),
• Среднее время запутывания для нашего приложения было пару часов,
• Ожидаемый срок службы обоих приложений - около десяти лет.

Разумным объяснением было, конечно, безопасность через мрак , и оно развивалось по вышеупомянутой схеме в некоторый момент ² . Оба поставщика имели юридический доступ к двоичному коду друг друга, и я думаю, что очевидно, что попытки декомпиляции от обоих были ожидаемы. Запутывание ничего не сделало с точки зрения безопасности, в конечном счете. У обоих поставщиков были высоко мотивированные и талантливые команды, работающие на чрезвычайно прибыльном и нишевом рынке, в итоге наши продукты были больше похожи, чем нет, и любое конкурентное преимущество было получено с помощью других, менее неясных средств.

Я не могу расширяться, потому что (а) это было очень рано в моей карьере, и я не получил четкого обзора проектных решений или результатов схемы отслеживания (если таковые имеются) и (б) некоторые из моего участия с проектом был под NDA.

Другой действительный вариант использования для обфускации может быть, когда вы каким-то образом по закону обязаны передать свой код третьей стороне :

Если ваша фирма занимается интеллектуальной собственностью для технологических компаний или участвует в делах, связанных с исходным кодом программного обеспечения, вы можете быть обязаны предоставить исходный код вашего клиента в ВПТЗ США, суду или третьей стороне.

Поскольку исходный код считается коммерческой тайной, большинство регулирующих органов используют правило «50%». Представленный исходный код скрыт, поэтому его нельзя использовать как есть.

IANAL, и ссылка больше относится к печатным копиям кода, а не к фактическому рабочему коду, так что это может быть совершенно неактуально.

Теперь, поскольку Javascript является каноническим примером запутывания, есть один побочный эффект, который обычно не рассматривается, и который скрывает вредоносный код в запутанном Javascript. Хотя есть определенные преимущества в минимизации ³ Javascript, я не вижу смысла в фактическом запутывании, и я рад, что Дуглас Крокфорд согласен со мной :

И наконец, возникает вопрос о конфиденциальности кода. Это безнадежное дело. Нет преобразования, которое помешало бы решительному хакеру понять вашу программу. Это оказывается верным для всех программ на всех языках, это просто более очевидно с JavaScript, потому что он поставляется в исходной форме. Преимущество конфиденциальности, предоставляемое путаницей, является иллюзией. Если вы не хотите, чтобы люди видели ваши программы, отключите ваш сервер.

Что касается запутывания для «безопасности работы», то это поведение, которое никогда не должно проходить проверку кода, и если оно идентифицировано, оно не должно допускаться. Сначала я не пошел бы так далеко, чтобы уволить преступника, но, по крайней мере, повторяющиеся преступники, безусловно, заслуживают хорошей порки.

В заключение, запутывание - это типичный пример безопасности через мрак, только очевидная его заслуга - сдерживание и не более того. Могут быть случаи творческого использования ^{4, о которых} я не знаю, но в целом преимущества минимальны, в лучшем случае.

_{¹ После того, как я написал это, я нашел ответ, который в основном описывает ту же схему, так что это может быть более распространенным, чем я думал.
² Хотя стеганография по-прежнему безопасна через мрак.
³ Минификация ~ удаление пробелов и сокращение токенов, не намеренно скрывая.
⁴ Считается ли международный конкурс кодов на скрытый код ?}

Случай запутывания кода состоит в том, что он поднимает планку для третьей стороны, чтобы определить, что / как код работает.

Однако это НЕ означает, что разработчик должен когда-либо писать запутанный код.

Видите ли, это то, чего, я думаю, не хватает в вашем вопросе: запутывание кода (как минимизация JavaScript) не требует и не должно выполняться вручную разработчиком. Аналогично, это не должно храниться как исходные файлы вашего ядра в управлении версиями.

Запутывание кода должно происходить как этап постобработки во время компиляции в сборку. Для этого есть множество сторонних продуктов, поэтому практически нет причин делать это дома.

Например: дотфускатор

У IEEE есть документ об эффективности обфускации кода

Результаты показывают, что переименование идентификатора значительно снижает эффективность атак, по крайней мере, вдвое увеличивая время, необходимое для завершения успешной атаки (даже в наихудшем сценарии, т. Е. Против лучшего атакующего). Кроме того, запутывание уменьшает разрыв между начинающими и опытными злоумышленниками, делая последние менее эффективными , и делает системы, которые легче атаковать в явном виде, более похожими на те, которые по сути сложнее взломать.

Акцент мой.

Я принимал участие в разработке MMORPG. Это включало логику сервера и логику клиента. На протяжении всей многолетней разработки проекта всякий раз, когда мы рассматривали интерфейс между клиентом и сервером, правилом было то, что клиент должен постоянно обрабатываться сервером при условии, что он был взломан. Другими словами, сервер должен был быть написан таким образом, чтобы не было ответа от клиента, который мог бы вызвать сбой сервера или позволить клиенту обмануть. Тем не менее, с самого начала было известно, что хакеры неизбежно найдут дыры в системе и используют их для обмана. И через некоторое время они сделали.

Конечно, прежде чем отправлять клиента в большой мир, мы постарались запутать его. Мы считаем, что запутывание имело следующие последствия:

1. Это удержало неопытных хакеров даже от попыток.
2. Это задержало опытных хакеров в достижении каких-либо взломов.
3. Это уменьшило количество взломов, совершаемых опытными хакерами.
4. Это ограничило эффективность взлома.
5. Самое главное: это заставило хакеров выполнить больше тестовых прогонов со своими взломанными клиентами на наших серверах, прежде чем они добились рабочего взлома, что увеличило шансы на то, что мы обнаружим их при поиске нерегулярных действий в журналах сервера.

Игровые аккаунты обнаруженных хакеров были закрыты без возмещения, поэтому это сделало хакерский бизнес более дорогим и менее привлекательным.

Таким образом, из-за всего вышеперечисленного, я считаю, что запутывание имеет общий положительный эффект в нашей игре, и, следовательно, запутывание может иметь общий положительный эффект в любом программном обеспечении, которое может быть взломано. (Например, программное обеспечение, содержащее меры защиты от копирования.)

Влияние запутывания на поддержание было практически нулевым. Было несколько мест, где некоторые неопытные программисты делали предположения об именах идентификаторов (они использовали отражение), но как только они были разобраны, все было хорошо. Этап запутывания просто стал частью общего этапа сборки для производственной версии игры, поэтому большинству из нас, разработчикам, никогда не приходилось беспокоиться об этом или иметь к этому какое-либо отношение. У нас уже был инструмент для просмотра журналов игры, поэтому мы изменили его, чтобы использовать таблицу ассоциаций (сопоставление запутанных идентификаторов с правильными идентификаторами), созданную обфускатором, чтобы переводить журналы для нас на лету, поэтому мы никогда даже приходилось видеть какие-либо запутанные идентификаторы во время посмертных обследований на основе журналов, собранных с поля.

Чтение и понимание (и, очевидно, написание) запутанного кода может быть интересной мысленной задачей. Вероятно, это выходит за рамки того, о чем вы спрашивали, но примеры, такие как IOCCC, могут вызывать как веселье, так и ужас.