In GDB, I can call a function that is part of the executable I am debugging by issuing a command like call foo("123").
How do I do the same in OllyDbg (or possibly some other primarily Windows debugger)?
I don't know how to do it using OllyDbg but since you mention other Windows Debuggers you can use the .call command in WinDbg.
0:001> .call ABC!DoSomething(1,2)
Thread is set up for call, 'g' will execute.
WARNING: This can have serious side-effects,
including deadlocks and corruption of the debuggee.
0:001> r
eax=7ffde000 ebx=00000001 ecx=00000001 edx=00000003 esi=00000004 edi=00000005
eip=10250132 esp=00a7ffbc ebp=00a7fff4 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
ABC!DoSomething:
10250132 55 push ebp
0:001> dd esp
00a7ffbc 00a7ffc8 00000001 00000002 ccfdebcc
The best explanation for it is from The Old New Thing.
In its default installation, Ollydbg can do this only for DLLs which have exports:
Debug > Call DLL export
For executables and DLLs without exports, you will have to build a plugin to do this.
Related
I want having a deep dive into ntdll!NtQueueApcThread seeing what happen after syscall instruction is executed. According to the document(Intel® 64 and IA-32 Architectures Software Developer’s Manual), the syscall instruction using the msr's LSTAR (0xC0000082) as the rip, so I set breakpoint in the nt!KiSystemCall64, which is the address I got by "rdmsr c0000082". But it's not working, my debugger doesn't break. It seems that the syscall inst does not jump to the address stored in the msr.
This is what I have done:
0: kd>
ntdll!NtQueueApcThread+0x10:
0033:00007ffb`3c32c640 7503 jne ntdll!NtQueueApcThread+0x15 (00007ffb`3c32c645)
0: kd>
ntdll!NtQueueApcThread+0x12:
0033:00007ffb`3c32c642 0f05 syscall
0: kd> rdmsr c0000082
msr[c0000082] = fffff802`3681e6c0
0: kd> u fffff802`3681e6c0
nt!KiSystemCall64:
fffff802`3681e6c0 0f01f8 swapgs
fffff802`3681e6c3 654889242510000000 mov qword ptr gs:[10h],rsp
fffff802`3681e6cc 65488b2425a8010000 mov rsp,qword ptr gs:[1A8h]
fffff802`3681e6d5 6a2b push 2Bh
fffff802`3681e6d7 65ff342510000000 push qword ptr gs:[10h]
fffff802`3681e6df 4153 push r11
fffff802`3681e6e1 6a33 push 33h
fffff802`3681e6e3 51 push rcx
0: kd> bp ffff802`3681e6c0
0: kd> t
ntdll!NtQueueApcThread+0x14:
0033:00007ffb`3c32c644 c3 ret
the target system version is Windows10 build 19042
After a few day study, I got to know what the problem is. In normal situation, setting a breakpoint in nt!KiSystemCall64 will cause a BSOD, this is because the first three instruction in nt!KiSystemCall64 is setting the kernel stack, which is required by windows kernel debugging mechanism. So the solution is setting the breakoint after the kernel stack is setup
bp nt!KiSystemCall64+0x15
In my situation, setting breakpoint does nothing happend, seems like the breakpoint is not working, I guess it is due to the anti-virus software I installed, which may have hooked some thing. After I uninstalled it, breakpoint is worked.
I am making an exe from an existing VB6 project. During Make, VB crashes with the following message
Visual Basic has stopped working
Problem Event Name: APPCRASH
Application Name: vb6.exe
Application Version: 6.0.97.82
Fault Module Name: ntdll.dll
Exception Code: c0000005
I am able to run the project from VB6 without any trouble. The problem occurs when I try to make the exe.
Please could you let me know what could be wrong?
Thanks!
This all needs to be done on the computer with the fault. I cannot load my ntdll.dll as it a different version and the addresses will be different to yours.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
This allows WinDbg to get the symbols for your version of ntdll.dll. Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
Open ntdll in WinDbg as a crashdump.
It will show the load address.
Type in WinDbg
ln <modloadaddress> + 7c911780
This will give you the nearest symbol to the crash. It probably isn't useful but lets see.
You can also run VB6 under WinDbg (make sure WinDbg is run as admin). When you crash do a stack trace.
Also do an !Analyze when you crash. It is meant for blue screens but will give info on appcrash.
Type in the WinDbg command prompt
!analyze -v
-v stands for Verbose and if the crash was originated by a program, as opposed to hardware or a driver, it will appear in the middle of the listing.
eg
PROCESS_NAME: java.exe
IMAGE_NAME: ntkrnlmp.exe
PROCESS_NAME only appears in the analyze -v output and only if a program originated the call that faulted.
WinDbg Commands
Open as Executable.
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
There is a breakpoint after loading but before any code is run. Press g to continue. Likewise there is a breakpoint after all code has run but before it is unloaded.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than separate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Sample output from a nearest symbol search.
Loading Dump File [C:\Windows\System32\ntdll.dll] Symbol search path
is: srvc:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is: ModLoad: 4b280000 4b3f9000
C:\Windows\System32\ntdll.dll eax=00000000 ebx=00000000 ecx=00000000
edx=00000000 esi=00000000 edi=00000000 eip=4b280000 esp=00000000
ebp=00000000 iopl=0 nv up di pl nz na pe nc cs=0000 ss=0000
ds=0000 es=0000 fs=0000 gs=0000 efl=00000000
ntdll!__guard_fids_table (ntdll+0x0): 4b280000 4d
dec ebp 0:000> ln 4b280000 + 65534 (4b2e5520)
ntdll!RtlInitializeBitMap+0x14 | (4b2e5540)
ntdll!TpCallbackUnloadDllOnCompletion
Sample stack trace.
You follow what function called what functions. So you read it from the bottom up. It has the first 4 parameters that were passed to the function. You find the debugger starts additional threads so we need to find our program's one.
~
Lists all threads
~<threadid> e <command>
Do a KB on all threads until you find the main one.
0:004> ~0 e kb
ChildEBP RetAddr Args to Child 04bdfc30
75ae325a 04bdfc70 00000000 00000000 USER32!NtUserGetMessage+0xc
04bdfc4c 00895eb6 04bdfc70 00000000 00000000 USER32!GetMessageW+0x2a
04bdfc8c 008a5b41 00890000 00000000 04e2336f notepad!WinMain+0xe6
04bdfd20 74ad3744 7f229000 74ad3720 10fde46e
notepad!WinMainCRTStartup+0x151 04bdfd34 7755a064 7f229000 b0c1107f
00000000 KERNEL32!BaseThreadInitThunk+0x24 04bdfd7c 7755a02f ffffffff
7757d7c9 00000000 ntdll!__RtlUserThreadStart+0x2f 04bdfd8c 00000000
008a59f0 7f229000 00000000 ntdll!_RtlUserThreadStart+0x1b
Assume that 04bdfc70 is an HWnd. Which it is because the documentation says so. But assume it an address of a string. This displays what is there.
ds 775a1300
or to look at the values
db 775a1300
When I use a unix utility from MinGW make, I get a StackDump file:
error:
sed -i -e 's/reveal.js\/css\/theme\/simple.css/reveal.js\/css\/theme\/moon.css/' index.html
0 [main] sed 8744 open_stackdumpfile: Dumping stack trace to sed.exe.stackdump
make: *** [index.html] Error 5
sed.exe.stackdump:
MSYS-1.0.12 Build:2012-07-05 14:56
Exception: STATUS_ACCESS_VIOLATION at eip=68008DAA
eax=03019001 ebx=60EA4124 ecx=00692788 edx=00000150 esi=00000000 edi=60EA00D4
ebp=0028FE9C esp=0028FE78 program=c:\Program Files (x86)\Git\bin\sed.exe
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028FE9C 68008DAA (60EA00D4, 00000150, 0028FEEC, 680044EA)
0028FEEC 6800466B (00000000, 00000000, 0028FF2C, 00517CF8)
0028FF0C 68004C5F (00401C28, 00000000, 5C952BA0, FFFFE001)
0028FF2C 68004C98 (00000000, 00000000, 928A67BF, FFFFF800)
0028FF5C 00517C08 (00401C28, FFFFE001, 00000001, 00000000)
0028FF8C 0040103D (7FFDE000, 0028FFDC, 771F0BBB, 7FFDE000)
0028FF98 74F6919F (7FFDE000, 99B8EAFE, 00000000, 00000000)
0028FFDC 771F0BBB (FFFFFFFF, 771DC9D0, 00000000, 00000000)
0028FFEC 771F0B91 (00401000, 7FFDE000, 00000000, 78746341)
End of stack trace
I get very similar errors when trying to use tools like rm, mv, and cp. What can I do to fix these errors? It is making developing on Windows impossible.
The make binary that I am using is located at C:\MinGW\msys\1.0\bin\make.exe, and the version information is:
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-msys
I'm guessing your problem is the msysgit version of sed is using the version of the MSYS DLL in C:\MinGW\msys\1.0\bin instead of the DLL in c:\Program Files (x86)\Git\bin. Try changing your PATH so that your makefile uses the sed in C:\MinGW\msys\1.0\bin, rather than the msysgit version.
I discovered the problem. I was actually using the MSYS version of make, but the sed binary was the one that shipped with cmder. This mismatch was causing the stackdumps. I fixed the path, and now it is working fine.
I'm working on porting Mumble over to Windows RT (using the jailbreak), and I've hit an issue where this one function is getting corrupted when Mumble loads.
Mumble (Corrupt function):
0:000> dq user32.dll+0x023918
77a63918 47c3004244696841 4770df010c16f241
77a63928 4770df010c17f241 4770df010c18f241
77a63938 4770df010c19f241 4770df010c1af241
77a63948 4770df010c1bf241 4770df010c1cf241
77a63958 4770df010c1df241 4770df010c1ef241
77a63968 4770df010c1ff241 4770df015c81f44f
77a63978 4770df010c21f241 4770df010c22f241
77a63988 4770df010c23f241 4770df010c24f241
0:000> u user32.dll+0x023918
* ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\windows\system32\user32.dll -
user32!WindowFromPoint:
77a63918 6841 ldr r1,[r0,#4]
77a6391a 4469 add r1,r1,sp
77a6391c 0042 lsls r2,r0,#1
77a6391e 47c3 ?blx r8
77a63920 f2410c16 mov r12,#0x1016
77a63924 df01 svc #1
TeXworks (Expected output):
0:000> dq user32.dll+0x23918
77a63918 4770df010c15f241 4770df010c16f241
77a63928 4770df010c17f241 4770df010c18f241
77a63938 4770df010c19f241 4770df010c1af241
77a63948 4770df010c1bf241 4770df010c1cf241
77a63958 4770df010c1df241 4770df010c1ef241
77a63968 4770df010c1ff241 4770df015c81f44f
77a63978 4770df010c21f241 4770df010c22f241
77a63988 4770df010c23f241 4770df010c24f241
0:000> u user32.dll+0x23918
* ERROR: Symbol file could not be found. Defaulted to export symbols for C:\windows\system32\USER32.dll -
USER32!WindowFromPoint:
77a63918 f2410c15 mov r12,#0x1015
77a6391c df01 svc #1
77a6391e 4770 bx lr
77a63920 f2410c16 mov r12,#0x1016
77a63924 df01 svc #1
77a63926 4770 bx lr
77a63928 f2410c17 mov r12,#0x1017
77a6392c df01 svc #1
(Apologies for the less than stellar formatting of the code, a screenshot of the windows can be found here: http://i.imgur.com/M6mLHN1.png )
Mumble uses Qt (customized by the Mumble team, to my understanding), Protobuf, Boost, and OpenSSL
TeXworks uses Qt
What I've tried so far:
Disabling the application compatibility engine
Unloading user32.dll at load, then reloading it (calling FreeLibrary 100 times, then calling LoadLibrary)
Removing anything that might look even remotely suspect from the manifests (from Qt and Mumble)
Removing the entire manifests (from Qt and Mumble)
If I patch this one function using cdb after Mumble launches it all works awesomely, but if I don't patch it the first action performed that calls that function ends in a crash. Opening/closing windows and dragging all call that function, so it's rather critical to the program that it's there.
Any help or pointers on this would be more than appreciated.
Edit: I've verified that it's something inside mainCRTStartup that's mucking around with it, trying to figure out what exactly it is now.
Edit 2: Found a platform-specific hook hidden in the Mumble code that was causing my troubles. Solved.
Since I can finally answer this now, Mumble had some hooks hidden away that I didn't know about. I defined a custom entrypoint that called mainCRTStartup so I could step through that and find exactly where that memory was getting changed, it led me straight to the hook.
Here's the code I used for that:
EXTERN_C int WINAPI mainCRTStartup();
void __stdcall EntryPoint()
{
MessageBox(HWND_DESKTOP,L"Pause(Before mainCRTStartup)",L"Pause(Before mainCRTStartup",MB_OK);
mainCRTStartup();
ExitProcess(0);
}
That allowed me to attach a debugger at the messagebox and step through mainCRTStartup until I found the static initializer that was getting called to load the hook.
here is what I'm trying to solve. I have a crash dump from Google Chrome.
I open windbg and say File -> Symbol File Path:
"SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com"
I guess this looks for the debugging symbols from let to right and should finally grab them from google then. I copied that from http://www.chromium.org/developers/how-tos/debugging.
I drag and drop the crash dump into windbg
And then...
Microsoft (R) Windows Debugger Version 6.2.8400.0 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\cburgdorf\Desktop\Chrome-last.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed May 16 16:25:24.000 2012 (UTC + 2:00)
System Uptime: not available
Process Uptime: 0 days 0:01:39.000
.........................................
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
eax=00000000 ebx=0038e1f8 ecx=00000001 edx=0012df58 esi=00000002 edi=0038e218
eip=776e013d esp=0038e1a8 ebp=0038e244 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!NtWaitForMultipleObjects+0x15:
776e013d 83c404 add esp,4
0:000> .excr
^ Syntax error in '.excr'
You see that it says "The stored exception information can be accessed via .ecxr" but once I insert that it tells me that I have a syntax error.
Does anyone know what I'm doing wrong?
You've got a typo, it's .ecxr :) In the meantime, another easy way to get information out of a crash dump without needing too much WinDbg-fu, is:
.symfix; .reload
!analyze -v
And if this is a .NET App (Chromium isn't but just for extra info), add these three lines
.loadby sos clr
!pe
~*e !clrstack