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