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

Ответ 1

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

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

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

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

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

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

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

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

<project>/libs/armeabi/libstuff.so

Ответ 2

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%. Вы можете сделать это сложнее, но не невозможно. Ваш веб-сервер может быть взломан, хакер может определить ваши ключевые слова, отслеживая количество транзакций и ключевые слова, которые вы отправляете для него, хакер может кропотливо пройти через источник и выяснить, какой код является манекеном.

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

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

Когда кто-то изменит расширение .apk на .zip, то после распаковки кто-то может легко получить все ресурсы (кроме Manifest.xml), но с APKtool можно получить реальное содержимое файла манифеста. Опять же, нет.

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

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

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

Даже с Smali люди могут играть с вашим кодом. В общем, это НЕ ВОЗМОЖНО.

Ответ 6

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

• Используйте ProGuard для обфускации кода приложения

• Используйте NDK с помощью C и С++ для размещения вашего ядра приложения и обеспечения части кода в файлах .so

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

Ответ 7

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

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

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

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

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

Ответ 8

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

невыполнима

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

невыполнима

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

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

Ответ 9

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

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

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

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

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

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

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

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

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

• Proguard, Android и сервер лицензирования
• Защита приложений Android LVL
• Вопрос о переполнении стека Невозможно ли защитить приложения Android от обратного проектирования?
• Вопрос о переполнении стека Как предотвратить обратное проектирование файла APK Android для защиты кода?

Ответ 10

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

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

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

Ответ 11

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

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

Ответ 12

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

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

Мое логическое обоснование:

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

Ответ 13

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

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

Ответ 14

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

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

Ответ 15

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

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

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

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

Ответ 16

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

Ответ 17

Схема подписки APK v2 в Android N

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

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

Поддержка схемы подписки APK v2 будет доступна позже в N Developer Preview.

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

Ответ 18

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

• Переименование методов/классов (поэтому в декомпиляторе вы получаете такие типы, как a.a)
• Обтекающий поток управления (поэтому в декомпиляторе код очень трудно прочитать)
• Шифрование строк и, возможно, ресурсов

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

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

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

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

Ответ 19

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

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

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

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

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

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

Ответ 20

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

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

Ответ 21

Согласен с @Muhammad Saqib здесь: fooobar.com/questions/13331/...

И @Mumair дают хорошие стартовые шаги: fooobar.com/questions/13331/...

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

Таким образом, здесь приходит уравнение:

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

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

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

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

Ответ 22

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

Ответ 23

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

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

Несколько подходов; это очевидно, что вы должны жертвовать услугами и

Ответ 24

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

Файл APK защищен с помощью алгоритма SHA-1. Вы можете увидеть некоторые файлы в папке META-INF APK. Если вы извлечете какой-либо файл APK и измените его содержимое, а затем заново запишите его, и когда вы запустите этот новый файл APK на машине Android, это не сработает, потому что хэши SHA-1 никогда не будут совпадать.

Ответ 25

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

Ответ 26

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

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

Ответ 27

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

Ответ 28

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

Ответ 29

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

Ответ 30

Я поставил свою мысль под вопросами Stackoverflow. 100% безопасность исходного кода и ресурсов в Android невозможна. Но вы можете сделать немного сложным для реинженера.

Посетите раздел Как защитить исходный код Android