Как расшифровать userdata android

Как извлечь данные с резервной копии userdata_*.backup Android

вкл. 12 Март 2019 . Опубликовано в Android — Общее

Как извлечь данные с резервной копии userdata_*.backup Android. У вас есть резервная копия userdata_*.backup созданная в стоковом Recovery Android и вам необходимо извлечь из нее данные? Вот как это сделать:

Если вы разбили дисплей или у вас установлен графический код , а может быть пин-код, то возможно вы сможете извлечь необходимые данные с помощью резервной копии созданной в стоковом Recovery Android. Об этом мы уже рассказывали вам в прошлой статье, рекомендуем ознакомиться — как создать бэкап Android стоковым Recovery .

Теперь в этой статье мы расскажем вам как вскрыть бэкап, с помощью 2 способов.

Способ 1. Открываем резервную копию userdata_*.backup

1. На компьютер загрузить 7-zip архиватор и установить его

2. Переместите резервную копию userdata_*.backup

3. Правым кликом по резервной копии вызовите дополнительное меню и выберите «Открыть с помощью» и указать «7-zip»

4. После чего вы можете извлечь все данные из архива

Если userdata_*.backup при попытке открыть его через 7-zip не увенчалась успехом, переходим ко второму способу.

Способ 2. Открываем резервную копию userdata_*.backup

Прежде всего вам необходимо будет установить на компьютер Ubuntu Linux или создать виртуальную машину с Ubuntu Linux (расскажем позже).

1. Все Файлы резервной копии userdata_*.backup переместите в Ubuntu

2. В папке где находиться резервные копии сделайте правый клик мыши на свободной области и в появившемся меню выбрать «Открыть в терминале»

3. Далее вводим команду с помощью которой мы создадим из текущих файлов userdata_*.backup в образы

1. Теперь необходимо создать из всех частей образов один целый образ

cat part*.img > backup.img

2.Теперь необходимо примонтировать данный образ к системе, чтобы мы могли увидеть что находиться внутри

sudo mount -t ext4 backup.img /mnt

3. Теперь необходимо запустить файловый менеджер под root правами чтобы можно было полностью открыть все что нам необходимо

4. Переходим по пути /mnt и видим кучу папок которые являются данными вашего backup файла

Извлекаем данные, где что?

Все файлы видео, фото, видео, аудио, документы, можно найти в папку /media/o/.

Источник

Шифрование Android. Можно ли извлечь данные из шифрованного раздела.

Layder

Z3X-Team

Если при работе в Explorer (в eMMC Tool Shuite) наблюдается такая картина:

Mount [system] successfully PartType: LINUX
Mount [cache] successfully PartType: LINUX
Mount [persist] successfully PartType: LINUX
Mount [cust] successfully PartType: LINUX
Mount [userdata] SKIPPED PartType: Full Disk Encryption
Mount [data] SKIPPED PartType: Full Disk Encryption
Mount [storage/sdcard1] SKIPPED PartType: Full Disk Encryption

Это означает, что раздел пользовательских данных зашифрован .

eMMC File Manager выводит такую информацию:

Warning! Partition #46 [USERDATA] Is ENCRYPTED!
Rev: 1.3
Key Size: 16 bytes
Algo: aes-xts essiv:sha256
MKey: 0x40203A849FA58DAFAE95ED1E81EC9C32
Salt: 0x6D7C5B1F84B51F2A657FEAB2865C5324

На текущий момент данные из такого раздела извлечь практически невозможно прямым считыванием раздела из eMMC.
Если плата повреждена и на ней исправны процессор и eMMC, то единственный вариант извлечь данные — перепаять процессор и eMMC в рабочий аппарат, включить его, ввести пароль пользователя и получить доступ к данным.

Если говорить коротко о шифровании, то раздел /data шифруется 128битным ключом (16 байт) по алгоритму SHA256 (точнее одной из его разновидности). В данном случае идет речь о FDE (Full Disk Encryption) (полнодисковое шифрование).

1) Первое включение:

При первом включении (также после «wipe data») устройство с предустановленной ОС Android 5.0 и выше генерирует псевдослучайный 128-разрядный ключ. Его называют мастер-ключом (Master Key) или DEK (Device Encryption Key) . Помимо DEK, также генерируется еще одно псевдослучайное 128-битное число Salt (соль), а пользователя просят ввести пароль (если пользователь пароль не вводит, а ОС шифрование /data включает, то ОС использует какой-то свой пароль, на знании этого пароля основано получение доступа к /data в Xiaomi через TWRP).

Далее ОС Android рассчитывает промежуточный ключ (IK1), затем к нему примешивает Hardware-Bound private Key (HBK) (индивидуальный ключ процессора), рассчитывает IK2, IK3 и создает Encrypted Master Key (используя KEK, IV (части IK3)), т.е. зашифрованный Master Key (DEK) с помощью пароля пользователя.

Encrypted Master Key и Salt сохраняются в так называемом «Хранилище ключей» (Crypto Footer), которое располагается либо в в самом процессоре (в более новых процессорах), либо в конце зашифрованного раздела userdata (31 сектор от конца).

Все данные на пользовательском разделе /data в конечном счете шифруются именно с помощью DEK . Как именно выглядит этот ключ, владелец устройства не знает, он никогда не вводит его и даже не может считать штатными средствами. Созданием DEK, а также проверкой валидности ключей занимается модуль «KeyMaster«, работающий в так называемой «Trusted Execution Environment (TEE)» процессора, за пределы которой не должен выйти ключ шифрования DEK.

2) Включение аппарата при наличии зашифрованного раздела:

Для расшифровки данных, когда пользователь вводит свой пароль (или при его отсутствии используется «дефолтный» пароль), ОС Android получает Salt из «Хранилища ключей» (Crypto Footer), рассчитывает с помощью него промежуточный ключ (IK1), затем с помощью Hardware-Bound private Key (HBK) (индивидуальный ключ процессора), рассчитывает IK2, IK3 и оправляет полученный результат (KEK, IV) для попытки рассчитать DEK в модуль «KeyMaster«, который также использует Encrypted Master Key из «Хранилища ключей» (Crypto Footer). Если пароль пользователя верный, то полученный DEK используется для раскодирования раздела /data.

Для того, чтобы пользователь мог сменить свой пароль без перешифрования всего раздела, используется ключ, называемый Encrypted Master Key, т.е. Master Key (DEK), зашифрованный с помощью пароля пользователя. Если аппарат включен, пароль пользователя введен, и данные расшифрованы с помощью DEK, то возможно создание нового Encrypted Master Key, который сохраняется вместо предыдущего в хранилище ключей (Crypto Footer).

3) Невозможность расшифровать раздел данных:

а) при вводе неверного пароля;
б) замена процессора (с другим Hardware-Bound private Key (HBK));
с) замена процессора (с другим Hardware-Bound private Key (HBK) и другим содержимым «Хранилища ключей» (Crypto Footer)).

В этих случаях модуль «KeyMaster» получает не соответствующий зашифрованным данным DEK, и расшифровка раздела данных не предоставляется возможным.

Кому интересно узнать больше, рекомендую статьи:

Источник

Основы безопасности операционной системы Android. Native user space, ч.2

Вступление

Сегодня я продолжу рассматривать безопасность на уровне немного выше ядра. Во второй части мы рассмотрим, откуда появляются system.img, userdata.img и cache.img, а также как обеспечивается безопасность в Native user space.
Всем кому интересно, добро пожаловать!

Список статей

Что подразумевается под Native user space

Под Native user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik Virtual Machine, и которые не являются частью Linux kernel. Native user space — это исполняемые файлы, скомпилированные под определенную архитектуру. К ним относятся исполняемые файлы, которые запускаются из init скрипта автоматически или в случае наступления какого-либо события, toolbox утилиты, а также некоторые исполняемые файлы, которые пользователь может запустить из-под shell.

Начало

Как я уже рассказывал в первой части, в основе Android лежит Linux kernel. Как и во всех Linux системах, в основе безопасности Android лежит access control. Т.е. каждый ресурс (например, файл) содержит мета-информацию о том, кто создал этот файл — owner (владелец) — и к какой основной группе (owner group) принадлежит owner (владелец). Каждый процесс запускается от имени какого-то user (пользователя). У каждого пользователя есть основная группа. Кроме того он может являться членом других групп. Таким образом, если к каждому ресурсу прикрепить информацию (в формате rwxrwxrwx) о том, кто может читать/писать/исполнять ресурс (например, файл), то можно контролировать доступ к этому файлу. Например, файлу можно назначить разрешения: что может делать с этим файлом owner (владелец) этого файла; что могут делать пользователи, которые входят в состав owner group; что могут творить все остальные. Здесь об этом можно почитать подробнее.

Но у Android есть некоторые отличия. Во-первых, изначально Android — это операционная система для телефонов, которые, как известно, относятся к очень личным вещам и которые мы не любим давать в чужие руки. То есть она была задумана как операционная система, у которой только один пользователь. Поэтому было принято решение использовать различных Linux users для обеспечения безопасности (для каждого приложения — отдельный пользователь, как я уже рассказывал в первой статье). Во-вторых, в Android некоторые user (пользователи) и их UID (идентификаторы) были жестко запрограммированы в систему, что вызывает очень много нареканий людей связанных с безопасностью (хотя я, если честно, не очень понимаю, почему критикуется такой подход). Мы уже видели этих пользователей в файле system/core/include/private/android_filesystem_config.h Например, root имеет идентификатор 0, а system — 1000.

Как я уже отмечал, процесс запускается от имени того же пользователя (UID), что и процесс, который запускает этот новый процесс, т.е. UID(calling_process) == UID (called_process). Первый процесс, который запускается в Android — init — запускается от имени root (UID == 0). Таким образом, по-идее, все процессы также должны быть запущены от имени того же пользователи. Так оно, наверное, бы и было. Но, во-первых, процессы, запущенные от имени привилегированного пользователя (а так же те, кто обладает определенными capabilities), могут изменять свой UID на менее привилегированный. А во-вторых, в Android при запуске демонов в init.rc скрипте так же можно указать, с привилегиями какого пользователя и каких групп запускать данный процесс.

Все процессы, которые будут запущены через этих демонов, уже не будут иметь root привилегии.

System, data и cache

Я столько раз анонсировал эту тему, что можно было подумать, что она очень сложная и запутанная. На самом деле, это не так. System.img, userdata.img и cache.img — то, что получается в результате компиляции операционной системы Android. То есть в результате сборки системы получаются эти три файла, которые мы и записываем на наше устройство.

Но самое важно здесь не это. Благодаря тому, что в Android системе user name и UID системных пользователей жестко запрограммированы, уже на этапе компиляции мы можем определить права доступа различных системных пользователей к различным директориям в данных образах. Эти права доступа указаны в файле system/core/include/private/android_filesystem_config.h, который мы уже рассматривали в первой статье. Права доступа определяются отдельно для директорий (android_dirs[]) и отдельно для файлов (android_files[]) следующим образом:

А функция static inline void fs_config(const char *path, int dir, unsigned *uid, unsigned *gid, unsigned *mode, uint64_t *capabilities), которая определена дальше в этом файле отвечает за выставление owner, owner group, capabilities и прав доступа. Эта функция вызывается во время сборки образа.

В общем здесь всё должно быть более-менее понятно, за исключением установки флагов прав доступа (setuid и setgid) для некоторых файлов (например, для «system/xbin/su» права доступа определены как 06755, где первая 6 означает, что выставлен флаг установки ID пользователя (4) и флаг установки ID группы (2)). Установка этих флагов означает, что пользователь может повысить права запускаемого процесса до уровня owner (владельца) файла или owner group (группы владельца). В случае Android, каждое приложение — это пользователь со своими UID и GID. Таким образом, по умолчанию если вы из своего приложения запускаете какой-нибудь native executable, он исполняется с теми же UID и GID, как и приложение его вызвавшее. Установка данных флагов прав доступа позволяет выполнить native executable с правами владельца. В нашем случае, владелец — AID_ROOT (root). Происходит это следующим обрзазом system/extras/su/su.c:

Т.е. вызываются функции setuid и setgid. В этом случае, если данные функции выполнились успешно, то процесс начинает работать от имени owner и owner group данного файла. В нашем примере, данный процесс получает права суперпользователя, т.е. он может делать всё, что ему пожелается 🙂 Подобная анархия не всегда оправдана, поэтому в Linux ввели понятие capabilities. Так приложению «run-as» не нужны всё права суперпользователя, ему достаточно иметь возможность только менять свой идентификатор, чтобы запускать приложения от имени различных пользователей. Кстати, capabilities похоже появились недавно — в Android 2.3.x я их не встречал.

Безопасность

В случае привилегированных программ (типа, su) необходимо ограничивать круг приложений, которые могут вызывать эти программы. В противном случае любое приложение может получить права суперпользователя. Поэтому очень часто в такие программы встраивают проверку по UID:

Т.е. программа вначале проверяет, от чьего имени запущен вызывающий процесс, используя функцию getuid(). А потом сравнивает эти значения со значениями, которые жестко запрограммированы в систему. В данном случае, только процессы запущенные от имени пользователей «system» и «root» имеют право использовать su.

Заключение

В данной статье мы закончили разбирать, как обеспечивается безопасность на уровне Native user space. В следующих статьях я планирую разобрать, как работают permission (разрешения), но в связи с большой текущей загрузкой не знаю, когда приступлю к их написанию. Как всегда, буду очень рад дополнениям и исправлениям.

Источник