[Dev]Auto ban runnable.

That's always been the best idea for an antihack, though what if the players are too dumb to type in !hacker ? - Sorry, I go strange in evenings :3
And having a constant check on all of the current logged in players, checking at what rate they're sending the 'evil' packets would use silly amounts of CPU.

Instead of being an idiot and making the player say !hacker, just send a packet to the server...
 
jewness12 said:
Nova said:
Yeap, that's what I'm talking about :].

What's the other check, if I may ask ? I don't see how you can do a check in the function, I believe the call a DLL makes to SetHP or whatnot is about as innocent looking as a call the runnable would make towards it. In less [and I might be speaking bullshit here] you check the return address that the external function caller (the DLL) made, and compare it to see if it's in the runnable's code segment.
That's more or less of what I've did, well done guessing.
I'll add more checks later.

That could be easily bypassed in ASM, but yeah. It would brush off most "inject & play" hackers.

jewness12 said:
Instead of being an idiot and making the player say !hacker, just send a packet to the server...

That would still require a check on the packet sending rate.
 
That could be easily bypassed in ASM, but yeah. It would brush off most "inject & play" hackers.



That would still require a check on the packet sending rate.

Yeah, but, people trigger it by saying '!hacker'.
Sending a different packet is more like.. filtering the morons.

How about you add me to MSN? >> [email protected]
You seem to have a nice BRAIN. lol.
 
I can do that with fast tbf LOL.

I don't play Gunz very often, so I said "an estimated given rate". =p

That's always been the best idea for an antihack, though what if the players are too dumb to type in !hacker ? - Sorry, I go strange in evenings :3
And having a constant check on all of the current logged in players, checking at what rate they're sending the 'evil' packets would use silly amounts of CPU. (Though this solution differs from the original proposal)

Not at all. Veldi's way was to enter a game room and grab everyone's MUID and check how fast they are sending "Zpost" functions. If you have a constant check, over every single game room + every channel, well now that's just stupid.

Instead of being an idiot and making the player say !hacker, just send a packet to the server...

Figure out the best method for that. Their are only two ways I can see it working and being efficient.
1) Wait till a user types in "!hacker" and scan.
2) Enter every game room + channel and scan.
 
Last edited:
I don't play Gunz very often, so I said "an estimated given rate". =p



Not at all. Veldi's way was to enter a game room and grab everyone's MUID and check how fast they are sending "Zpost" functions. If you have a constant check, over every single game room + every channel, well now that's just stupid.



Figure out the best method for that. Their are only two ways I can see it working and being efficient.
1) Wait till a user types in "!hacker" and scan.
2) Enter every game room + channel and scan.
Best method for what?


Xiao's GUNZ2830 ?
He meant if it's raw ASM action, or DLL injecting.
"runnable base*d*"
 
Last edited:
Not at all. Veldi's way was to enter a game room and grab everyone's MUID and check how fast they are sending "Zpost" functions. If you have a constant check, over every single game room + every channel, well now that's just stupid.

That's exactly what I'm saying. And I've never looked at the Veldi source, I just know it checks at what rate packets are getting sent.
 
I lol'd. there's an easier way for server-side, try and find it.
I already made the DLL call thing, but I did another check inside the ZPost functions.
And that "Net.Disconnect" thing, totally useless.

Net.Disconnect isn't useless at all. Rather than having a packet sent to the server (which can easily be detected by hooking Winsock), log the client off.

Mind sharing it ? Cause I don't think there is.

X-trap packets...

I think I know.
You meant, moving functions to new addresses, and on the old address, doing that whole ban thing.
So, when a DLL makes a call to the old address, it gets banned and disconnected.
So yeah, I already did that + another check for the ZPost functions. and all the other things.

See, the more security on the runnable, the better it is(methinks).

Moving the ZPost functions doesn't make sense, simply access an address from where the function is called and copy the address to a buffer. Then call that address, and you are good to go.

Also, what if I directly grab MatchServer and client sockets from the memory? (Wiztastic does that) :ott1:
 
Also, what if I directly grab MatchServer and client sockets from the memory? (Wiztastic does that) :ott1:

Take it this way..
No anti - hack is perfect.

Net.Disconnect isn't useless at all. Rather than having a packet sent to the server (which can easily be detected by hooking Winsock), log the client off.

Why spam the MatchServer with another packet...
When MatchServer bans the client, it could also disconnect it.
Time saving 4eva.
 
Take it this way..
No anti - hack is perfect.

Correct, but it should patch all current hacks.

Why spam the MatchServer with another packet...
When MatchServer bans the client, it could also disconnect it.
Time saving 4eva.

Sure, but sending out a ban packet is ambiguous. (Hence the fact I can easily catch the packet at Winsock level, check for the command id and then block that commandid from being send).
 
Correct, but it should patch all current hacks.



Sure, but sending out a ban packet is ambiguous. (Hence the fact I can easily catch the packet at Winsock level, check for the command id and then block that commandid from being send).

Got an other way of communicating between MatchServer and the client?
 
Back