Dell Digital Jukebox

[zook]

Okey. I've just added a new section to the Dell DJ wiki page.
I've tried to include everything that I could think of, pertaining to the firmware.
I'll add the program I've been using to extract the firmware, once I've updated it to handle big-endian files.

[LambdaCalculus]

Thanks, zook. I'm going to keep experimenting with this to see what else I can find.

I'm going to be a little busy in the next few weeks with some personal stuff I have to take care of, but I'll try to keep working on this when I get some time.

[zook]

Thanks, zook. I'm going to keep experimenting with this to see what else I can find.

I'm going to be a little busy in the next few weeks with some personal stuff I have to take care of, but I'll try to keep working on this when I get some time.

No problem, I'm used to being on my own, anyway

[zook]

Right, so I figured I'd post an update on things.
I've managed to get a disassembly of FRESCUE, it leaves a lot to be desired but it's useable.
The rescue mode software is located in the section of code which get's loaded at 0x840000.
I've found the main loop of the rescue menu and the functions which handles menu choices. I haven't fully investigated the ReloadFirmware code path, but there doesn't seem to be anything interesting there.
I've also found a function which parses the firmware archive format, from what appears to be a local file named upgrade.jrm.
The CINF block get's matched to a hardcoded device name string, as expected.
The CENC or TL block get's written to the local file jukebox2.jrm.
The DATA blocks, as assumed, get's written either to flash ram(F*) or the harddisk(H*).
The EXT0 block get's written to an internal device, either mcu0 or ide0. The P prefix to the device name does not appear to be checked.
The version I'm looking at checks for two extra block names: CODE and _PIC. CODE is related to CENC/TL and _PIC is related to mcu0, I haven't checked them indepth.

[LambdaCalculus]

zook, do you go to the IRC channel often? Maybe we can speak with the other devs about this as well.

[zook]

zook, do you go to the IRC channel often? Maybe we can speak with the other devs about this as well.

I've tried using the web interface a few times but it lags and ends up disconnecting me every 5 minute or so.

[mcuelenaere]

Could mcu0 stand for microcontroller unit?

[zook]

Could mcu0 stand for Memory Control Unit?

I suppose. Could also be Micro Controller Unit.
The devices are implemented in a polymorphic manner, which I haven't been able to track down at first glance. What I'm missing is the point where they're registered.

[zook]

I've added zenfirm.rar to the wiki page. It has 3 functions, extracting the firmware from the updater, displaying information about the firmware and splitting the firmware into seperate files. It includes heuristics for locating the firmware offset and key.
I've tested it with models from the NOMAD Jukebox 3 up to the Zen Vision: M. However, let me know if you run into problems with it.

The NOMAD Jukebox 3 uses the _PIC block which I mentioned earlier. The block data looks like the kind of ascii format you'd use to program an EEprom. I haven't checked which exact format it is, but it would definitely be interesting to see what the decoded code looks like.
My guess is that it contains the on-chip boot-loading code. Further more, I believe that EXT0 in the newer models fulfills the same purpose, with the main difference being that the EXT0 data is encrypted.

I've also discovered that the CENC/TL block get's read, validated and decoded/decrypted by the FRESC block code. I believe I've also found the code which displays the splash screen. To me this suggests that FRESC provides the base OS.

Now, that just leaves FBOOT unaccounted for. In some of the documentation I've read there's a mechanism refered to as a secondary bootloader. The reasoning behind this construct is that the on-chip boot loader is limited to reading a fixed amount of data into a fixed location. To work around this limitation, you'd create a secondary bootloader which is small enough to fit, and capable of doing the full boot. My guess is that FBOOT is such a device.

So if all my assumptions hold up, that leaves an execution sequence like this:
_PIC/EXT0 -> FBOOT -> FRESC -> Jukebox2.jrm (CENC/TL)

I'm currently trying to work out the encryption/encoding of Jukebox2.jrm. That'll mostlikely open up the door to examining FBOOT too, as they both contain similar artifacts.
If anyone feels like working on the ascii encoding used in the _PIC block used in the NOMAD Jukebox 3 firmware, that would be a great help. We need to understand the roles of the above mentioned components, as that'll be our only way into the fully protected firmware versions.

[mcuelenaere]

For people who are too lazy to extract the _PIC themselves: http://www.verzend.be/v/2031877/JB3Upgrade_1_20_0_r_PIC.bin.html

@zook: I tried running it through IDA, but didn't came with something usefull. Which processor/architecture do you think it is running ? C55x ?

[zook]

For people who are too lazy to extract the _PIC themselves: http://www.verzend.be/v/2031877/JB3Upgrade_1_20_0_r_PIC.bin.html

I believe the ascii encoding is what the 010 editor calls Intel 32-bit Hex Code (see the Copy As menu).

@zook: I tried running it through IDA, but didn't came with something usefull. Which processor/architecture do you think it is running ? C55x ?

The TMS320DSC24 manual (http://www.archopen.org/tiki-download_file.php?fileId=6), which should be similar enough, states that the ARM core is booted first and that it's responsible of resetting the DSP core.
The ARM core is a Micro Controller Unit, so it would make sense that _PIC/EXT0 contains the ARM boot code.

[LambdaCalculus]

The ARM core is a Micro Controller Unit, so it would make sense that _PIC/EXT0 contains the ARM boot code.

I believe you're right, zook. Why would it be any other way?

[zook]

It's been a busy week for me, so I haven't had all that much time to look at this.
However, I'm just one function short of having codified the CENC decoding.
The algorithm is a run length encoding variant. The first 32-bit word of the CENC block is the decoded size, then follows the sequences of encodings. The two most significant bit's of the first 8-bit word determines which type of encoding the sequence is. 0x80 and 0xC0 are repeated character block types (effectively memset's), with different length encodings. 0x00 and 0x40 is the type which I'm missing, I haven't traced it enough to describe it, but it's much more elaborate. My guess is that it's used to decode repeated patterns, but it goes hay-wire in the simulator so I can't say for sure.
Anyway, if any of this sounds familiar to anyone, then please chip in. I've had a feeling of deja vu since I first glanced at the code, but I still can't place where I've seen it before.

As an aside I've looked at the flash related code a bit and it seems like it provides these name mappings: TSIG, BOOT, CONF, TOC0, PFM1 and RESC. I was hoping to find code to decode/decrypt the BOOT block but so far I haven't found any. I'll need to fix the processor module though, there's too many important things missing currently.
I've also found the lowlevel functions which are used to erase or program the flash, so that should make an excellent starting point for working out how flash entries are processed during a firmware upgrade.
The flash functions in the Zen Micro firmware (the latest unprotected version) indentifies and accept 3 different types of SST flash chips. ID: 0xBF and 0x2780/0x2781/0x2782. I haven't cross-checked with the Dell DJ, but my guess is that it's the same. Why else would they accept different types?

[mcuelenaere]

In segment003 of FRESC of DellDJ_1_20_03_rk.bin there are a lot of BE EF and FE EB; also some FF FF FF ..
These remind me of the minifs/cfs filesystem described on nomadness;
could this be a (mini-)implementation of this filesystem (e.g. for emergency purposes)?

I tried finding those docs where this is described, but can't find them anymore...
But in the HDD-dumps posted on epiZENter you can also find some BE EF and FE EB's (these are probably boundary markers).

[zook]

In segment003 of FRESC of DellDJ_1_20_03_rk.bin there are a lot of BE EF and FE EB; also some FF FF FF ..
These remind me of the minifs/cfs filesystem described on nomadness;
could this be a (mini-)implementation of this filesystem (e.g. for emergency purposes)?

I tried finding those docs where this is described, but can't find them anymore...
But in the HDD-dumps posted on epiZENter you can also find some BE EF and FE EB's (these are probably boundary markers).

Ohh, FRESC does contain a filesystem implementation. I'm not sure the BE EF and FE EB blocks are referenced anywhere, though.
I've gathered a list of the most important functions that I've named in my disassembly:

Code: [Select]

00849EB4 RescueModeMenu // Handles the rescue menu.
00849B60  ReloadFirmware
00849C38  FormatAll
00849DAC  CleanUp

0084BA08 Bootup // Is responsible of intializing everything.
0084D65C  System_Init
00800000   Chip_Init
00801A64    Lcd_Init // Device construction and registration.
00804084    Adc_Init // --||--
0080421C    Iic_Init // --||--
00802064    Rtc_Init // --||--
00804734    Mcu_Init // --||--
00809750   Flash_Init // --||--
00848480   Usb_Init // --||--
00808EB0  Ide_Init // --||--
0084D100  ReadJukeAndSplash // Loads the player software and the splash bitmap.
0084C130   cenc_decode // Decompresses the player software.

0084A5BC ProgressUpgrade // Handles the firmware archive, which is stored locally as upgrade.jrm.
0084C1AC  ParseCIFF // Parses the firmware archive, validates it and stores each entry according to their type.

00800164 Device_Register // Is used to register a device class instance.
008004AC Device_Open // Is used to access a device class instance.

00806804 Object_Init // Based on how these functions are used, I'm guessing that they're synchronization primitives. But I could be wrong.
00806854 Object_Lock
00806880 Object_Unlock

0080304C _fopen // Provides access to the filesystem.
00803610 _fread
00803BE5 _fwrite

Im including the IDA plugin that I've been using, it's far from perfect but it's a step in the right direction: http://www.mediafire.com/?1mt2xznax33
Once again, the source is included along with a pre-compiled binary for IDA 5.0.
Once you've copied it to the plugins directory and loaded your FRESC file, you need activate the plugin by selecting Edit->Plugins->TMS320C55 processor extender.
It will extend the processor module to handle the two previously mentioned instructions, but it doesn't output the instruction text properly, so sometimes parts of or the whole instruction line is missing.
There's two more instructions which aren't handled at this point, because I haven't been able to find any documentation on them.
I plan to fix as many of the issues as I can once I've gotten the player software fully decoded.


Regarding the CENC encoding. I've gotten my code to the point where it produces the same output as the simulator in single case use. However, there's some logic or indexing error(s) in the code, which derails the decoding. So there's still some work left.