Введение

Реверс-инжиниринг - это не только про "взлом". Это про понимание: как работают компоненты системы, какие решения заложены в архитектуру, и почему некоторые механизмы Android устроены именно так.

В экосистеме Android, где миллионы строк кода сочетают Java, C/C++, Binder IPC, HAL и ядро Linux, без инструментов реверса невозможно глубоко разобраться в том, что реально происходит "под капотом".

Почему это важно

1. Глубокое понимание платформы. Когда исходники недоступны (например, GMSCore или OEM-патчи), реверс позволяет понять, как система принимает решения.

2. Диагностика сложных багов. Часто поведение скрыто в native-слое или IPC-взаимодействиях.

3. Анализ архитектуры и безопасности. Реверс помогает исследовать границы доверия и понять, какие проверки выполняются на клиенте, а какие - на сервере.

4. Инструмент обучения. Это лучший способ изучить внутренности Android, не ограничиваясь документацией AOSP.

Этическая и правовая сторона

Реверс-инжиниринг может быть законным при соблюдении ряда условий:

• Исследование ведётся на собственных устройствах или открытых образах (например, AOSP);

• Цель - анализ, аудит или разработка совместимых решений, а не обход защиты;

• Результаты не содержат приватных данных или инструкций по взлому.

Главное - не нарушать NDA, не публиковать обходы, а фокусироваться на архитектуре и инженерных принципах.

Инструменты инженера-исследователя

🔹 Статический анализ

• jadx, apktool, baksmali - декомпиляция и анализ структуры.

• Ghidra, IDA - дизассемблирование нативных библиотек.

• protobuf-dump, strings, grep - извлечение строк, ключей и структур.

🔹 Динамический анализ

• frida - динамический hooking, трассировка методов, логирование вызовов.

• strace, ltrace, perf - системные вызовы и поведение процессов.

• logcat, dumpsys, binder-trace - визуализация IPC и жизненного цикла сервисов.

🔹 Ядро и eBPF

• libbpf, bpftool, bcc-tools - инструменты для запуска eBPF-программ, которые позволяют наблюдать за поведением ядра и приложений.

• eBPF можно встраивать в Android-бинарь без внешних .o файлов - для внутреннего профилирования.

eBPF: новое измерение наблюдаемости

Что такое eBPF

eBPF (Extended Berkeley Packet Filter) - технология, позволяющая запускать безопасные программы прямо в ядре Linux без необходимости модификации ядра.
В контексте Android это революционный способ профилировать и анализировать поведение приложений и системных сервисов с минимальным overhead'ом.

Почему eBPF незаменим

1. Безопасность и изоляция. eBPF-программы проходят верификацию перед загрузкой - нельзя "сломать" ядро.

2. Низкий overhead. Работает быстрее, чем ptrace, strace, и не требует root'а на уровне ядра.

3. Глубокое наблюдение. Можно отслеживать syscalls, сетевые операции, Binder IPC, allocation-паттерны, работу планировщика и даже GC.

4. Нет прямых аналогов.

   • Традиционные профилировщики (perf, gdb) требуют вмешательства в процесс и дают неполную картину.

   • Tracing-фреймворки (например, atrace) ограничены уровнями userspace.

   • eBPF же позволяет прозрачно наблюдать за всей системой, оставаясь невидимым для целевых процессов.

Пример: профилирование Binder вызовов через eBPF

Можно написать eBPF-программу, которая отслеживает syscalls ioctl с кодом BINDER_WRITE_READ и собирает статистику по binder-коммуникациям между сервисами Android.

SEC("kprobe/binder_thread_read")
int bpf_binder_read(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    bpf_trace_printk("Binder read in PID %d\n", pid);
    return 0;
}

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

Методология исследования

1. Постановка цели: не "сломать", а понять, как работает компонент.

2. Сбор данных: APK, smali, бинарники, лог-файлы.

3. Гипотеза: формулируем, как компонент должен вести себя.

4. Проверка: динамический анализ, eBPF, трассировка вызовов.

5. Вывод: документируем связи, зависимости, модель данных.

Почему аналогов нет

eBPF - уникален тем, что сочетает:

• наблюдаемость уровня ядра,

• безопасность выполнения,

• минимальное влияние на производительность,

• универсальность (сеть, storage, IPC, scheduler, security hooks).

Ни один другой фреймворк не даёт такого покрытия без модификации ядра. Это делает eBPF единственным реалистичным способом прозрачного профилирования Android-системы в production.

Заключение

Реверс-инжиниринг - это не хакинг, а форма инженерного мышления. Он учит видеть логику систем, архитектуру, доверие и поведение.
А инструменты вроде eBPF делают это наблюдение точным и безопасным, превращая Android в исследуемую, прозрачную платформу.

Полезные ссылки

• Профайлинг JVM движка

• Пример профилирования 2

Купил в amazon вышло все в 20 евро

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

Задачи следующие:

1. Определить что сотрудник пришел в офис

2. Определить что он ушел

В голову пришла идея сканирования сети WIFI так как в большинстве случаев сотрудник в офисе всегда подключается к сети и будет подключен до ухода

Определить что сотрудник пришел в офис

ESP32 умеет подключатся к WIFI сети и я сделал ARP сканирование сети так как она работает на FreeRTOS и большинство привычных функций типа выдергивания ARP таблицы уже было вместе с проектами

Бизнес логика

1. Изначально у сотрудника состояние “в офисе“ стоит 0

2. Сканирование делается раз в минуту

3. Как только сотрудник подключается к системе состояние “в офисе“ становится 1

4. Если сотрудник уходит я даю ему шанс подключиться к сети в 15 минут

5. Если прошло более 15 минут после того как он был в сети то я его считаю ушедшим в то время когда я его видел

6. Но сотрудник может продолжить свое рабочее время если успеет “покурить“ в течении 15 минут

В итоге вышло примерно так

Приход в офис

Уход с офиса

Запартнерился с другом кто делал параллельный проект и решили внедрить эту систему ему в проект. Но к сожалению эта реализация не сработала так как у него работники работали в большом объекте где нету 100% покрытия вайфай сети и система показывала только косвенные данные

Исходники проекта

https://github.com/thisisdingo/mac-scanner

Я думал на счет перехода в следующие направления

• Кибербезопасность

  • Он хорош тем что никогда она не умрет. Пока существуют деньги в каком либо формате в IT - всегда будет потребность держать его в сохранности. Для начинающих это будет тяжело так как надо иметь очень большую надсмотренность в любом виде разработки и уметь нутром чуять слабые места системы. С моим опытом особо не нужно я думаю париться так как у меня уже был самый крутой опыт. Я держал сервис с 6 млн уникальных пользователей в месяц у нас были кастодиальные кошельки с реальными балансами. И в этом сервисе конечно очень много всяких хакеров точно целились. Расскажу потом про ежедневные угрозы взлома и как 2 раза это удалось сделать и в чем был косяк

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

• AI

  • Начал изучать как работает модели но изза я очень многое уже забыл с математики и вспоминать это все было очень тяжело и времязатратно. Но я думаю что я опоздал уже и изучать нужно очень многое с нуля чего бы не хотелось. Да и в принципе математика мне не нравится :)

• DevOps

  • После того как более менее уже погрузился в Kuburnetes, и держал под стабильные 20k RPS я начал думать что это будет перспективно так как высокие нагрузки это всегда высокая ответственность и если достаточно наработать опыт с большим трафиком то будет уже не страшно делать очень серъезные проекты

• Hardware

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

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

  • Порог входа в эту сферу довольно простой но надо знать физику и чуток математики и нотку программирования.

В итоге я решил уже начать плавно переходить в hardware разработку