That's not 'aimbot protection', that's 'not needing aimbot protection'.
Just play sandbox. Or have good admins
[QUOTE=Gbps;18061269]Well you can block lua_run_cl by blocking the command from being sent to the server. lua_run_cl is the only command in the clientside lua commands that is sent to the server before being run. On the other hand, lua_openscript_cl only runs clientside. As for an antihack, your two main goals are to override the RunString global with a script that kick(bans) them, and always detect if sv_scriptenforcer has changed to 0 on the clientside. That will stop about 98% of the current SE bypasses. To be even more interesting, why not override the require command with a command that checks a whitelist of modules before running the old saved require command.[/QUOTE]
But then you get SE2 bypasses that actually just inject lua code into the lua state, very hard to check.
Lua isn't designed to be secure against memory-access. There is no way you can create a 'Lua anticheat' that will block people from using modules or external applications to change the Lua state itself.
You could be annoying and do something like:
[lua]
local debug_getinfo = debug.getinfo
local allowed_files = {
"whatever/whatever.lua"
}
debug.sethook("c", function() if not allow_files[debug_getinfo(2, "S").source] then oh_shit_a_hack() end end)
[/lua]
But then they could just use lua_sethook.
Lua is designed to be secure against other Lua, not against code with higher-access.
Trying to stop it is as useless as obfuscating.
This is true. Any kind of bypasses that don't take place in the game's Lua environment are impossible to block.
[editline]09:16PM[/editline]
Or maybe you can force the client to download a module that blocks other modules. But that would be ridiculous.
[QUOTE=Gbps;18122992]This is true. Any kind of bypasses that don't take place in the game's Lua environment are impossible to block.
[editline]09:16PM[/editline]
Or maybe you can force the client to download a module that blocks other modules. But that would be ridiculous.[/QUOTE]
Pretty sure that you can't send modules anymore since the bug that allowed it was fixed [I think..]
Force as in, do not allow them to join the server without it. A stupid idea, though.
please stop posting
[highlight](User was banned for this post (""stop posting"" - mahalis))[/highlight]
He isnt asking 4 a anti-script thing he is asking for a luascript 4 his computer he plays on that detects aimbotters so he can manually ban them
I am also interested in a lua script like this.
I know its out there, because TnB use it apparently.
[QUOTE=Redell;18503055]I am also interested in a lua script like this.
I know its out there, because TnB use it apparently.[/QUOTE]
The problem is they are easy to bypass
i made one that kils 99%, trugh some times it gets confused and kicks innocent people. but most of the times it works.
check the md5 of the player, if its the same as the other players then there not cheating, unles EVERY one is hacking wich makes you quite a bad admin, if there not the same the person hacks [b]OR[/b] uses an other lua skin, wich often breaks there GMod whit SE anyway.
conclusion: there is NO good protection agenst it. only to filter out the general kids who download them and play whitout knowing anything about it or lua.
I did hope Sv_scriptenforcer 2 would stop it but now a method to inject code into the game has been found
[QUOTE=*Fish*;18507861]I did hope Sv_scriptenforcer 2 would stop it but now a method to inject code into the game has been found[/QUOTE]
Orly? Do you want to show us? :eng101:
Sadly I don't have the module to do it but I rember seeing deco explain how its done somewhere
[QUOTE=*Fish*;18505779]The problem is they are easy to bypass[/QUOTE]
I don't care how easy it is to bypass, cause probably half the people in my server are too stupid to know how to hide them.
[QUOTE=*Fish*;18508599]Sadly I don't have the module to do it but I rember seeing deco explain how its done somewhere[/QUOTE]
It's quite easy to create the module that injects the code into the current state (menu, client), but since some of the current injections run from the menu state, it's quite hard to figure out how to find the client state from within the menu state.
What if you just over-rid the main functions? Yeah, it would break some addons. But if it stopped it, it could do somthing. And a server module to encrypt the lua it sends around? Just a thought.
would still be easy to bypass and a server module to encrypt the lua it sends around would be stupid because if the client has to be sent the lua they have to be sent the method to decrypt the lua this would make the encryption pointless.
All I hear is 'It would be easy...' - Show us that you can bypass SE2, without proof noone will ever believe you.
This thread turned into a "How to bypass SE" topic from "Is there a Hack Detector we can use"
We don't really care about "how easy it is to bypass SE", we just want a "Lua exploit detector"
Not a "auto-ban when detected", not a "Disabler (SE)", and not a "Bypasser (w.e you guys are talking about)"
[QUOTE=The-Stone;18529946]All I hear is 'It would be easy...' - Show us that you can bypass SE2, without proof noone will ever believe you.[/QUOTE]
It's easy if I actually knew C++ :downs:
[sp]Hint: You override gLua's create state function with a dll on the menu state before the client state is created and continue by injecting plain lua code through the module as a proxy, which does not change the md5[/sp]
[QUOTE=Redell;18568481](...)We don't really care about "how easy it is to bypass SE", we just want a "Lua exploit detector"(...)[/QUOTE]
In order to make this you would have need to know how the "exploits" work. There is no general cure. You can always code in a way to mask your actions so any "Lua anti-cheat" gets pointless, because it would anyway only detect known cheats which are already blocked by SE.
Sorry, you need to Log In to post a reply to this thread.
