This kind of attack may be possible, but asus's servers only communicate the unlock information once. You would have to capture those communications and make a modified unlocker. Whether it works depends on how the bootloader code verifies the unlock information, and how much of the unlockable tablets information can be spoofed onto the un-unlockable tablet.
Here are my findings in regards to the unlock tool, for TF201 however probably applies to TF700 as well.
The Unlock tool app itself has these basic functions.
1. Install certificate that is included in the BKS keystore file.
2. DMServerUnlock. Connect to
https://mdm.asus.com/DmServer/DeviceState using SSL connection, using the following parameters:
--a. id=Wifi MAC address with columns removed
--b. AUTH=an MD5 hashed string with some modification. The string itself consists of Wifi MAC + SerialNo + WVDrmUtils.getKeyBoxSha1(0) + the string "dm_server" + the string "nEEd_query_STATe"
----i. the getKeyBoxSha1 is probably DRM related information specific to the device. ---not confirmed as this seems to be native commands.
--c. action=get
3. The above connection will return whether your device is already unlocked or not from ASUS servers.
4. If your device is still shown as locked, then it will proceed with determining whether a pin code verification or google account verification is necessary.
5. Upon above verification, then the actual unlock process starts.
6. NotifyDMServer - throws an android intent to the DMClient.apk program using the following: Action=com.asus.unlock.intent.REGISTRATION, Extra:registration_cpu_id = YourCpuId
--a. YourCpuId is parsed from /sys/devices/platform/cardhu_misc/cardhu_chipid
7. ---DMClient logic yet to be analyzed---
8. The DMClient will return a two part string separated by ";;".
--a. The first part is the unlock status. On success, this will be "unlock success"
--b. The second part is the "SecretCpuId" which according to Rayman is simply your cpuid + 256byte length ASUS RSA 2048 signature as a hex string. The total byte length of the unhexed string needs to be 292.
9. If unlock success and length is 292, then:
--a. "boot-unlock recovery" is written to mmcblk0p3 (misc partition)
--b. the "SecretCpuId" is written to mmcblk0p4 (staging partition)
10. A reboot is issued.
11. upon reboot, the bootloader checks the MISC partition for any commands, finds the "boot-unlock" command.
--a. writes the contents ofmmcblk0p4 into mmcblk0p7 (CER partition)
--b. bootloader will check the mmcblk0p7 contents, see if it is properly signed by ASUS, and if the cpuid matches, then:
----i. allow fastboot access
----ii. stop checking signature of blobs (not the header part, but the ASUS RSA signature at the end of BLOB files)
----iii. stop checking for signatures of boot images in SOS (recovery) and LNX(boot) partitions.
So basically, most of the logic within the unlock tool can be skipped. Acquiring the actual signed cpuid takes place within DMClient, I believe we need to analyze DMClient to see what parameters are being passed to the ASUS servers. Once this is done, we can do the following:
- figure out if any of the parameters are incorrect or not being parsed successfully.
- figure whether it is an issue with the proper SSL certificate being installed within the tablet itself.
- if above two are not the issue, then its most likely the ASUS server does not have the correct combination of parameters for our devices defined within their databases...
