Информационная безопасность это всегда гонка вооружений. Из чего следует одна простая мысль, что полная безопасность невозможна, особенно в случае с клиентскими приложениями, когда у злоумышленника есть физический доступ к устройству. Но тут как при убегании от медведя: необязательно бежать быстрее медведя, достаточно бежать  быстрее соседа.  Главная идея заключается в том, чтобы сломать вас было дороже получения возможной выгоды. Нужно  донести до потенциального хакера одну простую мысль, «ломать нас невыгодно, иди поищи счастья в другом месте». Поэтому одной из основных критических ошибок являются крики о том что ваша защита совершенна. На подобные  заявления сразу сбегается куча высоко профессиональных хакеров, которые будут ломать вашу защиту просто для доказательства своей крутизны невзирая на любую возможную выгоду.  Одним из основных столпов хорошей защиты, является журналирование действий и мониторинг всех нестандартных событий. Тяжело выстраивать защиту, если вы даже не знаете что вас ломают и каков вектор угрозы. Тут многое специфично для ваших процессов, но в качестве примеров могу привести использование большого количества разных аккаунтов с одного устройства; попытки обратиться к API к которому у аккаунта не должно быть доступа; многочасовые сессии в случаях, когда среднее время измеряется в минутах; нестандартные сбои и так далее. Они не защитят от продвинутых ребят, но прикручиваются быстро и выбрасывают всех script-kiddie которые  просто скачали утилиты из интернета и не особо понимают что делают. В природе есть много разных методик обнаружения рута. Одним из самых простых является проверка подписи прошивки или попытка достучаться до суперпользователя: Также очень популярным методом получения рута является Magisk. Обнаружение само по себе является той еще игрой в кошки мышки: находят один способ, потом разработчики его патчат, находят другой, его патчат и так далее. Самой свежей методикой обнаружения является использование изолированного процесса. Для обнаружения запуска на эмуляторе можно проверять разные поля из класса  Build. Большинство возвращаемых данных постоянны и одинаковы для подавляющего большинства эмуляторов: Также практически не меняется эмулируемая среда: сеть, данные с датчиков и так далее. Один из самых популярных инструментов для изучения приложений. Принцип работы достаточно простой: хукается основной процесс Zygote, что позволяет перехватить вызов любой функции и прочитать/подменить ответ. Есть много методик обнаружения такой атаки, например проверка stackTrace: Имя можно получить через Если вернуло null, то в 99% случаев это означает что приложение установлено вручную и скорее всего взломано. Имена основных сторов: Эти методики не спасут от профессионального специалиста по реверс-инжинирингу. От такого вообще ничего не защитит, поэтому лучше не держать на клиентских приложениях ничего сверх того что необходимо для работоспособности этого приложения. Зато они доставят достаточно много проблем, чтобы злоумышленники еще раз задумались, а надо ли это им.  Можно проверить путь установки приложения, в большинстве случаев при клонировании приложение устанавливается по нестандартному пути: и/или проверить подпись Проверка Android-устройства возвращает следующий ответ: basicIntegrity - базовые проверки надежности устройства; ctsProfileMatch - Более строгая проверка, прохождение которой означает что профиль устройства соответствует сертифицированному Google Эта проверка означает что мы не доверяем базовым сертификатам устройства, а доверяем только тому сертификату который нам известен. В случае okHttp3(стандарт сетевой библиотеки в большинстве приложений) проверка включается так: Стандартным подходом в индустрии является Proguard. Для дополнительной защиты можно использовать собственный словарь с символами иностранного языка(китайский и арабский особенно хороши). Также существует проблема, при которой строковые литералы не обфусцируются. Решается платным обфускатором DexGuard, также на GitHub есть библиотеки  не настолько качественные, зато бесплатные, например paranoid. Шифрование всех важных данных — очень хорошее препятствие для обратного инжиниринга.  Отличным вариантом алгоритма шифрации будет AES-256 Единственное, что нужно продумать, это ротацию ключей. В идеале это будет отдельный ключ на каждую сессию, но это очень сложно и дорого поддерживать, поэтому подбирайте баланс в зависимости от доступных ресурсов и требуемого уровня безопасности. Также очень интересным вариантом является перенос критической логики в нативный код. Отреверсить код на C намного тяжелее, чем это сделать с APK. Но так же как и с шифрованием это довольно дорого поддерживать, поэтому стоит продумать баланс в зависимости от доступных ресурсов и требуемого уровня безопасности. Если вас заинтересовала тема безопасности в мобильных приложениях, то есть прекрасное руководство от OWASP с которого можно начать своё путешествие в кроличью нору.