Comments on: Software Breakpoints

By: tc

tc — Fri, 08 Oct 2010 13:08:53 +0000

User level debugger requires permissions from the OS to be able to debug a child program (Windows debugging APIs / ptrace on Unix). Whenever an int 3 instruction is executed, the control is passed to the operating system’s interrupt vector. The OS then notifies the debugger that the child it was monitoring has hit a breakpoint. WaitForDebugEvent (Win) and waitpid (on Unix) calls are some ways how the OS notifies the debugger. The OS acts as the authority in order to grant debugging permissions and also routes the notifications back to the debugger.

By: Sumedh S

Sumedh S — Thu, 07 Oct 2010 22:21:51 +0000

I guess the above thing I mentioned wont work, because, cc would call some routine described by segment descriptor in IDT for int3.
Will it be possible to modify the segment selector and offset for int3 segment and point it to our code.

By: Sumedh

Sumedh — Thu, 07 Oct 2010 21:15:01 +0000

In case one is writing a debugger,
our option would be to replace the instruction at an addr ‘x’ with the opcode ’0xcc’.
At the same time we should be having a debug exception handler in place.
so with the above opcode should we be replacing a ‘call our_debug_handler’ instruction.
Our debug handler let says shows some values and then makes sure that the replaced instructions are brought back into the memory for resumed execution.
Am I right?

By: tsp

tsp — Tue, 20 Jul 2010 06:01:25 +0000

At the run time, we are attaching a process to the GDB and at time time we are setting a break point (in a specified file and a specfic line number), how the GDB know the exact opcode in the ELF file.is there any mapping application is there inside GDB

By: Debugging – Modifying Code At Runtime - technochakra.com

Debugging – Modifying Code At Runtime - technochakra.com — Sat, 09 Jan 2010 19:16:38 +0000

[...] The debugger’s access to a program’s memory and registers not only allows users to view the state of the program but also set software breakpoints. Software breakpoints are set by altering and restoring the instructions in memory and has already been covered indepth in an earlier article. [...]

By: tc

tc — Fri, 04 Sep 2009 18:59:24 +0000

@John, Nice approach. It also does not assume Intel as the underlying platform so will work for a lot of Unix variants.

By: John

John — Fri, 04 Sep 2009 09:56:56 +0000

For an alternative approach on a unix platform, assuming gdb, one can use raise(SIGTRAP). In fact, using a signal gives you a way to only stop execution if you are within gdb:

struct sigaction oldAct;
struct sigaction newAct;

newAct.sa_handler = SIG_IGN;
sigaction(SIGTRAP, &newAct, &oldAct);
raise(SIGTRAP);
sigaction(SIGTRAP, &oldAct, NULL);

Wrap that up in a function which takes a bool, and the process will send itself a signal that it will ignore. Crucially, gdb will *not* ignore it, and will take a break.

By: tc

tc — Tue, 18 Aug 2009 18:26:47 +0000

@Rohit,
I am assuming you are asking this for the Windows platform.
Inline assembly (__asm) is not allowed in Visual Studio’s x64 bit compilers. You can either create your own asm file with a function that invokes “int 3″ and call that function from your C/C++ code or simply invoke the ::DebugBreak() Windows API that internally invokes “int 3″.

By: Rohit Kulshreshtha

Rohit Kulshreshtha — Tue, 18 Aug 2009 14:55:03 +0000

Any clue on how one may achieve this on x86_64?