Hacking erroneous output of SBF Codec

[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).

[fish1552]

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.

[fish1552]

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).

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.

[MotoCache1]

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.

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!

[Jharmon12]

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?

[fish1552]

^^^ 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

File: 0x7C87, Phone: 0x18BB

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....