Hacking erroneous output of SBF Codec

Discussion in 'Droid Labs' started by MotoCache1, Sep 8, 2010.

  1. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    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:
    Code:
    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.

    Attached Files:

  2. Jharmon12
    Offline

    Jharmon12 New Member

    Joined:
    May 4, 2010
    Messages:
    257
    Likes Received:
    0
    Trophy Points:
    0
    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 :eek:
  3. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    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):
    The output is:
    Code:
    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.
    Code:
    00000154: 34 35
    00000155: 34 38
    00000157: 34 32
    00000158: 38 32
    
  4. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    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".
  5. Jharmon12
    Offline

    Jharmon12 New Member

    Joined:
    May 4, 2010
    Messages:
    257
    Likes Received:
    0
    Trophy Points:
    0
    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)
  6. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    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.
  7. fish1552
    Offline

    fish1552 Premium Member Premium Member

    Joined:
    Mar 16, 2010
    Messages:
    652
    Likes Received:
    16
    Trophy Points:
    0
    Location:
    Savannah area of Coastal Georgia, USA
    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. :)

    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.
  8. fish1552
    Offline

    fish1552 Premium Member Premium Member

    Joined:
    Mar 16, 2010
    Messages:
    652
    Likes Received:
    16
    Trophy Points:
    0
    Location:
    Savannah area of Coastal Georgia, USA
    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.... :)
  9. Jharmon12
    Offline

    Jharmon12 New Member

    Joined:
    May 4, 2010
    Messages:
    257
    Likes Received:
    0
    Trophy Points:
    0
    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
  10. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    OK, we've got a winner on question 1. We'll be moving right along in the next post...
  11. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    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.
  12. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    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:

    Code:
    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.
  13. Jharmon12
    Offline

    Jharmon12 New Member

    Joined:
    May 4, 2010
    Messages:
    257
    Likes Received:
    0
    Trophy Points:
    0
    It looks like some of the bytes are inverted
  14. fish1552
    Offline

    fish1552 Premium Member Premium Member

    Joined:
    Mar 16, 2010
    Messages:
    652
    Likes Received:
    16
    Trophy Points:
    0
    Location:
    Savannah area of Coastal Georgia, USA
    Facepalm! Too easy.
  15. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    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).
  16. fish1552
    Offline

    fish1552 Premium Member Premium Member

    Joined:
    Mar 16, 2010
    Messages:
    652
    Likes Received:
    16
    Trophy Points:
    0
    Location:
    Savannah area of Coastal Georgia, USA
    W.a.g.

    Ok, you said jumping right out at us, soooo......

    I can see the 2 at the end and it looks like it says "=xx". I tried looking at the characters using the number substitution for them, but it didn't really tell me much.

    7C & 7D = 7+12 7+13
    A6 & 87 = 10+6 8+7

    Other than the last 2 offsets are nearly the same much like the time stamp ones. So it looks like the 4 in the middle are the ones that throw us off so much?

    Or am I WAAAYYYY off base and not getting any of it. :icon_eek:
  17. fish1552
    Offline

    fish1552 Premium Member Premium Member

    Joined:
    Mar 16, 2010
    Messages:
    652
    Likes Received:
    16
    Trophy Points:
    0
    Location:
    Savannah area of Coastal Georgia, USA
    I see all the FF FF FF just like we had in the BMP file and CG files when we had to delete the portions.
  18. MotoCache1
    Offline

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    0
    I can see you searching for patterns. This is kind of a side note, but let me tell you about "hex" math.

    If you have the number 7C, you're right that the first digit is obviously 7, and the second digit is "worth" 12, but there's something missing there.

    A quick delve back into base 10 since we're all familiar with it.

    If have have the number 9 it's value is "9". But if I have the number "94", it's not worth 9 + 4 (13). It is actually worth 9x10 + 4*1 because the first column is our "tens" column and the second column is our "ones" column. Most people don't remember (or never knew) but the way we know how much each column is worth is to start at the rightmost column and work to the left.

    The right most column is worth 10^0 (read that as 10 with an exponent of zero). The next column is worth 10^1, then 10^2, 10^3 and so on, forever. Well, any number raised to the zero power is equal to 1. It's one of those "identity" laws or something. Then 10^1 = 10, 10^2 = 100, 10^3 = 1000, and so on.

    So it is in hexadecimal. The rightmost column is worth 16 ^ 0 (which equals 1), then 16 ^ 1 (16), then 16 ^ 2 (256), and so on.

    So, 7C isn't 7+12 (19), it's 7*16 + 12*1 = (112 + 12) = 124.

    OK, now that we've been through all that, I'll go ahead and tell you it has nothing to do with what we're solving. But now you understand hex math a little more. ;)

    OK, how about a hint and then I'm headed to bed and we can pick up tomorrow. Some of those bytes match something in the OP.

    Have a good night!
  19. Jharmon12
    Offline

    Jharmon12 New Member

    Joined:
    May 4, 2010
    Messages:
    257
    Likes Received:
    0
    Trophy Points:
    0
    i knew it had to do something with the check sum but i wasnt sure how to calculate the right one because thats the only difference between the good file and the bad one. The question is how much of the difference between the files really matter?
  20. fish1552
    Offline

    fish1552 Premium Member Premium Member

    Joined:
    Mar 16, 2010
    Messages:
    652
    Likes Received:
    16
    Trophy Points:
    0
    Location:
    Savannah area of Coastal Georgia, USA
    ^^^ Bad choice of characters in my substitution of the numbers. I wasn't really adding them, just figuring how they were holding places sort of to search for the pattern. The "+" meaning "&" really. And I guess with my including the "=" it didn't help.

    I saw the
    Code:
    File: 0x[SIZE=5][B][COLOR=Red]7C87[/COLOR][/B][/SIZE], Phone: 0x[B][SIZE=5][COLOR=Red]18BB[/COLOR][/SIZE][/B] 
    
    Is that actually TELLING us to put the 18 BB where the 7C 87 are.

    That is just too easy if it is right. 'Course, you DID hit on the "0x" part and you said something about not emphasizing it....
Search tags for this page
data[0]: checksum error sbf flash
,
error verifing code group 33 checksums. file 0xfc1b
,
error verifying code group 32
,

error verifying code group 32 checksums

,
error verifying code group 33 checks
,
error verifying code group 33 checksums defy plus
,
i couldn't flash defy code checksum error
,
sbf editor
,
sbf-recalc swap file error
,

sbfcodec

,
sbfcodec droid x
,
symptoms for hacked droid razr
,
using c# 4.5 codegroup
,
what erroneous output