OEM-unlock flag experiment — the verdict (Track A closed)

Question: does the bit-4 bootloader still read the OEM-unlock flag, or is the unlock path stripped entirely?

Method: write the official flag ourselves, as uid 0, through the official service path, then reboot and observe.

The gate stack (decompiled from services.jar, build F956BXXS4DZI1)

• OemLockService selects the PersistentDataBlockLock backend (no vendor oemlock HAL registered).
• The "carrier" gate is not a carrier check: ```java // PersistentDataBlockLock isOemUnlockAllowedByCarrier() = !UserManager.hasUserRestriction("no_oem_unlock", USER_SYSTEM);

setOemUnlockAllowedByCarrier(z, sig) { // "Signature provided but is not being used" setUserRestriction("no_oem_unlock", !z, USER_SYSTEM); if (!z && flashLocked) pdb.setOemUnlockEnabled(false); // note the side effect } - `setOemUnlockAllowedByUser(z)` gates: (1) `no_factory_reset` restriction → "Admin does not allow OEM unlock"; (2) carrier → "Carrier does not allow OEM unlock"; then writes the device flag. - The device flag is **the last byte of the persistent partition** (+ SHA-256 digest at offset 0):java // PersistentDataBlockService.doSetOemUnlockEnabledLocked channel.position(getBlockDeviceSize() - 1); channel.write(z ? 1 : 0); // then computeAndWriteDigestLocked() `` Getter reads the same last byte. - IOemLockService transactions on this build: 1=getLockName, 2=**setCarrier**, 3=isCarrier, 4=**setUser**, 5=isUser(=device flag), 6=isOemUnlockAllowed, 7=isDeviceOemUnlocked (ro.boot.flash.locked=="0"`).

The write (uid 0)

Kernel-context root shells can't reach servicemanager — fix with runcon while keeping uid 0:

sh runcon u:r:shell:s0 /system/bin/sh -c 'service call oem_lock 2 i32 1' # clear no_oem_unlock runcon u:r:shell:s0 /system/bin/sh -c 'service call oem_lock 4 i32 1' # write device flag

Result: tx3/5/6 all `TRUE`, PDB getter `TRUE`, **persistent last byte = `0x01`**,
digest valid.


  
Updated verdict (Oct 25, 2026): the unlock routine exists inside the compressed UEFI volume
  

    Correction to our earlier initial scan: running strings directly against
    the raw abl.elf container returned zero hits for oem_unlock because the
    LinuxLoader EFI application is wrapped inside an LZMA-compressed UEFI Firmware Volume
    at offset 0x59000.
  
  

    After decompressing the 1,648 KB payload to its full 5,976 KB image (22 PE32 EFI modules), the entire
    Fastboot unlock implementation is still present inside the binary, including
    OemCheckResetDevInfo, WriteToPartition: devinfo, and
    Display VerifiedBootMenu.
  
  

    How Samsung blocks it on One UI 8.5: instead of stripping the unlock code from the
    bootloader, SecUpdateCmdLine appends androidboot.other.locked=1 alongside
    ROC=1 on the kernel command line, which instructs Android Settings to hide the OEM Unlock
    toggle while SBL1 blocks standard Fastboot entry on normal boot.
  
  

    The PDB write still succeeds (uid 0, service call oem_lock 2/4 i32 1), but the bootloader
    ignores the flag: ro.boot.other.locked=1 is re-applied on every boot. The code was never
    removed; the gate is the QFPROM oem_sw_fuse and the TZ-side check, not a missing routine.
  



                Notes
              
              

                

                  An earlier no-arg service call oem_lock 2 probe accidentally called
                  setCarrier(false, null) → set no_oem_unlock=true and cleared the PDB flag
                  (the flash-locked side effect above). That self-inflicted the "Carrier does not allow"
                  refusals seen mid-session. Cleared with the i32 1 call.
                
                

                  The Settings toggle, if it existed, would call exactly these transactions — it's
                  irrelevant; the consumer of the flag (the abl) is the missing piece.