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.
Related
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?
I am using Windows7 x64, and OllyDbg 2.01(alpha 2)
I have an exe, and I want to popup a MessageBox to show some information during execution, and there is a great tutorial shows you how to do this: How to inject code into a exe file, basically, it is about adding a MessageBoxA API call with the wanted information:
PUSH 0 ; BUTTONS = <OK ONLY>
PUSH 1008751 ; CAPTION = Our adress of the "INJECTED NOTEPAD"
PUSH 1008751 ; MESSAGE = Same like above.
PUSH 0 ; ICON = <NO ICON>
CALL MessageBoxA ; Run MessageBoxA with the Params above.
It does work when in live debug session: I injected the code, and then debug it - the message box does pops up. But after I save the executable
(RMB->Edit->Select all; RMB->Edit->Copy to executable; In the new window, RMB->save file), and then execute, it just crashed.
Here are what I've observed:
Before save, the CALL MessageBoxA is actually CALL 74DAFD1E, which
means 74DAFD1E is the address of API MessageBoxA, but after save, the
address is changed to some other value.
Also, do you think ASLR would virtually stop up from injecting windows API call?
Any ideas? how could I managed to show the information I wanted from that exe?
Thanks in advance!
This is caused by ASLR, to make it work in Windows7, one approach is to disable ASLR (at your own risk).
You can download the Enhanced Mitigation Experience Toolkit (EMET) tool, install and run EMET_GUI.exe, in the pop up dialog, disable the ASLR and reboot:
You may want to re-enable ASLR after finishing your work, as it has impact on your OS's security.
I have a small issue with forms that are created from inside a DLL.
Basically what happens is when a form (Form1) from a dll is showing (I think it has to be stay on top) and you open another form (Form2) which is apart of the main application (i.e. does not live inside the dll). If you put your cursor over a control on Form2 so that the hint is displayed, Form2 will immediately go behind Form1.
This only happens with MainFormOnTaskBar is true. At the moment we are passing the main application's Application.Handle to the DLL and assigning that to Application.Handle of the DLL.
I have managed to resolve the issue by instead passing Application.MainForm.Handle to the DLL to be assigned to Application.Handle in the DLL.
Is this safe? does anyone know the proper way to fix this problem?
Your solution is perfectly reasonable. I have an Excel COM add-in that does something very similar. In that code I set Application.Handle in the DLL to be the window handle of the Excel main window. That's analagous to what you are doing.
The issue is that you need to get the window ownership set correctly. You need the chain of ownership to reach all the way back to your app's main form. Forms in a DLL have no knowledge of what the main form is, and so you have to provide that knowledge.
Note that I am talking about the concept of window owner as used by Windows and not the VCL concept of owner which is totally different. In VCL terminology this is known as popup parent and you could solve your problem by explicitly setting the DLL form's popup parent to be the main form. The relevant properties are PopupMode and PopupParent. For the forms that live in the main app, the VCL will naturally make their popup parent be the main form.
However, having talked about explicitly setting popup parent, I would stress that your current solution is simpler and more convenient.
What both of these solutions do is to make sure that all auxiliary forms are owned by the main form. That means that these forms are always on top of the main form. It means that the auxiliary forms will be minimized if the main form is minimized. Read about owned windows here: Window Features.
Incidentally, if you had been using runtime packages rather than a DLL, the code in the package would be connected to the same VCL as the main form. So the packaged code would be able to see the main form and set the window owner appropriately. This is certainly one advantage of using packages. Of course, there may very well be a good reason why you need to use DLLs rather than packages.
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 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.