Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bedanto” wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
i need the call stack, and procmon does exactly what i want…however, I
cant use it, I need to rereate similar functionality, and i would be obliged
if some one can give me some pointers in that direction
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
> Do you just need the process or the actual call stack of the requesting
> thread?
>
> If you need the stack for debugging purposes you can always see if Process
> Monitor helps, it has an option to show the call stack for the requests.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
> “Bedanto” wrote in message news:xxxxx@ntdev…
> Hi!
>
> Is there a way in Windows Kernel mode to walk the stack something likethe
> debugger kv command? I need to find the originator of an IOCTL call back to
> the actual process who generated it…
>
> B
>
>
>
> —
> 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
>
You might want to look into RtlCaptureStackBackTrace. Note that it doesn’t deal with FPO optimizations AFAIK.
Ken Johnson (Skywing), a regular contributor to this list, has some very good posts about FPO and stack walking on his blog (nynaeve.net) that you might want to check out.
Razvan
— On Tue, 8/4/09, Bedanto wrote:
> i need the call stack, and procmon does
> exactly what i want…however, I cant use it, I need to
> rereate similar functionality, and i would be obliged if
> some one can give me some pointers in that direction
If you are going to use the stack as a form of security, it can be easily spoofed. If you want to walk back all the way into um from the um to km transition, i do not think the rtl api will do that for you
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
From: Bedanto
Sent: Tuesday, August 04, 2009 5:09 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
i need the call stack, and procmon does exactly what i want…however, I cant use it, I need to rereate similar functionality, and i would be obliged if some one can give me some pointers in that direction
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone > wrote:
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.comhttp:</http:>
“Bedanto” > wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
—
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
— 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
“Bedanto” wrote in message news:xxxxx@ntdev…
> i need the call stack, and procmon does exactly what i want…however, I
> cant use it, I need to rereate similar functionality, and i would be
> obliged
> if some one can give me some pointers in that direction
Please note that procmon has an usermode part, besides of the driver.
You can get the process exe file name in your driver.
Why do you need the whole stack? is the driver called from a specific DLL?
–pa
> On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
>
>> Do you just need the process or the actual call stack of the requesting
>> thread?
>>
>> If you need the stack for debugging purposes you can always see if
>> Process
>> Monitor helps, it has an option to show the call stack for the requests.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Consulting Associate
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>>
>>
>> “Bedanto” wrote in message news:xxxxx@ntdev…
>> Hi!
>>
>> Is there a way in Windows Kernel mode to walk the stack something likethe
>> debugger kv command? I need to find the originator of an IOCTL call back
>> to
>> the actual process who generated it…
>>
>> B
>>
>>
>>
>> —
>> 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
>>
>
Without the PDB files of all involved binaries - hardly possible.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Bedanto” wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe debugger kv command? I need to find the originator of an IOCTL call back to the actual process who generated it…
B
yes we expect it to be called from a specific DLL
On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. wrote:
> “Bedanto” wrote in message news:xxxxx@ntdev…
>
>> i need the call stack, and procmon does exactly what i want…however, I
>> cant use it, I need to rereate similar functionality, and i would be
>> obliged
>> if some one can give me some pointers in that direction
>>
>
> Please note that procmon has an usermode part, besides of the driver.
> You can get the process exe file name in your driver.
> Why do you need the whole stack? is the driver called from a specific DLL?
> --pa
>
>
> On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
>>
>> Do you just need the process or the actual call stack of the requesting
>>> thread?
>>>
>>> If you need the stack for debugging purposes you can always see if
>>> Process
>>> Monitor helps, it has an option to show the call stack for the requests.
>>>
>>> -scott
>>>
>>> –
>>> Scott Noone
>>> Consulting Associate
>>> OSR Open Systems Resources, Inc.
>>> http://www.osronline.com
>>>
>>>
>>>
>>> “Bedanto” wrote in message news:xxxxx@ntdev…
>>> Hi!
>>>
>>> Is there a way in Windows Kernel mode to walk the stack something likethe
>>> debugger kv command? I need to find the originator of an IOCTL call back
>>> to
>>> the actual process who generated it…
>>>
>>> B
>>>
>>>
>>>
>>> —
>>> 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
>>>
>>>
>>
> —
> 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
>
> yes we expect it to be called from a specific DLL
Forget it, any of the stack walking stuff is going to be useful only for
debugging.
If this is for security reasons, seriously look into just applying an
appropriate ACL to your device object. Depending on your usage, it might
also be a perfect use for a service SID.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bedanto” wrote in message news:xxxxx@ntdev…
yes we expect it to be called from a specific DLL
On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. wrote:
“Bedanto” wrote in message news:xxxxx@ntdev…
i need the call stack, and procmon does exactly what i want…however, I
cant use it, I need to rereate similar functionality, and i would be obliged
if some one can give me some pointers in that direction
Please note that procmon has an usermode part, besides of the driver.
You can get the process exe file name in your driver.
Why do you need the whole stack? is the driver called from a specific DLL?
–pa
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bedanto” wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
—
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
—
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
it is not for security reasons directly, just a proof of concept way to race
back a caller from kernel to userland…
On Wed, Aug 5, 2009 at 4:46 PM, Scott Noone wrote:
> > yes we expect it to be called from a specific DLL
>
> Forget it, any of the stack walking stuff is going to be useful only for
> debugging.
>
> If this is for security reasons, seriously look into just applying an
> appropriate ACL to your device object. Depending on your usage, it might
> also be a perfect use for a service SID.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
> “Bedanto” wrote in message news:xxxxx@ntdev…
> yes we expect it to be called from a specific DLL
>
>
> On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. wrote:
>
> “Bedanto” wrote in message news:xxxxx@ntdev…
>
>
> i need the call stack, and procmon does exactly what i want…however, I
> cant use it, I need to rereate similar functionality, and i would be
> obliged
> if some one can give me some pointers in that direction
>
>
>
> Please note that procmon has an usermode part, besides of the driver.
> You can get the process exe file name in your driver.
> Why do you need the whole stack? is the driver called from a specific DLL?
> --pa
>
>
>
> On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
>
>
> Do you just need the process or the actual call stack of the requesting
> thread?
>
> If you need the stack for debugging purposes you can always see if Process
> Monitor helps, it has an option to show the call stack for the requests.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
> “Bedanto” wrote in message news:xxxxx@ntdev…
> Hi!
>
> Is there a way in Windows Kernel mode to walk the stack something likethe
> debugger kv command? I need to find the originator of an IOCTL call back to
> the actual process who generated it…
>
> B
>
>
>
> —
> 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
>
>
>
>
>
> —
> 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
>
>
>
> —
> 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
>
I have done this on both x86 and x64.
For x86 the first challange is finding the user stack pointer. After that
you can trace the stack frames. The problem here is that the frames might
not be valid stack frames. You need some way to detect that the frames are
not valid and you need some way to know when to stop tracing. From a
security standpoint the stack is under complete control of the user so the
user can make the stack look like the call came from somewhere else. You
also need to realize that the dll you are interested in will not be the
first frame on the stack. For your dll the stack will probably be ntdll,
kernel32.dll, and then your dll. Of course you also need to know the memory
address where your dll is loaded and need to know that the call is from your
process. If you are only interested in your process then it is a little
easier since you will only trace the stack for that one process. You will
also know how far back to trace so you should not see any invalid frames.
Bill Wandel
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Bedanto
Sent: Wednesday, August 05, 2009 8:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
it is not for security reasons directly, just a proof of concept way to race
back a caller from kernel to userland…
On Wed, Aug 5, 2009 at 4:46 PM, Scott Noone wrote:
> yes we expect it to be called from a specific DLL
Forget it, any of the stack walking stuff is going to be useful only for
debugging.
If this is for security reasons, seriously look into just applying an
appropriate ACL to your device object. Depending on your usage, it might
also be a perfect use for a service SID.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com http:</http:>
“Bedanto” wrote in message news:xxxxx@ntdev…
yes we expect it to be called from a specific DLL
On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. wrote:
“Bedanto” wrote in message news:xxxxx@ntdev…
i need the call stack, and procmon does exactly what i want…however, I
cant use it, I need to rereate similar functionality, and i would be obliged
if some one can give me some pointers in that direction
Please note that procmon has an usermode part, besides of the driver.
You can get the process exe file name in your driver.
Why do you need the whole stack? is the driver called from a specific DLL?
–pa
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com http:</http:>
“Bedanto” wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
—
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
—
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
—
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
— 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
Digging out the trap frame could certainly be fragile and version specific.
On the x86 you’ll need to deal with FPO, for which you’d need PDBs (or some
crazy heuristics). You also have to imagine any third party components that
might be between your and your device (including hooks or filters doing
interesting things, including stack swapping).
Good luck!
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bill Wandel” wrote in message news:xxxxx@ntdev…
I have done this on both x86 and x64.
For x86 the first challange is finding the user stack pointer. After that
you can trace the stack frames. The problem here is that the frames might
not be valid stack frames. You need some way to detect that the frames are
not valid and you need some way to know when to stop tracing. From a
security standpoint the stack is under complete control of the user so the
user can make the stack look like the call came from somewhere else. You
also need to realize that the dll you are interested in will not be the
first frame on the stack. For your dll the stack will probably be ntdll,
kernel32.dll, and then your dll. Of course you also need to know the memory
address where your dll is loaded and need to know that the call is from your
process. If you are only interested in your process then it is a little
easier since you will only trace the stack for that one process. You will
also know how far back to trace so you should not see any invalid frames.
Bill Wandel
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Bedanto
Sent: Wednesday, August 05, 2009 8:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
it is not for security reasons directly, just a proof of concept way to race
back a caller from kernel to userland…
On Wed, Aug 5, 2009 at 4:46 PM, Scott Noone wrote:
> yes we expect it to be called from a specific DLL
Forget it, any of the stack walking stuff is going to be useful only for
debugging.
If this is for security reasons, seriously look into just applying an
appropriate ACL to your device object. Depending on your usage, it might
also be a perfect use for a service SID.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bedanto” wrote in message news:xxxxx@ntdev…
yes we expect it to be called from a specific DLL
On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. wrote:
“Bedanto” wrote in message news:xxxxx@ntdev…
i need the call stack, and procmon does exactly what i want…however, I
cant use it, I need to rereate similar functionality, and i would be obliged
if some one can give me some pointers in that direction
Please note that procmon has an usermode part, besides of the driver.
You can get the process exe file name in your driver.
Why do you need the whole stack? is the driver called from a specific DLL?
–pa
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Bedanto” wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
—
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
—
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
—
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
— 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
bill,
i rad ur email and tried understanding it. My question is, is ther a stack
frame data structure which i can use to do the mapping? or do i define my
own (it is opaque). in that case the frame objects might differ b/w os
versions too.
thanks
b
On Wed, Aug 5, 2009 at 6:37 PM, Bill Wandel wrote:
> I have done this on both x86 and x64.
> For x86 the first challange is finding the user stack pointer. After that
> you can trace the stack frames. The problem here is that the frames might
> not be valid stack frames. You need some way to detect that the frames are
> not valid and you need some way to know when to stop tracing. From a
> security standpoint the stack is under complete control of the user so the
> user can make the stack look like the call came from somewhere else. You
> also need to realize that the dll you are interested in will not be the
> first frame on the stack. For your dll the stack will probably be ntdll,
> kernel32.dll, and then your dll. Of course you also need to know the memory
> address where your dll is loaded and need to know that the call is from your
> process. If you are only interested in your process then it is a little
> easier since you will only trace the stack for that one process. You will
> also know how far back to trace so you should not see any invalid frames.
>
> Bill Wandel
>
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Bedanto
> Sent: Wednesday, August 05, 2009 8:05 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] stack walking
>
> it is not for security reasons directly, just a proof of concept way to
> race back a caller from kernel to userland…
>
>
>
> On Wed, Aug 5, 2009 at 4:46 PM, Scott Noone wrote:
>
>> > yes we expect it to be called from a specific DLL
>>
>> Forget it, any of the stack walking stuff is going to be useful only for
>> debugging.
>>
>> If this is for security reasons, seriously look into just applying an
>> appropriate ACL to your device object. Depending on your usage, it might
>> also be a perfect use for a service SID.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Consulting Associate
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>>
>>
>> “Bedanto” wrote in message news:xxxxx@ntdev…
>> yes we expect it to be called from a specific DLL
>>
>>
>> On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. wrote:
>>
>> “Bedanto” wrote in message news:xxxxx@ntdev…
>>
>>
>> i need the call stack, and procmon does exactly what i want…however, I
>> cant use it, I need to rereate similar functionality, and i would be
>> obliged
>> if some one can give me some pointers in that direction
>>
>>
>>
>> Please note that procmon has an usermode part, besides of the driver.
>> You can get the process exe file name in your driver.
>> Why do you need the whole stack? is the driver called from a specific DLL?
>> --pa
>>
>>
>>
>> On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
>>
>>
>> Do you just need the process or the actual call stack of the requesting
>> thread?
>>
>> If you need the stack for debugging purposes you can always see if Process
>> Monitor helps, it has an option to show the call stack for the requests.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Consulting Associate
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>>
>>
>> “Bedanto” wrote in message news:xxxxx@ntdev…
>> Hi!
>>
>> Is there a way in Windows Kernel mode to walk the stack something likethe
>> debugger kv command? I need to find the originator of an IOCTL call back
>> to
>> the actual process who generated it…
>>
>> B
>>
>>
>>
>> —
>> 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
>>
>>
>>
>>
>>
>> —
>> 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
>>
>>
>>
>> —
>> 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
>>
>
> — 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
> —
> 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
>
The standard x86 stack frame is well documented and a pdb file is not
needed. The system dll’s use this stack frame from W2K through at least
Vista. The Microsoft compiler generates the standard frame. Disassemble any
function and you will see this. This doesn’t mean that all applications will
conform. This is one of the problems of tracing the stack. What you think is
a stack frame might not be one. The standard frame uses the BP register. If
you have a starting point then you can trace as long as the application uses
the BP register as a frame pointer.
Why do you want to do this? If it is your IOCTL from your application then
you should know where it came from.
Bill Wandel
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Bedanto
Sent: Wednesday, August 05, 2009 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
bill,
i rad ur email and tried understanding it. My question is, is ther a stack
frame data structure which i can use to do the mapping? or do i define my
own (it is opaque). in that case the frame objects might differ b/w os
versions too.
thanks
b
On Wed, Aug 5, 2009 at 6:37 PM, Bill Wandel wrote:
I have done this on both x86 and x64.
For x86 the first challange is finding the user stack pointer. After that
you can trace the stack frames. The problem here is that the frames might
not be valid stack frames. You need some way to detect that the frames are
not valid and you need some way to know when to stop tracing. From a
security standpoint the stack is under complete control of the user so the
user can make the stack look like the call came from somewhere else. You
also need to realize that the dll you are interested in will not be the
first frame on the stack. For your dll the stack will probably be ntdll,
kernel32.dll, and then your dll. Of course you also need to know the memory
address where your dll is loaded and need to know that the call is from your
process. If you are only interested in your process then it is a little
easier since you will only trace the stack for that one process. You will
also know how far back to trace so you should not see any invalid frames.
Bill Wandel
_____
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Bedanto
Sent: Wednesday, August 05, 2009 8:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
it is not for security reasons directly, just a proof of concept way to race
back a caller from kernel to userland…
On Wed, Aug 5, 2009 at 4:46 PM, Scott Noone wrote:
> yes we expect it to be called from a specific DLL
Forget it, any of the stack walking stuff is going to be useful only for
debugging.
If this is for security reasons, seriously look into just applying an
appropriate ACL to your device object. Depending on your usage, it might
also be a perfect use for a service SID.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com http:</http:>
“Bedanto” wrote in message news:xxxxx@ntdev…
yes we expect it to be called from a specific DLL
On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. wrote:
“Bedanto” wrote in message news:xxxxx@ntdev…
i need the call stack, and procmon does exactly what i want…however, I
cant use it, I need to rereate similar functionality, and i would be obliged
if some one can give me some pointers in that direction
Please note that procmon has an usermode part, besides of the driver.
You can get the process exe file name in your driver.
Why do you need the whole stack? is the driver called from a specific DLL?
–pa
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone wrote:
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com http:</http:>
“Bedanto” wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
—
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
—
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
—
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
— 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
—
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
— 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
What sort of decision do you intend to make based on stack walking?
If you are intending to deny access based on the call stack, search for ret2libc to learn why this is a hopeless goal that will be circumvented with the utmost triviality by an adversary.
- S
From: Bedanto
Sent: Wednesday, August 05, 2009 02:36
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
yes we expect it to be called from a specific DLL
On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. > wrote:
“Bedanto” > wrote in message news:xxxxx@ntdev…
i need the call stack, and procmon does exactly what i want…however, I
cant use it, I need to rereate similar functionality, and i would be obliged
if some one can give me some pointers in that direction
Please note that procmon has an usermode part, besides of the driver.
You can get the process exe file name in your driver.
Why do you need the whole stack? is the driver called from a specific DLL?
–pa
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone > wrote:
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.comhttp:</http:>
“Bedanto” > wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
—
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
—
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
— 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
… “The standard frame uses the BP register. If you have a starting point then you can trace as long as the application uses the BP register as a frame pointer.” …
WARNING: You cannot assume BP/EBP is a valid frame pointer in any third party code, as compilers can optimise the code (in an attempt to make it faster) so that there is no frame pointer in EBP, in which case it may be temporarily used and trashed during a function just like other general purpose registers (although it will be restored when leaving the function)
The default configuration for VS with CL doesn’t generate ebp-based frames. Calling it a standard frame is perhaps a little bit too strong, unlike on amd64 where it’s actually required to have frames laid out in a standard fashion.
But yes, most system DLLs have FPO turned off on x86 builds, mostly for the help of heap and handle trace saving.
- S
From: Bill Wandel
Sent: Wednesday, August 05, 2009 07:36
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] stack walking
The standard x86 stack frame is well documented and a pdb file is not needed. The system dll’s use this stack frame from W2K through at least Vista. The Microsoft compiler generates the standard frame. Disassemble any function and you will see this. This doesn’t mean that all applications will conform. This is one of the problems of tracing the stack. What you think is a stack frame might not be one. The standard frame uses the BP register. If you have a starting point then you can trace as long as the application uses the BP register as a frame pointer.
Why do you want to do this? If it is your IOCTL from your application then you should know where it came from.
Bill Wandel
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Wednesday, August 05, 2009 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
bill,
i rad ur email and tried understanding it. My question is, is ther a stack frame data structure which i can use to do the mapping? or do i define my own (it is opaque). in that case the frame objects might differ b/w os versions too.
thanks
b
On Wed, Aug 5, 2009 at 6:37 PM, Bill Wandel > wrote:
I have done this on both x86 and x64.
For x86 the first challange is finding the user stack pointer. After that you can trace the stack frames. The problem here is that the frames might not be valid stack frames. You need some way to detect that the frames are not valid and you need some way to know when to stop tracing. From a security standpoint the stack is under complete control of the user so the user can make the stack look like the call came from somewhere else. You also need to realize that the dll you are interested in will not be the first frame on the stack. For your dll the stack will probably be ntdll, kernel32.dll, and then your dll. Of course you also need to know the memory address where your dll is loaded and need to know that the call is from your process. If you are only interested in your process then it is a little easier since you will only trace the stack for that one process. You will also know how far back to trace so you should not see any invalid frames.
Bill Wandel
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Bedanto
Sent: Wednesday, August 05, 2009 8:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] stack walking
it is not for security reasons directly, just a proof of concept way to race back a caller from kernel to userland…
On Wed, Aug 5, 2009 at 4:46 PM, Scott Noone > wrote:
> yes we expect it to be called from a specific DLL
Forget it, any of the stack walking stuff is going to be useful only for
debugging.
If this is for security reasons, seriously look into just applying an
appropriate ACL to your device object. Depending on your usage, it might
also be a perfect use for a service SID.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.comhttp:</http:>
“Bedanto” > wrote in message news:xxxxx@ntdev…
yes we expect it to be called from a specific DLL
On Tue, Aug 4, 2009 at 10:17 PM, Pavel A. > wrote:
“Bedanto” > wrote in message news:xxxxx@ntdev…
i need the call stack, and procmon does exactly what i want…however, I
cant use it, I need to rereate similar functionality, and i would be obliged
if some one can give me some pointers in that direction
Please note that procmon has an usermode part, besides of the driver.
You can get the process exe file name in your driver.
Why do you need the whole stack? is the driver called from a specific DLL?
–pa
On Tue, Aug 4, 2009 at 5:25 PM, Scott Noone > wrote:
Do you just need the process or the actual call stack of the requesting
thread?
If you need the stack for debugging purposes you can always see if Process
Monitor helps, it has an option to show the call stack for the requests.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.comhttp:</http:>
“Bedanto” > wrote in message news:xxxxx@ntdev…
Hi!
Is there a way in Windows Kernel mode to walk the stack something likethe
debugger kv command? I need to find the originator of an IOCTL call back to
the actual process who generated it…
B
—
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
—
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
—
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
— 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
—
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
— 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
—
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</mailto:xxxxx></mailto:xxxxx>
Agreed. If you attempt to do this with code you need some way of detecting
invalid frames. There is really no reliable way to do it but in the OP case
it might be possible. He never fully explained what and why he was trying to
do.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@netsupportsoftware.com
Sent: Wednesday, August 05, 2009 12:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] stack walking
… “The standard frame uses the BP register. If you have a starting point
then you can trace as long as the application uses the BP register as a
frame pointer.” …
WARNING: You cannot assume BP/EBP is a valid frame pointer in any third
party code, as compilers can optimise the code (in an attempt to make it
faster) so that there is no frame pointer in EBP, in which case it may be
temporarily used and trashed during a function just like other general
purpose registers (although it will be restored when leaving the function)
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
guys, thanks for being parient and thanks for explaining things to me. as i
mentioned before, I want to do a proof of concept kind a thing that lets me
identify the IOCTL generator, and I intend to use HMAC to generate hashes of
the actual code that encapsulatesthe IOCTL call to demonstrate (for
educational purposes) how HMAC can be put to practical usage. I already have
a code that can do it when here is no other function between the aller and
callee, now we want to extend it to a kernel mode user mode concept.
ofcourse, I *KNOW* that trying to do it for security reasons is foolish, as
mentioned by amny of you here and many before in OSR threads. Infact, once
this code is done (if at all), then we can even demonstrate why it is not
worth doing so ans how to circumvent it.
skywing (I am an avid fan of ur articles), I will read up the xample you
recommended to enhance my knowledge.
thanks
B
On Wed, Aug 5, 2009 at 10:17 PM, Bill Wandel wrote:
> Agreed. If you attempt to do this with code you need some way of detecting
> invalid frames. There is really no reliable way to do it but in the OP case
> it might be possible. He never fully explained what and why he was trying
> to
> do.
>
> Bill Wandel
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com]
> On Behalf Of xxxxx@netsupportsoftware.com
> Sent: Wednesday, August 05, 2009 12:28 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] stack walking
>
>
> … “The standard frame uses the BP register. If you have a starting point
> then you can trace as long as the application uses the BP register as a
> frame pointer.” …
>
> WARNING: You cannot assume BP/EBP is a valid frame pointer in any third
> party code, as compilers can optimise the code (in an attempt to make it
> faster) so that there is no frame pointer in EBP, in which case it may be
> temporarily used and trashed during a function just like other general
> purpose registers (although it will be restored when leaving the function)
>
>
>
> —
> 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
>
>
> —
> 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 is surely doable, although you need to jump through a lot of hoops.
- subscribe for callbacks for module load and process creation. This wil give you the per-process map of loaded modules, both kernel and user
- You can easily get the kernel part of the stack as advised by multiple posters on this thread.
- You can deal with FPO by taking a photograph of the kernel stack (http://msdn.microsoft.com/en-us/library/aa490475.aspx) and then using debugging APIs. If you have no symbols AND you deal with FPO, you still can simply try to resolve all pointers as potential symbols.
- THe user stack is seriously tricky. GIven that you are talking about IOCTL, you will be running below dispatch, so you can touch user’s memory. If you’re lucky to be at dispatch, the only way of getting there I can think of is by queueing an APC to yourself. THat’s seriously tricky, because it is undocumented.
- Part 4) did tell “there”, but didn’t tell EXACTLY where. debugger !teb command lists the usermode stack base and limit (!). So, where did it get that?
1: kd> !thread
THREAD 83f75d48 Cid 0314.0334 Teb: 7ffdb000 Win32Thread: ffa11ba8 RUNNING on processor 1
1: kd> dt -r1 83f75d48 nt!_ETHREAD
+0x000 Tcb : _KTHREAD
…
+0x088 Teb : 0x7ffdb000
huh, match!!!
1: kd> !teb 7ffdb000
TEB at 7ffdb000
ExceptionList: 005ef570
StackBase: 005f0000 <–
StackLimit: 005eb000 <–
1: kd> dt 7ffdb000 _TEB
nt!_TEB
1: kd> dt -r1 7ffdb000 _TEB
nt!_TEB
+0x000 NtTib : _NT_TIB
+0x000 ExceptionList : 0x005ef570 _EXCEPTION_REGISTRATION_RECORD
+0x004 StackBase : 0x005f0000 <<–
+0x008 StackLimit : 0x005eb000 <<–
huh, match again!
needless to note that the stack trace given by the debugger is right there, ending at 0x005f0000.
you can extract this information about offsets on the fly from symbols or hardcode it for OS/SP revisions. PsGetCurrentTHread() will tell you where your _ETHERAD is.