eb (enter values) command query in kd

raj_r · September 16, 2006, 3:05pm

how does changing a byte with
eb eip “VALUE”
work

does it write to memory only ? so that the next time i restart the old
values still exist
or does it change it permanently in file ? (i hope not)

especially when using it in kd on a user mode process ??

i noticed the hard coded int3 being erased earlier but didnt give it a
second though few days ago

today i was again poking with windbg and winmine with kd and i notice if
i do

eb eip 0x55 in kd

it seems to permenantly write back to file

but doing a fc /b on guest shows the file is same

is it a problem of some cache memory ?? or am i seeing ghosts (due to lack
of sleep)

anyway here is the information

C:\Documents and Settings\Administrator\Desktop>dir /b
winmine.bak
winmine.exe
Copy of winmine.exe

C:\Documents and Settings\Administrator\Desktop>fc /b winmine.exe “copy of
winmi
ne.exe”
Comparing files winmine.exe and COPY OF WINMINE.EXE
FC: no differences encountered <-------------------

C:\Documents and Settings\Administrator\Desktop>

C:\PROGRA~1\DEBUGG~1>tlist

676 cmd.exe C:\WINNT\system32\cmd.exe - tlist
720 Copy of winmine Minesweeper
92 winmine.exe Minesweeper
812 tlist.exe

C:\PROGRA~1\DEBUGG~1>

kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****

<----------------- snip-------------------->

PROCESS ffaf8360 SessionId: 0 Cid: 02a4 Peb: 7ffdf000 ParentCid: 00c8
DirBase: 01b8c000 ObjectTable: ffb29ce8 TableSize: 21.
Image: cmd.exe

PROCESS ffb6d020 SessionId: 0 *Cid: 02d0 === 720* Peb: 7ffdf000
ParentCid: 00c8
DirBase: 024f5000 ObjectTable: ffaea548 TableSize: 22.
Image: Copy of winmine

PROCESS ffadf400 SessionId: 0 *Cid: 005c == 92* Peb: 7ffdf000
ParentCid: 00c8
DirBase: 00b52000 ObjectTable: ffade208 TableSize: 22.
Image: winmine.exe

kd> .process /p /r ffadf400
Implicit process is now ffadf400
.cache forcedecodeuser done
Loading User Symbols
…
kd> u 1003dd0
winmine!WinMainCRTStartup:
01003dd0 55 push ebp <---------------- this should be int3
and it should break every time i double click this file

but that doesnt seem to be the case ( i had earlier use eb eip 0x55 on this
image three four sessions back

and it seems this 0x55 is etched/blocked somewhere in memory or im doing
something thats extermely wrong

the other copy breaks everytime i double click it in guest

i had quit windbg with q making the guest freeze and restarted windbg so
that it starts up new

but it still has the edited byte see below this i have the disassembly of
the copy and it has the hardcoded int3

intact

either fc is bluffing or or my eyes are bluffing or windbg is bluffing hope
some one could help me find the

lier

01003dd1 8bec mov ebp,esp
01003dd3 6aff push 0FFFFFFFFh
01003dd5 68c0130001 push offset winmine!`string’+0x8 (010013c0)
01003dda 68d03f0001 push offset winmine!_except_handler3 (01003fd0)
01003ddf 64a100000000 mov eax,dword ptr fs:[00000000h]
01003de5 50 push eax
01003de6 64892500000000 mov dword ptr fs:[0],esp
kd> .process /p /r ffb6d020
Implicit process is now ffb6d020
.cache forcedecodeuser done
Loading User Symbols
…
kd> u 1003dd0
*** ERROR: Module load completed but symbols could not be loaded for Copy of
winmine.exe
Copy_of_winmine+0x3dd0:
01003dd0 cc int 3 <----------------------
01003dd1 8bec mov ebp,esp
01003dd3 6aff push 0FFFFFFFFh
01003dd5 68c0130001 push offset Copy_of_winmine+0x13c0 (010013c0)
01003dda 68d03f0001 push offset Copy_of_winmine+0x3fd0 (01003fd0)
01003ddf 64a100000000 mov eax,dword ptr fs:[00000000h]
01003de5 50 push eax
01003de6 64892500000000 mov dword ptr fs:[0],esp

regards

raj_r

raj_r · September 16, 2006, 3:20pm

if i restart the guest the executables become normal again

kd> g
Break instruction exception - code 80000003 (first chance)
Copy_of_winmine+0x3dd0:
001b:01003dd0 cc int 3
kd> g
Waiting for all contexts to be flushed
RTL: RtlNtStatusToDosError(0x80000023): No Valid Win32 Error Mapping
RTL: Edit ntos\rtl\generr.c to correct the problem
RTL: ERROR_MR_MID_NOT_FOUND is being returned
LSA AU: DeRregisterLogonProcess Failed 0xc00002fe
Shutdown occurred…unloading all symbol tables.
Waiting to reconnect…
Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: srv*D:\Borland\debugsymbols*http://msdl.microsoft.com/download/symbols;SRV\*D:\Borland\odbg110\symbols\*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e1b8
System Uptime: not available
Fips device driver loaded successfully
Fips driver locked into memory
Fips driver unlocked from memory
Break instruction exception - code 80000003 (first chance)
001b:01003dd0 cc int 3
kd> g
Break instruction exception - code 80000003 (first chance)
001b:01003dd0 cc int 3
kd> g

so once i edit some value in kd i shouldnt rely on it to become normal till i reboot and reconnect ?
that is i exit the image and restart the image i cant hope that a hardcoded int3 will remain intact ?

Tim_Roberts · September 18, 2006, 12:37pm

raj_r wrote:

how does changing a byte with
eb eip “VALUE”
work

It changes one byte in virtual memory. If that byte happens to be in an
executable file, the file is mapped in memory with
PAGE_EXECUTE_WRITECOPY, which means that when you write to a page, it
replaces the mapped page with a scratch page and does the write there.
The “eb” command will not change an executable image on disk.

That page will continue to live until the last handle to the executable
is closed. At that point, the modified page is freed. The next time
the executable is reloaded, it will of course have the original value.

today i was again poking with windbg and winmine with kd and i
notice if i do
eb eip 0x55 in kd
it seems to permenantly write back to file
but doing a fc /b on guest shows the file is same

Well, then, what leads you to think that the file is being modified?

C:\PROGRA~1\DEBUGG~1>tlist

676 cmd.exe C:\WINNT\system32\cmd.exe - tlist
720 Copy of winmine Minesweeper
92 winmine.exe Minesweeper
812 tlist.exe

C:\PROGRA~1\DEBUGG~1>

kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****

<----------------- snip-------------------->

PROCESS ffaf8360 SessionId: 0 Cid: 02a4 Peb: 7ffdf000 ParentCid:
00c8
DirBase: 01b8c000 ObjectTable: ffb29ce8 TableSize: 21.
Image: cmd.exe

PROCESS ffb6d020 SessionId: 0 *Cid: 02d0 === 720* Peb: 7ffdf000
ParentCid: 00c8
DirBase: 024f5000 ObjectTable: ffaea548 TableSize: 22.
Image: Copy of winmine

PROCESS ffadf400 SessionId: 0 *Cid: 005c == 92* Peb: 7ffdf000
ParentCid: 00c8
DirBase: 00b52000 ObjectTable: ffade208 TableSize: 22.
Image: winmine.exe

kd> .process /p /r ffadf400
Implicit process is now ffadf400
.cache forcedecodeuser done
Loading User Symbols
…
kd> u 1003dd0
winmine!WinMainCRTStartup:
01003dd0 55 push ebp <---------------- this should
be int3 and it should break every time i double click this file

Why do you think this should be an int 3? The stock copy of winmine.exe
certainly does not have a hardcoded interrupt at itsmain entry point.
How would the “int 3” get there?

but that doesnt seem to be the case ( i had earlier use eb eip 0x55
on this image three four sessions back
and it seems this 0x55 is etched/blocked somewhere in memory or im
doing something thats extermely wrong
the other copy breaks everytime i double click it in guest
i had quit windbg with q making the guest freeze and restarted windbg
so that it starts up new

WHAT “guest”? Are you running a virtualizer?

either fc is bluffing or or my eyes are bluffing or windbg is
bluffing hope some one could help me find the lier

kd> u 1003dd0
*** ERROR: Module load completed but symbols could not be loaded for
Copy of winmine.exe
Copy_of_winmine+0x3dd0:
01003dd0 cc int 3 <----------------------
01003dd1 8bec mov ebp,esp
01003dd3 6aff push 0FFFFFFFFh
01003dd5 68c0130001 push offset Copy_of_winmine+0x13c0 (010013c0)
01003dda 68d03f0001 push offset Copy_of_winmine+0x3fd0 (01003fd0)
01003ddf 64a100000000 mov eax,dword ptr fs:[00000000h]
01003de5 50 push eax
01003de6 64892500000000 mov dword ptr fs:[0],esp

This is an entirely different executable, called “Copy of winmine.exe”.
If you modified “Copy of winmine.exe” to patch in an
“int 3” at the entry point, why would you expect it to affect a file
called “winmine.exe”?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

raj_r · September 18, 2006, 1:16pm

On 9/18/06, Tim Roberts wrote:
>
>
> That page will continue to live until the last handle to the executable
> is closed. At that point, the modified page is freed. The next time
> the executable is reloaded, it will of course have the original value.

yes that’s what i was thinking but maybe minewine has some leaks or
something that doesn’t allow it to be freed

i exited winmine and restarted winmine several times so if it had freed the
modified scratch page it should have the original value (which was int3 to
start with which i embedded in its entry using a hex editor it is not stock
winmine and this application resides in my virtual PCs desktop not in
default %WINDIR%\system32

| >Why do you think this should be an int 3? The stock copy of winmine.exe
| >certainly does not have a hard coded interrupt at its main entry point.
| > How would the “int 3” get there?

they are both same both has embedded int3 in its $exentry
i modified them like that so that i can make them break in kd

WHAT “guest”? Are you running a virtualizer?

w2ksp4 on vpc2004 sp1
wxpsp2 as host

This is an entirely different executable, called “Copy of winmine.exe”.
If you modified “Copy of winmine.exe” to patch in an
“int 3” at the entry point, why would you expect it to affect a file
called “winmine.exe”?

yes its a different executable (just by its name) otherwise both of them are
same
and both has an int3 embedded by me and one was modified from kd
using eb eip 0x55 during a session and after i mucked up with that
i closed the winmine in vpc (game ->exit / alt+f4 / clicking on the x in
right top corner all of the above combinations several times )

and restarting it wasn’t breaking in kd like i hoped it should but was
running gleefully
without problems
so i was wondering where the int3 has gone and made another copy of it
but didn’t modify the int3 but dismissed it with g from kd when it broke
and the second copy runs too
(i believe it should NOT run but crash but that’s for another post or
another question)

raj_r · September 19, 2006, 2:46pm

i thought let me try some other executable and see if the problem persists

so i cooked up one

the problem seems to be same.
after editing a byte from kd once
it seems the memory holds the same value till i reboot the vpc

the test .exe compiled with vc2005 express
cl test.c

output from cmd.exe inside vpc

=============================================================================

C:\>cd %userprofile%\desktop\test

C:\Documents and Settings\Administrator\Desktop\test>dir
Volume in drive C has no label.
Volume Serial Number is 0B24-0BF0

Directory of C:\Documents and Settings\Administrator\Desktop\test

09/19/2006 03:51a

.
09/19/2006 03:51a ..
09/18/2006 03:10p 128 test.c
09/18/2006 03:11p 662 test.obj
09/18/2006 03:11p 53,248 test.exe
09/18/2006 03:11p 53,248 testmodone.bak
09/18/2006 03:11p 53,248 testmodtwo.bak
09/18/2006 03:15p 53,248 testmodone.exe
09/18/2006 03:16p 53,248 testmodtwo.exe
7 File(s) 267,030 bytes
2 Dir(s) 16,152,567,808 bytes free

C:\Documents and Settings\Administrator\Desktop\test>test
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>test
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>test
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>testmodtwo
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>testmodtwo
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>testmodtwo
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>testmodtwo
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>testmodtwo
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>type test.c
#include
int main(void)
{
printf("hello hello mike testing 1 2 3 tut tut tut\n");
return 1;
}

C:\Documents and Settings\Administrator\Desktop\test>test
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>testmodtwo
hello hello mike testing 1 2 3 tut tut tut

C:\Documents and Settings\Administrator\Desktop\test>fc /b test.exe
testmodone.e
xe
Comparing files test.exe and TESTMODONE.EXE
000012F7: E8 CC

C:\Documents and Settings\Administrator\Desktop\test>fc /b test.exe
testmodtwo.e
xe
Comparing files test.exe and TESTMODTWO.EXE
000012F7: E8 CC

C:\Documents and Settings\Administrator\Desktop\test>fc /b testmodone.exetestmo
dtwo.exe
Comparing files testmodone.exe and TESTMODTWO.EXE
FC: no differences encountered

C:\Documents and Settings\Administrator\Desktop\test>
===========================================================================

and i kd i set up a break on testmodetwo like this

kd> .printf "%y\n",804a929b
nt!NtCreateProcess+0xa5 (804a929b)
kd> u 804a929b L1
nt!NtCreateProcess+0xa5:
804a929b c22000 ret 20h

kd> bp 804a929b "!process 0 0 testmodtwo.exe;g"

when it's first hit i can get both the breaks

kd> g
PROCESS ffafed60 SessionId: 0 Cid: 0000 Peb: 7ffdf000 ParentCid: 0114
DirBase: 02272000 ObjectTable: ffaf4da8 TableSize: 2.
Image: testmodtwo.exe

Break instruction exception - code 80000003 (first chance)
001b:004012f7 cc int 3 <---------------- yaaaaayyyyy
kd> eb eip 0xe8 <------ i edit here in memory
kd> u eip
004012f7 e8cc230000 call 004036c8
004012fc e940feffff jmp 00401141
00401301 b830c04000 mov eax,40C030h

hit g to make it go its a console mode application so it exits after printf

i execute it again no int3 break :(

kd> g
PROCESS ffafed60 SessionId: 0 Cid: 0000 Peb: 7ffdf000 ParentCid: 0114
DirBase: 02e71000 ObjectTable: ffaf4da8 TableSize: 2.
Image: testmodtwo.exe

PROCESS ffafed60 SessionId: 0 Cid: 0000 Peb: 7ffdf000 ParentCid: 0114
DirBase: 0015e000 ObjectTable: ffaf4da8 TableSize: 2.
Image: testmodtwo.exe

PROCESS ffafed60 SessionId: 0 Cid: 0000 Peb: 7ffdf000 ParentCid: 0114
DirBase: 01233000 ObjectTable: ffaf4da8 TableSize: 2.
Image: testmodtwo.exe

PROCESS ffafed60 SessionId: 0 Cid: 0000 Peb: 7ffdf000 ParentCid: 0114
DirBase: 00bed000 ObjectTable: ffae5c48 TableSize: 2.
Image: testmodtwo.exe

PROCESS ffafed60 SessionId: 0 Cid: 0000 Peb: 7ffdf000 ParentCid: 0114
DirBase: 02e6e000 ObjectTable: ffaf4da8 TableSize: 2.
Image: testmodtwo.exe

the only difference between different executions is the dirbase it seems

can anyone point me in the right direction to understand this phenomenon

a simple answer like yep it will work that way go find some book (name
please) and read through it several times till you understand the process
would also suffice if its supposed to work this way

there are six executions of testmodtwo in cmd window in top

and six breaks on kd below

only the first one knows that there is an int3 all others seem to ignore the
int3

regards

raj_r

raj_r · September 22, 2006, 11:24am

no takers for this question yet

like i posted if the original byte that i modified was a single byte opcode
like
push ebp = 0x55

the execution continues from the next opcode if i do a go from from kernel
debugger

but if it was a multi byte opcode
like the one

004012f7 e8cc230000 call 004036c8

if i change a single byte for example
0xe8 to 0xcc (int3)

it leaves behind a reference to a data address cc2300000
and if i do go from kd
it breaks again in kernel debugger trying to execute that oxcc as an int3
and then the original application
crashes fine in vpc and te AeDebug windbg in vpc is able to catch it with
access violation trying to execute some bogus
and [ebx+##]

so dismissing an int3 hard breaks from kd seems to start executing from the
next eip
that’s available

this still leaves the question open could some one at least tell if this
behaviour is consistent on other vms or real two pc debugging may be it
could be a problem of vpc and not windbg or kd ?

regards

raj_r

OSR_Community_User · September 22, 2006, 1:16pm

I’m not sure I understand the question being asked. Are you asking
about how you can tell what instructions will be executed? If you
unassemble the code with ‘u’ it will show you what instructions are
going to get executed. If you manually modify the code stream you will
modify the instructions that will be executed. A new ‘u’ command will
show you what the new instructions are. From the behavior you describe
below it sounds like everything is working properly, I don’t think you
have a problem with your VM.

Alternately, are you asking if your manual edit of the code should be
ignored? The answer is no, when you modify the code stream you change
what is going to get executed.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Friday, September 22, 2006 8:24 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] eb (enter values) command query in kd

no takers for this question yet

like i posted if the original byte that i modified was a single byte
opcode like
push ebp = 0x55

the execution continues from the next opcode if i do a go from from
kernel debugger

but if it was a multi byte opcode
like the one

004012f7 e8cc230000 call 004036c8

if i change a single byte for example
0xe8 to 0xcc (int3)

it leaves behind a reference to a data address cc2300000
and if i do go from kd
it breaks again in kernel debugger trying to execute that oxcc as an
int3
and then the original application
crashes fine in vpc and te AeDebug windbg in vpc is able to catch it
with access violation trying to execute some bogus
and [ebx+##]

so dismissing an int3 hard breaks from kd seems to start executing from
the next eip
that’s available

this still leaves the question open could some one at least tell if this
behaviour is consistent on other vms or real two pc debugging may be it
could be a problem of vpc and not windbg or kd ?

regards

raj_r

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Skywing · September 22, 2006, 2:46pm

I think that this is what the expected behavior is - there is no special magic to hide the effects of the instruction opcode patching if you use eb' or other direct memory modification commands as opposed to setting a breakpoint via bp’.

You can think of eb as just doing a `memcpy’ in the targets address space - there is no magic to undo the copying.

Note that, as far as I remember, doing writes with kd on copy on write pages may not behave quite as you expect, as the underlying physical memory backing the VM may be modified with invoking the copy on write behavior. Logically, kd-invoked writes cannot copy on write because you are allowed to perform writes at high irqls where the paging system cannot run to do things like allocate a page to substitute for the original one on a COW operation.

There are some hints about this kind of behavior in the documentation for `!ubp’, where it states that changes may be reflected across all processes. So, what it comes down to, is that COW does not behave as you might expect when you write to memory with kd.

–
Ken Johnson (Skywing)
Windows SDK MVP

“raj_r” wrote in message news:xxxxx@windbg…
no takers for this question yet

like i posted if the original byte that i modified was a single byte opcode like
push ebp = 0x55

the execution continues from the next opcode if i do a go from from kernel debugger

but if it was a multi byte opcode
like the one

004012f7 e8cc230000 call 004036c8

if i change a single byte for example
0xe8 to 0xcc (int3)

it leaves behind a reference to a data address cc2300000
and if i do go from kd
it breaks again in kernel debugger trying to execute that oxcc as an int3
and then the original application
crashes fine in vpc and te AeDebug windbg in vpc is able to catch it with access violation trying to execute some bogus
and [ebx+##]

so dismissing an int3 hard breaks from kd seems to start executing from the next eip
that’s available

this still leaves the question open could some one at least tell if this behaviour is consistent on other vms or real two pc debugging may be it could be a problem of vpc and not windbg or kd ?

regards

raj_r

raj_r · September 22, 2006, 2:52pm

let me rephrase the question again

i compile this code

#include<stdio.h>

int main(void)
{
printf(“hello world\n”);
return 0;
}

load the resulting exe in a hexeditor and insert a 0xcc (int3)
in winmainCRTStartup() and save the exe

executing the modified exe results in a break on the kerneldebugger

so far so fine

in the kernel debugger i modify the byte back to its original
opcode that i modified and ask kernel debugger to resume
execution by typing g GO

the application runs ok prints the string and exits

now if i reexecute the modified exe again whether it should break again in
kd or not ??

i believe it should break again but that doesnt seem to be the case

every reexecution till i reboot the vpc never breaks in kd

but if i reboot the vpc and execute again it breaks in kd
for the first execution not over subsequent executions

hope i explained it well</stdio.h>

Skywing · September 22, 2006, 3:53pm

I would guess that this is due to the copy on write behavior I described earlier (or lack whereof, when used with kd). When you modify the memory with kd you are modifying the underlying physical pages backing the image section and not modfiying a copy. When you run the program a second time, I suspect that the cache manager is being clever and reusing an already existing section object in memory and expecting that everything will work as expected. Normally, this is fine, but you are “breaking the rules” a bit by writing to the underlying physical pages without triggering the copy logic with kd. If you used a conventional means to modify the memory, I suspect the problem will go away.

–
Ken Johnson (Skywing)
Windows SDK MVP

“raj_r” wrote in message news:xxxxx@windbg…
let me rephrase the question again

i compile this code

#include<stdio.h>

int main(void)
{
printf(“hello world\n”);
return 0;
}

load the resulting exe in a hexeditor and insert a 0xcc (int3)
in winmainCRTStartup() and save the exe

executing the modified exe results in a break on the kerneldebugger

so far so fine

in the kernel debugger i modify the byte back to its original
opcode that i modified and ask kernel debugger to resume
execution by typing g GO

the application runs ok prints the string and exits

now if i reexecute the modified exe again whether it should break again in kd or not ??

i believe it should break again but that doesnt seem to be the case

every reexecution till i reboot the vpc never breaks in kd

but if i reboot the vpc and execute again it breaks in kd
for the first execution not over subsequent executions

hope i explained it well</stdio.h>

raj_r · September 22, 2006, 4:26pm

On 9/23/06, Skywing wrote:
>
> I would guess that this is due to the copy on write behavior I described
> earlier (or lack whereof, when used with kd). When you modify the memory
> with kd you are modifying the underlying physical pages backing the image
> section and not modfiying a copy.
>

thanks Skywing i posted my reply before reading your earlier post so i
didnt comment anything about it earlier

When you run the program a second time, I suspect that the cache manager is
> being clever and reusing an already existing section object in memory and
> expecting that everything will work as expected.
>

doesnt the application take with it all the resources that it allocated
when exiting ? thats what i was wondering right from start is there some
cache somewhere thats being put to use later too
basically i wanted to break into kd from an user mode application
so i embedded an int3 and when it broke i changed it back (used eb for that)
after poking around and managing to crash the application in vpc
i thought let me start from scratch once again but i could not start from
scratch again because of the afore mentioned phenomenon

and after rebooting i still could manage to start from scratch only once
so was trying to find how this is supposed to work

the above phenomenon doesnt seem to be the case if i am purely doing
user mode (with windbg -I setting windbg as postmortem debugger)

i can do eb eip 0x## as many times as i want and reexecuting always
gets trapped by the AeDedug debugger

(a8c.a98): Break instruction exception - code 80000003 (!!! second chance
!!!)
(620.ffc): Break instruction exception - code 80000003 (!!! second chance
!!!)

Normally, this is fine, but you are “breaking the rules” a bit by writing
> to the underlying physical pages without triggering the copy logic with kd.
> If you used a conventional means to modify the memory, I suspect the problem
> will go away.
>

could you eloberate the usage of conventional means ?
like how i could force a modification from kd without having to reboot
everytime ?

thanks a lot for giving me some pointers to look up

regards

raj_r

OSR_Community_User · September 22, 2006, 4:42pm

The key is that modifying memory from kd is, as Skywing mentioned, not a
normal kind of OS-mediated activity. Instead it’s more of a direct
modification and may not go through all of the mechanisms that might
occur with a fully OS-backed write. User-mode code is almost always
marked copy-on-write, where a new page is created with a copy of the
original read-only data, then that new page is modified and used in
place of the original. This allows an on-disk image to be shared among
many processes while still allowing those processes to make local
changes. Changes are not permanent since the COW pages are not written
back. kd writes, again as Skywing mentioned, can’t do any of the
paging/page-table operations this requires since the OS is suspended,
thus their behavior is different.

In kd, if you unassemble the routine that you modified when you
reexecute the application do you see the 0xcc or the modified data? If
you see modified data then you are seeing the file caching behavior
Skywing mentioned.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Friday, September 22, 2006 1:26 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] eb (enter values) command query in kd

On 9/23/06, Skywing wrote:

I would guess that this is due to the copy on write behavior I
described earlier (or lack whereof, when used with kd). When you modify
the memory with kd you are modifying the underlying physical pages
backing the image section and not modfiying a copy.

thanks Skywing i posted my reply before reading your earlier post so i
didnt comment anything about it earlier

When you run the program a second time, I suspect that the cache
manager is being clever and reusing an already existing section object
in memory and expecting that everything will work as expected.

doesnt the application take with it all the resources that it allocated
when exiting ? thats what i was wondering right from start is there some
cache somewhere thats being put to use later too
basically i wanted to break into kd from an user mode application
so i embedded an int3 and when it broke i changed it back (used eb for
that)
after poking around and managing to crash the application in vpc
i thought let me start from scratch once again but i could not start
from scratch again because of the afore mentioned phenomenon

and after rebooting i still could manage to start from scratch only once

so was trying to find how this is supposed to work

the above phenomenon doesnt seem to be the case if i am purely doing
user mode (with windbg -I setting windbg as postmortem debugger)

i can do eb eip 0x## as many times as i want and reexecuting always
gets trapped by the AeDedug debugger

(a8c.a98): Break instruction exception - code 80000003 (!!! second
chance !!!)
(620.ffc): Break instruction exception - code 80000003 (!!! second
chance !!!)

Normally, this is fine, but you are “breaking the rules” a bit
by writing to the underlying physical pages without triggering the copy
logic with kd. If you used a conventional means to modify the memory, I
suspect the problem will go away.

could you eloberate the usage of conventional means ?
like how i could force a modification from kd without having to reboot
everytime ?

thanks a lot for giving me some pointers to look up

regards

raj_r

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · September 22, 2006, 4:55pm

Instead of hex editing your binaries, you might have more success getting
your work done if you tell us what you really want to do. If you just want
to catch a UM breakpoint in the kernel debugger, I think adding the:

__debugbreak();

intrinsic would probably be sufficient, since that’s a portable way to do
exactly what you are trying to do with all your goofing around with hex
editing and eb. When you hit it, simply step over it.

Phil

Philip D. Barila

Seagate Technology LLC

(720) 684-1842

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r

Sent: Friday, September 22, 2006 2:26 PM

To: “Kernel Debugging Interest List”

Subject: Re: [windbg] eb (enter values) command query in kd

On 9/23/06, Skywing wrote:

I would guess that this is due to the copy on write behavior I
described earlier (or lack whereof, when used with kd). When you modify
the memory with kd you are modifying the underlying physical pages backing
the image section and not modfiying a copy.

thanks Skywing i posted my reply before reading your earlier post so i
didnt comment anything about it earlier

When you run the program a second time, I suspect that the cache
manager is being clever and reusing an already existing section object in
memory and expecting that everything will work as expected.

doesnt the application take with it all the resources that it allocated

when exiting ? thats what i was wondering right from start is there some
cache somewhere thats being put to use later too

basically i wanted to break into kd from an user mode application

so i embedded an int3 and when it broke i changed it back (used eb for
that)

after poking around and managing to crash the application in vpc

i thought let me start from scratch once again but i could not start from
scratch again because of the afore mentioned phenomenon

and after rebooting i still could manage to start from scratch only once

so was trying to find how this is supposed to work

the above phenomenon doesnt seem to be the case if i am purely doing

user mode (with windbg -I setting windbg as postmortem debugger)

i can do eb eip 0x## as many times as i want and reexecuting always

gets trapped by the AeDedug debugger

(a8c.a98): Break instruction exception - code 80000003 (!!! second chance
!!!)

(620.ffc): Break instruction exception - code 80000003 (!!! second chance
!!!)

Normally, this is fine, but you are “breaking the rules” a bit by
writing to the underlying physical pages without triggering the copy logic
with kd. If you used a conventional means to modify the memory, I suspect
the problem will go away.

could you eloberate the usage of conventional means ?

like how i could force a modification from kd without having to reboot
everytime ?

thanks a lot for giving me some pointers to look up

regards

raj_r

— You are currently subscribed to windbg as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Tim_Roberts · September 22, 2006, 5:36pm

Skywing wrote:

I would guess that this is due to the copy on write behavior I
described earlier (or lack whereof, when used with kd). When you
modify the memory with kd you are modifying the underlying physical
pages backing the image section and not modfiying a copy. When you
run the program a second time, I suspect that the cache manager is
being clever and reusing an already existing section object in memory
and expecting that everything will work as expected. Normally, this
is fine, but you are “breaking the rules” a bit by writing to the
underlying physical pages without triggering the copy logic with kd.

I don’t believe that. I have often used WinDbg on user-mode apps, and I
have never seen my changes persist.

Mr. raj_r has not repeated the extremely important point that he is
debugging into a Virtual PC. My suspicion is that he is simply
encountering a bug in the copy-on-write handling in VirtualPC – a case
of overaggressive caching.

If you used a conventional means to modify the memory, I suspect the
problem will go away.

What do you mean by “conventional means”?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

raj_r · September 23, 2006, 3:57am

On 9/22/06, Drew Bliss wrote:
>
> In kd, if you unassemble the routine that you modified when you reexecute
> the application do you see the 0xcc or the modified data? If you see
> modified data then you are seeing the file caching behavior Skywing
> mentioned.
>

after i reexecute it doesnt break so i havent had a chance yet to
disassemble it and see if it has 0xcc or modified byte
if i break on nt!NtCreateProcess return i cant get it to disassemble

if i use ctrl+break and then disassemble the running application
by doing !process 0 0 App
.process /p /r EPROCESS

and disassemble i see the modified byte and not 0xcc

==================================
kd> u 1003dd0
winmine!WinMainCRTStartup:
01003dd0 55 push ebp <---------------- this should be int3
and it should break every time i double click this file

===================================

so i am seeing some cache and like SkyWing and you state
now how to get past this ??

On 9/22/06, xxxxx@seagate.com wrote:

>
> I think adding the:
> __debugbreak();

if i were coding then what you suggest is possible

i am not coding i dont have the source for my hello world program
i want to break in kd without having source so i am modifying the byte
to int3 this does break but to continue execution i have to revert it back
to original and if i revert it back it stays forever till i reboot a
chicken and egg problem i think unsolvable atleast not with my limited
knowledge

On 9/22/06, Tim Roberts wrote:
>
> I don’t believe that. I have often used WinDbg on user-mode apps, and I
> have never seen my changes persist.

well i didnt believe it either till i see it hapening now if you are talking
about windbg as pure windbg running in um and executing um code
the changes arent peristing the behaviour of persistance happens only
if i change it from kernelmode

Mr. raj_r has not repeated the extremely important point that he is
> debugging into a Virtual PC. My suspicion is that he is simply
> encountering a bug in the copy-on-write handling in VirtualPC – a case
> of overaggressive caching.

may be i am not sure and i dont have that kind of knowledge to
try test it or that kind of resources to check the behaviour in various vms
os etc

now if you want to test i can probably provide a simple oneliner app
that has been modifed in its entrypoint with a 0xcc provided you can trust
me to give you a clean application or you have no problems running
unknown binaries from untrusted strangers

or simply code a “hello world”
open the resulting exe in ollydbg
ollydbg should normally stop in peheader->Addr of Entry Point
and the focus normally will be on disassembler window
press ctrl+e
modify the first single byte to 0xcc
right click -> copy to executable
in the new window that pops up
right click -> save file -> give it a new name and
you have an application that when executed will break in kd

you can simply double click it in guest when it broke in kd
modify back to original byte resume kd with g
exit the app in vm
reexecute it and if it wasnt a feature of vpc then it should break again

> If you used a conventional means to modify the memory, I suspect the
> > problem will go away.
>
>
> What do you mean by “conventional means”?
>
sure Skywing i too would like to know about it a little more if you could
reply back with details

well me and my lame questions will never end it seems
thanks again to all of you who spend your valuable time
trying to answer my dumb questions

regards

raj_r

OSR_Community_User · September 25, 2006, 2:22pm

I don’t know that there’s a sure-fire way to get around the file
caching. You could try renaming the file, or copying it or some other
file operation that might force and update from disk.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Saturday, September 23, 2006 12:57 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] eb (enter values) command query in kd

On 9/22/06, Drew Bliss wrote:

In kd, if you unassemble the routine that you modified when you
reexecute the application do you see the 0xcc or the modified data? If
you see modified data then you are seeing the file caching behavior
Skywing mentioned.

after i reexecute it doesnt break so i havent had a chance yet to
disassemble it and see if it has 0xcc or modified byte
if i break on nt!NtCreateProcess return i cant get it to disassemble

if i use ctrl+break and then disassemble the running application
by doing !process 0 0 App
.process /p /r EPROCESS

and disassemble i see the modified byte and not 0xcc

==================================
kd> u 1003dd0
winmine!WinMainCRTStartup:
01003dd0 55 push ebp <---------------- this should be
int3 and it should break every time i double click this file

===================================

so i am seeing some cache and like SkyWing and you state
now how to get past this ??

On 9/22/06, xxxxx@seagate.com
wrote:

I think adding the:
__debugbreak();

if i were coding then what you suggest is possible

i am not coding i dont have the source for my hello world program
i want to break in kd without having source so i am modifying the byte
to int3 this does break but to continue execution i have to revert it
back
to original and if i revert it back it stays forever till i reboot a
chicken and egg problem i think unsolvable atleast not with my limited
knowledge

On 9/22/06, Tim Roberts wrote:

I don’t believe that. I have often used WinDbg on user-mode
apps, and I have never seen my changes persist.

well i didnt believe it either till i see it hapening now if you are
talking about windbg as pure windbg running in um and executing um code

the changes arent peristing the behaviour of persistance happens only
if i change it from kernelmode

Mr. raj_r has not repeated the extremely important point that he
is
debugging into a Virtual PC. My suspicion is that he is simply
encountering a bug in the copy-on-write handling in VirtualPC –
a case
of overaggressive caching.

may be i am not sure and i dont have that kind of knowledge to
try test it or that kind of resources to check the behaviour in various
vms
os etc

now if you want to test i can probably provide a simple oneliner app
that has been modifed in its entrypoint with a 0xcc provided you can
trust me to give you a clean application or you have no problems running

unknown binaries from untrusted strangers

or simply code a “hello world”
open the resulting exe in ollydbg
ollydbg should normally stop in peheader->Addr of Entry Point
and the focus normally will be on disassembler window
press ctrl+e
modify the first single byte to 0xcc
right click -> copy to executable
in the new window that pops up
right click -> save file -> give it a new name and
you have an application that when executed will break in kd

you can simply double click it in guest when it broke in kd
modify back to original byte resume kd with g
exit the app in vm
reexecute it and if it wasnt a feature of vpc then it should break again

> If you used a conventional means to modify the memory, I
suspect the
> problem will go away.

What do you mean by “conventional means”?

sure Skywing i too would like to know about it a little more if you
could reply back with details

well me and my lame questions will never end it seems
thanks again to all of you who spend your valuable time
trying to answer my dumb questions

regards

raj_r

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

raj_r · September 25, 2006, 2:44pm

On 9/25/06, Drew Bliss wrote:
>
> I don’t know that there’s a sure-fire way to get around the file
> caching. You could try renaming the file, or copying it or some other file
> operation that might force and update from disk.
>

well if i make a copy of it and start it again kd breaks on the copy
without problems i ve done that
but there are side effects the symbol engine doesnt know about that
executable it says cant find symbols
i have to use .reload /f /i and use .symopt LOAD_ANYTHING

see below in the last line there are five copies running
i tried to load user symbols for last process it cant

anyway thanks its always better to have something rather than nothing i
think i can script it to load symbols on bp hit i assume
thats better than rebooting

Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e1b8
Debug session time: Tue Sep 26 12:32:43.640 2006 (GMT+5)
System Uptime: 0 days 0:03:24.964
Break instruction exception - code 80000003 (first chance)
01003dd0 cc int 3
kd> eb eip 0x55
kd> g
Break instruction exception - code 80000003 (first chance)
01003dd0 cc int 3
kd> !process -1 0
PROCESS ffac4880 SessionId: 0 Cid: 0388 Peb: 7ffdf000 ParentCid: 0328
DirBase: 01b7c000 ObjectTable: ffab6da8 TableSize: 22.
Image: Copy (2) of win

kd> eb eip 0x55
kd> g
Break instruction exception - code 80000003 (first chance)
01003dd0 cc int 3
kd> !process -1 0
PROCESS ffab8a20 SessionId: 0 Cid: 0108 Peb: 7ffdf000 ParentCid: 0328
DirBase: 00ddb000 ObjectTable: ffac3668 TableSize: 22.
Image: Copy (3) of win

kd> eb eip 0x55
kd> g
Break instruction exception - code 80000003 (first chance)
01003dd0 cc int 3
kd> !process -1 0
PROCESS ffab8a20 SessionId: 0 Cid: 0108 Peb: 7ffdf000 ParentCid: 0328
DirBase: 01574000 ObjectTable: ffab7108 TableSize: 22.
Image: Copy (4) of win

kd> eb eip 0x55
kd> g
Break instruction exception - code 80000003 (first chance)
01003dd0 cc int 3
kd> !process -1 0
PROCESS ffab8a20 SessionId: 0 Cid: 0378 Peb: 7ffdf000 ParentCid: 0328
DirBase: 01aa3000 ObjectTable: ffab6bc8 TableSize: 22.
Image: Copy (5) of win

kd> lm
start end module name
80400000 805a3a00 nt (pdb symbols)
d:\borland\debugsymbols\ntoskrnl.pdb\3EE650B31\ntoskrnl.pdb

Unloaded modules:
fb843000 fb868000 kmixer.sys
fbb27000 fbb34000 DMusic.sys
fbb47000 fbb55000 swmidi.sys
fc510000 fc525000 VGA.dll
fc50d000 fc525000 vpc-s3.dll
f9510000 f9519000 redbook.sys
f9768000 f976d000 Cdaudio.SYS
f98bc000 f98bf000 Sfloppy.SYS
kd> .process /p /r ffab8a20
Implicit process is now ffab8a20
.cache forcedecodeuser done
Loading User Symbols
…
*** ERROR: Module load completed but symbols could not be loaded for Copy
(5) of winmine.exe

regards

raj_r