[Dev]Auto ban runnable.

I am currently working on an auto banning runnable.
I don't know if I will release this or not, I will consider it.

Edit:
Here we go.
Epic success.

To toggle this, you have to use a hack or something, like lawnmower.
When it is toggled, you get automatically banned and disconnected, and you get a message saying you're banned,
I used lawnmower, and,

One second before disconnect: http://up203.siz.co.il/up1/mlf0wojyizgm.jpg

After:
http://up203.siz.co.il/up2/2lznmkztiynm.jpg

Results:
http://up203.siz.co.il/up2/tuw4xez4eomw.jpg

Epic win.

Quote:

---

Originally Posted by jewness12

I am currently working on an auto banning runnable.
I don't know if I will release this or not, I will consider it.

---

http://forum.ragezone.com/f245/auto-...ctions-631753/

Sorry.

Quote:

---

Originally Posted by Your Master

http://forum.ragezone.com/f245/auto-...ctions-631753/

Sorry.

---

Bleh, mine is way simpler.

omgpro, come msn tommorow morning yoni

yoni nice =)
ben shel koskos

haha thats awesome stuff man. Gj

o.o very nice men ^^
you finished this or yet no?

Quote:

---

Originally Posted by diosz

o.o very nice men ^^
you finished this or yet no?

---

Yes, it is finished.
I am now adding new commands to my console, making it an Admin console.

Edit:
I work fast.
The server is down, so non of them will work unless it is on again.

http://img821.imageshack.us/img821/9484/gunz005.jpg

Perfect!!!! Excellent JOB! But this have the Anti Hack detect to?

Nice gj :)

Good job man! Try having the same thing for the July files too!

This wouldn't be just done in the runnable, you'd need to send your own packet to the server containing the UserID of the hacker, then you'd need to write a server-sided handle for the packet - so when the ban packet is received, the server has to execute a query to ban the player.

The GUNZ0XXXX dude released a server sided DLL for banning players when the /admin_ban packet is sent, he had a function in that DLL for executing SQL query's using the Matchserver ODBC connection.

Also, I released a Matchserver DLL that had a detour on MCommand::DataRet (I think it's called). So you could just do a simple :

PHP Code:

---

if(p_ID == 0xbanpacket) {
        p_ReadUID = // the the decrypted string.
    executeSQLQuery("UPDATE Account SET UGradeID = 253 WHERE UserID = %s", p_ReadUID);
} 


---

As to disconnecting the player, you'd just need to send the Net.Disconnect packet (ID 12F) in the runnable via ZNewCmd.
A codecave for this would look like :

Code:

---

PUSHAD
PUSH 0x12F
MOV EAX, 0xZNEWCMDADDRYOULLNEEDTOFINDIT
CALL EAX
POPAD

---

- don't forget to clear the stack.

But yeah, the banning part is a lot more work than what it looks like.

As to the hack detection - I guess you've just changed the ZPost__ functions addresses for lawnmower, and whatnot in places that they're CALLED in the runnable. And at the old addresses you've made a call to your ban + disconnect function. So when a DLL makes a call to that address, BANG, they're in the wrong spot, they call the wrong function and voilà, they're out.

Good job.

Quote:

---

Originally Posted by phoenix_147

Good job man! Try having the same thing for the July files too!

---

Yeah, that would be easy for me.

Quote:

---

Originally Posted by jorgitoarr

Perfect!!!! Excellent JOB! But this have the Anti Hack detect to?

---

Lets have a guess...
HACKS MAYBE?
I'll start by blocking everything in Freebase.

BTW, I am going to release a fix for 2007,
- Room Bot > The hack that moves people to other stages and won't let the server play.

- Pop up message bot > The hack when you attack someone and it shows a message over and over again and it wont let you play.

Edit:

Here it is.
http://forum.ragezone.com/f245/room-...1/#post5738343

Quote:

---

Originally Posted by Nova

This wouldn't be just done in the runnable, you'd need to send your own packet to the server containing the UserID of the hacker, then you'd need to write a server-sided handle for the packet - so when the ban packet is received, the server has to execute a query to ban the player.
As to disconnecting the player, you'd just need to send the Net.Disconnect packet (ID 12F) in the runnable via ZNewCmd.
A codecave for this would look like :

Code:

---

PUSHAD
PUSH 0x12F
MOV EAX, 0xZNEWCMDADDRYOULLNEEDTOFINDIT
CALL EAX
POPAD

---

- don't forget to clear the stack.

But yeah, the banning part is a lot more work than what it looks like.
As to the hack detection - I guess you've just changed the ZPost__ functions addresses for lawnmower, and whatnot in places that they're CALLED in the runnable. And at the old addresses you've made a call to your ban + disconnect function. So when a DLL makes a call to that address, BANG, they're in the wrong spot, they call the wrong function and voilà, they're out.

Good job.

---

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.

omg, friggin pro. Good job, this would definitely be extremely useful.

Quote:

---

Originally Posted by jewness12

I lol'd. there's an easier way for server-side, try and find it.

---

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

Quote:

---

I already made the DLL call thing, but I did another check inside the ZPost functions.

---

"DLL call thing" - euh, do you know what you're talking about ?

@Quotation - like ?

Quote:

---

Originally Posted by Nova

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



"DLL call thing" - euh, do you know what you're talking about ?

@Quotation - like ?

---

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

Just mimic Veldi's anti-hack, except for every "ZPost" function.
That will block a lot hacks. Not all of 'em of course, but it'll help an enormous amount. + no client-sided files.
Say, have a user type in "!hacker". Grab their room's MUID, have the bot enter the room invisibly, and check that user's packet-sending rate. Since no user should be able to, lets say, slash their sword 15 times in 5 seconds. (an estimated given rate)

Quote:

---

Originally Posted by jewness12

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.

---

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.

Quote:

---

Originally Posted by Your Master

Just mimic Veldi's anti-hack, except for every "ZPost" function.
That will block a lot hacks. Not all of 'em of course, but it'll help an enormous amount. + no client-sided files.
Say, have a user type in "!hacker". Grab their room's MUID, have the bot enter the room invisibly, and check that user's packet-sending rate. Since no user should be able to, lets say, slash their sword 15 times in 5 seconds. (an estimated given rate)

---

I can do that with fast tbf LOL.

Quote:

---

Originally Posted by Nova

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.

Quote:

---

Originally Posted by Your Master

Just mimic Veldi's anti-hack, except for every "ZPost" function.
That will block a lot hacks. Not all of 'em of course, but it'll help an enormous amount. + no client-sided files.
Say, have a user type in "!hacker". Grab their room's MUID, have the bot enter the room invisibly, and check that user's packet-sending rate. Since no user should be able to, lets say, slash their sword 15 times in 5 seconds. (an estimated given rate)

---

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)

Quote:

---

Originally Posted by Nova

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

Quote:

---

Originally Posted by jewness12

Quote:

---

Originally Posted by Nova

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.

Quote:

---

Originally Posted by jewness12

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.

Quote:

---

Originally Posted by Nova

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? >> krisdgreat@hotmail.com
You seem to have a nice BRAIN. lol.

what's your runnable base?

Quote:

---

Originally Posted by Military

what's your runnable base?

---

Be more specific.
"runnable base"?

Quote:

---

Originally Posted by jewness12

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? >> krisdgreat@hotmail.com
You seem to have a nice BRAIN. lol.

---

Hehe, added.
Though I'll be off to bed in a bit.

Xiao's GUNZ2830 ?

Quote:

---

Originally Posted by jewness12

I can do that with fast tbf LOL.

---

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

Quote:

---

Originally Posted by Nova

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.

Quote:

---

Originally Posted by jewness12

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.

Quote:

---

Originally Posted by Your Master

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?

Quote:

---

Originally Posted by Military

Xiao's GUNZ2830 ?

---

He meant if it's raw ASM action, or DLL injecting.
"runnable base*d*"

Quote:

---

Originally Posted by Military

I mean what runnable are you making the edits on for Christ's Sake...

Xiao's or runnables released by GUNZ2830.

---

WTF does that matter?
I can do it on any runnable.

I mean what runnable are you making the edits on for Christ's Sake...

Xiao's or runnables released by GUNZ2830.

Edit: Does it hurt to ask? I don't doubt your work I just want to know the base.

Quote:

---

Originally Posted by Military

I mean what runnable are you making the edits on for Christ's Sake...

Xiao's or runnables released by GUNZ2830.

---

... Point posting the same post?

Internet Lag.

Quote:

---

Originally Posted by Military

Internet Lag.

---

Hes trying to tell you it doesn't matter what runnable. >.<
Anyways, Good work. Your progress is very nice, It would help the section and many servers a lot if you released this.

Quote:

---

Originally Posted by Katsuro

Hes trying to tell you it doesn't matter what runnable. >.<
Anyways, Good work. Your progress is very nice, It would help the section and many servers a lot if you released this.

---

I was telling him why the post appeared twice *facepalm*

Quote:

---

Originally Posted by Your Master

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.

Quote:

---

Originally Posted by jewness12

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.

Quote:

---

Originally Posted by Nova

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

---

X-trap packets...

Quote:

---

Originally Posted by jewness12

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:

Quote:

---

Originally Posted by Wizkidje

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.

Quote:

---

Originally Posted by Wizkidje

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.

Quote:

---

Originally Posted by jewness12

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

---

Correct, but it should patch all current hacks.

Quote:

---

Originally Posted by jewness12

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

Quote:

---

Originally Posted by Wizkidje

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?

Quote:

---

Originally Posted by jewness12

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

---

All network communication would require a socket. You could set some low-level traps in Winsock though.

shalom tipesh kmo naal does your admin cp have working GT commands ;_; I've got most of mine to work courtesy of CBWhiz and Sulfins codes I found on my old pc from like 5-6years ago

Quote:

---

Originally Posted by Kevlarji

shalom tipesh kmo naal does your admin cp have working GT commands ;_; I've got most of mine to work courtesy of CBWhiz and Sulfins codes I found on my old pc from like 5-6years ago

---

Yes it does.. tipesh aba sha yomo
I use my own codes <_<

Good Luck With Your Runnable