Rockbox Technical Forums

Rockbox Development => New Ports => Topic started by: zorko on November 11, 2016, 07:26:14 AM

Title: Sony NW-E394 - new firmware
Post by: zorko on November 11, 2016, 07:26:14 AM
ThereĀ“s new firmware available for this device. Could this help with reverse engineering?
Title: Re: Sony NW-E394 - new firmware
Post by: pamaury on November 11, 2016, 08:00:42 AM
the problem with this player is that:
I'll have a look at the firmware upgrade but last time I tried to play with the device, it seemed that they changed the scrambling/encryption on their device from RKnanoB, and I was unable to do anything.

EDIT: it appears that utils/rknanotools/rkboottool can unpack the firmware. Most files are boring except for the main firmware called stage3.bin (assume I got the tool right). This file seems to use the same format as the RKNanoB, but we do not real understand it at the moment. The tool as an experimental mode for it where it prints the tentative sections but I need to dive into it to see if it makes sense. The good thing is that it *seems* it is not scrambled. My understanding of the format is that firmware is split into "sections" that are loaded dynamically (because the whole firmware does not fit into RAM). The file gives the placement of each "section" in RAM (which would explain why they overlap since a section is unloaded before the next once is loaded). It still need to test this theory by looking at the code. But we still don't have the programming manual for this soc so it might be hard to do a port without it.

EDIT2: for future reference, there is a crowdsourced project using RKNanoD called Firefly ( ( They said they would release everything but so far they only released the schematics. I am still hoping that they will release a firmware one day, that might be helpful.

EDIT3: a very quick look suggests that it makes sense: after splitting stage3 in around 150 elf files, most of them seem to follow the canonical ARMv7M arrangement which is that the code starts with a table, where the first entry is the stack pointer address and the next N entries are function pointers for exceptions. However the N seems to vary and if this is indeed the format, then it is clearly enforced someone in software because the files are not necessarily loaded at address 0. Or those might be a vtable for the section.