NO MORE annoying anti SOFT-ICE tricks
(how to improve SOFT-ICE)
by The Owl (Winice wizard eccelso)

HCU


Courtesy of reverser's page of reverse engineering
              NO MORE annoying anti SOFT-ICE tricks or
              how to improve SOFT-ICE!


   intro

      today's best EXE protectors contain code to prevent debugging with 
   SOFT-ICE, which is the best debugger among the ones i came across so 
   far. following protectors are known to me to defeat SOFT-ICE:

      EEXE (Encrypt Exe found in FZC.EXE)
      HACKSTOP (found in WWPACK.EXE)
      PROTECT! (found in various files)
      GUARDIAN ANGEL (found in some versions of HWINFO.EXE)
      EXELITE (a Polish exe compressor)
      the one written by PREDATOR 666 (found in DCA.EXE v1.4)
      the one used by Martin Malík (found in HWINFO.EXE v3.05 and up)
      DS-CRP by Dark Stalker (hi!)
      SECURE v0.19 by the authors of WWPACK
      ALEC v1.5 (the very best protector :-) by Random
      and a few others i don't remember right now...


   the problems

      SOFT-ICE can be detected/halted/crashed in many ways, here's a short
   list of them (some of them only makes single stepping harder but not
   impossible). i also included a short note on the effects for each version
   of SOFT-ICE:
                 :-( this trick works, 
                 :-) it causes no problems


      1. by the use of the INT3 interface provided by SOFT-ICE one can 
         check for the presence of SOFT-ICE and then have it execute various
         commands, e.g. HBOOT (see HackStop). the loader part of SOFT-ICE
         also leaves some traces in the low DOS memory, so one can find out
         the entrance values of the INT3 interface even if they were changed
         (see HMVS - a heuristic macro virus scanner - by J. Valky and
         L. Vrtik that uses SECURE v0.19). the Windows versions can also be
         detected by the following code (thanks to Dark Stalker and ACP :-):

           mov ebp,"BCHK"
           mov ax,4
           int 3
           cmp ax,4
           jne winice_installed

         it seems that BoundsChecker talks to SOFT-ICE via an interface very
         similar to the one between LDR.EXE and SOFT-ICE (although it's
         completely undocumented, as far as i know...)


         DOS: :-(
         W31: :-( (but the SECURE method is :-)
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      2. by checking for various devices SOFT-ICE installs ("CVDEBUG",
         "NU-MEGA", "SOFTICE1") and searching the part of the code SOFT-ICE
         leaves in the low DOS memory for some patterns (e.g. "CVDEBUG",
         "NU-MEGA", "SEGMAP", "S-ICE" (the latter coming from the filename),
         and any instruction sequence that's left there) one can detect the
         presence of SOFT-ICE. the Window$ versions provide a VXD entry point
         that can be get by:

           mov ax,01684h
           mov bx,0202h ; VXD ID for Winice, check out Ralf Brown's INTLIST
           xor di,di
           mov es,di
           int 2fh
           mov ax,es
           add di,ax
           cmp di,0
           jne winice_is_installed

         the Window$ versions can also be detected by calling the "debugger
         install check" function of the Window$ debug kernel (int 42/ax=0041),
         for more details see Ralf Brown's INTLIST.

         see HWINFO.EXE and DS-CRP.COM for an extensive application of these
         checks...


         DOS: :-(
         W31: :-) but the VXD entry point check is :-(
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      3. by the use of the undocumented ICEBP/INT01 instruction (opcode 0xF1):
         SOFT-ICE gives a short beep before the execution of this instruction
         (it will be reflected back to the V86 mode handler, thus at least
         the intended handler will get it) which can be VERY annoying (and
         make the execution VERY slow), see EEXE for an application of this.

         DOS: :-(
         W31: :-)
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      4. by using the TRAP flag, one can use the single stepping feature to
         call a protection routine (e.g. a decryptor). the problem is, that
         during single stepping SOFT-ICE clears the TRAP flag for the V86 task
         and will neither execute nor step into the INT01 handler of the
         V86 task. many schemes use this trick.

         DOS: :-(
         W31: :-(
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      5. by the use of the debug (DRx) and control (CRx) registers:
         accessing these registers in V86 mode leads to a General Protection
         Fault (INT0D), which SOFT-ICE doesn't handle correctly (it's normally
         used for emulating instructions that access the interrupt flag, the
         debug registers, the control registers, etc.). the protected mode
         handler emulates instructions that access these registers by
         executing them, however it doesn't make note about this for itself,
         i.e. whenever a debug fault is triggered SOFT-ICE will think that
         it must pop up and won't reflect back this exception to the V86 mode
         handler (that's waiting for it in vain). for a working example see
         GUARDIAN ANGEL. furthermore, accessing DR4/5 and CR1 will halt
         SOFT-ICE with a General Protection Violation error message, which is
         of course quite disturbing if it's used many times in the program...

         and best of all by accessing CR4 SOFT-ICE simply crashes since
         there's no emulation code for this kind of instructions (there's a
         jump table that tells SOFT-ICE which routine to use to handle these
         instructions and the table ends with CR3...). this method was first
         used by Random in his ALEC.EXE v1.4 :-)

         another sad fact is that the emulation in SOFT-ICE is not complete:
         it ALWAYS uses eax no matter what the original instruction was...

         e.g. mov dr0,ebx will load dr0 from eax!
              mov ecx,dr0 will load eax from dr0!

         i guess it's needless to say how easy it is to detect this behavior...

         a sidenote for protection writers: other memory managers that run
         DOS in V86 mode may or may not handle these instructions correctly,
         so the use of this trick is highly discouraged.

         DOS: :-(
         W31: :-(
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      6. by the use of INT08, which is the timer interrupt in real mode DOS,
         and the Double Fault Exception in protected mode. the protected mode
         handler checks whether it was entered from V86 mode or not, and in
         the first case it reflects back this interrupt to the V86 mode
         handler. however, one can't single step into it.

         DOS: :-(
         W31: :-)
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      7. by the use of the INT07 interrupt (this is the Coprocessor Not 
         Available Exception):
         instead of reflecting back this interrupt to the V86 mode handler,
         SOFT-ICE tries to skip the offending coprocessor instruction (it
         checks for some opcodes). it seems the Nu-Mega folks never thought
         it would be called directly... for a real life application get some
         programs written (and protected) by Predator 666.

         DOS: :-(
         W31: :-)
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      8. by the use of the Invalid Opcode Exception (INT06):
         SOFT-ICE tries to emulate some instructions (e.g. LOADALL), and then
         reflects back this exception to the V86 mode handler. however,
         certain opcodes aren't recognized and will give you an error message
         (i.e. execution will be interrupted, if the protection scheme uses
         this trick).

         DOS: :-(
         W31: :-(
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      9. by using direct INTxx calls that are triggered by hardware
         interrupts (e.g. INT08-INT0F, INT70-INT77, if the vectors in the PIC
         are not reprogrammed), one will not be able to single step into the
         interrupt handler. in fact, SOFT-ICE will even execute the next
         instruction and just then stop (if the next instruction is also an
         INTxx call of this type then it will be stepped over as well, and so
         on). so far, i know of no protection scheme that uses this trick,
         but i guess i've just given out a good idea :-).

         DOS: :-(
         W31: :-)
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      A. by reloading IDTR one can change the base and size of the interrupt
         table in real mode as well. however, SOFT-ICE will not emulate this
         instruction (it causes a General Protection Fault in V86 mode) thus
         a protection using LIDT won't run. the only problem is that memory
         managers don't like it very much, so probably we won't see it in a
         real life protection scheme, but one never knows :-).

         DOS: :-(
         W31: :-(
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


      B. sometimes one has to call an interrupt directly (GENINT xx), e.g. to
         dump a memory range to disk by using one's memory resident dumper
         (you know what i mean :-) and it's very annoying that SOFT-ICE
         doesn't stop after the interrupt call but executes the program
         being debugged (thus one has to set a breakpoint for a moment at the
         current CS:IP which will result in an unwanted 0xCC byte in the dump,
         if all debug registers are already used).

         DOS: :-(
         W31: :-(
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)

      C. in plain DOS INT3 and INT1 are handled by the same routine (which is
         a simple IRET). however, SOFT-ICE changes the INT3 handler of the
         V86 task to another IRET which can be detected by comparing its
         offset to the one of the INT1 handler. see HWINFO.EXE for
         an application

         DOS: :-(
         W31: :-)
         W95: not tested yet (probably same as W31)
         WNT: not tested yet (probably same as W31)


   the solutions

      in the following part you'll be presented with some ideas about the
   solution for the problems described above (the file offsets refer to the
   DOS version v2.80, but the ideas should work for other versions, as well.
   the easiest way to apply the patches is using Hacker's View which can
   be found in HIEW531.ZIP).

      one general problem is that SOFT-ICE (at least the DOS version) doesn't
   reprogram the hardware interrupt vectors, and this makes life (and the
   interrupt handlers) a bit more complex. the IDT that SOFT-ICE uses has
   entries that point to the following type of code:

   push xx
   jmp handler_xx

   where xx goes from 0x00 to 0xFF. in v2.80 this code begins at offset
   0x4534. the Win31 version has a very similar code beginning at offset
   0x14167 in v1.52:

   push d,[offset_xx]
   jmp handler_xx


      if you want to understand the patches that follow right below, you
   should study the interrupt handlers (and you should also have a good
   understanding of protected mode). however, some problems cannot be solved
   without understanding the internal flags of SOFT-ICE, and this requires a
   complete disassembly of it, which is a quite hard task i can tell.

      anyway, sooner or later it will be done, and then we'll have the
   ultimate debugging/cracking tool in our hands 'cos we'll be able to put in
   some missing functions, e.g. emulation of FlatRealMode, tracing INT1, PIC
   reprogramming, prefetch queue emulation, dumping a memory range to disk,
   etc. until then, enjoy the poor man's patches...

      1. some exe protections mentioned earlier are based upon the INT3
         interface of SOFT-ICE (see Ralf Brown's Interrupt List for details).
         this interface is activated when the protected mode INT3 handler of
         SOFT-ICE encounters the magic values in SI and DI. that is, when you
         try to trace through an INT3 call, SOFT-ICE will regain control,
         check for the magic values, and in case they are not found, it will
         reflect back this interrupt to the V86 mode INT3 handler (which it
         was supposed to do anyway). if it finds the magic values, then
         it'll execute the command given in AX (and DS:DX). all of these
         checks happen invisibly to the hacker, so there seems to be no
         solution to defeat this kind of protection (well, there's a slow way
         if you step through every instruction and before the "guilty" INT3
         call you change one or two registers).

         however, there's a simple solution: change the magic values SOFT-ICE
         is looking for and this will defeat those protectors based upon the
         INT3 interface. however, it's easier said than done because both
         SOFT-ICE (and WIN-ICE) itself and (W)LDR.EXE use this interface for
         some kind of intra/inter process communication. so every reference
         to the magic values will have to be changed!

         to keep the story short here's what i've come up with:
         browsing a few minutes in Hacker's View (another important tool ;-)
         i found the places where those changes had to be done. in order to
         avoid changes where those magic values occur by chance, i wrote an
         MSUB script to change whole instructions (they represent enough
         context). the amount of necessary changes would have forced me to
         use some search&replace utility, anyway. MSUB.EXE can be found in
         MSUB13.ZIP (use an ftp search engine to find it).

         the scripts

         SICE-VAL.MS: you should specify the old and new magic values in it
                      (note that numbers are decimal!)

         SICE2NEW.MS: it will replace the old magic values with the new ones.
                      there are almost 2^32 possible values, only that value
                      is forbidden for SI that equals to the version of
                      SOFT-ICE (for v2.80 it is \128\2, i.e. 0x0280). before
                      SOFT-ICE installs itself, it checks for its presence by
                      using an undocumented function of its INT3 interface by
                      setting AH to 0 or 1. on return SI will be loaded with
                      the version number or left unmodified if it's not
                      installed yet, that's why the version number must differ
                      from the preloaded value of SI.

         example usage

                  MSUB.EXE SICE2NEW.MS S-ICE.EXE LDR.EXE 

         if you're fed up with the shareware delay built into MSUB.EXE,
         here's how you can get rid of it (thanks to a friend of mine ;-)

         patch MSUB.EXE v1.3 (113,152 bytes long) as follows:

         offset    old new
         00002307: ??  EB
         00002308: ??  03
         0000C0DF: 77  EB


         the protection that SECURE uses is quite clever 'cos it checks the
         first 16 kBytes for the instruction sequence of

         mov si,SI_MAGIC
         mov di,DI_MAGIC

         they're encoded as 0BEh,x,y,0BFh,u,v where x,y,u and v are the magic
         values. when it finds 0BEh and 0BFh separated by two bytes from each
         other then it calls INT3 with the supposed magic values (the INT3
         handler is a simple IRET, so no problem should arise if SOFT-ICE is
         not installed). and guess what happens when SECURE finds the traces
         of the loader part of SOFT-ICE in that low memory area...

         the only solution that would defeat this kind of protection is to
         change the instructions that load SI and DI before the INT3 calls
         (unfortunately you can't avoid those calls since SOFT-ICE has to
         check for its presence and do other things). for obvious reasons
         (i guess one of the previous versions of this file gave the SECURE
         authors the idea...) i won't give you tips on how to do it, i hope
         you're smart enough to do it yourselves.

         the only limit is that you have 6 bytes of space to load both SI and
         DI (i checked that whenever SOFT-ICE uses the INT3 interface it loads
         SI and DI by two consecutive instructions, i.e. you can use the MSUB
         scripts to search for and replace them). another method could be to
         change the HBOOT command to something else (by MSUB of course),
         however other dangerous commands could be still issued...


         the BoundsChecker interface can be modified in the same way we did
         it with the rest of the INT3 interface: simply modify the value that
         is expected in ebp (but BoundsChecker must be changed as well!).
         look for the string "KHCB" to find the appropriate place.
         the following file offsets are valid for WINICE for Win 3.1 v1.52:

         offset    old new
         000130C7: 'K' ?
         000130C8: 'H' ?
         000130C9: 'C' ?
         000130CA: 'B' ?

         for WINICE for Win95 v3.0:

         offset    old new
         00016FDD: 'K' ?
         00016FDE: 'H' ?
         00016FDF: 'C' ?
         00016FE0: 'B' ?

         and for WINICE for Win95 v3.01:

         offset    old new
         000243F0: 'K' ?
         000243F1: 'H' ?
         000243F2: 'C' ?
         000243F3: 'B' ?


      2. the device names can be changed to anything you want, look at the
         beginning of S-ICE.EXE. the real problem is when the protection
         checks for instruction sequences. my only advice is that step through
         the protection and see which part of the code is checked for, then
         try to modify it in S-ICE.EXE (or disassemble, modify and then
         recompile the whole executable, but that's not gonna happen for
         a long time, i guess... :-).

         to defeat the int41 check, you have to change both the return value
         of the real and protected mode handlers in WINICE and the value that
         is checked for in KRNL386.EXE, VMM32.VXD, EMM386.EXE, IFSHLP.SYS and 
         NET.EXE. all these changes are necessary otherwise some WINICE
         commands (HWND, TASK) won't work 'cos apparently they rely on some
         Window$ functions which are available only in the debug kernel (and
         during startup these programs/drivers do this int41 check which will
         fail if you don't change the values they're expecting, as well).

         there're five places in WINICE that have to be patched (one is a cmp,
         the other four are mov's) and one in each one of the rest. sorry,
         that i don't provide you with detailed offsets, but there're too many
         versions/combinations of both WINICE and Win31/Win95... note, that
         after these changes other programs that want to use debug kernel
         functions will fail :-)

         and now let's talk about the VXD entry point check. the ID is stored
         at file offset 0x7821E in WINICE for Win95 v3.01 (to find it in
         other versions as well just look for "SICE   ", and the ID will be
         a few bytes before this text).

         so to change the ID just overwrite it there. however, it's not
         enough since some companion programs also test for WINICE by trying
         to get the VXD entry point, i.e. they have to be modified as well.
         they're DLOG.EXE and WLDR.EXE, and search for int2F (opcode: 0xCD
         0x2F) to get to the right place... :-)

         anyway, for the versions that come with WINICE for Win95 v3.0,
         the file offsets of the ID are 0x625/6 and 0x68B9/A respectively.


      3. what we have to do is simply skip the unnecessary parts in the
         handler (the beeps) and simulate the instruction as it would have
         been a direct INT 01 call (opcode: 0xCD 0x01). this way one will not
         only get rid of the beeps but be able to trace into the handler as
         well (and we'll have some space to put some extra code in when we'll
         need it :-).

         offset    old new
         00001DD5: 50  EB
         00001DD6: 51  60


      4. [this part is being worked on]
 

      5. there are two possible solutions: we either disable the DRx emulation
         feature of SOFT-ICE (this is quite easy to do) or correct it (this is
         really hard to do). SOFT-ICE emulates each instruction by executing
         a function whose offset is looked up in a table. each function ends
         in the same way: IP of the V86 task is incremented by the appropriate
         amount of bytes. so to disable emulation we'll change the pointers
         in that table to the common end of the functions, this way these
         instructions will essentially be handled as NOPs. i don't know
         whether it's worth to do it or not, since this modification can be
         detected by simply loading one of the debug registers and then
         checking whether it's really been modified or not. a more elegant
         solution would be to reserve a few bytes in the data segment of
         SOFT-ICE for storing the values of these registers and emulate the
         instructions (or at least their loading). anyone out there willing
         to do that?

         anyway, here's how to do the patch: the table itself is at file
         offset 0x1F1DD and it has 12 words in it pointing to the
         emulation code of the following instructions:

             mov eax,dr0 and mov dr0,eax
             mov eax,dr1 and mov dr1,eax
             mov eax,dr2 and mov dr2,eax
             mov eax,dr3 and mov dr3,eax
             mov eax,dr4 and mov dr4,eax
             mov eax,dr5 and mov dr5,eax
             mov eax,dr6 and mov dr6,eax
             mov eax,dr7 and mov dr7,eax
             mov eax,cr0 and mov cr0,eax
             mov eax,cr1 and mov cr1,eax
             mov eax,cr2 and mov cr2,eax
             mov eax,cr3 and mov cr3,eax

         note that there's no offset for emulating CR4...

         the offset of the common exit point (i.e. the new value you may want
         to set these pointers to) is 0x175A (this is NOT a file offset...).

         these patches still don't cure the problem with CR4. if you decided
         to get rid of the emulation entirely (including CR4) then you can
         do it much easier:

         offset    old new
         00002E7E: 03  0A
         00002E7F: 00  01


      6. i'll give you a general solution in section 8 since INT08 is just a
         a subset of the hardware interrupts which are discussed there.


      7. this problem can be solved quite easily: we replace the original
         protected mode handler with the one that serves all not_IRQ_related
         interrupts (and whose only task is to reflect them back to the
         V86 mode handler).

         offset    old new
         0000455A: B6  14
         0000455B: DF  D6


      8. what we have to do is to skip the call that prints the error message
         and simply reflect this interrupt back to the V86 mode handler.
         note that your buggy programs won't cause SOFT-ICE to pop up after
         this patch :-) (however, you'll be able to break in and see what
         went wrong).

         offset    old new
         00002447: A9  C3


      9. now we'll make use of the extra space we made in the original INT01
         handler. we have to check whether the interrupt was triggered by a
         hardware IRQ or not. this can be done by the following routine:

         push eax          ; save the registers that will be modified
         pushf             ; the order of PUSHs is important!
         mov al,0Bh        ; we'll read in the in-service registers
         out 20h,al        ; master PIC
         out 0A0h,al       ; slave PIC
                           ; there might be needed a short delay here
                           ; however, on my machine it isn't :-)
         in al,20h         ; read INTs being serviced by master PIC
         mov ah,al         ; save for later test
         in al,0A0h        ; read INTs being serviced by slave PIC
         test ax,0FFFFh    ; was it a hardware int?
         jnz original      ; 
         popf              ; restore flags
         pop eax           ; the general handler doesn't expect it
         jmp offset 1B70h  ; this has to be the general handler (this offset
                           ; is valid in v2.80)
         original:
         mov ax,8          ; the first two instructions of the original handler
         popf              ; were push eax, mov ax,8, thus we won't pop eax
         jmp offset 1A77h  ; this has to be the original handler's offset
                           ; plus 5 bytes (the length of push eax, mov ax,8)

         and at the beginning of the original handler (offset 0x1A72) we put:
         jmp offset 1DD7h  ; and since it's only 3 bytes long,
                           ; we get 2 spare bytes :-)

         the binary patches follow:

         offset    old new
         00001A72: 66  E9
         00001A73: 50  62
         00001A74: B8  03

         00001DD5: 50  EB
         00001DD6: 51  60
         00001DD7: B9  66
         00001DD8: 03  50
         00001DD9: 00  9C
         00001DDA: B0  B0
         00001DDB: 03  0B
         00001DDC: E6  E6
         00001DDD: 61  20
         00001DDE: 51  E6
         00001DDF: 33  A0
         00001DE0: C9  E4
         00001DE1: E2  20
         00001DE2: FE  8A
         00001DE3: E2  E0
         00001DE4: FE  E4
         00001DE5: E2  A0
         00001DE6: FE  A9
         00001DE7: E2  FF
         00001DE8: FE  FF
         00001DE9: E2  B8
         00001DEA: FE  08
         00001DEB: E2  00
         00001DEC: FE  75
         00001DED: E2  06
         00001DEE: FE  9D
         00001DEF: E2  66
         00001DF0: FE  58
         00001DF1: E2  E9
         00001DF2: FE  7C
         00001DF3: E2  FD
         00001DF4: FE  9D
         00001DF5: E2  E9
         00001DF6: FE  7F
         00001DF7: E2  FC


      A. to solve this problem we should do a complete disassembly of SOFT-ICE
         since we have to keep track of the base and size of the V86 mode
         interrupt table, and this requires too many changes to be worth to do
         it with simple byte patches.


      B. a somewhat lame (but it's more than nothing) solution is the
         following: we chain in a P RET command after GENINT by patching
         the jump at the end of the GENINT handler to the beginning of P RET.
         after executing GENINT we'll land at the IRET of our handler and
         a further P or T will take us back to the original instruction we
         were at. i said it was somewhat lame... but it works :-)

         offset    old new
         000118BF: BC  00
         000118C0: E0  C7


      C. before executing anything call up SOFT-ICE and change the offset of
         the V86 mode INT3 handler to the one of the INT1 handler.


      D. !!! SURPRISE !!!

         while you're in WINICE for Win95 v3.0 or 3.01 type in the following
         command: "ver ice" and see what you get... however, note that due
         to a bug (or feature?) you can use only once this command during
         a session, you have to restart WINICE to be able to get the
         message again.

         and while we're at undocumented features, try out "ver ?" as well.
         in the next release, i'll try to write a detailed description
         of the new commands (not that if it were that hard to find out...)


   unsolved mysteries :-)

      1. even the Nu-Mega docs tell about a problem when SOFT-ICE for DOS is
         loaded from the command line: if HIMEM.SYS is installed the machine
         simply reboots. i tracked down the problem and found out that the
         processor resets itself because of a triple fault. it happens so:

         after preparing the IDT and GDT (and loading IDTR and GDTR), paging
         will be enabled in CR0, and then DS and ES will be loaded a
         descriptor offset of 8. however, both this descriptor and the IDT
         seem to be invalid, and this leads to a triple fault. unfortunately,
         i couldn't find out what goes wrong during the setup of IDT and GDT,
         perhaps someone else out there will do the dirty job :-)... and maybe
         Nu-Mega will award you with a free, legal version :-)).


      2. on a Cyrix 486DLC-40 system (both with and without a coproc) SOFT-ICE
         gets a Page Fault and halts if the processor is running at 40 MHz,
         but works fine at 33 MHz. the Page Fault seems to happen while the
         code window is being put out (i.e. during the execution of the wc
         command). this is nonsense! so far, no solution... and yes, it's
         another dirty job...


   P.S. for everyone

         perhaps there's someone out there who didn't know it so far...
         WINICE can be used without Window$ (and you'll be able to debug
         programs that use some DOS extender, if it can make use of DPMI, but
         that's the case with the most popular ones, e.g. DOS4GW or PMODE/W)!
         the trick is that you have to make a 'crippled' version of Window$,
         i.e. make Window$ start without its GUI. a complete description of
         this can be found at the following URL:

                http://www.fys.ruu.nl/~faber/Windows_No_GUI

         after creating this GUI-less Window$ all you have to do is to start
         WINICE (beware, your normal Window$ shouldn't be on your PATH!) and
         voila, you'll be in a DOS session (i hope that you could find it out
         yourself that you had to start COMMAND.COM as your KRNL386.EXE...)
         with WINICE being able to pop up whenever you need it (of course, for
         native Window$ programs you'll need a full Window$).

         and if we're at Window$ here's another trick: if you don't want to
         see the logo being shown every time you start Window$, either start
         WIN.COM with a command line paramater of ':' i.e.

                WIN.COM :

         or (as the above method doesn't work with our GUIless version since
         WINICE doesn't seem to pass any parameters or you are too lazy to
         type in every time 2 more characters :-) look for the string 'LOGO'
         in WIN.COM and change it to something else (it's enough to change
         only one bit). note, that the WIN.COM of Window$ for Workgroups
         doesn't like this patch...


   P.S. for protection writers

         i know that some of the above modifications can be defeated (i could
         do it myself) however i won't make your life easier... i hope you
         understand why :-)

The Owl 1997

SICE-VAL.MS
cut from here ------
# OLD_SI: 'FG'
# OLD_DI: 'JM'

# OLD_SI
!:p=\71\70
# OLD_DI
!:q=\77\74

# NEW_SI
!:x=\71\68
# NEW_DI
!:y=\77\74
-------------- until here

SICE2NEW.MS
cut from here ------

!binary
!include sice-val.ms

# mov si,OLD_SI -> mov si,NEW_SI
\190:p
\190:x
# mov di,OLD_DI -> mov di,NEW_DI
\191:q
\191:y

# cmp si,OLD_SI -> cmp si,NEW_SI
\129\254:p
\129\254:x
# cmp di,OLD_DI -> cmp di,NEW_DI
\129\255:q
\129\255:y

# cmp w,[bp+4],OLD_SI -> cmp w,[bp+4],NEW_SI
\129\126\4:p
\129\126\4:x
# cmp w,[bp+0],OLD_DI -> cmp w,[bp+0],NEW_DI
\129\126\0:q
\129\126\0:y

# mov w,[bp+4],OLD_SI -> mov w,[bp+4],NEW_SI
\199\70\4:p
\199\70\4:x
# mov w,[bp+0],OLD_DI -> mov w,[bp+0],NEW_DI
\199\70\0:q
\199\70\0:y


# not sure about these ones...

# cmp w,[4],OLD_SI -> cmp w,[4],NEW_SI
\129\62\4\0:p
\129\62\4\0:x

# mov ax,OLD_SI -> mov ax,NEW_SI
\184:p
\184:x
------------ until here	

You are deep inside reverser's page of reverse engineering, choose your way out:

project 2
homepage links red anonymity +ORC students' essays
tools antismut cocktails search_forms mail_fravia
Is reverse engineering illegal?