2

I'm looking for the start address of where myfile.exe mapped into memory using Windbg. For this I connected to a VMWare for kernel debugging through serial port, after that I run myfile.exe in guest machine and attach to it from guest machine by ollydbg to see any editing that made in kernel debugging takes place in myfile.exe then break the Windbg to edit memory from host machine.

So I use the following command to get all the processes to see where can I find myfile.exe :

 kd> !process 0 0

And it gives me a long list of processes where I can finally find myfile.exe.

PROCESS ffffe001f9652080
    SessionId: 1  Cid: 0da4    Peb: 7ffdf000  ParentCid: 0588
    DirBase: 11d6d000  ObjectTable: ffffc0013e905680  HandleCount: <Data Not Accessible>
    Image: myfile.exe

So for more details about this process I run :

 kd> !process ffffe001f9652080 7

and it gives me :

    1: kd> !process ffffe001f9652080 7
PROCESS ffffe001f9652080
    SessionId: 1  Cid: 0da4    Peb: 7ffdf000  ParentCid: 0588
    DirBase: 11d6d000  ObjectTable: ffffc0013e905680  HandleCount: <Data Not Accessible>
    Image: myfile.exe
    VadRoot ffffe001f64dda10 Vads 129 Clone 0 Private 5676. Modified 520. Locked 0.
    DeviceMap ffffc0013dff8c30
    Token                             ffffc0014336a8e0
    ElapsedTime                       00:08:14.197
    UserTime                          00:00:00.046
    KernelTime                        00:00:00.125
    QuotaPoolUsage[PagedPool]         231392
    QuotaPoolUsage[NonPagedPool]      17632
    Working Set Sizes (now,min,max)  (11793, 50, 345) (47172KB, 200KB, 1380KB)
    PeakWorkingSetSize                13859
    VirtualSize                       148 Mb
    PeakVirtualSize                   159 Mb
    PageFaultCount                    24764
    MemoryPriority                    BACKGROUND
    BasePriority                      8
    CommitCharge                      6195
    DebugPort                         ffffe001fa6f0f90
    Job                               ffffe001f8544620
    THREAD ffffe001fa713440  Cid 0da4.10a4  Teb: 000000007ffdb000 Win32Thread: ffffe001f6822cb0 WAIT: (WrUserRequest) UserMode Non-Alertable
        ffffe001fa4bbb90  SynchronizationEvent
    Not impersonating
    DeviceMap                 ffffc0013dff8c30
    Owning Process            ffffe001f9652080       Image:         myfile.exe
    Attached Process          N/A            Image:         N/A
    Wait Start TickCount      56653          Ticks: 2 (0:00:00:00.031)
    Context Switch Count      11053          IdealProcessor: 2             
    UserTime                  00:00:01.125
    KernelTime                00:00:00.781
    Win32 Start Address 0x000000000044aa31
    Stack Init ffffd00025d59c90 Current ffffd00025d59480
    Base ffffd00025d5a000 Limit ffffd00025d54000 Call 0
    Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    ffffd000`25d594c0 fffff802`a1c92130 : ffffe001`f805e0c0 fffff961`00000000 ffffe001`fa713440 fffff802`a1c8ee76 : nt!KiSwapContext+0x76
    ffffd000`25d59600 fffff802`a1c91b48 : 00000000`00000000 00000000`00010001 00000000`00000000 00000000`00000000 : nt!KiSwapThread+0x160
    ffffd000`25d596b0 fffff802`a1c9120d : 00000000`00000000 00000000`00000000 ffffd000`25d59900 00000000`00000000 : nt!KiCommitThreadWait+0x148
    ffffd000`25d59740 fffff961`00c95dc5 : fffff901`00000000 ffffd000`25d598a0 fffff901`423edb20 fffff901`0000000d : nt!KeWaitForMultipleObjects+0x3fd
    ffffd000`25d59800 fffff961`00c959f8 : fffff901`423edb20 fffff901`423edb20 00000000`00003dff fffff961`00c958a3 : win32kfull!xxxRealSleepThread+0x355
    ffffd000`25d598f0 fffff961`00c94ba0 : ffffd000`25d59b80 00000000`00000000 fffff901`423edb20 00000000`00000000 : win32kfull!xxxSleepThread2+0x98
    ffffd000`25d59940 fffff961`00c93fc0 : ffffd000`25d59ab8 ffffd000`25d5c240 00000000`00000000 00000000`ffffffff : win32kfull!xxxRealInternalGetMessage+0xb70
    ffffd000`25d59a70 fffff802`a1dd2a63 : ffffe001`fa713440 00000000`570a8480 00000000`00000020 00000000`00000000 : win32kfull!NtUserGetMessage+0x90
    ffffd000`25d59b00 00000000`570b344a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`25d59b00)
    00000000`0009e6b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x570b344a

    THREAD ffffe001fab05840  Cid 0da4.11ac  Teb: 000000007fe9e000 Win32Thread: 0000000000000000 WAIT: (WrQueue) UserMode Alertable
        ffffe001f6741d40  QueueObject
    Not impersonating
    DeviceMap                 ffffc0013dff8c30
    Owning Process            ffffe001f9652080       Image:         myfile.exe
    Attached Process          N/A            Image:         N/A
    Wait Start TickCount      51667          Ticks: 4988 (0:00:01:17.937)
    Context Switch Count      34             IdealProcessor: 2             
    UserTime                  00:00:00.000
    KernelTime                00:00:00.015
    Win32 Start Address 0x0000000077e54630
    Stack Init ffffd000203cfc90 Current ffffd000203cf420
    Base ffffd000203d0000 Limit ffffd000203ca000 Call 0
    Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    ffffd000`203cf460 fffff802`a1c92130 : 0000ffff`00000000 00000000`00000001 ffffe001`fab05980 ffffe001`fab05940 : nt!KiSwapContext+0x76
    ffffd000`203cf5a0 fffff802`a1c91b48 : 00000000`743af562 00000000`00000030 00000000`00000000 ffffe001`f9652578 : nt!KiSwapThread+0x160
    ffffd000`203cf650 fffff802`a1c907a5 : 00000000`69f79021 00000000`00000010 fffffa80`013de6b0 fffffa80`0127b690 : nt!KiCommitThreadWait+0x148
    ffffd000`203cf6e0 fffff802`a1c90382 : ffffe001`f6741d40 00000000`00000000 00000000`00000001 00000000`00000000 : nt!KeRemoveQueueEx+0x215
    ffffd000`203cf750 fffff802`a1c8fd43 : fffff680`003a1d78 ffffe001`f9652578 ffffd000`203cfa00 00000000`00000000 : nt!IoRemoveIoCompletion+0x82
    ffffd000`203cf870 fffff802`a1dd2a63 : fffff6fb`40001d08 fffff680`003a1d78 ffff504a`eece1c5c 00000000`00000000 : nt!NtWaitForWorkViaWorkerFactory+0x303
    ffffd000`203cfa90 00007ff9`eeab538a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`203cfb00)
    00000000`049eea78 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtWaitForWorkViaWorkerFactory+0xa

So I note that there is 2 stacks for 2 threads as I see in Olly previously. as you can see :

    Stack Init ffffd00025d59c90 Current ffffd00025d59480
    Stack Init ffffd000203cfc90 Current ffffd000203cf420

So I imagine that I am at the process Virtual Address so I run the debuggee (press g) and edit both start and end of stacks via Olly in guest machine. Then break the guest machine again and do a dc to see the memories in that regions like :

    dc ffffd00025d59c90 
    dc ffffd000203cfc90

but I cannot see any changes (that I made in Stacks by Olly) !

So my questions are:

  • How can I get the address where myfile.exe mapped in memory (From Windbg in host machine) ?
  • What's wrong that I cannot see the changes that I made in olly in Windbg ?(I think Windbg gives me wrong information about Stack Init.)

Note : myfile.exe is a 32-bit program that runs under a 64-bit Windows 10 gust machine and the host machine is also a 64-bit Windows 10.

Update 1 : I edit the content of stack in olly. Both start of stack and end of stack.

Improve this question
2
  • It's not quite clear from your explanation, do you edit the content of the stack or the location of the stack from olly?
    – NirIzr
    Commented Mar 26, 2017 at 14:33
  • @NirIzr I edit the content of stack in olly.
    – Sina Karvandi
    Commented Mar 26, 2017 at 14:54

1 Answer 1

Reset to default
1

the stack you see in !process @$proc 7 is kernel stack not usermode stack

if you want to see usermode stack use 0x17 flag

whatever you edit in usermode would only be available in address that belongs to usermode stack that is address less that 0x80000000 normally

here is a calc.exe stack in kernel mode debugger 

kd> !process 0 17 calc.exe
Failed to get VAD root
PROCESS 811c3500  SessionId: 0  Cid: 0560    Peb: 7ffd7000  ParentCid: 00a8
    DirBase: 01cc4000  ObjectTable: e1a63450  HandleCount:  28.
    Image: calc.exe
    VadRoot 00000000 Vads 0 Clone 0 Private 115. Modified 0. Locked 0.
    DeviceMap e1a2ed30
    Token                             e1c22270
    ElapsedTime                       00:00:06.709
    UserTime                          00:00:00.030
    KernelTime                        00:00:00.060
    QuotaPoolUsage[PagedPool]         0
    QuotaPoolUsage[NonPagedPool]      0
    Working Set Sizes (now,min,max)  (644, 50, 345) (2576KB, 200KB, 1380KB)
    PeakWorkingSetSize                644
    VirtualSize                       27 Mb
    PeakVirtualSize                   34 Mb
    PageFaultCount                    669
    MemoryPriority                    FOREGROUND
    BasePriority                      8
    CommitCharge                      187

        THREAD 810efda8  Cid 0560.0564  Teb: 7ffdf000 Win32Thread: e1a631d0 WAIT: (WrUserRequest) UserMode Non-Alertable
            ffafbb00  SynchronizationEvent
        Not impersonating
        DeviceMap                 e1a2ed30
        Owning Process            00000000       Image:         
        Attached Process          811c3500       Image:         calc.exe
        Wait Start TickCount      6064           Ticks: 23 (0:00:00:00.230)
        Context Switch Count      164            IdealProcessor: 0                 LargeStack
        UserTime                  00:00:00.020
        KernelTime                00:00:00.060
        Win32 Start Address calc!WinMainCRTStartup (0x01012475)
        Stack Init f8bc2000 Current f8bc1c20 Base f8bc2000 Limit f8bbd000 Call 00000000
        Priority 12 BasePriority 8 PriorityDecrement 2 IoPriority 0 PagePriority 0

        ChildEBP RetAddr  Args to Child              
        f8bc1c38 804dc0f7 810efe18 810efda8 804dc143 nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
        f8bc1c44 804dc143 000025ff e1a631d0 00000000 nt!KiSwapThread+0x46 (FPO: [0,0,0])
        f8bc1c6c bf802f52 00000001 0000000d 00000001 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
        f8bc1ca8 bf801b2a 000025ff 00000000 00000001 win32k!xxxSleepThread+0x192 (FPO: [Non-Fpo])
        f8bc1cec bf819e6c f8bc1d18 000025ff 00000000 win32k!xxxRealInternalGetMessage+0x418 (FPO: [Non-Fpo])
        f8bc1d4c 804de7ec 0007fee8 00000000 00000000 win32k!NtUserGetMessage+0x27 (FPO: [Non-Fpo])
        f8bc1d4c 7c90e4f4 0007fee8 00000000 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f8bc1d64)
        0007fddc 7e4191be 7e4191f1 0007fee8 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
        0007fdfc 010021b0 0007fee8 00000000 00000000 USER32!NtUserGetMessage+0xc
        0007ff1c 010125e9 000a8aa8 00000055 000a8aa8 calc!WinMain+0x25f (FPO: [Non-Fpo])
        0007ffc0 7c817067 80000001 0144da28 7ffd7000 calc!WinMainCRTStartup+0x174 (FPO: [Non-Fpo])
        0007fff0 00000000 01012475 00000000 78746341 kernel32!BaseProcessStart+0x23 (FPO: [Non-Fpo])

ie the usermode stack part in above paste is at 

kd> dc 0007fddc
0007fddc  ???????? ???????? ???????? ????????  ????????????????
0007fdec  ???????? ???????? ???????? ????????  ????????????????
0007fdfc  ???????? ???????? ???????? ????????  ????????????????
0007fe0c  ???????? ???????? ???????? ????????  ????????????????
0007fe1c  ???????? ???????? ???????? ????????  ????????????????
0007fe2c  ???????? ???????? ???????? ????????  ????????????????
0007fe3c  ???????? ???????? ???????? ????????  ????????????????
0007fe4c  ???????? ???????? ???????? ????????  ????????????????

kd> .process /p /r 811c3500
Implicit process is now 811c3500
.cache forcedecodeuser done
Loading User Symbols
.....................



kd> dc 0007fddc
0007fddc  00000000 7e4191be 7e4191f1 0007fee8  ......A~..A~....
0007fdec  00000000 00000000 00000000 7e4191c6  ..............A~
0007fdfc  0007ff1c 010021b0 0007fee8 00000000  .....!..........
0007fe0c  00000000 00000000 7c80b731 000a232f  ........1..|/#..
0007fe1c  00000000 00000000 00000000 00000000  ................
0007fe2c  00000000 00000000 00000000 00000000  ................
0007fe3c  00000000 00000000 00000000 00000000  ................
0007fe4c  00000000 00000000 00000000 00000000  ................

you can see the edits done in ollydbg reflecting in kd on proper process context in user mode stack (make sure you dont edit message loops they are repeatedly called and overwritten on each call )

enter image description here

Improve this answer
4
  • Wow ! Yeah it works ... thank you for your example but one another question, would you please tell me is there any way to understand what is the physical address that you edit ?(because in your example you edit memory with a virtual address.)
    – Sina Karvandi
    Commented Mar 28, 2017 at 18:40
  • 2
    not sure your question makes sense you are editing in usermode and usermode doesnt have a concept of physical address it is virtual address space only
    – blabb
    Commented Mar 28, 2017 at 18:46
  • how did you get 0007fddc from the previous output?
    – AK_
    Commented Feb 16, 2022 at 22:22
  • @AK_ look at stack where the transition happens the last usermode call KiFast....ret and the first kmode call ntKifastcallentry the stack address is 7fddc the first address pritor to trapframe
    – blabb
    Commented Feb 17, 2022 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.