Как достать данные из заблокированного Android

Что нужно для импровизированной лаборатории

• 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 и отправляемся пить кофе. В итоге у нас расшифрованная база данных всех чатов с содержанием бесед и пересылаемых данных (их метаданных).





Резюме
Перед тобой полноценное руководство по извлечению данных из смартфона. Пускай мы и покажемся занудами, но используй его в благих целях. Все зло возвращается в десятикратных размерах. Зачем вредить самому себе?