Date:    06.12.97  03:47
Priority: Normal
TO: Non-HP-exe.hanno (exe%hanno@mailings.gmx.net)
Subject: Re: EXE: Bugfixed 'n' stuff
------------------------------- Message Contents -------------------------------
> Another but had snug into a file that some of you might've downloaded. My
> WinIce dector dectected itself in some cases. This should now be fixed.
> You can download the fixed program and source code on
>
> http://www.one.se/~stone/ad/stn-wid.zip

some notes on this winice detector:

1. method 2 and 3
winice (i mean the VXD portion) does not have a V86 INT 68 handler, however
the real mode initialization part does indeed hook the INT68 handler. by
doing so before Windows itself is started will have the effect that this
handler will be present in all V86 tasks (i.e. in all DOS windows). so
obviously you can detect it.

you should however know that INT68/43xx (i'm using Ralf Brown's notation)
has (probably) nothing to do with debuggers (including winice), the exact
purpose is yet unknown, but according to the Intlist it has something to
do with EMM managers (anyone wanna disassemble EMM386.EXE? ;-)

and while we are at this handler, does any of you know what INT68/44xx,
INT68/5080, INT68/5081 and INT68/9000 do? 'cos the real mode
initialization code of winice does something whenever these subfunctions
are called.

2. method 4
hmmm... it's not fair ;)  INT41 is not used as a real interrupt in DOS
but as the harddisk parameter table pointer. however, under windows, it's
used to communicate with a debugger, that is the kernel calls it to
notify the debugger of certain events (needless to say that the numega
guys are smarter again and are using not yet documented subfunctions of
it... damn ;-). beyond that, it'd be interesting to set the INT41 vector
via INT21/25 and INT21/35 and see whether it changes the behaviour or
not...

3. method 5
this is one of the previously mentioned subfunctions of the INT41
interface, it checks for the presence of a debugger, so it's not really
winice specific, nevertheless it works (unless you patch both winice and
the VMM).


and now some notes on SCRAM.

1. the keyboard problem
port 64 is the control port of the keyboard controller on the motherboard
(read/write). however one should be aware of the fact that the 8042
processor used on most motherboards is simply not fast enough to handle
successive IO instructions from the processor. in fact, when reading from
this very same port, the lower two bits will exactly tell you whether this
port (and port 60 as well) can be read from or written to (reading
concerns port 60 only of course). let's see how the nu-mega guys solved
the problem in winice (this routine checks whether port 60 can be read
or not, but the idea is the same for the write test, just use
'test al,2'):

pKbdWaitMbOutputReady            proc near

                                 push   ecx
                                 mov    ecx, 2000h

loc_290D:
                                 in     al, 64h
                                 push   ecx
                                 mov    ecx, 14h

loc_2915:
                                 loop   loc_2915
                                 pop    ecx
                                 test   al, 1
                                 loope  loc_290D
                                 pop    ecx
                                 retn
pKbdWaitMbOutputReady            endp


btw, writing AA to port 64 initiates a controller self test (when
there're no errors, 55 can be read from port 60).


2. 0xF1 a.k.a. INTBP
i dont really know where the idea of SMM mode checking came from, but this
instruction has been known as ICEBP for a long time. first i saw it in the
EEXE scheme (it's a protector for those who dont know ;-) that was used
on FZC (Fast Zip Cracker). what it does is very easy: it's like an
embedded INT1 instruction (much like CC is an INT3), and it does indeed
call the INT1 handler. the dos version of softice will trace it, however
it will give you a beep each time ICEBP is executed (one of the reasons i
started to reverse engineer softice 2 years ago was this fucking
beep...;-)


so much for now, take care

    The Owl
