WARNING : if you don't feel comfortable working with an hexadecimal editor, and manipulating bytes, don't modify your firmware. There are risks involved, especially for the DAH-1500 in which code and image are in the same file. If you modify some important part of the code, your cube will be dead. I cannot be held responsible for what will happen. If you don't agree, stop reading now and go watch TV instead.

1. Introduction : falling in love with a cube.

I wanted a very small mp3 player to replace my venerable Archos heavy Jukebox and its Marlboro CMoy amp. I love my Archos, especially after I replaced the hard drive with a 80 Gb one. But for a day of work, I don't need to store that much music. So I needed a smaller and lighter one. Hard drives are very fragile, so I decided for one with Flash RAM. I browsed some sites, and then I saw it : the korean Mobiblu DAH-1500 cube, also sold under the JNC SSF-8000 or SSF-8100 brand, also called Ozzio Musica in Japan and Mexico, also called Unimade i-Cube in Spain, also called Q-Be, also called SupportPlus, also called Yes YMP908 in Sweden, there are also several on eBay sold as "replicas" with a MP3 Digital Player logo, etc... Actually, I never saw a player sold with so many names and versions, I had some trouble to figure it out. I think this is a monumental error by the original company. Anyway. The cube is extremely small (one inch), a cute OLED blue screen, and a curious and funny cubic shape. I needed one. Now.

A cube with many names ! Mobiblu JNC Ozzio Unimade Q-Be SupportPlus Yes MP3 Dig.Pl.

At the time, the Cube was not yet sold in the US. So I bought an unofficial korean one on eBay. It's the DAH-1500. I think it is also the one sold in Europe right now. The sound quality was very good, so I didn't even felt the need to use an amplificator anymore, which is strange for such a small gizmo. Of course, my earphones are high-quality and noise-cancelling Etymotic ER-6. Later an improved version (the DAH-1500i) became available at Walmart online store. For a reason I wil explain later, I bought it too. Unlike my precedent cube, this one has USB 2 and a voice recording ability. It can also read WMA with DRM, but I hate the guts of any kind of evil DRM, so I don't care. The firmware and the design is a little bit different and clearly improved, although for some reason I preferred the 1500 fonts, but I can live with it.

When I bought my Archos Jukebox a long time ago, I found out that some cool people reversed, hacked, decrypted and disassembled the firmware (and some of the hardware) of it, and produced from scratch a brand new open source firmware for all Archos mp3 players. I love this kind of hacking and modding (Hello Make magazine !). Real DIY sprit. This project is called Rockbox, is still going on, and if you still have an old Archos, you must check it out. The firmware they made is vastly superior to the official one, with so many improvements and plugins that it would be too long to list them all. Hell, they even produced shades of grey on a LCD screen which was not designed for that, and even display JPEG and video. Incredible stuff. I never came back to the official firmware. Congratulations to Archos as a company for allowing this.

The Rockbox crew are my heroes, and I wondered if I could do the same with my brand new tiny little cube. Well, don't hold your breath, the response is no. I painfully found out that I probably lack the skills to program a new firmware from scratch (especially without knowing what micro-controller is used, which is quite annoying when you want to disassemble it), or even to add some useless function to the existing firmware, such as a text reader or a Pong game. So I did what lame people like me do as a consolation : I changed the embedded images to make, at least on the surface, a customized version of my cube. It is very easy, as you will see. Please note that for the moment, I didn't code a completely automated tool, so you will have to do some manual byte manipulation (insertion, copy/paste) with an hexadecimal editor. Come on, it's more fun like that. Maybe later I will code something easier to use if there is some demand (which I highly doubt).

WARNING 2 : It is much easier and safer to only modify the images than the code itself. Yet, you will see that if you do something wrong and mess up with some important bytes, there is a chance that you will definitely kill your Mobiblu Cube. So, if you don't want to take any risk, don't modify anything. I won't be held responsible for anything wrong that may happen to your cube and bla bla bla [insert legal crap here to be sure that nobody will sue my ass].

2. The tools : what you will need.

2.1. Basical stuff

I already mentioned an hexadecimal editor. And, of course, an image editor to create the new images, like The Gimp. Oh, and a PC running any Win32 flavor, because I code for that platform.

2.2. A Nokia cell phone firmware image viewer.

After painfully understanding what is the format of the images embedded in the firmware, I discovered by chance that it's exactly the same that is used in Nokia cell phones. I found out that several people already coded nice tools to decode (and sometimes change) images in Nokia firmwares, so I didn't have to code my own. We can use FlashView 1.1, by Alf. I like it because you can see at once vast areas of the firmware. Another good one is FlashGraphic 1.01 by Hasky, to pinpoint exactly one image.

2.3. My tool : Cube Checksum Calculator.

This program will only be needed for hacking the DAH-1500 (Europe/Asia) firmware. If you ordered your cube at Walmart in the US, you don't need it. Curiously, only the former firmware is protected by a checksum integrity verification routine. Maybe it's because they have now separated code and data, and the images do not need to be protected. A cheksum verification routine means that if you change an image only, the old checkum will not fit the new data, and the upload of the firmware will fail : the cube will know something is not right. So after changing the images, you have to fix the checksum. That's what this program is doing. The checksum is very simple, it's a double sum of every other byte. Source included, TASM32 assembler.

2.4. My tool : Cube Image Encoder.

This small program will transform a 64x48 24-bits black and white (no grey) BMP image into a string of Nokia/Cube binary pixels sequence. The output is 384 bytes long, because every pixel is off or on, 0 or 1, and so is encoded by a single bit, and (64x48)/8 is 384 (a byte is 8 bits). You can then paste these bytes at the exact place of the image that you want to replace inside the firmware. Be careful not to overwrite the DEDE markers which are situated every 512 bytes in the DAH-1500i firmware. Source included, TASM32 assembler.

So how are the images encoded ? It's extremely simple. Get the first column of pixels on the left. Get the 8 on top. The "off" ones are 0, the "on" ones are 1. Start from the bottom. You have a string of 8 binary values. That's the first encoded byte. Then do the same for the second column of pixels. When you reach the 64th column on the right, you start again on the left. Etc. Here is a graphic to explain :

Here is an example, the blackened pixels represent the "on" ones :

The encoded image would start like this, in binary : 10000000 11000000 00111111 00001111...

The same in hecadecimal : 80 C0 3F 0F....

The Nokia viewing tools we are using do the opposite. They transform binary strings back into images. That's why when you look at a firmware with them, you see a bunch of random-looking bytes when it's code, and then suddenly when you are around the place where the bitmaps are stored, you see images.

3. The DAH-1500 firmware.

2.1. Basical stuff

The firmware is composed of 2 files that you upload manually on the root of the cube : f1.sys and fw.bin. They are both 512 Kb long, exactly 524288 bytes long. A simple look with FlashView tells you that the images, fonts, and animations are inside the fw.bin file. Also that there are some hidden animations, showing various brand names, only one is probably shown. Here are all of them, the first one beeing the only one that I am used to, because it's the animation that is shown during the boot sequence on my cube :

By observing checksum errors, it seems to me that f1.sys is the code for the immediate upgrade, and fw.bin is the code that will be used at the next boot, after the cube verified and then flashed its own memory with it. The consequence is that if you mess up with important code like USB transfer or bootstrap sequence, the cube will flash itself with bogus code that will kill any subsequent attempt of boot or USB transfer. In other words, your cube will be dead. It happened to me. This is very unlike the Archos firmware, which had a fixed ROM firmware (actually, you could flash it too, to speed up the boot process, but only if you wanted to) that handled USB transfers, that could be overriden with a new one read from the disk at every boot. So in case of problem, you could just remove the messy firmware from the disk and start again.

Don't worry if you don't understand the above paragraph, I don't either. It's completely hypothetical. The only sure thing is that I destroyed my DAH-1500 cube, and had to buy a new one, this time a DAH-1500i. The good thing is that I could open it without too much worry, to see how they managed to get everything inside and the nice engineering of the cube, just like them, and them and them.

2.2. Checksum

How did I find out about the checksum ? Don't unleash the lawyers : I didn't disassemble anything. There was no need for it, and it would be quite difficult anyway because I don't even know what is the micro-controller on which the code is run (although I know the music encoding / USB is handled by a special korean chip called Skylark2, made by ECT). I just compared the three firmware versions that are available on the various Mobiblu websites, namely the 1.56, the 1.60s (which did not work on my cube) and the 1.60f. If you are a bit used to reverse engineering, you can guess right away, with an hexa editor, where is the checksum (random looking bytes near the start, offset 46h), and its size (2 bytes). Then you do a 1-bit change somewhere, and try to upload the firmware : it fails. So you do the same change on what ou think is the checksum, and after a few tries (best guess is that the algorithm will be a sum, a substraction, a XOR, a CRC...), it works. Then you just code a program to automatize the task.

This program is called Calculate_Cube_Checksum, and will calculate the new checksum, and write it into a new modified firmware called "firmware_with_checksum". It also verifies that the size is correct, but that's it.

2.3. Change the images

So where are the interesting images ?

You can change every image you want : fonts, small icons or full-screen image. Here we are only going to deal with full screen, 64x28 pixels graphics. Here are the main ones. First, the offset in decimal (as used by FlashGraphic), then in hexadecimal (as used by FlashView), then an image of what is it. Note that the offsets are the same in 1.56, 1.60s and 1.60f versions of the firmware :

The boot / switch off animation (the same is played in reverse order when you switch off your cube), 6 frames :

422912d : 67400h : frame 1 423424d : 67600h : frame 2 423936d : 67800h : frame 3 424448d : 67a00h : frame 4 424960d : 67c00h : frame 5 425472d : 67e00h : frame 6

The "Wait" image :

431616d : 69600h

The USB connect image (note that there will be a small icon overlapping it during connection, check the example with the hand):

394240d : 60400h

The image when charging (there will be an icon too):

394752d : 60600h

You can change many more things that don't necessarily fit in the 64x48 pixels full screen, for example plenty of small icons, fonts, and also all the menus. I didn't try everything. Note that when the icons are not 64 pixels wide, what you see in FlashView is a bit distorted (but you can change the viewing width, for example set it at 90 for the clock font at 68000h). Just don't touch the code. Have fun. After modifying your firmware, just recalculate the checksum and upload.

A last warning : with the hexadecimal encoder, be careful not to insert the new bytes, but to overwrite the old ones. If the modified fw.bin is not exactly the same size as the original one, there is something wrong. You update it as the manufacturer says, by moving the original f1.sys and the modified fw.bin in the root of the cube, and reboot it.

4. The DAH-1500i firmware.

2.1. Basical stuff

Quickly, because I'm starting to get bored. This time, you have to install a utility that will upgrade the firmware for you. It's installed in "My Program/MP3 Update". The 4 files that constitute the firmware are bootmanager.sb, StmpSys.sb, UsbMsc.sb, and resource.bin. Don't touch the three first ones. You will only modify resource.bin.

Just as a curiosity, there also seem to be some hidden stuff in the firmware. Like a biorythm calculations, and a Blackjack card game :

2.2. Change the images

This resource.bin file is quite big. If you observe it with FlashView, you will see that it contains a huge amount of what looks like korean and/or japanese characters first. The images are far away. Also, there are two annoying things that distorts the images when watched with FlashView, unlike with the DAH-1500 firmware in which they are in a flat raw linear format, and does not simplify the modification :

1. Each image has a small 15 bytes header that contains some information like its X and Y size, and the total size of the frame. So each full-screen image now occupies 15+384 = 399 bytes, which is not a multiple of 64, so they are no more aligned with our viewers.

2. Every 512 byte during the whole length of resource.bin, there is a double byte (DEDE in hexa), which is probably some kind of memory boundary marker. So sometimes a full-screen image frame will be 399 bytes long, sometimes 401 bytes long. Once again, no more nice alignement.

This DEDE marker is particularly annoying when you want to paste the new image data. You have to conserve it at the right place. For example if you originally have this :

You want to paste your new bytes around the DEDE, like this :

Here is where are the images I changed (the firmware version is 100.100.105), you may want to change other ones. I indicate if there is a damn DEDE inside the 384 bytes you will have to paste :

The boot logo (first thing to appear, stays on for one or two seconds). Start with this one as it's the easiest :

283284d : 45294h : no DEDE

The boot animation (unlike the DAH-1500, there are 2 different animations for the boot and the switch off sequences), 6 frames :

3205759d : 30ea7fh : frame 1 : no DEDE 3206158d : 30ec0eh : frame 2 : DEDE 3206559d : 30ed9fh : frame 3 : DEDE 3206960d : 30ef30h : frame 4 : DEDE 3207361d : 30f0c1h : frame 5 : no DEDE (note : the official image is one pixel too low) 3207762d : 30f252h : frame 6 : no DEDE

The goodbye / switch off animation, 8 frames :

3211766d : 3101f6h : frame 1 : DEDE 3212167d : 310387h : frame 2 : DEDE 3212568d : 310518h : frame 3 : DEDE 3212969d : 3106a9h : frame 4 : no DEDE 3213368d : 310838h : frame 5 : DEDE 3213769d : 3109c9h : frame 6 : DEDE 3214170d : 310b5ah : frame 7 : DEDE 3214571d : 310cebh : frame 8 : DEDE

You can change many other things that are not necessarily 64x48, if you want. Once you have modified the file, just put it back in the "mp3 update" directory, and update your firmware.

And that's it for today. Have fun, and, in the words of Richard Stallman, happy hacking !

[Update] This page has been cited by Anything But iPod, The MP3 Players, MP3Buzz, Tiny MP3 Tracker, and Mac Harris blog. Thanks people ! Maybe it's time to do a tool for an easy way to change the images. I will work on that when I have a minute.