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? ]
There is only one way to find out if it would work. And that is to keep working on it.