Как защищать свой код от реверса

Взгляд с другой стороны: что разработчик может сделать, чтобы усложнить реверс своего ПО.

Защита в глубину — несколько слоёв препятствий, повышающих стоимость анализа, в расчёте на то, что абсолютной защиты не существует.

Главная истина

Любой код, исполняемый на устройстве пользователя, в принципе поддаётся реверсу — это лишь вопрос времени и мотивации. Цель защиты не «сделать невозможным», а сделать дорого: чтобы атакующему было невыгодно. Это меняет подход.

Практические приёмы

  • Не храните секреты в клиенте. Ключи API, проверку лицензий, важную логику держите на сервере. То, чего нет в бинаре, нельзя извлечь реверсом.
  • Обфускация. Запутывает код и строки, повышая стоимость анализа (особенно полезна в мобильных приложениях — R8/ProGuard).
  • Шифрование строк и ресурсов. Чтобы strings не выдавал логику сразу.
  • Проверки целостности. Программа замечает, что её модифицировали.
  • Обнаружение отладки/эмулятора. Лёгкий барьер против ленивого анализа.

Чего НЕ стоит делать

  • Полагаться на «security through obscurity» как на единственную защиту.
  • Хранить пароли/ключи в коде в открытом виде (их найдут за минуту через strings).
  • Думать, что обфускация = безопасность. Это лишь повышение стоимости.

Как работает под капотом: серверная модель доверия

Самая надёжная защита логики — перенести её туда, где у атакующего нет кода: на сервер. Клиент отправляет запрос, сервер проверяет и отвечает. Реверс клиента покажет лишь протокол, но не серверную логику. Поэтому критичные проверки (оплата, доступ) делают на сервере, а не в приложении.

Связь с реверсом

Понимая, как реверсер ищет строки, проверки и точки входа (предыдущие разделы), вы знаете, что именно прятать и усложнять. Защита и анализ — две стороны одной медали; этот курс даёт обе.

Частые ошибки

  • Вшивать секреты в клиент «временно».
  • Считать обфускацию заменой серверной проверке.
  • Тратить силы на анти-отладку вместо архитектурно правильного выноса логики на сервер.

Итог

  • Абсолютной защиты от реверса нет — цель сделать анализ дорогим и невыгодным.
  • Не храните секреты и критичную логику в клиенте — выносите на сервер.
  • Обфускация, шифрование строк, проверки целостности — слои, а не панацея.
Проверьте себя
1. Какова реалистичная цель защиты кода от реверса?
AСделать реверс абсолютно невозможным
BПовысить стоимость анализа настолько, чтобы он стал невыгодным
CУскорить программу
DУменьшить размер файла
2. Где надёжнее всего держать критичную логику и секреты?
AВ исходном коде клиента
BВ строках бинаря
CНа сервере, куда у атакующего нет доступа к коду
DВ имени файла