programmers resources
  http://www.intel-assembler.it/  (c)2017 intel-assembler.it   info@intel-assembler.it
 
Search :  
Lingua Italiana    English Language   
Index
 
just an empty assembly space
just an arrow Intel Platform
just an arrow Article & Guides
just an arrow Download Software


23/01/2009 Featured Article: How to remove Buzus Virus (permalink)




:::3210396:::
Bottone Scambio Directory Pubblicitaonline.it
Home Page | Articles & Guides | Download | Intel Platform | Contacts

Google
 


Bookmark and Share
Download 
Tell a friend



Code Concealment

Come sigillare il proprio codice

(by demogorgon)

Questo interessante articolo mostra tecniche assembler di protezione anti-debugger con attenzione ai principali debugger disponibili (TD,SI,Debug).
This article is online from 5045 days and has been seen 4989 times


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 []


Top
Download 
Tell a friend
Bookmark and Share



Similar Articles

Anti Debugging Tricks Analysis
Notes by M.Forrest on 'Anti Debugging Tricks'
(by Michael Forrest)

Anti Debugging Tricks Rel.2
Tecniche di Antidebug in assembler
(by Inbar Raz)

Anti Debugging Tricks Rel.5
Antidebugging techniques
(by Inbar Raz)

Anti-Debugger Techniques
Assembler techniques for protecting code
(by Anonymous)

Applied Binary Code Obfuscation
Obfuscation in assembler
(by N.George, G.Charalambous)

Binary Protection Schemes
Code Protection under Linux
(by Andrew Griffiths)

Keep Your Code Hidden From Prying Eyes
Tecniche di back-jump nel codice
(by Demogorgon)

Reverse engineering: Anti-cracking Techniques
How to protect your code in 24 pages
(by N.George, G.Charalambous)

Windows Anti-Debug Reference
Several anti-debugging techniques used on Windows
(by Nicolas Falliere)

Writing Self-Modifying Code
Utilizing Advanced Assembly techniques
(by Russell Sanford)

 Tags: antidebug


webmaster jes
writers rguru, tech-g, aiguru, drAx

site optimized for IE/Firefox/Chrome with 1024x768 resolution

Valid HTML 4.01 Transitional


ALL TRADEMARKS ® ARE PROPERTY OF LEGITTIMATE OWNERS.
© ALL RIGHTS RESERVED.

hosting&web - www.accademia3.it

grossocactus
find rguru on
http://www.twitter.com/sicurezza3/
... send an email ...
Your name

Destination email

Message

captcha! Code