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.
Related
In visual studio I can set a breakpoint in my code and, when execution breaks, get the address of the memory I am interested in, and then put the address into the memory window to see all the memory bytes from the address onwards. Here's an example:
You can see the breakpoint hit in the middle Visual Studio window, the watch on the variable I am interested in in the bottom window that gives me the address, and I typed the address into the top window to see the memory there.
After execution hits a breakpoint in Xcode how do I view the bytes in memory from a particular address onwards?
(N.B. I have tried to search online for this but my search results are dominated by Xcode's memory usage monitor, which is not what I am after.)
As Martin R points out in his comment on my question, Eric covers exactly this in his answer to the question How to print memory in 0xb0987654 using lldb. Eric explains that Xcode has a Memory Browser window that displays the contents of a given memory addresses.
Eric mentions that we can access the memory browser by pressing ⌘⌥⇧M or through the Debug --> Debug Workflow --> View Memory menus.
He notes that there is a field in its bottom left corner where we can paste the memory address you want to inspect.
Lastly he provides a link to the documentation and to another related answer
Explorer seems to always start my application with SW_MAXIMIZE (STARTF_USESHOWWINDOW is set in STARTUPINFO.dwFlags). I know that ShowWindow will use this value the first time you/Windows needs to display a window but it has the unfortunate consequence of maximizing a window that should never be maximized.
My window is created with CreateDialogIndirectParam and has the following styles: WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_CLIPCHILDREN|DS_MODALFRAME|DS_CENTER|WS_VISIBLE. Why does ShowWindow not check if WS_MAXIMIZEBOX is set before allowing STARTF_USESHOWWINDOW to force SW_MAXIMIZE? Is this a bug in Windows?
This happens on a HP Stream 7 with Windows 8.1. I'm not sure if Explorer does this because it is touch enabled or because of the small screen.
Is this Explorer behavior documented anywhere and is there a way to turn it off? What is the best way to stop Explorer (or any other parent process) from affecting my initial window mode? (I don't want to block people starting me with SW_*MINIMIZE*)
WinVer.exe in system32 has the same problem:
My first thought was to turn off STARTF_USESHOWWINDOW in the PEB if the parent wanted me to start maximized but that is too nasty and undocumented so I have not tried that yet.
Preventing any kind of size change (which is OK for my application since it is just a "modal" dialog) sort of works:
case WM_WINDOWPOSCHANGING:
((WINDOWPOS*)lp)->flags |= SWP_NOSIZE;
return true;
The problem is that the window position is still set to 0 x 0 like a maximized window.
A better solution seems to be to detect and correct the problem after WM_INITDIALOG:
case WM_INITDIALOG:
PostMessage(hDlg, WM_APP, 0, 0);
break;
case WM_APP:
if (IsZoomed(hDlg)) ShowWindow(hDlg, SW_SHOWNOACTIVATE);
break;
I am the proud owner of several HP Stream 7 tablets and I would like to add my 2 cents here. Microsoft has made an arbitrary decision that devices with screen sizes smaller than 8 inches will behave differently than the norm. A lot of users are somewhat aware of this, but unaware that this is where your problem originates.
Windows determines a screen's size by reading the EDID information from the screen, which contains sizing information in it, in centimeters.
If no sizing information is present in the EDID, or the sizing information is below Microsoft's arbitrarily chosen 8 inch threshold, you get this apparent misbehavior which is at the very least, aggrivating to those who notice it and don't want it.
The solution is to override the default driver for the monitor in Device Manager with one that informs Windows that the screen is in fact, 8 inches or larger.
To do so, you need to first read the EDID information from the registry with a tool such as Deltacast's E-EDID Editor (free, last time I checked), and modify the size values and save the modified file someplace you can find it.
After you have modified your EDID file and saved it, download Monitor Asset Manager from EnTech (also free) and use it to create an INF file.
Once the INF file has been created, you need to restart Windows with the Advanced settings menu and choose to Disable Driver Signing Enforcement, since the INF file you created won't be digitally signed. Once disabled, open Device Manager in Windows and update the driver for the monitor using the INF file you created. You will need to confirm that you do in fact want to install the unsigned driver file.
Reboot and Windows will now behave normally with the one catch that, the onscreen keyboard will now appear a different size and will have more options available.
Sadly, Microsoft can change this behavior in the future, so there is no guarantee that through the same flawed decision making process they used to implement this in the first place, they won't force it down our throats again, using a much more difficult to counteract method.
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.
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.
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.