[ASUS ZenFone 8] vgmoose:
Strangely my toolid is reported as "ASUS_DEFAULT_ID_2" from getprop. Not sure if this is something that changes post-unlock. (I can't dump my asuskey4 partition to find out what's on there either).

No big update from me here, I'm still trying to understand the "verify" path from decompiling the section1.pe binary around the "oem asus-unlock" function. It looks like there are some references to maybe decrypting something and comparing it to a serial number (going off some print strings, potentially intended for UART logging).

Looking at the "oem asus-lock" is easier to read, and it looks like it just writes three 0's to a block device. And after the verification check, the unlock command writes three 1's to the same device. These three ones are likely stored one some other partition (maybe /dev/by-name/sysconf ?)

I noticed that the 6 asuskey partitions are symlinked to block devices sdg2 through sdg7, but sdg1 is "sysconf":

$ ls -lastr * | grep asuskey
0 lrwxrwxrwx 1 root root 15 1970-01-04 20:01 asuskey3 -> /dev/block/sdg4
0 lrwxrwxrwx 1 root root 15 1970-01-04 20:01 asuskey6 -> /dev/block/sdg7
0 lrwxrwxrwx 1 root root 15 1970-01-04 20:01 asuskey -> /dev/block/sdg2
0 lrwxrwxrwx 1 root root 15 1970-01-04 20:01 asuskey2 -> /dev/block/sdg3
0 lrwxrwxrwx 1 root root 15 1970-01-04 20:01 asuskey5 -> /dev/block/sdg6
0 lrwxrwxrwx 1 root root 15 1970-01-04 20:01 asuskey4 -> /dev/block/sdg5

$ ls -lastr | grep sdg1
0 lrwxrwxrwx 1 root root 15 1970-01-04 20:01 sysconf -> /dev/block/sdg1

Something else I observed is there are debug ASSERTs that reveal file names from the original the source code that seem to be built on top of this project: https://github.com/tianocore/edk2 . Which helps for understanding certain functions like "InternalMemCompareMem" being used to compare two buffers for equality (potentially the serial number ("sn_buf") and some plain text.

Here are the relevant UART(?) log lines (for "oem asus-unlock", in the order the code can hit them (from drilling in with Ghidra)). My comments/editorial are above each section and should go roughly over how the unlocking/verifying flow works:

# arg check and previously unlocked check
"Invalid parameter !"
"Device is already unlocked!"

# allocates space for the asuskey token
"verify_RD_unlock: alloc buffer fail\n"
"verify_RD_unlock total read size is %x\n"

# makes sure it's not empty
"asuskey size is zero\n"

# reads an x509 cert (from the binary) and an RSA key (from where?) tries to decrypt the contents from the 0x100-sized asuskey:
"ERROR: Image Invalid, X509_Certificate is NULL!\n"
"ERROR: RSA_KEY is NULL!\n"
"ERROR: decrypt fail!\n"

# prints out the serial number (?) and the decrypted text
"[BL] RD unlocked : sn_buf =%a \n"
"[BL] RD unlocked : plain_text = %a \n"

# if they don't match, we fail, else success
"***** Check RD unlock token Fail *****\n"
"***** Check RD unlock token Success *****\n"

# more strings to notify the user / report errors
"Verify unlock token fail."
"[ABL] Unable to Write Device Info : IsAuthorized = %d\n"
"Device unlocked successfully."
"[ABL] Unable to Write Device Info : IsDebugUnlocked = %d\n"

So, if as this implies, it's really decrypting some content that it receives from the server to verify some device-specific information, it doesn't seem likely to get the unlock working without finding some kind of exploit in this flow, or changing some device parameters (like hardcoding serial number).

There are two other commands: "oem xts-unlock" and "oem wm-unlock". I didn't investigate them as heavily, but xts-unlock appears to have the same x509/RSA verification and asuskey size checks (maybe used in testing?). wm-unlock looks different, and appears to stand for "watermask" (not sure what this refers to), and has some potential references to the IMEI and a string of all "111111111111111".

This leads me to believe that if this is possible at the current time, it is likely done through tricking the server into returning a valid asuskey response, rather than trying to discover a value to write here. Short of a leak of the private key, I really don't see how RSA verification methods could be tricked.