Rockbox Development > New Ports
Dell Digital Jukebox
zook:
--- Quote from: LambdaCalculus379 on September 24, 2007, 03:10:05 PM ---zook, do you go to the IRC channel often? Maybe we can speak with the other devs about this as well.
--- End quote ---
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:
--- Quote from: mcuelenaere on September 24, 2007, 03:23:53 PM ---Could mcu0 stand for Memory Control Unit?
--- End quote ---
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 ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version