The MINK chain — the secure-world door, opened (Track D, live)

What happened

On the locked bit-4 SM-F956B we drove Samsung's MINK secure-world transport end-to-end and the keymaster TA answered:

AppLoader object (id 3)      -&gt; loads the keymaster TA image
CKMHal object (id 0x96)      -&gt; the keymaster HAL door
GET_VERSION (0x200)          -&gt; "Keymaster 5.3 app 5.3000"   &lt;-- ANSWERED
READ_KM_DEVICE_STATE (0x202) -&gt; ret=0 status=0 rsp_status=-15  &lt;-- EXECUTED

The architecture (what MINK is)

Samsung's TEE IPC = the MINK framework, not the legacy qseecom:

/dev/smcinvoke — the kernel transport (the SMC-invoke driver)
libminkdescriptor.so — the userspace bridge (the CBOR-encoded descriptors, the per-app client environments)
libminksocket_vendor.so — the QRTR/vsock transports
Objects — the Remote (the AppLoader), the Callback, the Memory objects; everything = an object with an invoke(op, args) call
The legacy qseecom = the "compat" path on top (the QSEECOMPAT)

The walls we broke

The Safeplace/DEFEX exec block — the shell-context exec + the device perms (chmod 666 /dev/qseecom /dev/smcinvoke)
The clientEnv gate — TZCom_getClientEnvObject failed for the shell until the smcinvoke device opened
The TA load — the AppLoader object accepted the keymaster image
The -15 — decoded as the milestone gate (see below)

The -15: the milestone gate (decoded)

A buffer-form matrix (four different pointers) all returned the same rsp_status=-15 — the buffer was never the problem. The -15 = the TA's refusal of the device-state commands while the milestone is set:

> The normal AVB2 boot calls KEYMASTER_MILESTONE_CALL. Once set, the TA > refuses READ/WRITE_KM_DEVICE_STATE. The NO_AVB path (after the vbmeta > rename) never calls it — the commands then execute without restriction.

What remains (the honest board)

Tested and ruled out: - The devinfo flag flip (both offset layouts) — the boot ignores the partition, the RPMB is the authority. - The vbmeta-rename (vbmeta_s → xbmeta_s, byte-exact, both GPTs) — the boot survived, but the Samsung ABL uses the compile-time VB2 status, so the runtime vbmeta check the 24090 exploit leans on is absent on this build. The READ stayed -15 (the milestone fuse is one-way).

The remaining doors: 1. The EDL firehose (no public F956B loader yet). 2. The KernelSU module (the OSRC build, the download blocked). 3. A TZ-side primitive (the keymaster trustlet CVE-2026-21085 class).

The MINK chain itself stays fully documented and live — it answered the Keymaster and executed the READ; the gate is the fuse, not the transport.

Credits

Built on the kasnria001 noavb poc + the atlas4381 24090 flow + the public GhostLock chain. The MINK-on-Samsung execution = documented here for anyone picking it up.