[Inline patching] DbgPrint causes blocking of my VM

NTDEV
1

Hello,

I’m going to explain you my problem that i don’t success to solve for a while…

I am realizing inline patching on the specific function. For that, i put a DbgPrint() call so as to check if my detour function is really called. When i debug step to step, i notice that DebugPrint() function causes a blocking of my VM (probably a BSOD) because (i think) it’s not the rigth address.

Problem occurs inside of my detour function which is placed into a non paged memory.

Below, some piece of code.

  • First, an extract of my function which allows me to put the inline patching:
    VOID PrepareDetourFunction()
    {
    char *actual_function = (char *)MyFunctionToPatch;
    char *non_paged_memory;
    unsigned long detour_address;
    unsigned long reentry_address;
    int i = 0;

char newcode = { 0xEA, 0x44, 0x33, 0x22, 0x11, 0x08, 0x00, 0x90, 0x90, 0x90 };

reentry_address = ((unsigned long)MyFunctionToPatch) + 10;

non_paged_memory = ExAllocatePool(NonPagedPool, 256);

…

}
Note: non_paged_memory pointer corresponds at my_detour_function() address and so points on the memory pool allocated for my_detour_function().

and now, the code which causes my problem, once called:
__declspec(naked) my_detour_function()
{
__asm
{
pushad
pushfd
}
DbgPrint(“YEP:Inline patching occurs…\n”); // <- HERE, problem occurs!!!
__asm
{
popad
popfd
}
…
}

Thanks to WinDbg, i have the following line during the DbgPrint call:
815201d0 add byte ptr [eax],al ds:023:00000023=??
where 0x815201d0 is address of DbgPrint() function inside my_detour_function().
But, i noticed that the rigth address is 0x80500799 (nt!DbgPrint).

Why in my non paged function, i don’t have the right address of DbgPrint() Function? Can you explain me this behaviour and how to sove it?

Thanks for your help.

2

Hi
Right now I am using the build environment which Microsoft has given for
building my kernel mode drivers.
Is there any other IDE for building and debugging? What you are using
actually?

And one more thing for debugging the driver we are using the dbgview
tool to debug the driver messages.
What u are using?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, December 03, 2008 6:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] [Inline patching] DbgPrint causes blocking of my VM

Hello,

I’m going to explain you my problem that i don’t success to solve for a
while…

I am realizing inline patching on the specific function. For that, i put
a DbgPrint() call so as to check if my detour function is really called.
When i debug step to step, i notice that DebugPrint() function causes a
blocking of my VM (probably a BSOD) because (i think) it’s not the rigth
address.

Problem occurs inside of my detour function which is placed into a non
paged memory.

Below, some piece of code.

  • First, an extract of my function which allows me to put the inline
    patching:
    VOID PrepareDetourFunction()
    {
    char *actual_function = (char *)MyFunctionToPatch;
    char *non_paged_memory;
    unsigned long detour_address;
    unsigned long reentry_address;
    int i = 0;

char newcode = { 0xEA, 0x44, 0x33, 0x22, 0x11, 0x08, 0x00, 0x90, 0x90,
0x90 };

reentry_address = ((unsigned long)MyFunctionToPatch) + 10;

non_paged_memory = ExAllocatePool(NonPagedPool, 256);

…

}
Note: non_paged_memory pointer corresponds at my_detour_function()
address and so points on the memory pool allocated for
my_detour_function().

and now, the code which causes my problem, once called:
__declspec(naked) my_detour_function()
{
__asm
{
pushad
pushfd
}
DbgPrint(“YEP:Inline patching occurs…\n”); // <- HERE, problem
occurs!!!
__asm
{
popad
popfd
}
…
}

Thanks to WinDbg, i have the following line during the DbgPrint call:
815201d0 add byte ptr [eax],al ds:023:00000023=??
where 0x815201d0 is address of DbgPrint() function inside
my_detour_function().
But, i noticed that the rigth address is 0x80500799 (nt!DbgPrint).

Why in my non paged function, i don’t have the right address of
DbgPrint() Function? Can you explain me this behaviour and how to sove
it?

Thanks for your help.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

This e-mail has been scanned by Arbitron’s Email Content Service.

3

It seems that we have the same environment working.

I am using DDK (Driver Development Kit), i compile in Windows checked build so as to get information debug.

As debugger, i am using WinDbg so as to doing “step to step”, take an eye on memory location etc… and sometimes to get driver messages, i use dbgview.

4

A call to a function is encoded in ‘relative’ offset form to an import
descriptor. The ‘address’ as you so put it of DbgPrint encoded in the
instruction stream is not the address of DbgPrint at all. It is the EIP
relative offset from the call site to the address of the import thunk.

So if what you did was use a ‘template’ function stub and copy it into
memory somewhere other than where the loader put it, your ‘call’ to DbgPrint
will be wrong.

I can only suggest that you spend more time studying i386 assembly and
architecture and take a good look at what the compiler emits for code before
attempting something like a hot-patch at the entry of a function. You must
ensure that the patch-thunk is either properly relocated when allocated in
the heap or is created with only absolute address references to the
‘external’ targets.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, December 03, 2008 7:54 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] [Inline patching] DbgPrint causes blocking of my VM

Hello,

I’m going to explain you my problem that i don’t success to solve for a
while…

I am realizing inline patching on the specific function. For that, i put a
DbgPrint() call so as to check if my detour function is really called. When
i debug step to step, i notice that DebugPrint() function causes a blocking
of my VM (probably a BSOD) because (i think) it’s not the rigth address.

Problem occurs inside of my detour function which is placed into a non paged
memory.

Below, some piece of code.

  • First, an extract of my function which allows me to put the inline
    patching:
    VOID PrepareDetourFunction()
    {
    char *actual_function = (char *)MyFunctionToPatch;
    char *non_paged_memory;
    unsigned long detour_address;
    unsigned long reentry_address;
    int i = 0;

char newcode = { 0xEA, 0x44, 0x33, 0x22, 0x11, 0x08, 0x00, 0x90, 0x90,
0x90 };

reentry_address = ((unsigned long)MyFunctionToPatch) + 10;

non_paged_memory = ExAllocatePool(NonPagedPool, 256);

…

}
Note: non_paged_memory pointer corresponds at my_detour_function() address
and so points on the memory pool allocated for my_detour_function().

and now, the code which causes my problem, once called:
__declspec(naked) my_detour_function()
{
__asm
{
pushad
pushfd
}
DbgPrint(“YEP:Inline patching occurs…\n”); // <- HERE, problem occurs!!!
__asm
{
popad
popfd
}
…
}

Thanks to WinDbg, i have the following line during the DbgPrint call:
815201d0 add byte ptr [eax],al ds:023:00000023=??
where 0x815201d0 is address of DbgPrint() function inside
my_detour_function().
But, i noticed that the rigth address is 0x80500799 (nt!DbgPrint).

Why in my non paged function, i don’t have the right address of DbgPrint()
Function? Can you explain me this behaviour and how to sove it?

Thanks for your help.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Maybe you guys know how these two subjects are related, but I’m not sure the rest of us do - perhaps
this should be a separate thread. It’s still early, so I may just be missing something, and if so,
please accept my apologies.

As far the original question, the whole thing is really quite sketchy, there’s incomplete code, no
debugging information (!analyze -v ideally), and I’m not sure what to make of ‘(probably a BSOD),’ -
this is pretty much a binary phenomenon - but this is part of the problem, because it will trash
your stack:

__asm
> {
> pushad
> pushfd
> }
> DbgPrint(“YEP:Inline patching occurs…\n”); // <- HERE, problem
> occurs!!!
> __asm
> {
> popad
> popfd
> }

Minimally, I think you need to reverse the ‘pop’ statements. Presently, ignoring all other effects,
you are popping the previously pushed value of EFLAGS from the stack in to whatever register that
‘popad’ populates first (which I think is EDI, but I’m not sure); I’m not really sure what will
happen when you pop the first register pushed by pushad from the stack in to EFLAGS (I think that
means EAX). Some flags are restored and some are not (I don’t remember the specifics), but I think
it safe to say that nothing good will come of this either.

As far as what windbg reports later (not clear where you’re getting that from), it looks like
garbage, which is probably all there is going to be given the stack trashing that I think already
took place; in particular, I believe that this what windbg interprets an opcode of ‘0’ to be, but
I’m not sure:

815201d0 add byte ptr [eax],al ds:023:00000023=??

Fundamentally, as David just mentioned, you’re not encoding the instruction correctly.

If you’re learning or just experimenting, then no worries, but downloading a copy of the Intel
manuals would be a good start.

http://www.intel.com/products/processor/manuals/

There is mounting evidence that my brain is not yet quite working today, so if I’ve overlooked
something, my bad.

mm

Selvan Murasoli wrote:

Hi
Right now I am using the build environment which Microsoft has given for
building my kernel mode drivers.
Is there any other IDE for building and debugging? What you are using
actually?

And one more thing for debugging the driver we are using the dbgview
tool to debug the driver messages.
What u are using?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, December 03, 2008 6:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] [Inline patching] DbgPrint causes blocking of my VM

Hello,

I’m going to explain you my problem that i don’t success to solve for a
while…

I am realizing inline patching on the specific function. For that, i put
a DbgPrint() call so as to check if my detour function is really called.
When i debug step to step, i notice that DebugPrint() function causes a
blocking of my VM (probably a BSOD) because (i think) it’s not the rigth
address.

Problem occurs inside of my detour function which is placed into a non
paged memory.

Below, some piece of code.

  • First, an extract of my function which allows me to put the inline
    patching:
    VOID PrepareDetourFunction()
    {
    char *actual_function = (char *)MyFunctionToPatch;
    char *non_paged_memory;
    unsigned long detour_address;
    unsigned long reentry_address;
    int i = 0;

char newcode = { 0xEA, 0x44, 0x33, 0x22, 0x11, 0x08, 0x00, 0x90, 0x90,
0x90 };

reentry_address = ((unsigned long)MyFunctionToPatch) + 10;

non_paged_memory = ExAllocatePool(NonPagedPool, 256);

…

}
Note: non_paged_memory pointer corresponds at my_detour_function()
address and so points on the memory pool allocated for
my_detour_function().

and now, the code which causes my problem, once called:
__declspec(naked) my_detour_function()
{
__asm
{
pushad
pushfd
}
DbgPrint(“YEP:Inline patching occurs…\n”); // <- HERE, problem
occurs!!!
__asm
{
popad
popfd
}
…
}

Thanks to WinDbg, i have the following line during the DbgPrint call:
815201d0 add byte ptr [eax],al ds:023:00000023=??
where 0x815201d0 is address of DbgPrint() function inside
my_detour_function().
But, i noticed that the rigth address is 0x80500799 (nt!DbgPrint).

Why in my non paged function, i don’t have the right address of
DbgPrint() Function? Can you explain me this behaviour and how to sove
it?

Thanks for your help.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

This e-mail has been scanned by Arbitron’s Email Content Service.

6

@David R. Cattley:
Thanks for your explanation, I am beginning to doubt that my problem came from what you explain clearly.

@MM:
Concerning order of my pop/push intrusction, it is a stupid mistake. I am ashamed! Thank you for the comment.

I am aware that I have not provided all the information for several reasons:

  • I’m not at my project at this time
  • I start in using WinDbg (i am discovering some commands), as in the programming of drivers

Like you say, it would seem that i need intel manual. I am going to take en eye.

Thanks.

7

Why are you trying to do this? What are you doing that you think needs synamically generated code in kernel mode?

I suspect that the first of many problems here is that the compiler generated a relative call to and IAT thunk, and relocating the code breaks that relative call. This assumes that you are copying that code elsewhwre, which is not clear from the limited description that you provided.

Regardless, this seems like a bad approach in general in kernel mode. Why are you trying to do this in the first place? There may be a better way.

? S

-----Original Message-----
From: xxxxx@hotmail.com
Sent: Wednesday, December 03, 2008 06:55
To: Windows System Software Devs Interest List
Subject: [ntdev] [Inline patching] DbgPrint causes blocking of my VM

Hello,

I’m going to explain you my problem that i don’t success to solve for a while…

I am realizing inline patching on the specific function. For that, i put a DbgPrint() call so as to check if my detour function is really called. When i debug step to step, i notice that DebugPrint() function causes a blocking of my VM (probably a BSOD) because (i think) it’s not the rigth address.

Problem occurs inside of my detour function which is placed into a non paged memory.

Below, some piece of code.
- First, an extract of my function which allows me to put the inline patching:
VOID PrepareDetourFunction()
{
char *actual_function = (char *)MyFunctionToPatch;
char *non_paged_memory;
unsigned long detour_address;
unsigned long reentry_address;
int i = 0;

char newcode = { 0xEA, 0x44, 0x33, 0x22, 0x11, 0x08, 0x00, 0x90, 0x90, 0x90 };

reentry_address = ((unsigned long)MyFunctionToPatch) + 10;

non_paged_memory = ExAllocatePool(NonPagedPool, 256);

…

}
Note: non_paged_memory pointer corresponds at my_detour_function() address and so points on the memory pool allocated for my_detour_function().

and now, the code which causes my problem, once called:
__declspec(naked) my_detour_function()
{
__asm
{
pushad
pushfd
}
DbgPrint(“YEP:Inline patching occurs…\n”); // <- HERE, problem occurs!!!
__asm
{
popad
popfd
}
…
}

Thanks to WinDbg, i have the following line during the DbgPrint call:
815201d0 add byte ptr [eax],al ds:023:00000023=??
where 0x815201d0 is address of DbgPrint() function inside my_detour_function().
But, i noticed that the rigth address is 0x80500799 (nt!DbgPrint).

Why in my non paged function, i don’t have the right address of DbgPrint() Function? Can you explain me this behaviour and how to sove it?

Thanks for your help.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

@Ken Johnson:

I am discovering the driver programming in kernel mode environment under Windows OS and i find this more and more interesting. In this context, i decided to develop a small tool which allows to list all files created or opened. For that, I heard about the inline patching to realize a hook on the NtCreateFile() function.

Absolutely, I copy byte by byte to the location of my non paged memory.

Thanks

If you know another ways to do this tool more properly, i am listening.

9

>files created or opened. For that, I heard about the inline patching to realize a hook on the

NtCreateFile() function.

Write a minifilter instead.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

10

Hiya

I have the impression you’re either a student or a self starter learner. So
good on you, and welcome to the nt kernel world - you’ve a long, hard, but
fascintaing journey ahead, if you really have the interest and stamina. You
really should maybe should have a look at like
src\filesys\miniFilter\minispy for the sort of thing you’re interested in
here. By the way - ntdev has a sister called ntfsd which is all about file
systems and filters - so if you’re getting into the file system stack this
for sure is the place for you.

Best Wishes
Lyndon

wrote in message news:xxxxx@ntdev…
> @Ken Johnson:
> [quote]Why are you trying to do this in the first place?[/quote]
> I am discovering the driver programming in kernel mode environment under
> Windows OS and i find this more and more interesting. In this context, i
> decided to develop a small tool which allows to list all files created or
> opened. For that, I heard about the inline patching to realize a hook on
> the NtCreateFile() function.
>
> [quote]This assumes that you are copying that code elsewhwre, which is not
> clear from the limited description that you provided.[/quote]
> Absolutely, I copy byte by byte to the location of my non paged memory.
>
> Thanks
>
> If you know another ways to do this tool more properly, i am listening.
>

11

Don’t do that. As Maxim said, use a file system (mini)filter. Hooking file I/O system services is discouraged, undocumented, unreliable, and it won’t have any hope of catching memory-mapped file I/O (section views).

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, December 04, 2008 4:31 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] [Inline patching] DbgPrint causes blocking of my VM

@Ken Johnson:

I am discovering the driver programming in kernel mode environment under Windows OS and i find this more and more interesting. In this context, i decided to develop a small tool which allows to list all files created or opened. For that, I heard about the inline patching to realize a hook on the NtCreateFile() function.

Absolutely, I copy byte by byte to the location of my non paged memory.

Thanks

If you know another ways to do this tool more properly, i am listening.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

12

@Lyndon J. Clarke:
You are rigth, i am a self starter learner but I have finished my studies (oriented embedded/real time developpement). I note your advices: interest yes i do, stamina i really hope, but it is also necessary to have time for study that.

I did not find place where is located the following repesitory: “src\filesys\miniFilter\minispy” so as to have a look. Can you redirect me, please?

@Ken Johnson:
Ok!

Thanks for your advices.

13

Hi Nicolas

You can find this in the WDK - so if you installed say the 6001.18000 to
default locatio it should be at
C:\WinDDK\6001.18000\src\filesys\miniFilter\minispy

Good luck!
Lyndon

wrote in message news:xxxxx@ntdev…
> @Lyndon J. Clarke:
> You are rigth, i am a self starter learner but I have finished my studies
> (oriented embedded/real time developpement). I note your advices: interest
> yes i do, stamina i really hope, but it is also necessary to have time for
> study that.
>
> I did not find place where is located the following repesitory:
> “src\filesys\miniFilter\minispy” so as to have a look. Can you redirect
> me, please?
>
> @Ken Johnson:
> Ok!
>
> Thanks for your advices.
>
>