1

I am currently learning ARM assembly by trying to reverse a broken printer. I retrieved the firmware from the on board NAND flash and I am now trying to make some sense of it.

However, I get stuck at the very beginning: the interrupt table. From documentation I read on the web, the interrupt table is a table that contains instructions (most often LDR PC instructions) that load a direct memory address into the PC. The interrupt table is a sequence of these instructions all directly next to each other (this might not be the most technical correct explanation, but that is how I understand it, please correct me if I am wrong). In the underneath table these instructions would be: e5 9f f0 18 which I believe is a ldr pc, [pc, #24] instruction.

In the firmware I retrieved, after every two vectors, there is a byte with value 89. I do not know why it is there and what it does. I couldn't find it anything on the web that shows something similar (or I am looking for the wrong thing). What would be the function of this byte?

From how I understand it, the address 0x8e0 will be loaded into PC and the CPU will run from there, however, this means ignoring the four 89 bytes. If the bytes should be taking into account, than the CPU would jump to 9f f0 18 89, but this is outside of the binary.

I believe the CPU is big endian and probably an Armv7, but it is an unknown Marvel chip, so I am not 100% sure.

This is the hexdump of the interrupt table:

00000000  e5 9f f0 18 e5 9f f0 18  89 e5 9f f0 18 e5 9f f0  |................|
00000010  18 89 e5 9f f0 18 e5 9f  f0 18 89 e5 9f f0 18 e5  |................|
00000020  9f f0 18 89 00 00 08 e0  00 00 00 04 ac 00 00 00  |................|
00000030  08 00 00 00 0c db 00 00  00 10 00 00 00 14 db 00  |................|

Why are the four 89 bytes there and is my assumption that the CPU will jump to 0x8e0 correct?

  • 1
    How exactly did you read the NAND Can you describe the procedure ? – w s Aug 9 '17 at 16:21
  • I desoldered the NAND from the PCB and used FlashcatUSB to read the flash. I chose default settings (not sure if that makes sense) and the endian mode was set to 'Big endian'. No special settings set. Could you be more specific for the information that you are looking for? Maybe the settings you are interested, I can look them up if needed. Thank you! – HermJan Aug 9 '17 at 16:27
  • Could it be some ECC, CRC or similar? Either by the chip itself (which chip is it? datasheets), HW reader or SW interfacing it. – domen Aug 10 '17 at 13:56
  • Unfortunately there is no datasheet available for this chip. It's a proprietary chip it seems. I checked CRC-8 but it computes to a different value for the first 4/8 bytes. I am reading up on ECC, but it seems too frequent for ECC. – HermJan Aug 10 '17 at 16:07
1

It seems there is some bug in your dumping procedure. The first 8 bytes disassemble correctly as LDR PC instructions, but then it goes all wrong. If you delete the stray 89 bytes then they line up correctly again.

  • Thank you for your answer. I tend to agree with you, however, the pattern is not observed anywhere else in the binary (perhaps other bytes but not 89) . I find it hard to conclude that it would be something with the dumping procedure from this result alone. What would possible debugging steps be to confirm it is a faulty dump? Thank you. – HermJan Aug 10 '17 at 11:50
  • if it has jtag, you could try dumping it that way and comparing. – Igor Skochinsky Aug 12 '17 at 7:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.