[ASUS ZenFone 8] vgmoose:
Looks very interesting, thank you for the info!

Only that it should be 256 bytes, is returned from the unlock tool's server, and is written to asuskey using the "writekey" command. I got the name from decompiling the unlock tool in jadx-gui, and there's a method named: "verifySecretCpuID" (verify the response length from the server is good, not any actual crypto or inspection of the data).

Since my above post, I've learned that the file "abl.img" extracted using payload_dumper from the payload.bin in Asus's FW updates appears to be the bootloader. I don't think the source code is available, but the binary helps.

This article has a lot of useful information from someone else analyzing an android bootloader image to try to unlock it: https://www.pentestpartners.com/sec...id-bootloader-on-the-qualcomm-snapdragon-660/

In that case, the key also appears to be 256 bytes, but is encrypted/verified using RSA. The author actually then goes on to totally ignore the potential of writing this value and jumps straight to finding an exploit in the bootloader code. (Which is also interesting!)

After extracting the UEFI partition from abl.img using binwalk and uefi-firmware-parser (from the article above), there's a file: "section1.pe" that can then be reverse engineered. From this, using "strings", all fastboot oem commands can be extracted (attached to this post as a txt).

This PE file can also be decompiled in something like Ghidra to inspect what the actual unlock function is supposed to do. Unfortunately this is above what I'm able to understand, but it'd be interesting to try to follow the decompiled/assembly there and see what mechanism 1. is used to check the key from the bootloader, and 2. what it actually ends up doing to perform the unlock.

For fun, I tried "fastboot oem asus-unlock", and it of course reports: "FAILED (remote: 'Verify unlock token fail.')". I still believe that it's possible to write the unlock token by spoofing the server response in the unlocker app, and then try to run this command, but without knowing how it should look, it's kind of just speculation.

If the key is unique per each phone (which it probably is), then that would point to either 4th or 6th string in the above partition dump. If it needs to be exactly 256 bytes (0x100 in a hex editor), maybe it's a combination of one or more strings as well. The last string in particular (" 15715839e737449088fe70f7faf618f0") looks like an md5 hash. Some special hardcoded "magic bytes" like the "ASUS" string though is also pretty suspicious!

Is there any obvious consecutive 256 bytes in asuskey4 that looks like it might be this value? It could also contain 0000000s. I'm also still not sure what's going on with the partition layout though. There do appear to be some references to "asuskey4" in the bootloader code for reading the IMEI from asuskey4. There might also be the possibility that the secret key is cleared from the "asuskey" partition after the actual unlock occurs...

Attached is the list of fastboot oem commands extracted from the bootloader (again, this is all for the 10, but the same methods to extract them and likely many commands should also apply to the 8).

Maybe some of these could reveal what some of the string IDs are?