Как сделать приложение «Android-unlocker» безопаснее против сухарей?

Question

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

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

Независимо от того, что я делаю, такая реализация не всегда приводит к простым if, как это:

if(Program.isPremiumVersion()) { 
    // Remove ads... 
} 

Метод isPremiumVersion() является ответственным за всю работу в проверке на платную установку Unlocker приложения, если сертификаты совпадают и все это. Да, приложение для разблокировки защищено латом (хотя я читал несколько статей, в которых упоминается, как небезопасный LVL, но сейчас это не так). Но, в конце концов, независимо от того, насколько сложным становится код внутри isPremiumVersion(), он всегда приводит к возврату значения true или false.

Переопределение такой функции безопасности - это всего лишь вопрос обратного проектирования кода и получения его, чтобы он всегда возвращал true. Это не? Как мы можем защитить наши Android-приложения от этого? И да, код запутан ProGuard. Тем не менее, не должно быть слишком сложно для кого-то достаточно квалифицированного.

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

Любые идеи для повышения безопасности такой функции?

Answer 1

Вы уже видели это, но вот какой-то код для реализации того, что вы говорите:

http://groups.google.com/group/android-developers/browse_thread/thread/4ad3d67f735f16d7/948b4f9eee2490a3?pli=1

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

Answer 2

Против этого нет простого способа.

Вы должны попытаться замаскировать его. Вот несколько советов:

Совет 1: Возвращение булева слишком очевидно. Попробуйте вернуть значение (например, int). Затем используйте сравнение, чтобы узнать, является ли это допустимым известным возвращаемым значением.

Например: получить md5 строки, содержащей что-то, из которого вы можете узнать, является ли это премией или нет. Скажите, что у вас есть статическая финальная строка для каждого приложения. Возможно, md5 одного начинается с 9, а другой начинается с 1. В этом случае вычислите md5 и посмотрите, больше ли это «случайного» числа, которое, как вы знаете, находится между двумя другими числами. Скажем, что md5 «premium» - 987, а md5 «free» - 123. Вы можете вычислить md5 и сравнить его с 456.

Совет 2 - Еще лучше: дублируйте код и используйте разные значения каждый раз (вместо 456)! Надеюсь, это затруднит процесс декодирования зафуцированного кода.

Я знаю, что все эти проверки в конечном итоге будут сопоставлены с булевым (if(1 > 2) будет оценен до if(true)), но сложнее будет перепроектировать ваше приложение.

Совет 3: не выполняйте проверки на «isPremium» в наиболее очевидных местах. Например, не выполняйте проверку при запуске приложения, так как это наиболее очевидное место для этого. Возможно, будет сложно избежать определенных очевидных точек, если вы хотите иметь условную логику в зависимости от версии приложения, но приложите все усилия!

Совет 4: Создайте и обфускайте свое приложение. Запустите обратные инженерные инструменты против вашего apk. Прочтите его и посмотрите, как он выглядит.

Наконец, смотреть эту презентацию ежедневно Google IO на завтрак: Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine

[EDIT - несколько советов]

Совет 6: попробовать использовать код, который используется для проверки в совершенно допустимых местах. Это может замаскировать то, что вы на самом деле делаете там. Это может включать вызов кода для проверки версии приложения, но ничего не значимого в этом. Или, в моем предыдущем примере, сравнение md5 с 012 или 999, только ради разбавления реального использования этих переменных.

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

Совет 8: не когда-либо использовать код LVL, как это предусмотрено в Google учебники. Измените его. Много!

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