PDA

View Full Version : Anti-Hack: Freezeplayer


fowlplay4
01-18-2009, 04:55 AM
Due to the recent leak of a trainer from Team WSU, servers might need to invest some time in anti-trainer measures if they haven't already.

Tested and works perfectly without any changes to gameplay.

Edit: This snippet should be altered/installed into your main systems so if a trainer user decides alter their freezeplayer code it will result in crippled gameplay.


//#CLIENTSIDE
function onCreated() {
setTimer(1);
}

function onTimeout() {
// To avoid altering gameplay
if (player.freezetime > 0) return setTimer(1);
// Freeze the Player
freezeplayer(1);
if (player.freezetime != 1) hackDetected();
// Unfreeze Player
freezeplayer(0);
// Continue Loop
setTimer(1);
}

function hackDetected() {
// you decide the rest...
}


Other features of this latest trainer include warping to a specific X, Y, warping into a wall, can disable freezeplayer, enables turn while slashing, instant classic bomb explosion, wall running hack, sword delay hack.

Sounds like we got the work cut out for us!

Tigairius
01-18-2009, 05:14 AM
By releasing the script it will be extremely easy for hackers to disable the detection now. I recommend just removing it from the forums and installing it/giving it to a few servers. Otherwise, nice.

fowlplay4
01-18-2009, 06:21 AM
I am pretty confident in this snippet but it should be altered and morphed into common gameplay elements perhaps as a check and if a player fails the check it would report to RC and cripple gameplay elements.

If freezeplayer returned true the script could be simplified to just..


if (!freezeplayer(0)) hackDetected();

Thallen
01-18-2009, 11:15 PM
Those darn shockers.

Twinny
01-18-2009, 11:31 PM
I almost feel sorry for the idiots who buy those trainers (yes, you have to pay)....paying so they can lose their account. Woo!

07-12-2009, 01:49 PM
Or you could use this:


function onActionServerside() {
echo("[Hacker System]" SPC player.account SPC "is using the freezeplayer hack!");
}
//#CLIENTSIDE
function onCreated() {
setTimer(1);
}

function onTimeout() {
if (player.freezetime > 0) return setTimer(1);
freezeplayer(1);
if (player.freezetime != 1) hackDetected();
freezeplayer(0);
setTimer(1);
}
function hackDetected() {
triggerserver("weapon", this.name, "reportglitch", "");
}

fowlplay4
07-12-2009, 06:20 PM
Or you could use this:

Add PHP Tags around the code, and you're pretty much posting what should go without saying.

07-14-2009, 03:18 AM
Hey, it works.

cbk1994
07-14-2009, 04:18 AM
Or you could use this:


function onActionServerside() {
echo("[Hacker System]" SPC player.account SPC "is using the freezeplayer hack!");
}
//#CLIENTSIDE
function onCreated() {
setTimer(1);
}

function onTimeout() {
if (player.freezetime > 0) return setTimer(1);
freezeplayer(1);
if (player.freezetime != 1) hackDetected();
freezeplayer(0);
setTimer(1);
}
function hackDetected() {
triggerserver("weapon", this.name, "reportglitch", "");
}

I'd suggest adding logging as well.

07-16-2009, 06:20 PM
I agree.

Gambet
07-18-2009, 07:04 PM
This actually works quite well (will probably implement this on Zone). Not sure how this could be bypassed since when you freeze a player a freezeplayer address is added to them, and if they altered the freezeplayer address to say something other than 'freezeplayer,' then the client wouldn't recognize it and wouldn't actually freeze the player, thus triggering that the player is not frozen even though they should be and causing the system to detect them using a trainer.

EDIT: Also, if they try altering the freezetime address, then the system would still detect it, so there isn't really any address name-changing that can be done that wouldn't be detected. If they tried just changing the value of freezeplayer instead of changing the address of the name, then that still wouldn't work because the system would know that the player isn't being frozen for the amount of time specified (in this case 1 second), so basically, this leaves them without any options. All servers should look into implementing something similar to fit their systems and also add protection against the other features of the trainers.

Logically simple but affective at what it does, nice work. :)

fowlplay4
07-18-2009, 08:10 PM
You could even modify it a little to include random hack checking as well..


// Detection Code
temp.seed = random(1, 3);
freezeplayer(temp.seed);
if (player.freezetime != temp.seed || !(temp.seed in |1,3|)) hackDetected();
// Other Code..
//


The only way I believe they could get around it is by disabling the code itself, which is why I recommend implementing inside your weapon scripts, so if it fails it cripples your systems for hackers, I seriously doubt WSU being able to do this, they've made nothing but crappy trainers and macros lately.

But for whatever reason, I have had it show up false positives. But that may be related to my implementation in my weapon scripts, but typically if it's spamming on RC, they're up to no good.

Gambet
07-18-2009, 08:11 PM
You could even modify it a little to include random hack checking as well..


temp.seed = random(1, 3);
freezeplayer(temp.seed);
if (player.freezetime != temp.seed || !(temp.seed in |1,3|)) hackDetected();



Why would you need to?

fowlplay4
07-18-2009, 08:18 PM
Why would you need to?

Two birds one stone, plus RPG Servers like Zodiac rely on the random function for variance.

BlueMelon
07-18-2009, 08:22 PM
Is this for detection of the change of speed? like what does it detect..

Gambet
07-18-2009, 08:27 PM
Two birds one stone, plus RPG Servers like Zodiac rely on the random function for variance.


Yeah but you're doing the same thing in the end, just instead of freezing the player for a second you're randomly freezing them between 1 to 3 seconds, not exactly sure how this would accomplish anything different from the original script? And how did you manage to get false positives? Once the script freezes the player it should run through way too quickly for a normal player to be able to set it off.

fowlplay4
07-18-2009, 09:48 PM
Yeah but you're doing the same thing in the end, just instead of freezing the player for a second you're randomly freezing them between 1 to 3 seconds, not exactly sure how this would accomplish anything different from the original script? And how did you manage to get false positives? Once the script freezes the player it should run through way too quickly for a normal player to be able to set it off.

If a player replaces the random function in memory to like.. rendom or something..

random should return 0, and if the random seed isn't between the range you set it'll go off. So my modification allows the freezeplayer antihack to work like it did before as well as a check for random as well.

I blame the client and bad computers letting weird things happen, I've personally never had it give a false positive on myself though.

Inverness
07-19-2009, 12:12 AM
Kudos to you sir.