Hi folks,

Ok i hope someone could clarify all this confusion for me... I know i have to read the Intel Manual volume 3, and indeed i did but i guess somehow the truth evades me... i am still confused over all this int/trap handler stuff... The only difference i can understand is that trap/interrupt have different values pushed on stack before the handler is caller... so what is what and when which one occurs?

The recent discussion about rootkit detection mentioned it but to be honest i was kind of lost, when is interrupt handler called and when is trap handler called? I understand our IDT entries will specify whether a handler for specific int is interrupt handler or trap handler... using softice i can almost never see a Trap handler, only mainly int32 (which is interrupt handler i presume)... hence the confusion...

Let's say we have an int 3 instruction
int 3
this will trigger out interrupt handler? which in turn call the appropriate seh handler?

Or if we set T flag on EFlags for tracing, this will call int1 handler? How different is it from the INT 01 instruction and ICEBP... i know ICEBP was asked about by Kayaker long ago and discussed to a fair details, but how is ICEBP "eaten up" (eval's words) by our ring-3 debugger but not seh handler?

Hope you guys can understand me, cos honestly i am quite confused, hence the "confused question".

Thanks,

nice question! The idt entry descripor has the Type field which specifies the trap/interrupt handler. For what i know the interrupt handler is generally an asyncronous call so it should provide more register saving than a trap handler. A trap handler differs because you can pass parameters to it and it can return a return value (so i think it can do the std register saving). Its like saying that interrupt is asynchronous and trap is syncrhonous. There are still other type of idt descriptor (they are 16), each one with its own meaning. I am assuming you are talking about 32bit interrupt gate and 32bit trap gate (14 and 15). Naturally they are mutually exclusive. You can define several interrupt/trap handlers, but just only one can be installed at a time.

Calling an int 3 in the code calls the related handler (interrupt or trap), the function is os dependant, however on win it will end calling the per thread seh chain -> per process handler (unhandled exception filter). If the process is being debugged, the r3-debugger will be notified first. Softice is a bit different, as it has its own int3 handler.

Setting the trap flag generates a call to the int1 handler, which is dispatched like every other exception (see int3 ). ICEBP is an opcode that generates an INT1, so it is a call to int1, i dont know if there is a *real* difference between the two.
Hope i am not telling wrong things!

Bye!
AndreaGeddon

crUsAdEr, too much words, i not well understand
write numbered questions..

>>how is ICEBP "eaten up"(eval's words) by .. debugger but not seh handler?
there i also wrote: it is fault of debugger
(because not analyzes & then not manages).
Also, when debugger runs, he seats on debug-handlers, so he decides,
when will send to SEH, or eat..

about ICEBP.
i mostly read about ICEBP as INT01;
but now one said, it modifies DR6. i tested this fact & it's true.
so, calling ICEBP as INT(inter-privilege call) is wrong.

ok eval... so ICEBP eaten up by debugger is Olly bug ... undertand!

AnreaGeddon : thanks, that explains it, we can only install one at a time, either an interrupt handler or a trap handler...

ok onto next question,
Why can we trace the INT 01 handler in softice? as i see it, single stepping is by setting T flag then int01 handler is called? but if we are tracing within int01 handler wouldnt that cause an infinite loop?

doesnt make much sense to me
the last sentence said single step the INT instruction to step handler, yet the first sentence say INT instruction clear T flag?

>so ICEBP eaten up by debugger is Olly bug
not bug, fault; also SICE's fault.

>Why can we trace the INT 01 handler in softice?
if you mean NTOSKRNL's INT 01 handler, this will not cause loop.
(meditate on it

>the last sentence said single step the INT instruction to step handler,
>yet the first sentence say INT instruction clear T flag?
first put there BPX, then start trace.(this explaned also)

i meant sice's handler...


sorry do u care to elaborate?

>>i meant sice's handler...
mostly when i tried to trace sice's handler(or other code), sice crashes..

>>if we are tracing within int01 handler wouldnt that cause an infinite loop?
i meditated on it, answer is: NO.

loop can be if:
1. insude INT01 handler will be set BPMX
2. inside INT03 handler will be BPX

but debuger will still crash, when self tracing, because of overwrites of .data
variables..

yeah i thought of that as well...
like for INT01 handler, sice will place BPX at the next instruction for single stepping... or else it can set T flag... but the key is how sice can determine whether an area of code is int1 handler or not... ah well... guess i must dig further into this handler...

but yeah, sometimes tracing int handler in sice causes crash, sometimes it doesnt... that is because overwrites of .data variables as kayaker did mention to me...

>>how sice can determine whether an area of code is int1 handler or not
why you stuck on so easy things?

how any code can determine any range of address(self)??

erm... if u look at int01 handler in sice... it is really quite complicated with lots of subroutine called within the handler, spreading from cpthook.sys to ntice.sys... some of the codes are shared between both int1 and int3 handler...

Well, first of all in your question you used wrong enumeration.
You said "trap/interrupt" as if it's different sons of the same family.
Actually trap is interrupt. One kind of interrupts.
There are three kind of interrupts:
1.fault
2.trap
3.abort.

Most of Programmers (ecpecially HLL programmers) take it as execution on some opcode
as one step thing. Actually opcode handling takes several stages as decoding, address
calculation, PL checking etc. And exeption (active #signal in internal of proc.) can be
errised in any of the stage if something is not valid.

So talking about fist two kinds of interrupt handling (fault and trap) we
shall keep in mind that the cause of interrupt is some instruction, and the instruction
has address (=EIP in moment of decoding).
1. fault is type of interrupt when exeption is rised BEFORE "bad" instruction
is executed. In the moment EIP=address of the instruction.
2. trap is type of interrupt when active exeption signal formated AFTER
the "bad" instruction is executed. Thus EIP at the moment already is pointer to
NEXT TO the instruction bytes (they say usually "next command" but I don't like
it, since nobody can garantee that there is not some garbage, EIP just points to
(address of instruction + size of instruction, that may be next instruction address,
or something else))

You sain "different values pushed on stack", - and it's wrong to put it this way.
Not "different" it's always EIP (among others). Both fault and trap save EIP, the
other thing is that since fault doesn't let bad instruction to be executed EIP
at the moments equal to address of the instruction, and trap occurs after execution,
thus EIP has value of next, after instrution bytes address.

And about abort (3rd type of interrupt)
- it's really bad situation, when it can not be fixed, and
termination is the only solution, usually cause is some hardware problem.


)))
It's not enough to say "int 3" since the same mnemonic is used for two
different opcodes: CC and CD 03. The are different ways handled.

Hi The Svin,

Thanks for a very clear explanation but i guess the misunderstanding is due to my "mis-phrasing"... i was actually refering to the trap-gate and interrupt-gate...

sorry abt that :/

btw, is CC in someway similar to ICEBP, as in they differ from normal INT_xx instruction by some flag settings?

open 3 volume, press F3 and put for search:"trap gate";
read all places, where search stops until end.
then ask again, if not clear(because Intl plays dirti for me also;

Do you mean what is trap gate, interrupt gate and task gate?
Well, it's a lot of typing ) Since I have no idea of what
do you know and what you don't know about them.
If only difference between trap and interrupt gates is needed,
it's not to big:
int. gate works as trap gate except fot one difference:
When exeption passes control trough int. gate processor reset
to 0 IF (int flag) AFTER including in stack ret. address, yet
BEFORE execution 1st instruction of int. handler.
Reset to 0 IF means hardware ints prohibited until IRET instruction
is executed, yet progs. ints through NMI entry are allowed.
Of course, handler having enough PL can allow hardware ints by itself.
Automatic canceling hardware ints it the kinds of exeptions
(kinds using int gate) is important for handling ints from hardware:
sorce of int. may keep active IRQ signal until handler of interrupt
resets it (switch off) directly. In the case if IF would not reset to 0
it's possible multiple reaction of processor to one and the same signal
of interrupt - it happence 'cause processor checks for active signar in
enter line INTR, and it woul cause STACK OVERFLOW and reset of processor
itself. Thus IF set to 0 before first command of handler, after ret. address
included in stack. It doesn't happen while passing control though trap gate.
For other things they are work the same way.
So we should differ trap/int/task GATES (wich related to the way passing
control) and trap/fault/about types of exeption (wich related to when
it occurs, what is in stack etc.) For example we can have fault exeption
handled though trap gate