Showing disasm code lines before the current line?

[OranShuster]

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 the nearpc (disasm) view to start before the current code line Many 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?

[zachriggle]

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:

• Those instructions may not have been executed (e.g. we jumped to $pc)
• Variable-width architectures (e.g. Intel) may result in us showing the wrong instructions

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.

[OranShuster]

I just came here to clarify that i see that this only does that for certain situations

So i have 3 questions- 1.Assuming we set a breakpoint and continued to it, this is not equivalent to "fast stepping" through them? 2. Reverse-disassembling should be simpler if debug symbols are available? 3. the only reason i asked for this is that "vanilla" gdb does this. for instance, in its "graphical mode" you can see the lines above you (noted as -B if i recall correctly) even when stopping on a breakpoint after a continuous run

[zachriggle]

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.

[stnevans]

@zachriggle If you're still interested how vanilla gdb does this, here it is: https://github.com/bminor/binutils-gdb/blob/502c64b9ac12cf2a35d3cb55c51e2eefd33a2494/gdb/tui/tui-disasm.c#L116-L128

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? @disconnect3d

[gsingh93]

For RISC architectures like ARM, we should at least be able to add an argument to nearpc to show the instructions before the current PC, even if they're not the actually executed instructions, and we could clarify this distinction in the help text.