Есть ли потенциальные проблемы с запутыванием приложения?

Question

Я создаю весеннее веб-приложение MVC. Я планирую использовать Hibernate.

У меня мало опыта с запутыванием и т. Д.

Каковы возможные недостатки в запутывании приложения?

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

Есть ли какие-либо известные проблемы с фактическим запуском приложения? Можно ли вводить ошибки?

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

Answer 1

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

• очевидный: если ваш код вызывает методы с помощью отражения или динамически загружает классы, то это может привести к сбою, если имена классов / методов будут запутаны; хороший обфускатор позволит вам выбрать имена классов / методов, чтобы не запутывать, чтобы обойти эту проблему;
• похожая проблема может возникнуть, если не все ваше приложение скомпилировано одновременно;
• если он работает непосредственно на уровне байт-кода, обфускатор может создавать код, который в принципе не может создавать компилятор Java (например, он может вставлять произвольные инструкции GOTO, тогда как из Java они могут создаваться только как часть цикла) - это может быть немного теоретически, но если бы я писал JVM, я бы оптимизировал производительность для последовательностей байт-кодов, которые может создавать компилятор Java, а не для тех, которые он не может ...
• Обфускатор может вносить другие незначительные изменения в производительность, если он существенно изменяет число байт-кодов в методе или каким-либо образом изменяет, достигает ли данный метод / фрагмент кода пороговых значений для определенных оптимизаций JVM (например, встроенных методов). с меньшим числом байтовых кодов ").

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

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

Answer 2

Удивило, что никто не упомянул скорость - в общем, более запутанный = медленный код

---

[Редактировать] Я не могу поверить, что это имеет -2.Это правильный ответ.

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

• Разбиение 1 метода на 5;методы чередования;объединение классов [преобразования агрегации]
• Разделение 1 арифметического выражения на 10;перемешивание потока управления [вычислительные преобразования]
• И добавление фрагментов кода, которые ничего не делают [непрозрачные предикаты]

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

Answer 3

Вы можете посмотреть некоторые комментарии здесь, чтобы решить, имеет ли смысл запутывание: https://stackoverflow.com/questions/1988451/net-obfuscation

Вы можете выразить, почему вы хотите запутать. По мнению IMO, лучшая причина в основном заключается в том, чтобы иметь приложение меньшего размера, поскольку вы можете избавиться от классов, которые не используются в вашем проекте, при этом запутывая.

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

Answer 4

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

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

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

Answer 5

1 бесплатный, который вы могли бы проверить это Babel . Он предназначен для использования в командной строке (как и многие другие обфускаторы), есть Reflector addin, который предоставит вам пользовательский интерфейс.

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

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

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

• Переименование членов (поля / методы / события / свойства) является наиболее распространенным (поставляется в разных вариантах: простое переименование методов из чего-то вроде GetId () в a () вплоть до нечитаемых символов и удаления пространств имен). Кстати, это то место, где размышления обычно ломаются. Ваш сборочный файл может оказаться меньше из-за использования строк меньшего размера.
• Строковое шифрование: это затрудняет обращение ваших статических строк, используемых в вашем коде. Кстати, это в сочетании с переименованием затрудняет отладку проблем с переименованием ... так что вы можете включить его после того, как это сработает. При этом также потребуется добавить код для расшифровки строки непосредственно перед ее использованием в IL
• Кодовое искажение ... это то, к чему BlueRaja обращался. Это делает ваш код похожим на код spagetti - чтобы его было сложнее понять. CLR не нравится это ... он не может оптимизировать вещи так просто, и ваш конечный код, скорее всего, будет обрабатываться медленнее из-за дополнительного ветвления и чего-то не встроенного из-за перезаписи IL, используемой для этой опции. Кстати, эта опция действительно поднимает планку того, что нужно для обращения к исходному коду, но может привести к снижению производительности.
• Удаление неиспользуемого кода. Некоторые обфускаторы предлагают вам возможность обрезать любой код, который он находит неиспользуемым. Это может сделать вашу сборку немного меньше, если вокруг вас висит много мертвого кода ... но это просто бесплатная выгода от обфускаторов.

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