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:

This profile removes the LK H-Arx/UH path, asks EL3 to enter the kernel at EL2, and applies the matching decrypted/re-encrypted EL3 monitor patch table. It remains unavailable for stock/tampered bootloader flash modes. The web control center intentionally has no KVM control. With the matching kernel and WindowsInQemu, Windows can run in QEMU on the phone with full speed via KVM.

Quick Start

Do not treat every mode as one numbered installation sequence. Choose a goal:

--prepare is a recommended dry-run, not a required predecessor: --signed repeats preflight. The generated three-part Heimdall command is a boot-chain development tool; it is not a custom-ROM flash.

Read USER_GUIDE.md and choose its matching workflow before touching a device. It includes the complete-ROM handoff plus the unfused, fused, and uncertain-state recovery rules.

Optional Local UI

The browser UI uses only Python's standard library and calls the existing exploit/exploit.py CLI. Boot-chain development and its generated three-part Heimdall command remain terminal-only tools.

Start it from the repository root:

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:

The UI provides:

• red/green dependency and repository-asset checks;
• one global target-model choice and exactly two fuse decisions: Stay unfused or Fuse;
• a workflow chooser that shows and numbers only the selected workflow's steps;
• install-ROM, exploit-test, BootROM-dump, and stock-recovery workflows;
• an exact-model tampered-loader action that validates UH and flashes it to the BOOTLOADER slot with Heimdall to enter EUB;
• a permanent fuse warning and the configured key/eFuse SHA-256 fingerprint;
• an unfused-only stock boot-chain restore card that is unavailable after choosing Fuse;
• live process output, cancellation, and per-stage verification markers.

It also shows a CLI-only Exynos 990 KVM notice, but deliberately does not expose a KVM option or forward --kvm to any web action.

USB access follows the permissions of the process that launched the control center. Configure the supplied udev/driver permissions before starting it. The UI does not request, retain, or forward privilege credentials. Keep the printed token URL private and stop the server immediately after use.

Terminal users can ignore exynos990_control_center.py; every CLI command documented below remains unchanged and fully supported.

Requirements

Python 3.10 or newer is required.

Windows 10/11 (native PowerShell):

The setup installs a pinned native AArch64 toolchain, LZ4, Heimdall, and a repository virtual environment, then builds all payloads. The BootROM WinUSB driver is an explicit Administrator opt-in because its upstream self-signed certificate changes the machine trust stores. See WINDOWS.md for the complete setup, driver install, Download Mode distinction, verification, and troubleshooting process.

After Windows activation, use python wherever the remaining cross-platform examples show python3.

Linux:

macOS:

Repository Layout

Preflight

Preparation, signing, and payload modes run the same model-aware preflight:

1. Resolve the selected model to its canonical artifact family.
2. Replace exploit/extra/images/<model>/ with a clean copy of the untouched encrypted split images.
3. Apply the matching LK TSV with strict stock-byte checks. With --no-fuse, generate an effective TSV copy with the five fusing rows disabled first. With --kvm, also enable the LK rows marked kvm, decrypt and patch the matching EL3 monitor TSV, and re-encrypt its protected region.
4. Build mem.bin, loader.bin, and Exynos990_boot_custom_key.bin.
5. Confirm that EPBL and EL3 monitor are encrypted, re-encrypting only when necessary.
6. Validate stock FWBL1 model/EVT/rollback metadata and every Stage2 rollback footer before signing.
7. Sign FWBL1 with the selected model ID and sign all Stage2 components with the stock rollback revision.
8. Verify every generated Stage2 signature before USB transfer.

The process stops on the first firmware, patch, metadata, or signature mismatch. It never patches the immutable source directories in place.

Exploit Modes

All commands require --model.

--no-fuse is a modifier, not a standalone mode. It disables five identified custom-key OTP rows while rebuilding the working LK. Use it for every command that prepares, sends, or builds an unfused development chain. It does not undo an existing fuse.

The CLI accepts the modifier with UFS and dump modes because those commands also run preflight, but their USB operations do not transmit the rebuilt LK. The LK already flashed on the phone determines UFS fuse behavior. Consequently, the UI deliberately offers no no-fuse control for UFS or BootROM dump mode. Both bootloader flash modes reject --no-fuse because they perform no LK patching or signing.

--kvm is also a modifier. It is accepted with every exact-model workflow that runs preflight. KVM rows in the TSVs are ignored unless this flag is present, and the browser UI never supplies it.

Example:

Generate the corresponding signed bootloader without opening USB:

The command rebuilds the model image directory from clean stock inputs, applies the LK patch, signs and verifies every component, merges sboot.bin, checks the embedded components and tail, and prints its size, SHA-256, and a Heimdall command that sends sboot.bin, signed tzsw.img, and signed ldfw.img.

Only on a device known to be unfused, restore the exact stock boot chain from the selected model's original BL tar:

The command extracts only sboot.bin.lz4, tzsw.img.lz4, and ldfw.img.lz4, decompresses them in a temporary directory, verifies all three outputs are present and non-empty, and invokes one Heimdall flash operation. The temporary files are removed afterward. --no-reboot and --verbose are also supported. The phone must already be in a Heimdall-compatible download mode, and the selected model must exactly match the physical device.

This does not restore Android, AP, modem, CSC, userdata, or a complete stock ROM. Never run it on a custom-key-fused device. Such a phone requires stock-based software re-signed with the exact fused key; the custom trust root remains permanent. If fuse state is unknown, stop.

FRP / PERSISTENT Recovery Note

[!CAUTION] This procedure is only for a device that you personally own and are authorized to service. Using it on another person's device is strictly prohibited. A wrong partition path can cause permanent data loss or leave the device unable to boot. Back up the target partition and verify its resolved block-device path and size before writing anything.

This repository does not automatically remove Factory Reset Protection (FRP). On devices that use Android's PersistentDataBlockService, FRP state is stored in the partition commonly named PERSISTENT. See the AOSP implementation.

After the exploit chain has booted a custom recovery that provides adb and dd, identify and back up the partition. Do not substitute a guessed numeric block-device path:

Only after the backup has been pulled, zero the partition and let Android initialize a fresh persistent-data-block structure:

This method is tested and works, FRP is removed and the device is unlocked.

LK Patches

Patch selection follows the artifact mapping:

Validate a TSV against stock LK without changing it:

external/ghidra/ApplyLkPatches.java accepts the same six-column TSV format and now fails on old-byte mismatches instead of applying a patch blindly. Rows whose first column is kvm require an additional --kvm script argument. The legacy check_signature and check_ext4_signature return-zero rows use profile 0: they document the old bypass locations but are deliberately not applied, so built images must satisfy LK's real Samsung signature checks.

Signing

external/tools/sign_sboot_images.py requires a model and derives the model ID, EVT, and rollback revision from model_data.py:

The Stage2 signatures are verified after signing. The tool does not regenerate Samsung AVB metadata for ldfw.img or tzsw.img; changing secure-boot bytes inside those wrappers still requires the separate AVB policy used by the target boot flow. A complete signed ROM must use the exact AVB model and the same key bundle, then be flashed with its complete generated package. See the CreckerROM repository and the installation workflow in USER_GUIDE.md.

Tampered Loaders

The included tampered packages preserve every stock BL member except sboot.bin.lz4. That member is removed and the package's decompressed uh.bin is stored as sboot.bin, matching the EUB-triggering layout.

The UI can perform the corresponding Heimdall flow directly. It selects the exact physical model's tampered archive, verifies that sboot.bin is byte-identical to decompressed uh.bin.lz4, and flashes the validated UH payload to the BOOTLOADER slot:

This intentionally prevents normal boot and forces the next boot into EUB. It does not flash the remaining members of the BL tar.

Regenerate one package with:

Use the exact physical model's tampered loader when its directory is present. The coupled runtime mapping applies to exploit preflight and signing, not to the archived stock/tampered BL package selection.

Keep in mind that if you fused the device, you will need to flash a signed uh.bin to your BOOTLOADER slot, since the stock uh is currently signed with the wrong key.

Analysis Tools

Split and merge:

The standalone merger requires tzsw.img and ldfw.img in the parts directory and prints the corresponding three-part Heimdall command. Only use that command when those two images have already been signed for the selected model; --build-sboot performs and verifies that signing automatically.

Extract individual LDFW records:

The supplied split layout reconstructs every canonical stock sboot.bin byte-for-byte. EPBL and EL3 monitor decrypt/re-encrypt also round-trip byte-for-byte for all firmware families when the EPBL header is left unchanged.

Payload Compatibility

All supported phones share the same Exynos 990 BootROM. The payloads use common BootROM entry points and IRAM addresses rather than model-specific LK offsets. The generated binaries resolve to these entry points:

Model-specific behavior is confined to the LK TSV, FWBL1 model ID, and stock rollback revision.

Image Layout

Credits and Attribution

• Chimera Tool: earliest known discovery and practical use of this exploit, circa 2021–2022.
• Samsung's CVE-2024-56426 advisory: documents the vulnerability used by this project.
• Christopher Wade: reported CVE-2024-56426 to Samsung.
• Umer Uddin (halal-beef), through halal-beef/hubble: the backend code used by exploit/exploit.py; the SoC layout used by exploit/split.py and exploit/merge.py; and run_exploit(), which implements the address/overwrite operation.
• VDavid003 (David), through VDavid003/exynos-usbdl: the payload skeleton from which the Exynos990 custom-key payload was derived.