[Mini Guide]Bypassing the new added debugger detection

[{ Angelius }]

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.

[ahmed104]

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

[xmen01235]

Tried this but will still cause you a 1day banned. Though the detection takes longer than with the untouched TQanp.dll.

[{ Angelius }]

Originally Posted by ahmed104

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.

[ahmed104]

ok i understand it

[romeoromeo]

took me an hr to understand that i should press CRTL+A ...

[badguy4you]

Originally Posted by romeoromeo

took me an hr to understand that i should press CRTL+A ...

But your insist on learning is really appreciated

[Silent-Death]

Originally Posted by badguy4you

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.

Originally Posted by romeoromeo

took me an hr to understand that i should press CRTL+A ...

lol.. happens =)

[shitboi]

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

[_fobos_]

Originally Posted by shitboi

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.

[{ Angelius }]

@ _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.

[shitboi]

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.

[IAmHawtness]

Originally Posted by { Angelius }

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.

Originally Posted by shitboi

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 **** good, I tend to use it more than Olly to be honest.

[Zeroxelli]

Originally Posted by IAmHawtness

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 **** 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.

[_fobos_]

Originally Posted by { Angelius }

@ _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.