Кажется, что декомпиляция Android Apk

Я просто возился. Я загрузил dex2jar http://code.google.com/p/dex2jar/ и JD-GUI Java Decompiler http://java.decompiler.free.fr/?q=jdgui

Я получил свой собственный файл apk (подписанный, запечатанный и в Google Play), использовал dex2jar, чтобы превратить его в репозиторий jar.

(пользователи Windows используют .bat, все остальные .sh):

d2j-dex2jar.bat -f MyAwesomeApp.apk

Я перетащил вывод в JD-GUI и все файлы классов, исходный код снова появился. Меня немного смутило. Является ли мой код java/Android этим? Как ProGuard защищает мой apk, если он может быть декомпилирован и регенерирован так легко? Это не кажется запутанным вообще...

Спасибо заранее.

Ответ 1

Обфускаторы обычно просто меняют классы, методы и имена полей на имена, которые не имеют значения. Итак, если у вас есть "ScoreCalculator.computeScore(Player p, Match m)", вы получите "A.zk(F f, R r)". Это похоже на то, что компилятор Uglify или Closure делает для javascript, за исключением того, что в javascript это уменьшает длину источника.

Можно понять, что метод все равно, это сложнее.

Aslo, Java использует позднюю привязку (как DLL или SO файлы). Таким образом, вызовы, выходящие за пределы вашего кода (например, java.util, java.lang и т.д. Пакеты), не могут быть запутаны. Кроме того, если вашему коду необходимо принимать вызовы извне (типичный пример, зарегистрировать прослушиватель на кнопке), этот код не может быть запутан. То же самое происходит для DLL, где вы можете четко видеть имя метода, который нужно вызывать вне внешней библиотеки DLL и вызывает другие DLL.

Однако сопоставление между определенным исходным кодом и скомпилированным кодом необязательно один к одному. Старые компиляторы C, используемые для создания того же кода для заданной директивы источника, поэтому декомпиляторы были очень эффективными. Затем компиляторы C добавили много оптимизаций к результату op-кода, и эти оптимизации сделали декомпилятор в основном неэффективным [1]

Java никогда не реализовывала (много) оптимизаций во время компиляции, потому что для запуска на разных платформах (включая различные устройства Android), Java решила применить серьезные оптимизации позднее во время выполнения на основе архитектурных и аппаратных свойств (это то, что "HotSpot" в основном о [2]).

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

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

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

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

Ответ 2

Я также могу добавить, что существует современная альтернатива этому маршруту APKTool- > dex2jar- > JD-GUI!

Просто попробуйте декомпилятор APK и DEX с открытым исходным кодом, названный Jadx: https://sourceforge.net/projects/jadx/files/ Он также имеет онлайн-версию здесь: http://www.javadecompilers.com/apk