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.