Decode "radio.dnl" file
Posted: 11 Aug 2022, 08:58
Hey guys, today i'd like to share my findings about the "radio.dnl" file. Yet another DNL file. Like all other binary files from the update-CD it has a common trailer, but the format is different from other DNL files, so don't mix them up.
I'll summarize my findings in the Wiki (German): https://mk4-wiki.denkdose.de/artikel/na ... /radio.dnl
and software/example-data in my Github repo at: https://github.com/igittigitt/unpack_dnl
The format seems simple. There is always a 0x80 byte frame with management-frame, followed by a at least 0x100 bytes (or multiple of 0x100 bytes) data-frame. Unused bytes at the end of a frame are filled with 0x55. The size of the data-frame (payload) is not limited, but a payload can be split up into several data-frames, which are simply concatenated to build a large file.
The "radio.dnl" contains data blocks (files) for updating the V850 firmware in it's internal Flash, also the V850 bootloader, the external EEPROM and some currently unidentified data.
A management-frame uses only 0x20 bytes (rest is filled with 0x55). Here as an example from the "radio.dnl" of the MCA update-CD:
The first byte at offset 0x00 is the "type" of the block:
The second byte at offset 0x01 is an "segmentation-index":
Now a uint32 (big endian) follows at offset 0x02, giving the address of the data in target (Flash)
Then another uint32 (big endian) at offset 0x06 give the size of the payload. The remaining fill-bytes (0x55) in the the (last) frame is not part of the payload.
The 4 bytes at offset 0x0A looks like a checksum, but until now i could not figure out the type and data it checks.
Also the rest of the frame is currently unknown to me.
The data-frame simply contains pure payload up to the size of the frame, or the length given in the management-frame.
I've written a simple unpacker using Python 3 (see repo-link above). It will spit out these files:
"block_0x34_eeprom.bin"
"block_0x40_v850.bin"
"block_0x80_unknown.bin"
"block_0x81_unknown.bin"
"block_0x82_bootloader.bin"
You can use IDA Pro or Ghidra to disassemble the V850 firmware, for example.
I'll summarize my findings in the Wiki (German): https://mk4-wiki.denkdose.de/artikel/na ... /radio.dnl
and software/example-data in my Github repo at: https://github.com/igittigitt/unpack_dnl
The format seems simple. There is always a 0x80 byte frame with management-frame, followed by a at least 0x100 bytes (or multiple of 0x100 bytes) data-frame. Unused bytes at the end of a frame are filled with 0x55. The size of the data-frame (payload) is not limited, but a payload can be split up into several data-frames, which are simply concatenated to build a large file.
The "radio.dnl" contains data blocks (files) for updating the V850 firmware in it's internal Flash, also the V850 bootloader, the external EEPROM and some currently unidentified data.
A management-frame uses only 0x20 bytes (rest is filled with 0x55). Here as an example from the "radio.dnl" of the MCA update-CD:
Code: Select all
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 80 00 00 00 00 00 00 00 00 BB C6 8D 58 6A 00 80 €........»Æ.Xj.€
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC 30 ..............ü0
00000020 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
00000030 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
00000040 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
00000050 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
00000060 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
00000070 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
Code: Select all
0x34 => EEPROM data (8 KB)
0x40 => V850 Firmware (636 KB)
0x80 => Unknown (1 KB)
0x81 => Unknown (1 KB)
0x82 => V850 Bootloader (22 KB)
Code: Select all
[code]
0x00 ⇒ Data of block is fully contained within the data-frame (no segmentation)
0x01 ⇒ Data of block is segmented over several data-frames, this is the first one
0x02..up ⇒ Consecutive data-frames appended to the existing block of the samte type
Then another uint32 (big endian) at offset 0x06 give the size of the payload. The remaining fill-bytes (0x55) in the the (last) frame is not part of the payload.
The 4 bytes at offset 0x0A looks like a checksum, but until now i could not figure out the type and data it checks.
Also the rest of the frame is currently unknown to me.
The data-frame simply contains pure payload up to the size of the frame, or the length given in the management-frame.
I've written a simple unpacker using Python 3 (see repo-link above). It will spit out these files:
"block_0x34_eeprom.bin"
"block_0x40_v850.bin"
"block_0x80_unknown.bin"
"block_0x81_unknown.bin"
"block_0x82_bootloader.bin"
You can use IDA Pro or Ghidra to disassemble the V850 firmware, for example.