Can i set global breakpoint, using windbg, like softice (for example: bpx MessageBoxA) so it will break on all user mode running apps?
On Windows 95/98/ME, the main system libraries like kernel32 and user32 are shared by all processes. A normal usermode debugger cannot set breakpoints at all on these libraries on these systems.
On Windows NT based systems each process has its own copy and if you set a software breakpoint the modified page will not affect other processes.
If you want to debug a process and its children, you can do this with WinDbg. A script could probably set the breakpoint for each new process.
If you want to catch it in all processes for some insane reason you could maybe use a kernel debugger and a processor breakpoint ba?
If MessageBox is the actual thing you want to capture, you could probably use SetWinEventHook or a CBT hook instead of a debugger...
Related
I've always wanted to know the inner-workings of Visual Studio's debugger and debuggers in general. How does it communicate and control your code, especially when it's running inside a host process or an external network server (attach to process)? Does the compiler or linker patch your code with callbacks so that the debugger is given control? If it indeed works this way, how do interpreted languages such as JavaScript containing no debug code work?
Generally speaking, Windows provides an API for writing debuggers that let you examine and modify memory in another process and to get notifications when exceptions happen in another process.
The debug process sits in a loop, waiting for notification from events from the process under inspection. To set a breakpoint, the debugger process modifies the code in the debugee to cause an exception (typically, an int 3 instruction for x86).
The compiler and linker work together to make the symbol information about a program available in a format that can be read by debuggers. On Windows, that's typically CodeView in a separate PDB file.
In the Unix-derived world, there's an API called ptrace that does essentially the same sorts of things as Windows debugging API.
For remote debugging, a small program is placed on the remote machine that communicates with and acts on behalf of the actual debugger running on the local machine.
For interpreted languages, like JavaScript, the debugger works with the interpreter to give the same sorts of functionality (inspecting memory, setting breakpoints, etc.).
Windows includes support for debuggers. A process has to enable debugger privilege, and once this is done that process can attach to any other process and debug it using windows debugger functions
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679303(v=vs.85).aspx
For something like javascript, seems like you would need the equivalent of a javascript debugger.
In the case of a Visual Studio multi-process project, you typically have to switch which process the debugger is attached to in order to debug that process. I don't know if there's a way to have pending breakpoints set for multiple processes at the same time. There could be other debuggers that work better with multiple processes, but I haven't used such a tool.
I would like to set a memory breakpoints on access in windbg in the kernel mode debugger
I want the debugger breaks everytime a specific module in usermode is hit with the kernel debugger.
but I've read somewhere its impossible to set it, in order to make a memory breakpoints I have to write a plugin to make it
I tried to use SDbgExt plugin with the !vprotect command, but it fails to set memory bp
If I have to write a plugin to allow memory bp in kernel mode It has to be a driver?
I've read some chapters in windows internals book, but it doesn't help me at all.
I couldn't find too much info how to start deal with it
You can set breakpoints on user mode addresses from kernel mode. The only thing you should take care is to switch to the right process with ".process /i " command
If it is a one-off breakpoint -- that is, you are content with process being destroyed by debugging -- zero out the entire module using e command (edit memory). Set the whole thing to cc (which is int 3 as far as I remember)... zeros will do as well. You will break as soon as you touch any of the module's code.
Next step, remember where you were (relative to the module) and set a proper breakpoint.
Hope that helps.
(editing) Do you have full symbols? If you do, did you try bm module!*
Sounds like you want to set a "breakpoint on access" but instead of specifying an address you want to specify a range? I have never seen it done in windbg. The BA breakpoints uses HW debug registers instead of inserting INTs like SW breakpoints so this is definitely HW platform specific.
I have done this on an ARM chipset once using a HW debugger. ETM on ARM allows you to set triggers on address ranges.
I want to debug a specific process on a remote system and the only way i can do that is to use the kernel debugging method.
It works pretty good with just WINDBG, but i think ida can give me the extra edge i need for a better reversing experience.
So far debugging with windbg was successfull but now when i am using the windbg plugin in ida:
what i am actually experiencing is that i cant get the extra analysis from ida, all i can do is attach only to the process it self (only one available to attach to). and in the Modules window all i can see is the ntkrpamp.exe, which i assume is the kernel process.
i can use all WINDBG regular commands like !process 0 0, etc.. and can debug normally but nothing shows in the IDA window
I have never debugged dynamically using IDA but i can see it is possible..
could it work aswell in a kernel debugging session?
Edit:
I just noticed it is possible to analyze a model if i set a breakpoint with the windbg plugin and when IDA hits that breakpoint, this module is added to the IDA Modules windows.
It would be a lot easier if i could just analyze it without pre-putting a breakpoint on the specific module and waiting for it to hit.
I'm debugging a WDM Kernel driver IOCTL using Visual Studio Kernel Mode Debugger via pipe Serial connection to a Hyper-V VM running Windows Server 2012 R2.
Once I hit a breakpoint inside the Driver IOControl is it possible to view the user mode call stack?
At the moment I can only see the kernel stack, eg:
SIoctl!SioctlDeviceControl+0x14b [d:\workspace\ioctl\c++\sys\sioctl.c # 320] C/C++/ASM
nt!IovCallDriver+0x3cd C/C++/ASM
nt!IopXxxControlFile+0x8d2 C/C++/ASM
nt!NtDeviceIoControlFile+0x56 C/C++/ASM
nt!KiSystemServiceCopyEnd+0x13 C/C++/ASM
ntdll!NtDeviceIoControlFile+0xa C/C++/ASM
KERNELBASE!DeviceIoControl+0x73 C/C++/ASM
KERNEL32!DeviceIoControl+0x80 C/C++/ASM
0x9c402408 C/C++/ASM
> 0x0000005e`2f5af9c8 C/C++/ASM
Yes, you need to switch to the desired process first and then you have access to it's stack(s). See .process:
The .process command instructs the kernel debugger to use a specific user-mode process as the process context. This usage has several effects, but the most important is that the debugger has access to the virtual address space of this process. The debugger uses the page tables for this process to interpret all user-mode memory addresses, so you can read and write to this memory.
Note If you are performing live debugging, you should use the /i or the /p parameter. Without one of these parameters, you cannot correctly display user-mode or session memory.
The /i parameter activates the target process. When you use this option, you must execute the target once for this command to take effect. If you execute again, the process context is lost.
The /p parameter enables the forcedecodeuser setting. (You do not have to use /p if the forcedecodeuser option is already active.) The process context and the forcedecodeuser state remain only until the target executes again.
I am aware you asked about Visual Studio and I answered about WinDbg. I think you should use a tool appropriate for the job. WinDbg is infinitely more flexible and more powerful when it comes to debugging. I think in VS you would use the Process context, but I would recommend, again, use WinDbg.
I have tried that by using !process 0 0 app.exe and then doing .process /i pid or .process /P id as well, both fail to display the user stack.
I think it's because I'm already in that process, even thought it is inside the kernel driver, the running process is the application.exe. So when I either look in the call stack window or type in k I only see the kernel stack.
The "Visual studio way" of "switching" to different processes does not seem to work, the only thing I can do is walk around the different stack frames (within only the kernel stack - same as shown in the call stack window).
I'll try doing it in WinDbg see if it's any different.
EDIT:
I did something different now, after switching the context I did !threads and then .thread to the one thread that showed up and it is now working within a sleep call. Somehow in my IOCTL it does not work. But I tried it now using WinDbg and it works wonderfully!
Many Thanks!
I keep wondering how does a debugger work? Particulary the one that can be 'attached' to already running executable. I understand that compiler translates code to machine language, but then how does debugger 'know' what it is being attached to?
The details of how a debugger works will depend on what you are debugging, and what the OS is. For native debugging on Windows you can find some details on MSDN: Win32 Debugging API.
The user tells the debugger which process to attach to, either by name or by process ID. If it is a name then the debugger will look up the process ID, and initiate the debug session via a system call; under Windows this would be DebugActiveProcess.
Once attached, the debugger will enter an event loop much like for any UI, but instead of events coming from the windowing system, the OS will generate events based on what happens in the process being debugged – for example an exception occurring. See WaitForDebugEvent.
The debugger is able to read and write the target process' virtual memory, and even adjust its register values through APIs provided by the OS. See the list of debugging functions for Windows.
The debugger is able to use information from symbol files to translate from addresses to variable names and locations in the source code. The symbol file information is a separate set of APIs and isn't a core part of the OS as such. On Windows this is through the Debug Interface Access SDK.
If you are debugging a managed environment (.NET, Java, etc.) the process will typically look similar, but the details are different, as the virtual machine environment provides the debug API rather than the underlying OS.
As I understand it:
For software breakpoints on x86, the debugger replaces the first byte of the instruction with CC (int3). This is done with WriteProcessMemory on Windows. When the CPU gets to that instruction, and executes the int3, this causes the CPU to generate a debug exception. The OS receives this interrupt, realizes the process is being debugged, and notifies the debugger process that the breakpoint was hit.
After the breakpoint is hit and the process is stopped, the debugger looks in its list of breakpoints, and replaces the CC with the byte that was there originally. The debugger sets TF, the Trap Flag in EFLAGS (by modifying the CONTEXT), and continues the process. The Trap Flag causes the CPU to automatically generate a single-step exception (INT 1) on the next instruction.
When the process being debugged stops the next time, the debugger again replaces the first byte of the breakpoint instruction with CC, and the process continues.
I'm not sure if this is exactly how it's implemented by all debuggers, but I've written a Win32 program that manages to debug itself using this mechanism. Completely useless, but educational.
In Linux, debugging a process begins with the ptrace(2) system call. This article has a great tutorial on how to use ptrace to implement some simple debugging constructs.
If you're on a Windows OS, a great resource for this would be "Debugging Applications for Microsoft .NET and Microsoft Windows" by John Robbins:
http://www.amazon.com/dp/0735615365
(or even the older edition: "Debugging Applications")
The book has has a chapter on how a debugger works that includes code for a couple of simple (but working) debuggers.
Since I'm not familiar with details of Unix/Linux debugging, this stuff may not apply at all to other OS's. But I'd guess that as an introduction to a very complex subject the concepts - if not the details and APIs - should 'port' to most any OS.
I think there are two main questions to answer here:
1. How the debugger knows that an exception occurred?
When an exception occurs in a process that’s being debugged, the debugger gets notified by the OS before any user exception handlers defined in the target process are given a chance to respond to the exception. If the debugger chooses not to handle this (first-chance) exception notification, the exception dispatching sequence proceeds further and the target thread is then given a chance to handle the exception if it wants to do so. If the SEH exception is not handled by the target process, the debugger is then sent another debug event, called a second-chance notification, to inform it that an unhandled exception occurred in the target process. Source
2. How the debugger knows how to stop on a breakpoint?
The simplified answer is: When you put a break-point into the program, the debugger replaces your code at that point with a int3 instruction which is a software interrupt. As an effect the program is suspended and the debugger is called.
Another valuable source to understand debugging is Intel CPU manual (Intel® 64 and IA-32 Architectures
Software Developer’s Manual). In the volume 3A, chapter 16, it introduced the hardware support of debugging, such as special exceptions and hardware debugging registers. Following is from that chapter:
T (trap) flag, TSS — Generates a debug exception (#DB) when an attempt is
made to switch to a task with the T flag set in its TSS.
I am not sure whether Window or Linux use this flag or not, but it is very interesting to read that chapter.
Hope this helps someone.
My understanding is that when you compile an application or DLL file, whatever it compiles to contains symbols representing the functions and the variables.
When you have a debug build, these symbols are far more detailed than when it's a release build, thus allowing the debugger to give you more information. When you attach the debugger to a process, it looks at which functions are currently being accessed and resolves all the available debugging symbols from here (since it knows what the internals of the compiled file looks like, it can acertain what might be in the memory, with contents of ints, floats, strings, etc.). Like the first poster said, this information and how these symbols work greatly depends on the environment and the language.