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.
Related
I'm trying to get log of activity of my application with WinDbg. At the moment I'm on Win10 Pro x64. The entry point of my application is 0x10004D7EC. After start of WinDbg I press Ctrl+E to select my app. I input the next command
bp 10004D7EC
then hit F5 but WinDbg says that ERROR_PARTIAL_COPY has been occured (0x12B) so it seems that loading logexts is a bad idea because there is no garanty that information will be correct. So, how to fix this or maybe I do something wrong?
I believe that you're getting the error because you are putting your breakpoint on an invalid memory location. Check in the memory/disassembly window in windbg what is at this memory location - you'll probably find nothing there.
I guess that 10004D7EC is the address of your entry point on the disk - which might be different from the entry point address at runtime. You can search for the entry point with: x <your module name>!*<your entry point name>* (i.e. x myApp!*main*)
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
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.
I want to put a conditional breakpoint in windbg.
For example lets say LoadLibrary API.
How can I put breakpoint such that it should it whenever user32.dll get loaded.
> x kernel32!LoadLibraryW
It will give some address [XXXX]
Now I can put breakpoint as
> bu [XXXX]
but this will hit for all calls to LoadLibraryW.
Any suggestions.
you can not set a conditional breakpoint on a user32.dll since it's being mapped into the address space relatively early and the initial debugger's breakpoint triggers after that (as far as i know).
provided you can track the moment user32.dll is loaded, you can override a module break like this:
sxe ld user32.dll
what you could do is have your app get started by a boostrapper application and then have windows debugger break on user32.dll load. just use -o command-line option or .childdbg 1 extension call to initiate debugging of child processes and have it started with cmd.exe, for instance:
windbg -c "sxe ld user32.dll;g" -o cmd.exe /C yourapp.exe
I am a little confused by the text and header in your question. But assuming you want to set a conditional breakpoint you should take a look at the documentation cause it goes into plenty of detail on that subject.
I want to set a break point and wants it to be triggered when a piece memory (begin address and length are known) are changed. I am working on Windows Server 2003 x64 platform. Either solution in Windbg or solution in Visual Studio are fine. My purpose is to monitor when the memory content is change.
thanks in advance,
George
Try setting a data breakpoint.
In Visual Studio:
Go to Debug >> New Breakpoint >> New Data Breakpoint
Enter the address you want to watch (or an expression that evaluates to an address; such as &foo)
Enter the number of bytes to watch at that address
Click OK, run your program in the debugger, and wait!
This can be done in GDB also. In GDB, this is a watch on a specific address (I've had success setting watches on the address of C++ object members in this way).
Not sure about VS, but with windbg you can use the following command
ba w size address
Replace size with the length of the memory and address with the start address of the memory.
You can set a data breakpoint but you'll need to know the address of the memory location you're interesting in before you can set such a breakpoint. Typically, I either set a breakpoint at the beginning of my program or have the debugger suspend on attach so I can find the memory address of the variable I want to monitor, then set the data breakpoint.