<link hEref
<link href
. Maybe that E in there has something to do with the flash, like where that bit of code gets written to...or maybe there's a little more to descrambling this file, or maybe it's compressed some how. What do you guys think?These inconsistencies in plain xml '<hEref' appear in regular intervals, i.e. like every 128 bytes (find '~' mostly) inside a logical block, that's why I think it's part of a bigger package. I'm not really experienced in this.
Other things I observed are a lot of bitmaps in RGB565. If you see the descrambled file as a bitstream, run it through a raw pixel viewer and adjust the width correctly, you see a lot of bitmaps. The first one looks like a clock face, then comes more unidentified data and then a whole collection of more bitmaps. For example, I also found the 'middle balls' of the normal view in DP8xxA models.
Other bitmaps are the LXI logo, RIGOL logo, all in diverse colours. Haven't got any at hand to attach atm.
But these bitmaps do not have a header of some sort. They are just next to each other.
However, I didn't find a section with indexes and size information of the single bitmaps, yet. So, these might be part of a bigger package again.
So I keep on searching for some kind of index table.
I couldn't make any sense of the first 256 or so bytes in the file, yet.
I cannot seem to find any termination strings that might separate one file from another. I think an index has to be used. Something with offset, filelength and filename and probably some sort of checksum. Also, somewheres, I almost remember finding the ends of the various Rigol DP832 firmwares had something special about them, like it was all the same values, the last 500 and some bytes or something. I thought I posted about that somewhere here, in this thread. Maybe there's a footer.
44 50 38 33 31 41 00 00 44 50 38 33 32 41 00 00 | DP831A..DP832A..
44 50 38 32 31 41 00 00 44 50 38 31 31 41 00 00 | DP821A..DP811A..
44 50 38 31 32 41 00 00 44 50 38 31 33 41 00 00 | DP812A..DP813A..
44 50 38 34 31 41 00 00 44 50 38 33 31 00 00 00 | DP841A..DP831...
44 50 38 33 32 00 00 00 44 50 38 32 31 00 00 00 | DP832...DP821...
44 50 38 31 31 00 00 00 44 50 38 31 32 00 00 00 | DP811...DP812...
44 50 38 31 33 00 00 00 44 50 38 34 31 00 00 00 | DP813...DP841...
Could this be a lookup table for model numbers that are pre-programmed in the devices flash area along with serial number and calibration, etc?
Would it by as simple as changing byte 0x2F1771 from 00 to 41 'A' and perhaps byte 0x2F1739 from 41 to 00 for consistency but also just in case a simple checksum is used?
Nah, that seems to easy
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?
Ok, I didn't rescramble the file but modified my original 1.14 using the same '74 offset' formula.
So I changed
2F1379 from EE to AD
2F1771 from E5 to 5C
Reflashed using USB and the help button at the '...' elipses, it didn't spit back any errors and appeared to accept the file, flashed ok and asked me to power off and on.
Unfortunately it hasn't made the blindest difference (at least that I have found so far. Perhaps a SCPI command or the webserver will report back the wrong model?)
Ok, I chose to change the installed options text at 277BC0 from ":Official" to ":Hacked!" so the encoded bytes are
5E 6D 87 8A 93 8E B8 4C 2C
Reflashed and unfortunately the options still showed as ":Official" so perhaps it is ignoring the upgrade? I then tried the "Update analog board 1 & 2" step just in case but no luck.
So I downgraded using official 1.13 - that installed and reported version correctly.
I then re-installed my hacked 1.14 which gave all indication of installing ok, but the Sys Info still showed 1.13 and of course my hack did not work.
I then installed proper 1.14 which installed ok, and now Sys Info does show 1.14.
So I give up. That's it for tonight!
Just so I'm understanding you correctly, you had a hacked 1.14, you installed it, it seemed to install correctly. But the hack didn't go through, so you installed an unhacked 1.13, checked the version, it showed 1.13. Then you went and installed your hacked 1.14 again, checked the version, and it still showed 1.13, is that correct?
It seems there is in fact a checksum somewheres...Are there any logs that get stored anywhere on the device when a firmware update is performed? Also, when you install the hacked firmware, are you re-encoding them or does the power supply seem to accept the decrypted / unscrambled versions? Thanks for trying!
So I then chose to do something more blatant as in change some obvious text but without any attempt at covering for a simple checksum. I did not unscramble/decrypt the whole file, just changed the bytes using the 74 offset algo and HexEdit. No joy with that but no error messages stating anything wrong with the update. Indeed it appeared to go just fine!
Regarding limited chances at upgrading firmwares, it looks like downgrades and upgrades work just fine. I think it is only the bootloader that you can't downgrade but that is for firmwares with a bootloader <1.09 IIRC and the firmware we are playing with (so far) is not the bootloader.
Just so I'm understanding you correctly, you had a hacked 1.14, you installed it, it seemed to install correctly. But the hack didn't go through, so you installed an unhacked 1.13, checked the version, it showed 1.13. Then you went and installed your hacked 1.14 again, checked the version, and it still showed 1.13, is that correct?
Yep!QuoteIt seems there is in fact a checksum somewheres...Are there any logs that get stored anywhere on the device when a firmware update is performed? Also, when you install the hacked firmware, are you re-encoding them or does the power supply seem to accept the decrypted / unscrambled versions? Thanks for trying!...I did choose to swap the bytes instead of just changing 1 byte because I guessed there may be a checksum and simple checksum algo's will still work if bytes are just swapped....
So I then chose to do something more blatant as in change some obvious text but without any attempt at covering for a simple checksum. I did not unscramble/decrypt the whole file, just changed the bytes using the 74 offset algo and HexEdit. No joy with that but no error messages stating anything wrong with the update. Indeed it appeared to go just fine!
Regarding limited chances at upgrading firmwares, it looks like downgrades and upgrades work just fine. I think it is only the bootloader that you can't downgrade but that is for firmwares with a bootloader <1.09 IIRC and the firmware we are playing with (so far) is not the bootloader.At least that's good news that you can flash over and over again, as it seems.
Might be worth trying changes in all the different parts of the software now: changing bitmaps, changing HTML code, etc. See which changes are accepted until it breaks.
Maybe an interesting find and a pointer into the right direction (pun intended):
In the header of (00.01.14.00.03) we find:
000000: B4 AE 9A 89 00 40 81 40 00 00 52 00 A0 3D 00 00
000010: FF FF 00 00 9F 00 00 00 9C 3D 00 00 18 F0 9F E5
000020: 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5
000030: 00 00 00 00 14 F0 9F E5 14 F0 9F E5 F8 3A 08 00
000040: 7C 3C 08 00 7C 3C 08 00 7C 3C 08 00 7C 3C 08 00
000050: 7C 3C 08 00 58 22 08 00 00 00 00 00 00 00 00 00
000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The addresses 0x00A03D and 0x009C3D and surrounding looks like this:
003D80: 52 55 D5 00 00 00 00 00 00 00 00 00 00 00 00 00
003D90: 77 77 F7 00 FA FA FA 00 FA FA FA 00 00 00 00 00 <-- This is address 0x3D9C from the header
003DA0: A5 00 00 00 00 00 55 55 55 55 00 00 64 00 00 00 <-- This address is 0x3DA0 from the header
003DB0: 01 00 01 00 01 00 00 00 00 40 AB 61 00 00 00 00
003DC0: A1 6D 33 00 FF FF 00 00 9F 00 00 00 52 49 47 4F <-- RIGO
003DD0: 4C 4C 00 00 00 00 00 00 00 00 00 00 18 F0 9F E5 <-- L
003DE0: 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5
003DF0: FF FF FF FF 18 F0 9F E5 18 F0 9F E5 DC E8 26 40
003E00: 38 1D 06 40 70 1D 06 40 A8 1D 06 40 E0 1D 06 40
003E10: FF FF FF FF 50 1E 06 40 90 1E 06 40 01 01 00 00
003E20: 40 00 00 00 00 33 6D 40 00 00 00 00 F0 41 2D E9
003E30: 00 60 B0 E1 00 70 A0 E3 9C 0E 9F E5 D7 80 D0 E1
003E40: 08 00 B0 E1 00 0C A0 E1 40 0C B0 E1 80 12 80 E0
003E50: 88 0E 9F E5 01 02 90 E0 00 10 A0 E3 0C 12 C0 E5
003E60: 06 00 B0 E1 00 08 A0 E1 20 08 B0 E1 02 10 A0 E3
003E70: 4C 1D 81 E3 01 00 50 E1 10 00 00 0A 12 10 A0 E3
Notice the "RIGOL" string at 0x003DCC and the recurring 18F09FE5 pattern from the header.
A similar thing seems to happen in 1.09 GEL file and 1.13 GEL files.
Maybe worth looking into this one, as this might be an address reference.
Bytes 55 55 55 55 are some sort of a marker. It does not look like a valid armv5 instruction. However the uint32 that end with some sort of Ex (E0, E1, E3, E5, E9) might be some code bits.
I guess I have to figure out how http://www.hexedit.com/ can be used effectively now.
a slight change of subject - only slight.
maybe you should try to find out how the code determines the model.
does it identify the model when you change the firmware, and flash the apropriate files,
or does it install everything and then determine which files to use every time it's powered up?
does it have an eeprom?
00 00 21 21 54 D0 20 40 <-- starts at offset 315h
00 01 21 21 54 FF 20 A2
30 01 21 21 54 D1 20 40
00 01 21 21 54 FF 20 A4
//window.alert("oh yeah!\nö ~SOng is a pig!");