flat assembler
Message board for the users of flat assembler.

Index > Windows > Anti-Debugger

Author
Thread Post new topic Reply to topic
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
Post 03 Sep 2011, 04:41
View user's profile Send private message Reply with quote
Kazyaka



Joined: 10 Oct 2011
Posts: 62
Location: Earth
Kazyaka
Hello,
I'm working on "Anti-Debugger" project for FASM.

Here is my code:
Code:
; --- Anti-Debugger  by Kazyaka ---
include 'win32ax.inc'

.code
  start:
  invoke IsDebuggerPresent
  cmp eax, 0
  jne Debugger
        invoke  MessageBox,HWND_DESKTOP,"Debugger isn't running","Test", MB_OK
        invoke  ExitProcess,0
    Debugger:
    invoke  MessageBox,HWND_DESKTOP,"Debugger", "Error!", MB_ICONHAND
    invoke  ExitProcess,0
.end start    

If you compile and run this program you should see this messagebox:
Image

OK.
Now run it from some debugger, i. e. OllyDbg. You should see this text:
Image

Well done! It works fine.

So where is problem?
Now run it normally. After run CheatEngine and check ASM code. You'll see something like that (I'm using a little old version of CE):
Image
Worries me it that we can see every operation of our program.

Now my question:
How can I detect ASM debugger or protect my apps from programs like a CheatEngine?

PS: Looping IsDebuggerPresent or other standard functions doesn't work.
Post 17 Oct 2011, 14:44
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
here you can get some ideas:
http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx

my personal sugestion, don't bother to make somthing complicated on finding a debugger, if some pro wan't to crack your code it will take him not more than 5 min.

This things work only for noob crackers, anything will work except isDebuggerPresent, its too well documented.
Post 17 Oct 2011, 15:31
View user's profile Send private message Reply with quote
Kazyaka



Joined: 10 Oct 2011
Posts: 62
Location: Earth
Kazyaka
Thanks Enko. It's good article but from November 2008.
Don't you think it's little too old? Have you some newer?
Post 17 Oct 2011, 19:15
View user's profile Send private message Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
Some crack tutorials are maded for windows 95, so 2008 is actually very updated.
And not much has changed.

The only new technique not explained in the tutorial is using VirtualMachines, like you implement your own hypervizyer where you run your protected exe. (what themida does)

Other preaty anoying teqnique is well explaned by comrade on his wep page:
http://comrade.ownz.com/docs/fasm.html
(code obfuscation)

its actually fasm related and is implemented as simply as doing copy past.
Post 17 Oct 2011, 19:32
View user's profile Send private message Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat
Kazyaka wrote:
Worries me it that we can see every operation of our program.

Now my question:
How can I detect ASM debugger or protect my apps from programs like a CheatEngine?
Run your program on your own computer only. If it's running on someone else's computer, he can always patch out whatever anti-debugger checks you put in.
Post 17 Oct 2011, 21:12
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
AsmGuru62
Make two layers of defense:
1st is a simple Dialog Box, which says that EXE has been compromised.
2nd is silently checking if 1st has been patched.

Of course, happy hacker will see that he patched the EXE and dialog is no longer appearing. What he will not be expecting is that 2nd layer will begin annoying things, like:

A) On every mouse click VirtualAlloc some pages and 'forget' to free them.
B) Paste only 95% of data on Clipboard.
C) When user press ENTER in a dialog box randomly skip the call to EndDialog().

... and so on.

Happy Coding!
Post 18 Oct 2011, 13:59
View user's profile Send private message Send e-mail Reply with quote
Kazyaka



Joined: 10 Oct 2011
Posts: 62
Location: Earth
Kazyaka
Guys thank you for your replies! They're very useful for me.
Post 18 Oct 2011, 18:07
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Kazyaka wrote:
Thanks Enko. It's good article but from November 2008.
Don't you think it's little too old? Have you some newer?
You have two options:

1) realize what you're attempting to do is futile, and spend your energy on something worthwhile.
2) spend several years researching anti-debugging, reverse-engineering methods, malware, et cetera... and then spend a good amount of your time keeping up the cat and mouse game.

If you want to do something even modestly successful today, you'll need solid compiler and virtual machine knowledge, and a fair amount of specific operating system knowledge as well.

_________________
Image - carpe noctem
Post 20 Oct 2011, 18:11
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
Bump... There was a snippet somewhere (I have to find it again) that automatically detected a debugger without using any API and therefore would switch to a different operating bit mode. So a 32 bit app would switch to 64 bit and vice versa. I remember OllyDbg going haywire.
Post 29 Apr 2013, 03:50
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2940
Location: vpcmipstrm
bitRAKE
Are you talking about this:

http://board.flatassembler.net/topic.php?p=140791#140791

...and the IsDebuggerPresent flag is in PEB.

_________________
¯\(°_o)/¯ unlicense.org
Post 29 Apr 2013, 06:13
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
Nope. The following code. It was used mostly in the Malware scene, called Heaven's Gate. It's hard to debug the code lol. But runs perfectly without debugger.

It's explained here (+ more stuff): http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/

Here's an implementation showing processor mode switching.

Code:
include 'win32ax.inc'

.data
    nt32bit du 'Native 32bit',0
    nt64bit du 'Native 64bit',0
.code


proc bits64
     use64
    mov         rcx,  $0001'0002'0003'0004         ; some 64 bit stuff
    call        @f
    du          'WoW64',0
@@:                                       ; get pointer or do mov rax, [@label]
     pop        rax ; return address (pointer to string)
     use32
     retf
endp



CALL_GATE64 EQU $33     ; The call gate to 64 bit mode


start:

     MOV        AX, CS
     CMP        AL, $1B ;1Bh native 32 bit
     JE         native32bit

     CMP        AL, $33 ;33h native 64 bit
     JE         native64bit

     CMP        AL, $23 ; WoW64
     JE         wow64

     jmp        sayonara

wow64:
     call       CALL_GATE64:bits64         ; switch to 64 bit
     invoke     MessageBoxW, 0, eax, 0, 0
     jmp        sayonara

native64bit:
     invoke     MessageBoxW, 0, nt64bit, 0, 0
     jmp        sayonara

native32bit:
     invoke     MessageBoxW, 0, nt32bit, 0, 0
     jmp        sayonara

sayonara:
    invoke ExitProcess, 0

.end start


    


Try to debug that code and see where you end up. (Access violation) as explained in the linked article.

The trick is 32 bit debuggers fail after switching the processing mode.
Post 29 Apr 2013, 10:10
View user's profile Send private message Reply with quote
xDOBORAx



Joined: 09 Jun 2013
Posts: 24
xDOBORAx
just use themida protect or same thing
Post 16 Jul 2013, 09:45
View user's profile Send private message Reply with quote
machinecoder



Joined: 07 Apr 2013
Posts: 27
machinecoder
I strongly urge you not to use "themida protect", as for every "protector" there is an "unprotector", they are to well known and to easy to remove.

I had the same problem, so I wrote this code to baffle disassemblers
Code:
invoke  LoadLibraryA,kernel32
mov     [hlib],eax
mov  eax,str_isdebuggerpresent XOR $0000FFFF
xor eax,$0000FFFF
invoke  GetProcAddress,[hlib],eax
mov     [isdebuggerpresent],eax
mov  eax,str_exitprocess XOR $0000FFFF
xor eax,$0000FFFF
invoke  GetProcAddress,[hlib],eax 
mov     [exitprocess],eax
invoke  FreeLibrary,[hlib]

mov  eax,isdebuggerpresent XOR $0000FFFF
xor eax,$0000FFFF
call    dword [eax]
mov [debug_present],eax
or      eax,eax      
jz   .proceed
mov  eax,exitprocess XOR $0000FFFF
xor eax,$0000FFFF
push dword 0
call    dword [eax]
.proceed:

The rest of your program....

...
...
...

kernel32 db 'kernel32',0
str_isdebuggerpresent db 'IsDebuggerPresent',0
str_exitprocess db 'ExitProcess',0
exitprocess dd ?
isdebuggerpresent dd ?
debug_present dd ?    

Completely hides your protection routine, not only in a disassembler,
but also hides from resource hackers the fact that you are
calling "isdebuggerpresent" from your code at all.


Last edited by machinecoder on 31 Jul 2013, 14:12; edited 1 time in total
Post 31 Jul 2013, 13:30
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
You are just hiding the call from import list in PE file but it does not protect from simple hijacking IsDebuggerPresent API function by inserting breakpoint at the beginning of it.

Anyway if anyone is seriously considering IsDebuggerPresent in 2013 as anti-debugger mechanism than he is seriously wrong. The above code can't be consider a serious protection.
Post 31 Jul 2013, 14:10
View user's profile Send private message Reply with quote
machinecoder



Joined: 07 Apr 2013
Posts: 27
machinecoder
ACP wrote:
You are just hiding the call from import list in PE file but it does not protect from simple hijacking IsDebuggerPresent API function by inserting breakpoint at the beginning of it.

Anyway if anyone is seriously considering IsDebuggerPresent in 2013 as anti-debugger mechanism than he is seriously wrong. The above code can't be consider a serious protection.


I answered "Kazyaka" question, how to hide the call to "isdebuggerpresent" from a disassembler, the above example does this.

Of course you can still put a break point in at the start of the program, you would of course add to the above example and add extra random instructions like this, to try and make the code unreadable.

Code:
mov edx,$ffee
mov  eax,isdebuggerpresent - 45473 
add edx,ebx
add eax, 45473 
xor edx,eax
call    dword [eax] 
mov [debug_present],eax 
or      eax,eax       
jz   .proceed 
mov  eax,exitprocess + 166 
mov esi,$FF
shr edx,4
add edx,ebx
sub eax,166 
inc edx
push dword 0 
call    dword [eax] 
.proceed: 
    

There is no one easy way to stop a hacker you can only give them a headache and hours of extra work so they give up (hopefully)

you must use my example and keep adding many more methods over that.

There are many levels of hackers you can protect from a "wannabe" but your hosed when a "Boss" hacker comes along.

If you use a protector for example then the hacker doesnt even need to be a programmer, they just need to now how to google "unprotector".

I do not consider the code to be "serious protection", everything can be hacked.

It was intended as an example of "making it harder" to hack.
Post 31 Jul 2013, 14:23
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
machinecoder wrote:

Of course you can still put a break point in at the start of the program, you would of course add to the above example and add extra random instructions like this, to try and make the code unreadable.


I think you misunderstood my post. I was referring to the technique based on circumventing API calls by hooking their entry/exit point. It has nothing to do with code disassembly nor inserting breakpoint at program entrypoint or using Windows debugging API ability to stop in ntdll.dll before even first instruction of program gets executed .

No matter how hard you will try to hide your call it will not only be detected under debugger but also the result of the function will be false if you will control API calls of target process. There are even plugins for debuggers that does exactly this automatically.

machinecoder wrote:
It was intended as an example of "making it harder" to hack.


If you really intend to make it harder than I would suggest eliminating the call to IsDebuggerPresent() and instead inserting IsDebuggerPresent function code into your program after adding some obfuscation. Below is a disassembly of IsDebuggerPresent() for 32bit architecture.

Code:
mov     eax, large fs:18h
mov     eax, [eax+30h]
movzx   eax, byte ptr [eax+2]
    


Just my 2 cents...
Post 01 Aug 2013, 23:36
View user's profile Send private message Reply with quote
machinecoder



Joined: 07 Apr 2013
Posts: 27
machinecoder
The ultimate protection is ....

If you dont want some data stolen, or your code ripped,
dont upload it onto the internet.

Very Happy
Post 02 Aug 2013, 11:19
View user's profile Send private message Reply with quote
patchariadog



Joined: 24 Mar 2013
Posts: 94
patchariadog
dont use the isdebuggerpresent api because debuggers will easily pickup on api calls. This is what I use for my programs.

Code:
;check for debugger
    
mov eax, [fs:30h]
mov eax, [eax+68h]
and eax, 0x70
test eax, eax
jne .debuggerfound
ret

    .debuggerfound:
    invoke ExitProcess,0
    


I have yet to figure out the x64 version of this. When I do I will post it.
Post 23 Oct 2013, 15:05
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP
patchariadog wrote:
dont use the isdebuggerpresent api because debuggers will easily pickup on api calls. This is what I use for my programs.

Code:
;check for debugger
    
mov eax, [fs:30h]
mov eax, [eax+68h]
and eax, 0x70
test eax, eax
jne .debuggerfound
ret

    .debuggerfound:
    invoke ExitProcess,0
    


I have yet to figure out the x64 version of this. When I do I will post it.


There is nothing to figure out: just disassemble IsDebuggerPresent and you will see the code.

Here it is:
Code:
mov   rax,qword ptr gs:[30h]
mov     rcx,qword ptr [rax+60h]
movzx   eax,byte ptr [rcx+2] 
    


Your comment on catching debugging API calls is just a duplicate of what others have said in earlier posts...
Post 23 Oct 2013, 17:29
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.