Hacking erroneous output of SBF Codec

[Shibbey]

More solved

Oh dancedroid

I just solved where all the mystery bytes come from. I think. I am too tired to post it right now. I will do it when I wake up. Maybe not where they come from, but what they mean at least.

Big hint: look at SBF-Recalc's section labeled "Read FlashHeader from SBF - File"

 

[MotoCache1]

I found this on a German forum. As I am still new to the Droid hacking world, and am just starting to learn C#, maybe someone else can do something with this to help everyone out!

Excellent diligence Shibbey! To save you further looking, you are correct. This is the proper code to generate the checksums. There are actually an unbelievable number of proprietary checksum algorithms out there for phones, but the one you found does indeed work for SHOLS (Milestone) and SHOLES (Droid 1). It also works for Droid X, etc.

Now, what do you do with that source code?

(Are we having fun yet?)

 

[Shibbey]

SBF layout and detailed byte description

Discoveries Update:

• The SBF is a linear combination of the .HMG then RDL3 then CG42.

• HMG blocks 0-341
• Start Flash Group Flag - Blocks 342-34A
• RDL3 File Size - Blocks 34B-34E
• RDL3 Start Position Marker - Blocks 34F-352
• RDL3 blocks 353-4D352
• RDL3 sum32 hash - blocks 4D353-4D356
• End Flash Group Flag - Blocks 4D357-4D35E
  
• Start Flash Group Flag - Blocks 4D35F-4D368
• CG42 File Size - Blocks 4D369-4D36B
  
• CG42 Start Position Marker - Blocks 4D36C-4D36F
• CG42 blocks 4D370-8D36F
• CG42 sum32 hash - blocks 8D370-8D373
• End Flash Group Flag - blocks 8D374-8D37B

This is the best I can figure. I have also found the 16bit checksum that we are having issues calculating is actually the 2nd and 3rd from last bytes in the HMG file followed by 00.

It is unusual that the sum 32 hashes are generated inside the SBF file, and that 16 byte checksum is inside the HMG file. I wonder why that would be and how we can use this knowledge to progress towards calculating it.

An quick glance at other SBF files, It appears the typical SBF layout goes:

1. HMG file
2. Start Sync Flag
3. File Size
4. Position Marker
5. File
6. sum 32 has of leading file
7. End Sync Flag

• Repeating numbers 2-7 for all included files.

 

[Shibbey]

So, I guess that's the next question for you guys: How would you go about figuring out how to calculate the checksums for the Droid? The direct observation method I just described will work if you are very very good at math. Remember doing differential equations back in calculus and taking big formulas and having to factor them and blah blah blah -- this is kind of the reverse of that. All you are seeing are the answers and you have to figure out what formula is producing them.

Let me know what you come up with. It's possible I don't even have the answer and I just do the RSD Lite trick like everyone else does. Hard to say...

I found this on a German forum. As I am still new to the Droid hacking world, and am just starting to learn C#, maybe someone else can do something with this to help everyone out!

And here is the code for it

(Written in C #, but should serve well as pseudo code)

public static UInt16 GenerateSholsChecksum (byte [] bytes)
{ (
    UInt32 a = 0; UInt32 a = 0;
    UInt32 b = 0; UInt32 b = 0;

    var end = bytes.Length - (bytes.Length % 4); var end = bytes.Length - (bytes.Length% 4);

    for (var i = 0; i < end; i += 4) for (var i = 0; i <end; i + = 4)
    { (
        a += (UInt32)((bytes[i + 1] << 8) + bytes[i    ]); a + = (UInt32) ((bytes [i + 1] <<8) + bytes [i]);
        b += (UInt32)((bytes[i + 3] << 8) + bytes[i + 2]); b + = (UInt32) ((bytes [i + 3] <<8) + bytes [i + 2]);
    } )

    //if the bytes are not multiply of four, pad it with 0 / / If the bytes are not multiply of four, pad it with 0
    var diff = bytes.Length - end; var diff = bytes.Length - end;
    if (diff > 0) if (diff> 0)
    { (
        var nbytes = new byte[4]; var nbytes = new byte [4];

        for (var j = 0; j < 4; j++) for (var j = 0 j <4; j + +)
        { (
            if (j < diff) if (j <diff)
                nbytes[j] = bytes[end + j]; nbytes [j] = bytes [end + j];
            else else
                nbytes[j] = 0; nbytes [j] = 0;
        } )

        a += (UInt32)((nbytes[1] << 8) + nbytes[0]); = a + (UInt32) ((nbytes [a] <<8) + nbytes [0]);
        b += (UInt32)((nbytes[3] << 8) + nbytes[2]); b + = (UInt32) ((nbytes [3] <<8) + nbytes [2]);
    } )

    return (UInt16)(a + b + (a >> 16)); return (UInt16) (a + b + (a>> 16));            
} )

NOTE: For Yaffs2 partitions (they have code 0028) checksum 2048 bytes and you skip next 64 (spare parts).

EDIT: Actually, seeing the DROID sbf, the above applies for address greater than 0xD0000000 mainly.

So guess what. I almost pissed myself tonight! I now have a working program that will calculate the 16 bit checksum for me, instead of using the flash technique. I wrote it with some serious modification and research based on the code above. I was not going to share until I had a distributable copy, but I was so excited, I couldn't wait. Currently it is in beta testing by myself, and hopefully two others that I feel I can trust. I will put a copy out there for everyone once I know it works, and I make it a bit prettier!

 

[Shibbey]

Sholes SBF calculator!

'nuff said!

You know how to use it. No need to change the byte order. Already in Little Endian format!

Sholes SBF Calculator v1.0.0.1.exe

 

[Jharmon12]

WOW its amazing what has been discovered and how far our exploration has gone. I just used Shibbey's calc and it worked perfectly. Thanks I'm definitely going to use the heck out of it right along with MC1'S original cg42 script. Thanks you two and every one else!

Sent from my Droid using Tapatalk

 

[Jharmon12]

I was working on my own custom logo sbf and i decided to look at the RDL3 file and i changed what it said when you install it. I changed the updating software to installing boot logo and changed update complete to Press up now. Heres the sbf if you want to look at it im thinking about changing it to say hold up now but I wanna see what everyone else thinks first.

 

[fish1552]

Guess I had to take care of some stuff offline at a very bad time. Coming back to this thread and seeing all the new updates is amazing.

Good work guys!

 

[mcf517]

Is this applicable to stock sbf flashing?

I have been patiently and diligently perusing many forums and exhausted many avenues of possible solutions. My droid x currently is in a strange state that has not been typical for most rom flashers and I humbly ask for suggestions and advice.

The system reads that I'm on gingerbread 4.5.573, which is the first leaked version of gb. The only way to get anywhere at that point is to sbf back to stock 340 froyo. I keep getting checksums errors on multiple tries on various computers including windows xp, 7, and even Linux.

Here are the very peculiar symptoms my phone has exhibited that I don't see on any other forums. When I reboot, the system goes back to the way it was before I failed the first attempt on flashing back to 340. Apps installed go missing while uninstalled apps go back. Icon placement, ringtones, etc... All just go back to how I had it up until that point. It seems an image of the system was saved at a certain point and now is always being restored when i reboot, making my phone pretty crippled. I maintain root access, but using bootstrap only reboots my phone and never gets access to custom recovery. Factory reset also does nothing, including the ones inside the stock recovery. I have even wiped data and factory reset up to ten times each.

My boot loader is version 3004 and I boot with a red m logo which is gb. The flashing process passes some checksums, which still manage to reset the activation status of my phone. I always have to deactivate via *228 when I ultimately fail to flash 100%.

Here is my error log from Linux while attempting to flash the sbf....

=== VRZ_MB810_2.3.34_1FF_01.sbf ===
00: RDL03 0x82000000-0x8204CFFF 4D63 AP
01: RDL01 0x00150000-0x001FFFFF DEFA BP
02: *CG03 0x00000000-0x008FA367 8A11 BP
03: *CG31 0xB0280000-0xB02847FF 56E0 AP
04: *CG33 0xB1900000-0xB24C07FF 4125 AP
05: *CG34 0xB0700000-0xB07047FF 75F3 AP
06: *CG35 0xB1000000-0xB13FFFFF A91B AP
07: *CG39 0xB2A00000-0xC41C07FF 4432 AP
08: *CG40 0xC4200000-0xC4200FFF FDFF AP
09: *CG42 0xB0800000-0xB083FFFF 7479 AP
10: *CG47 0xB1400000-0xB18FFFFF 0255 AP
11: *CG61 0xB0B00000-0xB0B7FFFF 9804 AP
12: *CG64 0xB0000000-0xB00047FF 1768 AP
13: *CG65 0xB0180000-0xB01847FF 7167 AP
14: *CG66 0xD0000000-0xD7BA87FF 021A AP

waiting for phone: Connected.
uploading RDL03: 100.0%
-- OK
verifying ramloader
-- OK
executing ramloader
-- OK
waiting for phone: Connected.
sending erase
-- OK
uploading CG31: 100.0%
-- OK
uploading CG33: 100.0%
-- OK
uploading CG34: 100.0%
-- OK
uploading CG35: 100.0%
-- OK
uploading CG39: 100.0%
-- OK
uploading CG40: 100.0%
-- OK
uploading CG42: 100.0%
-- OK
uploading CG47: 100.0%
-- OK
uploading CG61: 100.0%
-- OK
uploading CG64: 100.0%
-- OK
uploading CG65: 100.0%
-- OK
uploading CG66: 100.0%
-- OK
verifying CG31
Checksum error (Expected 0x56e0, Got 0xb9a8)
!! failed
verifying CG33
Checksum error (Expected 0x4125, Got 0x48da)
!! failed
verifying CG34
-- OK
verifying CG35
Checksum error (Expected 0xa91b, Got 0x63d9)
!! failed
verifying CG39
Checksum error (Expected 0x4432, Got 0xea05)
!! failed
verifying CG40
Checksum error (Expected 0xfdff, Got 0xaf0f)
!! failed
verifying CG42
Checksum error (Expected 0x7479, Got 0xac60)
!! failed
verifying CG47
Checksum error (Expected 0x255, Got 0xbf99)
!! failed
verifying CG61
Checksum error (Expected 0x9804, Got 0x7bf4)
!! failed
verifying CG64
-- OK
verifying CG65
-- OK
verifying CG66
Checksum error (Expected 0x21a, Got 0xa36a)
!! failed
rebooting

I spent a good chunk of time reviewing the tutorial of finding bad checksums and replacing it with what the phone actually has, but I realized that since I only have one sbf file which does not flash correctly, I have no idea what the offset addresses are in order to try to replace the hex digits. Is my situation completely inapplicable to this tutorial? Even if it were possible to get the checksums correct, would the flash be successful considering the weird symptoms my phone is exhibiting?

Thanks ahead of time for even reviewing this lengthy post as I tried to give as much detail context of my situation. I'm trying to stay patient, but this is growing quite frustrating. Thanks again, I'm crossing my fingers.

 

[tcandhatch]

have you tried taking out the sd card and see how it runs kinda sounds like what mine was doing back a couple months ago and verizon just replaced it might work if you haven't tried yet just my two cents

Sent from my DROIDX using DroidForums

 

[Shibbey]

Looks to me like you have an issue with the SBF you are trying to use.
I recently got a DX and flashed .340 on it. Ran into FAILED flashes left and right.
I STRONGLY recommend looking at the following: Linux solution to your Windows/RSD lite problems

 

[kutothe]

So, my Droid X is driving me nuts. For some reason whenever the phone is rebooted, it goes back to a state it was in a few weeks ago. All newly installed apps, settings, etc are gone. I can't get it to boot into Clockwork Recovery either, only the default android recovery. I decided to try and flash it with sbf_flash, but kept getting "Checksum error" messages for 3 items. I used a hex editor and put in the values it expected and got it to flash without any failed messaged. However, once I restarted the phone, it's right back to that state it was in previously, like the flash had no effect at all...

I'm running CyanogenMod-7-09192011-NIGHTLY-DROIDX (i'm not sure if this nightly might have caused it?)

The phone works perfectly fine, it's just stuck in time.... Any help would be greatly appreciated, thank you!