В теме обсуждаются вопросы взлома под андроид и соответствующие тулзы.
ТУТОРИАЛЫ:
--> Тутор от chelpa<--
--> От аффтора antilvl<--
--> дебаг .so<--

ТУЛЗЫ:
JEB
ApkAnalyser
--> Android Reverse Engineering (A.R.E.) <--
--> Apktool <--
--> Smali/baksmali <--
--> APKRecovery <--
--> Dex2Jar <--
--> APKInspector <--
--> Lucky Patcher 1.2.0 <--
--> Crack Assist 0.3 <--
--> ART <--
--> JD-GUI <--
--> DexInspector <--
--> Android unpacker <--
GikDbg


В аттаче fernflower, очень годный жава декомпилер.
0ece_06.12.2012_EXELAB.rU.tgz - fernflower.jar

-----
SaNX

| Сообщение посчитали полезным: 4kusNick, WmLiM, gsx3000, Maximus, CoolMax_86, Rustem, Oott, streit, t0ShA, BAHEK, sooqa, Ara, VodoleY, vden, Thegodofviruses, SDFnik, Soso, ff0h, RAMZEZzz, quency, XroM_N70, Alinator3500, Coderess, samtehnik, Isaev, dgyst, ALSSL, dosprog, omeh2003, d0wn, ELF_7719116, Bad_guy

Я бы сначала посмотрел в листинге, зашифрована jni_onload() или нет, а потом стал дальше думать.

| Сообщение посчитали полезным:

Apokrif, посмотри, вроде по структуре похожи они. Мне кажется тут без шифрования.


| Сообщение посчитали полезным:

mixer632 пишет:
Мне кажется тут без шифрования.
Блин, ну нельзя же все понимать так буквально. Видно, что она вызывает только sub_AB30 и надо смотреть глубже. И смотреть проще на плюсах, а не ARM ASM...

| Сообщение посчитали полезным:

Apokrif, на sub_AB30 я тоже обратил внимание, в ней очень много кода, понятно что главный функционал в ней.
Обработал в hex-rays в плюсовый код, можете посмотреть куда в ней копать дальше. Я поизучал функцию registernatives(), по сути нужно найти ее вызов, а из ее параметров взять указатель на структуру динамических фунок, но вот проблема, ида не умеет распознавать эти функции в коде, как бы ее найти.

Как я понимаю надо искать что-то вида:


adf4_21.06.2016_EXELAB.rU.tgz - sub_ab30.txt

| Сообщение посчитали полезным:

А получится ли после registernatives() если в смали коде вызвать функцию

Для динамически экспортируемого метода и для jnionload(), потом определить разность между их адресами, ведь в памяти они будут по другим адресам, но расстояние между ними тоже самое, правильно я понимаю ?
Чтобы потом вычислив разность в памяти их адресов найти в самом *.so файле откуда этот метод начинается.

| Сообщение посчитали полезным:

mixer632
Ты бы не издевался над людьми и выложил бы свой апк.

-----
старый пень

| Сообщение посчитали полезным:

r_e, http://rgho.st/8gJ7djyRP
Посмотрите, пожалуйста. Интересует определение адресов динамически экспортируемых функций в libdexprotector.so

| Сообщение посчитали полезным:

r_e, я разобрался с отладкой нативной библиотеки через android_server от иды, можешь подсказать как мне поймать прогу на вызове в jni_onload(), эта функция получает управление один раз во время загрузки либы и конечно я подключаюсь после уже с отладчиком.
Какие тут варианты можно попробовать:
1. messagebox перед system.load() в смали коде прописать, чтобы идой подключиться до загрузки библиотеки в память
2. Бесконечный цикл в jni_onload() вписать в начале.
Мне интересно сработает ли 1 метод, то есть ида сможет бряк поставить на эту функцию или нет, ведь в этот момент либа еще не загружена в память.
Ну и есть ли еще какие способы ее там поймать, которые лучше предложенных ?

| Сообщение посчитали полезным:

mixer632 пишет:
Какие тут варианты можно попробовать
Наверное можно пропатчить jni_onload(), вписать в начале soft breakpoint.
Я никогда не пробовал это делать, так что гуглите...

| Сообщение посчитали полезным:

наткнулся на прикольную статью на хабре.. много полезных мелочей и ньюансов.. не смотря на то что статье 2 года, думаю начинающим будет полезно. там про далвик и про нейтив код.. вобщем вот
https://habrahabr.ru/post/232531/
и еще тутор на инглише
http://shubhamaher.com/native-android-reverse-engineering/
http://forum.xda-developers.com/showthread.php?t=2050393

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным: mixer632

Apokrif, нашел тут статью http://www.hexblog.com/?p=809 с помощью двух запущенных ида получилось смали и натив вместе отлаживать. Используя эту статью получилось в Jni_onload брякнуться)

| Сообщение посчитали полезным:

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

-----
SaNX

| Сообщение посчитали полезным:

SaNX--> дебаг .so<--
кстати.. в шапке твой пост) не хош подправить содержимое? а запускать андроид сервер разве не надо? раз ты мануал писал)

Добавлено спустя 5 минут
и может в шапочку еще на gikdbg.art ссылочку добавить.. для колекци.. типа.. ОлькаМод для дебаг андроида.. говорять глючная.. но комуто помогает

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

VodoleY пишет:
говорять глючная
Пробовал, логает жутко. С идой нормально дебажится.
Гдбсервер тоже пробовал, на любителя какой-то.
На реал устройстве на команду continue падал с ошибкой доступа, на виртуал устройстве continue работала, а команда info function упорно вместо адресов в памяти выдавала их смещения в файле на диске, то есть бряк не поставить было.

Добавлено спустя 1 минуту
VodoleY, не знаешь плагинов или утилит по распознаванию JNI фунок, чтобы ида их опознавала охота.
Хочу облегчить поиск в арм коде либы этой функи:


| Сообщение посчитали полезным:

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

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

SaNX пишет:
Дабы брякнуться на любой функе, достаточно в этой функе джамп на себя прописать
Соратники,
А в IDA + andoid_server работают эти фишки?
- Suspend on library load/unload
If selected, the debugger will suspend if a new library is
loaded or if a previously loaded library is unloaded.
И еще
Event condition
When one or more debug events (see above) are checked then this
option is used to specify a condition. In the following example,
the debugger will suspend the prcoess whenever a module with the
name test.dll is loaded:
GetEventId() == LIBRARY_LOAD && strstr(GetEventModuleName(), "test.dll") != -1
Если да, то на Jni_onload() брякнуться д.б. без проблем?

| Сообщение посчитали полезным:

VodoleY
По ведропротекторам это SaNXа кастовать надо в топик. Я плотно с ними не работал.
RegisterNatives экспортируется явно из ядра? Или он метод класса?
Если экспортируется явно, то метод поиска стандартный: база + смещение.
Если метод класса, то пишешь свою .so + apk, которая явно вызывает его и определяешь для твоего ядра смешение метода. Можешь в apk показывает его на экране. Ну а дальше дело техники.

-----
старый пень

| Сообщение посчитали полезным:

r_e, нашел все смещения jni через этот проект с гитхаба https://gist.github.com/libmaru/5814814
Та функа похоже не явно вызывается в либе, там нашел всякие jni вызовы типа GetStaticMethodID, CallStaticObjectMethod. Разрабы в смали коде помешаны на рефлексии, видать либу также писали.
По экспорту там только jni_onload(), она все остальное при старте формирует.

| Сообщение посчитали полезным:

Apokrif пишет:
Соратники,
А в IDA + andoid_server работают эти фишки?
- Suspend on library load/unload
Однако проверил - всё работает!
Вот всё по шагам:

Взял простейший код отсюда
http://www.hexblog.com/?p=809
Ставим и проверяем:
adb shell
android_server &
am start -D -e debug true -n ida.debug.hellojni/.MainActivity
Появилось окно "Waiting for debugger"

ida -> attach to ida.debug.hellojni
Debugger options
X Suspend on library load/unload
Event condition
GetEventId() == LIBRARY_LOAD && strstr(GetEventModuleName(), "libhello-jni.so") != -1
* Если не ставить, ida будет брякаться на загрузке/выгрузке всех либ!

ida -> run/continue

Теперь надо "подтолкнуть" наш "Waiting for debugger" процесс:
# Находим наш процесс
adb jdwp
755

APK д.б с application android:debuggable="true"
Без него будет пустой лист.
Возможно, что если сам девайс разрешает debug-жить любые APK, то в AndroidManifest.xml это не нужно.
Как разрешить для девайса уже обсуждали.

# Пробрасаваем порт
adb forward tcp:8000 jdwp:755

# Прицепляемся
jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8000

И брякнулись в ida на
loaded /data/app/ida.debug.hellojni-1/lib/arm/libhello-jni.so
Т.е. можно ставить бряку jni_onload() - она еще не выполнялась!


* Когда apk грузит либы, ida предлагает указать, где она лежит (уже разобранная?) на писюке.
Вот это еще не проверил, пора спать уже...

| Сообщение посчитали полезным: VodoleY

Apokrif пишет:
Когда apk грузит либы, ida предлагает указать, где она лежит (уже разобранная?) на писюке.
А если ей подсунуть псевдокод hex-rays самой иды ? Во время отладки ида не особо выдает псевдокод чтобы отлаживать.
Apokrif пишет:
Как разрешить для девайса уже обсуждали.
Перепрошивать в рекавери ?

| Сообщение посчитали полезным:

умеетют хексрейсы бегать под дебагером выдавая псевдокод

| Сообщение посчитали полезным:

reversecode пишет:
умеетют хексрейсы бегать под дебагером выдавая псевдокод
Проблема в том, что локальный файл *.so весь чистый от красных кусков кода, а когда я аттачусь к этой либе, то в ида получаю много красных кусков кода, из-за чего хексрейс не может нормально делать псевдокод из него.
Почему так происходит, как это пофиксить ? Специально либу, которая на компе лежит прочистил, чтобы вся полоска синяя была, а во время аттача он свое грузит с красными кусками.

| Сообщение посчитали полезным:

mixer632 пишет:
Как разрешить для девайса уже обсуждали.
Перепрошивать в рекавери?
Можно и так.
Или попробовать выставить ro.debuggable=1 в build.prop через setpropex
Ссылка на setpropex есть тут, на новых андроидах не проверял.

Apokrif пишет:
Когда apk грузит либы, ida предлагает указать, где она лежит (уже разобранная?) на писюке.
Вот это еще не проверил, пора спать уже...
Если открыть ida с уже разобранной либой (просто переименовал пару функций!)
Потом присоединиться к андроиду (android_server/attach process)
Ida спросит, уже открытая либа и либа в attached process: same или нет?
Говорю same, но разобранная либа не подхватывается...
Даже rebase сделать не предлагает...
Наверное, какую-то мелочь упускаю?

| Сообщение посчитали полезным:

Apokrif пишет:
Говорю same
Да вот у меня аналогично, тоже same выбираю, но не подхватывает разобранную.

| Сообщение посчитали полезным:

mixer632 потому что рейс декомпилит только полноценные функции а не огрызки кода которые не имеют ни начала ни конца
а у функции есть начало и конец и стек

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

mixer632 пишет:
Как этого избежать почему-то после аттача получаем много кусков не проанализированного кода.
reversecode пишет:
возможно потому что в статике либа имеет ельф формат и ида ее авто анализирует,
а при аттача это просто какая то память, ида ничего не знает о начале и конце кода
Собственно вопрос (который мы задали в разной форме несколько раз):
Есть проект с разобранной либой, над которым мы потрудились.
Как при attach process подсказать ida, что либа в нашем process и разобранная либа это одно и тоже?
Ida ведь честно спрашиват "уже открытая либа и либа в attached process: same или нет"?
Но даже если ответить same, ida всё равно открывает либу "по новой", и никаких результатов предыдущего анализа там нет. (Либа 100 пудово одна и таже!)
В инте проскакивают посты, что это возможно.
Т.е. у нас похоже не соблюдаются какие-то условия (например, "ну очень кривые руки" )
Может есть (проверенный!) туториал, где по шагам расписано, что и как нужно делать?

Добавлено спустя 2 часа 50 минут
Apokrif пишет:
Может есть (проверенный!) туториал, где по шагам расписано, что и как нужно делать?
Заранее извиняюсь за длинный пост!

Если пройти по тутору
* Неважно, по полному Dalvik debugger + Remote ARM Linux/Android debugger или только Remote ARM Linux/Android debugger, результат тот же!

Запускаем IDA, открываем либу не в папке, а именно из apk.
Находим нашу функцию Java_ida_debug_hellojni2_MainActivity_stringFromJNI
Меняем имя на XXX_Java_ida_debug_hellojni2_MainActivity_stringFromJNI
(Это типа наш анализ и есть!)
Ставим на ней breakpoint

Уточню, чуть поменял прогу (java part!), сделал 2 кнопки:
загрузить либу
вызвать нашу функцию
На код либы это, ессно, никак не влияет.

IDA | Attach process | Remote ARM Linux/Android debugger
Видим:
Rebasing program to 0xB6F82BA0...
Debugger: attached to process /system/bin/app_process32_original (pid=15777)
Проходит быстро, 1-2 сек
Откуда взялся этот "Rebasing program"?
Ведь наша либа еще не загружена...

В нашей проге на Andriod-е нажимаем кнопку "загрузить либу"
Выскакивает окно про новую либу у процесса - говорим "same"
Видим:
Rebasing program to 0x9BCC1BA0...
9BCC1000: loaded /data/app/ida.debug.hellojni2-2/lib/arm/libhello-jni.so
Debugger: thread 15810 has exited (code 0)
IDA что-то довольно долго делает, 3-4 минуты.
Похоже IDA пытается как то увязать, загрузку новой либы и наш предварительный анализ?

Либа крошечная, на диске 13kB, в памяти 6kB
При первом открытии из apk открывается и анализируется меньше чем за секунду!

В окне Module появляется наша либа
Если на неё кликнуть ida скажет:
Module /data/app/ida.debug.hellojni2-2/lib/arm/libhello-jni.so has no names
Т.е. этот новый module и та либа, что мы открывали из apk никак не связаны (пока?)

В нашей проге на Andriod-е нажимаем кнопку "вызвать нашу функцию"
Получаем Break на нашей функции!

Видим в окне IDA View-PC, наша функция показана как мы её переименовали
XXX_Java_ida_debug_hellojni2_MainActivity_stringFromJNI
Еще раз нажимаем на /data/app/ida.debug.hellojni2-2/lib/arm/libhello-jni.so в окне Module

Появляется Module: libhello-jni.so
И в нем наша функция показана как Java_ida_debug_hellojni2_MainActivity_stringFromJNI
(т.е. так, как называется в либе, а не как мы её переименовали при анализе!)
В окне функций всего 44, а при анализе было 69!
Т.е. наш предварительный анализ почему-то не показывается…
От того, что в окне IDA View-PC наша функция показана как нам нужно, как то не легче.

В общем всё, традиционный вопрос: кто виноват и что делать?
Это так и задумывалось или я что-то упустил?

Единственный понятный момент, при отладке ASLR лучше отключать, чтобы не тратить время на этот длительный Rebase...

| Сообщение посчитали полезным: mixer632

r_e пишет:
По ведропротекторам это SaNXа кастовать надо в топик.
а я как бы про протекторы не спрашивал)

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

Apokrif
Это может быть баг иды, как раньше было с пропадающими переменными.
Начальный ребейз, вероятно, из-за отличия базы самой программы (нативной части ВМ, например) от того куда ее загрузили. Поскольку он к модулю не относится - ребейз быстрый.
Второй ребейз более долгий потому что ремапится уже специфичный модуль.
Странно что при этом меняется состав экспорта. Это вы по Ctrl+E смотрите или в окне экспорта модуля?

VodoleY
Я на опережение работаю ))) Андроид в 6.8 был таки достаточно сырой, так что это гадание на кофейной гуще.

-----
старый пень

| Сообщение посчитали полезным: