438 replies to this topic

[JungleKing76]

Has anybody tried to replace the cdt.bin from the 181 fb file with the one from the leaks and fastbooting with rsd? Should I be the guinea pig?

Already tried. It sill fails the "pre flash verification". I have tried manipulating the fb files every which way but it just won't work.

I did notice that all gb builds and the two ics builds that are fastbootable only have one file called cdt. But the leaks that get us stuck (84 & above) have two cdt files.

Sent from my DROID RAZR using Xparent Purple Tapatalk

[JungleKing76]

Real quick..... after manually trying to go back to 181 from 84 i stopped after the cdt preflash failure....now my phone works fine but everytime i shutdown or reboot the bootloader pops up with flash failure and i have to reboot into the bootloader and boot from there.....annoying but phone works fine..... anyone know a fix?

Sent from my DROID RAZR using Tapatalk

The same thing happened to me. The phone works fine but like you said it is annoying to always have to boot from fastboot menu.

The only fix i could find was to use the utility to flash 181 fastboot files, then go into sick recovery and flash whatever leak you are stuck on again. The downside is you have to wipe data.

Sent from my DROID RAZR using Xparent Purple Tapatalk

[cconcepts]

Thanks man!

Sent from my DROID RAZR using Tapatalk

[theonlycosmic]

Already tried. It sill fails the "pre flash verification". I have tried manipulating the fb files every which way but it just won't work.

I did notice that all gb builds and the two ics builds that are fastbootable only have one file called cdt. But the leaks that get us stuck (84 & above) have two cdt files.

Sent from my DROID RAZR using Xparent Purple Tapatalk

It fails because of the new way we are going to have to fast boot. Since there are more than one cdt.bin files now, there has to be a certain way to flash them. It will be made clear when fb files for official ics come out.

Sent from my DROID SPYDER using Tapatalk 2

[xlightwaverx]

just because you see two files does not mean two get written. the update script deciphers with you have an 8 gig or 16 gig and it writes it accordingly.

we have successfully bypassed the cdt.bin file using a p18 block pulled with the cat command from 181 then cat'd back to /dev/block on 85, restarted and then fast boot flashed that file.

there are still 3 other partitions that require pre flash validation. someone else get on this besides me. I already am somewhat responsible for 1 bricked phone.

you're going to have to use the dd command whereas cat is for textual data.

X



Sent from my DROID RAZR using Tapatalk 2

[xlightwaverx]

we need to find the partition that is connected to dev tree and how dev tree is connected to the block.

X

Sent from my DROID RAZR using Tapatalk 2

[SilentViper]

we need to find the partition that is connected to dev tree and how dev tree is connected to the block.

X

Sent from my DROID RAZR using Tapatalk 2

im pretty sure /dev/block/mmcblk1p11 is devtree

/dev/block/mmcblk1p12 is devtree_backup

at least heres the commands i used / found to make a block back up

Please Login or Register to see this Hidden Content

[xlightwaverx]

What command did you use to pull up those symlinks?

X


Sent from my DROID RAZR using Tapatalk 2

[SilentViper]

What command did you use to pull up those symlinks?

X


Sent from my DROID RAZR using Tapatalk 2

i found them on some post somewhere; i came accross them again at

Please Login or Register to see this Hidden Content

[xlightwaverx]

i found them on some post somewhere; i came accross them again at

Please Login or Register to see this Hidden Content

Oh that's the Chinese Razr, we're different. Got excited, we gotta find those symlinks. I know its a simple linux command. Cmon people.

[xlightwaverx]

These are the only blocks I can find. But looky, we have more symlinks under the "secure" bootloader section as well. Maybe those are the culprits that we can override with .181 version, and get past prevalidation errors.

Using "find -type l"

/dev/block/emstorage
/dev/block/userdata
/dev/block/webtop
/dev/block/preinstall
/dev/block/cache
/dev/block/system
/dev/block/kpanic
/dev/block/cid
/dev/block/misc
/dev/block/cdrom
/dev/block/recovery
/dev/block/boot
/dev/block/utags
/dev/block/pds
/dev/block/platform/mmci-omap-hs.1/mmcblk1p26
/dev/block/platform/mmci-omap-hs.1/mmcblk1p25
/dev/block/platform/mmci-omap-hs.1/mmcblk1p24
/dev/block/platform/mmci-omap-hs.1/mmcblk1p23
/dev/block/platform/mmci-omap-hs.1/mmcblk1p22
/dev/block/platform/mmci-omap-hs.1/mmcblk1p21
/dev/block/platform/mmci-omap-hs.1/mmcblk1p20
/dev/block/platform/mmci-omap-hs.1/mmcblk1p19
/dev/block/platform/mmci-omap-hs.1/mmcblk1p18
/dev/block/platform/mmci-omap-hs.1/mmcblk1p17
/dev/block/platform/mmci-omap-hs.1/mmcblk1p16
/dev/block/platform/mmci-omap-hs.1/mmcblk1p15
/dev/block/platform/mmci-omap-hs.1/mmcblk1p14
/dev/block/platform/mmci-omap-hs.1/mmcblk1p13
/dev/block/platform/mmci-omap-hs.1/mmcblk1p12
/dev/block/platform/mmci-omap-hs.1/mmcblk1p11
/dev/block/platform/mmci-omap-hs.1/mmcblk1p10
/dev/block/platform/mmci-omap-hs.1/mmcblk1p9
/dev/block/platform/mmci-omap-hs.1/mmcblk1p8
/dev/block/platform/mmci-omap-hs.1/mmcblk1p7
/dev/block/platform/mmci-omap-hs.1/mmcblk1p6
/dev/block/platform/mmci-omap-hs.1/mmcblk1p5
/dev/block/platform/mmci-omap-hs.1/mmcblk1p4
/dev/block/platform/mmci-omap-hs.1/mmcblk1p3
/dev/block/platform/mmci-omap-hs.1/mmcblk1p2
/dev/block/platform/mmci-omap-hs.1/mmcblk1p1
/dev/block/platform/mmci-omap-hs.1/by-num/p26
/dev/block/platform/mmci-omap-hs.1/by-num/p25
/dev/block/platform/mmci-omap-hs.1/by-num/p24
/dev/block/platform/mmci-omap-hs.1/by-num/p23
/dev/block/platform/mmci-omap-hs.1/by-num/p22
/dev/block/platform/mmci-omap-hs.1/by-num/p21
/dev/block/platform/mmci-omap-hs.1/by-num/p20
/dev/block/platform/mmci-omap-hs.1/by-num/p19
/dev/block/platform/mmci-omap-hs.1/by-num/p18
/dev/block/platform/mmci-omap-hs.1/by-num/p17
/dev/block/platform/mmci-omap-hs.1/by-num/p16
/dev/block/platform/mmci-omap-hs.1/by-num/p15
/dev/block/platform/mmci-omap-hs.1/by-num/p14
/dev/block/platform/mmci-omap-hs.1/by-num/p13
/dev/block/platform/mmci-omap-hs.1/by-num/p12
/dev/block/platform/mmci-omap-hs.1/by-num/p11
/dev/block/platform/mmci-omap-hs.1/by-num/p10
/dev/block/platform/mmci-omap-hs.1/by-num/p9
/dev/block/platform/mmci-omap-hs.1/by-num/p8
/dev/block/platform/mmci-omap-hs.1/by-num/p7
/dev/block/platform/mmci-omap-hs.1/by-num/p6
/dev/block/platform/mmci-omap-hs.1/by-num/p5
/dev/block/platform/mmci-omap-hs.1/by-num/p4
/dev/block/platform/mmci-omap-hs.1/by-num/p3
/dev/block/platform/mmci-omap-hs.1/by-num/p2
/dev/block/platform/mmci-omap-hs.1/by-num/p1
/dev/block/platform/mmci-omap-hs.1/mmcblk1
/dev/block/platform/mmci-omap-hs.0/mmcblk0p1
/dev/block/platform/mmci-omap-hs.0/by-num/p1
/dev/block/platform/mmci-omap-hs.0/mmcblk0

X

[PWn3R]

xlightwaverx -- if you have the name of the folder or a file in the section you are looking for the symlink location for, do this


find ~ -lname *foldername or file
-- that should find the location that the file is actually in from the symlink

[xlightwaverx]

I can't get it to take. I have a -iname option, but its not pulling anything.

[jerkwad]

i'll see if i can figure anything out tonight - i'm nowhere near new to linux ;-)

lightwaver - are you NOT a linux guy? i would have guessed you were simply by the fact you seem quite knowledgeable about the android OS

[PWn3R]

I can't get it to take. I have a -iname option, but its not pulling anything.

Should be L as in LARRY name so LNAME Not sure if it will work, i can't test right now.

[tucstwo]

I updated the OP with information on how to get off this system version an onto the latest ICS leak. While this doesn't get us on path, it DOES get us off this damn system version an onto 4.0.4. But lets please guys, keep up the good work. I'm super excited to think we may all figure this beast out for sure.

[xlightwaverx]

i'll see if i can figure anything out tonight - i'm nowhere near new to linux ;-)

lightwaver - are you NOT a linux guy? i would have guessed you were simply by the fact you seem quite knowledgeable about the android OS

I'm not anything, but I think very logically. With that in mind, and considering the thread topic, have at this:

So, now that all the stuck ones can go up, and eventually leave GB for good and be solely on ICS, are we done? I kinda feel the need to keep working on an ICS2GB method.

Essentially, whatever version your boot.img is, you can install (by force) whatever build that the boot.img is from. If you are on .84, and you want to go to .85, you would have to patch .181GB-boot.img with .85ICSboot.img.p, flash new boot.img, proceed with recovery (by force) of .85. .84 cannot go to .85 and vice versa unless you issue a new boot.img.p patch off of original .181GB-boot.img and then proceed with that ota version recovery install correct?

Now, if u wanted to go backwards, is this where the CDT.bin file would prevent you from doing that? Because if we fastboot a .181 boot.img, it seems to take fine correct? The only issues are cdt.bin, devtree, cdrom, and recovery.

So since we successfully bypassed the CDT.bin preflash validation by copying (DD) a .181GB mmcblk1p18 to (whatever version of ICS leak you're on), rebooting in to fastboot, and flashing old cdt.bin, no issue arrises.

Now, once at that stage when we (by force) fastboot .181 GB files on after replacing cdt.bin, we receive customer ID error on boots, but cdt.bin is flashed, so customer id error keeps popping up because of the other 3 partitions being mismatched (devtree, cdrom, recovery?) I'm thinking out loud...

So, we if DD .181 cdt.bin (p18) along with recovery, devtree, and cdrom, reboot into fastboot, would the .181 fastboot files then be able to pass preflash validation? At that stage, force OTA update of .181GB over passed validated partitions, and then we would have a full 181 OTA install?

I understand the concept of having a locked bootloader, but when we DD these images out of .181GB, wouldn't these images retain their signature? Phew, that's a lot of typing, and then again, thinking out loud.

X

[_base2]

I'm not anything, but I think very logically. With that in mind, and considering the thread topic, have at this:

So, now that all the stuck ones can go up, and eventually leave GB for good and be solely on ICS, are we done? I kinda feel the need to keep working on an ICS2GB method.

Essentially, whatever version your boot.img is, you can install (by force) whatever build that the boot.img is from. If you are on .84, and you want to go to .85, you would have to patch .181GB-boot.img with .85ICSboot.img.p, flash new boot.img, proceed with recovery (by force) of .85. .84 cannot go to .85 and vice versa unless you issue a new boot.img.p patch off of original .181GB-boot.img and then proceed with that ota version recovery install correct?

Now, if u wanted to go backwards, is this where the CDT.bin file would prevent you from doing that? Because if we fastboot a .181 boot.img, it seems to take fine correct? The only issues are cdt.bin, devtree, cdrom, and recovery.

So since we successfully bypassed the CDT.bin preflash validation by copying (DD) a .181GB mmcblk1p18 to (whatever version of ICS leak you're on), rebooting in to fastboot, and flashing old cdt.bin, no issue arrises.

Now, once at that stage when we (by force) fastboot .181 GB files on after replacing cdt.bin, we receive customer ID error on boots, but cdt.bin is flashed, so customer id error keeps popping up because of the other 3 partitions being mismatched (devtree, cdrom, recovery?) I'm thinking out loud...

So, we if DD .181 cdt.bin (p18) along with recovery, devtree, and cdrom, reboot into fastboot, would the .181 fastboot files then be able to pass preflash validation? At that stage, force OTA update of .181GB over passed validated partitions, and then we would have a full 181 OTA install?

I understand the concept of having a locked bootloader, but when we DD these images out of .181GB, wouldn't these images retain their signature? Phew, that's a lot of typing, and then again, thinking out loud.

X

That thing about being logical is an understatement!! This makes a tremendous amount of sense to me... and I think you're onto exactly what we're looking for.

Since, even with a locked bootloader, we're able to successfully copy the cdt.bin to bypass the preflash validation, then it would certainly stand to reason that dd-ing the other blocks similarly would have similar effects on bypassing preflash validation for those blocks as well.

[ what path? ]

[Thach]

Sometimes logic is all you need.

Sent from my Motorola Xyboard WiFi (XOOM 2 ME)

[tucstwo]

I'm not anything, but I think very logically. With that in mind, and considering the thread topic, have at this:

So, now that all the stuck ones can go up, and eventually leave GB for good and be solely on ICS, are we done? I kinda feel the need to keep working on an ICS2GB method.

Essentially, whatever version your boot.img is, you can install (by force) whatever build that the boot.img is from. If you are on .84, and you want to go to .85, you would have to patch .181GB-boot.img with .85ICSboot.img.p, flash new boot.img, proceed with recovery (by force) of .85. .84 cannot go to .85 and vice versa unless you issue a new boot.img.p patch off of original .181GB-boot.img and then proceed with that ota version recovery install correct?

Now, if u wanted to go backwards, is this where the CDT.bin file would prevent you from doing that? Because if we fastboot a .181 boot.img, it seems to take fine correct? The only issues are cdt.bin, devtree, cdrom, and recovery.

So since we successfully bypassed the CDT.bin preflash validation by copying (DD) a .181GB mmcblk1p18 to (whatever version of ICS leak you're on), rebooting in to fastboot, and flashing old cdt.bin, no issue arrises.

Now, once at that stage when we (by force) fastboot .181 GB files on after replacing cdt.bin, we receive customer ID error on boots, but cdt.bin is flashed, so customer id error keeps popping up because of the other 3 partitions being mismatched (devtree, cdrom, recovery?) I'm thinking out loud...

So, we if DD .181 cdt.bin (p18) along with recovery, devtree, and cdrom, reboot into fastboot, would the .181 fastboot files then be able to pass preflash validation? At that stage, force OTA update of .181GB over passed validated partitions, and then we would have a full 181 OTA install?

I understand the concept of having a locked bootloader, but when we DD these images out of .181GB, wouldn't these images retain their signature? Phew, that's a lot of typing, and then again, thinking out loud.

X

wow, Holy Crap man, I understand about 6% of your thinking here but that's because of my ignorance and nothing else. I hope if you do have a way to implement what you just said then a lot of people will be happy. Not only to get on path but it seems almost like a bootloader bypass? Keep up the good work. If anything solid comes from all of your thinking here, I will most certainly update the OP with whatever you come up with.