-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Showing disasm code lines before the current line? #419
Comments
Not linearly. When stepping through, Pwndbg will remember the "previous" instruction for every given instruction, and display those. Reverse-disassembling from an arbitrary point is difficult because:
This is probably something we could add, to make a best-effort (and it's actually something we did a long, long time ago) but it's not something we currently support. |
I just came here to clarify that i see that this only does that for certain situations So i have 3 questions- |
Landing on a breakpoint, Pwndbg has no idea what was executed before the instruction it landed on (unless it's landed there before, via single-stepping). No, this is not equivalent to single-stepping. Reverse-disassembling is not any easier with symbols, unfortunately. Symbol information does not encode instruction boundaries. If you can find the code of how vanilla GDB handles this, I'd love to see / re-implement it in Python for Pwndbg. Either way, this is a feature I'd accept if you create a pull-request that does a best-effort reverse-disassembly and prints it IFF we don't have better information about what came before. The algorithm that PEDA (and old versions of Pwndbg) used is to disassemble backwards further than we need, in hopes that the instruction alignment happens to sort itself out. |
@zachriggle If you're still interested how vanilla gdb does this, here it is: Essentially, gdb looks for the first symbol before the pc that when disassembled from that point on, the entire tui would be filled. If you don't have symbols, gdb cannot disassemble before $pc because it can't identify their start point. In terms of pwndbg, we probably only care about disassembling from the start of the current function forward. The main issue with doing something like this is that there's no way to tell if we arrived at a certain instruction via a jump or just linearly running the code. In the case of a jump, it might be misleading if nearpc showed instructions that are just linearly before $pc in memory. The other issue is if code is intentionally obfuscated, the function might not be possible to linearly disassemble correctly (e.g. jumps to misaligned instructions). In that case it's probably stripped anyways though? We also might be able to do some sanity checks like making sure all jumps are to aligned instructions. Any thoughts if this is worth implementing or not? |
For RISC architectures like ARM, we should at least be able to add an argument to |
First of all i need to say that this made my gdb interaction much MUCH more pleasant and you have my infinite thanks.
Now, went over the
config
and issues and couldn't find how to start thenearpc
(disasm) view to start before the current code lineMany time you get to a breakpoint and you really want to know what happened in the immediate past
Is this possible or is this a feature request?
The text was updated successfully, but these errors were encountered: