Index
> Windows > Anti-Debugger |
| Author |
|
|
typedef 03 Sep 2011, 04:41
|
|||
03 Sep 2011, 04:41 |
|
|
Enko 17 Oct 2011, 15:31
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. |
|||
|
17 Oct 2011, 15:31 |
|
|
Kazyaka 17 Oct 2011, 19:15
Thanks Enko. It's good article but from November 2008.
Don't you think it's little too old? Have you some newer? |
|||
|
17 Oct 2011, 19:15 |
|
|
Enko 17 Oct 2011, 19:32
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. |
|||
|
17 Oct 2011, 19:32 |
|
|
Goplat 17 Oct 2011, 21:12
Kazyaka wrote: Worries me it that we can see every operation of our program. |
|||
|
17 Oct 2011, 21:12 |
|
|
AsmGuru62 18 Oct 2011, 13:59
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! |
|||
|
18 Oct 2011, 13:59 |
|
|
Kazyaka 18 Oct 2011, 18:07
Guys thank you for your replies! They're very useful for me.
|
|||
|
18 Oct 2011, 18:07 |
|
|
f0dder 20 Oct 2011, 18:11
Kazyaka wrote: Thanks Enko. It's good article but from November 2008. 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. _________________  - carpe noctem |
|||
|
20 Oct 2011, 18:11 |
|
|
typedef 29 Apr 2013, 03:50
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.
|
|||
|
29 Apr 2013, 03:50 |
|
|
bitRAKE 29 Apr 2013, 06:13
Are you talking about this:
http://board.flatassembler.net/topic.php?p=140791#140791 ...and the IsDebuggerPresent flag is in PEB. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
29 Apr 2013, 06:13 |
|
|
typedef 29 Apr 2013, 10:10
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. |
|||
|
29 Apr 2013, 10:10 |
|
|
xDOBORAx 16 Jul 2013, 09:45
just use themida protect or same thing
|
|||
|
16 Jul 2013, 09:45 |
|
|
machinecoder 31 Jul 2013, 13:30
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 |
|||
|
31 Jul 2013, 13:30 |
|
|
ACP 31 Jul 2013, 14:10
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. |
|||
|
31 Jul 2013, 14:10 |
|
|
machinecoder 31 Jul 2013, 14:23
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. 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. |
|||
|
31 Jul 2013, 14:23 |
|
|
ACP 01 Aug 2013, 23:36
machinecoder wrote:
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... |
|||
|
01 Aug 2013, 23:36 |
|
|
machinecoder 02 Aug 2013, 11:19
The ultimate protection is ....
If you dont want some data stolen, or your code ripped, dont upload it onto the internet.  |
|||
|
02 Aug 2013, 11:19 |
|
|
patchariadog 23 Oct 2013, 15:05
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. |
|||
|
23 Oct 2013, 15:05 |
|
|
ACP 23 Oct 2013, 17:29
patchariadog wrote: dont use the isdebuggerpresent api because debuggers will easily pickup on api calls. This is what I use for my programs. 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... |
|||
|
23 Oct 2013, 17:29 |
|
< Last Thread | Next Thread > |
Forum Rules:
|