Pull to refresh

Comments 12

Как бы ты защитил приложение от подобной атаки? Ведь по сути любая функциональность "за флажком" может быть включена

Наверняка защититься от подмены функциональности "за флажком" нельзя, можно лишь посмотреть в сторону усложнения реверс-инжениринга.

Вынесение текста вроде "You reached the maximum number of allowed free Zones" в ресурсы не поможет, т.к. легко соотнести id ресурса с текстом.

Вынесение функции в натив не особо усложнит задачу, т.к. будет обертка над нативными вызовами.

Дописать код с проверкой подписи — его так же найдет реверс-инженер. Запустит приложение и посмотрит по `adb logcat | grep 'package.name'`, что падает при запуске.

Обфускация кода — немного усложняет чтение, но как видно по статье — не проблема.

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

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

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

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

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

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

Что вы думаете насчёт стандартной обфускации от Гугла? Их чудо-программа оборачивает все уязвимые места в VM.Invoke, а код переводится в псевдо vm инструкции, которые сохраняются в отдельные файлы в assets внутри apk. Виртуальная машина компилируется в нативную либу libpairipcore.so, которая обфусцирована ещё сильнее. Также у нее есть встроенная защита от: frida, пересборки apk, изменения *.so файлов (последние два пункта решаются по гайду на 4pda)

Вы имеете в виду что-то вроде?

minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

Я смотрел код open source приложения NewPipe с подобной конфигурацией (только shrinkResources было false), — сложилось впечатление, что обертки над boolean-флагами у меня найти бы получилось.

Может быть, у вас есть опыт или были проблемы?

Наверное самый надёжный способ, реализация части функционала на сервере разработчика.

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

А я же смогу найти этот код и убрать проверку лицензии?

Подключить firebase сервисы. И все :)

Нет смысла делать сложную защиту от взлома. 96 процентов пользователей принципиально не покупают программы. ЦА это те, кто не будет тратить время на поиск вареза.

Поэтому как у меня была функция isFreeVersion() так и будет. И накручивать сложность защиты не буду.

Говно не пиратят.

https://www.google.com/search?q=rawbt+site%3Ashopee.co.id

Ну АХЗ Как такому относиться ? Покупать, то что в сети лежит на пиратках бесплатно ?

столкнулся как-то с apk написанном на flutter, и всё. хэш кастомный, версию движка перебором не найти - реверс-инжиниринг закончился ¯\_(ツ)_/¯

примерно год назад это и читал..( не так все просто на деле. все, что есть у атакующего - это Snapshot_Hash, который по идее соответсвует своему Engine_commit в официальном репозитории Flutter'a. По нему можно собрать свою версию вреймворка, которая подменяется, и в динамике дает слегда заглянуть вовнутрь. Но: разработчик приложения может сам себе собирать фреймворк, и сгенерируется свой уникальный хеш, отыскать совпадающую версию которого просто перебором уже не так легко (при условии, что разработчик еще и не изменил ничего). в лучшем случае при замене прилага будет просто падать, в худшем - продолжать прекрасно работать, но атакующий будет получать ерунду и пытаться в нёй разобраться)
кстати, вот актуальная версия reFlutter: https://github.com/Impact-I/reFlutter
за год может что-то изменилось, но мне на глаза не попадалось. нет пока такого арсенала для реверс-инжиниринга dart vm

Sign up to leave a comment.

Articles