Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1000 CNY

100.0%

CVE-2022-21894 PoC — Microsoft Windows Secure Boot 安全特征问题漏洞

Source
Associated Vulnerability
Title:Microsoft Windows Secure Boot 安全特征问题漏洞 (CVE-2022-21894)
Description:Microsoft Windows Secure Boot是美国微软(Microsoft)公司的安全启动。 Microsoft Windows Secure Boot存在安全特征问题漏洞。以下产品和版本受到影响:Windows 10 Version 1809 for 32-bit Systems,Windows 10 Version 1809 for x64-based Systems,Windows 10 Version 1809 for ARM64-based Systems,Windows Serv
Description
An implementation of baton drop (CVE-2022-21894) for armv7 (MSM8960)
Readme
# baton drop for armv7 (MSM8960)

Given that policyhax (aka golden key)'s fix actually works on Qualcomm systems, I picked up a working but sold for-parts Dell XPS 10 to port baton drop to MSM8960.

Here is the result.

Extract image.7z to your GPT fat32-formatted USB device, copy your unsigned EFI boot application to \boot.efi, boot your MSM8960 Windows RT device with it, enjoy.

All payload src (including `divide.obj` from MS CRT, which stage2 requires), is included. For building, use an MSVC cross-compiler command prompt. Run `make_cert.bat` to create a self-signed cert, `build_mcupdate.bat` to build stage1, `build_stage2.bat` to build stage2, `build_boot.bat` to build the hello world `boot.efi`.

## Exploitation specifics
- Physical address cut off is at `0xA000_0000`. It could probably be set later if you wanted to just use baton drop for a UMCI jailbreak (when exploiting baton drop, advanced options menu shows nointegritychecks option); remember that on win8.x exploitation requires `osdevice` to be a BitLocker encrypted volume with key flag bit 0 set (can be set manually as is the case for `payload.vhd`, but is usually set for VMK sealed by TPM with secure boot for integrity validation).
  - Please note that setting the cut off to `0xC000_0000` works for baton drop to load a payload, but in a dual boot situation would cause NT to fail to boot.
- `hal.dll` has been patched to add `mcupdate.dll` to its imports, and self-signed.
- `mcupdate.dll` loads `efiesp:\stage2.dll` and `efiesp:\boot.efi`, obtains all pointers that stage2 needs and calls stage2 entrypoint.
- stage2:
  - calls `BlpArchSwitchContext` to switch back to firmware context to call EFI services
  - walks through the EFI memory map to free everything allocated by the Windows bootloaders (except for what stage1 loaded and the stack which points to memory allocated by bootmgr)
  - calls boot.efi entrypoint
- Any error (or boot.efi returning) will lead to infinite loop.

File Snapshot

[4.0K] /data/pocs/6a4d8bf46dbe42577863279f10d150dac78b882d ├── [1.2K] LICENSE.txt ├── [1.9K] README.md └── [4.0K] src ├── [ 573] boot.c ├── [ 107] build_boot.bat ├── [ 167] build_mcupdate.bat ├── [ 117] build_stage2.bat ├── [8.2K] divide.obj ├── [ 285] make_cert.bat ├── [5.6K] mcupdate.c └── [3.8K] stage2.c 1 directory, 10 files
Shenlong Bot has cached this for you
Remarks
    1. It is advised to access via the original source first.
    2. If the original source is unavailable, please email f.jinxu#gmail.com for a local snapshot (replace # with @).
    3. Shenlong has snapshotted the POC code for you. To support long-term maintenance, please consider donating. Thank you for your support.