|
|
|
By openschemes, on February 4th, 2010% 2,749 views
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
By openschemes, on February 4th, 2010%
By openschemes, on January 30th, 2010% 3,404 views
We’ll start this article by talking about SPMP8k Software images. These are the large (>50MB) IMG files generated by the SKLOGO program or found on the interweb. They contain the operating system of the device and consist of lots of binary executables, even more XML configuration files, and even more BMP files. This bunch of files is the output you get from the file dumper from the last article, although not in a nice packed single file.
It seems that when people want to change their device configuration, they are opening the IMG file and hex editing the XML’s. That will certainly work, but is probably rather difficult for the beginner.
Another approach would be to dump your device or dump an IMG file to the full directory of files, edit them as you please, and then repack into an IMG and reflash the device. At that point, you are free to add/remove/replace any images, binaries, or XML you like. I smell a lot of background image customization tools on the horizon!
As we mentioned, one very slow way to get a full backup of software from an unknown device is to dump it via the serial port. It works, and today we successfully repacked a file dump into a new IMG and flashed that image to our semi-bricked PMP to bring it back to life. But the process takes time.
If you happen to have your IMG file on hand, you can dump it to your hard drive in just seconds using the sprdump tool. This is the tool that we mentioned in the last article, and we’ve received permission from the author to release it. But in order to estimate how many people have actually downloaded it, we must force you to go to the next page.
Continued on Next Page… Jump to Page 2
By openschemes, on January 30th, 2010%
By openschemes, on January 29th, 2010% 3,123 views
As you probably know, we’ve been busy dumping the raw NAND page data of the SPMP8k to see what mysteries it holds. The answer is, surprisingly: not many! But that’s a good thing – mysteries deep in the ROM are not a good thing.
One interesting note is that there are three filesystems on the flash:
BOOTFS: Bootcode (2nd stage) and Redboot. Starts at page 0.
RO(M)FS: System Software. Starts at page 0×2000
FAT: The Mass storage you can see over USB. Takes up the rest of the flash.
The first fielsystem is BOOTFS – this is our name by the way, just calling it the first thing that comes into mind. This filesystem resides in the first few pages of flash. It consists of several one-page (4k) functions and then the RedBoot binary. This is what you’d find in the firmware files such as BOOT_V15.IMG.
The ROM bootstrapper (+++MMP RomCode…) searches the first few NAND pages to try to find the magic bytes 33 CC AA 55. This signifies the start of a set of very crude allocation tables which point to two binary files responsible for initializing the DRAM, and the RedBoot binary.
Bootstrapper loads and executes the DRAM_Init() from flash, and once it has 16MB of DRAM, it load RedBoot into that and hands off control.
RedBoot either gets interrupted by you for nefarious purposes, or it loads a script which tells it to boot /IMAGE/8000_MMI.RAP. Woo, directories – now we’re getting fancy!
This second filesystem is called ROMFS (we saw ROFS somewhere too) but it does not seem to be compliant with the actual ROMFS that was around long before the SPMP. It’s still a fairly simple filesystem though, and can be explored through RedBoot by mounting the device /dev/nf2 and using the ls commands as we’re sure you’ve already done.
ROFS/ROMFS seems to be the whole kit & kaboodle of the eCos platform, containing executables, codecs and emulators as well as tons of XML files for configuration. This filesystem is what is contained in the big (>50MB) software files generated by the SKLOGO tool.
But SKLOGO simply takes different binary chunks and pastes them together – other than hex editing (which seems to work pretty well ala Jaime) it is difficult to make significant changes to the file system. And that’s something that you KNOW we’re going to want to do.
In order to have free reign over the filesystem, it is easiest to unpack the entire ROFS filesystem to it’s individual files and directories and modify it at well. Then, it’s pretty easy to use the Sunplus tools to repack and reflash your new filesystem to the device.
SIDE NOTE:
We were very disappointed/entertained to see the following entries in the directory dump:
/IMAGE/GAME/GAME_CONFIG.TXT 22963
/IMAGE/GAME/GBA_BIOS.BIN 16384
/IMAGE/GAME/GPSP.BIN 776004
Because it means that not only has Sunplus ripped off GNU/eCos, they have also ripped off Exophase as well as Nintendo. I mean, couldn’t you have changed it to data.dat1 and data.dat2? No shame.. Still a nice IC tho, so we’re happy to continue plugging along in the hopes of getting SOMETHING legal onto this little device.
The bright side is that we’ve invented a new game: Take a shot whenever you find something pirated, stolen, or used without permission in the Sunplus ’8k PMP. We’ve been hammered for days.
OK, OK – on to the dump tool.. Let us preface this with the warning that if you already have a copy of your firmware, there are much easier ways to extract it’s goods than the following tool. This tool is a glorified console script that can also convert ASCII to bin. Downloading the entire software will take time. (5.25*Size)/115.2kbaud as a rough estimate, where 5.25 is a rough multiplier based on the ascii conversion and overhead.
We’re talking hours, folks. About 6-7h if your RS-232 port is reliable. If you’re like us and want an exact copy of one device to another, then this is a little faster than a nand dump so it might be a viable option. A more likely use would be to download all the XML config data for your device to merge into a resource directory of another firmware. But IMO, letting an inanimate object work itself to death all night while we sleep is not a big deal.
If you’re not scared off yet, then please
Continue to Next Page… Jump to Page 2
By openschemes, on January 29th, 2010%
|
Recent Comments