Вопрос или проблема
Мне нужно поддерживать java-приложение с кодом безопасности, который я не уверен, что действительно полезен, и его первоначальная цель неясна (оригинальный разработчик давно ушел).
В основном, код проверяет некоторые параметры безопасности, прежде чем разрешить пользователю что-то сделать. Есть несколько методов, которые выполняют различные проверки. Замысловатость в том, что эти методы isXXXCorrect, isYYYAllowed, isZZZTampered и т.д. не возвращают true или false.
В коде есть две константы TRUE и FALSE, которые инициализируются случайно сгенерированными строками при запуске программы. Затем методы возвращают TRUE или FALSE, а вызывающие методы проверяют на равенство с TRUE или FALSE.
Некоторый контекст: приложение в конечном итоге является автономной программой, установленной конечным пользователем, который может захотеть взломать программу и деактивировать эти меры безопасности. При упаковке код обфусцируется с помощью zelix klassmaster. Замысловатость заключается в локальных методах, вызывающих другие локальные методы, сетевое взаимодействие не принимается в расчет.
Мой вопрос: есть ли у этого трюка какая-либо реальная ценность для защиты моего кода?
Правка: уточнение после комментариев и дальнейших размышлений с моей стороны.
Я знаю, что никакая безопасность не будет достаточной, если кто-то действительно захочет обратным образом проанализировать/модифицировать программное обеспечение. Я знаю, что даже если будет предпринято разумное усилие сделать это трудным (обфускация и т.д.), ни одно усилие никогда не будет абсолютно достаточным в этом контексте. Но если некоторые из этих усилий не добавляют ценности и засоряют код…
Мне интересно, чего пытался достичь первоначальный разработчик. Улучшить обфускацию? Мы используем Zelix Klassmaster, и он выполняет шифрование строк в коде, поэтому аспект «случайной строки» не кажется мне имеющим добавленную ценность в этом отношении. Предотвратить некоторые атаки? Это защитит от атаки «человек посередине» между локальным методом и другим локальным методом? Это вообще имеет смысл?
Нет, все это бессмысленно. Атакующий мог бы провести обратный анализ вашей программы и аннулировать все ваши проверки безопасности, даже с учетом всех описанных вами усилий. Любой код или данные, над которыми вы не хотите, чтобы пользователь имел 100% полный контроль, должны находиться на сервере, точка.
Ответ или решение
К скрытым методам в коде вашего Java-приложения можно подойти с осторожностью. Первоначально, идея о том, чтобы методы проверки безопасности не возвращали простые значения true или false, может показаться изощренной. Однако, в реальности, этот подход может не иметь реальной ценности в контексте безопасности.
Анализ методов проверки
Давайте рассмотрим подробнее структуру ваших методов. Как упоминается, существуют методы, такие как isXXXCorrect, isYYYAllowed и isZZZTampered, которые возвращают значения, связанные с двумя константами TRUE и FALSE. Эти константы инициализируются случайными строками при запуске программы. Затем вызываются методы, которые сравнивают возвращаемое значение с TRUE или FALSE.
1. Безопасность через неочевидность
На первый взгляд, этот подход может показаться попыткой создать некую обфускацию — усложнить процесс обратной разработки. Однако, даже если этот метод затрудняет понимание работы вашего кода, он не делает его действительно безопасным. Опытные хакеры смогут легко определить, что любые условные операции, сравнивающие возвращаемые значения с TRUE или FALSE, в конечном итоге будут уязвимы к манипуляциям.
2. Основные уязвимости
Обсуждая концепцию безопасности, следует учитывать, что любое приложение, которое устанавливается на компьютеры конечных пользователей, подвержено рискам взлома. Ваша логика проверки может действительно помочь сначала остановить недобросовестных пользователей, но как только приложение становится доступным, все логические проверки могут быть легко обойдены.
При наличии доступа к коду, злоумышленник может:
- Проанализировать логику выполнения методов проверки.
- Заменить возвращаемые значения этих методов на желаемые, тем самым обойти проверку.
- Использовать инструменты для динамического анализа и модификации байт-кода Java.
Ценность обфускации
Вы упомянули о Zelix Klassmaster, который обфусцирует код и шифрует строки. Это — действительно полезный инструмент, если вы хотите усложнить анализ кода, однако использование случайных строк в качестве значений для логических проверок не добавляет реальной ценности. Если злоумышленник сможет увидеть, что ваши методы проверок всегда вернут сгенерированные случайные строки, это только упрощает задачу.
Защита на сервере
В конечном итоге, наиболее эффективной стратегией безопасности является сохранение чувствительных логик и данных на серверной стороне. Если у вас есть контроль над сервером и способ взаимодействовать с приложением через безопасный канал, это может значительно уменьшить риски компрометации. Кроме того, серверные проверки могут быть выполнены по защищенной логике, которую конечный пользователь не сможет обойти, если у него нет доступа к вашему серверу.
Заключение
Таким образом, подход, описанный в коде вашего Java-приложения, не предоставляет реальной защиты, и скорее всего, является неэффективным способом усложнения кода. Рассмотрение безопасных архитектурных решений, таких как серверная обработка данных, несомненно, будет более эффективным в достижении ваших целей по обеспечению безопасности. Инвестируйте в проекты и решения, которые обеспечивают более высокий уровень защиты, и не позволяйте хрупким механизмам затмевать реальные проблемы, с которыми вы можете столкнуться.