I recently spent some time dissecting the bootloader used on Motorola's latest Android devices, the Atrix HD, Razr HD, and Razr M. The consumer editions of these devices ship with a locked bootloader, which prevents booting kernel and system images not signed by Motorola or a carrier. In this blog post, I will present my findings, which include details of how to exploit a vulnerability in the Motorola TrustZone kernel to permanently unlock the bootloaders on these phones.
These three devices are the first Motorola Android phones to utilize the Qualcomm MSM8960 chipset, a break from a long tradition of OMAP-based Motorola devices. Additionally, these three devices were released in both "consumer" and "developer" editions. The developer editions of these models support bootloader unlocking, allowing the user to voluntarily void the manufacturer warranty to allow installation of custom kernels and system images not signed by authorized parties. However, the consumer editions ship with a locked bootloader, preventing these types of modifications.
Supported Bootloader Unlocking
From the perspective of the user, unlocking the bootloader on a developer edition device is fairly straightforward. The user must boot into "bootloader mode" using a hardware key combination (usually Vol Up + Vol Down + Power) at boot. Next, the standard "fastboot" utility can be used to issue the following command:
fastboot oem get_unlock_data
In response to this command, an ASCII blob will be returned to the user. The user must then submit this blob to the Motorola bootloader unlock website (https://motorola-global-portal.custhelp.com/app/standalone/bootloader/unlock-your-device-a). If the user's device is supported by the bootloader unlocking program (i.e. if it's a developer edition device), the website will provide a 20-character "unlock token".
To complete the process, the user issues a final fastboot command:
fastboot oem unlock [token]
At this point, the bootloader unlocks, and the user may use fastboot to flash custom kernel and system images that have not been signed by Motorola or the carrier.
QFuses and Trusted Boot
Much of Qualcomm's security architecture is implemented using QFuses, which are software-programmable fuses that allow one-time configuration of device settings and cryptographic materials such as hashes or keys. Because of their physical nature, once a QFuse has been blown, it is impossible to "unblow" it to revert its original value.
If the FORCE_TRUSTED_BOOT QFuse is blown, as is the case on all production Motorola devices, each stage of the boot chain is cryptographically verified to ensure only authorized bootloader stages may be run. In particular, the PBL ("Primary Bootloader"), which resides in mask ROM, verifies the integrity of the SBL1 ("Secondary Bootloader") via a SHA1 hash. Each stage of the boot chain verifies the next stage using RSA signatures, until finally Motorola's APPSBL ("Application Secondary Bootloader"), "MBM", is loaded and run.
Checking the Bootloader Status
The entirety of the Android OS signature verification and bootloader unlocking process is implemented in MBM. To study the implementation, I examined the "emmc_appsboot.mbn" binary included in a leaked SBF update package for the Motorola Atrix HD. It's also possible to pull this partition directly from a device via the /dev/block/mmcblk0p5 block device.
To start, because the binary blob is an undocumented format, I assisted IDA Pro in identifying entry points for disassembly. Next, I searched for cross-references to strings referring to unlocking the bootloader. After getting my bearings, I identified the function responsible for handling the "fastboot oem unlock" command. The reverse engineered pseudocode looks something like this:
int handle_fboot_oem_unlock(char *cmd)
{
char *token;
if ( is_unlocking_allowed() != 0xff )
{
print_console("INFO", "fastboot oem unlock disabled!");
return 3;
}
if ( is_device_locked() != 0xff )
{
print_console("INFO", "Device already unlocked!");
return 3;
}
token = cmd + 12; /* offset of token in "oem unlock [token]" */
if ( strnlen(token, 21) - 1 > 19)
{
print_console("INFO", "fastboot oem unlock [ unlock code ]");
return 0;
}
if ( !validate_token_and_unlock(token) )
{
print_console("INFO", "OEM unlock failure!");
return 3;
}
return 0;
}
Of particular note are the is_unlocking_allowed() and is_device_locked() functions. Further reversing revealed that these functions query values stored in particular QFuses by accessing the QFPROM region, which represents the contents of the QFuses, memory-mapped at physical address 0x700000. In particular, these two functions invoke another function I called get_mot_qfuse_value(), which queries the value stored in a specific QFuse register.
Having reversed this behavior, the implementation of is_unlocking_allowed() is simple: it returns the "success" value (0xff) if get_mot_qfuse_value(0x85) returns zero, indicating the value in the QFuse Motorola identifies with 0x85 is zero (this register happens to be mapped to physical address 0x700439). In other words, by blowing this particular QFuse, unlocking may be permanently disabled on these devices. Fortunately, this has not been performed on any of the consumer editions of these devices.
The logic behind is_device_locked() is a bit more complex. It invokes a function I called get_lock_status(), which queries a series of QFuse values to determine the status of the device. Among others, it checks the QFuse values for identifiers 0x85 ("is unlocking disabled?") and 0x7b ("is the Production QFuse blown?"). If the Production bit isn't set, get_lock_status() returns a value indicating an unlocked bootloader, but this QFuse has been blown on all released models. Otherwise, if unlocking hasn't been permanently disabled, the result is based on two additional conditions.
If the QFuse with identifier 0x84, which is mapped to physical address 0x700438, hasn't been blown, the status is returned as "locked". It turns out this is the QFuse we're looking for, since blowing it will result in unlocking the bootloader! If this QFuse has been blown, there is one final condition that must be satisfied before get_lock_status() will return an "unlocked" status: there must not be a signed token in the SP partition of the phone. Further investigation revealed that this token is only added when the user re-locks their bootloader using "fastboot oem lock", so it does not pose any obstacle when trying to unlock the bootloader.
Token Validation
If the bootloader has not already been unlocked, MBM will attempt to validate the token provided by the user. More reversing revealed that the following logic is used:
- The CID partition is read from the device.
- A digital signature on the CID partition is verified using a certificate stored in the CID partition.
- The authenticity of the certificate is verified by validating a trust chain rooted in cryptographic values stored in blown QFuses.
- The user-provided token is hashed together with a key blown into the QFuses using a variant of SHA-1.
- This hash is compared against a hash in the CID partition, and if it matches, success is returned.
As a result, there is no way for a user to generate his or her own valid unlock token without either breaking RSA to violate the integrity of the CID partition, or by performing a pre-image attack against SHA-1, both of which are computationally infeasible in a reasonable amount of time.
Edit: The original post claimed the algorithm used was MD4. I mistakenly identified the algorithm because MD4 and SHA-1 evidently share some of the same constant values used during initialization. Thanks to Tom Ritter, Melissa Elliott, and Matthew Green for discussing this and inspiring me to take another look.
Introducing TrustZone
Having run into this dead-end, I examined what actually takes place when a successful unlock token is provided. We already know that MBM must somehow blow the QFuse with Motorola identifier 0x84 in order to mark the bootloader as "unlocked".
It accomplishes this by calling a function that invokes an ARM assembly instruction that may be unfamiliar to some: SMC (Secure Monitor Call). This instruction is used to make a call to the ARM TrustZone kernel running on the device.
TrustZone is an approach to security integrated into many modern ARM processors. TrustZone operates in what's known in ARM parlance as the "Secure world", a trusted execution mode whose security is enforced by the processor itself. Among other tasks, TrustZone may designate "Secure memory", which cannot be read from the "Non-secure world", regardless of privilege level. Even if code is running in SVC (kernel) mode, attempts to access a Secure memory region from a Non-secure execution context will cause the CPU to abort.
The Secure world stack is often implemented as a small trusted kernel. On these particular Motorola devices, the TrustZone kernel resides on the TZ partition of the device and is loaded at early boot, prior to MBM. The Non-secure world may issue requests to the Secure world using the privileged SMC instruction.
In this case, it became clear that MBM issues a specific SMC call to request that the TrustZone kernel blow the appropriate QFuse to unlock the bootloader on the device.
Communicating with TrustZone
For a first naive attempt at unlocking the bootloader, I decided to deconstruct the syntax of the SMC call made by MBM and make an identical call from kernel mode in the Android OS.
Fortunately, Qualcomm-based Linux kernel trees have source code that reveals the syntax of these SMC calls. Looking at arch/arm/mach-msm/scm.c reveals that calls to Qualcomm-based TrustZone kernels are expected to pass arguments using the following data structure:
struct scm_command {
u32 len;
u32 buf_offset;
u32 resp_hdr_offset;
u32 id;
u32 buf[0];
};
Understanding this data structure clarified the SMC calling convention I saw in MBM. In particular, when issuing the call to unlock the bootloader, MBM sets an id of 0x3f801 and provides a buf array of four words, containing the values 0x2, 0x4, 0x1, and 0x0, in that order. Based on looking at additional MBM code, it appears that the 0x4 represents a word offset within the QFuse bank beginning at 0x700428, and 0x1 represents a bitmask indicating which bits within that word should be blown. This makes sense, since this call would result in blowing the QFuse at physical address 0x700438, which we already determined would unlock the bootloader.
With this knowledge in hand, I threw together a kernel module that would issue an identical SMC call to hopefully unlock the bootloader. I loaded this module into the Android OS's Linux kernel and...it returned an error code of -1001.
Inside TrustZone
To see what was going on here, I knew I would need to reverse engineer portions of the TrustZone kernel running on the device. After loading the tz.mbn binary blob contained in an SBF update package into IDA Pro, rather than reversing the entire kernel I made a quick search for the immediate value 0xfffffc17 (-1001) to see if I could skip straight to the code I was interested in. Sure enough, there was only one function containing this value.
Taking a look at this function revealed the following pseudocode:
int handle_smc(int code, int arg1, int arg2, int arg3)
{
int ret;
switch (code) {
...
case 2:
if (global_flag) {
ret = -1001;
}
else {
/* Perform unlock */
...
ret = 0;
}
break;
case 3:
global_flag = 1;
ret = 0;
break;
...
}
return ret;
}
Based on this code, it appears that the first word in the SMC buffer represents a command code (in our case it's 0x2). The reason TrustZone is returning an error on our SMC call from the Android kernel is a particular one-way global flag residing in TrustZone secure memory has apparently been set by MBM before booting the Android OS, preventing all subsequent calls to blow QFuses. Going back to the MBM code, I confirmed this by identifying an SMC call with a command code of 0x3 invoked immediately before booting Linux. Another dead end.
Exploiting TrustZone
At this point, the end was in sight, but I knew I would need a vulnerability in the TrustZone kernel in order to set this flag to zero, allowing my SMC call to blow the QFuse required to unlock the bootloader. Fortunately, I didn't have to look long, since one of the other SMC commands in the same section of the TrustZone kernel contains a fairly obvious arbitrary memory write vulnerability:
switch (code) {
...
case 9:
if ( arg1 == 0x10 ) {
for (i = 0; i < 4; i++)
*(unsigned long *)(arg2 + 4*i) = global_array[i];
ret = 0;
} else
ret = -2020;
break;
...
}
This SMC call, invoked with command code 0x9, is evidently intended to allow the Non-secure Linux kernel to obtain values stored in a particular region of Secure memory. The value provided as the second argument in the SMC buffer is used as the physical address at which this memory is copied. This code does not check that the provided physical address corresponds to a Non-secure memory region, so it can be used to overwrite memory in a Secure region, including our global flag.
At this point, I had everything I needed. As a test, I issued the vulnerable SMC call while providing a physical address in Non-secure memory that I could read back. Fortunately, it appears that all but the first of the four words that are written by the vulnerable code are zeroes, allowing me to clear our global flag preventing a bootloader unlock. Finally, I put it all together by aiming the arbitrary TrustZone memory write to zero the flag and issuing the SMC call with command code 0x9, and then finally issuing the SMC call with command code 0x2 to unlock the bootloader. Rebooting my test device into bootloader mode and checking the bootloader status with "fastboot getvar all" showed I had been successful, and the bootloader was now unlocked!
As previously mentioned, this exploit will work on all Qualcomm-based Motorola Android phones, which includes the Razr HD, Atrix HD, and Razr M.
Thanks Dan, this is amazing work. You made a lot of people very happy with this!
Thank you so much man. I really enjoyed your step-wise explanation. Do you pass this information on to Moto for future consideration in development?
This looks like it has rather dire and complicated security implications beyond simply unlocking the bootloader. Amazing work as always and I hope the repercussions are as good down the road as they seem to us in the modding community right now. I am afraid that may not be the case...
Vielen Dank
I tried so hard to understand this as I was reading it. It definitely gave me a better understanding of what exactly you were up against with this task. Thank you very much for your hard work and dedication! I am now very happily sitting with an XT926 that is unlocked. :) After coming from a Droid X that I so desperately wanted to have fun with, this news makes me so excited. You're doing fantastic work, and I cannot express how thankful I am. Cheers, and keep up your amazing work!
Thank you for detailing this exploit. There are also LG devices that rely on TrustZone and SCM and their bootloaders are engineered by Qualcomm so this may help with those devices as well. Not all are msm8960 chips but there is a high probability the same steps will reveal the vulerable code.
tai hao le ~!~!~ zhivchi
Great work on both the exploit and the step by step introduction of it. I like how you are not just throwing around big words and describing the process in two sentences, but actually explaining WHAT it does, HOW it does that thing, and HOW did you came to that conclusion and result. Most of the exploiters should learn from this!
As a fellow Android developer, I can only congratulate you, I am pretty sure you made a lot of people happy with this discovery.
Also just a sidenote, but I believe this exploit not just brought happiness to many, but the backstory and details might have brought some closer to explore the internal workings of our devices!
Muchas Gracias! Form Guatemala I am sending all my gratitude to you. I have an Atrix Hd, I rooted it thanks to you... and now am unlocking my boot loader. Have already sent a donation your way. Now I have to figure out what I want to do from here! Thanks also, for explaining it, you gave me some insight... although I could never do anything like this.
Thanks Dan, awesome work!
first, can u explain how you found the address of global_flag? secure world uses virtual memory I presume, so u need a way to leak the address of something in secure world and calculate an offset right?
second, can you share the trustzone os blob somehow?
This is really amazing analysis, great job!
Amazing work. Thanks for the break down, no matter how over my head it is. It's fun to see the process. I know free exploits don't fall from the sky, thank you for sharing your work. I've got a rooted RAZR M because of it. Dan is the man.
Dan, as always your work is overwhelmingly impressive. I salute your work and all you have done for the Android community. THANK YOU!
Awesome work, and thank you so much for the detailed explanation. As mentioned there are a number of other similar devices based on qualcomm chipsets that may be vulnerable to this as well.
Im particularly curious about the Defy XT from Republic wireless that runs Snapdragon S1 (MSM7227A)
I'm stoked to paste this on Motorola's facebook page(s).
How did you get the location of global_flag?
Any chance you could do the Droid X next?
Great Job, I picked up a phone from china with the msm8960 Snapdragon chipset made for a large oem. There are a few other issues too ;)
My MoPho looks up from what was supposed to have been his early grave and final resting place, and proudly salutes you for liberating him from his shackles and chains.
"Free at last!", reads the scrolling banner on the screen. "Thank God Almighty, we are free at last!"
May every newly-liberated 'droid find the afterlife of happiness denied to it by Motorola and ambivalently scoffed by Google that's the birthright of all Android phones. Let them be energized by the empowering sourcecode bestowed upon them by Linus, celebrate the freedom fought for by Gnu Foundation, and lead their current or future owners to join the priesthood at the hallowed Temple of XDA.
...and just to really rub it in, let someone at Motorola mention at a staff meeting last week that the resale value of once-locked phones that prospective buyers wouldn't have touched with a dirty tetanus-infected needle last week has skyrocketed now that they're open :-)
I wonder if this may be applicable to unlocking other Motorola devices that use fuses. http://forum.xda-developers.com/showthread.php?t=1650520 is what we think we know right now about the fuses on the Motorola Photon. I am lightsword1942 on XDA.
First of all, excellent work!
Secondly I love how you present something so arcane and make it seem so easy. My hat is off to you sir. I look forward to seeing more TZ exploits from the community in the near future.
I always get fascinated when reading these kind of hacking stories.
Really brilliant exploit and explanation!
Congrats!
To answer a few questions:
The address of the global flag preventing the SMC call to blow the "unlock" QFuse is easy to find. Because the TrustZone kernel is always loaded at physical address 0x2a000000 on these devices (TZ references everything as physical, not virtual memory), the flag is referenced via a hardcoded address in the ARM assembly. This address varies per device due to differences in the compiled TrustZone kernel images, but can be determined at runtime by scanning the TZ kernel image via its block device, matching a byte signature, and decoding ARM instructions to retrieve the immediate value corresponding to the address of the flag.
http://sbf.droid-developers.org/ is a valuable resource for firmware images of Motorola phones.
Thanks for all the positive feedback and questions!
Looks like my choice to upgrade to the hd was a good one. Thanks Dan
This is great news to anyone with a locked down phone, but from the sounds of things it still leaves the phone in a stat that Motorola can still check that the phone's warranty has been voided. Sure you are not flat out telling them that you are voiding it, but all they have to do is take a look at the state of the QFuses. As these fuses cannot be reset once blown you are still SOL. If your phone is a developer version you might as well go through Motorola's process of unlocking the phone. It sounds like it will be simpler and have similar results.
Now if some way could be found to use the SMC calls in the TZ kernel to completely bypass the QFuses and boot arbitrary code, that would be a major break through.
Beautiful write-up.
Amazing read.
I loved the way you explained what were your latches (things you used to zero in on the interesting code).
Question:
How did find that buggy TZ command code?
The real question is why Dan has never joined Motorola or Google as an employee...
Awesome work Dan! I own a XT926 with a locked bootloader. Your work is really fascinating, however, I can't seem to figure out how to issue the SMC command to the device... Any help would be greatly appreciated, and, do you have a way for me to donate some coffee/beer money for your awesome work? I'm sure a lot others will be happy to send some money your way too!
Dan, you're amazing, hopefully your hard work will allow progress on the LG bootloader front as well.
I read through the entire procedure.This is simply awesome.
Truly impressed with the article and the thoroughness of the write-up. I'm always amazed to see what lengths developers (or whatever you identify yourself as) take to accomplish a daunting task like this. Overall, how long did it take you to figure out this exploit? Good work!
Great writeup! As an aspiring cybersec engineer, looking into your whole process is invaluable!
One question - when you reverse engineered emmc_appsboot.mbn, you mentioned using ida pro and then show a block of C pseudocode. Did you use hex-rays for this, or did you reverse the assembly by hand?
After reading through it I have a question about the "toekn" that is checked ony if the qfuse is blown and and the device has been re-locked. You mention that a fastboot oem lock command would generate the token here showing the locked status. If someone were to use this exploit to unlock the bootloader would there be a way to lock and re-unlock it? I assume the device would still fail on Motorola's developer site due to the other qfuses being pre-blown. I personally have no reason to re-lock the bootloader that I can think of but I am sure someone will think of something. It sounds like simply deleting that token would instantly change the status back to unlocked but what if any would be the process to delete that token from the SP partition in question?
Jake: it took about 4-5 days working on and off to figure this out and write the exploit (I just checked when I downloaded the first SBF package I looked at).
Bryan: I primarily reversed this by hand, especially the code issuing SMC calls, since Hex-Rays wasn't able to decompile that part. But I definitely use Hex-Rays when I want a quick glance at what a particular function is doing.
StrifeJester: You need to provide the same token used to unlock the phone to re-lock it ("fastboot oem lock [token]"), and they use that token and a QFuse-based key to generate an AES-CMAC, which is what is added to the SP partition. So while I didn't investigate this fully, I suspect you'd run into the same problem of needing to break SHA-1 in order to find the appropriate token to generate a valid CMAC to re-lock the device.
Thanks Dan! I own an LG Spirit, which from what I have read ( I'm not very versed on this ) seems to also utilize TZ. My hope is that we can tweak the process you used for the Moto to work with LG's, once we figure out if the TrustZone is in the TZ location (seems logical but fingers crossed). Any help on this would be VERY appreciated by many LG owners. Thanks again for the help and time and effort and high level of info.
Do you think you might be able to take a look at tegra2 Motorola bootloaders and see if there is anything in there that might be exploitable, maybe something that could reveal the Secure Boot Key or otherwise allow bootloader downgrades(so that the leaked unlocked bootloaders can be installed). If you need hardware I might be able to get you one.
Thank you so much!!!
Can you tell us whether this technique will work with xt530?
drjbliss is the man...
Amazing read....
Dan "is" the man...g
Thank you! Can you tell us whether this technique will work with xt531?
Simply amazing! Much respect and awe goes out to you Mr. Rosenberg. And I do believe that I first rooted my Atrix 2 using one of your exploits.. Thank you!
So, the former OMAP4 based Moto bootloaders are an entirely different animal than the new Qualcomm ones? And, I assume the consumer editions of those probably already have a fuse blown to not allow BL unlocking or to make finding an exploit even more difficult?
I know many Atrix 2, RAZR, Bionic, etc, owners would be elated if some sort of exploit were to turn up.. plus, almost all of those devices have a "Bootloader Unlock Bounty" of some sort on xda or elsewhere - so, someone could make bank, in theory.. :) (but, I am not complaining at all - we currently have kexec being perfected on these devices - thanks to kholk, mbm, hashcode, dhacker, jonpry, and others).
Thanks again for all of your hard work and contributions! -alterdlikeness
please mi friend.. say me.... this bootloader unlock is compatible whit the motorola droid 2 global? .. please!!!!
Ok, I would like to ask you Dan, if you could give some help for the Brazillian fellows who have bought the new Motorola Razr D3 (which for the first time started selling in Brazil before the rest of the world), which uses a mediatek chip and android 4.1.2. None of the all in one tools have worked to unlock it. I appreciatte any help. Thanks.
Dan, your contributions in the past have been legend, but THIS. You are amazing. Thank you for all that you do. I know a lot of Moto fans will be VERY pleased with your work. My only hope now is that you receive the bounty for all your hard work and people donate to show their support.
/v
Hello,
Thank you Dan, I'm ignorant of all of this technical talk but I followed your instructions and eventually I got it rooted but when I boot with the volume button it still says Locked. Using Motorola RAZR HD on 4.2.2
I was hoping to use my phone on a different carrier instead of Verizon. But after reading some posts I'm under the impression this unlock doesn't do that. I can't imagine what I could do with this unlock other than hope for using a different carrier because I'm not sure what else my phone could possibly do that it doesn't already do.
Perhaps this isn't meant to be info for the general public like me but if it is then maybe some more laymen info as to why one would want to unlock this way etc... might be useful for us newbs.
the internet will pay you to root the bionic...really we will...PLEASE ROOT 98.72.22 FOR THE BIONIC...OMAP4 suuuuucks
Dan I used your method to unlock my boot loader on my RAZR HD can I lock it back an return to stock any way to preserve my warranty? Any help would be appreciated.
What actually happens:
Droid 2 Global has 2 CPUs : OMAP (AP) & Qualcomm(BP) The chip is CDMA1x QSC6085 so it barely has any security on board
THIS METHOD is available on droid 2 global my friend.. please.. say meeee
I used your expoit to root my atrix hd. So grateful and thankful to you. Thank you, Dan Rosenberg. Your article on the story of this exploit was also perfect. I feel lucky to have a phone backed by Dan Rosenberg. I used a lot of motorola phones in the past and dan rosenberg was there for root ! Now,it is one step further that's bootloader unlocking.It freed the device from vain. :)
Dan Thanks for your root for the S4. I hope to see your future works, hopefully on the boot loader specifically :-)
Mobile phones totally changed the structure of communication industry. ... to be known as the best mobile phones manufacturer the mobile manufacturing companies are exerting much efforts and are launching mobile phones with innovative amazing features.
I recently flashed JB on my bionic and lost root :( I have a mac and can run virtual windows 8 using parallels. I have tried numerous rooting methods and non have worked. I also backed up my phone using both bootstrap and safestrap. Once, my phone is rooted and running JB, can use the above apps to restore my settings, sms, etc.? I would greatly appreciate your help, thank you.
Dan, I have downloaded your unlock package for the Motorola msm8960 phones. Would your unlock script work for the LG Motion, which also has an msm8960 board from Qualcomm, or would it have to be modified?
Very nice. Many years ago as a DOS programmer I wrote exe's that self modified themselves actually modifying initial variables and constants in the exe. In that way an exe would be unique from another copy. These exploits remind me of the same idea.
Anyway, seems like once the BL is unlocked it would be possible to flash new TZ code that totally ignores the actual values in the fuses and returns values that are, um different. So a rooted phone would never report as previously rooted and so on. It could even report that it wasn't unlocked. Fun stuff!
Would you like $800 US Dollars or more? Here is a challenge I think you can crack. http://forum.xda-developers.com/showthread.php?t=1224166
Mostly Tegra2 there are sources and technical manuals and your knowlege of other Moto tech... I really think you can claim the prize! Best of Luck and I hope it Works!!
Dan,
Amazing article well executed and well explained.
Looking for a vulnerability and you have found one ..a big one....
Learnt a lot from this.
Thanks.
Dan have you tried this on the X?
Well all u love your unlocked phones cause mine is locked down and nobody can ever unlock it I've tried everything and nothing
this is same as in motochopper?
Just curious, how could you load your own kernel module in the first place? It's production phone and not rooted I suppose, right?
Mr. Dan, can the recent 9.18.79 update of the RAZR HD still be rooted? I know so far the boot loader is locked.
So glad that the DROID RAZR HD I got was still running the older software version. I didn't know the HD could be unlocked, but I whenever I get a new phone, the first thing I do is go to the forums at xda and DroidRzr.
When I first booted up my RAZR HD, it stated there was an update. I immediately told it to NOT apply it, knowing that OTAs always patch exploits.
Sure enough, after reading in the forums, I saw a chance that I could unlock my bootloader.
Thanks Dan for all the hard work. I can see how much work was involved in this and how you possibly could not find another exploit after the last OTA.
I was curious if this same exploit be used on the Sony XperiaTL? Both that and the Atrix Hd share the same processor and chip set.
Any way you would be willing to find a new exploit for the updated RAZR M bootloader? Motorola/Verizon closed the hole in the summer update. Now we are unable to unlock our bootloaders.
If anyone could find a new exploit, you can. I don't think anyone else can do it.
I don't even understand a word you said, but I love the end result of allowing owners to use their own devices as we see fit!
my last ota update 9.18.94 and i have lock bootloader(((
Will this work for the Xt609 milestone plus also ?
Impressive work.
any chance we my see a similar (or new) tool for the Moto X and new Droids?
i'm new in this tropic , i want to unlock my phone (razr hd xt926) bootloader, but motorola site said my phone does not qualified to unlock the bootloader, and i also tried "motopocalypse" but i received "TrustZone write failed: -11" error.
is there anyway to unlock my phone bootloader.? please help me.
Thanks
The procedure is c4 classified especially to a potentially Qualcomm insider and by your questions it's obvious you are trying to 're reverse the vulnerability in the secure zone!
The main reason we use locks everywhere is that they provide us with a sense of security. But in movies and on television, spies, detectives and burglars can open a lock very easily, sometimes using only a couple of paper clips. Locksmith does their best to give us better security solutions. I like this blog post. Boot loader is also a great thing, there is no way for a user to generate his or her own valid unlock token without either breaking RSA to violate the integrity of the CID partition.
how exactly do i implement this exploit into a workable file or script that i can use to unlock the phone. i get the concept, but have no idea how to actually make this work as an exploit. what do i do? where do i enter this code? you know, those things. i currently have such a locked phone.
nice article
Thanks for the hint to upgrade from Aurora (Firefox 31.1aurora) by forcing a reboot 6 times with this page. Doesn't get simpler than that as ad impressions go...
Nice post! Provides some good info for people evaluating different approaches. In the proxy part, you might want to mention that it does introduce a little overhead. It's usually small compared to the benefit that you get from it, but still significant.
hello friend recently had my bricked bootloader on xt motorola 925 .. saw a toutorial on xda on the moto x with a process to restore the bootloader with a .bin image , I wonder if it would be possible to get this .bin image bootloader razr hd xt925 and also the image hex msm8960.hex .
my computer to the connected device appears only the USB port Qualcoom HS_USB QDloader 9008
thanks for your post
agadeço if you have any solution
thank you
Is there a way for us users who don't know how to use those exploit codes, I only know the fatboot trick but it gives me an error saying that unlocking bootloader is disabled...
Are you saying that with this you can still do it? If so, how?
how do I unlock my Republic Wireless Moto E with this information? motorola has told me that my device does not qualify for unlock. I have Windows XP and fastboot, but do I need a linux machine?
Thanks for the awesome post! it's good to know there is hope.
@Dan Rosenberg sir can you make another exploit for our xt907 183.46.15 bootloader
Grateful to check out your website, I seem to be ahead to more excellent sites and I wish that you wrote more informative post for us. Well done work.
Hello, can anybody please tell me if Motorola Moto X XT1060 Verizon Variant's bootloader can be unlocked? This stuff is kind of advanced. Anybody who knows how to unlock it please help me! Thanks.
Dan
Thank you so much for the very informative content. I believe you mentioned that from the non-secure world one can not execute code in secure world even with Kernel access? Would you elaborate on that? How did you validate this?
Dan, what about RAZR MAXX? It is OMAP device and its bootloader can be unlocked - it supports oem unlock function. However, it is different from Qualcomm. Well, there are more OMAP4 devices which can be unlocked natively, but they aren't included in the Motorola's unlock program. What if there's an eFuse too?