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.
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.)
Is there an option in ollydbg to find out what pieces of code write to a memory address ? Just like Cheat Engine shows all the assembly instructions that write to a specific address.
"breakpoint --> memory" does not work.
Yes,
With olly open and debugging a certain program, go to View tab>Memory or Alt+M
then, find the memory address (first you have to choose the memory part of the program like .data or .bss) and then click on the address (or addresses selecting multiple with Shift) with the right mouse button and hover to Breakpoint then you'll be able to choose the to break the program when it writes or reads the address
A good thing to do is first find the address on cheatEngine then use the breakpoint on ollydbg.
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.
I met this problem. I have a simple Win32 program which is like the boilerplate which I can get from selecting a "Win32 project" under Visual Studio 2010's "Template --> Visual C++".
I found all other Windows based program like Adobe Reader, Windows Explorer having the feature which is: you enlarging the main window to a new size and then select "Close" or "Exit" from File menu or system menu to close it, then you launch the program again, the main window would be of the size that you adjusted to last time. However that program I got from Visual Studio as the bootstrap does not have such feature.
I researched more on it but cannot find which setting in either WndClass or CreateWindow that I can tweak to make that happen. Does anyone know it, thank you for your help in advance.
The simplest way to do this is with the GetWindowPlacement() and SetWindowPlacement() functions. These manage the window size and state (minimized/maximized/restored) for you.
Call GetWindowPlacement() when you want to record your window's current state:
WINDOWPLACEMENT wp = {0};
wp.length = sizeof(wp);
if (GetWindowPlacement(hWnd, &wp))
{
// save wp values somewhere...
}
You can then save the values of the WINDOWPLACEMENT structure somewhere in your program's configuration files - either in the registry or on disk.
To restore your window's information, load the saved values into the WINDOWPLACEMENT structure, then call the SetWindowPlacement() function:
if (values were previously saved)
{
WINDOWPLACEMENT wp = {0};
wp.length = sizeof(wp);
// load wp values from somewhere...
SetWindowPlacement(hWnd, &wp);
}
You will need to save the position (X, Y) and size (Height, Width) of the window yourself, and set those values when the program starts up again.
Depending on the nature of the program, you might set this in a configuration file, a registry key, or a database (among other options).
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.