home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / 40hex_7.002 < prev    next >
Text File  |  1995-01-03  |  9KB  |  196 lines
  1. 40Hex Number 7 Volume 2 Issue 3                                       File 002
  2.  
  3.  
  4.               ■ Code Concealment             ■
  5.               ■    -Demogorgon/PHALCON/SKISM ■
  6.  
  7.      In the previous issue of 40hex, I wrote about how a programmer can
  8. keep his code from being stolen by others.  Ways of doing this are
  9. endless, and I will talk about a few more methods in this installment.
  10.  
  11. Part I  : Fun with int3
  12. Part II : Fun with int8
  13. Part III: The Prefetch
  14.  
  15.  
  16. Part_I : Fun with int3
  17.  
  18.      Int three is the debugger breakpoint.  Every time a debugger breaks
  19. while tracing through a chunk of code, it will call int3.  Int3 is
  20. called after every instruction is executed in trace mode, and after
  21. a breakpoint is reached.  Note that protected mode debuggers do not
  22. execute int3 in trace mode, but they will break when int3 is called from
  23. your code.  You can use this to your advantage.  Simply install a new
  24. handler for int3 and it will execute instead of the debugger if a thief
  25. tries to trace through your program.
  26.  
  27. start:  mov     ax, 2503h
  28.         mov     dx, offset int_start
  29.         int     21h                     ; put in the new handler at ds:dx
  30.  
  31.         ...             ; rest of real code here
  32.         int     20h
  33.  
  34. text db 'Smoke Mah Ass!$'
  35. int_start:
  36.         mov     ah, 9
  37.         mov     dx, offset text
  38.         int     21h
  39.         int     20h
  40.  
  41.      As soon as the first int21 call in this program is made, the code
  42. at int_start will execute if it is being traced in a debugger.
  43. Otherwise, the int call will be ignored and your normal code will
  44. execute.  The program can do whatever you want if a debugger is found.
  45. For example, you can format the hard drive or display a message.  The
  46. possabilities are endless.  By the way, it might be wise to restore the
  47. old interrupt handler before you exit the program, because it is bad
  48. programming practice to leave interrupts pointed into non-allocated
  49. memory.
  50.  
  51.  
  52. compatability:(works against all debuggers marked with an X)
  53. -------------------------------------------------------------------------
  54. Debug           Turbo Debug             Turbo Debug 386         Soft-Ice
  55.   X                   X
  56. -------------------------------------------------------------------------
  57.  
  58.  
  59. Part_II: Fun with int8
  60.  
  61.      The next segment will show you how to make a program nearly
  62. impossable to trace.  The concept is simple.  All you need to do is
  63. place the main body ofyour program into an int8 handler.  Int8 is the
  64. timer interrupt, and it is called 18.2 times a second.  Debuggers do not
  65. execute int8, so whatever you put there will only go when it is run from
  66. dos.  The only drawback to this is a short delay before the main program
  67. is executed.  It will probably go unnoticed, in most cases.  Here is
  68. some code:
  69.  
  70. thyroid:mov     ax, 3508h
  71.         int     21h                        ; get int8 handler
  72.         mov     word ptr [int_store], bx   ; store it
  73.         mov     word ptr [int_store+2], es
  74.         mov     dx, offset prog_start
  75.         mov     ah, 25h
  76.         int     21h                        ; install new int8 handler
  77.  
  78. yip:    cmp     flaag, 1
  79.         jne     yip             ; wait for int8 to be called
  80.                         ; int8 must set the flaag to 1
  81.         push    bx
  82.         pop     dx      ; restore
  83.         push    es      ; old
  84.         pop     ds      ; int8
  85.         int     21h     ; handler
  86.         int     20h
  87.  
  88. flaag db 0
  89. int_store dd ?
  90. prog_start:
  91. _main_program proc far
  92.         ; save all the necessary registers here
  93.         ; ... your code
  94.         mov     flaag, 1
  95.         ; restore the registers
  96.  
  97.         jmp dword ptr [offset int_store]  ; chain to real int8 handler
  98. _main_program endp
  99.  
  100.      This code is quite useful in that if some guy tries to trace
  101. through it, he will be stuck forever in the 'yip' loop.  The main code
  102. will never be executed.  If he tries to get out of the loop by
  103. 'executing to' the next instruction, he will end up running the entire
  104. program.  No debugger I know of can trace through this, because int8 is
  105. not called from within the debugger.
  106.  
  107. -------------------------------------------------------------------------
  108. Debug           Turbo Debug             Turbo Debug 386         Soft-Ice
  109.   X                   X                         X                   X
  110. -------------------------------------------------------------------------
  111.  
  112.  
  113. Part_III: The Prefetch
  114.  
  115.      My favorite way to confuse debuggers is to mess with the prefetch
  116. queue.  All intel processors have a small queue where the next
  117. instructions to be executed are stored.  In this way, the CPU does not
  118. have to waste clock cycles by fetching the next instruction, except in
  119. the cases of branching instructions such as jmps and calls.  The next
  120. chunk of code makes use of this:
  121.  
  122. eapple: mov     ah, 9
  123.         mov     word ptr [offset ear_lobe-2], offset sukk_debug
  124.         mov     dx, offset text
  125. ear_lobe:
  126.         int     21h
  127.         int     20h
  128.  
  129. text    db 'snee!$'
  130. sukk_debug db 0Ah, 0Dh, 09h, 'blow a goat!', 07h, 0Ah, 0Dh, '$'
  131.  
  132.      All this program does is print out a text string.  If it is run
  133. from dos, it will print out 'snee!'.  If it is traced through by any
  134. debugger, however, it will print 'blow a goat!', and beep the PC speaker
  135. (07h is ctrl-g).  Let me explain how this works.
  136.      When any chunk of code is executed by dos, the first few bytes are
  137. sent into the prefetch queue.  The actual number of bytes depends on the
  138. model of intel chip, and what year it was made in.  My computer is a
  139. 386DX-20 (early model), which has a 16 byte prefetch.  Be sure to check
  140. your code on several machines to insure compatability.
  141.      When the second instruction is reached, it places the offset of
  142. sukk_debug into the next instruction.  That is, the next instruction
  143. becomes 'mov dx, offset sukk_debug', rather than 'mov dx, offset text'.
  144. The system memory will be changed, but the prefetch will not, therefore
  145. only a debugger will respond to the new code.  Dos will execute it as if
  146. the instruction had never changed, because the instruction will already
  147. have been loaded into the prefetch.  This theory can be used, with a
  148. little modification, in order to branch to various subroutines, rather
  149. than just printing out different text.  One interesting application of
  150. this is to use the prefetch area to store registers.  This way, a person
  151. debugging your code can not simply nop it out, because it will be
  152. referred to later on.  In fact, you can even put the stack on the
  153. prefetch.  Try to debug through the following fragment, and watch what
  154. happens:
  155.  
  156. nee:    mov     ax, 4Ch
  157.         mov     dx, offset text
  158.         mov     sp, offset fin_rot
  159.         push    ax
  160.         mov     ah, 9
  161. fin_rot:int     21h
  162.         pop     ax
  163.         int     21h
  164. text:   db      'Duck is proud of her feet.  They can catch things.$'
  165.  
  166.      If you run it through debug, the entire program will be corrupted
  167. as soon as you move the stack pointer.  This is because the debug code
  168. uses the stack and expects it to be in a safe location.  If you run it
  169. through soft ice, the code will be corrupted as soon as you push ax.
  170. The stack area will be overwritten when int21 is executed, because the
  171. interrupt uses the stack.  However, in this example, the instruction
  172. pointer will already be beyond this area, so the program will execute
  173. normally.
  174.      Remember not to place the stack past any calls, because then the
  175. prefetch would have to be reloaded after the main program was returned
  176. to, and the instructions that were there before will be gone.
  177.  
  178. -------------------------------------------------------------------------
  179. Debug           Turbo Debug             Turbo Debug 386         Soft-Ice
  180.   X                   X                         X                   X
  181. -------------------------------------------------------------------------
  182.  
  183.      That about wraps it up for this installment.  I will probably have
  184. some new methods for you the next issue, unless I get bored and decide
  185. to drop the whole idea.  Keep in mind that the best ideas are your own.
  186.  
  187.                               
  188.         Remember:  Unprotected code is public domain!
  189.                               
  190.  
  191. []     If anyone has any questions or comments about my series,   []
  192.  []    or some more suggestions for methods that can be added to   []
  193.   []   it, feel free to drop me a note on Landfill BBS              []
  194.  
  195. Downloaded From P-80 International Information Systems 304-744-2253
  196.