fail to transfer interrupt to qemu

[XMUsuny]

Hi, I run the script 'nucleo_state_transfer.py' in avatar2-examples, but using a different firmware which enables a button interrupt. I want avatar2 to monitor and automatically transfer to execution to qemu when a button interrupt comes. I have tried to set the breakpoint in the interrupt handler, and then transfering the execution to qemu. However, when I step the execution it crashs, when jumping out of the interrupt handler(pc goes 0xfffffff8). Then I find some instructions in armv7m_interrupt.py: 'extracting interrupt exits and putting them into the avatar queue'. However, I don't know how to use it. Could you give me some advice on how to achieve ideas above? Thanks!

[rawsample]

Hi @XMUsuny, As you are interested in interrupts, I invite you to take a look at Pretender, which is integrated in Avatar2 since v1.3. The script you mentioned belongs to it, moreover multiple other examples are present. https://github.com/ucsb-seclab/pretender

Otherwise maybe @mariusmue can give you more help :)

[mariusmue]

Hi! The crash is likely due to the case that during forwarding, the context is currently not preserved.

However, as @rawsample noted, we have rudimentary irq-forwarding since pretender. We designed the armv7m_interrupt plugin for this. Did you load it before you initialize your targets? (avatar.load_plugin('arm.armv7m_interrupts'))

Unfortunately, I cannot give any guarantees how well this is functioning right now, but at least for simple button interrupts, I could use it successfully in the past.

Let me know how it goes and feel free to shoot any questions!

Cheers.

[XMUsuny]

Hi @XMUsuny, As you are interested in interrupts, I invite you to take a look at Pretender, which is integrated in Avatar2 since v1.3. The script you mentioned belongs to it, moreover multiple other examples are present. https://github.com/ucsb-seclab/pretender

Otherwise maybe @mariusmue can give you more help :)

Thanks for you advice! Indeed I have roughly read the pretender's code and run the example code. It's time I should take a careful study about it now :)

[XMUsuny]

Hi! The crash is likely due to the case that during forwarding, the context is currently not preserved.

However, as @rawsample noted, we have rudimentary irq-forwarding since pretender. We designed the armv7m_interrupt plugin for this. Did you load it before you initialize your targets? (avatar.load_plugin('arm.armv7m_interrupts'))

Unfortunately, I cannot give any guarantees how well this is functioning right now, but at least for simple button interrupts, I could use it successfully in the past.

Let me know how it goes and feel free to shoot any questions!

Cheers.

Thanks! Yes, I have loaded the plugin 'arm.armv7m_interrupts', but it doesn't work. By the way, I use STM32F103RB instead, also based on cortex-M3. I thought it doesn't make influence. Today I check the code where qemu went crash. It is a 'pop {R3,PC}' instruction at 0x800244e. Then I use openocd directly read the sp value and data on stack:

step target halted due to single-step, current mode: Handler External Interrupt(40) xPSR: 0x01000038 pc: 0x0800244e msp: 0x20004f90 halted: PC: 0x0800244e mdw 0x20004f90 10 0x20004f90: 08002439 fffffff9 000f4240 20000e3c 00000000 00000000 7738e8cd 08002929 0x20004fb0: 08002c82 4100f000

As above, there is a 'pop {R3,PC}' instruction at 0x800244e. However, when I step the process, it doesn't work properly:

step target halted due to single-step, current mode: Thread xPSR: 0x4100f000 pc: 0x08002c82 msp: 0x20004fb8 halted: PC: 0x08002c82

I think qemu works well as r3 goes 0x8002439 and pc goes 0xfffffff9, it crashes. I don't understand the fact that sp increase 0x28 and pc goes 0x8002c82, maybe it is related to ARM mode?

Maybe I should study pretender's code directly to achieve my original ideas, but the problem above is quite confused :)

[mariusmue]

If the F103RB is based on an M3, there shouldn't be too much differences. In this setup, are you still doing the state-transfer during the ISR routine? This is likely to not work. Could you try to just load the plugin, call avatar.enable_forwarding()after initializing you targets, and register watchmen for RemoteInterruptEnter and RemoteInterruptExit?

This could potentially give us insights on where the setup is failing.