[Dev]Auto ban runnable.

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

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:

To view the content, you need to sign in or register

After:

To view the content, you need to sign in or register

Results:

To view the content, you need to sign in or register

Epic win.

 

[PenguinGuy]

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-banned-system-asm-functions-631753/

Sorry.

 

[jewness12]

http://forum.ragezone.com/f245/auto-banned-system-asm-functions-631753/

Sorry.

Bleh, mine is way simpler.

 

[wtfhacker]

omgpro, come msn tommorow morning yoni

 

[hotgame]

yoni nice =)
ben shel koskos

 

[Joe9099]

haha thats awesome stuff man. Gj

 

[diosz]

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

 

[jewness12]

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.

 

[jorgitoarr]

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

 

[Evil[]Power]

Nice gj

 

[Phoenix]

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

 

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

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:ataRet (I think it's called). So you could just do a simple :

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 :

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.

 

[jewness12]

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

Yeah, that would be easy for me.

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-bot-pop-msg-bot-fix-j-672121/#post5738343

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 :

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.

 

[ManyBlackPpl]

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

 

[Nova]

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.

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 ?

 

[jewness12]

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

 

[PenguinGuy]

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)

 

[Nova]

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.

 

[jewness12]

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.

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.

 

[Nova]

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)