[ASUS ZenFone 8] vgmoose:
I'm on the Zenfone 10 and trying to replicate the same flow (MITM-ing the unlock tool traffic) alongside decompiling some of the system apps. There's a getprop value: "[ro.build.software.version]: [33_0220_0220_52]" and I tried adding this as "swVersion" form parameter (alongside apkVerison), but the same SW VERSION INCORRECT error returns.

Some other stuff I noticed (at least on ZP10):

- The unlock tool sends the response from the server to the com.asus.dm service, which writes it to "/ADF/asuskey.bin", and sets the "sys.debug.write.asuskey" prop to 1

- There's a short init file in "/system/etc/init/init.asus.unlock.rc" that reacts to this property being set, and calls the "writekey" shell command. This is located at "/vendor/bin/writekey".

- The writekey binary itself appears to read "/ADF/asuskey.bin", do some size checks, and write to "/dev/block/bootdevice/by-name/asuskey"

- (I didn't reverse engineer it further, maybe it writes to a specific section– I don't know what these partitions are for)

- When the writekey binary is done, it sets the "vendor.debug.asuskey.ready" prop to 1, which tells the unlocker app it was successful and to reboot (and... then something uses the written asuskey info to unlock?)

Less useful findings:

- "setprop sys.debug.write.asuskey 1" from adb shell also works and will cause writekey to run, resulting in this line in logcat: "UNLOCK(writekey): [BSP]/ADF/asuskey.bin does not exist!" (note: need to set it back to 0 and 1 again to get writekey to run again)

- The settings app (com.asus.settings) does contain AOSP-style references to the classic "OEM Unlocking" checkbox, and checks if "ro.oem_unlock_supported" is 1 (this can't be written to)

- There's another app (com.asus.openbeta2) that also is authorized to talk to the com.asus.dm service and write the key, but it doesn't appear to call this function.

- The signature check com.asus.dm makes on the unlocker app that calls it is only that the signature is the same as the com.asus.filemanager app's signature.

There are also some interesting fastboot/bootloader oem commands that exist listed here, but none seemed to help.

To decompile the APKs, I'm using jadx, and then exporting to a gradle project from the file menu, and searching for strings in vscode/grep. For extracting privileged scripts/binaries, can use payload_dumper on the payload.bin files for the firmware from ASUS's site.

Some speculation:

Besides trying to convince the server to work by changing more parameters (maybe their server is up, but the new APK isn't ready?) I'm wondering if someone knows what's even supposed to go onto these "asuskey" partitions, besides the secret key? There are 7 of them in "/dev/block/by-name".

I know that it's a "secret CPU ID", but it should be possible to actually write this key by intercepting the request via mitm-ing. This would eventually (via the .bin file -> init script -> writekey binary) make it onto that partition. So it might be interesting to see if any other values DO ... do something.

I haven't tried returning a key to be written there yet, but I can find some very old posts where people do talk about editing these files in a hex editor. Also, separately, I'm not sure what in the bootloader is supposed to even receive this secret key and then decide to perform the actual unlock. (fastboot oem unlocking? some fastboot oem asus-go equivalent?)

If someone is unlocked and rooted already, it should be possible to dump the contents of these "asuskey" partitions from the /dev/block/by-name folder (eg. with "sudo dd if=/dev/block/by-name/asuskey of=./asuskey.img"), and trying to see what the secret ID looks like in hex editor, or what other info is there.

It's pretty upsetting that this tool is still unavailable! I feel like I got the ZP10 under false pretenses! It would be a huge relief to either get the server working or figure out something else out with the asuskey partition(s).

For example, if writekey has permission to write to these block devices, it could be possible to convince it or another binary to set some data on a partition that the bootloader uses to ultimately unlock.