[Mini Guide]Bypassing the new added debugger detection

06/28/2012 00:04 { Angelius }#1
Link Removed.
I decided that this forum doesn't deserve or appreciate my work and I am not going to support it by releasing/maintaining my work and generating traffic for it.
06/28/2012 09:12 ahmed104#2
there are easiest way
download plugin Anti-Anti-Debug
Who x64
i used Sealth64 and make check with PEB!IsDebugged
anyway thanks with manual bypass
06/29/2012 05:36 xmen01235#3
Tried this but will still cause you a 1day banned. Though the detection takes longer than with the untouched TQanp.dll.
06/30/2012 01:51 { Angelius }#4
Quote:
Originally Posted by ahmed104 View Post
there are easiest way
download plugin Anti-Anti-Debug
Who x64
i used Sealth64 and make check with PEB!IsDebugged
anyway thanks with manual bypass
Its useful for those who works with memory based bots that needs to debug the process in order to work and cannot use a so called plugin to hide it.

Btw Yw.
06/30/2012 04:00 ahmed104#5
ok i understand it
06/30/2012 05:44 romeoromeo#6
took me an hr to understand that i should press CRTL+A ... :D
07/01/2012 05:21 badguy4you#7
Quote:
Originally Posted by romeoromeo View Post
took me an hr to understand that i should press CRTL+A ... :D
But your insist on learning is really appreciated
07/03/2012 03:28 Silent-Death#8
Quote:
Originally Posted by badguy4you View Post
But your insist on learning is really appreciated
come on man.. don`t be like that.. This is the kind of attitude that got epvp to this crappy state.

Quote:
Originally Posted by romeoromeo View Post
took me an hr to understand that i should press CRTL+A ... :D
lol.. happens =)
07/05/2012 03:21 shitboi#9
I guess i am too foolish to follow this tutorial, lol... Any even more idiot proof method?

I tried forcing "RETN 0" in the IsDebuggerPresent API located in KernalBA, but It seems that this dll is used all the time. lol
07/05/2012 16:25 _fobos_#10
Quote:
Originally Posted by shitboi View Post
I guess i am too foolish to follow this tutorial, lol... Any even more idiot proof method?

I tried forcing "RETN 0" in the IsDebuggerPresent API located in KernalBA, but It seems that this dll is used all the time. lol
If you're plan is to bypass IsDebuggerPresent, then this is not the way to go about it. Try an msdn search on what IsDebuggerPresent returns.
However I can tell you right of the bat that patching that is not going to help you much. But it is however an anti-debugging technique still widely used, so it can't harm to learn how to patch it.

If you do a quick MSDN search you will see that this function is a bool, so it will return true or false, that is for user-mode debuggers (like Ollydbg)
Which I guess is more popular here in the CO scene. So if your memory based bot uses debugging techniques and you want to bypass IsDebuggerPresent you will want that call to return a value of false. Makes sense right?

Now what you really need to know when debugging is what all the registers are for, which I don't think anyone in this forum has explained properly.
Anyway a quick google search about registers will get you everything you need to know about registers.

Either way, after that call EAX will have a value of either 1 or 0 depending on the outcome of IsDebuggerPresent, did it return true or false?
So a quick fix is just to patch EAX with 0, by doing a mov eax,0. Since there is most likely a test or compare statement underneath it to figure out what to do next.

However like I said in the beginning this will not help you against that 1 day restriction, and to be honest what is shown in the video is not enough either :) However a google search for "Anti-debugging techniques" will be enough.
07/05/2012 20:53 { Angelius }#11
@ _fobos_

A- By doing what i did in that video you are simply bypassing all the functions/anti-debugging techniques that the tqanp.dll contains just like its never been loaded into the process...

B- The point of this thread is to give the memory based bots that uses the debugging techniques the ability to Attach/debug conquer.exe again

C- Disabling the IsDebuggerPresent function will not do you any good and it will not let you attach or debug conquer.exe

D- seems like you have come to a conclusion that what i did in that video should stop the 1 day restriction thing... so let me correct you by saying that it has nothing to do with it, and that the 1 day restriction thing is server sided

@ shitboi

If your intention is to debug conquer.exe using something like ollydbg there is some library's/plugins that can hide the debugger for you so you don't have to do any of this.
07/05/2012 22:51 shitboi#12
Thanks for you reply angelius... I have already figured out what needed to be done. I most debug using CheatEngine (though most of you will disagree), but i simply can't get olly to do real time debugging on Conquer. Anyways my problem is solved for now.


Edit:

I concur with the statement that disabling IsDebuggerPresent doesn't do much.
07/05/2012 23:43 IAmHawtness#13
Quote:
Originally Posted by { Angelius } View Post
C- Disabling the IsDebuggerPresent function will not do you any good and it will not let you attach or debug conquer.exe
Works fine here, I can easily attach Cheat Engine to Conquer without doing any modifications at all.
The reason that the IsDebuggerPresent patch is needed is for when you're debugging Conquer.exe during launch. If you don't patch IsDebuggerPresent, you won't be able to launch Conquer through a debugger.

Quote:
Originally Posted by shitboi View Post
Thanks for you reply angelius... I have already figured out what needed to be done. I most debug using CheatEngine (though most of you will disagree), but i simply can't get olly to do real time debugging on Conquer. Anyways my problem is solved for now.
Cheat Engine is actually pretty damn good, I tend to use it more than Olly to be honest.
07/06/2012 00:55 Zeroxelli#14
Quote:
Originally Posted by IAmHawtness View Post
Works fine here, I can easily attach Cheat Engine to Conquer without doing any modifications at all.
The reason that the IsDebuggerPresent patch is needed is for when you're debugging Conquer.exe during launch. If you don't patch IsDebuggerPresent, you won't be able to launch Conquer through a debugger.



Cheat Engine is actually pretty damn good, I tend to use it more than Olly to be honest.
Touche to the cheat engine part. I've recently started using it instead of Olly for some things, though I'm pretty used to Olly. CE has always been super powerful for things like this, and it has a shitload of useful functions packed into one program.
07/06/2012 00:58 _fobos_#15
Quote:
Originally Posted by { Angelius } View Post
@ _fobos_

A- By doing what i did in that video you are simply bypassing all the functions/anti-debugging techniques that the tqanp.dll contains just like its never been loaded into the process...

B- The point of this thread is to give the memory based bots that uses the debugging techniques the ability to Attach/debug conquer.exe again

C- Disabling the IsDebuggerPresent function will not do you any good and it will not let you attach or debug conquer.exe

D- seems like you have come to a conclusion that what i did in that video should stop the 1 day restriction thing... so let me correct you by saying that it has nothing to do with it, and that the 1 day restriction thing is server sided

@ shitboi

If your intention is to debug conquer.exe using something like ollydbg there is some library's/plugins that can hide the debugger for you so you don't have to do any of this.
A) Thing is, it does get loaded in the process. What function gets called to load a DLL into memory? Exactly, patch that if you don't want it loaded into memory.

B) It doesn't, since there is no use to attaching a bot to a client if you can not bot because you get restricted.

C) Wrong there, I can debug just fine, I can run Conquer thru a debugger just fine as well. And I can bot cliented just fine as well.

D) I have come to a conclusion? Seems to me you have come to the conclusion that I came to a conclusion, I simply stated that it simply wouldn't help him to get past the 1 day restriction. And the restriction being completely server sided is also false.

So now let's all get to the conclusion that telling someone he is wrong is a no go.