Exynos 990 / Exynos9830 Unified BootROM Exploit

Unified CVE-2024-56426 tooling for the Exynos 990 Galaxy S20, S20 FE, and Note20 families. The exploit accepts all ten model names and maps them onto six verified stock bootloader families.

[!CAUTION] The tracked key bundle and generated images are fusing-capable. Fusing is irreversible. A phone fused to a key can only boot images compatible with that key. A wrong model, rollback revision, patch set, or key bundle can leave the device in a fused boot loop. Use development keys and the UFS payload while iterating. Add --no-fuse to every preparation/signing command unless custom-key fusing is explicitly intended.

Supported Models

The selected model controls both the BL1 model ID and the exact-model LK patch TSV. Runtime artifact controls which stock firmware and encrypted split images are used by preflight. The four non-5G flags that use paired 5G runtime artifacts also patch LK's model-ID check and model-ID programming path.

Model flag	Runtime artifact	Runtime firmware	Model ID	EVT	Rollback	Tested
`G780F`	`G780F`	`G780FXXSOFYJ1`	`0x154`	`11`	`24`	❌
`G980F`	`G981B`	`G981BXXSNHYB1`	`0x143`	`11`	`23`	✅
`G981B`	`G981B`	`G981BXXSNHYB1`	`0x13D`	`11`	`23`	❌
`G985F`	`G986B`	`G986BXXSNHYB1`	`0x142`	`11`	`23`	✅
`G986B`	`G986B`	`G986BXXSNHYB1`	`0x13C`	`11`	`23`	✅
`G988B`	`G988B`	`G988BXXSNHYB1`	`0x13E`	`11`	`23`	❌
`N980F`	`N981B`	`N981BXXSIHYH3`	`0x153`	`11`

Exynos 990 KVM and EL2 mode

All ten supported Galaxy S20, S20 FE, and Note20 model flags have an opt-in CLI-only KVM boot profile. Build a branch of the Exynos 990 kernel whose name contains kvm, and add --kvm to the exact-model command, for example:```bash python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm

Этот профиль удаляет путь LK H-Arx/UH, просит EL3 войти в ядро на уровне EL2 и применяет соответствующую
таблицу патчей монитора EL3 (расшифрованную/повторно зашифрованную). Он остаётся недоступным для режимов прошивки
стокового/модифицированного загрузчика. Веб-центр управления намеренно не имеет управления KVM. С соответствующим ядром
и [WindowsInQemu](https://github.com/Creeeeger/WindowsInQemu) Windows может работать в QEMU на телефоне на полной скорости
через KVM.

## Быстрый старт

Не рассматривайте каждый режим как одну нумерованную последовательность установки. Выберите цель:

| Цель                              | Путь                                                                                                                     |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| Установить подписанную кастомную прошивку | Точная модель/конфигурация → EUB → временная цепочка `--signed --no-fuse` → прошивка полного подписанного вывода прошивки → первая загрузка UFS |
| Протестировать эксплойт           | Опционально `--prepare --no-fuse` → EUB → `--signed --no-fuse` → остановка                                               |
| Разработка цепочки загрузки (только CLI) | Временный тест no-fuse → сборка → прошивка сгенерированных SBoot/TZSW/LDFW → UFS                                                   |
| Дамп / восстановление             | Используйте отдельный рабочий процесс и проверки состояния предохранителей                                                                          |

`--prepare` — это рекомендуемый пробный запуск, а не обязательный предшественник: `--signed`
повторяет предварительную проверку. Сгенерированная трёхчастная команда Heimdall — это инструмент разработки цепочки загрузки; это не прошивка кастомной
прошивки.

Прочитайте [USER_GUIDE.md](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/USER_GUIDE.md) и выберите соответствующий рабочий процесс перед тем, как касаться устройства. Он включает
передачу полной прошивки, а также правила восстановления для состояний без предохранителей, с предохранителями и с неопределённым состоянием.

## Опциональный локальный интерфейс

Браузерный интерфейс использует только стандартную библиотеку Python и вызывает существующий
CLI `exploit/exploit.py`. Разработка цепочки загрузки и её сгенерированная трёхчастная команда Heimdall остаются инструментами
только для терминала.

Запустите его из корня репозитория:```bash
python3 exynos990_control_center.py

The launcher binds to 127.0.0.1, generates a new access token, prints the full local URL, and opens it in the default browser. Use --no-browser when a browser should not be opened automatically:```bash python3 exynos990_control_center.py --no-browser

Интерфейс предоставляет:

- красно-зелёные проверки зависимостей и ресурсов репозитория;
- один глобальный выбор целевой модели и ровно два решения о перемычке: «Оставить без перемычки» или «Пережечь»;
- выбор рабочего процесса, который показывает и нумерует только шаги выбранного процесса;
- рабочие процессы установки ROM, проверки эксплойта, дампа BootROM и восстановления стоковой прошивки;
- действие точной модели с изменённым загрузчиком, которое проверяет UH и прошивает его в раздел BOOTLOADER с помощью Heimdall для входа в EUB;
- постоянное предупреждение о перемычке и настроенный отпечаток SHA-256 ключа/eFuse;
- карточку восстановления стоковой цепочки загрузки только без перемычки, недоступную после выбора «Пережечь»;
- вывод процесса в реальном времени, отмену и маркеры проверки на каждом этапе.

Также отображается уведомление о KVM Exynos 990 только для CLI, но намеренно не предоставляет опцию KVM и не передаёт `--kvm` ни в какое веб-действие.

Доступ к USB определяется правами процесса, запустившего центр управления. Настройте прилагаемые разрешения udev/драйвера перед его запуском. Интерфейс не запрашивает, не хранит и не передаёт учётные данные привилегий. Держите напечатанный URL токена в тайне и немедленно остановите сервер после использования.

Пользователи терминала могут игнорировать `exynos990_control_center.py`; все команды CLI, описанные ниже, остаются без изменений и полностью поддерживаются.

## Требования

Требуется Python 3.10 или новее.

Windows 10/11 (нативный PowerShell):```powershell
.\windows\setup.ps1
. .\windows\activate.ps1
python .\exploit\exploit.py --prepare --model G985F --no-fuse

Установка включает фиксированный нативный тулчейн AArch64, LZ4, Heimdall и виртуальное окружение репозитория, после чего собираются все полезные нагрузки. Драйвер BootROM WinUSB устанавливается только по явному согласию администратора, поскольку его самоподписанный сертификат от вышестоящего поставщика изменяет хранилища доверия машины. Полный процесс установки, установки драйвера, различия режима Download Mode, проверки и устранения неполадок описан в WINDOWS.md.

После активации Windows используйте python везде, где в остальных кроссплатформенных примерах указано python3.

Linux:```bash sudo apt-get update sudo apt-get install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu lz4

macOS:```bash
brew tap messense/macos-cross-toolchains
brew install aarch64-unknown-linux-gnu lz4

Структура репозитория

Предварительная проверка

Подготовка, подпись и режимы полезных нагрузок выполняют одну и ту же предварительную проверку с учётом модели:

Сопоставьте выбранную модель с её каноническим семейством артефактов.
Замените exploit/extra/images/<model>/ чистой копией нетронутых зашифрованных разделов.
Примените соответствующий TSV LK со строгой проверкой стоковых байтов. С --no-fuse сначала создайте рабочую копию TSV с отключёнными пятью строками фьюзов. С --kvm также включите строки LK, помеченные kvm, расшифруйте и пропатчите соответствующий TSV монитора EL3, а затем повторно зашифруйте его защищённую область.
Соберите mem.bin, loader.bin и Exynos990_boot_custom_key.bin.
Подтвердите, что EPBL и монитор EL3 зашифрованы, повторно шифруя только при необходимости.
Проверьте стоковые метаданные модели/EVT/номера отката FWBL1 и каждый футер отката Stage2 перед подписью.
Подпишите FWBL1 выбранным идентификатором модели и подпишите все компоненты Stage2 стоковой ревизией отката.
Проверьте каждую сгенерированную подпись Stage2 перед передачей по USB.

Процесс останавливается при первом несоответствии прошивки, патча, метаданных или подписи. Он никогда не патчит неизменяемые исходные каталоги на месте.

Режимы эксплуатации

Все команды требуют --model.

--no-fuse — это модификатор, а не отдельный режим. Он отключает пять определённых строк OTP пользовательского ключа при пересборке рабочего LK. Используйте его для каждой команды, которая подготавливает, отправляет или собирает цепочку разработки без фьюзов. Он не отменяет существующий фьюз.

CLI принимает модификатор с режимами UFS и dump, поскольку эти команды также выполняют предварительную проверку, но их USB-операции не передают пересобранный LK. Уже прошитый на телефоне LK определяет поведение фьюзов UFS. Следовательно, интерфейс намеренно не предлагает управление no-fuse для режимов UFS или дампа BootROM. Оба режима прошивки загрузчика отклоняют --no-fuse, поскольку они не выполняют патчинг или подпись LK.

--kvm также является модификатором. Он принимается с каждым рабочим процессом точной модели, который выполняет предварительную проверку. Строки KVM в TSV игнорируются, если этот флаг отсутствует, и веб-интерфейс никогда его не предоставляет.

Пример:```bash python3 exploit/exploit.py --signed --model N986B --no-fuse

Сгенерируйте соответствующий подписанный загрузчик без открытия USB:```bash
python3 exploit/exploit.py --build-sboot --model N986B --no-fuse

Команда пересобирает каталог образов модели из чистых исходных входных данных, применяет патч LK, подписывает и проверяет каждый компонент, объединяет sboot.bin, проверяет встроенные компоненты и хвост, а затем выводит его размер, SHA-256 и команду Heimdall, которая отправляет sboot.bin, подписанный tzsw.img и подписанный ldfw.img.

Только на устройстве, заведомо не распаянном (unfused), восстановите точную исходную цепочку загрузки из оригинального tar-архива BL выбранной модели:```bash python3 exploit/exploit.py --flash-stock --model N986B --wait

Команда извлекает только `sboot.bin.lz4`, `tzsw.img.lz4` и
`ldfw.img.lz4`, распаковывает их во временный каталог, проверяет, что все три выходных файла присутствуют и не пусты, и
выполняет одну операцию прошивки Heimdall. Временные файлы удаляются после завершения. `--no-reboot` и `--verbose` также
поддерживаются. Телефон уже должен находиться в совместимом с Heimdall режиме загрузки, а выбранная модель должна точно соответствовать
физическому устройству.

Это не восстанавливает Android, AP, модем, CSC, userdata или полный стоковый ROM. Никогда не запускайте это на устройстве с кастомным fused-ключом.
Такой телефон требует стокового ПО, повторно подписанного точным fused-ключом; пользовательский корень доверия остаётся
постоянным. Если состояние fuse неизвестно, остановитесь.

## Примечание по FRP / PERSISTENT Recovery

> [!CAUTION]
> Эта процедура предназначена только для устройства, которым вы лично владеете и
> которое уполномочены обслуживать. Использование её на чужом устройстве строго
> запрещено. Неверный путь к разделу может привести к необратимой потере данных или оставить
> устройство неспособным загрузиться. Сделайте резервную копию целевого раздела и проверьте его разрешённый
> путь к блочному устройству и размер перед записью чего-либо.

Этот репозиторий не удаляет автоматически защиту Factory Reset Protection (FRP). На устройствах, использующих
`PersistentDataBlockService` в Android, состояние FRP хранится в разделе, обычно называемом `PERSISTENT`. См.
[реализацию AOSP](https://android.googlesource.com/platform/frameworks/base/+/bc56632da95b/services/core/java/com/android/server/PersistentDataBlockService.java).

После того как цепочка эксплойтов загрузит кастомное recovery, предоставляющее `adb` и
`dd`, определите и сделайте резервную копию раздела. Не подставляйте угаданный числовой путь к блочному устройству:```bash
adb shell ls -l /dev/block/by-name/PERSISTENT
adb shell dd if=/dev/block/by-name/PERSISTENT of=/tmp/PERSISTENT.backup.img bs=4096
adb pull /tmp/PERSISTENT.backup.img

Только после того как резервная копия была извлечена, обнулите раздел и позвольте Android инициализировать новую структуру persistent-data-block:```bash adb shell dd if=/dev/zero of=/dev/block/by-name/persistent reboot

Этот метод проверен и работает, FRP удалён, и устройство разблокировано.

## Патчи LK

Выбор патча выполняется в соответствии с сопоставлением артефактов:```text
G780F -> lk_g780f_selected_patches.tsv
G980F -> lk_g980f_selected_patches.tsv  (applied to G981B LK)
G981B -> lk_g981b_selected_patches.tsv
G985F -> lk_g985f_selected_patches.tsv  (applied to G986B LK)
G986B -> lk_g986b_selected_patches.tsv
G988B -> lk_g988b_selected_patches.tsv
N980F -> lk_n980f_selected_patches.tsv  (applied to N981B LK)
N981B -> lk_n981b_selected_patches.tsv
N985F -> lk_n985f_selected_patches.tsv  (applied to N986B LK)
N986B -> lk_n986b_selected_patches.tsv

Проверьте TSV-файл на соответствие стандартному LK, не изменяя его:```bash python3 external/tools/apply_lk_patches.py
bootLoaderFiles/sbootSplitParts_original/G986B/lk.bin
external/ghidra/lk_g986b_selected_patches.tsv
--check

`external/ghidra/ApplyLkPatches.java` принимает тот же шестиколоночный TSV-формат и теперь завершается ошибкой при несовпадении старых байтов
вместо слепого применения патча. Строки, у которых первый столбец — `kvm`, требуют дополнительный аргумент скрипта `--kvm`.
Устаревшие строки `check_signature` и `check_ext4_signature` с возвратом нуля используют
профиль `0`: они документируют старые места обхода проверок, но намеренно не
применяются, поэтому собранные образы должны удовлетворять реальным проверкам подписи Samsung в LK.

## Подписание

`external/tools/sign_sboot_images.py` требует указания модели и извлекает ID модели, EVT и версию отката из
[model_data.py](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/external/tools/model_data.py):```bash
python3 external/tools/sign_sboot_images.py \
  --images-dir exploit/extra/images/G986B \
  --keys-dir external/keys/exynos9830_crecker \
  --model G986B

Подписи Stage2 проверяются после подписания. Инструмент не пересоздаёт метаданные Samsung AVB для ldfw.img или tzsw.img; изменение байтов secure-boot внутри этих обёрток по-прежнему требует отдельной политики AVB, используемой целевым загрузочным потоком. Полностью подписанный ROM должен использовать точную модель AVB и тот же набор ключей, а затем прошиваться вместе со своим полным сгенерированным пакетом. См. репозиторий CreckerROM и рабочий процесс установки в USER_GUIDE.md.

Изменённые загрузчики

Включённые изменённые пакеты сохраняют все штатные компоненты BL, кроме sboot.bin.lz4. Этот компонент удаляется, а распакованный uh.bin пакета сохраняется как sboot.bin, что соответствует раскладке, запускающей EUB.

Интерфейс может выполнять соответствующий поток Heimdall напрямую. Он выбирает изменённый архив точной физической модели, проверяет, что sboot.bin побайтно идентичен распакованному uh.bin.lz4, и прошивает проверенную полезную нагрузку UH в слот BOOTLOADER:```bash python3 exploit/exploit.py --flash-tampered --model G986B --wait

Это намеренно предотвращает обычную загрузку и принудительно переводит следующую загрузку в EUB. При этом остальные компоненты BL tar не прошиваются.

Перегенерируйте один пакет с помощью:```bash
python3 external/tools/build_tampered_loader.py \
  bootLoaderFiles/originalBl/G986B/BL_G986BXXSNHYB1.tar \
  bootLoaderFiles/tamperedLoader/G986B/BL_G986BXXSNHYB1_tampered.tar

Используйте точный модифицированный загрузчик физической модели, когда его каталог присутствует. Связанное сопоставление среды выполнения применяется к предварительной проверке эксплойта и подписи, а не к выбору архивного пакета BL (штатного/модифицированного).

Имейте в виду, что если вы прошили устройство, вам потребуется прошить подписанный uh.bin в ваш слот BOOTLOADER, поскольку штатный uh в настоящее время подписан неправильным ключом.

Инструменты анализа

Разделение и объединение:```bash python3 exploit/split.py sboot.bin -o /tmp/G986B-splits python3 exploit/merge.py /tmp/G986B-splits

Автономный модуль слияния требует наличия `tzsw.img` и `ldfw.img` в каталоге parts и выводит соответствующую трёхчастную
команду Heimdall. Используйте эту команду только в том случае, если эти два образа уже подписаны для выбранной модели;
`--build-sboot` выполняет и проверяет эту подпись автоматически.

Извлечение отдельных записей LDFW:```bash
python3 external/tools/extract_ldfw.py ldfw.img -o LDFWs

Предоставленная раскладка разделения восстанавливает каждый канонический стоковый sboot.bin байт-в-байт. Дешифрование/повторное шифрование EPBL и EL3 monitor также проходит байт-в-байт для всех семейств прошивок, когда заголовок EPBL остаётся без изменений.

Совместимость полезных нагрузок

Все поддерживаемые телефоны используют один и тот же BootROM Exynos 990. Полезные нагрузки используют общие точки входа BootROM и адреса IRAM, а не зависящие от модели смещения LK. Сгенерированные бинарные файлы разрешаются к этим точкам входа:

Поведение, зависящее от модели, ограничено TSV LK, идентификатором модели FWBL1 и стоковой ревизией отката.

Раскладка образа

Благодарности и указание авторства

Chimera Tool: самое раннее из известных обнаружений и практическое использование этого эксплойта, примерно в 2021–2022 годах.
Консультация Samsung по CVE-2024-56426: документирует уязвимость, используемую этим проектом.
Christopher Wade: сообщил о CVE-2024-56426 в Samsung.
Umer Uddin (halal-beef), через halal-beef/hubble: серверный код, используемый exploit/exploit.py; раскладка SoC, используемая exploit/split.py и exploit/merge.py; а также run_exploit(), реализующая операцию адресации/перезаписи.
VDavid003 (David), через VDavid003/exynos-usbdl: каркас полезной нагрузки, из которого была получена полезная нагрузка с пользовательским ключом Exynos990.

`bootLoaderFiles/originalBl/<model>/`	Чистые пакеты `BL_<firmware>.tar` точной модели для всех десяти моделей.
`bootLoaderFiles/sbootSplitParts_original/<model>/`	Нетронутые зашифрованные разделы SBoot точной модели: `ldfw.img`, `tzsw.img`, манифест и хвост.
`bootLoaderFiles/exynos9830Decrypted/<model>/`	Расшифрованные файлы анализа EPBL, EL3, TZSW и LDFW точной модели.
`bootLoaderFiles/tamperedLoader/<model>/`	Пакеты BL точной модели, вызывающие EUB.
`bootLoaderFiles/MODEL_COMPARISON.md`	Сравнение прошивок точной и связанной модели, а также заметки о совместимости патчей.
`bootLoaderFiles/exynos990Bootrom/`	Общий дамп BootROM Exynos 990.
`bootromNotes/`	Общие заметки о потоке BootROM и USB-контексте.
`drivers/windows/winusb/`	Зафиксированный пакет Houston WinUSB для BootROM/EUB `04e8:1234`.
`windows/`	Нативная настройка Windows, активация среды и установщик драйвера с проверкой хэша.
`exploit/extra/images/<model>/`	Одноразовые выходные данные предварительной проверки для конкретной модели.
`external/ghidra/`	TSV-файлы LK и KVM EL3 точной модели, а также скрипт патчинга Ghidra.
`external/decompiled_G985F/`	Декомпилированные справочные файлы только для G985F.
`exynos990reverseEng_G985F/`	Проект Ghidra только для G985F.
`external/keys/exynos9830_crecker/`	Общий набор пользовательских ключей.
`exploit/exploit.py`	Стабильная точка входа CLI и координатор рабочего процесса.
`exploit/build_payloads.py`	Кроссплатформенный сборщик нативных полезных нагрузок, используемый предварительной проверкой на Windows, Linux и macOS.
`exploit/preflight.py`	Подготовка рабочего образа, патчинг LK, подпись и проверка слияния.
`exploit/usb_transport.py`	Фрейминг PyUSB, обнаружение устройств, перезапись и транспорт дампа.
`exploit/tampered_loader.py`	Извлечение UH точной модели, проверка модифицированного загрузчика и EUB-прошивка Heimdall.
`exploit/stock_restore.py`	Извлечение стокового архива точной модели и построение команд Heimdall.
`control_center/`	Действия бэкенда браузера, проверки зависимостей, задания и HTTP API.
`external/tools/*_crypto.py`	Общие примитивы кодирования/подписи AES и ECDSA для EPBL/EL3.

`--prepare`	Запустить предварительную проверку без открытия USB.
`--build-sboot`	Запустить предварительную проверку и собрать проверенный подписанный `sboot.bin` в каталоге образа модели.
`--signed`	Отправить полезную нагрузку с пользовательским ключом и подписанную цепочку загрузки из EUB.
`--ufs`	Запустить путь загрузки UFS с `loader.bin`.
`--dump`	Запустить `mem.bin` и сбросить `0x20000` байт BootROM.
`--flash-tampered`	Проверить UH точной модели и прошить его в BOOTLOADER для принудительного EUB.
`--flash-stock`	Извлечь и прошить стоковые SBoot, TZSW и LDFW точной модели из исходного BL-архива.

`fwbl1.img`	Закрытый ключ BL1 плюс открытые блобы Stage2 TEE/REE
`epbl.img`, `el3_mon.img`	Stage2 TEE
`bl2.img`, `lk.bin`	Stage2 REE
`ldfw.img`, `tzsw.img`	Stage2 TEE, внутренний и внешний футеры Stage2

`mem.bin`	`0x02022010`	`0x02022010`
`loader.bin`	`0x02022010`	`0x02022010`
`Exynos990_boot_custom_key.bin`	`0x02022000`	позиционно-независимая стадия 1

`fwbl1.img`	`0x000000`	`0x003000`
`epbl.img`	`0x003000`	`0x016000`
`bl2.img`	`0x016000`	`0x082000`
`lk.bin`	`0x0DB000`	`0x35B000`
`el3_mon.img`	`0x35B000`	`0x39B000`

BL1	`0x02022000`
EPBL	`0x02026000`
BL2	`0x15600000`
LK	`0xE8000000`
EL3 monitor	`0xBFE80000`

CVE-2024-56426

Популярное