Как избежать обратного проектирования файла APK?

Я развиваю обработка платежей app для Android, и я хочу предотвратить доступ хакера к любым ресурсам, активам или исходному коду из APK.

Если кто-то меняет .расширение АПК .zip, то они могут распаковать его и легко получить доступ ко всем ресурсам и активам приложения, и с помощью dex2jar и Java-декомпилятор, они также могут получить доступ к исходному коду. Это очень легко перепроектировать файл Android APK-для более подробно см. вопрос переполнения стека обратное проектирование из файла APK в проект.

Я использовал инструмент Proguard, поставляемый с Android SDK. Когда я перепроектирую файл APK, созданный с использованием подписанного хранилища ключей и Proguard, я получаю запутанный код.

однако имена компонентов Android остаются неизменными, а некоторые коды, такие как значения ключей, используемые в приложении, остаются неизменными. Согласно документации Proguard, инструмент не может запутать компоненты, упомянутые в файле манифеста.

теперь мои вопросы:

  1. как я могу полностью запретить обратная инженерия Android APK? Возможно ли это?
  2. как я могу защитить все ресурсы, активы и исходный код приложения, чтобы хакеры не могли взломать файл APK каким-либо образом?
  3. есть ли способ сделать взлом более жестким или даже невозможным? что еще я могу сделать, чтобы защитить источник код в моем файле APK?

30 ответов


1. Как я могу полностью избежать обратного проектирования Android APK? Возможно ли это?

AFAIK, нет никакого трюка для полного избежания обратного проектирования.

а также очень хорошо сказал @inazaruk:что бы вы ни делали с вашим кодом, потенциальный злоумышленник может изменить его любым способом, который он или она считает возможным. Вы в принципе не можете защитить свое приложение от изменения. И никакая защита тут можно отключить / удалить.

2. Как я могу защитить все ресурсы, активы и исходный код приложения, чтобы хакеры не могли взломать файл APK каким-либо образом?

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

3. Есть ли способ сделать хакерство более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем файле APK?

как все говорят, и как вы, вероятно, знаете, нет 100% безопасности. Но место, чтобы начать Для Android, что Google имеет встроенный, является ProGuard. Если у вас есть возможность включить общие библиотеки, вы можете включить необходимый код в C++ для проверки размеров файлов, интеграции, так далее. Если вам нужно добавить внешнюю собственную библиотеку в папку библиотеки APK при каждой сборке, затем вы можете использовать его ниже предложение.

поместите библиотеку в собственный путь библиотеки, по умолчанию "libs" в ваша папка проекта. Если вы создали собственный код для 'armeabi' target затем поместите его под libs/armeabi. Если бы он был построен с armeabi-v7a затем положите его под libs / armeabi-v7a.

<project>/libs/armeabi/libstuff.so

AFAIK, вы не можете защитить файлы в каталоге /res больше, чем они защищены прямо сейчас.

однако есть шаги, которые вы можете предпринять для защиты исходного кода или, по крайней мере, что он делает, если не все.

  1. используйте такие инструменты, как ProGuard. Это запутает ваш код и затруднит его чтение при декомпиляции, если не невозможно.
  2. переместить наиболее важные части службы из приложения и в веб-сервис, скрытый за серверным языком, таким как PHP. Например, если у вас есть алгоритм, для написания которого Вам потребовался миллион долларов. Вы, очевидно, не хотите, чтобы люди украли его из вашего приложения. Перенести алгоритм и обработать данные на удаленном сервере, и использовать приложение, чтобы просто предоставить ему сведения. Или используйте NDK, чтобы записать их изначально .Итак, файлы, которые с гораздо меньшей вероятностью будут декомпилированы, чем apks. Я не думаю, что декомпилятор для .таким образом, файлы даже существуют на данный момент (и даже если это так, это было бы не так хорошо, как декомпиляторы Java). Кроме того, как отметил @nikolay в комментариях, вы должны использовать SSL при взаимодействии между сервером и устройством.
  3. при хранении значений на устройстве не храните их в формате raw. Например, если у вас есть игра, и вы храните сумму в игровой валюте, которую пользователь имеет в SharedPreferences. Предположим, это 10000 монеты. Вместо сохранения 10000 непосредственно, сохраните его с помощью алгоритма, такого как ((currency*2)+1)/13. Так что вместо этого из 10000 сохранить 1538.53846154 в SharedPreferences. Однако приведенный выше пример не идеален, и вам придется работать, чтобы придумать уравнение, которое не потеряет валюту из-за ошибок округления и т. д.
  4. вы можете сделать аналогичную вещь для задач на стороне сервера. Теперь, например, давайте возьмем ваше приложение для обработки платежей. Допустим, пользователь должен произвести оплату 0. Вместо отправки raw 0 value на сервер, отправьте ряд меньших, предопределенных значений, которые добавить до 0. Например, на вашем сервере есть файл или таблица, которые приравнивают слова к значениям. Так скажем, что Charlie соответствует и John to . Поэтому вместо отправки 0, вы можете отправить Charlie и John четыре раза. На сервере интерпретируйте то, что они означают, и добавьте это. Это не позволяет хакеру отправлять произвольные значения на ваш сервер, так как они не знают, какое слово соответствует какому значению. В качестве дополнительной меры безопасности, вы можете имейте уравнение, подобное пункту 3 для этого, а также меняйте ключевые слова каждые n количество дней.
  5. наконец, вы можете вставить случайный бесполезный исходный код в приложение, так что хакер ищет иголку в стоге сена. Вставьте случайные классы, содержащие фрагменты из интернета, или просто функции для вычисления случайных вещей, таких как последовательность Фибоначчи. Убедитесь, что эти классы компилируются, но не используются фактическими функциями приложения. Добавьте достаточно этих ложные классы, и хакеру будет трудно найти ваш реальный код.

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

вы можете только бороться, но никогда не выиграть.


ни в какой момент в истории вычислений никогда не было возможности предотвратить обратное проектирование программного обеспечения, когда вы даете его рабочую копию злоумышленнику. Также, по всей вероятности, невозможно.

с этим понято, есть очевидное решение:не давайте свои секреты нападающему. в то время как вы не можете защитить содержимое вашего APK, что вы can защитить все, что вы не распространяете. Типично это серверное программное обеспечение, используемое для таких вещей, как активация, платежи, соблюдение правил и другие сочные биты кода. Вы можете защитить ценные активы с помощью не распространение их в вашем APK. Вместо этого настройте сервер, который отвечает на запросы вашего приложения," использует " активы (что бы это ни значило), а затем отправляет результат обратно в приложение. Если эта модель не работает для активов, которые вы имеете в виду, вы можете пересмотреть свою стратегию.

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


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

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

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

теперь большинство компьютеров не используются в таких средах; они физически открыты, подключены к Интернету по беспроводному радиоканалу. Короче говоря, они уязвимы, как и их программное обеспечение. Поэтому им нельзя доверять. Есть некоторые вещи, которые компьютеры и их программное обеспечение должны знать или делать, чтобы быть полезными, но необходимо позаботиться о том, чтобы они никогда не могли знать или делать достаточно, чтобы нанести ущерб (по крайней мере, не постоянный ущерб за пределами этой единственной машины).

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

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

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

рассмотрим следующую схему. Пользователь вводит свои учетные данные для приложения из памяти в устройство. К сожалению, вы должны верить, что устройство пользователя еще не скомпрометировано кейлоггером или Трояном; лучшее, что вы можете сделать в этом отношении, - это реализовать многофакторную безопасность, путем запоминания трудно поддельной идентификационной информации об устройствах, используемых пользователем (MAC/IP, IMEI и т. д.), и предоставления по крайней мере одного дополнительного канала, по которому может быть проверена попытка входа на незнакомое устройство.

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

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

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

теперь компьютер, который хочет злоумышленник, - это ваш сервер, потому что он, а не клиентское приложение/устройство-это то, что может принести ему деньги или причинить другим людям боль для его удовольствия. Это нормально; вы получаете гораздо больше удовольствия за свои деньги и усилия по обеспечению безопасности сервера, чем при попытке защитить всех клиентов. Сервер может находиться за всеми видами брандмауэров и другой электронной безопасностью, и дополнительно может быть физически обеспечен за сталью, бетоном, доступом keycard/pin, и 24-часовым видеонаблюдением. Ваш злоумышленник должен быть очень сложным, чтобы получить какой-либо доступ к серверу напрямую, и вы должны знать об этом немедленно.

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


1. Как я могу полностью избежать обратного проектирования Android APK? Возможно ли это?

это невозможно

2. Как я могу защитить все ресурсы, активы и исходный код приложения, чтобы хакеры не могли взломать файл APK каким-либо образом?

когда кто-то меняет a .расширение АПК .zip, то после распаковки, кто-то может легко получить все ресурсы (кроме Манифест.в XML), но с APKtool можно получить реальное содержимое файла манифеста тоже. Опять же, нет.

3. Есть ли способ сделать хакерство более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем файле APK?

опять же, нет, но вы можете предотвратить до определенного уровня, то есть

  • загрузите ресурс из интернета и выполните некоторый процесс шифрования
  • используйте предварительно скомпилированную собственную библиотеку (C, C++, JNI, NDK)
  • всегда выполняйте хэширование (MD5 в/ша ключи или любая другая логика)

даже Smali люди могут играть с вашим кодом. В общем, это невозможно.


100% избежать обратного проектирования Android APK не представляется возможным, но вы можете использовать эти способы, чтобы избежать извлечения больше данных, таких как исходный код, активы образуют APK, и ресурсы:

  1. используйте ProGuard, чтобы запутать код приложения

  2. использовать NDK используя C и C++ чтобы поместить ядро приложения и безопасную часть кода в .so файлы

  3. чтобы защитить ресурсы, не включите все важные ресурсы в папку assets с APK. Загрузите эти ресурсы во время первого запуска приложения.


разработчики могут предпринять следующие шаги, чтобы предотвратить apk от кражи как-то,

  • самый простой способ-использовать такие инструменты, как ProGuard чтобы запутать их код, но до сих пор было довольно сложно полностью предотвратить кого-то от декомпиляции приложения.

  • также я слышал об инструменте HoseDex2Jar. Он останавливается Dex2Jar путем вставки безвредного кода в Android APK, который путает и отключает Dex2Jar и защищает код от декомпиляции. Это может каким-то образом помешать хакерам декомпилировать APK в читаемый java-код.

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

вообще, вы не можете полностью защитить свой код от потенциальных хакеров. Каким-то образом вы можете затруднить и немного разочаровать их задачу декомпиляции вашего кода. Один из наиболее эффективных способов-написать собственный код(C/C++) и сохранить его как скомпилированные библиотеки.


1. Как я могу полностью избежать обратного проектирования Android APK? Возможно ли это?

это невозможно

2. Как я могу защитить все ресурсы, активы и исходный код приложения, чтобы хакеры не могли взломать файл APK каким-либо образом?

разработчики могут предпринять такие шаги, как использование таких инструментов, как ProGuard, чтобы запутать их код, но до сих пор было довольно сложно полностью запретить кому-либо декомпилировать приложение.

это действительно отличный инструмент и может увеличить трудность "реверсирования" вашего кода, сокращая след вашего кода.

интегрированная поддержка ProGuard: ProGuard теперь упакован с инструментами SDK. Теперь разработчики могут запутать свой код как интегрированную часть сборки выпуска.

3. Есть ли способ сделать хакерство более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить источник код в моем файле APK?

исследуя, я узнал о HoseDex2Jar. Этот инструмент защитит ваш код от декомпиляции, но, похоже, невозможно полностью защитить ваш код.

некоторые из полезных ссылок, вы можете обратиться к ним.


1. Как я могу полностью избежать обратного проектирования Android APK? Возможно ли это?

невозможно

2. Как я могу защитить все ресурсы, активы и исходный код приложения, чтобы хакеры не могли взломать файл APK каким-либо образом?

невозможно

3. Есть ли способ сделать хакерство более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем APK файл?

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


вот несколько методов, которые вы можете попробовать:

  1. использовать обфускации и инструменты, такие как должны быть.
  2. шифрование некоторой части источника и данных.
  3. используйте собственную встроенную контрольную сумму в приложении для обнаружения подделки.
  4. введите код, чтобы избежать загрузки в отладчик, то есть пусть приложение имеет возможность обнаружить отладчик и выйти / убить отладчик.
  5. отделите аутентификацию как онлайн услуга.
  6. использовать разнообразие приложений
  7. используйте метод пальцевой печати, например, аппаратные подписи устройств из разных подсистем перед аутентификацией устройства.

основной вопрос здесь заключается в том, что файлы dex могут быть декомпилированы, и ответ заключается в том, что они могут быть "своего рода". Есть дизассемблеры, такие как dedexer и smali.

ProGuard, правильно настроенный, запутает ваш код. DexGuard, который является коммерческой расширенной версией ProGuard, может помочь немного больше. Тем не менее, ваш код все еще может быть преобразован в smali, и разработчики с опытом обратного проектирования смогут выяснить, что вы делаем из smali.

может быть, выбрать хорошую лицензию и обеспечить ее по закону наилучшим образом.


ваш клиент должен нанять кого-то, что знает, что они делают, кто может принимать правильные решения и наставником.

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

мое обоснование такое:

поскольку ваш домен обрабатывает платежи, можно с уверенностью предположить, что PCI DSS и / или PA DSS (и потенциальный штат / федеральный закон) будет иметь важное значение для вашего бизнеса - чтобы быть совместимым, вы должны показать, что вы в безопасности. Чтобы быть небезопасным, выясните (через тестирование), что вы не защищены, затем исправьте, повторное тестирование и т. д., Пока безопасность не будет проверена на подходящем уровне = дорогой, медленный, рискованный способ успеха. Чтобы сделать правильную вещь, подумайте хорошенько, посвятите опытный талант работе, разработайте безопасным образом, Затем проверьте, исправьте (меньше) и т. д. (меньше), пока безопасность не будет проверена на соответствующий уровень = недорогой, быстрый, малорисковый путь к успеху.


другие ответы upvoted здесь верны. Я просто хочу предложить другой вариант.

для определенных функций, которые вы считаете важными, вы можете разместить WebView управление в приложения. Затем функциональность будет реализована на вашем веб-сервере. Это будет выглядеть так, как будто он работает в вашем приложении.


Если мы хотим сделать обратное проектирование (почти) невозможным, мы можем поместить приложение на чип с высокой устойчивостью к взлому, который выполняет все чувствительные вещи внутри и связывается с некоторым протоколом, чтобы сделать возможным управление GUI на хосте. Даже tamper-упорные обломоки нет 100% отказоустойчивого; они как раз устанавливают адвокатское сословие Очень более высоко чем методы програмного обеспечения. Конечно, это неудобно: приложение требует небольшой бородавки USB, которая держит чип для вставки в устройство.

вопрос не раскрывает мотивацию для желания защитить это приложение так ревниво.

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

Если цель состоит в том, чтобы предотвратить клонирование, за исключением этого защищенного от взлома чипа, нет ничего, что вы можете сделать, чтобы защитить программу от обратного проектирования и копирования, так что кто-то включает совместимый способ оплаты в свое собственное приложение, что приводит к "несанкционированным клиентам". Есть способы затруднить разработку неавторизованных клиентов. Одним из них было бы создание контрольных сумм на основе снимков полного состояния программы: все переменные состояния, для всё. GUI, логика, что угодно. Программа-клон не будет иметь точно такого же внутреннего состояния. Конечно, это государственная машина, которая имеет сходные внешне видимые переходы состояния (как можно наблюдать входами и выходами), но вряд ли такое же внутреннее состояние. Серверное приложение может опросить программу: каково ваше подробное состояние? (т. е. дайте мне контрольную сумму по всем вашим внутренним переменным состояния). Это можно сравнить с фиктивным клиентским кодом, который выполняется на сервере параллельно, переживает подлинный переходы. Сторонний клон должен будет воспроизвести все соответствующие изменения состояния подлинной программы, чтобы дать правильные ответы, которые будут препятствовать ее развитию.


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

кроме того, вы не должны хранить кредитные карты или токены оплаты на приложение, все должно быть, опять же, делегировано службе, которую вы построили, это также позволит вам позже, быть PCI-совместимым более легко, и компании кредитных карт не будут дышать вам в шею (как они сделали для нас).


Я предлагаю вам посмотреть защита программных приложений от атак. Это коммерческая услуга, но компания моего друга использовала это, и они рады использовать его.


apk схема подписи v2 В Android N

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

чтобы поддерживать обратную совместимость, APK должен быть подписан со схемой подписи v1 (схема подписи JAR) перед подписывается со схемой подписи v2. Со схемой подписи v2 проверка не выполняется, если вы подписываете APK с дополнительным сертификатом после подписания со схемой v2.

поддержка apk signature scheme v2 будет доступна позже в предварительном просмотре разработчика.

http://developer.android.com/preview/api-overview.html#apk_signature_v2


в принципе это невозможно. Это никогда не будет возможно. Однако надежда есть. Вы можете использовать обфускатор чтобы сделать так, чтобы некоторые общие атаки намного сложнее выполнять, включая такие вещи, как:

  1. переименование методов / классов (поэтому в декомпиляторе вы получаете такие типы, как a.a)
  2. обфускация потока управления (поэтому в декомпиляторе код очень трудно читать)
  3. шифрование строк и, возможно ресурсы

Я уверен, что есть и другие,но это основные. Я работаю в компании под названием PreEmptive Solutions на .NET обфускатор. У них также есть Java obfuscator, который работает для Android, а также называется Дашо.

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

в противном случае ваш единственный выбор-сделать так, чтобы ваше приложение Android просто проходило на сервер, на котором размещена вся реальная логика вашего приложения. В этом есть своя доля проблем, потому что это означает, что пользователи должны быть подключены к Интернету, чтобы использовать приложение.

кроме того, это не только Android, который имеет эту проблему. Это проблема в каждом app store. Это просто вопрос того, насколько сложно добраться до файла пакета (например, я не считаю, что это очень легко на айфонах, но это все еще возможно).


его невозможно полностью избежать RE, но, делая их более сложными внутри, вы ставите сделать его более трудным для злоумышленников, чтобы увидеть четкую работу приложения, которое может уменьшить количество векторов атаки.

Если приложение обрабатывает конфиденциальные данные, существуют различные методы, которые могут увеличить сложность обратного проектирования вашего кода. Один из методов-использовать C / C++ для ограничения простых манипуляций во время выполнения злоумышленником. Есть достаточно C и C++ библиотеки, которые очень зрелые и легко интегрируются с Android предлагает JNI. Злоумышленник должен сначала обойти ограничения отладки, чтобы атаковать приложение на низком уровне. Это еще больше усложняет атаку. Android-приложения должны иметь android: debuggable= "false", установленный в манифесте приложения, чтобы предотвратить легкое манипулирование временем выполнения злоумышленником или вредоносным ПО.

Проверка Трассировки – приложение может определить, является ли это в настоящее время отслеживается отладчиком или другим инструментом отладки. При отслеживании приложение может выполнить любое количество возможных действий ответа на атаку, таких как отбрасывание ключей шифрования для защиты пользовательских данных, уведомление администратора сервера или другие подобные ответы в попытке защитить себя. Это можно определить, проверив флаги состояния процесса или используя другие методы, такие как сравнение возвращаемого значения ptrace attach, проверка родительского процесса, отладчики черного списка в список процессов или сравнение временных меток в разных местах программы.

оптимизация - чтобы скрыть передовые математические вычисления и другие типы сложной логики, использование оптимизации компилятора может помочь скрыть объектный код, так что он не может быть легко разобран злоумышленником, что делает его более трудным для злоумышленника, чтобы получить представление о конкретном коде. В Android это может быть легко достигнуто путем использования изначально скомпилированные библиотеки с NDK. Кроме того, использование LLVM-обфускатора или любого защитного SDK обеспечит лучшую обфускацию машинного кода.

зачистки файлы – удаление собственных двоичных файлов-эффективный способ увеличить количество времени и уровень навыков, необходимых злоумышленнику, чтобы просмотреть состав функций низкого уровня вашего приложения. Путем удаления двоичного файла таблица символов двоичного файла удаляется, так что злоумышленник не может легко отладить или отменить инженер приложение.Вы можете ссылаться на методы, используемые в системах GNU/Linux, такие как sstriping или использование UPX.

и, наконец, вы должны знать о запутанности и таких инструментах, как ProGuard.


нет никакого способа полностью избежать обратного проектирования APK. Для защиты ресурсов приложения можно использовать шифрование.

  • шифрование затруднит его использование без расшифровки.выбор какого-то сильного алгоритма шифрования затруднит взлом.
  • добавление некоторого кода spoof в вашу основную логику, чтобы сделать более сложным для взлома.
  • Если вы можете написать свою критическую логику на любом родном языке, и это, безусловно, затрудняет декомпилировать.
  • использование любых сторонних фреймворков безопасности, таких как Quixxi

согласен с @Muhammad Saqib здесь: https://stackoverflow.com/a/46183706/2496464

и @Mumair дают хорошие начальные шаги: https://stackoverflow.com/a/35411378/474330

всегда можно с уверенностью предположить, что все, что вы распространяете на устройство пользователя, принадлежит пользователю. Просто и ясно. Вы можете использовать новейшие инструменты и процедуры для шифрования ваших интеллектуальных свойств, но нет способа предотвратить определенное человек из "изучения" вашей системы. И даже если современные технологии могут затруднить им получение нежелательного доступа, завтра или даже через час может быть какой-то простой способ!

таким образом, вот уравнение:

When it comes to money, we always assume that client is untrusted.

даже в такой простой, как экономика в игре. (Особенно в играх! Есть более "сложные" пользователи там и лазейки распространяются в считанные секунды!)

Как мы остаемся безопасными?

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


разве чипы TPM (Trusted Platform Module) не должны управлять защищенным кодом для вас ? Они становятся распространенными на ПК (особенно на Apple), и они уже могут существовать в современных чипах смартфонов. К сожалению, пока нет API ОС, чтобы использовать его. Надеюсь, Android добавит поддержку для этого в один прекрасный день. Это также ключ к очистке DRM контента (над которым работает Google для WebM).


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

  • поместите свою основную логику (алгоритмы) на стороне сервера.
  • связь с сервером и клиентом; убедитесь, что связь B/w сервер и клиент защищены через SSL или HTTPS; или использовать другие методы алгоритмов генерации пары ключей (ECC, RSA). Убедитесь, что конфиденциальная информация остается сквозной зашифрованный.
  • используйте сеансы и истекает их через определенный интервал времени.
  • шифровать ресурсы и получать их с сервера по требованию.
  • или вы можете сделать гибридное приложение, которое система доступа через webview защитить ресурс + код на сервере

несколько подходов; это очевидно, что вы должны пожертвовать среди производительность и безопасность



хотя я согласен, что нет 100% - ного решения, которое защитит ваш код, v3 из HoseDex2Jar теперь, если вы хотите попробовать.


Если ваше приложение является таким чувствительным, вы должны рассмотреть часть обработки платежей на стороне сервера. Попробуйте изменить алгоритмы обработки платежей. Используйте приложение android только для сбора и отображения информации о пользователе (i.e баланс счета) и вместо обработки платежей в кодах java отправьте эту задачу на сервер, используя безопасный протокол SSL с зашифрованными параметрами. Создайте полностью зашифрованный и безопасный API для связи с сервером.

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


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


инструмент: использование Proguard в вашем приложении может быть ограничено обратной инженерии вашего приложения


Я вижу, что хороший ответ в этой теме . Кроме того, вы можете использовать facebook redex для оптимизации кода. Redex работает на .dex уровень, где proguard работает как


просто дополнение к уже хорошим ответам выше.

еще один трюк, который я знаю, - хранить ценные коды в качестве библиотеки Java. Затем установите эту библиотеку в качестве вашего проекта Android. Было бы хорошо, как C .так что файл, но Android Lib будет делать.

таким образом, эти ценные коды, хранящиеся в библиотеке Android, не будут видны после декомпиляции.