31–40 of 62 posts
Earlier quoted context omitted.
Yes, and introducing bugs is not the only issue at stake. Imagine malware that could react differently when a debugger is attached.
Malware already does this. Non-malware programs already do this to complicate analysis.
Earlier quoted context omitted.
Malware already does this. Non-malware programs already do this to complicate analysis.
If those non-malware programs are fixed to use a proper API instead of side channel hacks, then it simplifies analysis.
I think you’re missing the point as to why programs would do this. Usually it’s to protect some sort of DRM scheme through obscurity.
I'd really like a way for a program to have an API for interacting with GDB: with that it could tell "I'm running under a debugger". There would be a file descriptor which talks to the debugger, if the debugger is present. Output sent to it goes to the debugger and perhaps it could obtain input from the debugger also. Maybe the API could provide some introspection: the program could ask what breakpoints have been set…
Earlier quoted context omitted.
this is not particularly hard to do with the Python interface: you define structures that are known by the process and the Python module + global variables, then you set an internal (silent) breakpoint on a given 'event' function. In the program you fill the structure with some queries, and in the Python breakpoint callback, you process it as you need. This is the way multi-thread debugging work (used to at least), s…
Okay, good ideas there: so the program has some standard dispatch function that can be called to talk to the debugger. Normally that does nothing. The debugger can recognize this function and stick a breakpoint in it to alter the behavior. The function can do something like put a request into a mailbox buffer, and then check for a reply in the inbox buffer. When there is no debugger, there is never any reply. When th…
please, GDB internals are open source, you can do all of that in plain C :D That's what I did initially, to give GDB the ability to distinguish user-level threads (see libthread_db).
Having a high-level language / interface to GDB is a great again of time !
Earlier quoted context omitted.
MD5 is fine for verifying a download is not corrupted, so that's probably the intended use.
For that purpose, TCP already includes a CRC32. I'd say cryptographic hashes are generally meant for more than corrupted downloads.
> New shortcuts for TUI Single-Key mode: 'i' for stepi, and 'o' for nexti; TUI really is one of the best features to really get into gdb. visually stepping through the disassembly really makes debugging more appealing, I really wish they dont abandon this aspect of gdb
https://www.youtube.com/watch?v=PorfLSr3DDI
It really did change my opinion of gdb in just 15 min.
Earlier quoted context omitted.
Well, to be fair malware already exists that can detect when a system debugger is attached so maybe my concern is invalid. I guess the greater concern is the introduction of bugs after all. Edit - Other commenters beet me to this point :-P
The program is what it is and it has bugs. There is a risk that bugs are irreproducible under a debugger (no matter how transparent the debugger). Oh well; you have to debug those in some other way. That risk shouldn't paralyze us from innovating debuggers. There are bugs that won't reproduce when you debug via JTAG; so what. Simply pausing on a breakpoint can make a bug irreproducible. Programs can infer that they a…
starti, rbreak and ptype sound good even if they've been available as idioms before.
ptype already existed, but did not print out offsets. This is incredibly useful, and something Windbg does with dt. Pwndbg does this in GDB by adding new commands.