LINUX.ORG.RU
Форум — Admin  

Как расшифровать раздел ext4

 , , , ,


0

2

С потом и кровью был слит раздел userdata с Android 10 (LineageOS). Ожидался битый раздел, но debugfs говорит что он clean, видимо система успела его демонтировать при отключении: 

Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode filetype extent encrypt sparse_super large_file uninit_bg quota
Filesystem flags: unsigned_directory_hash
Default mount options: (none)
Filesystem state: clean <<<<<<<<<<<<<<<<<<<<<
Errors behavior: Remount read-only
Filesystem OS type: Linux
Inode count: 3432448
Block count: 13704952
Reserved block count: 4096
Free blocks: 8182
Free inodes: 3394575
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512

fsck нашел одну ошибку, но тоже не криминальную:

# fsck -fv /dev/sdd
fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Padding at end of inode bitmap is not set. Fix<y>? yes
Error writing file system info: Input/output error

/dev/sdd: ***** FILE SYSTEM WAS MODIFIED *****

(не обращайте внимание на Error writing file, это защита образа от записи, равно как и на FILE SYSTEM WAS MODIFIED - это приворукость авторов fsck)

Все монтируется великолепно без каких-либо ошибок.

Проблема в том, что никуда зайти нельзя, единственное к чему у меня есть доступ, это:

./data/unencrypted
./data/unencrypted/key
./data/unencrypted/key/version
./data/unencrypted/key/secdiscardable
./data/unencrypted/key/stretching
./data/unencrypted/key/keymaster_key_blob
./data/unencrypted/key/encrypted_key
./data/unencrypted/ref
./data/unencrypted/per_boot_ref
Вот так я познаю мир, оказывается и такое вот бывает.

Здесь, как я полагаю, храняться ключи шифрования. Вопрос - как их скормить и кому скормить, чтобы получить полный доступ к тому, что было когда-то /data/data/? Другие разделы тоже сдамплены, ну или что-то похожее на дамп есть.

Есть идея прошить в рекавери TWRP и слить данные через него, но пока ссыкатно, хотелось бы не мучать телефон больше.

← OpenNebula шаблон не переписывает настройки Virtual Networks
DHCP не обновляет BIND9 →

Ответ на: комментарий от anonymous

Ключ по всей видимости есть, но encrypted_key, а fscrypt хочет файлик на 32 байта, которого нет. Есть по всей видимости ключница keymaster_key_blob. Вот как оттуда достать сам ключ - не очень понятно.

Есть мануал как это сделать, но на самом телефоне: https://xdaforums.com/t/mate-9-how-to-retrieve-encrypted-files-from-a-broken-system-userdata-partition.3894561/ - и я тут ничего не понял

ruzisufaka ★
() автор топика
Ответ на: комментарий от ruzisufaka

Keymaster is able to use them and communicate with a hardware based Trusty TEE to obtain the real key for fscrypt. The decryption is related to hardware so only the device which creates these keys are able to decrypt them.

Без работоспособного девайса никак.

MagicMirror ★★
()
Ответ на: комментарий от monkdt

интересная тема, но я бы удивился если бы так просто можно было расшифровать диск имея только данные из бекапнутого раздела ). Это была бы не просто дыра в секурити, а дырища

Ну и слить бекап тоже не просто, спасибо приложению «спасите Бирму, подарок от Ньянмы», которое перебирает сплойты для процессора https://imobiefix.com/mct-mtk-bypass-tool-mediatek-auth-unlock-tool/

ruzisufaka ★
() автор топика
Ответ на: комментарий от MagicMirror

Без работоспособного девайса никак.

Девайс есть, но пока дальше fastboot загрузиться не могу. В момент, когда должна появиться анимированная заставка, происходит ребут.

На fastboot boot реагирует так:

fastboot boot twrp-3.7.0_9-0-begonia.img
< waiting for any device >
Sending 'boot.img' (31380 KB) OKAY [ 5.533s]
Booting OKAY [ 0.063s]
Finished. Total time: 5.658s

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

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

ruzisufaka ★
() автор топика
Последнее исправление: ruzisufaka (всего исправлений: 1)
Ответ на: комментарий от ruzisufaka

Тебе достаточно добиться рабочего TWRP, в нём же разблокировать раздел штатным методом и скопировать данные. Рекавери можно спокойно шить, это обратимо всегда.

MagicMirror ★★
()
Ответ на: комментарий от anonymous

Если это LineageOS, то по идее загрузчик на девайсе УЖЕ разлочен и доверенная загрузка начинается чуть дальше и ключ шифрования data доступен будет. И да, это урон безопасности, но выбор не велик - либо кушать залоченное производителем, либо разлоченное, но менее безопасное. Ключи шифрования по идее должны быть неизвлекаемыми, то есть свистнуть их и склонировать на другое устройство нельзя, но как оно в каждом конкретном девайсе - хз.

Идеально было бы, если бы производитель позволял в разлоченный загрузчик подгружать свои ключи, а не втихую игнорировать проверку. Но я таких телефонов вживую не видал (оно и на x86 раньше не в каждом UEFI можно было свои ключи для SecureBoot подкинуть)

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Если это LineageOS, то по идее загрузчик там УЖЕ разлочен

Это тоже не точно. Если спросить fastboot getvar all, то среди прочего нам дадут:

(bootloader) off-mode-charge: 1
(bootloader) warranty: no
(bootloader) unlocked: yes
(bootloader) secure: no
(bootloader) crc: 1
(bootloader) kernel: lk
(bootloader) product: begonia
(bootloader) is-userspace: no
(bootloader) slot-count: 0

У меня нету гарантии, оно разлочено, а остальное я не понимаю. По всей видимости у меня еще 0 слотов, потому и грузится ему нечем. Однако, если запустить MTK_Bypass, которая от друзей из Ньянмы, то там картинка другая:

► Installing driver... [OKAY]
► Waiting for brom... [FOUND]
  ● DETECT AS MediaTek USB Port (COM11)
► Configuration port... [OKAY]
► Handshaking... [OKAY]
► Retriving information... [OKAY]
  ● device hw code: 0x0813
  ● device hw sub code: 0x8a00
  ● device hw version: 0xca00
  ● device sw version: 0x0000
  ● sl auth: Yes
  ● da auth: Yes
► Reading configuration... [OKAY]
► Disabling watchdog timer... [OKAY]
► Disabling protection... [OKAY]

Не смотря за разлоченный загрузчик, тут есть 2 аутентификации. Но это я так понимаю, для BROM, а не для самого бутлоадера.

Так что сложно сказать, насколько девайс разлоченный.

ruzisufaka ★
() автор топика
Ответ на: комментарий от ruzisufaka

(bootloader) unlocked: yes

Обычно оно вот тут.

Собственно а ты что, не помнишь, как шил LineageOS? Там наверняка есть шаг по разлочке загрузчика.
Или девайс шел с уже предустановленной?

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Или девайс шел с уже предустановленной?

Девайс пришел с Aliexpress уже анлокнутый, я было приготовился сосать проприетарные утилиты и привязывать симкарты, даже отдал телефон левым людям на месяц, но оказалось что это был перешитый китаец на глобальную прошивку. LineageOS был зашит 2 командами в fastboot.

ruzisufaka ★
() автор топика
Ответ на: комментарий от Pinkbyte

А, пардоньте, не заметил, что там уже LOS.

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

Для этого нужен универсальный стандарт, такой как UEFI и TPM, плюс принуждающая к соблюдению сила, такая, как, простите, Microsoft, которая предъявляет подобные требования для сертификации железа. Правда, я не уверен, что они, например, требуют давать возможность загрузки своего PK (как требует предоставлять возможность отключения SB вообще), но не суть. Разве что Google однажды дозреет до этого, но это вряд ли будет очень скоро.

anonymous
()
Ответ на: комментарий от ruzisufaka

Теперь понятнее. TWRP можно не шить, насколько я помню, в fastboot была команда для прямой загрузки с нужным рекавери. Это позволит избежать лишней записи. А потом уже считать данные с раздела. Выдернуть ключ, как я понимаю, не выйдет, но это не точно.

anonymous
()
Ответ на: комментарий от anonymous

Теперь понятнее. TWRP можно не шить, насколько я помню, в fastboot была команда для прямой загрузки с нужным рекавери

Вообще, прошивка TWRP помогла. Со второй попытки. Оригинал с официального сайта загрузить не смог, зато васяносборка с 4pda завелась и даже со второго раза смогла смонтировать раздел. Вроде бы данные слил, но…

https://a.cockfile.com/RbBAaV.gif (смешная гифка)

По поводу команды fastboot boot, то пишут, что на Ксяомах она забагована и толком не работает, надо именно что шить.

Еще мне по пути сказали, что ключи на Медиатеках лежат в разделе metadata, а там у меня 32 мегабайта нулей. Или вычитывание прошло некорректно, или на самом деле оно лежит где-то еще.

ruzisufaka ★
() автор топика

Итак, история успеха.

Как поднять телефон из бутлупа и слить данные? Нам понадобятся следующие амулеты:

  1. MTK_Bypass (и его зависимости в виде USBDK + LibUSB) и по всей вероятности виндовые драйверы, подписанные Медиатеком (у меня телефон на MT6785). Само собой, все под оффтопиком, как бы это было под онтопиком даже представить страшно, мне цирка и так хватило.
  2. SP Flash Tool версии 5 (не 6!), бралась в виде васяносборочки под MT6785
  3. Android platform tools (использовались сразу под оффтопиком и онтопиком)
  4. Васяносборочка TWRP под мой телефон, официальная не завелась

Что делать?

  1. Запускаем сплойт под процессор, снимаем защиту
  2. Через SP Flash Tool сливаем разделы для успокоения своих нервов (они не понадобятся в случае успеха) 2.1. Так как у меня все не как у людей, то в процессе слива у меня постоянно вылезал STATUS_READ_DATA_EXCEPTION (0xC0050007), что лечат перетыканием кабелей или другим компьютером. У меня других компьютеров мало, потому пишем на Перле небольшой скриптик и разрезаем большой userdata на кучу мелких файлов по 1gb и спокойно сливаем данные.
  3. Идем в fastboot, в моем случае это картинка с зайцем, шьем васяносборочку на место рекавери: fastboot flash recovery vasyan.img
  4. Монтируемся в RW (увы, при монтировании ему надо покакать новыми ключами на раздел, потому монтирование в RO не прокатывает), в этот момент оно радостно расскажет что сумело расшифровать раздел и поднимает MTP. Если нету неприязни, можно скачивать свои порнофоточки.
  5. Принудительно идем в Mount->Disable MTP, выключаем тем самым MTP, чтобы поднялся adb обратно. Пытаемся слить данные через adb pull /data .

5.1. У меня опять все не как у людей, под оффтопиком оно не может записать слишком длинные имена, но успело слить 20 гигов порнофоточек

5.2. Под онтопиком adb у меня максимально калечный и скачивание файлика в 5 гигов доходило до 300%, после чего умирало, ссылаясь на слишком большой файл.

5.3. Делаем adb shell 'tar czk /data/ | base64' | base64 -d | tar xzv и смотрим кино. Да, медленно, но все слилось в лучшем виде.

  1. В моем случае в логах оно ругалось на set_policy_failed:/data/bootchart, удаление этой директории не помогло
  2. Идем в TWRP и в разделе WIPE вытираем основные разделы, делая свайп до Factory Reset. После чего телефон будет девственно-новым, но со старым паролем и порнофоточками на /sdcard/
  3. Ребутаемся и инсталлим все приложения:
cd backup/data
find app | grep base.apk | xargs -n1 adb install

Это как устанавливать сразу все игры, но приложения.

  1. Так как все приложения тоже девственно чистые, то восстанавливаем их состояние:
adb root (если не прокатит, то в настройках девелопера включить галочку)
adb push data/org.ligi.fast/ /data/data/ # зальет данные приложения org.ligi.fast в /data/data/ (слеши на конце ОБЯЗАТЕЛЬНЫ)Э

Или все сразу:
find app | grep base.apk | cut -d/ -f2 | cut -d- -f1 | sort -u > /dev/shm/apps
cat /dev/shm/apps | while read aa; do adb push data/"$aa"/ /data/data/;done
  1. Настройки самом системы лежат в /data/system/ в виде кучи XML, так что мержить не рискнул, все настроил ручками, благо все приложения уже настроены.

Enjoy

ruzisufaka ★
() автор топика
Ответ на: комментарий от ruzisufaka

Добавлю:

После восстановления данных через

adb push data/<PACKAGE_ID>/ /data/data/

Файлы принадлежат пользователю root, что может создать проблемы. У меня вот коллекция игр https://f-droid.org/en/packages/name.boyle.chris.sgtpuzzles/ работала, но отказывалась начинать новые игры. Проблема выглядит вот так:

# stat /data/data/name.boyle.chris.sgtpuzzles/puzzlesgen
  File: /data/data/name.boyle.chris.sgtpuzzles/puzzlesgen
  Size: 10224    Blocks: 32      IO Blocks: 512 regular file
Device: 1031eh/66334d    Inode: 311417   Links: 1
Access: (0777/-rwxrwxrwx)       Uid: (    0/    root)   Gid: (    0/    root)

Смотрим кто есть кто:

# stat /data/data/name.boyle.chris.sgtpuzzles/
  File: /data/data/name.boyle.chris.sgtpuzzles/
  Size: 4096     Blocks: 16      IO Blocks: 512 directory
Device: 1031eh/66334d    Inode: 311300   Links: 6
Access: (0700/drwx------)       Uid: (10177/ u0_a177)   Gid: (10177/ u0_a177)

Чиним:

begonia:/ # chown u0_a177:u0_a177 /data/data/name.boyle.chris.sgtpuzzles/puzzlesgen

Можно починить всю директорию или как вам больше нравится.

Очевидный пост очевиден, на сайте о линуксе даже стыдно как-то такое писать, но дополнил на тот случай, если кто-то через 1000 лет наткнется на этот же пост и захочет восстановить свой трупик.

ruzisufaka ★
() автор топика
← OpenNebula шаблон не переписывает настройки Virtual Networks
Admin
DHCP не обновляет BIND9 →