I just found out how to break into the SetTimer function inside a windows dll (user32.dll).
link text
However i need to know what arguments its called with. I think that the arguments are pushed onto the data stack right before calling the function, but I have found no way to display a threads data stack in visual studio 2010.
Open a Memory debug window, and load the address at ESP (which you can get from the Registers Window). ESP points to the top of the stack. If you scroll up the window a bit, you'll see what's been recently pushed onto the stack. Make sure you set the memory window to display one column of 4byte integers (unless you're a 64 bit app, then use 8bytes).
If you open up the call stack window (Debug -> Windows -> Call Stack) you should be able to double-click on the functions up the call stack, view the parameters, local variables and so on.
Related
I'm working on extending the old WinAPI program (I don't have source code - only EXE) with the possibility to write debug messages on standard output. That program already uses kernel32.dll library and in the .rdata section I see a lot of references to different functions in 3th part DLLs. In order to do that I need WriteConsole function which lives in kernel32.dll. I used the simplest strategy and just copied the memory address of WriteConsole in kernel32.dll in time of debugger breakpoint. After restart of program, I was disappointed that the address doesn't point anymore into kernel32.dll WriteConsole. Instead, it pointed into another random DLL.
I wonder what is recommended and easiest option to setup properly address to that external function?
I sow that x32dgb have a section with symbols - can I use some x32dbg feature to add other functions pointers from existing DLLs?
Thank you :-)
I'll show how to add WriteConsoleA entry to IAT. This is the ANSI version of WriteConsole, when you need to output UNICODE strings, use WriteConsoleW. From your screenshot I see that currently your binary uses ANSI versions of kernel32.dll functions, for example GetStartupInfoA.
Download PETools. Run it, select Tools->Pe Editor and select your binary. A dialog box appears. Click Directories button, a new dialog box appears. Click ... button for import directory. Import directory window opens. Right click on a dll in the upper list, select Add Imports....
Enter KERNEL32.dll as dll name, WriteConsoleA in the API name edit, click + button. Click OK. Close all the windows and save changes by
clicking close, save and OK buttons. Your binary will have a new entry in IAT for WriteConsoleA function.
When I am debugging in Microsoft Visual Studio 2017 my "Registers" window shows no data available. What can I do to fix this?
As Sneftel stated, you cannot inspect data in the debugger unless you break the execution of the process. During execution, things would be changing far too quickly for any data display to be meaningful.
You can use the "Pause" button in the toolbar to break execution, and then you will see everything in the debugger: the current source line, the contents of registers, your "watch" variables, the full contents of memory in the "Memory" window, etc.
You can also set a breakpoint on a particular line of code, and then execution will break once that point is reached.
Once paused, you can then single-step through your program's code. This means that one line of code (the very next one) will be executed, and then the program will break again so that you can see everything in the debugger. This is an excellent troubleshooting technique—one that you should be well-acquainted with. In fact, I recommend that you single-step through every line of code that you write, just to make sure that it works correctly. You can also modify the contents of registers and variables (or, really, any location in memory) while you are single-stepping, giving yourself a way to test potential bug fixes or even introduce bugs (e.g., invalid input) to see how your code handles them. The default keyboard shortcut for single-step is F11.
You'll find more information about using the debugger, and the available keyboard shortcuts, here on MSDN. As you can see, that article confirms my answer:
Most debugger features, such as viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only while the debugger is paused (also called break mode). When the debugger is paused, your app state is suspended while functions, variables, and objects remain in memory. While in break mode, you can examine the elements' positions and states to look for violations or bugs.
(Edit-and-continue is not available in assembly projects. You will need to stop execution and rebuild if you want to make changes to your code.)
For those with the "No data available" message, you can right click in the Registers window and choose what you want to see (UC, MMX, SSE, etc). It seems like by default there's nothing selected in Visual Studio 2019. At least, on mine there was nothing selected.
I tried looking on MSDN, Google and Stack Overflow and I couldn't find an answer to what I'm looking for.
Is there a way to edit, through the Memory Window, the code at a given address? I use the Disassembly Window to get the address of the instruction I would like to overwrite, find it in the Memory Window but "Edit Value" is grayed out. Any reason why? Is it because my code gets cached and VS prevents me to edit it? Is there a way to change that through project settings?
Thank you
The application is consisted of data parts and executable parts of code. Windows forbids the changes to executable parts by default, but this can be changed from the code with VirtualProtect function (also pay attention to remarks and FlushInstructionCache).
Maybe your ultimate goal is not to change some code from debugger, but something else that can be achieved differently. What do you really want?
Is there a way to follow a program's execution through DLL code in hex?
For example, I want to see what sections have just been read when I press a button. It has to work for x64 DLL's.
Thanks!
Yes you load the process into debugger and single step it.
Load the project in visual studio.
Press 'Play' or F5 to start the program in the debugger.
You will need to eventually halt execution sometime so you can start stepping through code or assembly code. You can do this by inserting a breakpoint, or breaking the execution by hitting the break command in the visual studio IDE.
Once halted, you can right click in the code view window, and select "Show Disassembly". Then it will show you the machine instructions.
Also in the watch window in the visual studio debugger, the right click pop up menu has an option to display all variables as hexidecimal. I'm beginning to prefer hex myself lately, because I can see invalid memory patterns easier.
You can use the tool at http://ircdb.org to log function calls arbitrary DLLs.
It's name is SocketSpy, because initially it was created for tracing winsock.dll only, but it does allow you to trace other dlls.
From http://fixunix.com/programmer/95098-tracing-library-dll-calls-win32.html
Use Option->Default Break Point List
Menu to add or remove soft breakpoints
from attached DLLs. Put soft
breakpoints only at function you need
to maximize execution time.
Soft breakpoint means that socketspy
does not stop at this breakpoint, only
log breakpoint information. Hard
breakpoint means that socketspy DOES
STOP at this breakpoint, and
Breakpoint dialog is opened. Specify
what calls should be captured ALL,
FROM EXE FILE or from DLLs (Combobox).
Specify log file File->Open Log File
menu if you want to save function
DLLs' calls into the text file, enable
logging (check box).
Then select a new or already action
process (Select Process button). The
tool can be used in NT/2000/XP only
Alternatively, there is StraceNT, which can trace arbitrary Dlls. It is available for free from http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
I've not used it, but I once stumble upon an Intel tool, which samples the context of the Instruction Pointer, and is able to use symbol files to convert IP to an actual function name... VTune maybe?
I guess there might be other such tools
UPDATE: aka. "statistical profilers"...
Debugging using IDE does not show you the assembly language equivalent of the execution of an IL instruction. You need to write your own hooks to a proper disassembler.
Is it possible to view the heap and stack during debugging?
AFAIK, the main windows you'd want to use are the Locals (Ctrl + Alt + V, L) and Autos (Ctrl + Alt + V, L) windows which MSDN has as:
The Locals window displays variables local to the current context or scope. Usually, this means the procedure or function you are currently executing. The debugger populates this window automatically. In Visual C#, when the Exception Assistant is disabled, the Locals window also displays a pseudovariable $exception whenever there is an active exception. You can expand the pseudovariable to see details of the exception.
The Autos window displays variables used in the current line of code and the preceding line of code. For native C++, the Autos window displays function return values as well. Like the Locals window, the Autos window is populated automatically by the debugger.
...and for the Stack there's the Call Stack window (Debug -> Windows -> Call Stack) or Ctl + Alt + C.
However, I get the feeling this isn't what you're after.
If you are looking for an "in-memory" view you might be able to make use of Visual Studio's Memory windows which can be accessed from the Debug -> Windows -> Memory -> Memory x menus (where x is 1-4) or Ctrl + Alt + M, 1-4.
As a few people have now mentioned, there are a couple of other external tools which are quite useful for memory debugging (I use mainly SysInternals tools and the Debugging Tools for Windows).
You need the "Call Stack Window"...
http://msdn.microsoft.com/en-us/library/a3694ts5.aspx
By using the Call Stack window, you can view the function or procedure calls that are currently on the stack.
And for the Heap, the "Memory Window"...
http://msdn.microsoft.com/en-us/library/s3aw423e(VS.80).aspx
The Memory window provides a view into the memory space used by your application.
"Restoring Hidden Debugger Commands" may also be useful...
http://msdn.microsoft.com/en-us/library/9k643651(VS.80).aspx
As you get into debugging memory, other debuggers will be more useful. As someone suggested, WinDbg is excellent for memory debugging. I use IDA Pro Disassembler a lot myself.
You can view the call stack while debugging, but I assume that's not what you're looking for. You might want to try Windbg and SOS, which are GREAT for debugging memory issues. A bit steep on the learning curve, but the payback is HUGE.
Microsoft Debugging Tools for Windows
If you actually want to look at the raw memory for some reason you can open the "Memory" debug window from "Debug->Windows->Memory" and write the address you want to look at in the edit box. You can also write in the edit box any expression which evaluates to an address and it'll show you that address, for instance &variable
This is not very useful for actually looking at variables because you'll have a tough time parsing the raw bytes into meaningful values but it can be useful for debugging situations where you suspect there are buffer overruns or memory that is overwritten unexpectedly. It is particularly useful when used in conjunction with data-breakpoints.
I know this is an old question, but I figured I'd update it anyway...
Visual Studio 2015 comes with the Memory Usage Monitor built right in to the Diagnostic Tools panel. If you take snapshots before, during, and after what you want to inspect, you can retroactively peek at the heap view of those snapshots.
Hope this helps someone.