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:
Code:
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,53
5, 65,53
6 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:
Code:
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:
Code:
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.
