This is supposed to be some anti-debugging code but it isn't working right.
When it's run, it immediately opens open Ollydbg.
When I step through it, it runs into problems at the call eax instruction.
Is there a fix for this?
Thanks.
.DATA
our_process_handle dd -1
.CODE
start:
lea eax,our_process_handle
push eax
mov ebx,esp
push 0
push 4
push ebx
push 7
push dword ptr
mov eax,077F5BDD8h
call eax ; execute NtQueryInformationProcess
pop ecx
test eax,eax
jl finish
cmp ecx,0
jge we_are_not_debugged
;int 3 ; yes we are debugged!
we_are_not_debugged: ; no debugger detected
finish:
invoke ExitProcess,0
end start
When it's run, it immediately opens open Ollydbg.
When I step through it, it runs into problems at the call eax instruction.
Is there a fix for this?
Thanks.
.DATA
our_process_handle dd -1
.CODE
start:
lea eax,our_process_handle
push eax
mov ebx,esp
push 0
push 4
push ebx
push 7
push dword ptr
mov eax,077F5BDD8h
call eax ; execute NtQueryInformationProcess
pop ecx
test eax,eax
jl finish
cmp ecx,0
jge we_are_not_debugged
;int 3 ; yes we are debugged!
we_are_not_debugged: ; no debugger detected
finish:
invoke ExitProcess,0
end start
Take a few steps back and try to get an idea of The Bigger Picture.
Just a quick question:
Are you sure of the address of NtQueryInformationProcess?
The reason that I ask is because your routine does not show the method you used to obtain this address (077F5BDD8h)
Are you sure of the address of NtQueryInformationProcess?
The reason that I ask is because your routine does not show the method you used to obtain this address (077F5BDD8h)
I have attached the article by Peter Ferrie, Senior Anti-Virus Researcher, Microsoft Corporation that the code came from.
Andy
Andy
That's where I thought you got your code from; however, unless I missed that part I did not see a hard coded address for the call into NtQueryInformationProcess (listed in Section II Sub Section d paragrah iii)
If you are going to hard code this address then you will need to have a section of code that goes out and finds its address on the system you are running
If you are going to hard code this address then you will need to have a section of code that goes out and finds its address on the system you are running
That's where I thought you got your code from; however, unless I missed that part I did not see a hard coded address for the call into NtQueryInformationProcess (listed in Section II Sub Section d paragrah iii)
If you are going to hard code this address then you will need to have a section of code that goes out and finds its address on the system you are running
I finally got it fixed.
The original code had the wrong API address for NTQuery...
I attached the .exe.
I would appreciate if it could be tested on other NT versions besides XP Sp2.
Thanks.
; anti2.asm Anti-debug
;
.386
.MODEL FLAT, STDCALL
OPTION CASEMAP: NONE
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\advapi32.inc
include \masm32\include\shlwapi.inc
include \masm32\macros\macros.asm
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib
includelib \masm32\lib\advapi32.lib
includelib \masm32\lib\shlwapi.lib
.DATA
our_process_handle dd -1
szFile_OK db "Not being debugged.",0
szDebugged db "Application being debugged!!",0
szAppName db "Box",0
.CODE
start:
lea eax,our_process_handle
push eax
mov ebx,esp
push 0
push 4
push ebx
push 7
push dword ptr
mov eax,07C90E01Bh ; API address - Used ASM2OP.exe
call eax ; execute NtQueryInformationProcess
pop ecx
test eax,eax
jl finish
cmp ecx,0
jge Not_debugged
invoke MessageBox, NULL, addr szDebugged, addr szAppName,MB_OK
invoke ExitProcess,0
Not_debugged: ; no debugger detected
invoke MessageBox, NULL, addr szFile_OK, addr szAppName,MB_OK
invoke ExitProcess,0
finish:
end start
I finally got it fixed.
The original code had the wrong API address for NTQuery...
I attached the .exe.
I would appreciate if it could be tested on other NT versions besides XP Sp2.
The only time it's acceptable to hardcode addresses is if you're writing shellcode... and shellcode isn't accepted around here, for pretty obvious reasons.
XP ENU SP0: does not work.
XP ENU SP1: does not work.
XP ENU SP2: works.
XP RUS SP2: works.
XP ENU SP3: does not work.
2003 ENU SP0: does not work.
2003 ENU SP1: does not work.
There ain't such thing as right address for NtQueryInformationProcess. How do you think, why we still use old-fashioned import tables to dynamically link to DLLs (aside from being completely nuts)?
Using function that may be altered or unavailable in future versions of Windows is the sure path to problem. Calling it in obscure/viral way only makes it worse. With the same (or slightly greater) level of success (or failure) you may call service dispatcher via call [7FFE0300]/int 2E/sysenter.
Are you trying to develop working anti-debugging scheme, or just trying all googlable variants? If the former is true, you have to be smarter than most of crackers' community (they're hard-boiled and armed to teeth). If the latter, hmm... all documented anti-debugging tricks are defeated by definition.
"If it runs, it can be hacked."
XP ENU SP1: does not work.
XP ENU SP2: works.
XP RUS SP2: works.
XP ENU SP3: does not work.
2003 ENU SP0: does not work.
2003 ENU SP1: does not work.
There ain't such thing as right address for NtQueryInformationProcess. How do you think, why we still use old-fashioned import tables to dynamically link to DLLs (aside from being completely nuts)?
Using function that may be altered or unavailable in future versions of Windows is the sure path to problem. Calling it in obscure/viral way only makes it worse. With the same (or slightly greater) level of success (or failure) you may call service dispatcher via call [7FFE0300]/int 2E/sysenter.
Are you trying to develop working anti-debugging scheme, or just trying all googlable variants? If the former is true, you have to be smarter than most of crackers' community (they're hard-boiled and armed to teeth). If the latter, hmm... all documented anti-debugging tricks are defeated by definition.
"If it runs, it can be hacked."
There ain't such thing as right address for NtQueryInformationProcess. How do you think, why we still use old-fashioned import tables to dynamically link to DLLs (aside from being completely nuts)?
Using function that may be altered or unavailable in future versions of Windows is the sure path to problem. Calling it in obscure/viral way only makes it worse. With the same (or slightly greater) level of success (or failure) you may call service dispatcher via call [7FFE0300]/int 2E/sysenter.
Are you trying to develop working anti-debugging scheme, or just trying all googlable variants? If the former is true, you have to be smarter than most of crackers' community (they're hard-boiled and armed to teeth). If the latter, hmm... all documented anti-debugging tricks are defeated by definition.
"If it runs, it can be hacked."
Thanks baldr for the feedback.
There is no reason to think the worst. Try to think positive.
I am learning and that involves making some mistakes along the way.
Take care,
Andy
Somewhat perverted way to learn. May be you should take easier tutorials to examine? ;-)
It seems more like you are copy-pasting code, for whatever reason, rather than learning.