безопасные нативные методы и API-ключи в Android с помощью ndk - PullRequest
Новая
       8

безопасные нативные методы и API-ключи в Android с помощью ndk

0 голосов
/ 06 июля 2018

Я использую ndk и android studio для защиты моего API-ключа, и теперь он работает.также я пытаюсь грязный код, чтобы укрепить разборки ....но я все еще могу декомпилировать и увидеть нативные методы в классах Java.также предварительно созданные .so (совместно используемые объекты) файлы доступны в apk и будут использоваться снова!

Вопросы:

  1. После выпуска apk все хакеры могут видеть.so файл, и они могут использовать пользовательские настройки в файле .mk и программно-ориентированные нативные методы, такие как мой класс, для извлечения только API-ключа.они вызывают мои функции, связанные с API-ключом, не зная реализации.я что-то здесь исключаю?

  2. нужен ли для этого способ защиты?

Ответы [ 2 ]

0 голосов
/ 08 июля 2018

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

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

Тем не менее, стоит, по крайней мере, не хранить API-ключ в виде обычного текста в коде C ++. Попробуй себя запустить 

strings libnative.so

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

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

0 голосов
/ 07 июля 2018
  1. Вы увеличиваете время, необходимое хакерам для декомпиляции и понимания файла .so. Оцените, насколько это сложно, и время от времени изменяйте свою аутентификацию API. Это делает предыдущую попытку взлома устаревшей, даже если она была успешной.

Чтобы уточнить: введите API-ключ и в процессе аутентификации в нативных методах. Например, для API HTTPS отправьте uri, json content, usertoken в собственный метод. Затем в нативном коде используйте их, API-ключ и некоторые хеш-функции для создания хеша. И выведите этот хэш в код Java для отправки в HTTP-запросе. Таким образом, будет трудно угадать рецепт аутентификации, просто отслеживая записи и выходные данные. Злоумышленникам придется декомпилировать нативный код.

  1. Активируйте Proguard, скомпилируйте, декомпилируйте и убедитесь сами. На мой взгляд, это повышает хороший уровень сложности для очень простой настройки.
...