View Full Version : Reverting .621 to .602/.605

04-19-2012, 11:02 PM
So, we may have a final solution to this .621 problem. This will be following the lead of the D2G on their recent un-revertable update (for those unaware, Moto has made it habit over the last few months to roll out updates similar to what came out on the DX to the similar devices).

What needs to happen is we need to brick our DX, and then save it with a custom SBF.

Essentially, we SBF to .602, let it brick, and then take a compiled SBF (which includes the recoveries and BL from .621) and flash that on top. NOTHING else. This will allow us to be on .602/.605 (or feasibly as early as .340, as we can replace the kernel). Which means we can revert.

The SBF file has to be depacked, the custom files inserted, and a custom SBF has to be built.

mhouser @Rootz posted up a copy. I have tried it and had issues, however I am on BL 30.03, which may be the cause of the issues. I did try pulling the 30.03 ramdisk portions out of the .340 update and recompiling the SBF, but had the same issue.

Regardless, after flashing .602 and the patch I was able to get it past the bootlogo before I got bootloader errors, which is further than .602 usually takes it. So we are almost there I believe.

I would like to take this a step further and do what has happened on the Defy+. Essentially they had an unrevertable update, and by mounting CG39 in Linux they were able to successfully inject su and binaries into system properly symlinked.

What this means is a pre-rooted SBF file, which would be awesome.

Anyways, you can see various threads here:

D2G thread:
[How-to] [SBF] unbricking & root D2g 629 - Droid 2 / R2D2 / Milestone 2 / Droid 2 Global - RootzWiki
DX thread:
Recover to 4.5.602 from 4.5.621? - Droid X - RootzWiki
Defy+ thread:
DFP-188, DFP-231, DFP-2311 BL7 Finally Rooted - xda-developers
For anyone who knows me, see if you can tell what's wrong with the below picture (tease):


Nemo aeternamn
04-19-2012, 11:10 PM
intresting... my x is just sitting around these days... i might have to try this

post script: and what's wrong is the radio... 621 has the 15p radio... not the 13p radio... am i right?

04-19-2012, 11:26 PM
That's good there almost there..

ⓡⓞⓛⓛ ⓣⓘⓓⓔ ⓡⓞⓛⓛ

04-20-2012, 12:04 PM
intresting... my x is just sitting around these days... i might have to try this

post script: and what's wrong is the radio... 621 has the 15p radio... not the 13p radio... am i right?

Right. It appears the .602 SBF took but I couldn't get out of the bootloader. But the radio flashed. So it appears everything else took.

04-20-2012, 12:08 PM
Nemo I'd really appreciate if you would brick your X for us hhaha.
I'm sure you'd help out tons of people if you did it.
And I wouldn't mind having the 15p radio either haha.


04-20-2012, 03:46 PM
Other people tested it on BL 30.04 and had the same issues.

I also tried pulling the CGs out of 621 and put in to the 602 SBF and recompiled, I had compiling errors though. I'll try it again when I get more time.

04-21-2012, 11:54 PM
Update: Skreelink has made a modified CG39 which includes su and binaries. He is currently working on getting it injected in an sbf_flash.

This would be following the Defy lead. If this is able to be pulled off, Moto may have a big problem on their hands (well, if they care)

Essentially, we can modify the CG39 (which is the system portion, as is mountable) and then it can be reinjected into an SBF file and it will be taken in sbf_flash.

What this means is as long as we have an SBF, we may have a way to achieve root regardless, period. Unless if/when Moto updates how they work their firmware away from an SBF file. Feasibly, all SBF files are modifiable in this way. What this means is we could crack open the .621, the .605, etc. SBF. We could inject a modified system portion (CG39) which includes su and binaries, and rebuild the SBF file. So we would have pre-rooted SBF files available.

Since we can also inject RDL files (ramdownloader, parts that write to the ramdisk which is the "locked bootloader" part) we may also be able to revert from .621 this way. This is part is all in the realm of *maybe* but it might work. Just include the .605 RDL versions in the SBF.

There's relevant threads kinda scattered around Rootz, but I'll update here whenever necessary if any progress is made. Could be pretty big news if possible.

04-22-2012, 12:38 AM
Wow.. that's amazing news.
Mindblowing but amazing


04-22-2012, 01:48 PM
noob question, im on .605(GB) and verizon is try to push the .621 update to my DX, what are my options? as it keeps asking me to update and dont want to brick my phone if i can help it.

04-23-2012, 09:35 AM
noob question, im on .605(GB) and verizon is try to push the .621 update to my DX, what are my options? as it keeps asking me to update and dont want to brick my phone if i can help it.


05-03-2012, 05:29 PM
So, figured I'd post an update here in case anyone thought this little side project may be dead:

So, for those that want to get all up and technical, I've found out what breaks reversion.

The specific code file CG31.smg. This is the cdt file. The cdt file is what maps the rest of the file and it also the file that is referenced by the mbm (Motorola Boot Manager) when doing signature verification/validation.

This is also what is breaking reversion. Changes in CG31, of some sort, are breaking reversion.

Flashing/SBFing appear successful, but when it validates the file upon bootup it is validated the the cdt file is invalid which gives the MEM_MAP error (the cdt is the MEM_MAP).

Now, without being able to open the cdt/MEM_MAP file I am unsure if it is signature or changes in the cdt table that are breaking validation. But it is most definitely what *is* breaking reversion.

Using the write_raw_data command in Clockwork allows us to apparently successfully overwrite the cdt file to one which is preferred (say .602) but when bootup gives command to the cdt to draw the memory it fails.

So... further digging. Next step is to see if I can mount the cdt.bin to determine differences. Its signed, so no changes can be made and recompiled, but it may be a bit useful leading forward.

This also means it will likely not be possible to flash the .621 kernel without reversion being broken, unless we can literally break the reversion on .621. FWIW.

Got it opened in a diff utility as we speak, most of its encrypted, appears all the normal firmware stuff is the same, however it appears to use a different signing at the end... :( Need to see if I can find out where its pointing to.

05-03-2012, 08:26 PM
Thanks for the update Goose. I take it you had found another tester then

Sent from my DROIDX using Xparent ICS Tapatalk 2

05-03-2012, 09:43 PM
Thanks for the update Goose. I take it you had found another tester then

Sent from my DROIDX using Xparent ICS Tapatalk 2

Myself :) Haha. I've been working on writing different portions of an SBF via CWM, seeing what causes kernel panics and what causes MEM_MAP errors. SBF'd about 10 times today, then decided I was burnt out on it for today. But got a lot of good info :)

05-03-2012, 09:49 PM
Oh snap haha..:beer:

Sent from my DROIDX using Xparent ICS Tapatalk 2

05-03-2012, 09:51 PM
Good luck Goose, hope it works out better for ya :)

teleported from MI Wizardry UI DXtreme

05-06-2012, 12:34 AM
Anyone else want to make their eyes bleed for a bit? (Encrypted files)

Here's the diff on a simple Merge/Diff of the binary on the CDT:



05-06-2012, 01:12 AM
I need some eye drops now :)

teleported from MI Wizardry UI DXtreme

05-06-2012, 12:13 PM
Thought I'd register over here and see what mess I can get into... Time to get my hands a little bit more dirty on the DX since it's not a 'carry' phone for me, so it's not a major problem if I leave it bricked overnight. Swapped my service to my Droid 2, which I wish had more development... :(

Goose, I wonder if the bootloader has certain verification checks that we can't look into. Maybe bootloader checks CDT, then CDT checks everything else? That would be an understandable assumption since you can write the CDT with raw write. Wonder if it's verifying the entire file, or possibly just some headers... All falls back to the encrypted bootloader, thanks Moto.

Since we've obtained root for 621, I guess side-project trying to return to 602/605 is the next step for fun eh? Wonder if (lol no) it'd theoretically be probably to reversion back to Eclair if a way is found to pass the boot verification for the flashed files in an SBF. Then again, I'm still wondering if some kind of check in the bootloader was changed/added in 621's 30.04.

05-06-2012, 11:59 PM
So, update 3 - this is again mostly copy-pasted from Rootz, but in case anyone is wondering, this is a bit of a wandering post as it also describes what can be done with decompiled SBFs and whatnot (in case anyone else was wondering):

There is a few things you can do with decompiled SBFs:

There is a few very useful items here:

http://and-developer.../partitions:cdt (http://and-developers.com/partitions:cdt)

If you scroll down there is a Droid X section. It details all the different CG numbers and what they correspond to. As they are in binary format, you can do some things with them. As the main files (mbm, kernel, cdt, recoveries) etc. are written to the phone in binary all you have to do is literally change the name on them and they correspond to that. However, as soon as you attempt to modify/open them you break the precious header data which contains the signature validation. But we are able to extract them and use them in their current form in .zip files using the write_raw_data command (you can find this in the kernel update, for example).

The CDT (that which breaks reversion) is essentially what maps out all these different sections, thus the MEM_MAP. Its signature is a base 1 according to that website's coding system, which essentially means its full-on 2048 RSA security (that which cannot be hacked... http://rootzwiki.com/public/style_emoticons/default/android/wink2.png )

Some items are unsigned, and some are signed and validated at every boot, and some are only validated at first boot. All that is described there.

Effectively, because of the CDT changes, which IS new signatures, it makes it unrevertable. I verified via opening the CDT in binary that the actual MEM_MAP is untouched e.g. the its not something new in the system that breaks it. What DOES break it is the new signatures (at least as far as I can tell... I mean I'm staring at encrypted binary so yeah... lol) but I'm about 95% positive this is it. I can tell the portion that contains the MEM_MAP is untouched because the MEM_MAP is the top third of the CDT and there is no diff between it and .602.

So, the CDT basically controls everything we do, at least as far as writing the raw data or kernels, etc. which is what we want to get out of this. So we are effectively in a catch-22 - because of the new CDT we cannot write old code otherwise the signature validation will fail on boot. Even if we try forcing it to write the old CDT table using the write_raw_data command it doesn't take. HOWEVER if we DO write the .602 CDT table using said command we no longer get the MEM_MAP BLANK error in bootloader. We will still get a bootloader error, but it is coded differently. What this means is the consistency of the MEM_MAP is unaffected, however signature validation has failed. This is the holy "e-fuse" - its not as exciting as it sounds, lol. And yes, that means I have e-fused my DX. All you do is SBF afterwards (it really does appear to be nearly impossible to soft-brick the X) I'm guessing and/or assuming that we get MEM_MAP BLANK when using the SBF file because the SBF does a signature validation check while flashing and because it does not match it does not overwrite the CDT, which breaks a bunch of stuff at that point.

In a way, Skreelink is right... it IS the MBM (Motorola Boot Manager) that is stopping us from reverting back, but the MBM gets its signatures from the CDT. Which means all roads eventually lead to the CDT. I can verify the MBM signatures are NOT changed, as I did update my MBM from 30.03 to 30.04 using write_raw_data while on .621. So its not an updated MBM/Bootloader, but its the CDT table file.

So... where does this leave us? Well I don't know. LOL. I'm still trying and failing to merge CDT files and try different versions of recovery/etc getting swapped either in a recompiled SBF or via write_raw_data. I've gotten a few different bootloader errors... but they are always bootloader errors.

BTW, you can load up the /system portion of the SBF in Linux and get its contents. However changing it is chancy. You effectively have a certain number of bytes to work with otherwise you break its headers and it won't flash when its recompiled. There's info at XDA about the terminal commands needed to mount that portion in Linux. This is how it may be feasible to make a pre-rooted SBF, as it has been done on a few phones.

So, I am looking at two possibilities. First, I want to find where the radio is written in the SBF, as its never clearly delineated. If I can do that, I want to pull the .15p radio from the .621 and put it in a .605 and a .604 SBF. This way we can use RSD Lite to SBF to the Milestone X rootable firmware, and those still on .605 can upgrade the radio by performing a simple SBF rather than having to go to Froyo. Still trying to figure this one out.

If I can pull that off, then I would want to attempt making a pre-rooted /system portion on the .621 SBF and .605 SBF. Then, we would have a pre-root, .15p radio, SBF file available for anyone.

Finally, and the big one, is still reversion? Can it be broken? I've kinda taken this as a personal quest, but I only have so much time between work, college, girlfriend, etc. to be SBF'ing my phone over and over. LOL.

So we'll see. I don't know if anyone of this is possible, but it'd be awesome if I got it, I know that much. :)

05-07-2012, 12:24 AM
Just want to say thank you Goose. Thanks for putting so much time and effort in to this project and going above and beyond to make this into reality, I hope it works out and if it doesn't, I'm sure you learned a lot from it and those ideas will be used again for something else. Thanks again :)

teleported from MI Wizardry UI DXtreme