edb-debugger
edb-debugger copied to clipboard
eteran
Issue with pushfd, or am I doing something wrong?
When edb executes a pushfd, the trap flag is set in the value pushed on the stack. When a popfd is done, the trap flag gets set in the efl and edb stops at the (2nd) opcode. Trying to continue the run (F9) does not work, it behaves like step by step execution.
As I am very new to edb, and not very deep into asm programming, maybe I'm doing something wrong. But ollydbg on windows does not show this behavior, the trap flag is not set in the pushed value.
I have added a very simple program that shows the behavior on my installation. Important (possibly...) is that I'm running Ubuntu virtually. Both in VirtualBox and in WSL2 the behavior is the same. The 'and' instruction is resetting the bit on the stack. Skipping this instruction shows the issue with edb.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Well I guess OllyDbg takes special steps to fix up the pushed value after the fact. EDB doesn't AFAIR.
Interesting, yea, it would make sense to try to handle that a little more elegantly.
I've been thinking about this issue and there's two modes of operation that we need to care about (I think).
Stepping should be easy since we can just simulate the instruction and filter what ends up in the eflags as needed during that simulation. I've been wanting to implement unicorn-engine for generalized code simulation and more predictive analysis :-).
But outright running may require more complex instrumentation, to be "seamless", we'd need to somehow have the debugger informed that a popfd is about the effect the TF flag and act accordingly. Unless maybe we can notice the trap, look at the surrounding code and realize why it happened and fix it up? I wonder if other debuggers like gdb and x64dbg handle this.
My understanding is that the debugger is setting the TF in single step mode, which then gets pushed on the stack by pushfd and a later popfd creates the issue (independent of single step or run mode at that point). So if the debugger can filter out the TF that it sets in step mode when doing the pushfd, the stack value will not contain the TF so a later popfd will not create the issue. In your second case, are you considering that the TF would have been pushed/set on the stack by some explicit instruction in the application code, not by the step mode of the debugger? Would that not be really weird code to be generated by an application?
Ah, that makes sense, I think you are right. This may be slightly simpler to solve than I expected :-)