int 3/ int 2d

NTDEV
1

hi all,

If i recall correctly, we are not supposed to call INT3H or INT2D from
inside win32 applications. Doing so, will generate an exception.

However, recently I came across some application (win32 console) that uses
inline assembly to generate these interrupts. That application works fine
without causing any expections at all. Infact, the os debug handler catches
the debug interrupt (I have checked using a break point).

The same app (32 bit) generates expection when run on 64 bit vista (wow64),
also the same app when compiled for 64 bit (moving out the assenbly code
into seperate files) also generates exception.

So, my question is, why and how does the 32 bit executable work without
expection on a 32 bit vista os?

thanks in advance

–

  • amitr0
2

On Tue, Dec 23, 2008 at 11:07:58PM -0800, amitr0 wrote:

If i recall correctly, we are not supposed to call INT3H or INT2D from
inside win32 applications. Doing so, will generate an exception.

The second sentence is true. The first sentence is not. As long as you
have a debugger attached, int 3 is perfectly acceptable. Indeed, when
you have a debugger attached and set a breakpoint, the debugger inserts
an “int 3” at that spot.

However, recently I came across some application (win32 console) that uses
inline assembly to generate these interrupts. That application works fine
without causing any expections at all. Infact, the os debug handler catches
the debug interrupt (I have checked using a break point).

Right, just as it is supposed to.

The same app (32 bit) generates expection when run on 64 bit vista (wow64),
also the same app when compiled for 64 bit (moving out the assenbly code
into seperate files) also generates exception.

So, my question is, why and how does the 32 bit executable work without
expection on a 32 bit vista os?

How are you noticing the exception? Perhaps the app is catching it.

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

3

Tim,

I am not clear in several points here, let me try once more…

The second sentence is true. The first sentence is not. As long as you
have a debugger attached, int 3 is perfectly acceptable. Indeed, when
you have a debugger attached and set a breakpoint, the debugger inserts
an “int 3” at that spot.

okay, I understand about int3, what about int2d? What is the behaviour of
int2d with and without debugger on win32 and win64?

How are you noticing the exception? Perhaps the app is catching it.

No, the app doesnt catch it, I notice it because windbg in kernel mode
cathces it as

The context is partially valid. Only x86 user-mode context is available.
WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
00000000`00428235 59 pop ecx
so when I looked into the code of the app, I saw where it was throwing.

On Tue, Dec 23, 2008 at 11:47 PM, wrote:

> On Tue, Dec 23, 2008 at 11:07:58PM -0800, amitr0 wrote:
> >
> > If i recall correctly, we are not supposed to call INT3H or INT2D from
> > inside win32 applications. Doing so, will generate an exception.
>
> The second sentence is true. The first sentence is not. As long as you
> have a debugger attached, int 3 is perfectly acceptable. Indeed, when
> you have a debugger attached and set a breakpoint, the debugger inserts
> an “int 3” at that spot.
>
> > However, recently I came across some application (win32 console) that
> uses
> > inline assembly to generate these interrupts. That application works fine
> > without causing any expections at all. Infact, the os debug handler
> catches
> > the debug interrupt (I have checked using a break point).
>
> Right, just as it is supposed to.
>
> > The same app (32 bit) generates expection when run on 64 bit vista
> (wow64),
> > also the same app when compiled for 64 bit (moving out the assenbly code
> > into seperate files) also generates exception.
> >
> > So, my question is, why and how does the 32 bit executable work without
> > expection on a 32 bit vista os?
>
> How are you noticing the exception? Perhaps the app is catching it.
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boeklheide, Inc.
>
> —
> 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
>

–

- amitr0

4

amitr0 wrote:

I am not clear in several points here, let me try once more…

>The second sentence is true. The first sentence is not. As long as you
>have a debugger attached, int 3 is perfectly acceptable. Indeed, when
>you have a debugger attached and set a breakpoint, the debugger inserts
>an “int 3” at that spot.

okay, I understand about int3, what about int2d? What is the behaviour
of int2d with and without debugger on win32 and win64?

I’ve never had the need to trace it. On XP, I get an exception without
the debugger. With ollydbg, it is ignored. With Windbg, it breaks to
the debugger as a “breakpoint occurred”.

No, the app doesnt catch it, I notice it because windbg in kernel mode
cathces it as

The context is partially valid. Only x86 user-mode context is available.
WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
00000000`00428235 59 pop ecx
so when I looked into the code of the app, I saw where it was throwing.

Right, but this is normal. The debugger gets a shot at “first chance”
exceptions. If you “go” from here, doesn’t it recover?

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

5

if the breakpoint exception is not handled in a test machine ( where no
debugger is on and or installed — detail ignored here), it should show
break point exception, and app terminates …
Otherwise I think the application has installed exception handler somewhere.
Long time back, MSJ had a nice article on it, people still uses to create
their own crash dumps etc using this along with StackWalk() etc…

-pro

On Wed, Dec 24, 2008 at 11:19 AM, Tim Roberts wrote:

> amitr0 wrote:
> >
> > I am not clear in several points here, let me try once more…
> >
> > >The second sentence is true. The first sentence is not. As long as you
> > >have a debugger attached, int 3 is perfectly acceptable. Indeed, when
> > >you have a debugger attached and set a breakpoint, the debugger inserts
> > >an “int 3” at that spot.
> >
> > okay, I understand about int3, what about int2d? What is the behaviour
> > of int2d with and without debugger on win32 and win64?
>
> I’ve never had the need to trace it. On XP, I get an exception without
> the debugger. With ollydbg, it is ignored. With Windbg, it breaks to
> the debugger as a “breakpoint occurred”.
>
>
> > No, the app doesnt catch it, I notice it because windbg in kernel mode
> > cathces it as
> >
> > The context is partially valid. Only x86 user-mode context is available.
> > WOW64 breakpoint - code 4000001f (first chance)
> > First chance exceptions are reported before any exception handling.
> > This exception may be expected and handled.
> > 00000000`00428235 59 pop ecx
> > so when I looked into the code of the app, I saw where it was throwing.
>
> Right, but this is normal. The debugger gets a shot at “first chance”
> exceptions. If you “go” from here, doesn’t it recover?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>

6

Be sure to check the Registry key already cited in this thread. If the key
is not defined, or the program it references is not installed, there is no
JIT debugger that can be invoked, and the effect is a fatal exception which
is reflected back to the app, which, having no exception handler for it,
will take the default exception handler (unhandled exception) and terminate
the app.
joe

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Wednesday, December 24, 2008 2:07 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] int 3/ int 2d

Tim,

I am not clear in several points here, let me try once more…

The second sentence is true. The first sentence is not. As long as you
have a debugger attached, int 3 is perfectly acceptable. Indeed, when
you have a debugger attached and set a breakpoint, the debugger inserts
an “int 3” at that spot.

okay, I understand about int3, what about int2d? What is the behaviour of
int2d with and without debugger on win32 and win64?

How are you noticing the exception? Perhaps the app is catching it.

No, the app doesnt catch it, I notice it because windbg in kernel mode
cathces it as

The context is partially valid. Only x86 user-mode context is available.
WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
00000000`00428235 59 pop ecx

so when I looked into the code of the app, I saw where it was throwing.

On Tue, Dec 23, 2008 at 11:47 PM, wrote:

On Tue, Dec 23, 2008 at 11:07:58PM -0800, amitr0 wrote:
>
> If i recall correctly, we are not supposed to call INT3H or INT2D from
> inside win32 applications. Doing so, will generate an exception.

The second sentence is true. The first sentence is not. As long as you
have a debugger attached, int 3 is perfectly acceptable. Indeed, when
you have a debugger attached and set a breakpoint, the debugger inserts
an “int 3” at that spot.

> However, recently I came across some application (win32 console) that uses
> inline assembly to generate these interrupts. That application works fine
> without causing any expections at all. Infact, the os debug handler
catches
> the debug interrupt (I have checked using a break point).

Right, just as it is supposed to.

> The same app (32 bit) generates expection when run on 64 bit vista
(wow64),
> also the same app when compiled for 64 bit (moving out the assenbly code
> into seperate files) also generates exception.
>
> So, my question is, why and how does the 32 bit executable work without
> expection on a 32 bit vista os?

How are you noticing the exception? Perhaps the app is catching it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

—
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

–

- amitr0
— 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 message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.

7

On 12/25/08, Tim Roberts wrote:

> I’ve never had the need to trace it. On XP, I get an exception without
> the debugger. With ollydbg, it is ignored. With Windbg, it breaks to
> the debugger as a “breakpoint occurred”.

windbg will report unknown exception 0xc0000096
the break point occured msg probably happens because DebugService has an
embedded int3 after int2d
in ntdll.dll (in xp - sp2 atleast)

windbg will neither go to the handler for in2d with gh or gn and seems to
ignore it as well is what i remember

also executing int2d in debugger will give the next opcode a slip and will
continue execution one byte afterwards

i have some snippet stashed somewhere ill post it when i dredge it out

thanks and regards

raj_r

8

first of all. thanks to all of you for replying and trying to explain it to
me.

Well here is my experimental code below:

there are two files f1.c which is defined as

==== f1.c ====

main()
{

genInt2D();

}

and there is a file util.asm defined as

====util.asm====

genInt2D PROC
push eax
push ebx
push ecx
mov eax,1234h ; some eye catcher vals in regs to identify the
interrupt in kernel mode
mov ebx,3456h
mov ecx,789h
int 2dh
pop ecx
pop ebx
pop eax
ret
ENDP

i also write a kernel mode driver that hooks int2d (only for experiment to
see how the mechanism works, trying to learn here)

when i build this app in 32 bit and execute, i hit my interrupt handler in
kernel and i can see eax, and other regs filled in with my values.

but when i build the same app as amd64 and run on vista64, the call never
reaches the driver and i see the app throwing an exception.

i cannot understand the difference in behavior. can someone pray explain or
atleast confirm that why this will not work similarly in both oses[32 and
64]?

Note: I am not an assembly programmer so the above snippet might have some
syntax errors, but i assure u, that in the code i run they are all correct.
i am typing from memory here.

thanks

amitr0

On Fri, Dec 26, 2008 at 8:19 AM, raj_r wrote:

>
>
> On 12/25/08, Tim Roberts wrote:
>
>
>> I’ve never had the need to trace it. On XP, I get an exception without
>> the debugger. With ollydbg, it is ignored. With Windbg, it breaks to
>> the debugger as a “breakpoint occurred”.
>
>
> windbg will report unknown exception 0xc0000096
> the break point occured msg probably happens because DebugService has an
> embedded int3 after int2d
> in ntdll.dll (in xp - sp2 atleast)
>
> windbg will neither go to the handler for in2d with gh or gn and seems
> to ignore it as well is what i remember
>
> also executing int2d in debugger will give the next opcode a slip and will
> continue execution one byte afterwards
>
> i have some snippet stashed somewhere ill post it when i dredge it out
>
> thanks and regards
>
> raj_r
> — 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

–

- amitr0

9

well my memory or my windbg rememberance is rusty and tim is actually right
in saying windbg shows breakpoint exception

here is a session output from ollydbg

Log data
Address Message
7C810867 Breakpoint at kernel32.BaseProcessStartThunk
00401000 Program entry point
00403980 COND: 0040A128 "I’m going to handle int 3
"
00403980 COND: 0040A143 "im going to int 3 now
"
0040117B INT3 command at handlein.0040117B
00403980 COND: 0040117C "this is int 03H int3handler
"
00403980 COND: 0040A15A "we came here succesfully after int 3
"
004011D5 Breakpoint at handlein.int2ddemo
00403980 COND: 0040A180 "I’m going to handle int 2d
"
00403980 COND: 0040A19C "im going to int 2d now
"
*00401208 Breakpoint at handlein.00401208
00403980 COND: 0040A1B4 “if this printed int2d handler wasnt called and
nop before this was skipped
*”
0040120D Breakpoint at handlein.0040120D

same session in windbg

0:000> bl
0 e 00403980 0001 (0001) 0:**** handleintn!__org_printf “da
poi(esp+4);g”
0:000> g
0040a128 “I’m going to handle int 3.”
0040a143 “im going to int 3 now.”
(a14.508): Break instruction exception - code 80000003 (first chance)
eax=00000016 ebx=7ffdf000 ecx=0040a143 edx=7c90eb94 esi=0040a0b8
edi=00000000
eip=0040117b esp=0012ff78 ebp=0012ff84 iopl=0 nv up ei pl nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000206
handleintn!c2_0+0x2b:
0040117b cc int 3
0:000> gn
0040117c “this is int 03H int3handler…”
0040a15a “we came here succesfully after i”
0040a17a “nt 3.”
0040a180 “I’m going to handle int 2d.”
0040a19c “im going to int 2d now.”
(a14.508): Break instruction exception - code 80000003 (first chance)
eax=00000017 ebx=7ffdf000 ecx=0040a19c edx=7c90eb94 esi=0040a0b8
edi=00000000
eip=00401202 esp=0012ff78 ebp=0012ff84 iopl=0 nv up ei pl nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000206
handleintn!int2ddemo+0x2d:
00401202 90 nop
*0:000> gn
0040120e “this is int 02dH int2dhandler…”
0040a200 “we came here succesfully after i”
0040a220 “nt 2d.”
*eax=00241ebc ebx=00000000 ecx=0000e06a edx=7c97c080 esi=7c90e88e
edi=00000000
eip=7c90eb94 esp=0012fe54 ebp=0012ff50 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret

*and the sample code (this is hack just use it for vague refernace purpose
only and use two pinches or ten pinches of salt while taking a look at this
code, This Code may be unsafe,buggy, mpunsafe, x64 unworking , and os
dependent crap)*
**

#include <stdio.h>

#include “intndemo.h”

#define numbint 0x3

#define handler int3handler

#define message int3message

#define getout int3getout

#define intn(numbint) int numbint

int int3demo(void)

{

printf(“I’m going to handle int 3\n”);

setseh

printf(“im going to int 3 now\n”);

intnbreak

intmsg

printf(“we came here succesfully after int 3\n”);

remseh

handleseh

return 0;

}

#undef numbint

#undef handler

#undef message

#undef getout

#define numbint 0x2d

#define handler int2dhandler

#define message int2dmessage

#define getout int2dgetout

int int2ddemo(void)

{

printf(“I’m going to handle int 2d\n”);

setseh

printf(“im going to int 2d now\n”);

//_asm

//{

// mov eax,0

// mov ecx,0

// mov edx,0

// mov ebx,0

// mov edi,0

//}

intnbreak

_asm { nop }

printf(“if this printed int2d handler wasnt called and nop before this was
skipped\n”);

intmsg

printf(“we came here succesfully after int 2d\n”);

remseh

handleseh

return 0;

}

int main (void)

{

int3demo();

int2ddemo();

return 0;

}

and the contents of intndemo.h

#define setseh <br>
_asm { assume fs:nothing }; <br>
_asm { push offset handler }; <br>
_asm { push dword ptr fs:[0] } <br>
_asm { mov fs:[0], esp };

#define remseh <br>
_asm { pop dword ptr fs:[0] };<br>
_asm { add esp, 0xc };<br>
_asm { retn };

#define intnbreak <br>
_asm { intn(numbint) };

#define intmsg <br>
_asm { message db “this is intn(numbint) handler”,13,10,0 };<br>
_asm { getout: };

#define handleseh <br>
_asm { handler: };<br>
_asm { push offset message };<br>
_asm { call printf };<br>
_asm { add esp,4 };<br>
_asm { mov eax,dword ptr ss:[esp+0xc] };<br>
_asm { mov dword ptr ds:[eax+0xb8],offset getout };<br>
_asm { mov eax,0 };<br>
_asm { retn };

int int3demo(void);

int int2ddemo(void);

thanks and regards

raj_r

On 12/26/08, raj_r wrote:
>
>
>
> On 12/25/08, Tim Roberts wrote:
>
>
>> I’ve never had the need to trace it. On XP, I get an exception without
>> the debugger. With ollydbg, it is ignored. With Windbg, it breaks to
>> the debugger as a “breakpoint occurred”.
>
>
> windbg will report unknown exception 0xc0000096
> the break point occured msg probably happens because DebugService has an
> embedded int3 after int2d
> in ntdll.dll (in xp - sp2 atleast)
>
> windbg will neither go to the handler for in2d with gh or gn and seems
> to ignore it as well is what i remember
>
> also executing int2d in debugger will give the next opcode a slip and will
> continue execution one byte afterwards
>
> i have some snippet stashed somewhere ill post it when i dredge it out
>
> thanks and regards
>
> raj_r
></stdio.h>