Copy Link
Add to Bookmark
Report
40Hex Issue 07 File 002
40Hex Number 7 Volume 2 Issue 3 File 002
% Code Concealment %
% -Demogorgon/PHALCON/SKISM %
In the previous issue of 40hex, I wrote about how a programmer can
keep his code from being stolen by others. Ways of doing this are
endless, and I will talk about a few more methods in this installment.
Part I : Fun with int3
Part II : Fun with int8
Part III: The Prefetch
Part_I : Fun with int3
Int three is the debugger breakpoint. Every time a debugger breaks
while tracing through a chunk of code, it will call int3. Int3 is
called after every instruction is executed in trace mode, and after
a breakpoint is reached. Note that protected mode debuggers do not
execute int3 in trace mode, but they will break when int3 is called from
your code. You can use this to your advantage. Simply install a new
handler for int3 and it will execute instead of the debugger if a thief
tries to trace through your program.
start: mov ax, 2503h
mov dx, offset int_start
int 21h ;put in the new handler at ds:dx
... ;rest of real code here
int 20h
text db 'Smoke Mah Ass!$'
int_start:
mov ah, 9
mov dx, offset text
int 21h
int 20h
As soon as the first int21 call in this program is made, the code
at int_start will execute if it is being traced in a debugger.
Otherwise, the int call will be ignored and your normal code will
execute. The program can do whatever you want if a debugger is found.
For example, you can format the hard drive or display a message. The
possabilities are endless. By the way, it might be wise to restore the
old interrupt handler before you exit the program, because it is bad
programming practice to leave interrupts pointed into non-allocated
memory.
compatability:(works against all debuggers marked with an X)
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X
-------------------------------------------------------------------------
Part_II: Fun with int8
The next segment will show you how to make a program nearly
impossable to trace. The concept is simple. All you need to do is
place the main body ofyour program into an int8 handler. Int8 is the
timer interrupt, and it is called 18.2 times a second. Debuggers do not
execute int8, so whatever you put there will only go when it is run from
dos. The only drawback to this is a short delay before the main program
is executed. It will probably go unnoticed, in most cases. Here is
some code:
thyroid:mov ax, 3508h
int 21h ;get int8 handler
mov word ptr [int_store], bx ;store it
mov word ptr [int_store+2], es
mov dx, offset prog_start
mov ah, 25h
int 21h ;install new int8 handler
yip: cmp flaag, 1
jne yip ;wait for int8 to be called
;int8 must set the flaag to 1
push bx
pop dx ;restore
push es ;old
pop ds ;int8
int 21h ;handler
int 20h
flaag db 0
int_store dd ?
prog_start:
_main_program proc far
;save all the necessary registers here
;... your code
mov flaag, 1
;restore the registers
jmp dword ptr [offset int_store] ;chain to real int8 handler
_main_program endp
This code is quite useful in that if some guy tries to trace
through it, he will be stuck forever in the 'yip' loop. The main code
will never be executed. If he tries to get out of the loop by
'executing to' the next instruction, he will end up running the entire
program. No debugger I know of can trace through this, because int8 is
not called from within the debugger.
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X X X
-------------------------------------------------------------------------
Part_III: The Prefetch
My favorite way to confuse debuggers is to mess with the prefetch
queue. All intel processors have a small queue where the next
instructions to be executed are stored. In this way, the CPU does not
have to waste clock cycles by fetching the next instruction, except in
the cases of branching instructions such as jmps and calls. The next
chunk of code makes use of this:
eapple: mov ah, 9
mov word ptr [offset ear_lobe-2], offset sukk_debug
mov dx, offset text
ear_lobe:
int 21h
int 20h
text db 'snee!$'
sukk_debug db 0Ah, 0Dh, 09h, 'blow a goat!', 07h, 0Ah, 0Dh, '$'
All this program does is print out a text string. If it is run
from dos, it will print out 'snee!'. If it is traced through by any
debugger, however, it will print 'blow a goat!', and beep the PC speaker
(07h is ctrl-g). Let me explain how this works.
When any chunk of code is executed by dos, the first few bytes are
sent into the prefetch queue. The actual number of bytes depends on the
model of intel chip, and what year it was made in. My computer is a
386DX-20 (early model), which has a 16 byte prefetch. Be sure to check
your code on several machines to insure compatability.
When the second instruction is reached, it places the offset of
sukk_debug into the next instruction. That is, the next instruction
becomes 'mov dx, offset sukk_debug', rather than 'mov dx, offset text'.
The system memory will be changed, but the prefetch will not, therefore
only a debugger will respond to the new code. Dos will execute it as if
the instruction had never changed, because the instruction will already
have been loaded into the prefetch. This theory can be used, with a
little modification, in order to branch to various subroutines, rather
than just printing out different text. One interesting application of
this is to use the prefetch area to store registers. This way, a person
debugging your code can not simply nop it out, because it will be
referred to later on. In fact, you can even put the stack on the
prefetch. Try to debug through the following fragment, and watch what
happens:
nee: mov ax, 4Ch
mov dx, offset text
mov sp, offset fin_rot
push ax
mov ah, 9
fin_rot:int 21h
pop ax
int 21h
text: db 'Duck is proud of her feet. They can catch things.$'
If you run it through debug, the entire program will be corrupted
as soon as you move the stack pointer. This is because the debug code
uses the stack and expects it to be in a safe location. If you run it
through soft ice, the code will be corrupted as soon as you push ax.
The stack area will be overwritten when int21 is executed, because the
interrupt uses the stack. However, in this example, the instruction
pointer will already be beyond this area, so the program will execute
normally.
Remember not to place the stack past any calls, because then the
prefetch would have to be reloaded after the main program was returned
to, and the instructions that were there before will be gone.
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X X X
-------------------------------------------------------------------------
That about wraps it up for this installment. I will probably have
some new methods for you the next issue, unless I get bored and decide
to drop the whole idea. Keep in mind that the best ideas are your own.
% % % % % % % % % % % % % % % % % % % % % %
Remember: Unprotected code is public domain!
% % % % % % % % % % % % % % % % % % % % % %
[] If anyone has any questions or comments about my series, []
[] or some more suggestions for methods that can be added to []
[] it, feel free to drop me a note on Landfill BBS []
+++++
