Как спрятать секретное число от декомпиляторщиков в Android приложении?

#java #android #безопасность

Сейчас в моем клиентском приложении лежит очень секретное число. Лежит оно в ресурсах,
strings.xml, надо срочно что-то придумать, чтобы ковыряльщики-хакеры не смогли ничего
найти, или хотя бы приостановить их злодеяния :) Число это состоит из 50 цифр, передается
серверу строкой как API ключ. Я придумал следующее:

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

Или есть более грамотное решение? Я вот замечал где-то что апктул не умеет декомпилить
boolean, там что-то вроде 0 и 1 получается, точно не помню. 

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

Ответы

Ответ 1

В статье «Обзор способов защиты программных продуктов на Java» можно почитать по
основным способам защиты приложения.

Выдержка из конца статьи:


  Сценарий защиты
  
  Подводя итог хотел бы вкратце обрисовать сценарий достаточно эфективой борьбы против
декомпиляции:
  
  
  Предварительно поместить в готовый java код несколько глухих классов.
  Откомпилировать их и запихать в отделный архив.
  Затем «затемнить» java код используя вспомогательные средства, например, Crema.
  Отдельно реализовать классы которые будут храниться в native методе и получаться
при помощи механизма схожего с ClassLoader.
  Откомпилировать их.
  Откомпилировать остальной java код.
  Применить метод изменения байт-кода.
  Запаковать остальной java код.
  Зашифровать классы которые храниться в native методе, используя любой алгоритм,
например RSA и поместить его в native код.
  Реализовать в native методе проверку целостности архива с java кодом
  Откомпилировать native код.
  Удалить архив с глухими классами.
  Создать лицензию.
  Теперь всё это можно запускать.


Ответ 2

Принято считать, что всё, что находится в клиенте – раскрыто и поддаётся подделке.

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


Ответ 3

апктул не умеет декомпилить boolean, там что-то вроде 0 и 1 получается, точно не помню


Это не "не умеет", 0 = false, 1 = true, что еще надо.


  Лежит оно в ресурсах, strings.xml


Это пожалуй самое неудачное, Apktool это первое с чего начинают, даже самые недалекие,
которые не пойдут дальше и вообще программировать толком не умеют.


  А то вот такие манипуляции каждый раз при запросе на сервер длительны будут


Вдобавок, могут даже навредить, HTTP хорошо сниффится, это тоже начальный уровень
реверс-инжиниринга.


  Вообщем, что можно придумать?


В основном эффективны два способа:


Искажение информации (дезинформация). Изобразите, что это число вовсе не так важно
и вовсе не то, что они ищут, а что-то неинтересное.
Уменьшение количества информации. Чем меньше знает разведчик, тем дальше он от цели.
Была задача, где приложение работало с неким сервером, а еще должно было слать на некий
сервер данные при попытке взлома, так я сделал, чтобы это был один и тот же сервер,
и данные слались POST-запросом на корневой URL (с index.php), в котором такой запрос
отличался от других и обрабатывался иначе, и поди разберись в том же сниффере где какой
запрос и что за что отвечает, а если бы было "acrbtrverbtr.ru/eih8eh89e8hvev.php" -
то сразу бы бросалось в глаза, это не лучше чем назвать прямо "security-server.ru/report.php".



  есть какие-то утилиты для просмотра ячеек dalvik памяти приложения


Есть, отладчики называются, но отладка уже далеко не всем доступна, в отличие от
декомпиляции JD-Gui и Fernflower'ом, и дизассемблирования в IDA Pro.


Ответ 4

Есть несколько вариантов разной степени продвинутости и применимости:


Зашифровать ваш API key, но это только кажется, что решает проблему, потому, что
пароль для шифрования все равно будет лежать в коде/ресурсах, так что история превращается
в рекурсивную сказочку про попа с собакой. Видел варианты с глубиной рекурсии до 3-х :)
Можно конечно в качестве пароля использовать идентификатор устройства - проблема
в этом случае возникает с развертыванием вашей аппы. Надо заранее знать deviceId и
сгенерировать для него шифрованный API key - то есть имеет крайне ограниченную применимость.
Правда, если речь идет о корпоративных устройствах для ограниченного круга лиц - вполне
работает
Еще способ - хранить ключи во внешнем сервере и при первом запуске приложения получать
их оттуда (требуется https и какой-нибудь небольшой облачный сервисочек с высунытым
наружу Rest'ом)
Другой вариант использовать коммерческие обфускаторы, типа DexGuard, которые в отличие
от ProGuard умеют также и шифровать код.


Ответ 5

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