In the previous post we looked at the task of attaching a debugger to a Windows machine.

The topic is reasonably interesting on its own because you can start to mess about in there, especially if you crack open the in-built help (not kidding, it is an exceptional help file) to start exploring.

So, the thing is, when we attach the debugger to the system we take control but the target appears frozen while we are broken in. Wouldn't it be cool if we could just let the system run as normal until it arrived at the spot we were interested in? Potentially we could just keep using the system as normal till it does that thing that has been irking you.

The next logical step then - is to explore the system using breakpoints!

For example, say we want to explore what happens when we create files in Windows...

Well, MSDN tells us one function that can be used to create files is ntCreateFile (or zwCreateFile). MSDN tells us this here:

Then - lets do a breakpoint for that function so we can just break in right when the system is doing that stuff...


1. Break into the system using the techniques in the previous post:

2. At the debugger type bp zwcreatefile

3. Now hit g to let the system run. The plan is, if the debugger notices that function being called we should break in at that point and we can dig around and learn about the function and how it works.

In this example, the function is called and the debugger breaks in.

We can have a dig around using commands like k to display the call stack or ub to "unnasemble backwards" (unassembled the current function backwards and display the instructions - in this example we have picked up the PfQuerySuperFetchInformation function and you can see if calling the NtCreateFile function). We will do some messing around with debugger commands in another post shortly.

That's about it, setting a breakpoint is fairly simple if you know the function you are interested in.

Oh! To remove the breakpoints type bd * to clear them all, or bd "{function}" to disable (bd == breakpoint disable) that one. You can also use bl to list the breakpoints that are currently set.