Imagine an application that displays a button: OK. Is it possible to break the execution of the program and view the disassembly using WinDbg, right after the button has received a click? How would I do that? In this scenario, the source code is not available.
So, your description is very general, and not very well defined, and the exact research really depends on the application that you are trying to reverse. You will have easier time if you have symbols, but these aren't required.
First, some (trivial) background: Windows communicates with the application through Windows Messages. The application will fetch messages from the message queue, and almost always will dispatch those messages to the appropriate Windows Procedure.
So, first - what do you mean: "right after the button has received a click"? I suspect that you actually don't care about this code. Although your application could have a custom button, and you really care how the button handles a WM_LBUTTONDOWN message. I'm going to assume that your application has a Windows stock button (implemented in user32.dll or comctl32.dll), and that you don't care about that.
The default implementation of a button control handling WM_LBUTTONDOWN is to send WM_COMMAND to the window that contains the button. Typically, the application that you want to investigate handles the "click" there. Now, if this is the 'OK' button, it's ID would be IDOK (defined to be 1), and Windows will send you the same message also when you click the 'Enter' key.
So, we are now looking for how the application handles WM_COMMAND. What you want to find is the Windows procedure. Do that with Spy++. Open Spy and find the Window that contain your button. Most chances that the code you are looking for is in the Windows Procedure of that window. Spy++ will tell you the address of the Window Procedure.
As an example, let's look at the 'Save' button of the 'Save As' dialog in Notepad. On my machine the address is: 0x73611142, which is in ComCtl32.dll
Go to WinDbg, and take a look at the function.
0:000> u 73611142
COMCTL32!MasterSubclassProc
73611142 8bff mov edi,edi
73611144 55 push ebp
73611145 8bec mov ebp,esp
73611147 6afe push 0FFFFFFFEh
73611149 6858126173 push offset COMCTL32!Ordinal377+0x146 (73611258)
7361114e 68a1b06273 push offset COMCTL32!DllGetVersion+0x336f (7362b0a1)
73611153 64a100000000 mov eax,dword ptr fs:[00000000h]
73611159 50 push eax
This is indeed a function. Like all Windows, it starts with move edi,edi, and then it sets the frame pointer.
Put a break point, hit go, and you'll almost immediately break. Let's take a look:
0:000> bu 73611142
0:000> g
0:000> kb1
ChildEBP RetAddr Args to Child
0101f220 75d87443 00120c6a 00000046 00000000 COMCTL32!MasterSubclassProc
The first argument (00120c6a) is handle of the window. Compare with the value on Spy++, it should be the same. The second argument is the message. In my case it was 0x46 which is WM_WINDOWPOSCHANGING.
OK, I don't care about all those messages, and I want to break only on the messages I care about. You care about WM_COMMAND which is 0X0111 (winuser.h)
Now, put the following (a little bit complex command):
0:000> bu 73611142 "j poi(esp+4)==00120c6a AND poi(esp+8)==111 AND poi(esp+''; 'gc'"
breakpoint 0 redefined
You set a breakpoint on the windows procedure, and you tell WinDbg to break only when the first argument ( that's the poi(esp+4) ) is your Windows handle, and the second argument is 111. The 'gc' tells WinDBG to continue the execution when the condition will not meet.
Now you can debug the disassembly. If you have symbols, you'll have an easier job, but this isn't necessary. In any case, remember to download the Microsoft stripped down symbols from the symbols server, so if the code you are debugging is calling a Windows API, you can see it.
That's about it. Modify this technique if your requirements are different (different Window, different message, etc). As a last resort consider putting a breakpoint on PostMessage or DispatchMessage if you can't reliably find the Windows Procedure (although, you'll have to follow that code). For heavy lifting reversing use IDA, which will disassemble the executable, and solve various cross reference.
Assuming you had the pdbs and they did not have the private symbols stripped then you would set the breakpoint on the button handler like so:
bp myDLL!myWindowApp::onOKBtnClicked
If you had the pdbs then you could search for a likely handler using x:
x myDLL!myWindowApp::*ok*
this presumes that you know or can guess which dll and what the function name is, otherwise you could gleam this information using spy++, Win Spy++ or Win Detective to get the handle for the button and intercept the window messages and from that info set the breakpoint.
Once it hits the breakpoint you can view the assembly code using u, there is a msdn guide if you require it.
Related
I have this application that I need to disassemble. I don't have a clue on how to stop the running code on the desired location, so I decided my best guess would be breaking upon a button click. But how do I capture button clicks? I know it has probably something to do with the Windows functions such as CallNextHookEx. I'm using IDA PRO to disassembly.
IDA PRO is used mostly as disassembler, for static analysis purposes. I'd suggest you to use Ollydbg (or some other debugger, if you want to) because it will suit better to debugging purposes.
I don't know if you can set a breakpoint on an API like that.
But you can do this:
Load the application in olly, or attach to it.
Generate the event by clicking on anything.
Stop the application from ollydbg(F12)
Use C(k)all stack(ALT+K)
You will see a few calls to functions, one of them is doing what you need. But you may need to go to upper calls to see the whole loop. So you will just try which one it is. There will be a loop in one of them.That loop will have conditional jumps and generate events, load forms, fill the app etc. And when you place a breakpoint on the right jump there, it will stop at each mouse click.
When I'm debugging apps, most of the times I find myself on a breakpoint like this, and I see from the beginning how the application is filling an empty form(it takes so long.)
How i can view Stack content (not stack call) at visual studio 2013?
view to where ESP is pointing and below. show content at char.
Thanks for the help.
You can do this by going to Debug > Windows > Registers, get the location of ESP, and then enter this address in a Debug > Windows > Memory window. However, that will only give you the raw memory.
As OwenWengerd points out in the comments, you can simply type ESP in the address field if you're debugging native code. For some reason, this doesn't work for managed code though.
The other answer is correct for 32-bit code, however it is only "half-correct" for 64-bit code.
If you really want to see the memory at esp, then you can enter esp in the Address input box in the Memory debug window.
However, this is probably not what you want for 64-bit code. The stack is at rsp not esp.
If you enter rsp into the Address input textbox in the Memory debug window then you will see the stack memory. If you enter esp into the Address input textbox then you will see the memory at (rsp & 0x00000000ffffffff), which is probably not what you want.
You may recreate what some older DOS debuggers had like Turbo Debug, with an arranged memory pane:
Open a memory pane.
In the context menu, select 4-bytes integer (resp. 8-bytes) for a 32-bit stack (resp. 64-).
Select 1 column (or reduce the width of the pane to let only 1 column appear, whatever suits you best; also you might want to display this narrow pane under your solution explorer where it'll almost naturally have a single column)
Enter esp (resp. rsp) in the address bar.
Click on the refresh button so that the address bar reevaluates on each step.
If debugging at assembly level and stepping through some PUSHes and POPs, you should see the memory pane keep in sync.
Note: this was written with x86 or amd64 architectures in mind which aren't the only supported by VS. If you're on another architecture, adapt what you read to your CPU's own specifics i.e., open the register pane to find out your own stack pointer register name.
when the program is doing calculations in c++,c#,vb.net you can use the application::doevents() to refresh the screen so the screen do not freeze. how can you do this in assembly particular masm
I tried putting
invoke SendMessage, hWin, WM_SETREDRAW, 0, 0
invoke SendMessage, hWin, WM_SETREDRAW, 1, 0
in the loop part of my program but it does not work.
I also tried
invoke SendMessage, hWin, WM_SETREDRAW, 1, 0
but that does not work either
Application::DoEvents does a lot more than just refresh the screen. It actually pumps the message queue for the application's UI thread. If you wanted to do this in assembler, you would need to pump the message queue yourself. However, I don't recommend this. Using DoEvents in any UI framework is a definite anti-pattern, whether it provides such a function or not. More information is here and here.
If all you want to do is ensure that your listbox control gets repainted, then you need to invalidate it and force a redraw. In WinForms, that would be:
myListBox.Invalidate();
myListBox.Update();
In assembler, you will need to invoke the appropriate Win32 API functions yourself. In particular, you can use InvalidateRect to invalidate the client area of your listbox control and then UpdateWindow to ensure that it gets repainted immediately.
I don't know the syntax for MASM, but in unmanaged C++, it would look like this:
InvalidateRect(hListBox, /* handle to your listbox control */
NULL, /* invalidate the entire client area */
TRUE); /* erase the background */
UpdateWindow(hListBox);
In most cases, invalidating the window is enough. You don't need to force an immediate repaint, because the next time that your application processes messages (in its regular message loop), it will process a WM_PAINT message and redraw the control. The only reason this wouldn't work is if you were blocking the UI thread by performing some type of long-running operation, which you should not be doing in the first place—spin off a background thread to perform calculations.
The reason sending a WM_SETREDRAW message doesn't work here is because that basically sets a flag indicating whether the control is allowed to redraw itself. As the linked documentation explains, the window still needs to be redrawn in order to see the changes. It says you can force this by calling, e.g., RedrawWindow or doing the same thing we did above.
I am trying to debug a very old C program in visual studio. I was stepping through some code line by line and came to a line DispatchMessage(&msg); I wanted to see where the code went next, so I clicked the "Step into" button, but I was not taken to any new code that processed the message, instead the little yellow arrow just stepped along to the next line down the same page...
Is this expected behaviour? How can I see what DispatchMessage actually did?
Could this be an indication that the window handler is not set up correctly?
extra info: The task I was tring to debug was the processing of a mouse click on a particular window. I had displayed the msg structure, and msg.hwnd was the window I had clicked on (I used Winspector to confirm). The msg.message was 513 (=WM_LBUTTONDOWN).
This is completely expected behaviour...
DispatchMessage() is implemented in User32.dll and as such, the source code is not available. For the most part, you have to treat Win32 API calls as blackboxes. At times, this can really make debugging Win32 code a challenge.
Remember, there are some tricks in your arsenal for debugging this kind of thing:
Go on treating DispatchMessage() as a black box. Place a breakpoint on the WndProc you expect to receive the WM_LBUTTONDOWN and continue debugging there.
Have Winspector log the messages coming into all of the windows involved. This can help make sure the message is received and in the order you are expecting.
If worst comes to worst, you may have to step into DispatchMessage() or some other API call, looking at its disassembly. Most of the time, nothing good comes from that (but I always learn something when I do).
Chances are that option #3 won't be necessary and your time would be better spent debugging around DispatchMessage() rather than within it.
I have a already compiled C++ console application wich is shown as a little black window.
Now i want to disassemble the app and add code to get the Process start hidden. Maybe you can help me finding the api call or if you can explain me how that works. The current Debuger I use is OllyDBG but I also have knowledge in IDA and WDASM32.
Thanks forward!
There are two ways to do this. You can do a code injection to hide the window after it's created or you can change the subsystem that is defined in the PE header.
The PE header has a flag defining the subsystem the code was compiled against. This will currently be WINDOWS_CUI and you want to change it to WINDOWS_GUI.
To do the code injection, find a codecave, then patch a JMP at entry point (EP) to this codecave. In the codecave, write the instruction that was overwritten by the JMP then make a call to FreeConsole then JMP back to the instruction after the JMP you patched in at the EP earlier.
Let me give you an example. I compiled a C program in VC++:
#include <Windows.h>
int main() {
Sleep(INFINITE);
return 0;
}
If we open up the result binary in OllyDbg, we get something like this:
Press the big M at the top to get the Memory Map:
Since our main module is Some_console_App then double click the PE header there which takes us to this:
Scroll down a bit to find the subsystem:
As you can see it's set to IMAGE_SUBSYSTEM_WINDOWS_CUI which is defined as 3. We want to set it to IMAGE_SUBSYSTEM_WINDOWS_GUI which is 2. Go back to the CPU window and in the hex dump, go to the address that the subsystem flag was set on. In this case it's 0x0136013C:
Select the byte you want to change, hit Ctrl-E and change the 3 to 2. Then right-click >> Copy to Executable File. In the File window that pops up, right-click and select Save File.
Tada! Done. Sorry for large resolutions of pictures.