Hacking erroneous output of SBF Codec

[MotoCache1]

Over in this topic we figured out that SBF Codec (the tool most folks use to try to make their own bootloader image SBF files) doesn't create the file correctly when it only has a single code group in it. This topic is going to be sort of a walk through of hacking that bad output to figure out how to make it good.

As far as hacking endeavors go, we've got a lot of advantages. We have an SBF that works (the one I made -- monster-mc1rebuild.sbf) and one that doesn't work (the one that SBF Codec made -- monster.sbf). Both files are attached as zips.

We also have the very helpful error log from RSD Lite when it tried to flash the bad SBF file:

02:14:09,  September 08, 2010
Line: 587
ERROR: Flash failure: Interface AP-OS: Error verifying Code Group 42 checksums. File: 0x7C87, Phone: 0x18BB (Error Code: 31),
Detailed Error Details: Direction of the Error=No Direction, Command Value=4000000, Code Group Number=42

The log tells us what the SBF said the checksum would be and what it actually found the checksum to be when it looked at what got written to the phone. This is important information.

Since we can't change how SBF Codec works, we are going to work through figuring out what's different, and coming up with a repeatable process to fix SBF Codec's output.

Note: This is a hacking tutorial in progress. If you already know how to do this, please don't pop in here, post spoilers and ruin the fun for those who are working through this sort of thing for the first time.

In the next post I'm going to cover the first step and we'll see where we go from there.

Critical Note: DO NOT ATTEMPT TO FLASH THE SBF INSIDE MONSTER.ZIP TO YOUR PHONE. I NAMED IT ENDING IN ".BAD" TO FURTHER DISCOURAGE IT, BUT IF YOU DO FLASH IT IN, YOU WON'T LIKE THE RESULT.

 

[Jharmon12]

Critical Note: DO NOT ATTEMPT TO FLASH THE SBF INSIDE MONSTER.ZIP TO YOUR PHONE. I NAMED IT ENDING IN ".BAD" TO FURTHER DISCOURAGE IT, BUT IF YOU DO FLASH IT IN, YOU WON'T LIKE THE RESULT.

but if you do it might not be the end of the world just flash the good sbf and it should fix it, but no guarantees

 

[MotoCache1]

OK, so where do we start? Well, we have a special advantage that you don't always have. We have two SBF's, both made from the exact same CG42 code group and the same RAM downloader. One works, one doesn't. What is the sensible first step? I'll answer it to get the ball rolling -- we want to see what's different between them. Fortunately, the answer is "not much".

If you have a tool that can compare binary files graphically and display the differences, that's awesome -- it would be handy here (I use UltraCompare). If you don't, that's OK, there is a really simple one built into Windows called "fc" (file compare). Let's use it to compare the two files.

First, the files are binary files, not text files, so we have to use the "/b" switch when we run "fc" (at the command line -- in the same directory where the two SBF files are):

fc /b monster.sbf.BAD monster-MC1rebuild.sbf

The output is:

Comparing files monster.sbf.bad and MONSTER-MC1REBUILD.SBF
00000154: 34 35
00000155: 34 38
00000157: 34 32
00000158: 38 32
0000033E: 87 BB
0000033F: 7C 18
0004D355: A1 9F
0004D356: 1C 75
0008D372: 7D 7C
0008D373: A6 87

This is pretty awesome. There are only 10 bytes that are different between the two files. The 8 digit numbers to the left of the colon are the offsets from the start of the file in hexadecimal. You should have a hex editor handy (Frhed is a free one). If you open the files in your hex editor and go to the offsets shown, you should see the bytes shown.

Elaborating: Go to offset 0x154 in both files (you'll often see hex numbers written beginning with a 0x to indicate that it is hexadecimal and with the leading zeroes on the actual number left off). In monster.sbf.bad (hereinafter referred to simply as "the bad file") you should find a 0x34 at that offset. In monster-MC1rebuild.sbf (hereinafter referred to simply as "the good file") you should fine a 0x35. I'm going to pause here and anticipate a question. Someone is going to say "in the hex editor I see a 150h (0x150) and I see a 160h (0x160), but no 0x154. What gives? Well, that number is the offset of the first byte in that row. My hex editor shows 16 bytes per row (line), and in hex 150h + 16 (decimal) = 160h. That's because in hex, each digit can have a value between 0 and F which are "worth" from zero to 15. So, when we count in decimal it goes like this: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11... When we get to the maximum value for a column (which is 9 in decimal) we reset the column to zero and add one to the next column, so 9 becomes 10. We do the same in hex. But in hex each column can be between 0 and F, so in hex we count like this: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10, 11,... So, if the first byte in that row is 0x150, and the row has 16 bytes, then the last byte in the row is 0x15F, and the first byte in the next row is 0x160. So, 0x154 (the first offset we're looking for) is going to be the 5th column (150 is the first column, 151 is the second column, 152 is the third column, 153 is the fourth column, and 154 is the fifth column -- the "zeroeth" item throws everything off by one. So, now you know where to find the value for offset 0x154 and hopefully you see a 0x34 there in the bad file and a 0x35 there in the good file. Do not continue until this makes sense and you are finding the values shown in your hex editor. If you're lost now it will only get much much worse.

These hex numbers we're seeing are basically the ASCII (pronounced ass-kee) values of each byte. Some ASCII values can be represented by characters we are used to seeing like letters and numbers. Other's can't. Your hex editor should show you the hex values on the left, and the characters on the right. Sometimes being able to see the characters is helpful. It is in this case.

OK, first stopping point. it turns out we don't really care about the fact that the four bytes below are different between the good and bad file. The good news is that only leaves 6 bytes left to figure out. Piece of cake. Consult your hex editor and figure out why we don't care about these 4 bytes. Then we'll continue.

00000154: 34 35
00000155: 34 38
00000157: 34 32
00000158: 38 32

 

[MotoCache1]

Critical Note: DO NOT ATTEMPT TO FLASH THE SBF INSIDE MONSTER.ZIP TO YOUR PHONE. I NAMED IT ENDING IN ".BAD" TO FURTHER DISCOURAGE IT, BUT IF YOU DO FLASH IT IN, YOU WON'T LIKE THE RESULT.

but if you do it might not be the end of the world just flash the good sbf and it should fix it, but no guarantees

True -- if you just don't get crazy you can flash the good SBF right behind it and all should be well. You may just be a little flipped out when you have to battery pull your phone and the bootloader tells you "code corrupt".

 

[Jharmon12]

i hope you dont mind me interrupting here and saying the hex editor im using HxD makes it really easy in comparing files (ctrl+k)

 

[MotoCache1]

i hope you dont mind me interrupting here and saying the hex editor im using HxD makes it really easy in comparing files (ctrl+k)

Nope. Great suggestion for others. I use UltraEdit as my editor (hex and otherwise) and its companion product, UltraCompare for doing compares. The graphical compare tools are a lot better than "fc" at a command prompt eh? When you're only dealing with 10 bytes it's not too bad, but if you've got many blocks of deltas, fc is useless.

 

[fish1552]

i hope you dont mind me interrupting here and saying the hex editor im using HxD makes it really easy in comparing files (ctrl+k)

Thanks for the link. I found UltraCompare but it's only a 30 day trial. Might not use it after that, but it's nice to have a backup just in case. Can't see spending $49 if I use it once a year.

True -- if you just don't get crazy you can flash the good SBF right behind it and all should be well. You may just be a little flipped out when you have to battery pull your phone and the bootloader tells you "code corrupt".

I am proof positive that you CAN come back form this! LOL Main thing was I STAYED CALM - thought through how to fix it and did it.

If anyone attempts any of this, MAKE SURE YOUR BATTERY IS AT LEAST 60% to FULLY CHARGED!!! Having a corrupt code phone and trying to RSDLite a file when the battery is low won't work.

 

[fish1552]

My vote for the reason we don't care much is the offsets are relatively close? A total of 4 bytes?

Not sure my left-brain is letting me see anything else....

 

[Jharmon12]

My vote for the reason we don't care much is the offsets are relatively close? A total of 4 bytes?

Not sure my left-brain is letting me see anything else....

No those bytes are the time stamp and will be different on every file. Use HxD and compare the files ctrl k and open them both and it will be very obvious

 

[MotoCache1]

My vote for the reason we don't care much is the offsets are relatively close? A total of 4 bytes?

Not sure my left-brain is letting me see anything else....

No those bytes are the time stamp and will be different on every file. Use HxD and compare the files ctrl k and open them both and it will be very obvious

OK, we've got a winner on question 1. We'll be moving right along in the next post...

 

[MotoCache1]

Oh, and while you guys were pondering I rewrote my Perl script that makes a proper CG42 out of a BMP file. The previous one you had to do the "mirror" in your image software before saving the file. In this one it does everything for you. You just feed it a 480 x 182, 24-bit BMP, and it spits out a CG42 for you. A super simple way to flash just CG42 on without even making an SBF also dawned on me, but it requires Linux, so I'll save that for a later time.

 

[MotoCache1]

OK, so we figured out that the first 4 non-matching bytes were in the timestamp from when the SBF was compiled. If we wouldn't have both compiled our files so close together (time wise) even more bytes would have been different, but as it was, only the minute and seconds were different, so only 4 bytes.

So we have 6 more non-matching bytes. Honestly that should be a little exciting. We only need to figure out how to determine what the value of 6 little bytes should be and we'll know how to manually fix SBF Codec's bad file.

The remaining bytes are:

0000033E: 87 BB
0000033F: 7C 18
0004D355: A1 9F
0004D356: 1C 75
0008D372: 7D 7C
0008D373: A6 87

Now, honestly, if you've got a real hacker brain, and you've really absorbed everything so far, plus have an idea of what we're after here (I've said it in previous posts, just not emphasized it), some of those numbers should be screaming at you right now. Of those 6 bytes, which ones do we already know one method for figuring out what they should be (if we didn't already have a "good" SBF with right values)?

That's question 2. We'll stop here until someone gets it.

 

[Jharmon12]

It looks like some of the bytes are inverted

 

[fish1552]

My vote for the reason we don't care much is the offsets are relatively close? A total of 4 bytes?

Not sure my left-brain is letting me see anything else....

No those bytes are the time stamp and will be different on every file. Use HxD and compare the files ctrl k and open them both and it will be very obvious

Facepalm! Too easy.

 

[MotoCache1]

It looks like some of the bytes are inverted

Good guess. Not it. Somewhere we know exactly what to replace some of these bytes with (and the data happens to match the "known good" file).