Now, we should set up a debugger to intercept the moment the driver code gets executed so that we can get control over it immediately once it starts. In most cases, we don't have symbol information for the analyzed sample, so we can't use common WinDbg commands such as bp <driver_name>!DriverEntry to stop at the driver's entry point. There are several other ways this can be done, as follows:
-
By setting unresolved breakpoints: The following command can be used to set a breakpoint that will trigger once the module is loaded:
bu <driver_name>!<any_string>
- Even though the debugger doesn't stop at the entry point in this case, it is possible to reach it manually. In order to do this, take the base of the driver from the console output window, add the entry point's offset to it, and then set a breakpoint. Then, remove or disable the previous breakpoint and continue execution.
- By breaking on the module...
