Inspecting the firmware

[Maxwell Smart]

(Moved back to this sub-forum from a discussion in "D2 Flash".)

Using the Unix "strings" utility to poke around in the firmware images, we find that they're unencrypted.

It would be a reasonable to assume that Cowon used free software to build their software stack, but likely stayed away from GNU GPL-licensed libraries, as this would require them to distribute much or all of their firmware under the GNU GPL as well.

I think I can confirm this assumption in one respect. They seem to be using the bone-standard and ubiquitous libjpeg library, by the Independent JPEG group.


$ grep 1998 d2_firmware_3.50b_*
d2_firmware_3.50b_0_d2N.txt: 16440d Copyright (C) 1998, Thomas G. Lane
d2_firmware_3.50b_0_d2N.txt: 164430 6b 27-Mar-1998

d2_firmware_3.50b_1_d2N.txt: 2ade15 Copyright (C) 1998, Thomas G. Lane
d2_firmware_3.50b_1_d2N.txt: 2ade38 6b 27-Mar-1998

It might be fruitful to inspect areas around these addresses so we can find out for sure exactly what archiecture triple and object file format is being used here. E.g., I don't even know if the D2's CPU uses standard 32-bit ARM opcodes or Thumb opcodes.

[ManchesterBaby]

Stuck it through a disassembler - it's mostly ARM opcodes as far as i can see.

There's some seriously weird strings in one of the firmware files (3.46/1/d2N.bin i think) including:
"catchtwentytwo", "ear nose and throat department", "Nine-Eleven" and "7 de setembro", amongst many others (though they do tend to repeat in different formats (case etc)). Seriously weird. I suspect they're test strings for debugging purposes that somehow made it into the final build...

[MaxSt]

Seriously weird.

It's probably related to dictionary.

[punit]

I tried fdisk on the usb device when mounted under linux. The D2 had four partitions on it. There was also some form of error reported - logical/physical sector size mismatch or some such. I am sorry I don't have my usb cable atm to get the exact message.

One thing to try would be to examine the content of those drives to see their content - layout, files etc. They might contain the files extracted from the firmware, maybe even the bootloader.

Also there has been some progress made on understanding the format of the firmware header (in a totally unrelated thread on this forum). Now that I have my D2 (got it couple of days back. I love it :) ) I will be try to change the firmware strings and see if it loads up. There seems to be a checksum (essentially two unidentified 4 byte fields) in the header, but no idea which checksum it is.

[almightyzues]

if only i had a strain of a idea of what this all meant.

[calcheese]

Good work guys! Didn't want to disturb you but somebody already did..I thought I'd bring you guys hot chocolate and cookies...is what I would have done if this were a real room. It would be amazing once you guys figure this out. Much appreciated! I won't disturb you anymore. Continuez sans moi.

[punit]

An update on my last post - I tried a few things and had the scare of my life.

Currently there are two unidentified fields in the header - at address 10h and 18h. In order to know more about them, I changed a character in a string in the firmware binary and tried loading it on the D2. On reboot of the D2, a firmware update screen shows up, but the progress bar reaches about 1/5th and then straight goes to the opening menu. The file is deleted from the root directory of the D2.

This points to a checksum which fails and prevents D2 from updating the firmware.

Next I tried to change the unidentified fields in the firmware header on an original firmware binary. On changing the field at 18h I got similar results with the firmware being rejected (i.e., not loaded and deleted from root directory).

After this things got a little hazy. I lost patience and didn't document the changes I made in the binary. From memory, I kept the field at 18h unchanged and zeroed the four bytes starting at 10h. And next I know, the D2 is not booting.

Oh shit. I am glad I had the recovery drivers. But it is a windows application and I am not very good with windows. After a couple of tries and lots of tense moments I am able to use the recovery drivers to get the D2 back from the land of the dead.

My thoughts from these fiddling is that the field at 18h is a 32bit checksum. No idea what format. Still don't know what the field at 10h is or could be.

A few things I failed to notice -
1. After installing the firmware update from the recovery drivers whether the same upgrade bars shows up or not.
2. I chickened out after the recovery but a worthy thing to try would be try loading a modified firmware from the recovery software. Would give a clue as to the firmware checksum being checked even after loading via the recovery software.
3. Using a USB snooper to monitor the data and command sent over the USB during the recovery procedure.

I would appreciate if somebody could provide a confirmation of the results - the ones related to field 10h and 18h.

I will continue to fiddle around, but my knowledge of reverse engineering is small. So if there are others interested we could pool our resources and hopefully make faster progress.

[Am also reposting this on rockbox forums in case there are others interested on that forum too]

[MaxSt]

I don't think there is anything in the firmware file that really needs to be changed that way. The whole thing isn't worth the trouble.

[man.dovvn]

the checksum is a major problem, until we can crack that we'll never be able to load custom firmware.

On another note:
The new firmware upgrades are good, we'll have to see where they take/leave it, custom firmware would be amazing, but re-creating features like flash lite (for example) will probably never happen unless we could pinch the original code. The quality of the custom firmware will depend greatly on the amount of people willing to tackle it and the accessibility (ie, if we can code in C++ or something, we'll have an army of people to work on it)