Почему Вы запутываете свой код?

Да, чтобы было сложнее реконструировать.

It's called "Job Security". This is also the reason to use Perl -- no need to do obfuscation as separate task, hence higher productivity, without loss of job security.

Call it "security through obsfuscability" if you will.

Конечно, чтобы обеспечить работу на всю жизнь (шучу).

Это довольно забавно и познавательно: Как написать непонятный код .

Я не верю, что усложнение реверс-инжиниринга - веская причина.

Хорошая причина для обфускации кода - уменьшить компилируемый след. Например, приложения J2ME должны быть как можно меньше. Если вы запустите приложение через обфускатор (и оптимизатор), вы можете уменьшить размер jar-файла с пары мегабайт до нескольких сотен килобайт.

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

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

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

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

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

Между прочим, нелегко отследить исключения, генерируемые из обфусцированного стека! На самом деле я однажды запомнил, что aH означает «исключение нулевого указателя» для конкретной сборки.

Я помню, как создавал приложение Windows Service для онлайн-резервного копирования, которое было построено на .NET. Я мог легко использовать Visual Studio или такие инструменты, как .NET Reflector, чтобы увидеть классы и исходный код внутри него.

Я создал новое тестовое приложение Visual Studio и добавил к нему ссылку на службу Windows. Дважды щелкнув ссылку, я могу увидеть все классы, все пространства имен (но не исходный код). Кто угодно может понять внутреннюю работу ваших модулей, посмотрев на имена классов. В моем случае одним из таких классов был FTPHandler, который четко сообщает, куда идут резервные копии.

.NET Reflector выходит за рамки этого, показывая реальный код. У него даже есть возможность экспортировать весь проект, чтобы вы получили проект VS со всеми классами и исходным кодом, подобным тому, что было у разработчика.

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

Looking at some of the code I wrote for my disk driver project makes me question what it means to be obfuscated.

    ((int8_t (*)( int32_t, void * )) hdd->_ctrl)( DISK_CMD_REQUEST, (void *) dr );

Or is that just system programming in C? Or should that line be written differently? Questions...

Если я доставляю приложения Java Swing клиентам, я всегда запутываю файлы классов перед распространением.

Вы никогда не можете быть слишком осторожными - однажды я указал на достойный декомпилятор Java (я использовал JD Java Decompiler - http://www.djjavadecompiler.com/ ) в моих файлах классов и был вознагражден почти идеальным воспроизведением исходного кода. Это было довольно неприятно, поэтому с тех пор я начал запутывать свой производственный код. Я сам использую Klassmaster ( http://www.zelix.com/klassmaster/ )

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

Раньше это было далеко чаще, чем сегодня. Это также привело к (несуществующему?) Obfuscated C Contest.

Законный (хотя, возможно, и не ")"

Да и нет, я не поставлял приложения с легко декомпилируемым инструментом.

Я запускал что-то вроде обфускаторов для старых интерпретаторов Паскаля Basic и UCSD, но это было для другая причина, оптимизация времени выполнения.