Содержание
1. Введение: Зачем искать следы стирания в Android Recycle Bin и в чём сложность2. Архитектура Android: как работает корзина и куда удаляются данные
3. Подготовка окружения: установка ADB, Python-скриптов и forensic-утилит
4. Интерфейс анализа: выбор инструментов и настройка рабочей станции
5. Получение дампа системы: безопасное извлечение логов и кэша
6. Базовый парсинг: структура журналов и поиск записей MediaStore
7. Практика: анализ SQLite-баз данных и файловых метаданных
8. Продвинутые техники: восстановление фрагментов, анализ F2FS/EXT4 и журнал транзакций
9. Работа с облачными корзинами и синхронизацией Google/Производителей
10. Автоматизация процесса: скрипты, пайплайны и batch-обработка
11. Безопасность и юридические аспекты: цепочка custody, хеширование и протоколирование
12. Мониторинг и отладка: логирование, тесты и оптимизация анализа
13. Интеграция с forensic-платформами: Autopsy, Cellebrite, Magnet AXIOM
14. Часто задаваемые вопросы (FAQ)
15. Заключение: Будущее мобильной криминалистики и анализа корзины в 2026 году
Введение: Зачем искать следы стирания в Android Recycle Bin и в чём сложность
В современных расследованиях, связанных с утечкой данных, корпоративными инцидентами или гражданскими спорами, Android-устройства часто становятся ключевым источником цифровых улик. При этом пользователи активно используют функцию «Корзины» (Recycle Bin / Trash), предполагая, что она гарантирует временное хранение файлов перед окончательным удалением. Однако с точки зрения мобильной криминалистики, корзина Android — это не единая папка, а распределённая система метаданных, журналов и скрытых резервных копий, которая оставляет обширные следы даже после «очистки».Проблема заключается в том, что начиная с Android 10, Google внедрила модель ограниченного доступа к хранилищу (Scoped Storage), переработала архитектуру MediaStore и изменила механизм работы с удалёнными файлами. Вместо прямого перемещения в `/storage/emulated/0/.Trash`, система использует логический флаг `IS_TRASHED` в базе данных `MediaProvider`, временные ярлыки, кэшированные превью и журналы транзакций файловой системы. При ручном анализе через проводник или стандартные инструменты восстановления эти следы часто остаются незамеченными, что приводит к ложным выводам о «полном удалении» данных.
Дополнительную сложность добавляют особенности файловых систем: F2FS (Flash-Friendly File System) и EXT4, используемые на современных устройствах, применяют журналирование, отложенную запись и механизмы checkpointing, которые сохраняют фрагменты удалённых блоков в служебных разделах до момента принудительного освобождения пространства. Попытка извлечь данные без понимания этих механизмов ведёт к повреждению метаданных, нарушению цепочки custody и потере юридической значимости результатов.
Решение — системный, криминалистически корректный подход к анализу корзины Android: от безопасного извлечения логических и физических образов до парсинга SQLite-баз, анализа WAL-файлов, проверки журналов файловой системы и автоматизированного сопоставления метаданных. Преимущества такого пайплайна очевидны: возможность восстановления временной шкалы удаления, доказательство факта сокрытия данных, юридически значимая фиксация результатов и минимизация риска повреждения оригинального носителя.
В этом руководстве мы подробно разберём каждый этап работы: от подготовки forensic-окружения и установки ADB/Python-утилит до продвинутого анализа F2FS/EXT4, интеграции с Autopsy и автоматизации массового парсинга. Материал опирается на официальную документацию Android Open Source Project (AOSP), стандарты NIST SP 800-86 и ISO/IEC 27037, а также проверенные практики мобильной криминалистики. Для выполнения инструкций потребуются базовые навыки работы с командной строкой, понимание принципов реляционных баз данных и знание основ файловой журналирования. Мы уделим особое внимание безопасности, валидации доказательств, соответствию требованиям 152-ФЗ и GDPR, а также типичным ошибкам, которые делают результаты анализа недопустимыми в суде.
Архитектура Android: как работает корзина и куда удаляются данные
Понимание внутренней архитектуры корзины Android критически важно для корректного извлечения следов стирания. В отличие от настольных ОС, где корзина представляет собой скрытую директорию с перемещёнными файлами, Android использует многоуровневую систему управления медиаконтентом и метаданными.Начиная с Android 10 (API 29), Google заменила прямой доступ к файловой системе через MediaStore API на модель с логическими идентификаторами. При «удалении» файла система не перемещает его физически. Вместо этого в таблице `files` базы данных `com.android.providers.media.module` обновляется столбец `IS_TRASHED` на значение `1`, а в `DATE_EXPIRES` записывается метка времени окончания хранения (обычно 30 или 60 дней). Файл остаётся на физическом носителе по прежнему пути, но становится невидимым для приложений, запрашивающих контент через MediaStore.
Файловые менеджеры и производители реализуют собственные «корзины», создавая скрытые директории:
- `/storage/emulated/0/.Trash/`
- `/sdcard/.Trash/`
- `/storage/emulated/0/Android/data/com.sec.android.gallery3d/.trash/` (Samsung)
- `/data/media/0/.trash/` (Xiaomi/MIUI)
Важно понимать: эти директории содержат только ярлыки или копии превью, а не оригиналы. Оригиналы остаются в исходных папках (`DCIM`, `Pictures`, `Downloads`) до срабатывания планировщика очистки `MediaProvider`.
Журналы удаления регистрируются в нескольких местах:
1. SQLite WAL-файлы (`files.db-wal`): содержат промежуточные транзакции до коммита, включая флаги удаления.
2. Системные логи (`logcat`): события `MediaScanner`, `FileObserver`, `StorageManager` фиксируют перемещения и очистку.
3. Журнал файловой системы (`EXT4 journal`, `F2FS checkpoint`): сохраняет метаданные блоков до принудительного освобождения.
4. Кэш приложений: галереи, файловые менеджеры и мессенджеры кешируют превью и метаданные даже после удаления оригиналов.
При полном удалении («Очистить корзину») MediaProvider отправляет команду `MediaStore.TRASH_MEDIA` или `MediaStore.setDeleteUri()`, после чего система помечает блоки как свободные. На F2FS это не означает мгновенную запись нулей — блоки остаются в состоянии `DIRTY` до garbage collection. На EXT4 они переходят в `UNALLOCATED` и могут быть перезаписаны в любой момент.
⚠️ Важно: Включённое шифрование (FDE/FBE) не удаляет данные мгновенно. Оно шифрует блоки на лету, но физические сектора сохраняются до перезаписи или команды `cryptsetup`/`vold` очистки. Это позволяет извлекать фрагменты при наличии ключей или резервных копий.
Понимание этой архитектуры позволяет выбрать корректный метод анализа: логический (для метаданных и SQLite), гибридный (для кэша и логов) или физический (для carving и journal-анализа). В следующих разделах мы перейдём от теории к практике: подготовке рабочей станции и установке необходимых инструментов.
Подготовка окружения: установка ADB, Python-скриптов и forensic-утилит
Для криминалистического анализа Android Recycle Bin требуется стабильное, изолированное окружение, обеспечивающее безопасное подключение к устройству, извлечение данных и парсинг без риска модификации оригинала. Linux является предпочтительной платформой благодаря нативной поддержке ADB, инструментам работы с образами и широкому набору open-source forensic-утилит.Установка базовых компонентов на Ubuntu/Debian:
bash
sudo apt update && sudo apt upgrade -y
sudo apt install -y adb fastboot python3 python3-pip python3-venv \
sqlite3 libsqlite3-dev hexdump xxd parted e2fsprogs f2fs-tools
sudo apt install -y autopy python3-tk git curl wget
Настройка изолированного Python-окружения:
bash
python3 -m venv ~/android-forensic
source ~/android-forensic/bin/activate
pip install --upgrade pip setuptools wheel
pip install pandas numpy loguru hexdump tqdm sqlite3-wrapper pytz
Установка дополнительных forensic-инструментов:
bash
<h2 id="autopsy-graficheskiy-analiz-obrazov">Autopsy (графический анализ образов)</h2>
sudo apt install -y autopsy sleuthkit
<h2 id="ftk-imager-alternativa-dlya-sozdaniya-obrazov">FTK Imager (альтернатива для создания образов)</h2>
<h2 id="skachat-s-sayta-accessdata-ili-ispolzovat-wine-port">Скачать с сайта AccessData или использовать wine-порт</h2>
<h2 id="rekomenduetsya-ispolzovat-dd-dc3dd-dlya-chistoty">Рекомендуется использовать dd/dc3dd для чистоты</h2>
<h2 id="sqlite-browser-vizualnyy-analiz-baz">SQLite Browser (визуальный анализ баз)</h2>
sudo apt install -y sqlitebrowser
Создание структуры проекта:
bash
mkdir -p ~/android-forensic/{images,databases,logs,scripts,output,tests}
touch ~/android-forensic/scripts/extract_mediacore.py
touch ~/android-forensic/scripts/parse_trash_logs.py
touch ~/android-forensic/config.yaml
Конфигурационный файл `config.yaml`:
yaml
log_level: "INFO"
adb_timeout: 30
device_id: ""
output_dir: "./output"
log_file: "./logs/analysis_$(date +%F).log"
skip_system_apps: true
validate_hashes: true
parse_wal: true
Проверка окружения:
bash
adb version
sqlite3 --version
python3 -c "import sqlite3, pandas, loguru; print('Environment OK')"
⚠️ Предупреждение: Никогда не подключайте исследуемое устройство к сети без отключения автоматической синхронизации. Отключите Wi-Fi, мобильные данные и Bluetooth до начала извлечения. Используйте режим «Только зарядка» или «Передача файлов» с подтверждением отладки.
После подготовки окружения переходим к настройке интерфейса анализа и выбору инструментов для работы с дампами и базами данных.
Интерфейс анализа: выбор инструментов и настройка рабочей станции
Анализ следов удаления в Android Recycle Bin требует комбинации низкоуровневого парсинга, визуального анализа баз данных и автоматизированного сопоставления метаданных. Выбор правильной среды напрямую влияет на точность, скорость и воспроизводимость результатов.Инструменты для работы с базами данных:
- DB Browser for SQLite — базовый GUI-инструмент для просмотра таблиц, выполнения SQL-запросов и экспорта данных. Подходит для первичного анализа `files.db`.
- SQLite Studio — продвинутый анализатор с поддержкой WAL-режима, экспорта в JSON/CSV и встроенным отладчиком запросов.
- Python + sqlite3/pandas — для автоматизации, массового парсинга и сопоставления с внешними источниками.
Hex-анализ и парсинг образов:
- 010 Editor — профессиональный hex-редактор с шаблонами для SQLite, EXT4, F2FS. Позволяет автоматически распознавать структуры.
- Autopsy — комплексная forensic-платформа с модулями для Android, поддержкой carving, анализом журналов и генерацией отчётов.
- strings + grep + xxd — CLI-конвейеры для быстрого поиска сигнатур, меток времени и фрагментов удалённых файлов.
Настройка рабочей станции для стабильности:
bash
<h2 id="otklyuchenie-usb-avtosnabzheniya">Отключение USB-автоснабжения</h2>
echo 0 | sudo tee /sys/module/usbcore/parameters/autosuspend
<h2 id="nastroyka-prav-dostupa-k-adb">Настройка прав доступа к ADB</h2>
sudo usermod -aG plugdev $USER
<h2 id="uvelichenie-limitov-faylovyh-deskriptorov">Увеличение лимитов файловых дескрипторов</h2>
echo "* soft nofile 65536" | sudo tee -a /etc/security/limits.conf
sudo sysctl -p
Конвейерная обработка логов:
bash
<h2 id="izvlechenie-sobytiy-udaleniya-iz-logcat">Извлечение событий удаления из logcat</h2>
adb logcat -d | grep -i "trash\|delete\|mediaprovider" > ./logs/trash_events.log
<h2 id="poisk-sqlite-wal-fragmentov">Поиск SQLite WAL-фрагментов</h2>
find /data/media -name "*.db-wal" -exec cp {} ./output/ \;
⚠️ Совет: Ведите отдельный журнал для каждой сессии. Фиксируйте: модель устройства, версию Android, хеш образа, список извлечённых баз, результаты парсинга и метки времени. Это критично для юридической значимости.
После настройки интерфейса переходим к безопасному получению дампов системы.
Получение дампа системы: безопасное извлечение логов и кэша
Корректное извлечение данных — фундамент криминалистического анализа. На современных Android-устройствах полный физический дамп часто невозможен без root или exploit, поэтому применяется логический и гибридный подходы, фокусирующиеся на MediaStore, кэше приложений и системных журналах.Логическое извлечение через ADB:
bash
<h2 id="proverka-podklyucheniya">Проверка подключения</h2>
adb devices
<h2 id="vklyuchenie-rezhima-otladki-i-podtverzhdenie-na-ustroystve">Включение режима отладки и подтверждение на устройстве</h2>
<h2 id="izvlechenie-baz-dannyh-mediaprovider">Извлечение баз данных MediaProvider</h2>
adb shell "run-as com.android.providers.media.module cp /data/user/0/com.android.providers.media.module/databases/files.db /sdcard/"
adb pull /sdcard/files.db ./output/
<h2 id="izvlechenie-kesha-galerey">Извлечение кэша галерей</h2>
adb shell "ls -la /sdcard/Android/data/com.google.android.gallery3d/cache/" | head -20
Извлечение логов и журналов:
bash
<h2 id="sbros-i-sohranenie-logcat">Сброс и сохранение logcat</h2>
adb logcat -c
adb logcat -v time -d > ./logs/full_logcat.log
<h2 id="filtratsiya-sobytiy-udaleniya">Фильтрация событий удаления</h2>
grep -i "IS_TRASHED\|MediaStore.TRASH\|FileObserver.DELETE" ./logs/full_logcat.log > ./logs/trash_filtered.log
Гибридный дамп (с ограниченным root или через backup API):
bash
<h2 id="sozdanie-rezervnoy-kopii-dannyh-prilozheniy-trebuet-podtverzhdeniya">Создание резервной копии данных приложений (требует подтверждения)</h2>
adb backup -f android_backup.ab -apk com.android.providers.media.module com.sec.android.gallery3d
<h2 id="raspakovka-ab-trebuetsya-openssl">Распаковка .ab (требуется openssl)</h2>
openssl zlib -d -in android_backup.ab -out android_backup.tar
tar -xvf android_backup.tar -C ./output/backup/
Верификация целостности:
bash
sha256sum ./output/files.db > ./logs/extract_hash.sha256
md5sum ./output/files.db >> ./logs/extract_hash.sha256
⚠️ Важно: Не используйте команды `adb shell rm`, `adb shell su` или сторонние «cleaner» приложения. Они модифицируют метаданные, перезаписывают WAL-файлы и нарушают цепочку custody.
После получения дампов переходим к базовому парсингу и поиску записей, связанных с корзиной.
Базовый парсинг: структура журналов и поиск записей MediaStore
Побитовый дамп или логическое извлечение Android-устройства содержит тысячи файлов. Без понимания структуры MediaStore и журналов удаление остаётся «невидимым». На этом этапе применяется сигнатурный поиск, анализ SQLite-схем и сопоставление временных меток.Анализ схемы `files.db`:
bash
sqlite3 ./output/files.db ".schema"
sqlite3 ./output/files.db "SELECT name FROM sqlite_master WHERE type='table';"
Ключевые таблицы: `files`, `thumbnails`, `audio`, `images`, `video`, `downloads`.
Поиск записей с флагом удаления:
sql
SELECT _id, _data, mime_type, IS_TRASHED, DATE_EXPIRES, DATE_MODIFIED
FROM files
WHERE IS_TRASHED = 1
ORDER BY DATE_EXPIRES DESC;
Результат показывает файлы, помеченные как удалённые, путь к ним (`_data`), тип MIME и дату истечения срока хранения в корзине.
Анализ WAL-файлов:
WAL (Write-Ahead Logging) содержит транзакции, которые ещё не были записаны в основную базу. Даже после очистки корзины фрагменты могут оставаться в `files.db-wal`.
bash
sqlite3 ./output/files.db-wal "SELECT count(*) FROM files WHERE IS_TRASHED=1;"
<h2 id="ili-cherez-python-dlya-bezopasnogo-chteniya">Или через Python для безопасного чтения</h2>
python3 -c "
import sqlite3
conn = sqlite3.connect('./output/files.db-wal')
cursor = conn.execute('SELECT _data, IS_TRASHED FROM files WHERE IS_TRASHED=1')
for row in cursor: print(row)
"
Поиск в системных логах:
bash
grep -E "MediaProvider|MediaScanner|StorageManager" ./logs/trash_filtered.log | head -30
События типа `MediaProvider: trashing file` или `FileObserver: DELETE event` подтверждают факт удаления и указывают время операции.
⚠️ Предупреждение: Не редактируйте `.db` или `.db-wal` файлы напрямую. Используйте `PRAGMA journal_mode=WAL;` и `VACUUM;` только на копиях. Прямая запись может повредить WAL-цепочку и сделать данные нечитаемыми.
После базового поиска переходим к практике анализа метаданных и восстановления контекста удаления.
Практика: анализ SQLite-баз данных и файловых метаданных
На практике восстановление следов стирания требует не просто поиска флагов, но и сопоставления метаданных, анализа кэшированных превью, проверки журналов приложений и восстановления временной шкалы событий.Извлечение метаданных удалённых файлов:
python
import sqlite3
import pandas as pd
def extract_trash_metadata(db_path):
conn = sqlite3.connect(db_path)
query = """
SELECT f._data, f.mime_type, f.IS_TRASHED, f.DATE_EXPIRES, f.SIZE, f.DATE_MODIFIED, f.DATE_ADDED
FROM files f
WHERE f.IS_TRASHED = 1
ORDER BY f.DATE_MODIFIED DESC
"""
df = pd.read_sql_query(query, conn)
conn.close()
return df
trash_df = extract_trash_metadata("./output/files.db")
print(trash_df.head(10))
trash_df.to_csv("./output/trash_files_metadata.csv", index=False)
Этот скрипт извлекает путь, тип, размер, даты добавления/изменения и срок хранения в корзине. Экспорт в CSV позволяет сопоставить данные с внешними журналами.
Анализ кэша превью:
Даже после удаления оригиналов, кэшированные миниатюры часто остаются в `/data/data/com.android.providers.media/thumbnails/` или `/sdcard/Android/data/.../cache/`.
bash
adb pull /data/data/com.android.providers.media/thumbnails/ ./output/thumbnails/
file ./output/thumbnails/*.jpg | head -10
Совпадение хешей превью с удалёнными файлами подтверждает их существование и помогает восстановить визуальный контекст.
Сопоставление с журналом приложений:
Мессенджеры, почта и облачные синхронизаторы ведут собственные логи. Например, WhatsApp хранит `msgstore.db`, Telegram — кэши в `org.telegram.messenger/files/`. Поиск по `_data` из MediaStore позволяет найти дубликаты или упоминания удалённых файлов в чатах.
⚠️ Совет: Всегда сохраняйте оригинальные `.db` и `.db-wal` до анализа. Используйте `cp` или `rsync -a`. Никогда не работайте с оригиналом напрямую.
После практики переходим к продвинутым техникам восстановления фрагментов и анализа журналируемых файловых систем.
Продвинутые техники: восстановление фрагментов, анализ F2FS/EXT4 и журнал транзакций
Когда логические методы исчерпаны, а файлы помечены как удалённые, требуется анализ на уровне файловой системы. F2FS и EXT4 используют журналирование и отложенную запись, которые сохраняют метаданные и фрагменты данных до принудительного освобождения.Анализ F2FS checkpoint:
F2FS хранит метаданные в структуре `checkpoint`, которая обновляется при синхронизации. Удалённые блоки помечаются в `SIT (Segment Information Table)` как `DIRTY`, но остаются читаемыми до garbage collection.
bash
<h2 id="ustanovka-f2fs-tools">Установка f2fs-tools</h2>
sudo apt install -y f2fs-tools
<h2 id="proverka-obraza">Проверка образа</h2>
fsck.f2fs -f ./output/f2fs_image.img
<h2 id="izvlechenie-metadannyh">Извлечение метаданных</h2>
dump.f2fs -d ./output/f2fs_image.img | grep -i "delete\|trash\|inode" | head -20
Скрипт для парсинга inode удалённых файлов:
python
import struct
def parse_f2fs_inode(image_path, inode_offset):
with open(image_path, 'rb') as f:
f.seek(inode_offset)
data = f.read(256)
flags = struct.unpack('<I', data[100:104])[0]
if flags & 0x1000: # Пример флага удаления
print(f"Inode at {hex(inode_offset)} marked as deleted/trashed")
Анализ EXT4 journal:
EXT4 записывает транзакции в `journal` (обычно `/dev/sdX3` или внутренний раздел). Удаление файла регистрируется как `unlink` в journal до коммита в main filesystem.
bash
<h2 id="ustanovka-e2fsprogs">Установка e2fsprogs</h2>
sudo apt install -y e2fsprogs
<h2 id="damp-journal">Дамп journal</h2>
debugfs -R "dump <8> ./output/journal_dump.bin" /dev/sdX2
<h2 id="analiz-cherez-strings">Анализ через strings</h2>
strings ./output/journal_dump.bin | grep -i "unlink\|delete\|IS_TRASHED"
Для криминалистического анализа используется `jbd2` модуль в Autopsy или `ext4undel` для восстановления unlinked файлов.
Carving фрагментов:
Когда метаданные утеряны, применяется carving по сигнатурам (JPG, MP4, PDF, DB).
bash
foremost -i ./output/physical_dump.img -o ./output/carved/ -T
scalpel ./output/physical_dump.img -c /etc/scalpel/scalpel.conf -o ./output/carved_scalpel/
Сопоставление carved файлов с датами из MediaStore позволяет восстановить удалённый контент даже после очистки корзины.
⚠️ Важно: Carving не восстанавливает имена файлов и метаданные. Он извлекает сырые данные. Для криминалистики это допустимо только как вспомогательный метод после анализа логических следов.
Переходим к работе с облачными корзинами и синхронизацией.
Работа с облачными корзинами и синхронизацией Google/Производителей
Современные Android-устройства активно синхронизируют данные с облачными сервисами: Google Photos, Samsung Cloud, Xiaomi Cloud, Яндекс.Диск, Dropbox. При «удалении» файла на устройстве, синхронизация может оставить копию в облачной корзине, которая хранится отдельно и доступна через веб-интерфейс или API.Архитектура облачной синхронизации:
- Google Photos: использует `com.google.android.apps.photos`. Корзина хранится на серверах Google до 60 дней. Локальные следы: кэш превью, `photos_sync.db`, журналы `Google Play Services`.
- Samsung Gallery: синхронизирует через `com.samsung.android.cloud`. Корзина доступна 30 дней. Локальные следы: `/sdcard/.Trash/`, `gallery3d.db`.
- Xiaomi/MIUI: использует `com.miui.gallery` и Mi Cloud. Корзина 30 дней. Следы: `/data/data/com.miui.gallery/files/trash/`.
Извлечение локальных следов синхронизации:
bash
adb pull /data/data/com.google.android.apps.photos/databases/photos_sync.db ./output/
adb pull /data/data/com.samsung.android.cloud/files/sync_logs.json ./output/
Анализ `photos_sync.db`:
sql
SELECT cloud_id, local_path, upload_status, trashed_at, restored_at
FROM local_media
WHERE trashed_at IS NOT NULL;
Запрос показывает файлы, помеченные как удалённые в облаке, даты удаления и восстановления.
Автоматизация проверки через API:
Для корпоративных расследований допустимо использовать OAuth2 API Google Photos или Microsoft Graph (для OneDrive) для выгрузки списка удалённых элементов из корзины владельца аккаунта.
bash
<h2 id="primer-zaprosa-k-google-photos-api-trebuet-avtorizatsii">Пример запроса к Google Photos API (требует авторизации)</h2>
curl -H "Authorization: Bearer $TOKEN" \
"https://photoslibrary.googleapis.com/v1/mediaItems?fields=mediaItems(id,filename,mediaMetadata,trashed)" \
| jq '.mediaItems[] | select(.trashed == true)'
⚠️ Предупреждение: Доступ к облачной корзине требует явного согласия владельца или судебного постановления. Анализ локальных следов синхронизации допустим без доступа к аккаунту, но не заменяет выгрузку с серверов провайдера.
Переходим к автоматизации и batch-обработке.
Автоматизация процесса: скрипты, пайплайны и batch-обработка
Ручной парсинг не масштабируется для массовой обработки устройств. Автоматизация включает создание конвейеров, пакетную обработку дампов и генерацию отчётов.Bash-скрипт для автоматического извлечения и парсинга:
bash
#!/bin/bash
DEVICE_DIR="./devices"
OUTPUT_DIR="./output/batch"
mkdir -p "$OUTPUT_DIR"
for dev_dir in "$DEVICE_DIR"/*/; do
DEV_ID=$(basename "$dev_dir")
echo "Processing $DEV_ID"
# Извлечение MediaProvider
adb -s "$DEV_ID" pull /data/user/0/com.android.providers.media.module/databases/files.db "$OUTPUT_DIR/$DEV_ID/"
# Парсинг корзины
sqlite3 "$OUTPUT_DIR/$DEV_ID/files.db" \
"SELECT _data, DATE_MODIFIED, DATE_EXPIRES FROM files WHERE IS_TRASHED=1;" \
> "$OUTPUT_DIR/$DEV_ID/trash_list.csv"
# Хеширование
sha256sum "$OUTPUT_DIR/$DEV_ID/files.db" >> "$OUTPUT_DIR/$DEV_ID/hashes.log"
done
Python-пайплайн для массового анализа:
python
import os
import sqlite3
import pandas as pd
from pathlib import Path
def batch_parse_trash(input_dir, output_dir):
Path(output_dir).mkdir(exist_ok=True)
results = []
for db_file in Path(input_dir).rglob("files.db"):
try:
conn = sqlite3.connect(db_file)
df = pd.read_sql_query(
"SELECT _data, SIZE, DATE_MODIFIED, DATE_EXPIRES FROM files WHERE IS_TRASHED=1",
conn
)
conn.close()
df['source_db'] = str(db_file)
results.append(df)
except Exception as e:
print(f"Error parsing {db_file}: {e}")
if results:
combined = pd.concat(results, ignore_index=True)
combined.to_csv(f"{output_dir}/batch_trash_report.csv", index=False)
print(f"Processed {len(combined)} trashed files across {len(results)} databases.")
batch_parse_trash("./images", "./output/batch")
Интеграция с cron/systemd для фоновой обработки:
bash
<h2 id="systemd-service">systemd service</h2>
[Unit]
Description=Android Trash Analysis Batch
[Service]
ExecStart=/usr/bin/python3 /opt/android-forensic/scripts/batch_parser.py
[Install]
WantedBy=multi-user.target
⚠️ Совет: Добавляйте логирование, обработку ошибок и проверку целостности хешей в каждый этап пайплайна. Автоматизация без валидации приводит к ложным результатам.
Переходим к безопасности и юридическим аспектам.
Безопасность и юридические аспекты: цепочка custody, хеширование и протоколирование
В корпоративных и судебных расследованиях результаты анализа Android Recycle Bin должны быть юридически значимыми. Это требует строгого соблюдения цепочки custody (chain of custody), фиксации хешей и протоколирования каждого шага.Хеширование образов и баз:
bash
sha256sum ./output/files.db > ./logs/evidence_hashes.txt
md5sum ./output/files.db >> ./logs/evidence_hashes.txt
<h2 id="verifikatsiya">Верификация</h2>
sha256sum -c ./logs/evidence_hashes.txt
Хеши должны генерироваться сразу после извлечения и проверяться перед каждым анализом.
Протоколирование действий:
bash
<h2 id="zapis-sessii-v-log">Запись сессии в лог</h2>
script ./logs/session_$(date +%F_%H%M).log
<h2 id="vypolnenie-komand">Выполнение команд</h2>
adb devices
sqlite3 ./output/files.db "PRAGMA integrity_check;"
<h2 id="zavershenie">Завершение</h2>
exit
`script` записывает все команды и вывод в файл, обеспечивая воспроизводимость.
Соответствие 152-ФЗ и GDPR:
- Персональные данные в корзине (фото, документы, логи) подпадают под защиту.
- Обезличивание: хеширование имён файлов, удаление метаданных EXIF перед отчётом.
- Хранение: шифрование архивов `gpg --symmetric --cipher-algo AES256 evidence.tar.gz`.
- Удаление: безопасное стирание `shred -vfz -n 7 evidence.tar.gz` после завершения дела.
⚠️ Важно: Никогда не передавайте необработанные дампы третьим лицам. Используйте только хеши, метаданные и экспорты CSV/JSON с удалёнными личными данными. Суды принимают только результаты, полученные с соблюдением процедур фиксации и хеширования.
Переходим к мониторингу и отладке.
Мониторинг и отладка: логирование, тесты и оптимизация анализа
Для production-использования пайплайн должен быть надёжным, воспроизводимым и устойчивым к повреждённым базам.Логирование через `loguru`:
python
from loguru import logger
import sys
logger.remove()
logger.add(sys.stderr, level="INFO")
logger.add("./logs/analysis_{time:YYYY-MM-DD}.log", rotation="10 MB", level="DEBUG", compression="zip")
def parse_db(db_path):
logger.info(f"Starting analysis: {db_path}")
try:
# код парсинга
logger.success("Analysis completed successfully")
except Exception as e:
logger.error(f"Failed to parse: {e}")
raise
Юнит-тесты для валидации запросов:
python
import unittest
import sqlite3
import os
class TestTrashParser(unittest.TestCase):
def setUp(self):
self.db_path = "./tests/test_files.db"
conn = sqlite3.connect(self.db_path)
conn.execute("CREATE TABLE files (_data TEXT, IS_TRASHED INTEGER)")
conn.execute("INSERT INTO files VALUES ('/test.jpg', 1)")
conn.commit()
conn.close()
def test_query_trashed(self):
conn = sqlite3.connect(self.db_path)
res = conn.execute("SELECT count(*) FROM files WHERE IS_TRASHED=1").fetchone()
self.assertEqual(res[0], 1)
conn.close()
def tearDown(self):
os.remove(self.db_path)
if __name__ == '__main__':
unittest.main()
Оптимизация больших баз:
Для `files.db` > 500 МБ используйте индексы и чтение по чанкам:
sql
CREATE INDEX idx_trash ON files(IS_TRASHED, DATE_MODIFIED);
python
import sqlite3
conn = sqlite3.connect("large_files.db")
cursor = conn.execute("SELECT _data FROM files WHERE IS_TRASHED=1 LIMIT 1000 OFFSET 0")
Переходим к интеграции с forensic-платформами.
Интеграция с forensic-платформами: Autopsy, Cellebrite, Magnet AXIOM
Ручной парсинг эффективен для разовых задач, но в расследованиях используется специализированное ПО. Интеграция с Autopsy, Cellebrite и Magnet AXIOM ускоряет анализ, автоматизирует отчёты и обеспечивает стандартизацию.Autopsy:
- Импорт образа: `File → Add Data Source → Disk Image`
- Модуль Android: автоматически парсит `MediaStore`, `IS_TRASHED`, кэш приложений
- Отчёт: `Tools → Generate Report` в PDF/HTML
- Настройка кастомных ingest-модулей для SQLite-парсинга через Python
Cellebrite UFED:
- Логическое извлечение: `Logical → Android → MediaStore`
- Физическое: `Physical → JTAG/Chip-off` (требует лицензии)
- Отчёт: встроенный анализ корзины, временные шкалы, связи между приложениями
Magnet AXIOM:
- Поддержка F2FS/EXT4 journal
- Автоматическое восстановление `WAL` и `SHM` файлов
- Экспорт в CSV/JSON для внешних систем
Пример интеграции скриптов с Autopsy:
python
<h2 id="ingest-modul-dlya-autopsy-java-python-bridge">Ingest-модуль для Autopsy (Java/Python bridge)</h2>
def analyze_trash(db_path):
# парсинг
return {"trashed_files": list, "dates": list, "hashes": list}
⚠️ Совет: Используйте open-source инструменты для верификации результатов коммерческого ПО. Расхождения в парсинге часто указывают на повреждённые WAL или нестандартные реализации производителей.
Часто задаваемые вопросы (FAQ)
1. Почему `IS_TRASHED=1` не означает, что файл физически удалён?Android использует логическое удаление. Файл остаётся на диске до истечения `DATE_EXPIRES` или принудительной очистки. Блоки помечаются как свободные только после garbage collection.
2. Как найти удалённые файлы, если корзина очищена?
Используйте carving по сигнатурам, анализ EXT4/F2FS journal, поиск кэшированных превью и сопоставление с логами приложений. Физические блоки сохраняются до перезаписи.
3. Почему `files.db` пустой или повреждён?
Android 11+ использует разделённые базы (`files.db`, `external.db`), а производители часто меняют схему. Проверьте `com.android.providers.media.module` и используйте WAL-парсинг.
4. Можно ли восстановить файлы без root?
Логическое извлечение через ADB возможно для MediaStore и кэша. Физический доступ требует root или exploit. Для криминалистики допустим логический дамп с фиксацией ограничений.
5. Как доказать, что файл был удалён намеренно?
Сопоставьте `DATE_MODIFIED`, журналы `MediaProvider`, события `FileObserver` и логи приложений. Наличие `IS_TRASHED=1` с последующим `DELETE` подтверждает действие пользователя.
6. Почему облачная корзина не совпадает с локальной?
Синхронизация происходит с задержкой. Локальные файлы могут быть удалены до отправки команды в облако, или наоборот. Анализируйте оба источника.
7. Как обойти шифрование при анализе?
Без ключа пользователя или аппаратного токена расшифровка невозможна. Используйте логический дамп с активного устройства или извлечение из backup.
8. Что делать, если `logcat` очищен?
Системные логи ротируются. Ищите архивы в `/data/log/` или используйте `dumpsys` для получения текущих метрик. Кэши приложений часто содержат следы дольше, чем logcat.
9. Можно ли использовать Android Recycle Bin данные в суде?
Да, при соблюдении цепочки custody, хеширования, протоколирования и соответствия процедуре изъятия. Результаты должны быть воспроизводимы независимым экспертом.
10. Как автоматизировать отчёт для руководства?
Используйте Python + Pandas + Jinja2 для генерации PDF/HTML отчётов. Экспортируйте CSV, добавляйте хеши, временные метки и сводные таблицы.
11. Почему некоторые телефоны не показывают `IS_TRASHED`?
Производители (Samsung, Xiaomi) используют кастомные реализации MediaStore. Проверяйте `gallery3d.db`, `miui.db` и системные журналы.
12. Как безопасно удалить следы после анализа?
Используйте `shred` для образов, `DBAN` для дисков, `cryptsetup` для зашифрованных разделов. Убедитесь, что резервные копии и кэши также уничтожены.
13. Что делать при ошибке SQLite `database disk image is malformed`?
Восстановите из `.db-wal` или используйте `PRAGMA integrity_check;` с `REINDEX;`. Для криминалистики работайте только с копиями, оригинал оставьте нетронутым.
14. Как проверить, что файл не был восстановлен из облака после удаления?
Сравните `DATE_EXPIRES` в MediaStore с логами синхронизации. Наличие `RESTORED` в `photos_sync.db` или `gallery3d.db` подтверждает обратное действие.
15. Можно ли парсить корзину на Android 14/15?
Да, архитектура MediaStore сохранена. Добавлены новые поля `DATE_TRASHED` и улучшена изоляция `Scoped Storage`. Используйте актуальные ADB и SQLite-схемы.
Заключение: Будущее мобильной криминалистики и анализа корзины в 2026 году
Анализ следов стирания в Android Recycle Bin остаётся критически важным навыком для специалистов по мобильной криминалистике, корпоративной безопасности и цифровому расследованию. Несмотря на усложнение архитектуры Android, внедрение FBE, Scoped Storage и облачной синхронизации, система продолжает оставлять обширные метаданные, журналы и кэшированные фрагменты, которые позволяют восстановить историю удаления файлов с высокой точностью.В 2026 году экосистема анализа смещается в сторону автоматизации, интеграции с AI-моделями для распознавания контекста и строгой стандартизации процедур фиксации. Ручной парсинг уступает место скриптовым пайплайнам, forensic-платформам с поддержкой F2FS/EXT4 journal и кросс-платформенной валидации результатов. Использование стандартных инструментов (ADB, SQLite, Autopsy) в сочетании с Python-скриптами обеспечивает баланс между доступностью, точностью и юридической значимостью.
Рекомендации для production-сред:
- Всегда создавайте логический образ до любых операций
- Фиксируйте хеши `SHA-256` и `MD5` сразу после извлечения
- Анализируйте `WAL` и `SHM` файлы отдельно от основной базы
- Сопоставляйте метаданные MediaStore с логами приложений и облачными синхронизациями
- Ведите протокол действий с использованием `script` и `loguru`
- Соответствуйте требованиям 152-ФЗ, GDPR и ISO/IEC 27037
Технологии хранения и защиты данных эволюционируют, но принципы криминалистически корректного анализа остаются неизменными. Освоив описанный пайплайн, вы получите надёжный инструмент для восстановления следов удаления, минимизации рисков и обеспечения юридической значимости доказательств. Следите за обновлениями AOSP, стандартами NIST и развитием forensic-платформ для поддержания экспертизы на актуальном уровне.
