How to break on the entry point of a program when debug in kernel mode with windbg?
Asked Answered
M

2

1

I want to debug a program in kernel mode, and I want to break on the entry point of the program like ollydbg. But I can't break it with bp because the program is not start and the symbol can't be loaded. I have found some way to do it but I think it's not so good.

1.Break on the CreateProcess function in kernel. But I don't know which function exactly should I break and I think there is a long way between CreateProcess and the entry point of the program.

2.Change the entry point of the program with cc. But it needs other tools and I should change the code where the byte changed back. I think it is annoying.

3.With the help of ollydbg. Debugging the program with ollydbg in a virtual machine which is debugged with windbg. I don't think that it is a good idea.

4.Use sxe ld. It can be found on Listing 3.29 in <<Advanced Windows Debugging>>. I have tried it but I found that it only works on the first time. And I don't know what exactly should I do after the break.

5.Break on the entry function with bu. But I don't know what exactly I should do either. For example, how to load the symbol?

6.Use .create. I don't know whether it is properly or not to do what I said.

I think that it is a common use to break on the entry point of a program when debug in kernel mode with windbg , and I think that there must be a good way to do that with the powerful windbg. What's the best way to do it?

By the way, I want to debug a program in kernel mode because I want to get the token vaule of the program. I found that the windbg can identify the token with !token in user mode, but I don't know how to get the value of token in user mode. It seems that I can only get the value of token in the kernel mode, right or wrong?

Mall answered 8/7, 2015 at 14:12 Comment(9)
Security tokens live in kernel address space. This makes it possible to refer to security token using !token <address> in kernel debugger. In user mode tokens surface out through HANDLE's, so if you know the value of the handle, you can dump properties in user mode debugger with command !token <handle>. In your case you seem to be talking about a token of the user account under which process was started, right? If so, then invoking !token without parameters will display the right token, assuming the thread is not impersonating. So you don't need to mess with kd at all.Lollis
I know that !token can show me the information of token, even there is a impersonation token. But I can only get TS Session ID,User/Groups GUID,Primary Group,Privs,Auth ID,Impersonation level,TokenType,Is restricted token from !token. It seems that I can't get the handle of the token?Mall
I believe that !token obtains a thread token by calling OpenThreadToken, then queries the properties of the token, and closes the handle. So the handle might not be an internal HANDLE of the process being debugged, it is internal to WinDbg itself. What other type of information you need from the token?Lollis
In fact, I want to check that when the token was changed to a impersonation token with system GUID and when it comes back in a poc, but I find that I can't find the value of the token. I think I must get the value of token to check for the change.Mall
And I need the vaule of token because it will be verified in kernel with the result of PsReferenceImpersonationToken or PsReferencePrimaryToken and I want to check for it.Mall
Can't you use kernel debugging and user mode debugging at the same time using two instances of WinDbg? Use .wtitle to distinguish them. Use AeDebug to start the debugger automatically for the process you're interested in.Tintinnabulum
One of the ways to get the HANDLE of impersonation tokens is to set a breakpoint on SetThreadToken and inspect the second parameter.Lollis
@Thomas You mean that I use a windbg to debug a virtual mathine, and start a windbg in the virtual mathine to debug the program in user mode? Are there any articles talk about it in detail?Mall
@sevatitov I find that SDbgExt is easier to get the handle of token, and the example is here. But what I want to get is the real value of token from handle, which can be got from PsReferenceImpersonationToken.Mall
C
4

you can run any exe in the target via ntsd -d to debug it from the kernel mode debugger running in the host

assuming you are running a virtual machine mytarget inside myhost

install windbg in myhost
set symbol path for myhost viz srv*x:\xxxx*http:\xxxxxxxxxxxx
create a kernel connection in the host (choose the best shown below is a serial connnection)

X:\xxxx\windbg.exe -k com:pipe,port=\\.\pipe\debugPipe,resets=0,reconnect

install windbg in mytarget
open a shared folder z:\ pointing to the symbolcache folder in myhost set symbolpath in mytarget pointing to the shared folder run ntsd -d calc.exe

kd will break on $exentry of calc.exe with Input Prompt

as long as Input prompt is shown you are using kd like a native usermode debugger so if you set a bp calc!Winmain and issue g kd will break on calc.exe winmain

to get to kd session use .breakin

messy stuff but will work well once you get accustomed (ie memorizing the docs)

a sample run

kd> g   <-------------- kd session running in myhost

CommandLine: calc.exe 
Symbol search path is: srv*z:\
*http://msdl.microsoft.com/download/symbols

ntdll!DbgBreakPoint:
7c90120e cc              int     3

.sympath
NOTE: The symbol path for this ntsd is relative to where
ntsd.exe is running, not where kd.exe is running.
Symbol search path is: srv*z:\
*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*z:\
*http://msdl.microsoft.com/download/symbols

.reload /f calc.exe

lm m calc
start    end        module name
01000000 0101f000   calc       (pdb symbols)          z:\calc.pdb\3B7D84101\calc.pdb

0:000> version  <--------------------usermode session in kd via ntsd -d 
version
Windows XP Version 2600 (Service Pack 3) UP Free x86 compatible

Live user mode: <Local>

command line: 'ntsd -d calc.exe'  Debugger Process 0x3F8 

? $exentry;? calc!WinmainCrtstartup
Evaluate expression: 16852085 = 01012475
Evaluate expression: 16852085 = 01012475

as to your original request i am not sure what token you are interested to find

if getting the EPROCESS->Token of your exe is the only requirement you dont have to run any kd session

you can get the token of all running process in myhost with a local kernel debugging session (either using kd -kl or by using livekd from sysinternals)

here is a simple script which fetches the sid of all running process employing the above technique

:\>cat sid.txt
!for_each_process "r $t0 =(@@c++(((nt!_eprocess *) @#Process )->Token.Object)) &
 @@(~7); r $t1 = @@c++(((nt!_token *) @$t0 )->UserAndGroups->Sid);!sid @$t1 1; ?
? (char *)((nt!_eprocess *) @#Process )->ImageFileName "

:\>kd -kl -c "$$>a< sid.txt;q"

result

WARNING: Local kernel debugging requires booting with kernel
debugging support (/debug or bcdedit -debug on) to work optimally.

lkd> kd: Reading initial command '$$>a< sid.txt;q'
SID is: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
char * 0x8ac729a4
 "System"
SID is: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
char * 0x8a35729c
 "smss.exe"

SID is: S-1-5-20 (Well Known Group: NT AUTHORITY\NETWORK SERVICE)
char * 0x8a3619ac
 "svchost.exe"

SID is: S-1-5-19 (Well Known Group: NT AUTHORITY\LOCAL SERVICE)
char * 0x8a36ef14
 "svchost.exe"

SID is: S-1-5-21-602162358-1801674531-1417001333-1003 (User: XXXXXX\Admin)
char * 0x8a261b64
 "explorer.exe"
Curagh answered 15/7, 2015 at 6:1 Comment(0)
H
2

Use the method described in the Windbg help file for debugging WinLogon. Substitute your user mode app for WinLogon:

Windbg | Help | Contents | Windows Debugging | Debugging Techniques | Specialized Debugging Techniques | Debugging WinLogon

IFEO will start your user mode app and attach ntsd.exe. From ntsd.exe, you can set a break point on image entry with bu $exentry then g to continue.

At any point that ntsd.exe is broken into your user mode process, you can issue .breakin command to switch to kernel mode debugging.

Hallvard answered 14/7, 2015 at 21:56 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.