I am debugging 'smartgit for windows'.
I want to know how it invokes 'git' (command it pass to git). I start VS and attach the process of smartgit.
I suspect it communicates with git by windows pipe, and other APIs like ReadFile and WriteFile and so on, so set breakpoints at those functions.
After some Options be set, I tick off 'Just My Code' and delete all exclude modules In symbol settings then I download symbols. and I can ensure that 'Kernel32.pdb' was loaded.
'smartgit.exe' (Win32): Loaded 'Q:\Program Files (x86)\SmartGit\bin\smartgit.exe'. Module was built without symbols.
'smartgit.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ntdll.dll'. Symbols loaded.
'smartgit.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Symbols loaded.
'smartgit.exe' (Win32): Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Symbols loaded.
'smartgit.exe' (Win32): Loaded 'C:\Windows\SysWOW64\user32.dll'. Symbols loaded.
_ReadFile#20:
765EF0C0 8B FF mov edi,edi
765EF0C2 55 push ebp
765EF0C3 8B EC mov ebp,esp
765EF0C5 6A FE push 0FFFFFFFEh
765EF0C7 68 C0 52 68 76 push 766852C0h
but still I got the disasm code view when bps were triggered. I am quiet sure that I have ticked 'Show Source Code' option.
WHY? and how to view C code of ReadFile, I want to know what it(smartgit) reads and writes. So I inspect through lpBuffer.
pdb files not containing source code. it can containing information how map RVA address to source file/line. but this information is useful only if you have this source files. because you have no source files for windows system dlls (ntdll, kernel32, kernelbase..) you and can not view it c/c++ code in debugger. and usual information about source files/lines is stripped from system pdbs - because source files anyway not exist for download. but with pdb files you can view internal functions and symbols names (not only exported symbols) - already great advantage which very help in debugging.
in case ReadFile - for what you need source code here ? when you can view say lpBuffer address in [esp + 8] at first instruction (765EF0C0 in your dump) and then in [ebp+0xc] ?
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.
We are writing a console app using .Net Core 2.0. In the app, we load several DLLs from a sub-folder dynamically (by using "Assembly.LoadFromFile()"). And when I set a break-point in which DLL was loaded dynamically, the break-point cannot be hit.
But I am pretty sure the code was called, because I printed out some log information to the console, and the log was there.
So i would like to know why my break-point is not hit? And I have put the corresponding "PDB" files in the sub-folder. And when I opened the "Debug->Windows->Modules" view, i can see the "PDB" files were loaded successfully. So what's the problem?
I want to analyze a file in OllyDbg, however, the "address of entry point" in this file is 0x0000. So it will run the MZ signature as beginning part of the ASM code.
Most debuggers are also unable to debug it directly.
How could I find the original entry point to modify the header?
If AddressOfEntryPoint in EXE set to 0 - so EXE and have no this entry point. In this case, for not crash EXE must have the TLS callbacks - look for IMAGE_TLS_DIRECTORY (IMAGE_DIRECTORY_ENTRY_TLS) and AddressOfCallBacks must be not 0. So this is real entry point(s) of this EXE - no other option, otherwise EXE will crashes.
Most debuggers are also unable to debug it directly.
This happens if debugger set breakpoint on entrypoint. In this case "entrypoint" will be on MZ - and when debugger set breakpoint (0xcc opcode) here - damage MZ signature. As result in process initialization was exception (user32.UserClientDllInitialize -> ntdll.CsrClientConnectToServer -> RtlImageNtHeaderEx (error because MZ damaged by breakpoint) )
But if debugger has not set a breakpoint on entrypoint - no problem in debugging.
So solution is to look for IMAGE_DIRECTORY_ENTRY_TLS.AddressOfCallBacks or set breakpoint to LdrpCallTlsInitializers
really this was CLR (.NET) image - in this images type entry point is formal and not used after xp. system ignore it and call _CorExeMain in mscoree.dll as entry point.
But if you try to debug this with the debugger which auto set breakpoint to entrypoint (how debugger thinks) - the MZ (IMAGE_DOS_HEADER) is damaged. as result RtlImageNtHeader[Ex] return 0 (error) for EXE and application crashed (under this debugger)
0x00000000 is valid value for Address of entry point in PE file, malware uses this trick to make its debugging hard.
Visual Studio can debug a binary that have EP == 0.
When I try to debug a code in Visual C++ 2010, in the Output box, there's some notification :
'latihan.exe': Loaded 'C:\Users\sinta\Documents\Visual Studio 2010\Projects\latihan\Debug\latihan.exe', Symbols loaded.
'latihan.exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\mpich2mpi.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\msvcr100d.dll', Symbols loaded.
The program '[1008] latihan.exe: Native' has exited with code 0 (0x0).
The code :
#include <stdio.h>
int main ()
{
printf ("Welcome \n");
return 0;
}
I just want to know, :)
Those messages mean that your system is missing the symbol files (.pdb, for program database) for various Windows DLLs. They're pretty harmless messages, since usually you won't really care about them, but if you want to get the symbols, you can obtain them via Microsoft's symbol servers.
Right-click the Output window and you'll get a context menu:
The entries with the checkboxes correspond with what you posted. They are notifications generated by the debugger when something interesting happened in your program that you might want to know about. Unchecking one stops the corresponding type of message from being displayed. Documenting them all:
Exception messages. Any exception thrown in your program produces a "First chance" exception notification message. If the exception is not caught then you'll get another one and the debugger stops at the statement that threw the exception. You are always interested in exceptions since they usually indicate a problem.
Step filtering messages. Not relevant to C++ code, managed code has a "Just My Code" debugging feature that can automatically step over code you didn't write.
Module load messages. You'll get a message for every DLL that gets loaded into your process. You got those, messages 2 through 6. It also tells you whether it could find the debugging symbols for the DLL. You don't have the ones for these Windows DLLs because you didn't configure the symbol server. You don't really need them but they can be handy when a winapi call fails.
Module unload messages. Tells you when a DLL gets unloaded
Process exit messages. Tells you when your program stopped running. The last one in your snippet. You might be interested in the exit code, 0 is good.
Thread exit messages. Tells you when a thread stopped running, also displayed with an exit code.
Program output. Anything that the code in your program writes with OutputDebugString in a C/C++ program will appear in the Output window.
Everything looks normal in your snippet.
My workflow follows.
Configure the symbol file path and source code file path for WinDbg.
Open one source code file to be debugged later.
Press F9 and try to set breakpoint in the source code.
WinDbg pops up an error dialog, saying 'Debuggee must be stopped before breakpoints can be modified.'
Who can tell me why? My WinDbg version is 6.11.0001.404 (X86), Windows XP 64-bit. I am debugging a dll from within very complicated runtime system.
I wrote a simple exe and click to open it. Immediately after opening it, I open the source code file and set one breakpoint. It works in this case!
The hint is in the error, "Debuggee must be stopped before breakpoints can be modified". You have to break into the target process with Debug->Break before WinDBG will let you set a breakpoint. When you launch an EXE under WinDBG is starts off broken in, so you can set the breakpoint.
-scott