How does Fuzzware identify the interrupts in the fuzzed firmware before modeling them?

[B03901108]

Hi, I am looking into the way Fuzzware identifies the interrupts supported by the tested firmware. I cannot find explicit interrupt vector tables in the sections and the beginning of some benchmark firmware. I wonder what Fuzzware does in this case (for example, uEmu/utasker_MODBUS). Thank you.

[Scepticz]

That is via the VTOR, see here: https://developer.arm.com/documentation/ddi0439/b/System-Control/Register-summary

[B03901108]

@Scepticz Great thanks for sharing the VTOR information. It works.

I want to make sure that I did not get it wrong. I read the interrupt vector table (IVT) starting from the address indicated by nvic.vtor. I read it 4 bytes by 4 bytes for at most NVIC_NUM_SUPPORTED_INTERRUPTS (i.e., 256) times. After a certain moment, the retrieved 4-byte addresses were obviously not function addresses or 0. Should I decide on the end of the IVT by detecting this moment? Is there a smarter/more formal way to decide on the IVT's end (or size)? Thank you so much.

[Scepticz]

The exact number is platform specific in general, so you will not statically know if you don't know the exact hardware. However, the firmware has to enable the interrupts explicitly via the NVIC. From this configuration you can derive which interrupts the firmware is using. The vector table entries can also change whenever the firmware writes different pointers into the NVIC, when the firmware changes the VTOR itself, or when different vectors are enabled/disabled during runtime.

[B03901108]

I ended up identifying the supported interrupts dynamically during the emulated executions. It seems to be much more reliable than static methods. Thank you for all the help.