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.