Now we’ll get to the good stuff. A couple of items that are extremely beneficial to any hack are the datasheet, user guide, and SDK. For some reason these items seem to be rare in the hax0r community on this device. But they’re freely available now!
Perhaps we were lucky, or perhaps Appotech is simply loosening up on the ’206 as they bring out the latest and greatest, but they are offering these little gems up for the taking as a bit of a side note for another part’s page. The page is for the newer AX2003, but you can see that the files at the bottom all refer to the AX206. Score! We hope that the newer devices continue to use this same hackable topology!
Now we’d hate for them to change their minds, so we are happy to mirror these items for the advancement of the development on these intriguing little devices.
AX206 Firmware Source Code and SDK (9MB)
That big pile of fun should keep you busy for a few days while we attempt to brick, err – hack our device. The present state of the device is that it’s possible to upload your own code to an unused part of memory, and with a hacked menu sector, jump to that code. What is NOT yet possible is the ability to reflash the entire firmware at once, since the process of erasing the present firmware gives the chip nothing to execute during the flash and it bricks.
Our first thought is to upload a flasher stub and use that stub to reflash the main firmware. The main problem with that is that it still cannot be used to recover a bricked device.
There’s also reports of a hardware bootloader accessed by (IIRC) holding the MENU button when exiting reset (actually, differing reports here so we shall see). That hardware bootloader is the real way to reflash a brick, but it’s function and commands are yet unknown. Perhaps we’ll try to find a way to coax it’s code out so we can take a little peek, eh?
Additionally, there IS what appears to be a flash tool supplied by the manufacturer in that SDK, but as of now we’ve had no luck with it. The COBY has no explicit reset button so we’ve not yet played with the hardware bootloader. Plenty of opportunity for fun there as well.
All in all, it should be an interesting hack. You may note the inclusion of a couple of simple games in that SDK. If we get this thing good and broken, we’ll have a “best game” contest or something to see what people can come up with. Should be a good time!
Our final gift to you is a windows (err, DOS) based dump tool from the Spriteserver Talk Page. Please realize that this is not our work, although we will probably build upon it in the future. Our contribution today is just to build up a little Bloodshed Dev C++ project for your ease of use, and to compile up a binary for all you suckers without compilers.
So here you go: Source, Executable, and Dev C++ Project for Dermaik’s Dump Tool as well as Our Own Factory Fresh COBY DP-151 Dump. Interestingly, this one uses ProcTbl3.0.
It is HIGHLY RECOMMENDED to take an original dump of your DPF before you begin screwing around with it. That way, you may have some hope of recovering a bricked device, even if it means reflashing with an external SPI pogrammer. If you come across a unique device and would like to share it’s dump file for the sake of other users that may need it for unbricking, then please email it to DPF at openschemes..
Until next time – happy hacking!
Hi there,
thanks for posting the DS, that should finally boost some funky development.
Also, feel free to mess with some alternative source code: https://sourceforge.net/projects/dpf-ax/
It uses the free SDCC and implements a similar banking scheme like the Keil based code.
Also, it kinda allows “in system update” of the flash.
Unfortunately there seems to way to get at the bootloader (ROM). It appears to be protected against the typical ways of reading out memory areas. Maybe they don’t want us to see the horrible JPEG decoding implementation
I was also wondering whether someone has found out whose 8051 core they use. The USB I/O seems to be very close to the implementations from Crystal.
Cheers,
- hackfin
Hi hackfin, thanks for the post and sourceforge link! Boy, we were going to wait another day to talk about the bootloader, but we might as well spill it: In the SDK there is a flash tool for that hardware bootloader mode, and it works! We have another article written in hasty excitement about this very subject that we’ll release now.
Still no way to read out the bootloader code, but by investigating the vendor tool’s communications I think there are new and interesting things to be learned.
couple of notes for you folks.
1) If you are attempting to compile the firmware from scratch using the sources in the SDK, there can be a conflict between this tool’s cygwin make and other cygwin shells that may be in your path. On this PC here, there’s about 4 billion other cygwin apps. This conflict will result in stupid syntax errors any time there is a paren in the command. Like S( or DW(.. Fix it by deleting your paths in dos: Just do a set path=c:\windows\system32 before running makeall.bat and you’ll be good.
2) The make likes to bomb out in stage 2 due to unresolved references. It’s an Error 1 bombing to an Error 2. Fix it by adding DW(1,2) to the link config in the makefile for the offending directory. We just added to all the makefiles. For example: \Audio\Makefile
Stage2 : LINK_Config = RS(256) DW(1,2)
This will get your build completed successfully. Not that this will help, as none of the standard LCD’s work for the COBY, but it’s fun to play anyway
Ok, found ProgSPI and played around with it a little, seems to work well. Not on all frames though, some frame’s flashes are not recognized, I guess this requires more tweaking of the flashlib.ini. Seems their parser is very picky about the format.
).
Now: Someone willing to snoop the HID protocol sequence to download stuff? I’d still like to see a command line tool for linux (sorry
Anyhow, great news that we’ll be able to unbrick our dead DPFs at least under Windows.
Keep it going!
Cool! Glad to hear you got some success! Maybe we’ll have to extend that flashlib.ini some day.
BTW – it probably won’t be long until the protocol is snooped or the tool is disassmebled and a linux version is up and running. On our side, we would like to get a working vendor firmware compiled from scratch for the COBY first before we investigate the flash too.. So far the firm compiles and runs but the LCD is all wrong. Currently building up a new lcd lib that fits the vendor firmware framework.