Как избежать обратного инжиниринга файла APK?
Я занимаюсь разработкой приложения для обработки платежей для Android и хочу запретить хакеру доступ к любым ресурсам, ресурсам или исходному коду из файла APK.
Если кто-то изменяет расширение.apk на.zip, то он может разархивировать его и легко получить доступ ко всем ресурсам и ресурсам приложения, а с помощью dex2jar и декомпилятора Java они также могут получить доступ к исходному коду. Обратный инжиниринг Android APK-файла очень легко - более подробно см. Вопрос переполнения стека. Обратный инжиниринг из APK-файла в проект.
Я использовал инструмент Proguard, поставляемый с Android SDK. Когда я выполняю обратный инжиниринг APK-файла, созданного с использованием подписанного хранилища ключей и Proguard, я получаю запутанный код.
Однако имена компонентов Android остаются неизменными, а некоторый код, например значения ключей, используемые в приложении, остается неизменным. Согласно документации Proguard, инструмент не может запутать компоненты, упомянутые в файле Manifest.
Теперь мои вопросы:
- Как я могу полностью предотвратить реверс-инжиниринг Android APK? Это возможно?
- Как я могу защитить все ресурсы, ресурсы и исходный код приложения, чтобы хакеры никак не могли взломать APK-файл?
- Есть ли способ сделать взлом более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем файле APK?
35 ответов
1. Как мне полностью избежать реверс-инжиниринга Android APK? Это возможно?
AFAIK, нет никакого уловки для полного избежания обратного проектирования.
И также очень хорошо сказано @inazaruk: что бы вы ни делали со своим кодом, потенциальный злоумышленник может изменить его любым способом, который он или она сочтет возможным. Вы в принципе не можете защитить свое приложение от изменения. И любая защита, которую вы вставите туда, может быть отключена / удалена.
2. Как я могу защитить все ресурсы приложения, ресурсы и исходный код, чтобы хакеры не могли каким-либо образом взломать APK-файл?
Вы можете делать разные трюки, чтобы сделать хакерство сложнее. Например, используйте обфускацию (если это Java-код). Это обычно значительно замедляет реверс-инжиниринг.
3. Есть ли способ сделать взлом более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем файле APK?
Как все говорят, и, как вы, наверное, знаете, нет 100% безопасности. Но Google должен начать с Android, и это ProGuard. Если у вас есть возможность включения общих библиотек, вы можете включить необходимый код в C++ для проверки размеров файлов, интеграции и т. Д. Если вам нужно добавить внешнюю собственную библиотеку в папку библиотеки APK на каждой сборке, то вы можете использовать ее по предложению ниже.
Поместите библиотеку в собственный путь к библиотеке, который по умолчанию равен "libs" в папке вашего проекта. Если вы создали собственный код для цели armeabi, поместите его в libs / armeabi. Если он был собран с помощью armeabi-v7a, поместите его в libs/armeabi-v7a.
<project>/libs/armeabi/libstuff.so
AFAIK, вы не можете защитить файлы в каталоге /res больше, чем они защищены прямо сейчас.
Тем не менее, есть шаги, которые вы можете предпринять, чтобы защитить свой исходный код или, по крайней мере, то, что он делает, если не все.
- Используйте такие инструменты, как ProGuard. Это запутывает ваш код и затрудняет чтение при декомпиляции, если не невозможно.
- Переместите наиболее важные части службы из приложения в веб-сервис, скрытый за языком серверной стороны, таким как PHP. Например, если у вас есть алгоритм, который написал вам миллион долларов. Вы, очевидно, не хотите, чтобы люди крали его из вашего приложения. Переместите алгоритм и сделайте так, чтобы он обрабатывал данные на удаленном сервере, и используйте приложение, чтобы просто предоставить ему данные. Или используйте NDK для записи их в.so файлы, которые с меньшей вероятностью будут декомпилированы, чем apks. Я не думаю, что декомпилятор для.so файлов даже существует на данный момент (и даже если бы он существовал, он не был бы так же хорош, как декомпиляторы Java). Кроме того, как упоминалось в комментариях @nikolay, вы должны использовать SSL при взаимодействии между сервером и устройством.
- При хранении значений на устройстве не храните их в необработанном формате. Например, если у вас есть игра, и вы храните сумму в игровой валюте, которую пользователь имеет в SharedPreferences. Давайте предположим, что это
10000монеты. Вместо сохранения10000сохраните его, используя алгоритм((currency*2)+1)/13, Так что вместо10000, вы сэкономили1538.53846154в SharedPreferences. Однако приведенный выше пример не идеален, и вам нужно будет поработать, чтобы придумать уравнение, которое не будет терять валюту из-за ошибок округления и т. Д. - Вы можете сделать то же самое для задач на стороне сервера. Теперь для примера давайте возьмем ваше приложение для обработки платежей. Допустим, пользователь должен сделать платеж
$200, Вместо отправки сырого$200значение на сервер, отправить серию меньших предопределенных значений, которые складываются в$200, Например, на вашем сервере есть файл или таблица, в которой слова сравниваются со значениями. Так скажем, чтоCharlieсоответствует$47, а такжеJohnв$3, Так что вместо отправки$200, ты можешь отправитьCharlieчетыре раза иJohnчетыре раза. На сервере интерпретируйте их значение и сложите их. Это не позволяет хакеру отправлять произвольные значения на ваш сервер, поскольку они не знают, какое слово соответствует какому значению. В качестве дополнительной меры безопасности вы можете использовать уравнение, аналогичное пункту 3, и изменять ключевые слова каждый раз.nколичество дней. - Наконец, вы можете вставить случайный бесполезный исходный код в ваше приложение, чтобы хакер искал иголку в стоге сена. Вставьте случайные классы, содержащие фрагменты из Интернета, или просто функции для вычисления случайных вещей, таких как последовательность Фибоначчи. Убедитесь, что эти классы компилируются, но не используются реальной функциональностью приложения. Добавьте достаточно этих ложных классов, и хакеру будет нелегко найти ваш реальный код.
В общем, нет способа защитить ваше приложение на 100%. Вы можете сделать это сложнее, но не невозможно. Ваш веб-сервер может быть скомпрометирован, хакер может выяснить ваши ключевые слова, отслеживая суммы транзакций и ключевые слова, которые вы отправляете для него, хакер может тщательно изучить исходный код и выяснить, какой код является фиктивным.
Вы можете только дать отпор, но никогда не выиграть.
Ни в одной точке истории вычислений не было возможности предотвратить реверс-инжиниринг программного обеспечения, когда вы предоставляете рабочую копию его злоумышленнику. Кроме того, по всей вероятности, это никогда не будет возможно.
С этим пониманием, есть очевидное решение: не передавайте свои секреты злоумышленнику. Хотя вы не можете защитить содержимое вашего APK, вы можете защитить то, что не распространяете. Как правило, это программное обеспечение на стороне сервера, используемое для таких вещей, как активация, платежи, принудительное применение правил и другие сочные фрагменты кода. Вы можете защитить ценные активы, не распределяя их в вашем APK. Вместо этого настройте сервер, который отвечает на запросы от вашего приложения, "использует" ресурсы (что бы это ни значило) и затем отправляет результат обратно в приложение. Если эта модель не работает для активов, которые вы имеете в виду, вы можете пересмотреть свою стратегию.
Кроме того, если вашей главной целью является предотвращение пиратства приложений: даже не беспокойтесь. Вы уже потратили больше времени и денег на эту проблему, чем любая мера по борьбе с пиратством, которая когда-либо могла бы вас спасти. Возврат инвестиций для решения этой проблемы настолько низок, что не имеет смысла даже думать об этом.
Первое правило безопасности приложения: любая машина, к которой злоумышленник получает неограниченный физический или электронный доступ, теперь принадлежит вашему злоумышленнику, независимо от того, где он находится на самом деле или за что вы заплатили.
Второе правило безопасности приложения: любое программное обеспечение, которое выходит за физические границы, в которые злоумышленник не может проникнуть, теперь принадлежит вашему злоумышленнику, независимо от того, сколько времени вы потратили на его кодирование.
Третье правило: любая информация, выходящая за те же физические границы, в которую злоумышленник не может проникнуть, теперь принадлежит вашему злоумышленнику, независимо от того, насколько она ценна для вас.
Основы безопасности информационных технологий основаны на этих трех фундаментальных принципах; единственный действительно безопасный компьютер - это тот, который заперт в сейфе внутри клетки Фаррадея, внутри стальной клетки. Есть компьютеры, которые проводят большую часть своего срока службы именно в этом состоянии; один раз в год (или реже) они генерируют закрытые ключи для доверенных корневых центров сертификации (перед множеством свидетелей с камерами, записывающими каждый дюйм помещения, в котором они находятся).
В настоящее время большинство компьютеров не используются в этих типах сред; они физически находятся на улице, подключены к Интернету по беспроводному радиоканалу. Короче говоря, они уязвимы, как и их программное обеспечение. Поэтому им нельзя доверять. Существуют определенные вещи, которые компьютеры и их программное обеспечение должны знать или делать для того, чтобы быть полезными, но необходимо позаботиться о том, чтобы они никогда не знали или не делали достаточно, чтобы нанести ущерб (по крайней мере, непоправимый ущерб за пределами этой отдельной машины).).
Вы уже знали все это; Вот почему вы пытаетесь защитить код вашего приложения. Но в этом заключается первая проблема; инструменты запутывания могут сделать код беспорядком для человека, чтобы попытаться разобраться, но программа все еще должна работать; это означает, что фактический логический поток приложения и данные, которые оно использует, не подвержены запутыванию. Учитывая немного упорства, злоумышленник может просто не запутывать код, и это даже не требуется в определенных случаях, когда то, на что он смотрит, не может быть ничем иным, кроме того, что он ищет.
Вместо этого вы должны пытаться гарантировать, что злоумышленник не сможет ничего сделать с вашим кодом, независимо от того, насколько легко ему получить его четкую копию. Это означает, что нет жестко закодированных секретов, потому что эти секреты не являются секретными, как только код покидает здание, в котором вы его разработали.
Эти значения ключей, которые вы жестко запрограммировали, должны быть полностью удалены из исходного кода приложения. Вместо этого они должны быть в одном из трех мест; энергозависимая память на устройстве, которую злоумышленнику труднее (но все же не невозможно) получить автономную копию; постоянно на кластере серверов, к которому вы управляете доступом железным кулаком; или во втором хранилище данных, не связанном с вашим устройством или серверами, например, физической картой или в памяти вашего пользователя (это означает, что в конечном итоге он будет находиться в энергозависимой памяти, но это не займет много времени).
Рассмотрим следующую схему. Пользователь вводит свои учетные данные для приложения из памяти в устройство. К сожалению, вы должны верить, что устройство пользователя еще не взломано кейлоггером или трояном; лучшее, что вы можете сделать в этом отношении, - это реализовать многофакторную безопасность, запоминая трудно подделываемую информацию об устройствах, которые использовал пользователь (MAC/IP, IMEI и т. д.), и предоставив по крайней мере один дополнительный канал с помощью какую попытку входа в систему на незнакомом устройстве можно проверить.
Учетные данные после их ввода обфусцируются клиентским программным обеспечением (с использованием безопасного хэша), а учетные данные в виде простого текста отбрасываются; они послужили своей цели. Обфусцированные учетные данные отправляются по защищенному каналу на сервер, прошедший проверку подлинности сертификата, который снова хэширует их для получения данных, используемых для проверки правильности входа в систему. Таким образом, клиент никогда не знает, что на самом деле сравнивается со значением базы данных, сервер приложений никогда не знает учетные данные в виде открытого текста, которые он получает для проверки, сервер данных никогда не знает, как создаются данные, которые он хранит для проверки, и человек в середина видит только тарабарщину, даже если безопасный канал был взломан.
После проверки сервер передает токен по каналу. Токен полезен только в безопасном сеансе, состоит из случайного шума или зашифрованной (и, следовательно, проверяемой) копии идентификаторов сеанса, и клиентское приложение должно отправить этот токен по тому же каналу на сервер как часть любого запроса. сделать что-то. Клиентское приложение будет делать это много раз, потому что оно не может делать ничего, включая деньги, конфиденциальные данные или что-либо еще, что может повредить само по себе; вместо этого он должен попросить сервер выполнить эту задачу. Клиентское приложение никогда не будет записывать какую-либо конфиденциальную информацию в постоянную память на самом устройстве, по крайней мере, не в виде простого текста; клиент может запросить у сервера через безопасный канал симметричный ключ для шифрования любых локальных данных, которые сервер запомнит; в более позднем сеансе клиент может запросить у сервера тот же ключ для дешифрования данных для использования в энергозависимой памяти. Эти данные тоже не будут единственной копией; все, что хранит клиент, также должно быть в той или иной форме передано на сервер.
Очевидно, что это делает ваше приложение сильно зависимым от доступа в Интернет; клиентское устройство не может выполнять какие-либо из своих основных функций без надлежащего подключения к серверу и его аутентификации. Не отличается от Facebook, правда.
Теперь компьютер, который хочет злоумышленник, - это ваш сервер, потому что именно он, а не клиентское приложение / устройство - это то, что может принести ему деньги или причинить другим людям боль от его удовольствия. Это нормально; вы получаете гораздо больше денег, затрачивая деньги и усилия на защиту сервера, чем на защиту всех клиентов. Сервер может находиться за всеми видами брандмауэров и другой электронной безопасности, а также может быть физически защищен за стальным, бетонным доступом, доступом с помощью карточек / штырьков и круглосуточным видеонаблюдением. Ваш злоумышленник должен быть очень изощренным, чтобы получить любой доступ к серверу напрямую, и вы должны (должны) знать об этом немедленно.
Лучшее, что может сделать злоумышленник, - это украсть телефон и учетные данные пользователя и войти на сервер с ограниченными правами клиента. Если это произойдет, как если бы вы потеряли кредитную карту, законный пользователь должен получить указание позвонить по номеру 800 (желательно, чтобы его было легко запомнить, а не на оборотной стороне карты, которую он носил бы в своем кошельке, кошельке или портфеле, который может быть украденный вместе с мобильным устройством) с любого телефона, к которому у них есть доступ, который напрямую связывает их с вашей службой поддержки клиентов. Они утверждают, что их телефон был украден, предоставляют некоторый базовый уникальный идентификатор, а учетная запись заблокирована, любые транзакции, которые злоумышленник, возможно, смог обработать, откатываются, и злоумышленник возвращается к исходной точке.
1. Как мне полностью избежать реверс-инжиниринга Android APK? Это возможно?
Это невозможно
2. Как я могу защитить все ресурсы приложения, ресурсы и исходный код, чтобы хакеры не могли каким-либо образом взломать APK-файл?
Когда кто-то меняет расширение.apk на.zip, то после разархивирования кто-то может легко получить все ресурсы (кроме Manifest.xml), но с помощью APKtool можно также получить реальное содержимое файла манифеста. Опять нет.
3. Есть ли способ сделать взлом более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем файле APK?
Опять же нет, но вы можете предотвратить до некоторого уровня, то есть
- Загрузите ресурс из Интернета и выполните некоторый процесс шифрования
- Используйте предварительно скомпилированную нативную библиотеку (C, C++, JNI, NDK)
- Всегда выполняйте хеширование (ключи MD5/ SHA или любая другая логика)
Даже с Smaliлюди могут играть с вашим кодом. В общем, это НЕ ВОЗМОЖНО.
100% -ное предотвращение реверс-инжиниринга Android APK невозможно, но вы можете использовать эти способы, чтобы избежать извлечения дополнительных данных, таких как исходный код, ресурсы из вашего APK и ресурсы:
Используйте ProGuard, чтобы запутать код приложения
Используйте NDK, используя C и C++, чтобы поместить ядро вашего приложения и защитить часть кода в
.soфайлыЧтобы защитить ресурсы, не включайте все важные ресурсы в папку ресурсов с APK. Загрузите эти ресурсы во время первого запуска приложения.
Разработчики могут предпринять следующие шаги, чтобы предотвратить кражу APK,
самый простой способ заключается в использовании таких инструментов, как
ProGuardчтобы запутать их код, но до сих пор было довольно сложно полностью помешать кому-либо декомпилировать приложение.Также я слышал об инструменте HoseDex2Jar. Останавливается
Dex2Jarвставляя безвредный код в Android APK, который сбивает с толку и отключаетDex2Jarи защищает код от декомпиляции. Это может как-то помешать хакерам декомпилировать APK в читаемый код Java.Используйте некоторое приложение на стороне сервера для связи с приложением только тогда, когда это необходимо. Это может помочь предотвратить важные данные.
Вообще, вы не можете полностью защитить свой код от потенциальных хакеров. Каким-то образом вы могли бы усложнить и немного расстроить их задачу декомпиляции вашего кода. Один из наиболее эффективных способов - это писать в нативном коде (C/C++) и хранить его как скомпилированные библиотеки.
Вот несколько способов, которые вы можете попробовать:
- Используйте обфускацию и такие инструменты, как ProGuard.
- Зашифруйте некоторую часть источника и данных.
- Используйте проприетарную встроенную контрольную сумму в приложении для обнаружения взлома.
- Введите код, чтобы избежать загрузки в отладчике, то есть дайте приложению возможность обнаруживать отладчик и выходить из него / убивать его.
- Отделяйте аутентификацию как онлайн-сервис.
- Используйте разнообразие приложений
- Используйте технику отпечатков пальцев, например, для аппаратных сигнатур устройств из другой подсистемы перед аутентификацией устройства.
1. Как мне полностью избежать реверс-инжиниринга Android APK? Это возможно?
Невозможно
2. Как я могу защитить все ресурсы приложения, ресурсы и исходный код, чтобы хакеры не могли каким-либо образом взломать APK-файл?
Невозможно
3. Есть ли способ сделать взлом более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем файле APK?
Более сложный - возможно, но на самом деле это будет более жестким, в основном для обычного пользователя, который просто ищет гаджеты по взлому. Если кто-то действительно хочет взломать ваше приложение - оно будет взломано, рано или поздно.
1. Как мне полностью избежать реверс-инжиниринга Android APK? Это возможно?
Это невозможно
2. Как я могу защитить все ресурсы приложения, ресурсы и исходный код, чтобы хакеры не могли каким-либо образом взломать APK-файл?
Разработчики могут предпринять такие шаги, как использование таких инструментов, как ProGuard, для запутывания своего кода, но до сих пор было довольно сложно полностью предотвратить компиляцию приложения.
Это действительно отличный инструмент, и он может увеличить сложность "перевернуть" ваш код, в то же время уменьшая его площадь.
Интегрированная поддержка ProGuard: ProGuard теперь поставляется с SDK Tools. Теперь разработчики могут запутывать свой код как интегрированную часть сборки релиза.
3. Есть ли способ сделать взлом более жестким или даже невозможным? Что еще я могу сделать, чтобы защитить исходный код в моем файле APK?
Во время исследования я узнал о HoseDex2Jar. Этот инструмент защитит ваш код от декомпиляции, но, кажется, невозможно полностью защитить ваш код.
Некоторые полезные ссылки, вы можете обратиться к ним.
Основной вопрос здесь заключается в том, можно ли декомпилировать файлы dex, и ответ на них может быть "своего рода". Есть такие дизассемблеры, как dedexer и smali.
ProGuard, правильно настроенный, запутает ваш код. DexGuard, который является коммерческой расширенной версией ProGuard, может помочь немного больше. Тем не менее, ваш код все еще может быть преобразован в smali, и разработчики с опытом обратного проектирования смогут выяснить, что вы делаете из smali.
Может быть, выбрать хорошую лицензию и обеспечить соблюдение закона в лучшем виде.
Ваш клиент должен нанять кого-то, кто знает, что он делает, кто может принимать правильные решения и может наставлять вас.
Говорить выше о том, что у вас есть какая-то возможность изменять систему обработки транзакций на бэкэнде, абсурдно - нельзя допускать таких архитектурных изменений, поэтому не ожидайте, что сможете это сделать.
Мое обоснование этого:
Поскольку ваш домен обрабатывает платежи, можно с уверенностью предположить, что PCI DSS и / или PA DSS (и потенциальный закон штата / федеральный закон) будут важны для вашего бизнеса - чтобы соответствовать требованиям, вы должны показать свою безопасность. Чтобы быть небезопасным, выясните (через тестирование), что вы не защищены, затем исправьте, проведите повторное тестирование и так далее, пока безопасность не будет проверена на подходящем уровне = дорогой, медленный, рискованный путь к успеху. Чтобы поступить правильно, тщательно продумайте все заранее, привлеките опытный талант к работе, развивайтесь безопасным образом, затем тестируйте, исправляйте (меньше) и так далее (меньше), пока безопасность не будет проверена на подходящем уровне = недорого, быстро, путь к успеху с низким уровнем риска.
Как человек, который много работал на платежных платформах, включая одно мобильное платежное приложение (MyCheck), я бы сказал, что вам нужно делегировать это поведение на сервер, не нужно хранить имя пользователя или пароль для обработчика платежей (какой бы он ни был) или это жестко закодировано в мобильном приложении, это последнее, что вы хотите, потому что источник может быть понят, даже если вы запутываете код.
Кроме того, вы не должны хранить кредитные карты или платежные токены в приложении, все должно быть опять-таки делегировано на созданный вами сервис, это также позволит вам в дальнейшем, легче соответствовать PCI, и компании, выпустившие кредитные карты, выиграли не дышите на шею (как они сделали для нас).
Если мы хотим сделать реверс-инжиниринг (почти) невозможным, мы можем поместить приложение в микросхему с высокой степенью защиты от несанкционированного доступа, которая выполняет все важные элементы внутри себя и взаимодействует с некоторым протоколом, чтобы сделать возможным управление GUI на хосте. Даже устойчивые к взлому чипы не на 100% устойчивы к растрескиванию; они просто устанавливают планку намного выше, чем программные методы. Конечно, это неудобно: приложению требуется небольшая USB-бородавка, которая удерживает чип для вставки в устройство.
Вопрос не раскрывает мотивацию желания ревниво защищать это приложение.
Если цель состоит в том, чтобы повысить безопасность метода оплаты путем сокрытия любых недостатков безопасности, которые может иметь приложение (известные или иные), оно полностью ошибочно. Чувствительные к безопасности биты на самом деле должны быть с открытым исходным кодом, если это возможно. Любой исследователь безопасности, который просматривает ваше приложение, должен сделать так, чтобы как можно проще было найти эти биты, тщательно изучить их работу и связаться с вами. Платежные приложения не должны содержать никаких встроенных сертификатов. То есть не должно быть серверных приложений, которые доверяют устройству просто потому, что оно имеет фиксированный сертификат с завода. Платежная транзакция должна быть сделана только на основании учетных данных пользователя с использованием правильно разработанного протокола сквозной аутентификации, который исключает доверие к приложению, платформе или сети и т. Д.
Если цель состоит в том, чтобы предотвратить клонирование, за исключением этого защищенного от взлома чипа, вы ничего не сможете сделать, чтобы защитить программу от повторного проектирования и копирования, чтобы кто-то включил совместимый метод оплаты в свое собственное приложение, предоставляя подняться до "неавторизованных клиентов". Есть способы усложнить разработку неавторизованных клиентов. Можно было бы создать контрольные суммы на основе снимков полного состояния программы: все переменные состояния для всего. GUI, логика, что угодно. Программа-клон не будет иметь точно такое же внутреннее состояние. Несомненно, это конечный автомат, который имеет подобные внешне видимые переходы состояний (что можно наблюдать по входам и выходам), но вряд ли одно и то же внутреннее состояние. Серверное приложение может опросить программу: каково ваше подробное состояние? (т.е. дайте мне контрольную сумму по всем вашим внутренним переменным состояния). Это можно сравнить с фиктивным клиентским кодом, который выполняется на сервере параллельно, проходя через переходы подлинного состояния. Сторонний клон должен будет повторить все соответствующие изменения состояния подлинной программы, чтобы дать правильные ответы, которые будут препятствовать ее развитию.
Другие ответы здесь верны. Я просто хочу предоставить другой вариант.
Для определенных функций, которые вы считаете важными, вы можете разместить в своем приложении элемент управления WebView. Функциональность будет затем реализована на вашем веб-сервере. Это будет выглядеть так, как будто оно работает в вашем приложении.
Договорились с @Muhammad Saqib здесь: /questions/10331679/kak-izbezhat-obratnogo-inzhiniringa-fajla-apk/10331707#10331707
И @Mumair дают хорошие стартовые шаги: /questions/10331679/kak-izbezhat-obratnogo-inzhiniringa-fajla-apk/10331710#10331710
Всегда безопасно предположить, что все, что вы распространяете на устройстве вашего пользователя, принадлежит пользователю. Легко и просто. Возможно, вы сможете использовать новейшие инструменты и процедуры для шифрования вашей интеллектуальной собственности, но нет способа помешать определенному человеку "изучить" вашу систему. И даже если текущая технология может затруднить получение нежелательного доступа, завтра может быть легкий путь или даже просто следующий час!
Таким образом, здесь приходит уравнение:
When it comes to money, we always assume that client is untrusted.
Даже в такой простой, как внутриигровая экономика. (Особенно в играх! Там больше "искушенных" пользователей, и лазейки расползаются за секунды!)
Как мы можем оставаться в безопасности?
Большинство, если не все, наших систем обработки ключей (и, конечно, базы данных) расположены на стороне сервера. А между клиентом и сервером лежит зашифрованная связь, проверки и т. Д. Такова идея тонкого клиента.
APK схема подписи v2 в Android N
Класс PackageManager теперь поддерживает проверку приложений с использованием схемы подписи APK v2. Схема подписи APK v2 - это схема подписи всего файла, которая значительно повышает скорость проверки и усиливает гарантии целостности, обнаруживая любые несанкционированные изменения в файлах APK.
Для обеспечения обратной совместимости APK должен быть подписан схемой подписи v1 (схема подписи JAR), прежде чем подписываться схемой подписи v2. При использовании схемы подписи v2 проверка завершается неудачно, если вы подписываете APK дополнительным сертификатом после подписания по схеме v2.
Поддержка схемы подписи APK v2 будет доступна позже в N Developer Preview.
Я предлагаю вам взглянуть на Защиту программных приложений от атак. Это коммерческий сервис, но компания моего друга воспользовалась этим, и они рады его использовать.
100% безопасность исходного кода и ресурсов в Android невозможна. Но вы можете сделать немного сложным для реинженера. Вы можете найти более подробную информацию об этом в следующих ссылках:
Посетите раздел Безопасное сохранение постоянных значений и https://www.agicent.com/blog/mobile-app-security-best-practices/
Нет никакого способа полностью избежать реверс-инжиниринга APK. Для защиты ресурсов приложения, ресурсов вы можете использовать шифрование.
- Шифрование усложнит использование без расшифровки. Выбор надежного алгоритма шифрования усложнит взлом.
- Добавление некоторого поддельного кода в вашу основную логику, чтобы усложнить взлом.
- Если вы можете написать свою критическую логику на любом родном языке, и это, безусловно, затруднит декомпиляцию.
- Использование любых сторонних систем безопасности, таких как Quixxi
Инструмент: использование Proguard в вашем приложении может быть ограничено для обратного проектирования вашего приложения
Я знал, что некоторые банковские приложения используют DexGuard, который обеспечивает обфускацию, а также шифрование классов, строк, активов, файлов ресурсов и собственных библиотек.
Ничто не является безопасным, когда вы кладете его в руки конечных пользователей, но некоторые распространенные практики могут затруднить злоумышленнику кражу данных.
- Поместите свою основную логику (алгоритмы) в сторону сервера.
- Общаться с сервером и клиентом; убедитесь, что связь между ч / б сервером и клиентом защищена через SSL или HTTPS; или использовать другие методы генерации пар ключей (ECC, RSA). Убедитесь, что конфиденциальная информация остается в зашифрованном виде.
- Используйте сеансы и истекайте их через определенный промежуток времени.
- Шифруйте ресурсы и извлекайте их с сервера по требованию.
- Или вы можете сделать гибридное приложение, которое получает доступ к системе через
webviewзащитить ресурс + код на сервере
Множественные подходы; это очевидно, что вы должны жертвовать производительностью и безопасностью
Невозможно полностью избежать RE, но, сделав их внутренне более сложными, вы помешаете злоумышленникам увидеть четкую работу приложения, что может уменьшить количество векторов атак.
Если приложение обрабатывает высокочувствительные данные, существуют различные методы, которые могут усложнить обратный инжиниринг вашего кода. Одним из методов является использование C/C++ для ограничения легких манипуляций во время выполнения злоумышленником. Существует множество библиотек C и C++, которые очень развиты и легко интегрируются с Android-предложениями JNI. Злоумышленник должен сначала обойти ограничения отладки, чтобы атаковать приложение на низком уровне. Это добавляет дополнительную сложность атаке. Приложения Android должны иметь android:debuggable=”false”, установленный в манифесте приложения, чтобы предотвратить простую манипуляцию во время выполнения злоумышленником или вредоносным ПО.
Проверка трассировки - приложение может определить, отслеживается ли оно в данный момент отладчиком или другим средством отладки. При отслеживании приложение может выполнить любое количество возможных действий ответа на атаку, например, сбросить ключи шифрования для защиты пользовательских данных, уведомление администратора сервера или ответы другого типа, пытаясь защитить себя. Это можно определить, проверив флаги состояния процесса или используя другие методы, такие как сравнение возвращаемого значения ptrace attach, проверка родительского процесса, отладчиков черного списка в списке процессов или сравнение временных меток в разных местах программы.
Оптимизации - Чтобы скрыть сложные математические вычисления и другие типы сложной логики, использование оптимизаций компилятора может помочь запутать объектный код, так что злоумышленник не сможет его легко разобрать, что затруднит понимание злоумышленником конкретного кода. В Android этого проще достичь, используя встроенные библиотеки с NDK. Кроме того, использование Обфускатора LLVM или любого SDK защитника обеспечит лучшую запутывание машинного кода.
Удаление двоичных файлов - удаление собственных двоичных файлов - это эффективный способ увеличить количество времени и уровень навыков, требуемых от злоумышленника, чтобы просмотреть структуру функций низкого уровня вашего приложения. При удалении двоичного файла таблица символов двоичного кода удаляется, так что злоумышленник не может легко отладить или перепроектировать приложение. Вы можете ссылаться на методы, используемые в системах GNU/Linux, такие как sstriping или использование UPX.
И, наконец, вы должны быть в курсе обфускации и таких инструментов, как ProGuard.
Если ваше приложение настолько чувствительно, то вы должны рассмотреть часть обработки платежей на стороне сервера. Попробуйте изменить ваши алгоритмы обработки платежей. Используйте приложение Android только для сбора и отображения информации о пользователе (например, об остатке на счете), а не для обработки платежей в кодах Java. Отправьте эту задачу на свой сервер, используя безопасный протокол SSL с зашифрованными параметрами. Создайте полностью зашифрованный и безопасный API для связи с вашим сервером.
Конечно, он также может быть взломан и не имеет ничего общего с защитой исходных кодов, но считается, что это еще один уровень безопасности, чтобы хакерам было сложнее обмануть ваше приложение.
В принципе это невозможно. Это никогда не будет возможно. Однако есть надежда. Вы можете использовать обфускатор, чтобы сделать это так, что некоторые общие атаки намного сложнее выполнить, включая такие вещи, как:
- Переименование методов / классов (поэтому в декомпиляторе вы получаете такие типы, как
a.a) - Запутывание потока управления (поэтому в декомпиляторе код очень трудно читать)
- Шифрование строк и, возможно, ресурсов
Я уверен, что есть и другие, но это основные. Я работаю в компании под названием PreEmptive Solutions на обфускаторе .NET. У них также есть Java-обфускатор, который работает для Android, который называется DashO.
Однако запутывание всегда идет с ценой. Примечательно, что производительность, как правило, хуже, и обычно требуется дополнительное время для релизов. Однако, если ваша интеллектуальная собственность чрезвычайно важна для вас, то она обычно того стоит.
В противном случае ваш единственный выбор - сделать так, чтобы ваше Android-приложение просто передавалось на сервер, на котором размещена вся реальная логика вашего приложения. У этого есть своя доля проблем, потому что это означает, что пользователи должны быть подключены к Интернету, чтобы использовать ваше приложение.
Кроме того, не только Android имеет эту проблему. Это проблема в каждом магазине приложений. Это просто вопрос того, насколько трудно получить доступ к файлу пакета (например, я не верю, что это очень легко на iPhone, но это все еще возможно).
Я вижу этот хороший ответ в этой теме. В дополнение к вы можете использовать Facebook redex оптимизировать код. Redex работает на .dex уровень, на котором Proguard работает как .class уровень.
Разве чипы TPM (Trusted Platform Module) не предназначены для управления защищенным кодом для вас? Они становятся обычным явлением на ПК (особенно на Apple) и, возможно, уже существуют в современных чипах для смартфонов. К сожалению, пока нет API для ОС, чтобы использовать его. Надеюсь, Android добавит поддержку этого дня. Это также ключ к чистому контенту DRM (над которым Google работает для WebM).
Как я могу защитить все ресурсы, ресурсы и исходный код приложения, чтобы хакеры никак не могли взломать APK-файл?
Файл APK защищен алгоритмом SHA-1. Вы можете увидеть некоторые файлы в папке META-INF на APK. Если вы извлечете какой-либо файл APK и измените его содержимое, а затем снова заархивируете его, и когда вы запустите этот новый файл APK на компьютере Android, он не будет работать, потому что хэши SHA-1 никогда не будут совпадать.
Хотя я согласен, что не существует 100% -го решения, которое защитит ваш код, v3 HoseDex2Jar теперь работает, если вы хотите попробовать.