KG (Knox Guard) behavior notes

Observed on a 2026 Samsung flagship (downgrade-triggered Prenormal state) + bootchain RE of the KG trustlet (tz_kg).

Where the state lives

From tz_kg.mbn strings + behavior: - QFPROM fuse row — HWIO_QFPROM_RAW_OEM_SPARE_1_ROW1_LSB_ADDR; the trustlet has KGBL_read_fuse / KGBL_write_fuse APIs. - RPMB — KG_TA secure data (KG RPMB partition/sectors). - The trustlet exposes KG_unlock / KG unlock / verify complete token — the unlock flow consumes a token from Samsung's servers (the 168h wait + check-in pipeline).

The 168h clock

What it actually needs (empirically + community consensus): - active SIM + network (check-ins via kgclient — NOT the OTA agents), - automatic date/time ON, - device powered on with accumulated uptime over 7 days, - manual check-in code: *#*#2432546#*#*.

Notes: - ro.boot.kg can read 0x0 while knox.kg.state = Prenormal — the bootloader-side KG bit and the userspace KG-agent state are different things. Don't read ro.boot.kg alone. - Disabling OTA agents (com.wssyncmldm, com.sec.android.soagent) does NOT break the KG check-in path — kgclient is separate. (Verified.) - Date-forward tricks (the old Denz0id play) have no confirmed effect on modern server-side KG; treat as folklore.

carrierid vs sales code

• ro.csc.sales_code can say one thing (e.g. carrier-branded) while ro.boot.carrierid shows the ACTIVE carrier profile (e.g. unbranded). The "carrier does not allow OEM unlock" error is not driven by either — it's the no_oem_unlock user restriction (see oem-unlock-gate-stack.md).

Why KG usually doesn't matter for unlock anymore

On firmware where the abl ignores the software flag entirely, clearing KG changes nothing about unlockability — at most the toggle reappears and flips the same ignored flag. Still worth keeping the clock fed (online + SIM + auto-time) as insurance while other research lines are open.