Hacker Newsnew | past | comments | ask | show | jobs | submit | more Tiddles-the2nd's commentslogin

I'll also plug pwndbg[1] here. Like Gef it greatly extends the utility of GDB, and is oriented around exploit development.

[1] https://github.com/pwndbg/pwndbg


I'll make a shameless plug here as Pwndbg maintainer - apart from the FEATURES.md file describing features, you can see some of them detailed on those slides: https://docs.google.com/presentation/d/1mDfA_27DtLUkOaTZ8U9k...


Visually it looks very cool, but I agree it's not very helpful.

At the very least each result and RC should be in a different colour.


xchg %ax,%ax is the nop instruction. I would have expected to see <nop> written instead but the opcode (0x90) is shared by both.

It's also possible that xchg %ax,%ax is has been decoded from a multi-byte nop (to align memory) before the function call.


Writing nop for xchg %ax,%ax loses information. The xchg %ax,%ax is two bytes. If you write "nop", I'd assume that it's the one-byte version.

Typically, you use xchg %ax,%ax because you can replace it with a jump if you want.


Note that it uses ax (16 bits) instead of rax (64 bits). I'd assume it has opcode 0x66 0x90, a 2 byte nop.

Now if the author can provide some more details, we'll see if the call is aligned on some interesting boundary.

I always wonder how much aligning code helps in real code. They seem waste a lot of bytes in the code segment. Aligning data, yes, that changes a lot, but the return position of a call in code?


https://devblogs.microsoft.com/dotnet/loop-alignment-in-net-...

Is a good post in regards to code alignment effects.


That's an article worthy of its own HN post. Thanks


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: