Как восстановить и вытащить данные из Андроид

Личная и деловая переписка, деньги, фотографии, заметки, планы на будущее и удаленный доступ к рабочим инструментам — все это сегодня заключается в маленькой стосорокамиллиметровой пластиковой коробочке, которую каждый цивилизованный человек носит с собой постоянно. Неудивительно, что все чаще она становится целью для хакеров. Сегодня мы рассмотрим Android c точки зрения специалиста по форензике, пройдемся по теории, рассмотрим инструментарий и решим пару настоящих криминалистических кейсов.

Немного об особенностях платформы Android

Android представляет собой модифицированную версию ядра Linux, адаптированную под мобильные гаджеты и носимые девайсы. За работу приложений (application) отвечает встроенная виртуальная машина Dalvik, преобразующая байт-код приложений в инструкции для исполнения начинкой устройства. Однако с версии Android 4.4 Dalvik был заменен на более шуструю Android Runtime, хотя сути работы это не поменяло. Рабочее окружение, так же как и в традиционном Linux, дополняют нативные и сторонние библиотеки, обеспечивающие различные профильные функции девайса.

Наследие Linux в Android проявляется в управлении процессами, в организации файловой системы, подсистемы доступа и разрешений (user-based permission model, SELinux и root mode), ну и, конечно же, в поддержке терминала и некоторых команд из стандартного core utilities. Это во многом роднит Android и Linux, несмотря на то что различий между системами тоже много. Но эти знания помогут тебе в решении некоторых задач в наших кейсах.

Готовим лабораторию для исследований

Для нашей импровизированной лаборатории понадобится следующий минимальный набор инструментов:
* 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 и через него шелл, который предоставит нам доступ к девайсу:

Так, мы законнектили наш девайс к компьютеру. Теперь можно получить внутренний шелл Android-устройства и проверить вывод, к примеру набрав команду whoami:

Приглашение $ в командной строке говорит о том, что мы находимся в непривилегированном пользовательском режиме. Символ # — приглашение с правами суперпользователя.

Более подробно о работе ADB и том, что с ее помощью можно сделать, читай в одной из наших статей.

Мини-шпаргалка по самым востребованным командам 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 reboot — перезагрузить устройство;
• adb reboot recovery — загрузиться в режим recovery;
• adb reboot bootloader — перейти в режим настройки загрузчика.

Создаем копию внутренней памяти Android-устройства. Для этого в CLI девайса пишем:

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

Чтобы сделать копию уже имеющейся SD-карты, можно воспользоваться знакомой нам бесплатной утилитой FTK Imager. Кстати, этот же образ потом можно будет и просмотреть в программе.

Источники данных

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

Все данные приложений, в том числе системных, сохраняются в директории /data/data/. Однако доступ к этой директории возможен только с правами суперпользователя, так что если наше устройство изначально не рутовано, то нам предстоит это сделать.

Каждое приложение (app) представляет собой одноименный пакет, как правило вида <com.name_app.base>, где name.app — имя приложения, которое пользователь видит в Google play или уже в своем телефоне, а *.base — это некая сигнатура, определяющая, что именно содержит пакет, к примеру:

• .contacts — список контактов;
• .maps — карты и координаты геолокации;
• .telephony — списки SMS- и MMS-сообщений.

Внутри пакета по сути набор директорий, где в соответствии с внутренней логикой приложения содержатся те или иные данные. К примеру, обычно визуальный и аудиоконтент хранится в /media, фотокарточки и аватары — в /photos, данные профиля — в /profile, кеш — в /chache. Конечно, бывают и исключения, так что иногда приходится ручками залезать в каждый каталог и просматривать его.

Подробнее о системных и пользовательских директориях в Android можно узнать из этого материала.

Рассмотрим самые основные источники данных.

1. Контакты и журнал вызовов

Имя пакета: com.android.providers.contacts

Интересующие эксперта директории и файлы:

• /files/
• photos/
• profile/
• /databases/
• contacts2.db — основная БД, содержащая список контактов, открывается с помощью SQL Manager Lite (viewer)

2. Сообщения SMS и MMS

Имя пакета: com.android.providers.telephony

Интересующие эксперта директории и файлы:

• /app_parts
• /databases/
• mmssms.db — БД с SMS- и MMS-сообщениями
• telephony.db — журнал звонков

3. Почта Gmail

Имя пакета: com.google.android.gm

Интересующие эксперта директории и файлы:

• /cache
• /databases/
• mailstore.@gmail.com.db
• databases/suggestions.db
• /shared_prefs/
• MailAppProvider.xml
• Gmail.xml
• UnifiedEmail.xml

4. 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/

5. Google Maps

Имя пакета: com.google.android.apps.maps

Интересующие эксперта директории и файлы:

• /cache/http/
• /databases/
• gmm_myplaces.db — сохраненные места на картах Google Maps
• gmm_storage.db — места, отмеченные геолокацией

6. Facebook (без мессенджера)

Имя пакета: com.facebook.katana

Интересующие эксперта директории и файлы:

• /files/video-cache/
• /cache/images/
• /databases/
• bookmarks_db2
• contacts_db2
• nearbytiles_db
• newsfeed_db
• notifications_db
• prefs_db
• threads_db2

7. Viber

Имя пакета: com.viber.voip

Интересующие эксперта директории и файлы:

• /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

8. WhatsApp

Имя пакета: com.whatsapp

Интересующие эксперта директории и файлы:

• /files/
• Avatars/
• me
• me.jpeg
• /shared_prefs/
• RegisterPhone.xml
• VerifySMS.xml
• /databases/
• msgstore.db
• wa.db
• /sdcard/WhatsApp/
• Media/
• Databases/

Помимо стандартных приложений, на устройство может быть установлено фейковое или вредоносное ПО, поэтому еще одним источником данных может послужить изучение *.apk-файла, вытянутого из внутренней памяти. Но это уже больше относится к реверсингу малвари и выходит за рамки настоящей статьи. Однако для вирусных аналитиков и форензик-специалистов это настоящий кладезь ценной информации. Более подробно о реверсинге APK ты можешь почитать в статьях тут и вот тут.

Рутинг устройства

Рутинг — это получение прав суперпользователя, то есть root’а на Android-совместимом девайсе. В ходе рутинга в систему устанавливаются приложение SuperSU, бинарный файл SU и набор консольных утилит BusyBox. Root-права дадут нам полный контроль над системой, возможность беспрепятственно получать доступ к системным директориям, пользовательским данным и их содержимому, что как раз и требуется.

Среди программ для рутования Android-девайса на сегодняшний день наиболее популярны Unlock Root, Kingo Android ROOT, Universal AndRoot и iRoot. Хотя найдется еще с десяток других, которые сделают это не хуже. Сам процесс рутования мы рассматривать не будем, отметим лишь, что все названные проги имеют GUI-интерфейс и, как правило, одну кнопку.

В случае если девайc был физически поврежден и информация утеряна, часть данных можно попробовать восстановить на новый аппарат из облачного хранилища Dropbox, GDrive, с которыми устройство синхронизировалось. Для этого достаточно получить доступ к привязанному аккаунту Google.

Сброс пароля и графического ключа

Один из основных вопросов при начале анализа — как получить доступ к устройству. И на первых порах помешать этому может установленный графический ключ или пароль. Но для нас это будет совсем не большой проблемой. Поступить можно двумя способами: либо узнать сам 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 пишем:

Если же после перезагрузки девайса трюк не удался, то сделай еще так:

И как вариант, еще прописать измененные данные в базу данных без удаления файлов:

Вот, собственно, и все! Дело сделано, дорога расчищена.

Для любопытных есть еще одна утилита — 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

[/crayon]
После копирования открываем файл 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 и отправляемся пить кофе.

В итоге у нас расшифрованная база данных всех чатов с содержанием бесед и пересылаемых данных (их метаданных).

Вот, собственно, и все! Следы контактов с «посторонними лицами» были обнаружены. Хотя, конечно, показанные операции — это лишь часть большой работы, что была проделана другими специалистами.