ncxcy/A15-SECUREROM-VULNS: secureROM t8110 (A15) Reverse eng list of vulns

Target: SecureROM for t8110si, iBoot-6338.0.0.200.19 Load base: 0x100000000 File size: 0x100000 bytes (1MB) Device: iPhone 14 (D27AP), CPID:8110, CPFM:03

[!IMPORTANT] Claude code was used for documenting markdown not for reverse engineering, and im posting this as RESEARCH, i hope this is helpfull for someone building their own tool for bypassing activation lock / building jailbreak tool from this and if you publish some kind of tools you must put my creds if you are used any of these vulnerabilities from here. now focusing on finding vulnerabilities (vulnerabilities are confirmed by coding PoC's (will be uploaded)).

1. Security Posture

Critical: All 4 DFU slot dispatch functions (0x100014544, 0x10001457c, 0x1000145b4, 0x1000145ec) use AUTIBSP + BRAAZ X0. No unauthenticated dispatch path exists through the slot table

2. SRAM Layout - Complete Field Map

Buffer base: 0x1FC022000 (DFU download buffer, 0x800 bytes)

Inside the DFU buffer (0x000 – 0x7FF) - key fields:

Gap (0x800 – 0xDAF) - USB DMA region

USB / DFU control block (0xCB0 – 0xDA8):

3. Confirmed Vulnerabilities

VULN-01 - DFU TOCTOU Race (Confirmed, fires iter 0 every run)

Handler: 0x10001412C (dfu_control_request_handler) Race window: Between DFU_DNLOAD SETUP (stores wLength at 0xD90/D98) and OUT data phase Trigger: DFU_ABORT resets bytes_received (0xD8C) to 0, leaves wLength stale Effect: USB hardware delivers OUT data; callback checks bytes_received(0) + len ≤ limit > passes > memcpy runs starting at da0+0, overflowing past buf_end Reliability: 100% - fires on iter 0, 2-3 aborts, every run

VULN-02 - Memory Write Primitive via da0 Overflow

Mechanism: TOCTOU race causes memcpy to write attacker payload starting at da0+0, extending past 0x1FC022800 (buf_end) by 0x5A8 bytes Range check: sub_10000AB5C - bypassed entirely on CPFM:03 (bypass flag at 0x1FC0218E6 bit 0 = 1) Limitation: sub_100013FD0 resets da0 on every DFU SETUP before data arrives

VULN-03 - Re-init Skip via 0x570 / 0x580 flags

Discovery: IDA decomp of sub_10000C440 and sub_10000C4B4 Mechanism:

• buf[0x570] = 1 > sub_10000C440 skips dfu_endpoint_setup (da0 not reset by re-init)
• buf[0x580] = 1 > sub_10000C4B4 skips sub_10000C2B8 (da0 not reset by event loop) Effect: da0 = rsa_pkcs1_verify survives across USB events and re-enumeration

VULN-04 - rsa_pkcs1_verify Data-Write Patch

Target: sub_100024730 (rsa_pkcs1_verify) Confirmed: Calls sub_100024BBC (Montgomery exp) + sub_1000253C0 (PKCS1 pad check) Patch: Write MOV W0,#0 + RET (8 bytes: 00 00 80 D2 C0 03 5F D6) to 0x100024730 Effect: Every RSA signature check returns 0 (success) > ROM accepts any binary

VULN-05 - Range Check Bypass Flag (CPFM:03)

Address: 0x1FC0218E6 bit 0 Confirmed: sub_10000AB60 checks this first - if set, all range validation skipped Status on device: Always 1 (CPFM:03 = development fused) Effect: da0 can point to ROM (0x100024730) and memcpy will write there - no DRAM range restriction

4. Key Function Map

5. DFU Control Flow (Confirmed)

Power on > dfu_init (0x10000C440)
  > sub_100012A84 (USB device setup)
  > sub_100012F70 ("Apple Mobile Device (DFU Mode)")
  > sub_100014054 (dfu_endpoint_setup)
       > sub_10000C6D4(1) > da0 = alloc_base
       > allocates 0x800-byte download buffer
       > registers control + data callbacks
  > sub_1000130F4 (USB descriptor setup)
  > MEMORY[0x1FC022570] = 1

Event loop: sub_10000C4B4 (called from sub_10001A63C)
  > if 0x580 == 0: sub_10000C2B8 (re-init pool) > resets da0
  > sub_10000C25C (nonce setup)
  > v0 = MEMORY[0x588] or sub_100010F5C/sub_100019C4C
  > v1 = v0(nonce)
  > sub_10000C440(v1):
       > if MEMORY[0x570] & 1 == 0: dfu_endpoint_setup > resets da0
       > else: SKIP (da0 preserved)

DNLOAD SETUP > sub_100014130:
  > wLength ≤ 0x800 accepted
  > sub_100013FD0(new_buf, 0x800, 0):
       > MEMORY[0xDA0] = new_buf  < RESETS da0
       > MEMORY[0xD84] = 0x800
       > spins while MEMORY[0xD80] == 0
       > sub_10000C54C > teardown if 0x570==1

DNLOAD DATA > sub_1000142E4:
  > sub_10000AB5C(da0 + bytes_received, len):
       > if 0x1FC0218E6 & 1: return 1 (bypass - always on CPFM:03)
  > memcpy(da0 + bytes_received, ep_buf, len)
  > bytes_received += len

6. Exploit Chain (Current State)

What works:

• Race fires iter 0 every time (100% reliability)
• 0x570=1 + 0x580=1 flags suppress re-init
• 0xD80=1 prevents spin-wait crash
• da0 overflow to 0x100024730 is correct

Current blocker:

sub_100013FD0 at line MEMORY[0xDA0] = new_buf - called by the DNLOAD SETUP handler for stage 2 - resets da0 before the data arrives. Stage 2 DNLOAD SETUP triggers this, which means da0 is overwritten before our 8-byte patch goes through the callback.

Possible fixes (to research):

Fix A - Send stage 2 data WITHOUT a SETUP (inject raw OUT) USB protocol normally requires SETUP before data. Possible with raw libusb async - submit an OUT transfer to endpoint 0 without sending SETUP first. If the USB controller has buffered data from the previous race, the callback fires with da0 still = rsa_verify.

Fix B - Overflow wLength storage (0xD90) to skip sub_100013FD0 If 0xD90 (wLength) still matches the stage 2 transfer length, sub_100014130 may skip calling sub_100013FD0 entirely for certain state machine values. Needs state machine analysis.

Fix C - Use CLRSTATUS zero-write to zero sub_100013FD0's new_buf store DFU_CLRSTATUS computes ptr = da0 + (bytes_received - 0x10) and writes 16 zero bytes. If da0 = rsa_verify and bytes_received = 0x10, writes zeros at rsa_verify+0 - which IS MOV X0,X0 + NOP (not a return). Not directly useful but shows another write path.

Fix D - Use DFU_MANIFEST state to trigger execution After a complete DNLOAD sequence, ROM enters dfuMANIFEST and attempts to execute the downloaded payload. If our overflow payload is crafted to be a valid (unsigned) iBSS binary, and RSA is already patched, it may execute directly.

Fix E - Patch a different target that sub_100013FD0 doesn't reset Instead of da0, find a SRAM location written AFTER sub_100013FD0 runs that we can control. Candidates:

• 0xD82 (DFU state machine) - written by sub_100014130 after SETUP
• 0xD84 (size limit) - written by sub_100013FD0 itself
• 0xCCC (interface count) - read by sub_1000130F4, if 0 > returns -1 > triggers alt path

Fix F - Pre-position patch bytes using TOCTOU overflow directly The race itself delivers 0x800 bytes starting at da0+0. After the race, da0 is still = rsa_verify until sub_100013FD0 runs. The race already wrote buf[0..0x7FF] to SRAM at 0x1FC022000. If we position the RSA patch bytes at offset (rsa_verify - da0_real) within the overflow payload, and rsa_verify is reachable that way... but rsa_verify (0x100024730) < da0_real (0x1FC022000+), so the offset wraps. Not directly reachable.

Fix G - Two-stage TOCTOU: race again during stage 2 Run the race again while stage 2 is connected. Race fires > bytes_received reset > da0 still = rsa_verify (0x570/0x580 flags still set) > stage 2's data callback fires > patch lands. The stage 2 thread is already polling - if the race re-fires during stage 2's DNLOAD, it might work.

7. Image4 / Signature Validation Chain

img4_validate_manifest (sub_100006324)
  > sub_10000ABD4: check 0x1FC0218E6 bit 6 (security state)
  > if development (CPFM:03): relaxed validation

FUN_1000244D0 (RSA/ECDSA dispatch)
  > loads fn ptr from crypto vtable at 0x100030940
  > 0x100030940 = 0x100024730 (rsa_pkcs1_verify)
  > vtable in ROM - cannot be patched via overflow

Image4 validator chain:
  FUN_10002394C > FUN_100023A88 > FUN_100024BBC
  > rsa_pkcs1_verify (0x100024730) - PATCH TARGET

8. Additional Checks Found

Check 1 - CCC (interface count) gate in sub_1000130F4

if (MEMORY[0x1FC022CCC] == 0) return 0xFFFFFFFF;

If overflow zeros 0xCCC (buf+0xCCC = 0xCCC), sub_1000130F4 returns -1 > sub_10000C440 calls sub_10000C428 > DFU fails to initialize. Must keep 0xCCC non-zero. Offset 0xCCC is past our OVFL_TOTAL (0xDA8) so currently safe.

Check 2 - D81 flag in sub_100014054

if (MEMORY[0x1FC022D81] == 1) return 0;  // already initialized, skip

If 0xD81 = 1, dfu_endpoint_setup returns immediately without resetting da0. buf[0xD81] = 1 would prevent dfu_endpoint_setup from resetting da0. Offset 0xD81 is within OVFL_TOTAL (< 0xDA8). This is a new unexplored approach.

Check 3 - 0x534 USB active gate in sub_10000BB64

if (MEMORY[0x1FC022534] == 0) return sub_10000BAF0(a1, -1);

Must be non-zero for USB event processing. buf+0x534 is inside the DFU buffer - calloc zeroes it. But it's set by sub_10000AF98 during USB init and restored on re-enumeration. May need buf[0x534] = 1.

Check 4 - wLength bounds in dfu_control_request_handler

if (wLength < 0x801) > accepted (wLength ≤ 0x800)
if (wLength ≥ 0x801) > error (wLength 0x801-0xFFFF rejected)

Maximum per-DNLOAD is 0x800 bytes. The race causes overflow not by exceeding wLength but by resetting bytes_received mid-transfer.

Check 5 - D82 state machine in CLRSTATUS path

if (MEMORY[0x1FC022D82] != '\a') goto error;  // must be dfuMANIFEST (7)
ptr = da0 + (bytes_received - 0x10);
*ptr = 0; *(ptr+8) = 0;  // 16-byte zero write

DFU_CLRSTATUS zero-write only fires in dfuMANIFEST state. Could write 16 zeros anywhere da0 points, at offset bytes_received-0x10.

9. Most Promising Unexplored Finding

buf[0xD81] = 1 - dfu_endpoint_setup skip flag

From sub_100014054 (dfu_endpoint_setup):

if (MEMORY[0x1FC022D81] == 1) return 0;  // already init - SKIP EVERYTHING

If the overflow sets buf[0xD81] = 1:

• da0 is NOT reset (dfu_endpoint_setup returns immediately)
• USB endpoint buffer is NOT reset
• All other fields remain as-is

This is different from 0x570 and 0x580:

• 0x570 prevents the outer re-init call from sub_10000C440
• 0x580 prevents pool re-init from sub_10000C4B4
• 0xD81 prevents dfu_endpoint_setup itself - the deepest guard

And crucially: sub_100013FD0 does NOT check 0xD81. sub_100013FD0 resets da0 regardless. But if 0xD81=1, the USB endpoint is not re-registered on re-enumeration. The device may not enumerate properly. Needs testing.

Combined flag strategy for next run:

buf[0x534] = 1;   // USB active flag - keeps event loop running
buf[0x570] = 1;   // outer re-init skip
buf[0x580] = 1;   // pool re-init skip
buf[0xD80] = 1;   // DFU state byte - prevents spin-wait
buf[0xD81] = 1;   // dfu_endpoint_setup skip - NEW, prevents da0 reset
                  // from re-enumeration path
buf[0xDA0..0xDA7] = 0x100024730  // da0 > rsa_pkcs1_verify

The key question: does sub_100013FD0 still reset da0 when called from the stage 2 DNLOAD SETUP? Yes - it does. The 0xD81 flag only bypasses dfu_endpoint_setup, not sub_100013FD0.

The definitive fix is to not trigger sub_100013FD0 at all for stage 2. That means either:

1. Sending stage 2 data without a SETUP packet (raw OUT - non-standard)
2. Having stage 2 complete WITHIN the same DFU session as the race (same USB connection)
3. Finding a code path that reads da0 without calling sub_100013FD0 first

10. iBSS / iBEC / iBoot Patch Targets (Confirmed)

Once SecureROM bypass is achieved, the chain continues:

iBSS (d27, decrypted):

iBEC (d27, decrypted) - identical offsets to iBSS:

Same 4 patches, same offsets, confirmed from binary analysis.

iBoot (d27, load base 0x86BA00000):