2

I am trying to disassemble a code from a old radio containing a 68xx (68hc12 like) microcontroller. The problem is, I dont have the access to the interrupt vector of the micro in the top of the ROM, so I don't know where start to look. I only have the code below the top. There is some suggestion of where or how can I find meaningful routines in the code data?

Hernandi F. Krammes F.
  • 25
  • 7
  • How come you don't have the vector area? You cannot read the code from the MCU and you have an incomplete S19? Some HC11 may have internal EEPROM overlaid the vectors. In that case, have you looked there? – tonypdmtr Jun 02 '17 at 16:33
  • It uses internal EEPROM. It does not have external ROM of any kind. There are online available ROM upgrades for this device, that is where I got the firmware for evaluation. I chose not try to access the firmware via direct connection. – Hernandi F. Krammes F. Jun 03 '17 at 17:28
  • Do you know which part number exactly? – tonypdmtr Jun 03 '17 at 17:30
  • Its a CA6812. I don't know the manufacture, but it is 68hc clone. JVC, Philis, Panasonic, all relay on a chinese manufactor – Hernandi F. Krammes F. Jun 05 '17 at 17:30
  • Unfortunately, that doesn't help me. I asked because some parts (e.g. HC811E2) have user-mapped EEPROM that can be mapped over the vectors. In that case, it is possible for the vectors to be inside the EEPROM. When reading the MCU memory, however, from bootstrap mode, the EEPROM may be mapped in its default address range (usally $0xxx) producing 'garbage' for the vectors. In that case, you would need to temporarily map the EEPROM (via CONFIG register) to the run-time location (presumably last page -- overlapping the vectors) or read the actual EEPROM interpolating vectors & contents. – tonypdmtr Jun 07 '17 at 12:49
  • 1
    I used a python script to detect the architecture of the binary, and turn out it was a 8051. After disassembling it became a clear and nice code. So CA6812 is a 8051 variant. – Hernandi F. Krammes F. May 12 '20 at 15:25
  • It took you almost three years but good you got it working :) – tonypdmtr May 12 '20 at 16:01
  • I used cpu_rec together binwalk. Worked well. I also was able to detect another firmware architectures, like Reneseas v850! https://github.com/airbus-seclab/cpu_rec – Hernandi F. Krammes F. May 13 '20 at 15:17

1 Answers1

1

You can't really disassemble reliably without knowing where the reset vector points. What you can do, however, is try to narrow down the possible reset addresses by eliminating all those other addresses that cannot possibly be a starting point.

So, given that any address in the memory map that contains a valid opcode is a potential reset point, you need to either eliminate it, or keep it for further analysis.

For the 68HC11 case, you could try to guess somewhat the entry point by looking for LDS instructions with legitimate operand value (i.e., pointing at or near the top of available RAM -- if multiple RAM banks, then to any of them).

It may help a bit if you know the device's full memory map, i.e., if external memory is used, its mapping and possible mapped peripherals (e.g., LCD). Do you also know CONFIG register contents?

The LDS instruction is usually either the very first instruction, or close thereafter (so look back a few instructions when you feel you have finally singled out your reset address). The problem here is some data may, by chance, appear as LDS instructions so you could end up with multiple potentially valid entry points. Only one of them is valid, of course.

You can eliminate further by disassembling a few instructions starting from each of these LDS instructions until you either hit an illegal opcode (i.e. obviously not a valid code sequence but an accidental data arrangement that looks like opcodes), or you see a series of instructions that are commonly used in 68HC11 initialization. These involve (usually) initialization of any one or more of the registers BPROT, OPTION, SCI, INIT ($103D in most parts, but for some $3D), etc.

You could write a relatively small script (e.g., in Lua) to do the basic scanning of the memory map and produce a (hopefully small) set of potential reset points to be examined further with a true disassembler for hints like the ones I mentioned.

Now, once you have the reset vector figured out the job becomes somewhat easier but you still need to figure out where any interrupt handlers are located. For this your hint is an RTI instruction and whatever preceding code that normally should acknowledge the specific interrupt it handles.

Hope this helps.

tonypdmtr
  • 3,037
  • 2
  • 17
  • 29