Что нужно для импровизированной лаборатории:
- Android SDK — стандартный пакет SDK для Android-разработчика;
- Mobile drivers — пак драйверов для подключения исследуемого девайса к хостовой машине, с которой сидит «эксперт-криминалист».
Всегда ясно и четко осознавай, какое именно действие и для какой цели ты совершаешь. Неправильное использование приведенных в тексте статьи программ может привести к потере информации (артефактов) или искажению полученных данных (криминалистических доказательств). Ни автор, ни редакция не несут ответственности за любой ущерб, причиненный неправильным использованием материалов данной статьи.
Первые приготовления
Итак, самым первым и обязательным шагом подготовки нашей лаборатории будет установка Android SDK и пакета драйверов. Последний часто идет универсальным паком, то есть содержит драйверы для большинства современных девайсов. И они автоматически определят подключенную модель. В редких случаях приходится доустанавливать необходимый драйвер вручную: либо тоже паком, как Android Device Driver Pack, либо ручками. Чтобы пойти вторым путем, надо найти нужный пак в каталогах типа Android Find Driver.
📌 Особо ленивые могут установить ADB вместе со всеми драйверами и аддонами «одним кликом»: при помощи ADB Installer.
Очень важная составляющая SDK — Android Virtual Device. Благодаря этому компоненту можно создавать виртуальные образы системы и после запускать их на своей машине. По сути это эмулятор системы, созданный для разработчиков, которые пишут приложения под эту платформу.
Первое подключение
После установки SDK и пакета драйверов можно смело линковать девайс к компьютеру через USB-кабель. Предварительно в опциях девайса нужно активировать режим USB mass storage, то есть режим внешнего USB-накопителя. Дальше это поможет выполнять команды с ADB-консоли. Еще надо включить режим отладки Android Debug Bridge (ADB) в секции «Для разработчиков».
Теперь запускаем командный интерпретатор CMD.EXE. А дальше, уже через него, — шелл, который предоставит доступ к девайсу:
- C:\ADB_folder>adb.exe devices
- List of devices attached:
- 4df155сс115e4f21 device
Так, мы законнектили наш девайс к компьютеру. Теперь можно получить внутренний шелл Android-устройства и проверить вывод, набрав команду whoami:
- C:\ADB_folder>adb.exe shell
- shell@android:/ $ whoami
📌 Приглашение $ в командной строке означает, что мы находимся в непривилегированном пользовательском режиме. Символ # — приглашение с правами суперпользователя.
Мини-шпаргалка по самым востребованным командам ADB
- adb start-server — запуск службы ADB на локальном компьютере;
- adb kill-server — остановить службу ADB (завершить процесс и выгрузить из памяти);
- adb devices — получить список подключенных устройств;
- adb get-state — получить статус текущих подключений;
- adb logcat — просмотр логов в режиме реального времени в консоли;
- adb logcat *:E — выводить на экран только ошибки (system error);
- adb backup -option -packets — выполнить резервное копирование;
- adb backup -option -packets — выполнить резервное копирование;
- adb backup -option -packets — выполнить резервное копирование;
- adb reboot bootloader — перейти в режим настройки загрузчика.
Теперь создаем копию внутренней памяти Android-устройства. Для этого в CLI девайса пишем:
- ️ dd if=/dev/block/mmcblk0 of=/sdcard/blk0.img bs=4096
Не забудь предварительно убедиться, что в смартфон или другое устройство вставлена SD-карточка, на которую будет писаться образ. Иначе он запишется во внутреннюю память устройства, и тогда часть артефактов потеряется. Результат: фактическая картина инцидента будет искажена.
Чтобы сделать копию уже имеющейся SD-карты, можно воспользоваться бесплатной утилитой FTK Imager. Кстати, этот же образ потом можно будет и просмотреть в программе.
Источники данных
Прежде чем приступить к поиску и извлечению артефактов, нужно определиться с основными источниками, которые мы будем анализировать, и местами их хранения во внутренней памяти Android-девайса.
📌 Все данные приложений, в том числе системных, сохраняются в директории /data/data/. Но доступ к этой директории возможен только с правами суперпользователя, так что если наше устройство изначально не «рутовано», значит, нам предстоит это сделать.
Каждое приложение (app) представляет собой одноименный пакет. Как правило вида <com.name_app.base>, где name.app — имя приложения, которое пользователь видит в Google Play или уже в своем телефоне, а *.base — это некая сигнатура, определяющая, что именно содержит пакет. К примеру:
- contacts — список контактов;
- maps — карты и координаты геолокации;
- maps — карты и координаты геолокации.
Внутри пакета по сути набор директорий, где в соответствии с внутренней логикой приложения содержатся те или иные данные. Например, обычно визуальный и аудиоконтент хранится в /media, фотокарточки и аватары — в /photos, данные профиля — в /profile, кеш — в /chache. Конечно, бывают исключения: иногда нужно залезать в каждый каталог и просматривать его.
Основные источники данных
Контакты и журнал вызовов
/files/photos/profile//databases/contacts2.db — основная БД, содержащая список контактов, открывается с помощью SQL Manager Lite (viewer).
Сообщения SMS и MMS
Имя пакета: com.android.providers.telephony
Интересующие эксперта директории и файлы:
/app_parts
/databases
/mmssms.db — БД с SMS- и MMS-сообщениями
telephony.db — журнал звонков
Почта Gmail
Имя пакета: com.google.android.gm
Интересующие эксперта директории и файлы:
/cache
/databases
mailstore.@gmail.com.
dbdatabases/suggestions.db
/shared_prefs/MailAppProvider.xml
Gmail.xml
UnifiedEmail.xml
Google Chrome
Имя пакета: com.android.chrome
Интересующие эксперта директории и файлы:
/app_chrome/Default/
Sync Data/SyncData.sqlite3
Bookmarks
Cookies
Google Profile Picture.png
History
Login Data
Preferences
Top Sites
Web Data
/app_ChromeDocumentActivity/
/cache/http/
databases/gmm_myplaces.db — сохраненные места на картах Google
Mapsgmm_storage.db — места, отмеченные геолокацией
/files/video-cache/
/cache/images/
/databases/
bookmarks_db2
contacts_db2
nearbytiles_db
newsfeed_db
notifications_db
prefs_db
threads_db2
/files/preferences/
activated_sim_serial
display_name
reg_viber_phone_num
/sdcard/viber/media/
/User Photos/
/Viber Images/
/Viber Videos/
/databases/
viber_data
viber_messages
/files/
Avatars/
me
me.jpeg
/shared_prefs/
RegisterPhone.xml
VerifySMS.xml
/databases/
msgstore.dbwa.db
/sdcard/WhatsApp
/Media/
Databases/
Помимо стандартных приложений на устройство может быть установлено фейковое или вредоносное ПО. Поэтому еще одним источником данных может послужить изучение *.apk-файла, вытянутого из внутренней памяти. Но это уже больше относится к реверсингу малвари и выходит за рамки статьи. И все же для вирусных аналитиков и форензик-специалистов это настоящий кладезь ценной информации.
Сброс пароля и графического ключа
Один из основных вопросов в начале анализа — как получить доступ к устройству. И на первых порах помешать этому может установленный графический ключ или пароль. Но для нас это будет совсем не большой проблемой. Поступить можно двумя способами: либо узнать сам PIN/Password, либо просто обнулить их.
📌 Хеш графического ключа хранится в файле /data/system/gesture.key, а пароля — в /data/system/password.key. В принципе, пароль можно попробовать и побрутить, благо на это есть готовые радужные таблицы. Но тут Android оказался не так плох, и в password.key хеш пароля хранится с солью. А сама соль лежит по пути /data/data/com.android.providers.settings/databases/settings.db для Android версии 4.4 и ниже и собственно в /data/system/locksettings.db для версий старше, чем 4.4. Хотя есть утилиты, способные методом перебора и разделения соли выдать нам готовые PIN/Key. Мы так извращаться не станем и пойдем более быстрым и жестким путем.
Итак, приступим к разблокировке девайса. Как написано выше, если нет файла, значит, нет условия проверки. А значит, чтобы скинуть Lock Screen, нужно просто удалить несколько файлов. В консоли ADB пишем:
▫️ adb shell
▫️ su
▫️ rm /data/system/locksettings.db
▫️ rm /data/system/locksettings.db-wal
▫️ rm /data/system/locksettings.db-shm
▫️ reboot
Если после перезагрузки девайса трюк не удался, сделай еще так:
▫️ adb shell
▫️ cd /data/data/com.android.providers.settings/databases
▫️ sqlite3 settings.db
▫️ update system set value=0 where name=’lock_pattern_autolock’;update system set value=0 where name=’lockscreen.lockedoutpermanently’;.
▫️ quit
Вот, собственно, и все! Дело сделано, дорога расчищена.
Для любопытных есть еще одна утилита — UFED User Lock Code Recovery Tool. Она полностью автоматизирует байпасинг. Все, что нужно, — это подключить девайс по USB-кабелю и выбрать соответствующую опцию в окне программы. И, на всякий случай, есть еще аналогичный онлайн-сервис — Andriller.
Основной инструментарий
Теперь об инструментах, которые мы будем юзать для форензики нашего Android-девайса.
ViaExtract — это очень крутая прога, которая позволяет извлекать данные как на логическом, так и на физическом уровне. Она вытаскивает бэкапы, «рутует» девайс в один клик, а также имеет внутренний парсер и просмотрщик директорий, содержимого в них (картинки, аудио, видео), умеет делать репорты в формате XML, PFD или JSON!
Autopsy — известная прога для анализа файловых систем и восстановления удаленных/allocated-файлов. Есть возможность мгновенного предпросмотра, экспорта и каталогизации.
ViaLab Community Edition — софтина, чем-то родственная ViaExtract. Позволяет извлекать крайне ценные данные: содержание телефонной книги, журнала SMS, паролей от Gmail и других сервисов Google, пассы от сохраненных профилей Wi-Fi и т.д.
Oxygen Mobile forensic — очень крутой комбайн утилит для извлечения различных данных с девайса: календаря, журналов звонков, SMS-переписки, телефонной книги, удаленных контактов, системных логов и т.п. Must have в арсенале эксперта-криминалиста, занимающегося расследованиями на мобильных платформах.
SQL Manager Lite — известная утилита для просмотра баз данных (контакты, списки групп и т.д.), которые мы можем вытянуть из внутренней памяти исследуемого девайса.
Кейс 1. Украденный телефон
Кейс — банальная история утери (кражи) телефона некоего топ-менеджера одной из солидных фирм. Внутри корпоративная почта, аккаунты, привязанные к различным CRM-, ERP-системам, удаленный доступ к рабочему ноутбуку и куча сохраненных файлов, содержащих конфиденциальную информацию (отчеты, планы, презентации, вложения писем). Через пару дней телефон был случайно обнаружен (подброшен?) в офисе. Однако непонятно, кто и с какой целью его похитил. Соответственно, встал вопрос: что злоумышленники делали с телефоном все то время, которое он отсутствовал у владельца?
Первым делом скидываем цифровой пароль и получаем доступ к смартфону. Далее тратим несколько минут на «рутинг» девайса и получаем права суперпользователя.
Дальше восстанавливаем SMS, список контактов и журнал вызовов. Пишем в консоли ADB:
<span class="pln">adb pull </span><span class="pun">–</span><span class="pln">p </span><span class="pun">/</span><span class="pln">data</span><span class="pun">/</span><span class="pln">data</span><span class="pun">/</span><span class="pln">com</span><span class="pun">.</span><span class="pln">android</span><span class="pun">.</span><span class="pln">providers</span><span class="pun">.</span><span class="pln">telephony</span><span class="pun">/</span><span class="pln">databases</span><span class="pun">/</span><span class="pln">mmssms</span><span class="pun">.</span><span class="pln">db C</span><span class="pun">:</span><span class="str">/Users/</span><span class="typ">Forensic</span><span class="pun">/</span><span class="typ">Case_0001</span>
После копирования открываем файл mmssms.db вьювером SQL Manager Lite. Либо, если предварительно прогнать через Autopsy, сразу будет доступен предпросмотр.
Дальше, после прогона Autopsy, мы можем получить список контактов и журнал вызовов, а затем выстроить по ним таймлайн, чтобы определить, звонил ли по каким-то номерам телефонов наш злоумышленник.
Далее просматриваем список Wi-Fi-сетей, к которым подключался девайс. Для этого нужно пройти по пути /data/misc/wifi/wpa_supplicant.conf и извлечь файл wpa_supplicant.conf. Этот файл содержит в себе открытым текстом (без какого-либо шифрования!) данные о подключениях к Wi-Fi: имя точки доступа, пароль и некоторые служебные данные, необходимые для подключения.
Как видим, кроме корпоративной сети с дефолтными настройками, наш аппарат больше никуда не подключался. И как мини-вывод: либо никаких подключений злоумышленнику и не требовалось, либо данные об этом подключении после завершения коннекта были удалены.
Ищем удаленные файлы с помощью Autopsy.
По результатам поиска нам так и не удалось обнаружить никаких серьезных артефактов, свидетельствующих о неправомерных действиях с телефоном. Очевидно, что злоумышленник мог просто получить визуальный доступ, просмотрев, к примеру, почтовые сообщения, сохраненные вложения и, возможно, перекопировав пароли доступа к другим корпоративным системам (если их просмотр без смены был возможен). Как вариант, мог быть снят полный дамп памяти телефона. Но к сожалению, подобные манипуляции никак не отражаются в системе, и констатировать их невозможно.
Кейс 2. Ревнивая жена
Очень банальная ситуация в духе детективных агентств из классических романов. К нам в лабораторию обратилась дама с просьбой найти следы измены ее благоверного. Несмотря на то, что муж заявляет обратное, и никаких компрометирующих данных на поверхностный взгляд в смартфоне нет, мы попробуем установить истину. Итак, что мы будем искать в первую очередь? Это переписка в мессенджере WhatsApp, сохраненные (и, возможно, уже удаленные) фотографии во внутренней памяти и на SD-карте, а также звонки и SMS-сообщения. Ведь это же прямые доказательства, не так ли? Снова извлекаем данные о SMS/MMS, журнал звонков и список контактов. На сей раз будем действовать при помощи Oxygen Mobile forensic. После нескольких минут ожидания получаем листинг отправленных SMS и совершенных звонков.
Пробуем нащупать удаленные фотовидеофайлы, которые могли быть отправлены или получены от интересующего нас адресата. В дело идет уже известный Autopsy.
Ну что, дело за WhatsApp. Уж там-то должно быть много интересного! Дергаем два файла: /data/data/com.whatsapp/databases/msgstore.db и /data/data/com.whatsapp/databases/wa.db. Файл wa.db хранит в себе список контактов, их номеров, активность и даты чатов. Кстати, WhatsApp периодически делает резервную копию, которую хранит локально. Взять ее можно по пути /sdcard/WhatsApp/Databases/msgstore.db.crypt. А ключ шифрования лежит по пути userdata/data/com.whatsapp/files/key.
Берем программу WhatsApp DB/Key Extractor и скармливаем ей наш ключ, указывая путь к msgstore.db, дальше выбираем опцию Decrypt и отправляемся пить кофе. В итоге у нас расшифрованная база данных всех чатов с содержанием бесед и пересылаемых данных (их метаданных).
Резюме
Перед тобой полноценное руководство по извлечению данных из смартфона. Пускай мы и покажемся занудами, но используй его в благих целях. Все зло возвращается в десятикратных размерах. Зачем вредить самому себе?
