So now I had a plan - I knew of an address in the encrypted ROM which would be decrypted to a given value in RAM, which was accessible. I whipped up a python script which prepared 16 different firmwares, each exposing 16 encrypted values in a set range, and proceeded to move through the process of flashing the firmware on, starting st-util, and then, in gdb, using:
target remote localhost:4242
dump binary memory ~/documents/lerdge/ram/ramtest<x>.bin 0x20000000
disconnect
to dump out the table. A python script then pulled the decrypted values from the RAM files and output them as a table.
Wonderful, except that many, many of the output bytes didn't match values I knew. For instance:
# Byte Range 0x0-0xf
0xaa: 0x0,
0xae: 0x1,
0xb2: 0x2,
0xb6: 0x3,
0xba: 0x4,
0xbe: 0x5,
0xa2: 0x6,
0xa6: 0x7,
0xca: 0x8,
0xce: 0x9,
0xd2: 0xa,
0xd6: 0xb,
0xda: 0xc,
0xde: 0xd,
0xc2: 0xe,
0xc6: 0xf,
We know the value of 0x08 - encrypted, it must be oxDF, because that's the lead byte in the interrupt table. It's certainly possible there's byte swapping going on, but I proceeded to do a series of tests and discovered some interesting behavior. After verfying that my script had written the correct bytes into place, I saw my results didn't fit the known value of 0x65 being the encrypted version of 0x20 (lead byte of the stack pointer)
# Byte Range 0x20-0x2f 0x2b: 0x20,
This lead me to do a few more tests, and discovered that while many bytes changed values, 0x5D always mapped to 0x00. So I inserted known values from my manual mapping, and low and behold, when mixed with 5D, I get the correct value, EXCEPT for the leading 00, which does not have two 5Ds in front of it:
5D5D5555 5D 00 00 5D 5D 65 65 5D 5D 5F 5F 5D 0000FFFF 00 AA AA 00 00 20 20 00 00 08 08 00 5D5D 00 5D 02 5D 03 5D 04 5D 05 5D 06 5D 07 5D 0000 AA 00 B2 00 B6 00 BA 00 BE 00 A2 00 A6 00
0x5D seems to change how bytes afterwards are interpreted, particularly a double 5D. So next I need to determine if there are sets of bytes which change interpretation, if a single byte can, and so on.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.