• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Asus tf700t bootloader unlock app source

Search This thread

oroo708

Senior Member
Dec 16, 2010
353
29
The code harpik3d posted is the class that writes the unlock command to the device.
mmcblk0p3 is the partition that sends commands to the bootloader such as boot into recovery or fastboot, unlock, etc.
In this case, the raw text "boot-unlock" is written to the first few bytes of this partition, and another set of data (which is the unlock code) is written to mmcblk0p4.
edit: the string "recovery\lf" (\lf is the line feed character) is also written starting at byte 64 on this partition. Im not sure why, perhaps to delete the DRM keys in stock recovery?

After this the device reboots, and the bootloader checks mmcblk0p3, sees the unlock command, and flashes the unlock code from mmcblk0p4 to another partition. (I think)

s.class creates the main unlock function with the input variable being a string which is the unlock code.
this function is executed by unlock activity, which gets the unlock code from f.class
f.class gets the tegra chipid from another class, and sends that id to, and recieves the unlock code from dmclient.

If you wanted to trace the unlock code back to the source you would have to pull and decompile dmclient.
Most likely the unlock code is downloaded from asus server since it is, I'm assuming, a the digital signature for the device's tegra chipid which must be signed by asus's secret signing key. There is no way to generate this signature without that key. There is also no known way to change the chipid to match a known signature (if someone found a way to do that, we could have a non-asus bootloader unlock). The bootloader should only contain the public key used to verify the unlock code (which it does on every boot before booting an unsigned custom firmware), and the private key can't be computed from the publc key without a mathematical breakthrough in integer factorization.

At this point, it we would want to find another way to unlock the tablet, we would have to disassemble the bootloader code and check for weaknesses.

I would like to do it, but I am no programmer. :(
 
The code harpik3d posted is the class that writes the unlock command to the device.
mmcblk0p3 is the partition that sends commands to the bootloader such as boot into recovery or fastboot, unlock, etc.
In this case, the raw text "boot-unlock" is written to the first few bytes of this partition, and another set of data (which is the unlock code) is written to mmcblk0p4.
edit: the string "recovery\lf" (\lf is the line feed character) is also written starting at byte 64 on this partition. Im not sure why, perhaps to delete the DRM keys in stock recovery?

After this the device reboots, and the bootloader checks mmcblk0p3, sees the unlock command, and flashes the unlock code from mmcblk0p4 to another partition. (I think)

s.class creates the main unlock function with the input variable being a string which is the unlock code.
this function is executed by unlock activity, which gets the unlock code from f.class
f.class gets the tegra chipid from another class, and sends that id to, and recieves the unlock code from dmclient.

If you wanted to trace the unlock code back to the source you would have to pull and decompile dmclient.
Most likely the unlock code is downloaded from asus server since it is, I'm assuming, a the digital signature for the device's tegra chipid which must be signed by asus's secret signing key. There is no way to generate this signature without that key. There is also no known way to change the chipid to match a known signature (if someone found a way to do that, we could have a non-asus bootloader unlock). The bootloader should only contain the public key used to verify the unlock code (which it does on every boot before booting an unsigned custom firmware), and the private key can't be computed from the publc key without a mathematical breakthrough in integer factorization.

At this point, it we would want to find another way to unlock the tablet, we would have to disassemble the bootloader code and check for weaknesses.

i think that the signature is taken from an url constructed in h.class, and it seems to be something like:

Code:
https://mdm.asus.com/DMServer/DeviceState?id=<DEVID>&AUTH=<AUTHKEY>&ACTION=get

where

<DEVID>
      String var1 = ((TelephonyManager)this.mContext.getSystemService("phone")).getDeviceId();
      if(var1 == null) {
         var1 = ((WifiManager)this.mContext.getSystemService("wifi")).getConnectionInfo().getMacAddress().replace(":", "").toUpperCase();
      }


<AUTHKEY>
md5 <DEVID> + <device.class>.a() + <device.class>.getKey() + "dm_server" + "nEEd_query_STATe"
replace("+", "m").replace("/", "f");
if(var5.endsWith("==")) {
               var5 = var5.substring(0, -2 + var5.length());
               return var5;
            }

            if(!var5.endsWith("=")) {
               return var5;
            }
 

ostar2

Senior Member
Nov 22, 2012
142
24
Well, I found out that you do not even need a gmail account to unlock the device. I did not enter the password or username of my email. It still unlocked the bootloader.
 

flyhighx

Senior Member
Nov 9, 2008
233
88
Does this give any hope to those of us who can't unlock? For example I keep getting the failed to unlock, please try again later message and I've been trying for weeks.
 
I've been thinking in another approach:

Correct me if I'm wrong, but how i understand the boot process, the init executable loads the system properties (from wherever it stores them), then it starts running the init*.rc scripts where the initial system is set-up and the main hardware is initialized (including the fastboot behavior)

-I've found in my padfone that the fastboot is enabled(or not) in the init.asus.usb.rc depending on the value of property:sys.usb.fastboot
-I've also seen how in init.rc the script /system/etc/flash_recovery.sh is called to re-create the recovery partition if it has been modified

could it be possible to modify the flash_recovery.sh so it sets the property:sys.usb.fastboot to 1 every time during boot process bypassing the signature check??

what do you think? :confused:
 

_that

Recognized Developer / Recognized Contributor
Oct 2, 2012
4,821
4,208
Correct me if I'm wrong, but how i understand the boot process, the init executable loads the system properties (from wherever it stores them), then it starts running the init*.rc scripts where the initial system is set-up and the main hardware is initialized (including the fastboot behavior)

The fastboot protocol support is in the bootloader, before init starts or even before the Android partition is read. At least on the TF700, I don't know details about the Padfone - it has a different SOC and OS. The only common thing is that it runs Android and it's made by Asus. :)

The property sys.usb.fastboot and etc/flash_recovery.sh don't exist on the Infinity.
 

ostar2

Senior Member
Nov 22, 2012
142
24
The fastboot protocol support is in the bootloader, before init starts or even before the Android partition is read. At least on the TF700, I don't know details about the Padfone - it has a different SOC and OS. The only common thing is that it runs Android and it's made by Asus. :)

The property sys.usb.fastboot and etc/flash_recovery.sh don't exist on the Infinity.

Yeah, the OS does not matter nor does the SOC. What matters is that the bootloader executes before the OS as the OS would not be able to flash its self. Also, I am still angry at ASUS. They know that allot of people are going to use this tool and they take advantage of that. They do this by voiding your warranty and stealing your private information.
 

_that

Recognized Developer / Recognized Contributor
Oct 2, 2012
4,821
4,208
What matters is that the bootloader executes before the OS as the OS would not be able to flash its self.

That does not matter. Any PC OS can update itself without special support from the bootloader - Linux can even overwrite the executable files of running programs.

Also, I am still angry at ASUS. They know that allot of people are going to use this tool and they take advantage of that. They do this by voiding your warranty and stealing your private information.

What private information is stolen? Do you have anything to back that claim?
 

ostar2

Senior Member
Nov 22, 2012
142
24
That does not matter. Any PC OS can update itself without special support from the bootloader - Linux can even overwrite the executable files of running programs.



What private information is stolen? Do you have anything to back that claim?

Remember how ASUS tracks you with cmclient and dmclient. Also, they transmit your Google account credentials that you give the unlock tool as an unencrypted string. They watch your every move.
 

ostar2

Senior Member
Nov 22, 2012
142
24
Also, when I said the "OS" I meant embedded systems that cannot be opened up with special tools or be reprogrammed external without special equipment and software.
 

_that

Recognized Developer / Recognized Contributor
Oct 2, 2012
4,821
4,208
Remember how ASUS tracks you with cmclient and dmclient.

I remember a thread about these, but I don't know what information they send - I also don't really care, my current ROM doesn't have them anyway. :)

Also, they transmit your Google account credentials that you give the unlock tool as an unencrypted string.

You claimed that already once in this thread and I asked you to point to the code that sends this info - you didn't answer that question. Prove it, otherwise you are spreading FUD.
 
  • Like
Reactions: stanglifemike

Zeklandia

Senior Member
Nov 21, 2011
174
56
It does not report to Asus that you unlocked it, it stops reporting that it is locked.

Sent from my DROID RAZR using Tapatalk 2
 
Last edited:

_that

Recognized Developer / Recognized Contributor
Oct 2, 2012
4,821
4,208
It does not report to Asus that you unlocked, it stops reporting that it is.

I don't know what you mean. From the info in this thread we already know that the unlock tool sends the MAC address to Asus, and their server sends back your cpuid signed with their private key, which gets written to the staging partition, from where the bootloader writes it to the CER partition.

I just asked ostar2 to post the code fragment, network packet trace, or whatever, where the Google account info is sent unencrypted to Asus - because that would be a security issue.
 

Zeklandia

Senior Member
Nov 21, 2011
174
56
I don't know what you mean. From the info in this thread we already know that the unlock tool sends the MAC address to Asus, and their server sends back your cpuid signed with their private key, which gets written to the staging partition, from where the bootloader writes it to the CER partition.

I just asked ostar2 to post the code fragment, network packet trace, or whatever, where the Google account info is sent unencrypted to Asus - because that would be a security issue.

That's when it gets the device's specific ID, all unlocking tools do that, even HTC.

Sent from my DROID RAZR using Tapatalk 2
 
It seems to me this is how ASUS is maintaining a list of unlocked devices, which they do state clearly (that your warranty is void once unlocked). I think the real question is, what does on gain by unlocking their bootloader not using this tool other than a higher risk of a pricey paperweight. The bottom line is, once the bootloader is unlocked, via any means, I don't even think APX blobs could get it back to a 'factory' state if one were trying to avoid this dissolution of the warranty agreement. Or am I totally missing the point here?
 

_that

Recognized Developer / Recognized Contributor
Oct 2, 2012
4,821
4,208
I think the real question is, what does on gain by unlocking their bootloader not using this tool other than a higher risk of a pricey paperweight.

If we could unlock without the Asus tool, we could keep our warranty. I don't see any higher risk. We know how unlocking works, but it's impossible without the Asus private key.

The bottom line is, once the bootloader is unlocked, via any means, I don't even think APX blobs could get it back to a 'factory' state if one were trying to avoid this dissolution of the warranty agreement.

Why? With nvflash you can read and write every bit of the internal eMMC. It's even possible without nvflash to re-lock an unlocked device, but of course that doesn't change any information on Asus' server which still knows your warranty is void since you used their unlock tool.
 
If we could unlock without the Asus tool, we could keep our warranty. I don't see any higher risk. We know how unlocking works, but it's impossible without the Asus private key.
That's sort of the catch-22 I'm seeing as well.. I suppose I should first ask if restoring from nvflash blobs actually 're-lock' the bootloader which that does make sense. I also see what you're saying about using nvflash; I would trust APX over poorly obfuscated Java code anyday.

I apologize if I came off as dismissive, I was one of the lame who upgraded past the .30 bootloader shortly before pulling in the driveway the night I got mine :( and that didn't even occur to me.

That being said, I can see a purpose and I think the logical next step would be to investigate the mechanism that actually receives the key- post 'authentication and invalidation' from the ASUS server. IIRC, this is in dmclient right? I'll take a look around and see what I can find that might be interesting but what first comes to mind beyond mucking with SSL certificates and capturing traffic would be to hook the functionality it uses to make the connection and transfer the crucial data. If not on the dmclient side, perhaps on the framework-side-- depending on what it actually uses for HTTPS communication.

Lastly, a disclaimer: I feel this all falls well within the rights afforded to us as owners of this product under the DMCA to reverse engineer these rather secret applications some of which have proven to have quite nefarious capability.

Does that seem to scan with your understand?

---------- Post added at 05:59 PM ---------- Previous post was at 05:29 PM ----------

Reading a bit further, it seems the server probably spits back the signed version of the Tegra ID which seems to be used to actually do the unlocking. I guess the bootloader is the next logical target .. or the SBK itself since that, albeit quite deeply, is stored within the Tegra 3 chip.

Hm, what an obscure solution to a pretty simple problem ASUS.

At this point going after a means to sign the device ID and 'produce' a valid unlock code, if you will, would probably involve hijacking the process of the bootloader signing staging but I don't see how that could end in anything but a very VERY long and complicated (like 1.2E5 years - being quite generous) differential cryptographical attack against AES-128 and if you're up for that, you might as well go for the $100,000 prize out there for it.

Any thoughts now that I feel a bit more caught up to speed :\
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    The code harpik3d posted is the class that writes the unlock command to the device.
    mmcblk0p3 is the partition that sends commands to the bootloader such as boot into recovery or fastboot, unlock, etc.
    In this case, the raw text "boot-unlock" is written to the first few bytes of this partition, and another set of data (which is the unlock code) is written to mmcblk0p4.
    edit: the string "recovery\lf" (\lf is the line feed character) is also written starting at byte 64 on this partition. Im not sure why, perhaps to delete the DRM keys in stock recovery?

    After this the device reboots, and the bootloader checks mmcblk0p3, sees the unlock command, and flashes the unlock code from mmcblk0p4 to another partition. (I think)

    s.class creates the main unlock function with the input variable being a string which is the unlock code.
    this function is executed by unlock activity, which gets the unlock code from f.class
    f.class gets the tegra chipid from another class, and sends that id to, and recieves the unlock code from dmclient.

    If you wanted to trace the unlock code back to the source you would have to pull and decompile dmclient.
    Most likely the unlock code is downloaded from asus server since it is, I'm assuming, a the digital signature for the device's tegra chipid which must be signed by asus's secret signing key. There is no way to generate this signature without that key. There is also no known way to change the chipid to match a known signature (if someone found a way to do that, we could have a non-asus bootloader unlock). The bootloader should only contain the public key used to verify the unlock code (which it does on every boot before booting an unsigned custom firmware), and the private key can't be computed from the publc key without a mathematical breakthrough in integer factorization.

    At this point, it we would want to find another way to unlock the tablet, we would have to disassemble the bootloader code and check for weaknesses.
    2
    I have fully decompiled and deobfsucated the bootloader unlock tool provided by Asus for the tf700t. I was wondering if someone here would be able to modify it so it would not submit data to Asus and void the warranty. I believe that this would be a great help to any one who owns the Asus Transformer Pad infinity.
    1
    This has been tried before with the Prime. In order for it to unlock the device needs to communicate with the Asus servers to get the unlock token that's specific to each device.

    Sent from my ADR6425LVW using XDA Premium.
    1
    This exactly, the unlock requires something to be signed by asus, however I don't really think that reversing the unlock tool is going to help as it doesn't perform the unlock, it only requests the token.

    I agree with you, i think it connects to asus server to request the key and then signs in to your google account to mark the device as unlocked (so it cannot play DRM contents)

    in fact it gets the key from th url:
    Code:
    https://mdm.asus.com/DMServer/DeviceState?id=<deviceID>&AUTH=<AuthString>&ACTION=get
    
    where:
    [B]deviceId[/B]=
    String str = ((TelephonyManager)this.mContext.getSystemService("phone")).getDeviceId();
    if (str == null)
      str = ((WifiManager)this.mContext.getSystemService("wifi")).getConnectionInfo().getMacAddress().replace(":", "").toUpperCase();
    return str;
    
    [B]AuthString[/B]=
    md5(deviceId + Build.SERIAL + NativeKey + "dm_server" + "nEEd_query_STATe")
    1
    Why should they? The server is not intended to be used with a Web browser anyway.

    I assume the check is just an additional safety measure that you are the really device owner before you go on voiding your warranty. Before you accuse Asus of privacy invasion, at least make sure you understand the code and find out what exactly the software does with the password.

    Anyway, by reverse engineering the unlocker we will probably gain more knowledge how the unlocking process works, but it will still not give us any way to do it without Asus servers.

    If they pass any type of private information to that server IT SHOULD BE SECURED. Thats why they should. Doesn't matter if its not intended to be used by a browser, its a security risk.

    Using your gmail acct to check to see who you are, that's really f*ing stupid. You can add another account and sign in with a fake acct. So that makes no sense.

    I never ACCUSED Asus of anything you read wrong I simply said IT SEEMS < SEEMS more like a privacy invasion then anything. There is no LEGITIMATE reason for them to obtain use, transfer information about your gmail acct. Google doesnt do, Motorola Doesnt do it, HTC doesnt do, Sony doesnt do it. So why does asus need to?

    Who care's who you are, they have serial numbers on the device thats all they need. If someone unlocks the device and its not you, thats a legal matter between you and that person not asus and you.