Что нужно для импровизированной лаборатории 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 и отправляемся пить кофе. В итоге у нас расшифрованная база данных всех чатов с содержанием бесед и пересылаемых данных (их метаданных). Резюме Перед тобой полноценное руководство по извлечению данных из смартфона. Пускай мы и покажемся занудами, но используй его в благих целях. Все зло возвращается в десятикратных размерах. Зачем вредить самому себе?