Need help hacking DP832 for multicolour option.

[Spork Schivago]

What's the bootloader code look like unscrambled?   I have searched through the file looking for some sort of table.   I've found html files, css files, etc.   But there's very few file names.   I found a couple, here's their offsets:

Code: [Select]

Offset 002E8FF8: /images/nav_1_0.jpg
Offset 00285CEC: /DP800A_NetworkSettings.html
Offset 00285D0C: /DP800A_setting_pswrong.html
Offset 002BA170: /RG1000NetworkSettings.css
Offset 002BA18C: /DP800A_NetworkStatus.html
Offset 002BA1C4: /DP800A_WelcomePage.html
Offset 002BAAC4: /RG1000WelcomePage.css
Offset 002BAADC: /DP800A_Security.html
Offset 002BAAF4: /DP800A_successful.html
Offset 002BAB0C: /images/logo_DP800.jpg
Offset 002E8FA8: /RG1000Security.css
Offset 002E8FBC: /DP800A_Help.html
Offset 002E8FD0: /images/logo.jpg
Offset 002E8FE4: /images/nav_1.jpg
Offset 002E8FF8: /images/nav_1_0.jpg
Offset 002E900C: /images/nav_2.jpg
Offset 002E9020: /images/nav_2_0.jpg
Offset 002E9034: /images/nav_3.jpg
Offset 002E9048:/images/nav_3_0.jpg

There were more, but I got tired.   I tried finding how those names were related the data and I couldn't find anything.    For example, I thought there'd be a good chance the /images/logo.jpg file would exist.    So, I searched for hex values like 2E8FD0   and D08F2E.  I found D08F2E at offset: 21A7D4

I found a bunch of other addresses in that area and tried going to what they said, and they took me places, some of them seem to line up and I thought I found the table, but then some of them didn't.   I give up for the night and I'm going to bed.   Maybe someone else can figure it out though.

[stj]

What do you guys make of offset 0x30A69B?   We're still missing something on the decryption or this file is somehow compressed, but I don't think it's compressed.   There's to much text.   Text compresses real easy like.

I see a comment:

Code: [Select]

//window.alert("oh yeah!\nö ~SOng is a pig!");

oh yeah!   then a new line.    But the funky o with two dots over it, the squigly ~, stuff like that I don't think's right.   There's a lot of ý's where there shouldn't be.   Maybe if we could work on getting a bit cleaner descrambling program, we'd see things a bit differently?

"nö ~SOng" - is a font issue - use something else to view it such as UTF-8

[Spork Schivago]

What do you guys make of offset 0x30A69B?   We're still missing something on the decryption or this file is somehow compressed, but I don't think it's compressed.   There's to much text.   Text compresses real easy like.

I see a comment:

Code: [Select]

//window.alert("oh yeah!\nö ~SOng is a pig!");

oh yeah!   then a new line.    But the funky o with two dots over it, the squigly ~, stuff like that I don't think's right.   There's a lot of ý's where there shouldn't be.   Maybe if we could work on getting a bit cleaner descrambling program, we'd see things a bit differently?

"nö ~SOng" - is a font issue - use something else to view it such as UTF-8

I have tried UTF-8 but it doesn't seem to make a difference.   Are you sure that's an issue?   There's some strings like:

Code: [Select]

http://ýw~.w3.org/TR/html4/loose.dtd

That's at offset 0x00309133

I'm using HxD and right now have the character set set to ANSI.  I change it to the various different options and none show www.   So, with it set to ANSI, I copy the text, then I open notepad.   I paste the text.   I go to File -> Save As and I set it to UTF-8.   I reopen the text, it's the same.   I paste the text again, now that Notepad is in UTF-8 mode, still the same.   Is there a better hex editor?   I like how HxD can do the various checksums (even custom ones), I like how I can set how many bytes to group together and how many bytes to display per row....It's still lacking though and I don't think it's going to be updated any time soon.

It'd be nice to be able to see the bytes in something besides hex, for instance...Being able to set the encoding to UTF-8 would be nice.   Being able to do a side-by-side comparison of different windows would be nice.   Kinda like how Volkimel displayed the differences between the firmwares, with the underlines and stuff like that.   Any suggestions on a better hex editor for Windows?

I got a little bit of time today.   I want to download the source to Volkimel's program, setup a compiler, make an executable.   I'd like to add some simple command line switches or write a second program that reencrypts the firmware.   If anyone has already done this and just wants to share the source code, I'd greatly appreciate it.   I haven't written a C program for the PC in a long time and it'll take me a bit to walk through the code.   I was looking at the C program Volkimel wrote and I don't fully understand it yet.   That's an issue.   I used to be a C programmer and got paid for writing code.   I shouldn't have trouble understanding this!   It's just been so long.

[2N3055]

In Windows, Notepad++ is the choice..

[Macbeth]

Spork,

I just wrote a simpler version in Python and added a -r command line option for re-scrambling.

No need for C compilers and .exe files Install Python 2.7 if you don't have it already, and yes Notepad++ is what I use in Windows.

Code: [Select]

# DP800 file descrambler

import argparse

parser = argparse.ArgumentParser(description='Descramble a Rigol DP800 .GEL file')
parser.add_argument('-r', '--rescramble', action='store_true',help='convert back to original format')
parser.add_argument('infile', help='input filename')
parser.add_argument('outfile', help='output filename')
args = parser.parse_args()

with open(args.infile, 'rb') as infile:
    buf = bytearray(infile.read())
    infile.close()

offset = 116

for i in range(len(buf)):
    if args.rescramble:
        b = buf[i] + offset
        if b>255: b-=256
    else:
        b = buf[i] - offset
        if b<0: b += 256

    buf[i] = b
    offset += 1
    if offset > 255: offset=0

with open(args.outfile, 'wb') as outfile:
    outfile.write(buf)
    outfile.close()


[Spork Schivago]

Spork,

I just wrote a simpler version in Python and added a -r command line option for re-scrambling.

No need for C compilers and .exe files Install Python 2.7 if you don't have it already, and yes Notepad++ is what I use in Windows.

Code: [Select]

# DP800 file descrambler

import argparse

parser = argparse.ArgumentParser(description='Descramble a Rigol DP800 .GEL file')
parser.add_argument('-r', '--rescramble', action='store_true',help='convert back to original format')
parser.add_argument('infile', help='input filename')
parser.add_argument('outfile', help='output filename')
args = parser.parse_args()

with open(args.infile, 'rb') as infile:
    buf = bytearray(infile.read())
    infile.close()

offset = 116

for i in range(len(buf)):
    if args.rescramble:
        b = buf[i] + offset
        if b>255: b-=256
    else:
        b = buf[i] - offset
        if b<0: b += 256

    buf[i] = b
    offset += 1
    if offset > 255: offset=0

with open(args.outfile, 'wb') as outfile:
    outfile.write(buf)
    outfile.close()


Macbeth, thanks for the Python script.   I'm a bit of a C fan personally and I might just use your Python script to rewrite the C code to process it.   Not that there's anything wrong with Python.   It's a very nice language and everything.

So, Notepad++, I've heard of this, but it's an actual hex editor that can do everything that I'm looking for?   If it's the program I'm thinking of, it's been around for a very long time, when I was in high school.   Back then, I remember it just being a fancy text editor...I'll check it out.

[Macbeth]

Python... nice!... this is my first attempt at a Python script from scratch and I'll have you know it was a serious PITA! Tabs vs spaces fighting each other !

Yeah, good old 'C' is my ultimate fallback and what I use for microcontrollers, short of pure assembler, but all the fashionable kids are doing it in Python, and to be fair interpreted stuff is nicer/easier to play with.

Notepad++ is a text editor with programmers in mind. My Windows Hex editor is free from www.hexedit.com, I've not tried HxD. I will give it a shot...

[Spork Schivago]

Python... nice!... this is my first attempt at a Python script from scratch and I'll have you know it was a serious PITA! Tabs vs spaces fighting each other !

Yeah, good old 'C' is my ultimate fallback and what I use for microcontrollers, short of pure assembler, but all the fashionable kids are doing it in Python, and to be fair interpreted stuff is nicer/easier to play with.

Notepad++ is a text editor with programmers in mind. My Windows Hex editor is free from www.hexedit.com, I've not tried HxD. I will give it a shot...

Yeah, I have to agree about the Python.   I've seen a lot about it recently and started learning it from the free MIT courses.   For an interpreted language, it's not too shabby.    I'm slowly getting into PICs.   I just don't have enough free time and too many projects.    C is my favourite, even for the PICs although assembly might be a little more efficient (for microcontrollers I mean).   For being a high level language, the C compilers I generally use seem to pretty optimized.   My all time favourite is the GNU C compiler.

So Notepad++ isn't what I'm looking for.   I'm looking for a better hex editor for Windows.  I'll check out hex edit.   HxD is free as well.   It was promising but I think it's dead now.   The checksum features are nice though.   It can calculate all the way up to SHA-512.  You can pick just one, or certain ones, or all of them, you can have it use custom checksums, you can have it run a checksum on the whole file or just the selection.

[volkimel]

Spork,

I just wrote a simpler version in Python and added a -r command line option for re-scrambling.

No need for C compilers and .exe files Install Python 2.7 if you don't have it already, and yes Notepad++ is what I use in Windows.

Very nice, Macbeth. Thanks.
Being a microcontroller programmer by trade, it was easier for me to just get a quick C console .exe together. Just because, I knew what I was doing and I was excited to see this pattern.
But Python is of course a nice language for this kind of work. I didn't have Python installed on the machine I'm doing this with.

I was looking more into the structure of the GEL file, again. Haven't tried any reflashing my DP832, yet. It's still happily running on 00.01.13.00.01 with all options.

Now, simply put "18 F0 9F E5" into Google and see what comes out: A few websites suggest it is the vector table of an ARMv5 architecture, leaving the correct space at 0x00000014 and doing the correct stuff at the few vectors.
So, when disassembling this, we could figure out where the reset vector branches, make it our main() and disassemble from there. That's a task for someone who knows what he's doing.

So far, I only took it as indication that we have to concentrate on the few bytes before the first "18 F0 9F E5". I would guess that's the header then.

For 1.14 it looks like this:
0x000000: B4 AE 9A 89 00 40 81 40 00 00 52 00 A0 3D 00 00
0x000010: FF FF 00 00 9F 00 00 00 9C 3D 00 00


In this bit of hex code there are "A0 3D 00 00", followed by "FF FF 00 00", and "9C 3D 00 00". If you read these backwards (different endianess, I'm always getting confused, which is which) these are addresses or offsets that point close to another structure like the header:

Again, in 1.14 it is here:
0x003D9C: 00 00 00 00 A5 00 00 00 00 00 55 55 55 55 00 00
0x003DAC: 64 00 00 00 01 00 01 00 01 00 00 00 00 40 AB 61
0x003DBC: 00 00 00 00 A1 6D 33 00 FF FF 00 00 9F 00 00 00
0x003DCC: 52 49 47 4F 4C 4C 00 00 00 00 00 00 00 00 00 00

The GEL file continues with "18 F0 9F E5" again, so I guess the structure is done after these 64 bytes.

Like in the first 28 Bytes at 0x000000 there seems to be another address or offset before the "FF FF 00 00", again here. It is "A1 6D 33 00".
If you take this as another offset to 0x003DDC (where the ARM Vector table starts) and jump to location (0x003DDC + 0x336DA1 = 0x33AB7D), you are exactly 64 Bytes from the end of the GEL file.

The last 64 Bytes in 1.14 look like this:
33AB7D: 9F 00 00 00 68 FC 5A AA 5F 2A A7 CF CF BC 40 37 <-- maybe checksums here?
33AB8D: 1C 20 81 2A 66 8F D4 A9 90 24 05 00 90 24 05 00  <-- repeating pattern starts here...
33AB9D: 90 24 05 00 90 24 05 00 90 24 05 00 90 24 05 00
33ABAD: 90 24 05 00 90 24 05 00 90 24 05 00 91 24 05 00  <-- ...except for one more bit in the last "91"

There is also the "9F 00 00 00" again.

Softwares 1.13 and 1.14 have the same structure.

The same thing is happening in the 1.09 software that did not have the scrambling and did not have the mystical "B4 AE 9A 89" in the beginning.
The last 64 Bytes of 1.09 look like this:
3233C5: 9F 00 00 00 46 4E 7D 13 0B 73 66 35 70 07 E4 93 <-- maybe checksums here?
3233D5: 84 BC F8 1B E9 F5 3C 2F D7 FF 04 00 D7 FF 04 00  <-- repeating pattern starts here...
3233E5: D7 FF 04 00 D7 FF 04 00 D7 FF 04 00 D7 FF 04 00
3233F5: D7 FF 04 00 D7 FF 04 00 D7 FF 04 00 DE FF 04 00  <-- ...except for two bits in the last "DE" (one on, one off)


Maybe the few bytes after "9F 00 00 00" and before the repeating pattern are finally checksums of different blocks. I didn't check on them.

I'm just thinking out loud here, to what I find.

So Notepad++ isn't what I'm looking for.   I'm looking for a better hex editor for Windows.  I'll check out hex edit.   HxD is free as well.   It was promising but I think it's dead now.   The checksum features are nice though.   It can calculate all the way up to SHA-512.  You can pick just one, or certain ones, or all of them, you can have it use custom checksums, you can have it run a checksum on the whole file or just the selection.

I also use all of those tools. They are really helpful. The HEX plugin for my version of NP++ has some issues when copy and pasting HEX code, though, so I don't rely on it.
I couldn't figure out how to copy a block of HEX bytes including their addresses. So far I do a lot of manual editing and trying not to get confused after that.

[Spork Schivago]

I noticed the repeating pattern at the end there as well.   I was trying to figure out the checksum and was trying to figure out what to run the checksum algorithms against (I couldn't figure out exactly where to stop).   I tried a few beginnings.   I tried without the first 4 bytes and without the first 128 bytes and without the first 256 bytes and 512 bytes, etc.

I'm either going to install Python or write the C program to rescramble the firmware and I'll try flashing on my machine.   I want to try a few things.   Because we can downgrade, I wanted to try removing those first four bytes and flashing an unscrambled, unedited file.   I wonder if the bits say something, like this is a compressed file, etc.   It could also maybe be the size of the file?

I really want to start flashing my unit but every time I sit down on the PC to start writing the program to rescramble the firmware, I get distracted.   Now my wife wants to watch a movie.   You and Macbeth know a lot more about microcontrollers than I do.   I don't know what a vector table is, for example.

Macbeth, you're certain the modified firmware didn't take?   For example, not trying to change a version number or anything, just maybe some HTML or something, going from a lower firmware to a modified higher firmware, checking the version number, and it's still the lower version, right?

[whatchitfoool]

Anyone have an update on the state of the project?

[Spork Schivago]

I believe the firmware files might have been successfully decoded.   We know at least some of them have been.   I think we might still be missing some of the decryption scheme but maybe not.   We haven't been able to actually update the device using a modified firmware image though.   We're thinking maybe there's some sort of checksum routine in the firmware file.

At this point, I think it's best to try and figure out the format of the firmware file, but that can take a bit of work.   Someone with experience with the processor used in these power supplies might be beneficial.

Our baby came Saturday, October 15th, at 7:40AM.   Chloe Lee Swarthout, weighing 8 lbs, 12.7 ounces, being 20 3/4" long.   She's healthy.   My wife had some complications during the pregnancy and was delivering from 11:45PM Friday until 7:40AM Saturday.   The midwife had to leave early on and came back around 5:30am and yelled at the nurse and kicked her out.   The baby was in the wrong position and she said she shouldn't had let Jess go that long pushing.   She should have known that baby wasn't coming out.   So, she had Jess lay down on her side and sleep for an hour and a half or so.   At 7:20AM, she brought a new nurse in and tried again.   20 minutes later, the baby was here!

Jess was coming in and out of during the delivery.  Her blood pressure was really low and I don't think she remembers most of it, so that's good.   But we just got home today from the hospital and are slowly adjusting to be new parents!   I probably won't be on for a bit to answer questions though.

[Macbeth]

I wish mother and baby well! You need a bracing glass of something or other too 

Don't be too hard on the nurses, everything is amplified in these situations, and lets not forget that only a few decades ago it was normal for a 1 in 10 chance complete loss of life of mother, baby, or both during childbirth. 

This is one reason I am glad for the NHS in the UK and utterly bewildered at the "green" Guardianistas who decide to "give birth naturally" with feckin' "doolahs" or whatever these mystics are called  Yeah that birthing pool of natural yoghurt is great until the complications happen!  :-D

[2N3055]

....   But we just got home today from the hospital and are slowly adjusting to be new parents!   I probably won't be on for a bit to answer questions though...

Wish your wife speedy recovery and for baby to be healthy and to bring joy to the family.. All the best and congrats!!

[Spork Schivago]

I wish mother and baby well! You need a bracing glass of something or other too 

Don't be too hard on the nurses, everything is amplified in these situations, and lets not forget that only a few decades ago it was normal for a 1 in 10 chance complete loss of life of mother, baby, or both during childbirth....

I've been looking at it as at least my wife and baby are okay and that it could have been much worse, you know?   Although Jess is hurting, she'll recover with time.   It could take up to a month but at least she's still here, you know?  And the baby is healthy as well.   That's great.

Also, the midwife left because of an emergency.   So if she had stayed, maybe someone wouldn't have made it?   I guess in the end, we're just thankful everything worked itself out.

[Dwaine]

Did anyone get any further ahead decoding the file structure?

[Pinkus]

Did anyone get any further ahead decoding the file structure?

Not as I know. As there is no license code for this, I assume this can only be done by either hacking and installing an existing firmware update package or by changing the files on the internal flash.
It does not look like this will happen in a near future.

[Spork Schivago]

Did anyone get any further ahead decoding the file structure?

There were people who claimed to have dump the firmware directly from the flash on this unit.   I've contacted all the people I could find who said they were able to dump it, to see if they'd provide me with a copy, but I never got a response.   I went out and bought a JTAG device, just to find out OpenOCD didn't support the flash with this CPU, so I wasn't able to dump it myself.   That was a while back.   Maybe now they do support the flash with this CPU?   The CPU, if I remember correctly, has some fancy security features.   I want to say there was something about making it really hard to read the flash, something with encryption, I dunno.

Anyway, if we could get a copy of the flash on the drive, maybe we'd have better luck decrypting the firmware .GEL files?   It almost seems like the decryption program that the one person wrote isn't quote right.   If you look through a "decrypted" .GEL file, you'll see stuff like ht~1p:// instead of http:// (that's just an example, I don't think it's ht~1p://, I just don't remember what they look like).   I was thinking maybe there's a little bit more to decrypting the files, but I could be wrong.   I just thought that was wrong.   That we should be seeing those strings as http.

I think there's some sort of checksum in the firmware that tells if the firmware's been modified or not.   I think that would be the next step, finding where the checksum is and figuring out how it's calculated.   It might be impossible, I dunno.   There could be multiple checksums.   There might be one for each section and then one for the entire file.   At the very end of the files for the different firmware versions, I found similar bytes.   I thought maybe that was some sort of checksum.

There's probably some table of contents, something that says where the files are located and how many bytes are in each file.  I couldn't really find anything in the .GEL file.   Perhaps this information is in another file?   I dunno.   There's gotta be a way to say this is the start of one file, this is the end of this file, either a special character or some sort of table.   That's something that'd need to be done.   Usually files on flash have filenames, right?   Or isn't that always the case?   I have limited experience with flash.   I've been looking at it more like a hard drive with some sort of filesystem.   Maybe it's not like that at all though?   If it is, there should be filenames somewheres as well.

[toxuin]

Looking at the unscrambled file with binwalk shows there are many LZMA-compressed chunks – could this be packaged firmwares for various chips on board? But sadly, extraction is not possible because of damaged archive.
I suspect it has something to do with the infamous ht~p:/ bug – as it damages strings it damages the compressed structures. Unscrambling has to have more to it.

I've took a look at gotroot's keygen and it has a dp832 private key – not sure if we need it or not, but might be useful. Apart from that there is a lot of wicked crypto stuff that must come (at least an idea how to do it) from a disassembled binary, no doubt.

[Spork Schivago]

My wife had a baby and I don't have a lot of free time anymore.   But this is great news.   We should look at how often that ~ appears.   If I remember correctly, it was x number of bytes into the file.   For example, everything 74th byte, there'd be a ~, which made me start thinking maybe the code to decrypt was 100% right, but maybe it wouldn't need much to fix at all.    ~ is ASCII 126 decimal or 7E hex.    t is 116 decimal or 74 hex.   It's only 10 digits off.

I wanted to write the decryption / encryption program in C but lost the free time.   I'll try to find it again and maybe we can try stepping through this one more time.

[smithnerd]

Looking at the unscrambled file with binwalk shows there are many LZMA-compressed chunks – could this be packaged firmwares for various chips on board? But sadly, extraction is not possible because of damaged archive.
I suspect it has something to do with the infamous ht~p:/ bug – as it damages strings it damages the compressed structures. Unscrambling has to have more to it.

I believe those extra bytes ('~' etc) are an artefact of the html files being encoded in a TFS filesystem, within the firmware executable. I've seen it before in the DS1054Z firmware.

Binwalk is a handy tool, but you often get false positives for LZMA because the header is so simple. You need to examine each one to check how plausible it is as LZMA stream data, and bear in mind that in the DS1054Z GEL files, they are using a non-standard LZMA implementation - what should be a 64-bit uncompressed size field is a pair of 32-bit values representing compressed/uncompressed sizes.

I had a quick scroll through a hexdump of the DP800 firmware, and I see some good long chunks of properly aligned ARM code. It looks correctly decoded to me.

[Spork Schivago]

Than that means we're back to trying to figure out what type of checksum routine / signature they're using.   I thought I remember seeing the same bytes at the end of two different versions of the encrypted firmware that I thought might have been some sort of signature or checksum routine.   That was long time ago though.

[ollihd]

Any updates on this?

[Spork Schivago]

I've compared the current (00.01.14.00.01) GEL file that was de-scrambled as before, with an older version (00.01.09.00.01). Here is what they look like:

DP800Update.GEL (00.01.09.00.01)                    DP800Update_descrambled.GEL (00.01.14.00.01)   
----------------------------------------------------------------------------------------------------
                                                 |                                      B4 AE 9A 89
00 40 CE 08 00 00 52 00 20 35 00 00 FF FF 00 00  |  00 40 81 40 00 00 52 00 A0 3D 00 00 FF FF 00 00
9F 00 00 00 20 35 00 00 18 F0 9F E5 18 F0 9F E5  |  9F 00 00 00 9C 3D 00 00 18 F0 9F E5 18 F0 9F E5
18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 00 00 00 00  |  18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 00 00 00 00
14 F0 9F E5 14 F0 9F E5 78 33 08 00 FC 34 08 00  |  14 F0 9F E5 14 F0 9F E5 F8 3A 08 00 7C 3C 08 00
FC 34 08 00 FC 34 08 00 FC 34 08 00 FC 34 08 00  |  7C 3C 08 00 7C 3C 08 00 7C 3C 08 00 7C 3C 08 00
40 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00  |  58 22 08 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 C0 9F E5 1C FF 2F E1  |  00 00 00 00 00 00 00 00 00 B5 06 48 00 68 40 07
E1 0E 08 00 00 C0 9F E5 1C FF 2F E1 C1 03 08 00  |  40 0F 00 06 00 0E 07 28 00 D3 00 20 00 06 00 0E
00 C0 9F E5 1C FF 2F E1 1D 0F 08 00 00 C0 9F E5  |  08 BC 18 47 20 0D FF FF 10 B5 04 00 20 78 A1 78

The (00.01.09.00.01) version is not scrambled and misses the first 4 Bytes: B4 AE 9A 89. From there on, the structure aligns pretty good. Only a few bytes are different, either addresses or length information...

I looked through the bitmaps I could find in (00.01.14.00.03) and made a collection of them here.
Furthermore I could find a lot of 1 bit per pixel character sets with all sorts of special characters. Amongst them are also the 7-segment numbers in different sizes for the main display. Haven't indexed those, though.

Still looking at it and not getting an idea what the overall structure could be. Any more ideas? Any disassemblers?

I wonder what would happen if you removed the B4 AE 9A 89 in the 00.01.14.00.03 file and did a byte-swap somewheres.   Maybe those 4 bytes are some sort of flags....

[Macbeth]

Does anyone have the previous DP800 firmware versions available? I would like to give a try at decoding something...

1.11, 1.13, 1.14 here (all seem to use bootloader 1.09) https://mega.nz/#F!6dll0ZCS!KwD7sHGZLU3D7Kr8u03ifA