[QUOTE=James xX;47731188]What if I wanted to cheat, and I created by hooks inside a timer?[/QUOTE]
If you did that you'd have the worst cheat in the world, but ok.
Do you like flashy esps? :^)
UPDATE!
Re-Added CVar check!
Now checks vs the server's cvars!
[QUOTE=FPtje;47729918]Because this is fundamentally flawed and will ban innocent clients when any addon decides to add a temporary Think/HUDPaint/CreateMove hooks.
[url=https://github.com/FPtje/DarkRP/blob/master/gamemode/modules/chat/cl_chatlisteners.lua#L186]Like DarkRP does.[/url][/QUOTE]
Alright now I see why, hopefully he will fix it.
[QUOTE=vrej;47731276]Alright now I see why, hopefully he will fix it.[/QUOTE]
I'm working on it, trying to find a way to dismiss temp hooks.
[url=https://github.com/cdriza/CAH2/blob/master/lua/plugins/sv_cah_antiaim.lua]this[/url] will ban people that use smartsnap.
[url=https://github.com/cdriza/CAH2/blob/master/lua/autorun/client/cl_toolgun_editchange.lua#L147]this[/url] will more than likely cause lots of networking issues / network buffer overflows.
[url=https://github.com/cdriza/CAH2/blob/master/lua/autorun/server/sv_cah_load.lua#L12]this[/url] is silly and is just going to end up causing problems when people rename the addon.
[url=https://github.com/cdriza/CAH2/blob/master/lua/plugins/sv_cah_filestealer.lua#L10]this[/url] is not escaped and allows me to write/overwrite whatever files I want in the data directory.
[url=https://github.com/cdriza/CAH2/blob/master/lua/plugins/sv_cah_pingtest.lua#L16]this[/url] is useless, why'd someone detour a function that's sole purpose is to kick them when detoured?
Why do you bother?
[QUOTE=>>oubliette<<;47731358][url=https://github.com/cdriza/CAH2/blob/master/lua/plugins/sv_cah_antiaim.lua]this[/url] will ban people that use smartsnap.
[url=https://github.com/cdriza/CAH2/blob/master/lua/autorun/client/cl_toolgun_editchange.lua#L147]this[/url] will more than likely cause lots of networking issues / network buffer overflows.
[url=https://github.com/cdriza/CAH2/blob/master/lua/autorun/server/sv_cah_load.lua#L12]this[/url] is silly and is just going to end up causing problems when people rename the addon.
[url=https://github.com/cdriza/CAH2/blob/master/lua/plugins/sv_cah_filestealer.lua#L10]this[/url] is not escaped and allows me to write/overwrite whatever files I want in the data directory.
[url=https://github.com/cdriza/CAH2/blob/master/lua/plugins/sv_cah_pingtest.lua#L16]this[/url] is useless, why'd someone detour a function that's sole purpose is to kick them when detoured?
Why do you bother?[/QUOTE]
1. I don't think it will, also I haven't seen smartsnap in quite a long time. I'll go check. (Edit: No it doesn't.)
2. Removed filestealer.
3. Fixed.
4. Removed filestealer.
5. Fixes idiotic net.Start detours
Couldn't, in theory, a player have an edited copy of cl_toolgun_editchange.lua and simply include it to override yours which would defeat the purpose of any clientside checking? I'm assuming the cheater has the ability to run clientside Lua/scripts as I figure thats what this is supposed to catch
[QUOTE=Exho;47731833]Couldn't, in theory, a player have an edited copy of cl_toolgun_editchange.lua and simply include it to override yours which would defeat the purpose of any clientside checking? I'm assuming the cheater has the ability to run clientside Lua/scripts as I figure thats what this is supposed to catch[/QUOTE]
Yes, but they'd have to be smart enough to hook runstring and stop the file from loading, then emulate the net message ping.
[editline]15th May 2015[/editline]
Irremovable timer!
[url="github.com/cdriza/CAH2-COMPAT"]Compatibility version for DarkRP and addons that create false positives![/url]
Haha, a separate version to make it not ban innocent people. That's a good one.
[QUOTE=FPtje;47734453]Haha, a separate version to make it not ban innocent people. That's a good one.[/QUOTE]
It detects cheats popularly used in DarkRP, and doesn't create false positives like the regular version does since you use temporary hooks.
If by temporary you mean hooks that are created and removed in code periodically, then you'll get banned for running my gPhone :o
[QUOTE=Exho;47736468]If by temporary you mean hooks that are created and removed in code periodically, then you'll get banned for running my gPhone :o[/QUOTE]
Yeah :V
It's because when you set it up, unless the hook is running right then, you won't be able to add it to the whitelist! :c
Then again, that addon is mainly used on DarkRP.
DarkRP has a compatibility version as the gamemode actually uses temporary hooks.
[url=https://github.com/cdriza/CAH2-COMPAT/blob/master/lua/sv_cah_main.lua#L51]gotta love clientside Lua injection[/url]
[lua]
net.Start("CAH_Bypass");
net.WriteString("hi\",1 ,3) RunConsoleCommand('say', 'clientside lua injection!') --");
net.SendToServer();
[/lua]
Of course you get banned but when you can potentially rootkit the server through admins that's not really a problem.
I would not install this addon, there are better free alternatives. Connor I'd suggest you do a little more research before releasing addons like this.
[QUOTE=Exho;47736468]If by temporary you mean hooks that are created and removed in code periodically, then you'll get banned for running my gPhone :o[/QUOTE]
Because this isn't meant for gPhone, duh!
I got no idea what I'm looking at here. This is just aweful.
[QUOTE=ZeConnor;47736592]Yeah :V
It's because when you set it up, unless the hook is running right then, you won't be able to add it to the whitelist! :c
Then again, that addon is mainly used on DarkRP.
DarkRP has a compatibility version as the gamemode actually uses temporary hooks.[/QUOTE]
Temporary hooks are not limited to DarkRP, I use them all the time. If you are causing a bigger headache for developers instead of cheaters, you might need to rethink your approach
ok apparently that's possible, nice find oubliette.
[QUOTE=ZeConnor;47738651]ok apparently that's possible, nice find oubliette.[/QUOTE]
[code]
] lua_run CAH.Ban( findExho(), "hi\",1 ,3) RunConsoleCommand('say', 'clientside lua injection!')--" )
> CAH.Ban( findExho(), "hi\",1 ,3) RunConsoleCommand('say', 'clientside lua injection!')--" )...
Exho: clientside lua injection!
[CAH] Scanning!
[/code]
Edit: You edited your post before I could test :p, it originally said "Thats not possible". Now to actually be productive, the 'ping test' thing which goes off every 5 or so seconds is annoying as fuck. Its just ding.....ding.....ding......ding... etc
[QUOTE=Exho;47738723][code]
] lua_run CAH.Ban( findExho(), "hi\",1 ,3) RunConsoleCommand('say', 'clientside lua injection!')--" )
> CAH.Ban( findExho(), "hi\",1 ,3) RunConsoleCommand('say', 'clientside lua injection!')--" )...
Exho: clientside lua injection!
[CAH] Scanning!
[/code]
Edit: You edited your post before I could test :p, it originally said "Thats not possible". Now to actually be productive, the 'ping test' thing which goes off every 5 or so seconds is annoying as fuck. Its just ding.....ding.....ding......ding... etc[/QUOTE]
You can turn that off in CAH_Config.lua
(CAH.NotifyScan)
If I had a server, I don't think I'd want to risk running this, based on what I've seen. Or any of the other anti-cheat scripts. If there are ways to hack, then those should be mitigated at a lower level by other people. Either the gamemode itself, at the Lua binding or in the source engine.
[QUOTE=ph:lxyz;47739267]If I had a server, I don't think I'd want to risk running this, based on what I've seen. Or any of the other anti-cheat scripts. If there are ways to hack, then those should be mitigated at a lower level by other people. Either the gamemode itself, at the Lua binding or in the source engine.[/QUOTE]
What difference does it make whether it's part of the gamemode or an addon? There's nothing 'low level' about a gamemode vs an addon.
[QUOTE=man with hat;47739293]What difference does it make whether it's part of the gamemode or an addon? There's nothing 'low level' about a gamemode vs an addon.[/QUOTE]
OK - I'm being lazy with my terminology. I used the wrong phrase. I am not dumb, however - I know what I am talking about. I just did a bad job of proving that. The point I am trying to make is this - something like this shouldn't be necessary in the first place. If 'hacking' - in this case, messing with a server is easily possible from the client via external lua scripts, something is wrong. I realize that perfect security is not possible and there are tradeoffs, but what's the benefit of this compared with just verifying input in gamemodes and addons? If an addon is not known to be particularly secure, either fix it or uninstall it.
[QUOTE=ph:lxyz;47739494]OK - I'm being lazy with my terminology. I used the wrong phrase. I am not dumb, however - I know what I am talking about. I just did a bad job of proving that. The point I am trying to make is this - something like this shouldn't be necessary in the first place. If 'hacking' - in this case, messing with a server is easily possible from the client via external lua scripts, something is wrong. I realize that perfect security is not possible and there are tradeoffs, but what's the benefit of this compared with just verifying input in gamemodes and addons? If an addon is not known to be particularly secure, either fix it or uninstall it.[/QUOTE]
You don't get the point of anti cheat scripts. This addon wasn't made to prevent people from hacking the server, it's made to prevent people from running clientside scripts.
Anticheat scripts exist only because of the fact that allowcslua 0 is easy enough to bypass.
[QUOTE=FPtje]You don't get the point of anti cheat scripts.[/QUOTE]
[QUOTE=ph:lxyz]in this case, messing with a server is easily possible from the client via external lua scripts[/QUOTE]
[QUOTE=FPtje]Anticheat scripts exist only because of the fact that allowcslua 0 is easy enough to bypass.[/QUOTE]
[QUOTE=ph:lxyz]at the Lua binding or in the source engine[/QUOTE]
allowcslua 0 should be final. The server should deliver the client side lua and should validate input from the client. Why is this any different from a website? We don't have anti-JS scripts on web servers to load stuff client-side to check the client-side JS isn't going to send anything, we just validate the data at the server.
If allowcslua 0 doesn't prevent client-side lua other than that which the server provides to be executed, then something is wrong. Maybe the server should sign the client side code with a private key and the source engine or lua binding will only run the code on the client side that is signed with the server's key. If I'm still talking crap, please explain to me where I'm going wrong. I'm not trying to downplay Conna's work here, I'm just saying that ideally, it shouldn't be necessary in the first place, and if it is, then something else needs to be changed in the first place.
[QUOTE=ph:lxyz;47741911]allowcslua 0 should be final. The server should deliver the client side lua and should validate input from the client. Why is this any different from a website? We don't have anti-JS scripts on web servers to load stuff client-side to check the client-side JS isn't going to send anything, we just validate the data at the server.
If allowcslua 0 doesn't prevent client-side lua other than that which the server provides to be executed, then something is wrong. Maybe the server should sign the client side code with a private key and the source engine or lua binding will only run the code on the client side that is signed with the server's key. If I'm still talking crap, please explain to me where I'm going wrong. I'm not trying to downplay Conna's work here, I'm just saying that ideally, it shouldn't be necessary in the first place, and if it is, then something else needs to be changed in the first place.[/QUOTE]
By design sv_allowcslua is final, when that is turned on there is no way for a user to use methods the developer of the game provided. Altering the game is what makes it possible to run Lua scripts after that point and what you suggested does not stop these alterations.
[quote]If allowcslua 0 doesn't prevent client-side lua other than that which the server provides to be executed, then something is wrong.[/quote]
sv_allowcslua blocks the Lua console commands. It does nothing else. If you're loading clientside scripts, chances are you're doing it in C++, and can bypass every measure put in place to stop you. It's not hard. There's a different way to run Lua, but it involves editing a menu file, and it's a really dumb way to do it and it sucks.
[quote]Maybe the server should sign the client side code with a private key and the source engine or lua binding will only run the code on the client side that is signed with the server's key.[/quote]The client gets the final say. It doesn't matter how many checks you put in. You're going to send it to the client and the client is the one that ultimately makes the decision. There is nothing you can do to stop that. [B][I]You can't force the client to do anything more than the client can force the server to do anything.[/I][/B] You can program the client so that it listens and complies to the server's requests (the client obeys sv_allowcslua), but the client can be modified to not give a shit about what you want, which is how the C++ Lua enabling cheats in GMod work.
[quote]If I'm still talking crap, please explain to me where I'm going wrong.[/quote]
Just about everywhere, to be honest.
[quote]I'm not trying to downplay Conna's work here[/quote]
That's not Conna.
Maybe I'm turning senile or something.
[QUOTE=man with hat;47741974]sv_allowcslua blocks the Lua console commands. It does nothing else. If you're loading clientside scripts, chances are you're doing it in C++, and can bypass every measure put in place to stop you. It's not hard. There's a different way to run Lua, but it involves editing a menu file, and it's a really dumb way to do it and it sucks.
[/QUOTE]
I wasn't aware that sv_allowcslua only did that - I thought it was more secure (if such a thing is even possible) - thanks for clearing that up.
[QUOTE=man with hat;47741974]
[B][I]the client can be modified to not give a shit about what you want, which is how the C++ Lua enabling cheats in GMod work.[/QUOTE]
Are there no ways of making that difficult in the first place though?
I can modify the JS on a webpage to do whatever I like - but the server is the one that decides whether the command sent to it is legit. Who cares what appears on the screen of the client? At least JS can't access your files - maybe Lua can (and if it can't then it can via a C++ module - but then don't install C++ modules you don't trust)
[QUOTE=man with hat;47741974]
The client gets the final say. It doesn't matter how many checks you put in. You're going to send it to the client and the client is the one that ultimately makes the decision. There is nothing you can do to stop that.
[/QUOTE]
I know that - but even if the user of the client injects their own code into the client (either via lua, a binary module or editing the RAM while the game is running), you can [i]still[/i] (as the server of the game) decide against what the client is sending to you and choose not to act on it. That said, the client script detection stuff might actually be useful to prevent scripts from accessing files on the hard drive of the client that they should otherwise not be (which doesn't apply in the JS/web comparison).
EDIT: Is this anti-cheat stuff specifically for the case where a binary (C++ or whatever language you wanted to use) module has been created and then either the hacks have been done using C++, or Lua itself has been bound (again) as a separate library into [i]that module[/i] so that you can run whatever Lua you want?
It's specifically for the case where someone uses one of the hundreds of available sv_allowcslua bypasses to run Lua.
Server validation can be done [i]in some cases[/i] but sensory/visual stuff has nothing to do with the server (aside from the PVS). And aimbots are hard to distinguish from human movement when done properly.
[QUOTE=ph:lxyz;47742385]Maybe I'm turning senile or something.
I wasn't aware that sv_allowcslua only did that - I thought it was more secure (if such a thing is even possible) - thanks for clearing that up.
Are there no ways of making that difficult in the first place though?
I can modify the JS on a webpage to do whatever I like - but the server is the one that decides whether the command sent to it is legit. Who cares what appears on the screen of the client? At least JS can't access your files - maybe Lua can (and if it can't then it can via a C++ module - but then don't install C++ modules you don't trust)
I know that - but even if the user of the client injects their own code into the client (either via lua, a binary module or editing the RAM while the game is running), you can [i]still[/i] (as the server of the game) decide against what the client is sending to you and choose not to act on it. That said, the client script detection stuff might actually be useful to prevent scripts from accessing files on the hard drive of the client that they should otherwise not be (which doesn't apply in the JS/web comparison).
EDIT: Is this anti-cheat stuff specifically for the case where a binary (C++ or whatever language you wanted to use) module has been created and then either the hacks have been done using C++, or Lua itself has been bound (again) as a separate library into [i]that module[/i] so that you can run whatever Lua you want?[/QUOTE]
JavaScript example is true, but that's for something SERVERSIDE.
sv_allowcslua is a serverside cvar, but can be forced to 1 on a client, which then it can run CLIENTSIDE lua scripts.
And then you can just hook RunString and run scripts without having sv_allowcslua changed at all
I see - so it wouldn't stop someone getting around sv_allowcslua 0 by using another way in and then just aimbotting, for example.
Thanks for clearing that up.
[QUOTE=>>oubliette<<;47736779][url=https://github.com/cdriza/CAH2-COMPAT/blob/master/lua/sv_cah_main.lua#L51]gotta love clientside Lua injection[/url]
[lua]
net.Start("CAH_Bypass");
net.WriteString("hi\",1 ,3) RunConsoleCommand('say', 'clientside lua injection!') --");
net.SendToServer();
[/lua]
Of course you get banned but when you can potentially rootkit the server through admins that's not really a problem.
I would not install this addon, there are better free alternatives. Connor I'd suggest you do a little more research before releasing addons like this.[/QUOTE]
What is the best way of preventing that from occuring and is it possible anywhere where a string gets concatenated?
Sorry, you need to Log In to post a reply to this thread.
