Methods to reduce detection?

How are some hacks undetected for quite a while, and others are detected within a day or so? I don't know much about anti-cheat programs, but I do know that encrypting strings help. What "methods" are used, if there are any, to prevent detection?

Another side question:
Does the amount of text/boxes you draw on the screen affect FPS? What are some methods to reduce lag in a menu?(Besides using a timer for PTC; I've done that)

sorry if this is a noob question, I'm still learning C++ and CA Hacking on my spare time.

custom encryption is a big way to stop detection. A lot of people just use the public Xor... if you switched to a private, i'm sure it'd help with detection. Encrypt/Decrypt ALL YOUR TEXT STRINGS, that includes PTC's, Memory addies/bytes, menu strings, menu items, etc.

on top of that. packing your dll helps too.

Other methods would be to try n avoid hard coding classes. Try to get them virtually some how, the less addresses, the less the game notices changes.

Anything your putting on someones screen is gonna cause more RAM/VRAM use and that always means lag. the more fancy d3d, the more text strings, the more stuff you have will always affect something. You can't have 100 d3d squares and have it run the same as having 0

dont use public functions and procedures, Instead get creative and make your own functions and procedures that have the same effect but not the same code.

Originally Posted by supercarz1991

Is UPX a decent packer to use? if I use Themida the file becomes huge..

Originally Posted by Departure

dont use public functions and procedures, Instead get creative and make your own functions and procedures that have the same effect but not the same code.

My knowledge of DirectX programming is VERY BAD atm, so I'll be using public ones till then >_<

Well, here are some things to reduce lag:

Code:

1. For every "new" you have, make sure it is followed by a "delete" or "delete[]"
2. For Console Commands and Memory Hacks, only call them once instead of every frame like almost all public bases do, it greatly reduces lag
3. Make your code clean and efficient (simple rule to always follow)

To decrease detection, follow what the people above said.

Originally Posted by supercarz1991

custom encryption is a big way to stop detection. A lot of people just use the public Xor... if you switched to a private, i'm sure it'd help with detection. Encrypt/Decrypt ALL YOUR TEXT STRINGS, that includes PTC's, Memory addies/bytes, menu strings, menu items, etc.

on top of that. packing your dll helps too.

Other methods would be to try n avoid hard coding classes. Try to get them virtually some how, the less addresses, the less the game notices changes.

Anything your putting on someones screen is gonna cause more RAM/VRAM use and that always means lag. the more fancy d3d, the more text strings, the more stuff you have will always affect something. You can't have 100 d3d squares and have it run the same as having 0

Unless nexon starts to attempt decryption of every possible memory block using the public XOR method, it would still work just fine. But yes, using any encryption will definitely help. I dont know what you mean by "the less addresses", because you can't just magically modify a location in memory without referencing its address in some way. I also fail to understand how if a 3D game can be rendered at 60 fps, some developers manage to cut that in half with a 2D overlay. Other methods you can play around with are polymorphic junk stubs strategically placed throughout your code, and if you really want to have some fun mess around with instruction permutation (modify your code at runtime to other instructions that are logically equivalent).

Originally Posted by Saltine

Unless nexon starts to attempt decryption of every possible memory block using the public XOR method, it would still work just fine. But yes, using any encryption will definitely help. I dont know what you mean by "the less addresses", because you can't just magically modify a location in memory without referencing its address in some way. I also fail to understand how if a 3D game can be rendered at 60 fps, some developers manage to cut that in half with a 2D overlay. Other methods you can play around with are polymorphic junk stubs strategically placed throughout your code, and if you really want to have some fun mess around with instruction permutation (modify your code at runtime to other instructions that are logically equivalent).

What i mean by less addresses is basically offsets. One of the private bases i know of and have seen uses one address for everything. It doesnt go near any others

Like others already stated, encrypt strings. Avoid using public code when possible. Write your own code or look at existing code and modify it in different ways. Themida generating huge files shouldn't be a problem, even if you intend to release on here. We are still talking about less than 1 MB even with a complex hack and virtualization switched on. Only downside with themida is that it's known to mess up the files if you go all paranoid with settings, you may need to repack a dozen times before you get a valid file.

As for lag, there may be some hacks that draws a lot of stuff that suffers with problems but most hacks that lags does so even with a simple menu and it's probably the result of people not having a clue what they are doing. I've even seen sleep() called for every framerate in a few bases lol. Think things through and how you choose to code them. Is there some parts of your code that doesn't need to run constantly? Or is there some way of doing whatever you are doing in a more efficient way? Aim to minimize the amount of instructions per framerate. Also make use of threads. You would be surprised in some cases how much smoother threading some of your code can make the hack run.

Originally Posted by merp.

Is UPX a decent packer to use? if I use Themida the file becomes huge..

Packing your stuff is pretty insignificant, it's more of just a way to protect your stuff from modifications while it's not running + reducing size. The packed code is in a fully unpacked state in memory anyway (except for stolen code blocks).

But generally (most of this has probably been posted already):

+ Encode your strings (how you do it doesn't really matter as I'm pretty sure no anticheat system has a generic decoding engine)
+ Understand how others do stuff, but write the stuff yourself, this will generate different code
+ Keep your code as private as possible, it's best to only discuss findings with others instead of sharing complete sources
+ Use self modifying code (both file and memory, this fools hashing systems)
+ Avoid public hooks if possible

Sorry but you all talking about strings witch is not the only reasone that may cuz a detection . . .

1 ) But have to say It effect cuz nexon cmp strings and then detection come -> so ya crypt ur strings
2 ) About packer i use themida and yes it help protect from detection ( was ) , cuz on wr some used it with old detours and was totaly working but later i heard they patched it
3 ) Now supercarz said about using ofs will ya i prefer using ofs for many functions , for example if they patched rapidfire addie u can look around it and find rapid ofs / is shoting
4 ) If it was me i would build a simple base ( no menu ) then just add basic things on it to check what nexon detect on it then i move up to menu base
5 ) I Really think most of ppl problem here come from detours

Methods to reduce detection?

Post a Reply

Similar Threads

Tags for this Thread