Analysis on XINGCODE

Originally Posted by FantaWauWau

Ok I don´t know much things about the kernel mode, but now I know it

Thx

And Injection is good and maybe faster than External, but External is harder to detect.

Sorry for bad english :/

It's okay, and externals are just as easy to detect as not external cheats.

Originally Posted by ~FALLEN~

It's okay, and externals are just as easy to detect as not external cheats.

Mhhh ok in other forums and on other websites, some people said that their cheats never got detected, because they are external

Well it doesn't matter. Because right now both internal and external cheats are working on the game.
But there are advantages to internal cheats that don't exist on external ones; It takes less resources to change the game's memory and less lag.
And there are hooks that only work on internal.

Originally Posted by Jabberwock

Well it doesn't matter. Because right now both internal and external cheats are working on the game.
But there are advantages to internal cheats that don't exist on external ones; It takes less resources to change the game's memory and less lag.
And there are hooks that only work on internal.

ok

thats right

Hi,

I just wanted to say thanks for the laughs, of few of your are so off-base with this that it's not even funny.

However, to contribute something useful:

The anti-cheat has levels that you all haven't even encountered yet. Sure, they do work in the kernel, and that's always a pain to deal with. But, if you code efficiently, you won't have to touch anything in ring0, you can let them operate correctly without having any problems with detection. There are no CRC checks to bypass, no APIs to worry about (so long as your module doesn't show in the PEB/TEB linked module list).

Their only real issue, from what I personally have had to contend with, on a few occurrences, is their ability to nail your injecting process. Quite honestly, if you're using a common packer, or anything that implements a static, and easily identifiable signature into your module as protection, you're leaving yourself very susceptible to their scans.

Now, I haven't even begun to tear into the anti-cheat, it hasn't really been necessary. But, from what I gather (and can actually prove this, if someone really wants to challenge me on it), is that they're iterating all processes (not even enuming them, they're literally looping from 0 to 65536 and attempting to OpenProcess on all PIDs. If the call is successful, they hold a handle to it, and ReadProcessMemory (yes, using the ring3 API), to compare data. Where they're doing this from will surprise you.

Let their anti-cheat function, simply evade. If you hide well enough, they'll never find you.

Anyway, that's all I'm going to share for now, just a few quick thoughts. But again, this thread was an interesting laugh, and to my user who pointed me here, I thank you for the entertainment.

Cheers,
uNrEaL

Originally Posted by uNrEaL

Hi,

I just wanted to say thanks for the laughs, of few of your are so off-base with this that it's not even funny.

However, to contribute something useful:

The anti-cheat has levels that you all haven't even encountered yet. Sure, they do work in the kernel, and that's always a pain to deal with. But, if you code efficiently, you won't have to touch anything in ring0, you can let them operate correctly without having any problems with detection. There are no CRC checks to bypass, no APIs to worry about (so long as your module doesn't show in the PEB/TEB linked module list).

Their only real issue, from what I personally have had to contend with, on a few occurrences, is their ability to nail your injecting process. Quite honestly, if you're using a common packer, or anything that implements a static, and easily identifiable signature into your module as protection, you're leaving yourself very susceptible to their scans.

Now, I haven't even begun to tear into the anti-cheat, it hasn't really been necessary. But, from what I gather (and can actually prove this, if someone really wants to challenge me on it), is that they're iterating all processes (not even enuming them, they're literally looping from 0 to 65536 and attempting to OpenProcess on all PIDs. If the call is successful, they hold a handle to it, and ReadProcessMemory (yes, using the ring3 API), to compare data. Where they're doing this from will surprise you.

Let their anti-cheat function, simply evade. If you hide well enough, they'll never find you.

Anyway, that's all I'm going to share for now, just a few quick thoughts. But again, this thread was an interesting laugh, and to my user who pointed me here, I thank you for the entertainment.

Cheers,
uNrEaL

A real hacker/knowledgeable person on mpgh right here. UnReal atleast knows his shit.

Originally Posted by uNrEaL

Hi,

I just wanted to say thanks for the laughs, of few of your are so off-base with this that it's not even funny.

However, to contribute something useful:

The anti-cheat has levels that you all haven't even encountered yet. Sure, they do work in the kernel, and that's always a pain to deal with. But, if you code efficiently, you won't have to touch anything in ring0, you can let them operate correctly without having any problems with detection. There are no CRC checks to bypass, no APIs to worry about (so long as your module doesn't show in the PEB/TEB linked module list).

Their only real issue, from what I personally have had to contend with, on a few occurrences, is their ability to nail your injecting process. Quite honestly, if you're using a common packer, or anything that implements a static, and easily identifiable signature into your module as protection, you're leaving yourself very susceptible to their scans.

Now, I haven't even begun to tear into the anti-cheat, it hasn't really been necessary. But, from what I gather (and can actually prove this, if someone really wants to challenge me on it), is that they're iterating all processes (not even enuming them, they're literally looping from 0 to 65536 and attempting to OpenProcess on all PIDs. If the call is successful, they hold a handle to it, and ReadProcessMemory (yes, using the ring3 API), to compare data. Where they're doing this from will surprise you.

Let their anti-cheat function, simply evade. If you hide well enough, they'll never find you.

Anyway, that's all I'm going to share for now, just a few quick thoughts. But again, this thread was an interesting laugh, and to my user who pointed me here, I thank you for the entertainment.

Cheers,
uNrEaL

Hey uNrEaL, didn't know you were still active. Nice to see you around =) To add onto this they have hooks in the ssdt and ssdts. A few of them that I know of are : GetAsyncKeyState, CreateFont( if it was ported from other versions, the version SANA uses does this ), I believe OpenProcess ? @uNrEaL tbh once you figure out XignCode, it's kind of a joke isn't it? I think they were better off with GameGuard as their anticheat lolz =)

Post a Reply

Similar Threads

Tags for this Thread