Bspatch. Trying to get ICS stuck CDMA Razrs back on the path.

Search This thread
By:
Advanced…
S

SilentViper

Member
Jan 26, 2010
16
3
Knowing the methods Matt used, and that updates use the same applypatch method update.zip uses. They would have to change pre existing releases to patch this method


Edit: thanks Matt!
Sent from my DROID RAZR using XDA
 
X

xlightwaverx

Senior Member
Jun 27, 2010
99
28
www.crackflasher.com
SilentViper said:
Knowing the methods Matt used, and that updates use the same applypatch method update.zip uses. They would have to change pre existing releases to patch this method


Edit: thanks Matt!
Sent from my DROID RAZR using XDA
Click to expand...
Click to collapse

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
 
Last edited:
S

SilentViper

Member
Jan 26, 2010
16
3
xlightwaverx said:
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
Click to expand...
Click to collapse

Logically and theoretically what you are saying makes sense. I was going to try that first chance i get. Since i just realized that i have the fastboot screen burned in I'm more willing to screw with my second phone

Sent from my DROID RAZR using XDA
 
Q

Q9Nap

Senior Member
Feb 13, 2009
1,018
1,893
So does the no corruption bspatch posted in the op make a flashable boot.img? i used it to patch the bionic 5.9.905 boot.img with boot.img.p from the latest 6.7.235 leak and it does create a file; however the new boot.img is different than the boot.img included in matt's DroidBionicUnstuck.zip utility. I know i can just use the image from this utility, but want to have the technique ironed out for future reference.

is the method from this post...

http://xdaforums.com/showthread.php?t=1702233

...still the only way to successfully patch boot.img?
 
mattlgroff

mattlgroff

Inactive Recognized Developer
Dec 5, 2011
2,289
2,445
San Diego
Q9Nap said:
So does the no corruption bspatch posted in the op make a flashable boot.img? i used it to patch the bionic 5.9.905 boot.img with boot.img.p from the latest 6.7.235 leak and it does create a file; however the new boot.img is different than the boot.img included in matt's DroidBionicUnstuck.zip utility. I know i can just use the image from this utility, but want to have the technique ironed out for future reference.

is the method from this post...

http://xdaforums.com/showthread.php?t=1702233

...still the only way to successfully patch boot.img?
Click to expand...
Click to collapse

The stickied method thread by myself for patching boot.IMG is the only way I know of.

Sent from my Galaxy Nexus using Tapatalk 2
 
  • Like
Reactions: Q9Nap
You must log in or register to reply here.

Similar threads

Hashcode
[ROM] [CDMA/GSM] Official CM10.1 (JB 4.2.2)
Replies
4K
Views
891K
T
t-mobile_mda
K
[4.4.4][CDMA/GSM] Official CM11 Nightlies (Snapshot M12 Update 5/28/15)
Replies
9K
Views
1M
D
Dudefoxlive
hacker812c
  • Locked
[ROM][GSM][CDMA] Razr Android 4.2.2 Official MIUI V5 [06 Dezember]
Replies
2K
Views
466K
ApriliaM3
ApriliaM3
FrAsErTaG
[ROOT] ROOT FOR DROID RAZR [GSM/CDMA] [GB/ICS] [Windows Only]
Replies
310
Views
310K
S
soadcma
K
[GSM/CDMA] The EternityProject Official Motorola RAZR ROMs Thread
Replies
457
Views
313K
M
MetaruSonikkuX

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 6
    mattlgroff
    mattlgroff
    So... a lot of us are stuck on a certain firmware and need to get off of it. A solution to us all (hopefully), is a program called "bspatch" (usually comes with bsdiff). We have a boot.img file (compiled android img) and a boot.img.p (from an OTA update, zip, which we know 100% works and people have updated with the OTA zip).

    We need bspatch to stop checking for corruption like it does now and to just force the patch to go. This would help save a lot of users stuck on firmware and we would all appreciate a point in the right direction.

    We tried compiling the source of bspatch from many sites, but none seem to compile correctly or even run. We get them to run from binary pre-compiled versions, but those won't help us since it sees the patch as corrupt.

    If we can get boot.img from the 6.12.181 fastboot files to patch with the boot.img.p from an ICS like the most current (6.16.206 as of 5/20/2012) we can make a fastboot files that is flashable onto someone stuck on 6.14.84 so they can upgrade to 206 with Moto Recovery.

    Also if this magically can be done by the help of the XDA community, we can create a boot.img from 6.12.181 patched with a 4.0.3 boot.img.p (like from 84 or 85, since 79 and below aren't flashable on newer ICS), we can also have a root method for 4.0.4 like the GSM users have.

    Best of luck to those who try to help with this!

    http://www.daemonology.net/bsdiff/

    https://launchpad.net/ubuntu/+source/bsdiff/4.3-10ubuntu1/+build/2960721

    Files(s): http://rombot.droidhive.com/ROMs/spyder/BspatchProject.zip
    alt link: http://www.filefactory.com/file/1xj6eh1mocz7/n/BspatchProject_zip

    Note: My friend tried this already and we got Pre-flash validation errors when trying to fastboot it. Just throwing this idea out there.... best of luck.
    EDIT: Added as an attachment.

    Thanks to dhacker29 for trying this idea out first :D
    View
    3
    whirleyes
    whirleyes
    Err.. Doesn't the /system/bin/applypatch can do this already??
    I've always used it to patch OTA manualy..

    example usage:
    Code: 
    applypatch boot.img boot_new.img [B]X Y Z[/B]:boot.img.p
    where
    Code: 
    [B]X[/B] is the target(boot_new.img) sha1sum
[B]Y[/B] is the target(boot_new.img) new size
[B]Z[/B] is the source(boot.img) sha1sum

    Obviously it will failed the cert test,
    if the patch(boot.img.p) is not intended for the base(boot.img)

    Information can be extracted from OTA update-script

    example
    assert(apply_patch("MTD:boot:8388608:5fff8425560eb 1002b467062de2b355b45090ad7:8388608:2997ddb421e1d4 4b026410339e343f60b3bb65bd",
    "-", 2997ddb421e1d44b026410339e343f60b3bb65bd, 8388608,
    5fff8425560eb1002b467062de2b355b45090ad7, package_extract_file("patch/boot.img.p")));
    Click to expand...
    Click to collapse

    X = 2997ddb421e1d44b026410339e343f60b3bb65bd
    Y = 8388608
    Z = 5fff8425560eb1002b467062de2b355b45090ad7

    easily done via adb

    Code: 
    adb.exe push boot.img /tmp/
adb.exe push boot.img.p /tmp/
adb.exe shell /system/bin/applypatch /tmp/boot.img /tmp/boot_new.img X Y Z:/tmp/boot.img.p
adb.exe pull /tmp/boot_new.img
    View
    1
    S
    SilentViper
    whirleyes said:
    Err.. Doesn't the /system/bin/applypatch can do this already??
    I've always used it to patch OTA manualy..

    example usage:
    Code: 
    applypatch boot.img boot_new.img x y z:boot.img.p
    where
    Code: 
    x is the target(boot_new.img) sha1sum
y is the target(boot_new.img) new size
z is the source(boot.img) sha1sum

    Obviously it will failed the cert test,
    if the patch(boot.img.p) is not intended for the base(boot.img)
    Click to expand...
    Click to collapse


    I can confirm that applypatch does have at least some success in patching a boot.img once you can figure out the information required from updater-script found in the OTA you are trying to make fastboot images for. I patched the file obtained by
    Code: 
    dd if=/dev/block/mmcblk1p14 of=/sdcard-ext/b/boot.bin
    on a 6.12.181 successfully using the code
    Code: 
    applypatch ./boot.bin ./boot.bin.2 dd9310794842a4908aff55979a9fe97f825e8748 8388608 8e21cfa5d9be4dd08427b079fbff9a80d6e04560:boot.img.p

    the code i ripped apart from 6.16.206 is
    Code: 
    assert(apply_patch("MTD:boot:8388608:8e21cfa5d9be4dd08427b079fbff9a80d6e04560:8388608:dd9310794842a4908aff55979a9fe97f825e8748",
       "-", dd9310794842a4908aff55979a9fe97f825e8748, 8388608,
       8e21cfa5d9be4dd08427b079fbff9a80d6e04560, package_extract_file("patch/boot.img.p")));



    to figure out the apply patch code i looked at the info above and compared it to this
    [qoute]adb shell applypatch
    usage: applypatch <src-file> <tgt-file> <tgt-sha1> <tgt-size> [<src-sha1>:<patch> ...]
    or applypatch -c <file> [<sha1> ...]
    or applypatch -s <bytes>
    or applypatch -l

    Filenames may be of the form
    MTD:<partition>:<len_1>:<sha1_1>:<len_2>:<sha1_2>:...
    to specify reading from or writing to an MTD partition.[/quote] and with a little trial and error got it to work :D


    EDIT
    Let me be clear the patched boot.bin.2 does flash perfectly fine. no preflash validation failure.
    Anyone on 6.16.206 want to do me a favor and do?
    Code: 
    dd if=/dev/block/mmcblk1p15 of=/sdcard-ext/b/recovery.bin
    and email/upload it to me? I'll hit the thanks button :) </bribe>
    View
    1
    D
    dimitri407
    This is what a user at DroidRzr got when he tryed:

    dd if=/dev/block/mmcblk1p15 of=/sdcard-ext/b/recovery.bin

    [quote name='Fixter' timestamp='1337690349' post='46825']
    Doing it right now Matt.
    PS: Cannot Open for Read: Permission Denied
    Also, I have root. Let me check now. I forgot to restore root.

    Update 2: Cannot Open for Write: No such file or Directory. I copy pasted it, so I know it's right.
    [/quote]
    View
    1
    S
    SilentViper
    mattlgroff said:
    He might need to do
    Code: 
    mkdir /sdcard-ext/b
    Click to expand...
    Click to collapse


    http://www.mediafire.com/?iihwd669mdxg740
    Recovery.bin from DR user Fixter from 206.
    Enjoy!
    Click to expand...
    Click to collapse

    AWESOME. I successfully flashed that to my secondary razr that i am playing with these updates on. I used this plus my custom patched boot.bin.2 to successfully boot into recovery. but im currently stuck there because no OTAs will flash from that, and my /system partition isn't the right version, nor anything else for that matter. now I need the rest of the /dev/block files from 206 :/

    i'm going to have to figure something out quick
    View

New posts