Hacking erroneous output of SBF Codec

[fish1552]

2. There were 10 mismatched bytes originally. We've "explained" 6 of them. What do the other 4 do?Anybody work on these at all?

I've been thinking about the last one since before we figured out the error code thing. Is the "=" just a random character or does it have something to do with it?
I've also wondered if the 87 has a reason for being both at the top and the bottom or if it's just coincidence.

I'm wondering if the following error:

ERROR AP Public ID: ffffffffffffffffffffffffffffffffffffffff

has anything to do with the original part of the CG42 file we left in? Maybe something we cut out right before that matters that it throws that error? I'd be curious to see if the "07f0010c41720304000000000400" has any corresponding part in the hex code as well.

 

[Jharmon12]

I have done a quick search and i couldnt find in the entire file any accurance of

07f0010c41720304000000000400

and isnt repeting f's just padding?

 

[Jharmon12]

Ok the curiosity finally got to me. I made full sbf's of both mine and MC1's monster logo and got some curious results This is MC1's full sbf

01:13:09,  September 11, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400

01:13:09,  September 11, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000

01:13:09,  September 11, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff

01:13:09,  September 11, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000

01:16:56,  September 11, 2010
Line: 1309
ERROR: Interface AP-OS: Error verifying Code Group 42 checksums. File: 0x7C87, Phone: 0x18BB
File: X:\test_dev_usb\flash\code\flashdll\FlashOp.cpp
Device ID: 0

01:17:32,  September 11, 2010
Line: 1182
ERROR: Phone[0000]: Flash failed.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashThread.cpp
Device ID: 0

01:17:32,  September 11, 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
File: X:\test_dev_usb\flash\code\flashdll\FlashHdlr.cpp
Device ID: 0

Heres mine, Just keep in mind that these are full sbf's and they flashed without a problem.

01:05:34,  September 11, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400

01:05:34,  September 11, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000

01:05:34,  September 11, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff

01:05:34,  September 11, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000

01:09:19,  September 11, 2010
Line: 1309
ERROR: Interface AP-OS: Error verifying Code Group 42 checksums. File: 0x7C87, Phone: 0x18BB
File: X:\test_dev_usb\flash\code\flashdll\FlashOp.cpp
Device ID: 0

01:09:58,  September 11, 2010
Line: 1182
ERROR: Phone[0000]: Flash failed.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashThread.cpp
Device ID: 0

01:09:58,  September 11, 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
File: X:\test_dev_usb\flash\code\flashdll\FlashHdlr.cpp
Device ID: 0

01:10:10,  September 11, 2010
Line: 1492
ERROR: Error getting subscriber unit information.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashThread.cpp

WOW if you look it has the same checksum error as before but flashed anyway. All i did was used sbf codec to explode the two known working monster sbf's and use the ch42's to make the full SBF"s. So what it looks like is that SBF is rewriting the check sum incorrectly. But when they are in a full sbf RSD Lite ignores the checksum and flashes anyway. I also done a control flash to see the result, i took the VZW_A855_ESD56_QSC6085BP_C_01.3E.01P_SW_UPDATE_03.sbf and flashed it thinking i would get no errors but this is what i got.

01:19:02,  September 11, 2010
Line: 1492
ERROR: Error getting subscriber unit information.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashThread.cpp

01:20:17,  September 11, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400

01:20:17,  September 11, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000

01:20:17,  September 11, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff

01:20:17,  September 11, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000

The same exact error we got flashing the monster logo only in previous posts. So this leads me to believe that its not the sbf's that are causing the errors its RSD Lite not handling the 100% correctly.

And just for curiosity sake i took the CG42 out of the Verizon SBF and fed it into the logo only SBF and it failed, which confurms my suspition of sbf codec not rewriting the checksums correctly . But anyway this is what I got

 01:34:17,  September 11, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400

01:34:17,  September 11, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000

01:34:17,  September 11, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff

01:34:17,  September 11, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000

01:34:20,  September 11, 2010
Line: 1309
ERROR: Interface AP-OS: Error verifying Code Group 42 checksums. File: 0x106A, Phone: 0x73E3
File: X:\test_dev_usb\flash\code\flashdll\FlashOp.cpp
Device ID: 0

01:34:20,  September 11, 2010
Line: 1182
ERROR: Phone[0000]: Flash failed.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashThread.cpp
Device ID: 0

01:34:20,  September 11, 2010
Line: 587
ERROR: Flash failure: Interface AP-OS: Error verifying Code Group 42 checksums. File: 0x106A, Phone: 0x73E3 (Error Code: 31),
Detailed Error Details: Direction of the Error=No Direction, Command Value=4000000, Code Group Number=42
File: X:\test_dev_usb\flash\code\flashdll\FlashHdlr.cpp
Device ID: 0

Well anyway now that my phone is back in working order and that i fried my brain i think i will finish watching this movie and hopefully go to sleep!

EDIT: Sorry for the long post, there was allot of info to cover.

 

[Moto Droid]

And just for curiosity sake i took the CG42 out of the Verizon SBF and fed it into the logo only SBF and it failed, which confurms my suspition of sbf codec not rewriting the checksums correctly . But anyway this is what I got

 01:34:17,  September 11, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400
 
01:34:17,  September 11, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000
 
01:34:17,  September 11, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff
 
01:34:17,  September 11, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000
 
01:34:20,  September 11, 2010
Line: 1309
ERROR: Interface AP-OS: Error verifying Code Group 42 checksums. File: 0x106A, Phone: 0x73E3
File: X:\test_dev_usb\flash\code\flashdll\FlashOp.cpp
Device ID: 0
 
01:34:20,  September 11, 2010
Line: 1182
ERROR: Phone[0000]: Flash failed.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashThread.cpp
Device ID: 0
 
01:34:20,  September 11, 2010
Line: 587
ERROR: Flash failure: Interface AP-OS: Error verifying Code Group 42 checksums. File: 0x106A, Phone: 0x73E3 (Error Code: 31),
Detailed Error Details: Direction of the Error=No Direction, Command Value=4000000, Code Group Number=42
File: X:\test_dev_usb\flash\code\flashdll\FlashHdlr.cpp
Device ID: 0

Well anyway now that my phone is back in working order and that i fried my brain i think i will finish watching this movie and hopefully go to sleep!

EDIT: Sorry for the long post, there was allot of info to cover.

With taking the original CG 42 out of the original and complete sbf file and still getting a error when you flash that, well just doesn't make sense unless like you say sbf codec is not calculating the check sums properly. Not the right tool for the job?? side note: is ur droid screaming @ u after that many flashes in a row with Errors?

 

[Jharmon12]

Lol naa Sue (my droids name) understands and is willing to make sacrifices for the greater good. She's a real trooper. Back on track I guess we explained the error log but. Other the four bytes. But atleast we know now that they aren't causing errors, the only thing else we can do is change one byte at a time and observe the outcome.

Sent from my Moto Droid using Tapatalk

 

[Moto Droid]

Lol naa Sue (my droids name) understands and is willing to make sacrifices for the greater good. She's a real trooper. Back on track I guess we explained the error log but. Other the four bytes. But atleast we know now that they aren't causing errors, the only thing else we can do is change one byte at a time and observe the outcome.

Sent from my Moto Droid using Tapatalk

makes u wonder what tool does MC1 use to do this with then?

 

[Jharmon12]

Lol he most likely hand coads his because he's 1337

Sent from my Moto Droid using Tapatalk

 

[MotoCache1]

Another question I would like to know as well, why does it work when u flash the whole sbf file with all the CG's in it? does the phone only check the first CG then let everything else go?

Yeah - I want to know that too. Now that you know where the checksum bytes live you should be able to look at your modified full-flash SBF and see if SBF Codec correctly recalculates the checksum when CG42 isn't the only CG in the file. My theory is that perhaps SBF Codec just has an issue where it accidentally (or intentionally) doesn't recalculate the checksum of the first CG in the file. It's a good hacker project for someone who needs the experience to go find out.

I have made a coulpe from the base ones you made, and switched up the order in the way I make them and save them from the orginal instructions. So when i look at them i am now getting the same check sum you got with yours (which we know are good to flash). no matter what picture i put in there as long as I build from your base i get the same check sum just scared to flash since a few days ago got that corrupt message. need to know about the last 4 bytes?????

Your post makes me realize that: a) we never really discussed what a checksum is, b) not everybody knows what one is. This is my failing. Now you may know what a checksum is and I'm mis-interpreting your post, but in case you or anybody else doesn't, we're going to fix that now.

One of the problems with storing information is that it is possible for errors to occur. These errors can easily occur when the data is in transit or storage. When an error happens, then the data received or retrieved is no longer the same as the data that was originally sent or stored. This is a "bad thing". Since the problem has existed since there first was a concept of data (cave paintings might get washed away or defaced by another disgruntled cave man for example) in the computer world various means of detecting (and sometimes correcting) data errors have been devised. One of the simplest (and earliest) means of detecting data errors is the checksum. Literally a checksum is just a sum of all the bytes in a block of data. Checksums may also be referred to a "CRC checks" (Cyclic Redundancy Check).

I'm going to illustrate how a checksum/CRC works.

Take the word "Hello" for example. That word is data. In standard ASCII that word is comprised of 5 bytes. In decimal, those bytes are:

H = 72
e = 101
l = 108
l = 108
o = 111

So the simplest possible checksum for that word would be nothing more than: 72 + 101 + 108 + 108 + 111 = 601. One problem that is immediately apparent with this scheme is that if the data were very large at all, the checksum number would get huge and be unwieldy. To address this issue, most checksums have some sort of "base" or maximum value defined. For example, the checksums we're dealing with are 16 bit checksums. That means they consist of 16 bits at most. If you've worked with binary long enough, you know 16 bits of binary (two bytes) can have a maximum value of 65,635. If you didn't know that off the top of your head (most sane people), using the binary mode of your Windows calculator, key in 16 1's and then switch to decimal and it will tell you 65,535. If you were curious and switched to hex mode you'd see FFFF, unsurprisingly that's the largest possible 4 character hex number (4 characters of hex just like our checksums we're dealing with here).

The way a 16-bit checksum is calculated is almost the same as before, only any time the total value of the checksum goes over 65,535, 65,536 will be subtracted from it - so 65535 + 1 = 0. So let's say now that our word "Hello" appeared not by itself, but in the middle of a much larger block of data. Let's say that the checksum of everything prior to the word "Hello" had reached a total of 65,402. The continued calculation of the checksum would then go like this:

H = 72 + 65402 = 65474
e = 101 + 65474 = 65575 - 65536 = 39
l = 108 + 39 = 147
l = 108 + 147 = 255
o = 111 + 255 = [U][B]366[/B][/U]

So, if I wanted to send that message to you, I could first send you a message that tells you the checksum of the message I'm about to send you is 366. Then I send the message itself. At "your end" you would calculate the checksum of the message you received, compare it to the checksum that I sent you initially, and if the numbers were the same, you'd know you received my message intact. Sort of.

A simple checksum such as the one illustrated above is not immune to offsetting errors. To most easily illustrate what that means, consider that I sent the word "Hello" (as above), but what you received was actually this:

H = 72 + 65402 = 65474
[COLOR=Red][B]f[/B][/COLOR] = 102 + 65474 = 65576 - 65536 = [COLOR=Red][B]40[/B][/COLOR]
l = 108 + 40 = [COLOR=Red][B]148[/B][/COLOR]
[COLOR=Red][B]k[/B][/COLOR] = 107 + 148 = [COLOR=DarkGreen][B]255[/B][/COLOR]
o = 111 + 255 = [COLOR=DarkGreen][B][U]366[/U][/B][/COLOR]

Notice that even though two of our bytes are wrong, we still got the same checksum. That's because 1 byte was "low by 1" and another was "high by 1", so the errors offset and left us with the same checksum. Since the chances of a perfectly offsetting combination of high and low values are relatively small, for non-critical data these simple checksums may still be used. Remember that the more complex the checksum is, the more time the computer wastes calculating checksums instead of doing other things. For more critical data, checksum schemes have been devised which are more robust. There are also "one-way hashes" like SHA1 that act like a signature of sorts and essentially guarantee that the data is identical if the hash matches.

OK, so all of that was intended to help you understand that a checksum is intended to guarantee data integrity. When you flash a SBF to the phone, after writing the data RSD Lite calculates the checksum of what it found in the phone. It then compares that checksum to the checksum that's in the SBF file. If it matches it knows the file was written correctly. If it doesn't, it alerts you. The checksum from the SBF file is also apparently written to the phone for at least some CGs. So, when the bootloader loads, it can check the checksum of CG42 and if it doesn't match the one "on file", it tells you "Code corrupt".

At this point it should be obvious to you that every time you change the contents of the CG, the checksum is going to change. There is no such thing as a checksum that is "close enough". It is either right, or it is wrong.

It would be nice if the phone used a simple checksum like the example at the beginning of this post. Unfortunately it does not. Exactly how the checksums are calculated is still an open question in this topic.

Hope this helps.

 

[MotoCache1]

There are several other items in this topic that I intend to respond to but I have other commitments at this time. There have been a couple observations posted while I was away that I think need some discussion.

I'll try to get to them later tonight, or tomorrow.

 

[Jharmon12]

So what u r saying is that the differences in the files could be that they messed up in transfer? But don't putting them in zip files prevent that?

Sent from my Moto Droid using Tapatalk

 

[MotoCache1]

So what u r saying is that the differences in the files could be that they messed up in transfer? But don't putting them in zip files prevent that?

Sent from my Moto Droid using Tapatalk

No, I was just explaining what the function and purpose of checksums is. There had been some comments about values being "close enough" and about knowing a value is good because it worked for a prior image and I wanted to make sure everyone understood that each image will result in a different checksum, and generally what a checksum is and how simple ones are calculated. SBF Codec is simply not recalculating the checksum and is leaving it set to what it was before you changed the CG which obviously won't work.


Sent from my Droid using Tapatalk

 

[Jharmon12]

See from my experiment I found out that sbf codec Is changing the checksum just incorrectly.

Sent from my Moto Droid using Tapatalk

 

[Moto Droid]

So what u r saying is that the differences in the files could be that they messed up in transfer? But don't putting them in zip files prevent that?

Sent from my Moto Droid using Tapatalk

No, I was just explaining what the function and purpose of checksums is. There had been some comments about values being "close enough" and about knowing a value is good because it worked for a prior image and I wanted to make sure everyone understood that each image will result in a different checksum, and generally what a checksum is and how simple ones are calculated. SBF Codec is simply not recalculating the checksum and is leaving it set to what it was before you changed the CG which obviously won't work.




Sent from my Droid using Tapatalk

"There had been some comments about values being "close enough" and about knowing a value is good because it worked for a prior image and I wanted to make sure everyone understood that each image will result in a different checksum"

That's exactly what I was wondering about, I have used the base of your good ones and put different images in and the check sum was staying the same. It's just SBF coded is not recalculating a checksum for the new image it stays with the old one, which will not work for the new image?

 

[Jharmon12]

Sooo MC1 what tool do you use to make your sbf's?

 

[Keka_Umans]

RSDLite 4.6 stopped throwing errors all it says is all i get now is"failed flashing process (0x7100);phone connected" i think i've got this figured out, but without the expected checksum to change in the sbf i cant fix them...