antidbg.txt

80386单片机

     CS:0107 CC             INT    3
     CS:0108 98             CBW
     CS:0109 01C3           ADD    BX,AX
     CS:010B E2F9           LOOP   0106

1.6. Halt computer using stack:

       This trick is based on the fact that debuggers don't usually use a
     stack space of their own, but rather the user program's stack space. By
     setting the stack to a location in the middle of a code that does NOT use
     the stack itself, any debugger that will try to trace the code will
     overwrite some of the code by its own stack (mainly interrupt return
     addresses). Again, CLI and STI are in order, and are not shown for the
     purpose of the example only. They must be included, or you risk hanging
     your computer wether a debugger is installed or not.

     Example:

     CS:0100 8CD0           MOV    AX,SS
     CS:0102 89E3           MOV    BX,SP
     CS:0104 0E             PUSH   CS
     CS:0105 17             POP    SS
     CS:0106 BC0B01         MOV    SP,010B
     CS:0109 90             NOP
     CS:010A 90             NOP
     CS:010B EB02           JMP    010F
     CS:010D 90             NOP
     CS:010E 90             NOP
     CS:010F 89DC           MOV    SP,BX
     CS:0111 8ED0           MOV    SS,AX

1.7. Halt TD386 V8086 mode:

       This is a nice way to fool Turbo Debugger's V8086 module (TD386). It is
     based on the fact that TD386 does not use INT 00h to detect division by
     zero (or register overrun after division, which is treated by the
     processor in the same way as in the case of division by zero). When TD386
     detects a division fault, it aborts, reporting about the faulty division.
     In real mode (even under a regular debugger), a faulty DIV instruction
     will cause INT 00h to be called. Therefore, pointing INT 00h to the next
     instruction, will recover from the faulty DIV.

     Note: It is very important to restore INT 00h's vector. Otherwise, the
     next call to INT 00h will cause the machine to hang.

     Example:

     CS:0100 31C0          XOR     AX,AX
     CS:0102 8ED8          MOV     DS,AX
     CS:0104 C70600001201  MOV     WORD PTR [0000],0112
     CS:010A 8C0E0200      MOV     [0002],CS
     CS:010E B400          MOV     AH,00
     CS:0110 F6F4          DIV     AH
     CS:0112 B8004C        MOV     AX,4C00
     CS:0115 CD21          INT     21

1.8. Halt any V8086 process:

       Another way of messing TD386 is fooling it into an exception.
     Unfortunately, this exception will also be generated under any other
     program, running at V8086 mode. The exception is exception #13, and its
     issued interrupt is INT 0Dh - 13d. The idea is very similar to the
     divide by zero trick: Causing an exception, when the exception interrupt
     points to somewhere in the program's code. It will always work when the
     machine is running in real mode, but never under the V8086 mode.

     Note: It is very important to restore the original interrupt vectors.
     Otherwise, the next exception will hang the machine.

     Example:

     CS:0100 31C0          XOR     AX,AX
     CS:0102 8ED8          MOV     DS,AX
     CS:0104 C70634001301  MOV     WORD PTR [0034],0113
     CS:010A 8C0E3600      MOV     [0036],CS
     CS:010E 833EFFFF00    CMP     WORD PTR [FFFF],+00
     CS:0113 B8004C        MOV     AX,4C00
     CS:0116 CD21          INT     21

2. Self-modifying code:
-----------------------

2.1. Encryptive/decryptive algorithm:

       The first category is simply a code, that has been encrypted, and has
     been added a decryption routine. The trick here is that when a debugger
     sets up a breakpoint, it simply places the opcode CCh (INT 03h) in the
     desired address, and once that interrupt is executed, the debugger
     regains control of things. If you try to set a breakpoint AFTER the
     decryption algorithm, what is usually needed, you will end up putting an
     opcode CCh in a place where decryptive actions are taken, therefore losing
     your original CCh in favour of whatever the decryption algorithm produces.
     The following example was extracted from the Haifa virus. If you try to
     set a breakpoint at address CS:0110, you will never reach that address,
     since there is no way to know what will result from the change. Note that
     if you want to make the tracing even harder, you should start the
     decryption of the code from its END, so it takes the whole operation
     until the opcode following the decryption routine is decrypted.

     Example:

     CS:0100 BB7109         MOV    BX,0971
     CS:0103 BE1001         MOV    DI,0110
     CS:0106 91             XCHG   AX,CX
     CS:0107 91             XCHG   AX,CX
     CS:0108 2E803597       XOR    Byte Ptr CS:[DI],97
     CS:010C 47             INC    DI
     CS:010D 4B             DEC    BX
     CS:010E 75F6           JNZ    0106
     CS:0110 07             POP    ES
     CS:0111 07             POP    ES

2.2. Self-modifying code:

   2.2.1. Simple self-modification:

            This method implements the same principle as the encryption
          method: Change the opcode before using it. In the following example,
          we change the insruction following the call, and therefore, if you
          try to trace the entire call ('P'/Debug or F8/Turbo Debugger), you
          will not succeed, since the debugger will put its CCh on offset 103h,
          but when the routine runs, it overwrites location 103h.

          Example:

          CS:0100 E80400         CALL   0107
          CS:0103 CD20           INT    20
          CS:0105 CD21           INT    21
          CS:0107 C7060301B44C   MOV    Word Ptr [0103],4CB4
          CS:010D C3             RET

          Watch this:

          CS:0103 B44C           MOV    AH,4C

   2.2.2. The Running Line (self-decrypting):

            This is an example of a self-tracing self-modifying code,
          sometimes called 'The running line'. It was presented by Serge
          Pachkovsky. It is a bit tricky in implementation, but, unlike
          all other techiniques mentioned in this document, it is relatively
          resistive to various protections of the vector table. In short, it
          results in instructions being decoded one at time, thus never
          exposing long code fragments to analisys. I will illustrate it
          with the following (over-simplified) code example:

          XOR     AX, AX
          MOV     ES, AX
          MOV     WORD PTR ES:[4*1+0],OFFSET TRACER
          MOV     WORD PTR ES:[4*1+2],CS
          MOV     BP, SP
          PUSHF
          XOR     BYTE PTR [BP-1], 1
          POPF
          MOV     AX, 4C00H               ; This will not be traced!
          DB      3 DUP ( 98H )
          DB      C5H, 21H

   TRACER:

          PUSH    BP
          MOV     BP, SP
          MOV     BP, WORD PTR [BP+2]
          XOR     BYTE PTR CS:[BP-1], 8
          XOR     BYTE PTR CS:[BP+0], 8
          POP     BP
          IRET

===============================================================================

Comments:

In order to save lines of code, I did not insert the CLI/STI pair before any
vector change. However, it is adviseable to do this pair before ANY manual
vector change, because if any interrupt occurs in the middle of your
operations, the machine could hang.

An apology:

In previous releases of this article, a false example, as noted by Serge
Pachkovksy, was posted. That was 2.2.2 - Manipulating the PIQ. Apperantly
the posted source would not work under any circumstances. In return, Serge has
presented the 'Running Line' technique.

Thanks to:

Eden Shochat, 2:401/100
  and
Yossi Gottlieb, 2:401/100.3

for helping me assembling this list.

Other acknowledgements:

Matt Pritchard, 80XXX echo

Serge Pachkovsky, Distributed Node (2:5000/19.19)

================================================================================

Any comments, suggestions, ideas and corrections will be gladly accepted.

Author can be reached in one of the following ways:

Inbar Raz, 2:401/100.1                          {fidonet}
Inbar Raz, 2:403/100.42                         {fidonet}
[e-mail]                 {internet}
uunet!m2xenix!puddle!2!403!100.42!Inbar.Raz     {UUCP}
[e-mail]           {internet<>FIDO gate}
[e-mail]          {internet<>FIDO gate}