when ever i try attaching ollydbg and other debuggers to this program , it will detect the debugger instantly (... well after i press f9 to resume the process when olly breaks on attaching) and also this is not the work of IsDebuggerPresent because i used the hide debugger plugin + i made a hook on that api to return 0 when testing other debuggers on it. CheckRemoteDebuggerPresent also wont be a problem as i dont have winxp sp1 (just retail)... so any ideas ?

edit:... oh yeah... i cant use softice cuz when i load it up it will use 100% cpu power and then eventually crash (winxp; driver suite 2.7 and also i tested driver suite 3 too).

You have not stated the information you were required to state in the FAQ and in your signature block. There are several processes which are used to detect debuggers, from the simple to the complex. You need to do some of your own home work and "search" for answers "before" you ask. For example, there are some protection systems which search various places for the "name" of the debugger or its window title and changing the name of the exe and/or searching for the window title and changing that also will prevent some protection systems from spotting your debugger.

Using "detect + debugger" (without the quotes) with the SEARCH button, I got 45 entries here you should review. You could also use "ollydbg + detect" (without the quotes) which gave 10 results you should check.

Regards,

it doesnt detect anything to do with titlename/classname b/c i renamed with a hexeditor + i also tried renaming the title with SetWindowText. also as mentioned, i tried this with other debuggers (built into cheat engine and tsearch) and also some other ones like PEBrower Pro.. oh yeah, the protection is asprotect 1.23RC4, tools are: ollydbg XD, i have read tutorials on common debugger detection, meltice, int68, int41, etc, but they most concerns softice and kernel mode debuggers which im not using (though i wish i could use softice again..) and the detection methods for user-mode debuggers, IsDebuggerPresent, that checkremote one and NtQueryInformationProcess, i used an old dll(which is injected) which i made which writes

IsDebuggPresent:
xor eax,eax
ret

and hooks NtQueryInformationProcess to always return 0x0 if the information is requesting for the debugport

And did you read the threads here on detecting Olly mentioned in my previous post? You see how much more informative your earlier post would have been if you had included, as required by the posting guidelines, the steps you had already tried and the searching you had already done?

Using "ollydbg detect* + asprotect" ( again without the quotes) I got 24 hits in various languages. Have you done such a focused search? Notice the use of the "*" symbol to catch both "detect" and "detection" and "detected". A useful tool for searching.

Regards,

the point is that its not only ollydbg that gets detected, because i tried other usermode debuggers besides ollydbg, so detection techniques have to be general, and i only can think of 3 methods which i mentioed above(i believe that asprotect uses the IsDebuggerPresent detection, as i remember from unpacking asprotect b4) and concerning, seting up an exception to crash olly, olly can pass exceptions on to the debuggee plus no expections are raised after resume it so thats not a valid detection method.

i looked into those articles in google and found the olly detection mostly to do with FindWindow and Process32First/Process32Next, which is easy to trick... FindWindow=hexedit, Process32First/Process32Next=hook NtQuerySystemInformation, or hook the actual api, or unlink ollydbg from the double linked list containing all active processes. but as mentioned, the method of detection is general to all user-mode debuggers, so its not valid.

theres a lot more than 3 methods to detect a debugger..

yes.. but most methods concern softice and kernelmode debuggers... thats y im asking, what methods exist for usermode debugger

with Get/SetThreadContext, an userapp can read various debug regs, which are used by most debuggers.

i would try to hook GetThreadContext and manipulate its result

Normally it wouldn't even have to use these API calls to get them, it could simply catch them directly from the stack in an exception handler, right? In that case this hook wouldn't work...

And have you considered dissassebly of the exe to see if you can follow the dead listing to determine where the debugger "detection" is occurring? As an alternative, have you attempted to intercept the start of the program and step through it until it detects the presence of the debugger? In other words, are you taking a proactive approach to helping yourself?

Regards,

Hi guys,

My first post here - normally, due to my low logging frequence everything is answered - pleased to meet you all! .

@kbot:

Asprotect doesnt have sophisticated anti-debug on its newest versions, perhaps the packer is not this one and has used some trick to hide itself (sections renaming and some code at the entry point, say). If i recall, you should be able to attach to asprotected targets after they run... (not sure).

Anyway, when you hook a procedure you have to keep in mind that the packer will emulate the first instructions and so it's quite likely to miss the call. Indeed, it's possible to emulate (in user-level) until you reach the "int 2E". So, i'd be more careful with hooking...

The latest asprotect has a very improved emulation. I mean, improved with respect to the previous one. Indeed, seems that svkp has "imitated" it (according to what i've read at their web).

Hmmm... if the target is asprotect i think you'd better debug into.

Regards,
havok.