This all started whenwe found a serious mistake in the version of the firmware on our device. Seems the ability to reflash from MicroSD was accidentally removed! Sure, we’ll talk more about that later unless you guys all figure it out yourselves in the meantime… 
But back to our problem – what will we do? We can try to hex edit our 8000_MMI.RAP file but boo hoo, it just gets rejected. And that only means one thing:
Checksum.
We love ‘em. Sometimes. They’re like a lock on a door that has no reason to be there. It just makes people wonder what’s inside. And once certain people get to wondering what’s inside… Well, then it’s become a challenge, hasn’t it?
Today we will only talk about simple checksums using summation. XOR is not too bad, but when you get into hashing things it all becomes much more difficult, and the article would be MUCH longer.
We rate this one a 2 – simple , but tries to be a bit tricky. Worth a try, and great for beginners.
Barring any other ability to see into the brains of the device, one way to determine the algorithm for a checksum is to investigate the differences required to pass/fail.
Change a byte. It should fail. Now make a couple educated guesses about a second byte to change, and see if any of those pass. Use the data from those trials to extend further guesses until you have the algorithm. Some canned guesses for you to start with are:
DIFF: If the original byte increased by 1, decrease the byte next to it by 1. You must also try the byte 2 down, 4 down, etc for word, dword, etc sized checksums. This is best for the type of checksum where the entire file is summed, and then a checksum is computed that will make the sum equal to 0, or $FFFFFFFF, or some magic number.
SUM: If the original byte increased by 1, you would also increase the “test” byte by 1 as well. This is good for locating checksums where all bytes in the file are summed up and the sum is stored somewhere. If you increase the sum by 1, you can increase any corresponding byte in the file by 1 and pass.
For very simple patches like nopping out an instruction or two, you can probably get away with just those two techniques and compute out your new sum, where it is either + or – the value of the change you are making.
That’s breaking a window. We want a key.
By checking which bytes we need to diff, we quickly found that this checksum was 32-bits wide. ie – incrementing byte n required byte n+4, or n+8, etc to be decremented in order to pass.
Looking at the headers of a few files showed one bunch of bytes that had no reason to be there, and was always different. Sure we accidentally changed the time/date byte once or twice and scratched our head when our sum didn’t work. But we got it eventually.
The checksum initially looked like a simple CHK32, but running that checksum on our file did not give matching data. We began modifying single bytes further down the file until… Bang! We failed. Did we give up and die, or did we crack another beer and keep going?
Which will YOU do?
Continued on Next Page… Jump to Page 2
Recent Comments