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....
Ok, i tried what your hypothesis and changed highlighted bytes to bb 18 and saved the sbf and it flashed with no problem (yeah i know playing with fire) But this raises the question, with every sbf that is made do we have to flash it first and then see what the phone expects it to be and then hex edit the proper checksum in like we did with this one, and if thats it what were the other bytes that didnt match up with the good file? Attached is the sbf I changed those two bytes and flashed.
Edit: And if that is the problem then why is the checksum switched around insted of 18BB its BB18?
Obviously I didn't actually go to bed because I'm a moron, but that's beside the point...
So let me ask you a question ... how awesome did it feel when that SBF -- the one that previously would temporarily trash a phone -- flashed right in with no trouble at all? Pretty awesome right? Now who really cares about the nifty picture that it puts on the screen -- that's incidental. What matters is that 6 hours ago (when I first started writing this, more like 7 now I guess) the only tool you had for replacing CG42 was a sledge hammer, and now you have a scalpel -- and you learned something kinda cool too. This was a really great "get your feet wet" hacking exercise because honestly we started out so close to functional that we didn't have to go far, and we also had a working, but otherwise identical specimen. Having someone to guide the way who knew the answer before we ever started didn't hurt either. But now you kind of see the method -- or at least
a method -- of figuring this sort of thing out just by brute force observation and reasoning.
So let me tackle your very good questions.
I'm going to take the easy one first:
The answer to this has to do with Gulliver's Travels -- yes, the book. Rather than explain it I'll just link you to
a Wikipedia article about it. The short answer is that sometimes the MSB (most significant byte -- the one that is worth more) is stored first and sometimes the LSB (least significant byte) is stored first. There are various reasons for this, but that doesn't really matter. When thinking of MSB, think of it like this. When we write 5000, how do you know that we mean 5x1000 + 0x100 + 0x10 + 0x1 and not 5x1 + 0*10 + 0*100 + 0*1000? I mean it's a pretty big difference. We know because when we humans deal with decimal numbers we do so in Big Endian fashion (see the Wiki) -- the more important numbers come first. We
could write 5000 as 0005 if we all agreed we were going to operate in a Little Endian fashion.
Anyway, when us humans read numbers -- be they hex or decimal or whatever, we always do it Big Endian. So if you see a hex number written 0x7C87 you can be confident that they are talking about 7*16^3 + C*16^2 + 8*16^1 + 7*16^0. But that doesn't mean that's the way the number will be stored in memory or even in a file, depending on if the thing that is going to use it is Big Endian or Little Endian. Of course we don't have any documentation, so let's say somehow we figured out how to calculate the right checksum. How do we know whether to put it in 7C 87 or 87 7C? Well, you know now by observation. You have an error message that says that the file read 0x7C87, but you looked at the file and it actually said 87 7C, so you know that in the future, if you know the right checksum, you need to put it in the file in Little Endian format.
OK, enough of that.
Your first (and probably most important) question was:
But this raises the question, with every sbf that is made do we have to flash it first and then see what the phone expects it to be and then hex edit the proper checksum in like we did with this one, and if thats it what were the other bytes that didnt match up with the good file?
The answer is yes, no, and maybe -- all at once. If you went no further than where we are at now, you would have to do exactly what you just said. Let SBF Codec build your SBF with the bad checksums (it's just keeping the checksum for the prior contents by the way -- I checked), then flash it onto your phone - then get the error log from RSD Lite to find out what the checksum should be, and fix your file. Honestly, this is what lots of people do. It is reliable (obviously RSD Lite knows how to calculate the checksum), and trashing CG42 shouldn't pose any risk of bricking your phone though it is a bit disconcerting to see that code corrupt error. Another option would be to see if you can figure out how to calculate the checksum yourself. This might be a pretty tall order.
We're dealing with a 16 bit checksum. How do I know that? There are lots of ways to come up with the answer. First, the checksum is a 4 digit hex number, right? For me, I know two hex characters are one byte, and we have 4, so that's two bytes, and a byte is 8 bits, so that's 16 bits. Another way to tell would be to bring up the Windows calculator and put it in scientific mode. Then switch it to hex, and then key in the largest possible 4 digit hex number (FFFF). Then switch it to binary. FFFF will change to 1111111111111111. If you count the 1's you'll find 16 of them -- 16 bits.
So, anyway, normally the way you calculate a 16 bit checksum is just to add up the values of every byte in the entire file, and then take a modulus of that total against 0x10000 (0xFFFF + 1). The "modulus" is just the remainder when you divide one number by another. So, 7 modulus 3 is 4. And 25 modulus 2 is 1. Anyway, that's the normal way to calculate a 16 bit checksum and if it were that easy, that would be great. I'll save you the hassle of experimenting -- they aren't calculated that way for the Droid.
The "direct observation" way would be to start with a CG42 that was filled with all zeroes, flash it into the phone, get error, see what the right checksum is, write it down, then change the first zero in CG42 to a 1 and do the whole thing again and see how the checksum changes. Keep incrementing bytes one at a time and watching how the checksum changes. If this were a standard 16 bit checksum the pattern would be that every time you added the value of the next byte the checksum would increase by that much until it got to 0x10000 at which time it would reset to 0x0000 and start counting up again. But it doesn't work that way for the Droid (I've already done all of this if you can't tell).
So, I guess that's the next question for you guys: How would you go about figuring out how to calculate the checksums for the Droid? The direct observation method I just described will work if you are very very good at math. Remember doing differential equations back in calculus and taking big formulas and having to factor them and blah blah blah -- this is kind of the reverse of that. All you are seeing are the answers and you have to figure out what formula is producing them.
Let me know what you come up with. It's possible I don't even have the answer and I just do the RSD Lite trick like everyone else does. Hard to say...
The other question (I was going to ask it, but you asked it first so I pose it back to you -- reworded and fleshed out a little) is:
OK, so out of 10 mismatched bytes, 4 were the datestamp which didn't matter, and 2 were the CG42 checksum (which did matter). That leaves 4 more that were different, but don't seem to be a barrier to flashing. What do they do? Good question. I can tell you that one or more of them causes a difference you will see on the screen in RSD Lite. That's a pretty big hint. Put your hacking caps back on and let me know what you find.
Anyway, good work guys. I hope you feel a little (or big) sense of accomplishment. And with that, now I
am going to bed since I need to be up in about 3 hours.
