I’m seeing a puzzling issue while stepping in windbg as below:
eax=00000010 ebx=00000000 ecx=00000000 edx=01ae0001 esi=e14feb88
edi=8196a220
eip=f9ae6069 esp=f9e6a570 ebp=f9e6a640 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000282
somedrv+0xb069:
f9ae6069 c7042400e0adf9 mov dword ptr [esp],offset somedrv+0x3000
(f9ade000) ss:0010:f9e6a570=00000346
kd> dd f9e6a570 l1
f9e6a570 00000346
kd> dd esp l1
f9e6a570 00000346
kd> t
eax=00000010 ebx=00000000 ecx=00000000 edx=01ae0001 esi=e14feb88
edi=8196a220
eip=f9ae6070 esp=f9e6a570 ebp=f9e6a640 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000282
somedrv+0xb070:
f9ae6070 83c404 add esp,4
kd> dd esp l1
f9e6a570 f9ade000 (NOTE: esp value here)
kd> t
eax=00000010 ebx=00000000 ecx=00000000 edx=01ae0001 esi=e14feb88
edi=8196a220
eip=f9ae6073 esp=f9e6a574 ebp=f9e6a640 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000286
somedrv+0xb073:
f9ae6073 ff7424fc push dword ptr [esp-4]
ss:0010:f9e6a570=00000286 (NOTE: esp-4 value here)
After ‘add esp,4’ content of esp-4 should be f9ade000. But thats not the
case. The content is 00000286.
Can anyone suggest why this is happening?
Thanks in advance,
Chandra
chandra97 97 wrote:
I’m seeing a puzzling issue while stepping in windbg as below:
…
kd> dd esp l1
f9e6a570 f9ade000 (NOTE: esp value here)
kd> t
eax=00000010 ebx=00000000 ecx=00000000 edx=01ae0001 esi=e14feb88
edi=8196a220
eip=f9ae6073 esp=f9e6a574 ebp=f9e6a640 iopl=0 nv up ei ng nz
na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000286
somedrv+0xb073:
f9ae6073 ff7424fc push dword ptr [esp-4]
ss:0010:f9e6a570=00000286 (NOTE: esp-4 value here)
After ‘add esp,4’ content of esp-4 should be f9ade000. But thats not
the case. The content is 00000286.
Can anyone suggest why this is happening?
Absolutely. You are trying to read data beyond the top of the stack.
Such data has no meaning. In this case, every time you single step, you
get a debug trace interrupt. What’s the first thing that an interrupt
does? It pushes the flags and the current CS:EIP. Notice what the
flags value is in your register listing.
“push dword ptr [esp-4]” is an expensive no-op, exactly equivalent to
“sub esp,4”. What did you think you were doing here?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
I see your point. Basically during ‘debugging’ access to any data beyond top
of stack is dangerous as OS may be using that location for its own
housekeeping. In this case saving register context due to INT 1.
I came across this while analyzing DriverEntry routine of a packed driver.
This driver works fine without debugger attached.
Thanks
Chandra
On Fri, May 16, 2008 at 1:02 PM, Tim Roberts wrote:
> chandra97 97 wrote:
>
>> I’m seeing a puzzling issue while stepping in windbg as below:
>> …
>> kd> dd esp l1
>> f9e6a570 f9ade000 (NOTE: esp value here)
>> kd> t
>> eax=00000010 ebx=00000000 ecx=00000000 edx=01ae0001 esi=e14feb88
>> edi=8196a220
>> eip=f9ae6073 esp=f9e6a574 ebp=f9e6a640 iopl=0 nv up ei ng nz na pe
>> nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>> efl=00000286
>> somedrv+0xb073:
>> f9ae6073 ff7424fc push dword ptr [esp-4]
>> ss:0010:f9e6a570=00000286 (NOTE: esp-4 value here)
>>
>> After ‘add esp,4’ content of esp-4 should be f9ade000. But thats not the
>> case. The content is 00000286.
>>
>> Can anyone suggest why this is happening?
>>
>
> Absolutely. You are trying to read data beyond the top of the stack. Such
> data has no meaning. In this case, every time you single step, you get a
> debug trace interrupt. What’s the first thing that an interrupt does? It
> pushes the flags and the current CS:EIP. Notice what the flags value is in
> your register listing.
>
> “push dword ptr [esp-4]” is an expensive no-op, exactly equivalent to “sub
> esp,4”. What did you think you were doing here?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
chandra97 97 wrote:
I see your point. Basically during ‘debugging’ access to any data
beyond top of stack is dangerous as OS may be using that location for
its own housekeeping. In this case saving register context due to INT 1.
Not only during debugging! You can get an interrupt at ANY time.
Timer, disk, DMA; it is NEVER safe to rely on memory beyond the top of
the stack.
I came across this while analyzing DriverEntry routine of a packed
driver. This driver works fine without debugger attached.
And that is exactly why they did it. Note that all you can say “it has
worked fine SO FAR without debugger attached”. Sooner or later, you’ll
catch a timer interrupt between those two statements, and it will explode.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Depending on what you’re trying to do here, you might want to look in to IDA Pro (www.datarescue.com), if you haven’t already.
Good luck,
mm
chandra97 97 wrote:
Tim,
I see your point. Basically during ‘debugging’ access to any data beyond
top of stack is dangerous as OS may be using that location for its own
housekeeping. In this case saving register context due to INT 1.
I came across this while analyzing DriverEntry routine of a packed
driver. This driver works fine without debugger attached.
Thanks
Chandra
On Fri, May 16, 2008 at 1:02 PM, Tim Roberts > mailto:xxxxx> wrote:
>
> chandra97 97 wrote:
>
> I’m seeing a puzzling issue while stepping in windbg as below:
> …
>
> kd> dd esp l1
> f9e6a570 f9ade000 (NOTE: esp value here)
> kd> t
> eax=00000010 ebx=00000000 ecx=00000000 edx=01ae0001 esi=e14feb88
> edi=8196a220
> eip=f9ae6073 esp=f9e6a574 ebp=f9e6a640 iopl=0 nv up ei
> ng nz na pe nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000286
> somedrv+0xb073:
> f9ae6073 ff7424fc push dword ptr [esp-4]
> ss:0010:f9e6a570=00000286 (NOTE: esp-4 value here)
>
> After ‘add esp,4’ content of esp-4 should be f9ade000. But thats
> not the case. The content is 00000286.
>
> Can anyone suggest why this is happening?
>
>
> Absolutely. You are trying to read data beyond the top of the
> stack. Such data has no meaning. In this case, every time you
> single step, you get a debug trace interrupt. What’s the first
> thing that an interrupt does? It pushes the flags and the current
> CS:EIP. Notice what the flags value is in your register listing.
>
> “push dword ptr [esp-4]” is an expensive no-op, exactly equivalent
> to “sub esp,4”. What did you think you were doing here?
>
> –
> Tim Roberts, xxxxx@probo.com mailto:xxxxx
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> mailto:xxxxx
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
I’ve been using IDA for last couple of years as I am windbg. I just wanted
to see that code as it was running. This is my first introduction to this
anti-debugging trick.
Chandra
On Fri, May 16, 2008 at 3:08 PM, Martin O’Brien
wrote:
> Depending on what you’re trying to do here, you might want to look in to
> IDA Pro (www.datarescue.com), if you haven’t already.
>
>
> Good luck,
>
> mm
>
>
>
>
> chandra97 97 wrote:
>
>> Tim,
>> I see your point. Basically during ‘debugging’ access to any data beyond
>> top of stack is dangerous as OS may be using that location for its own
>> housekeeping. In this case saving register context due to INT 1.
>>
>> I came across this while analyzing DriverEntry routine of a packed driver.
>> This driver works fine without debugger attached.
>>
>> Thanks
>> Chandra
>>
>> On Fri, May 16, 2008 at 1:02 PM, Tim Roberts >> xxxxx@probo.com>> wrote:
>>
>> chandra97 97 wrote:
>>
>> I’m seeing a puzzling issue while stepping in windbg as below:
>> …
>>
>> kd> dd esp l1
>> f9e6a570 f9ade000 (NOTE: esp value here)
>> kd> t
>> eax=00000010 ebx=00000000 ecx=00000000 edx=01ae0001 esi=e14feb88
>> edi=8196a220
>> eip=f9ae6073 esp=f9e6a574 ebp=f9e6a640 iopl=0 nv up ei
>> ng nz na pe nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>> efl=00000286
>> somedrv+0xb073:
>> f9ae6073 ff7424fc push dword ptr [esp-4]
>> ss:0010:f9e6a570=00000286 (NOTE: esp-4 value here)
>>
>> After ‘add esp,4’ content of esp-4 should be f9ade000. But thats
>> not the case. The content is 00000286.
>>
>> Can anyone suggest why this is happening?
>>
>>
>> Absolutely. You are trying to read data beyond the top of the
>> stack. Such data has no meaning. In this case, every time you
>> single step, you get a debug trace interrupt. What’s the first
>> thing that an interrupt does? It pushes the flags and the current
>> CS:EIP. Notice what the flags value is in your register listing.
>>
>> “push dword ptr [esp-4]” is an expensive no-op, exactly equivalent
>> to “sub esp,4”. What did you think you were doing here?
>>
>> – Tim Roberts, xxxxx@probo.com mailto:xxxxx
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> You are currently subscribed to windbg as: xxxxx@gmail.com
>> mailto:xxxxx
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>> mailto:xxxxx
>>
>>
>>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>