So i have a gamemode where one player is nearly invisible, and a lot of the gameplay revolves around this. You can see this is probably something that will cause issues.
Clientside aimbots can reveal the invisible player and people with materials edited can see the invisible player. I can't really solve the lua aimbot issue but i think there's a way to avoid players who use material hacks.
[lua]
"Refract"
{
"$model" "1"
"$dudvmap" "effects/fisheyelens_dudv"
"$normalmap" "effects/fisheyelens_normal"
"$refractamount" "0.003"
"$vertexalpha" "1"
"$vertexcolor" "1"
"$translucent" "1"
"$forcerefract" "1"
"$bluramount" "1"
"$nofog" "1"
"Refract_DX60"
{
"$fallbackmaterial" "sprites/heatwavedx70"
}
}[/lua]
On the client (or server?) I could just have a think function that sets these values to what they are in the file every second. Would this work or is there more that i need to be considering?
If they are invisible then just SetNoDraw(true)
It's harder to see the stalker than the hidden. Actually i never actually see him, i usually just somehow manage to shotgun hit him in mid air.
I should be more specific. The player isn't invisible, just barely visible. SetNoDraw would make him impossible to see which isn't what i want
Does gmod have sv_pure? Because that would accomplish what i am trying to accomplish. Or maybe i could use CRC on the file itself?
sv_pure should work, I remember seeing it used on some random TTT server I joined.
Also why are you worried about aimbots and stuff? Just keep "sv_allowcslua" at 0 and you should be fine.
[QUOTE=.\\Shadow};38245029]sv_pure should work, I remember seeing it used on some random TTT server I joined.[/QUOTE]
Agreed on this. sv_pure will fix this.
[QUOTE=sabreman;38245146]Also why are you worried about aimbots and stuff? Just keep "sv_allowcslua" at 0 and you should be fine.[/QUOTE]
Dude literally it would take me (or any other decent programmer for that matter) 5 minutes to bypass that.
And then get garry/vac banned? Sure it will be an issue for a bit, but after that the person won't be back.
[QUOTE=sabreman;38245599]And then get garry/vac banned? Sure it will be an issue for a bit, but after that the person won't be back.[/QUOTE]
Yeah not really, keeping your bypass private pretty much stops both of those from happening. I'm not condoning cheats (as fun as they are to develop), I'm just saying.
That doesn't mean the system won't detect it. Afaik garry said that there really was no way to bypass his system without him knowing.
And honestly, how many people are actually going to go this far just to cheat on some dudes server? sv_allowcslua will be more than enough to protect him.
sv_allowcslua will keep out most cheaters, any public bypass will be dealt with by garry (and can usually be detected with Lua too), the people who use private cheats are so few and far between it really doesn't matter
Along with all the above you could also just have decent active admins to pick up on the cheating and ban them.
[QUOTE=Archemyde;38245169]Agreed on this. sv_pure will fix this.[/QUOTE]
Does sv_pure affect all files or just gamemode files?
[QUOTE=twoski;38247324]Does sv_pure affect all files or just gamemode files?[/QUOTE]
All files
Okay well i guess sv_pure solves any problems that might arise.
You can set a whitelist of the files sv_pure should care about IIRC
sv_pure 2 forces gcf files
[QUOTE=sabreman;38245799]That doesn't mean the system won't detect it. Afaik garry said that there really was no way to bypass his system without him knowing.
And honestly, how many people are actually going to go this far just to cheat on some dudes server? sv_allowcslua will be more than enough to protect him.[/QUOTE]
That's completely wrong. Look at SethHack for example, it may be far and few between that coders can slop together a decent hack, but all it takes is 1 to sell it and everyone has access.
And what do you mean by "And honestly, how many people are actually going to go this far just to cheat on some dudes server?", any programmer with knowledge of LUA's internals, and garry's mod specific lua (gLUA) could write a simple 'cheat' that would be undetected in a matter of an hour, it's not exactly rocket science.
If you believe for a second that Garry is the god of detecting cheats I can assure you, you are very misinformed and clearly don't understand low level programming nor do you realize that all it takes to bypass script enforcer is a valid Client lua_State pointer (which is by no means hard to obtain).
[editline]30th October 2012[/editline]
[QUOTE=Drakehawke;38246429]sv_allowcslua will keep out most cheaters, [B]any public bypass will be dealt with by garry (and can usually be detected with Lua too)[/B], the people who use private cheats are so few and far between it really doesn't matter[/QUOTE]
Yeah, maybe if you don't know what you're doing, or don't know how VAC works internally. Bypassing VAC (and GAC for that matter) is not a difficult task at all.
[QUOTE=JustSoFaded;38258321]That's completely wrong. Look at SethHack for example, it may be far and few between that coders can slop together a decent hack, but all it takes is 1 to sell it and everyone has access.
If you believe for a second that Garry is the god of detecting cheats I can assure you, you are very misinformed and clearly don't understand low level programming nor do you realize that all it takes to bypass script enforcer is a valid Client lua_State pointer (which is by no means hard to obtain).[/QUOTE]
So you have a working cheat that you have used on servers that is undetectable and allows you to run your own code on any server? Or are you just saying its possible without actually doing it yourself.
[QUOTE=highvoltage;38258361]So you have a working cheat that you have used on servers that is undetectable and allows you to run your own code on any server? Or are you just saying its possible without actually doing it yourself.[/QUOTE]
Yeah, I do. However I don't condone/endorse it. I developed it strictly as a proof of concept, so far the only community to detect my cheat is StonedPotatoes, and I gave Flappy major props. I don't have a VAC or GAC ban yet, so clearly neither of those are a worry (it's not public, but that proves that Garry's stupid little anti-cheat he made isn't a threat). I don't actually use the cheat, but yeah it's completely working and runs my LUA just fine (while also detouring scriptenforcer 2, if that's still a thing. Essentially my lua state hash is constant.)
[QUOTE=JustSoFaded;38258442]Yeah, I do. However I don't condone/endorse it. I developed it strictly as a proof of concept, so far the only community to detect my cheat is StonedPotatoes, and I gave Flappy major props. I don't have a VAC or GAC ban yet, so clearly neither of those are a worry (it's not public, but that proves that Garry's stupid little anti-cheat he made isn't a threat). I don't actually use the cheat, but yeah it's completely working and runs my LUA just fine (while also detouring scriptenforcer 2, if that's still a thing. Essentially my lua state hash is constant.)[/QUOTE]
If its "by no means hard to obtain" you should inform Garry on the method you are using so he can prevent others from doing the same thing you are, except for actually cheating and messing with servers instead of just a proof of concept.
[QUOTE=highvoltage;38258476]If its "by no means hard to obtain" you should inform Garry on the method you are using so he can prevent others from doing the same thing you are, except for actually cheating and messing with servers instead of just a proof of concept.[/QUOTE]
All standard lua functions push a lua_State pointer as the very first arg. Detour any single one, grab the first arg, and now you have a valid lua state pointer. From there all it takes is loading into the state, essentially you could sigscan (or possibly vhook, assuming the lua functions are virtual. I can't quite remember) for lua_load (or possibly lua_pcall), and call your local version of lua_load passing the lua_State pointer as the first arg. That's literally all it takes, the hardest part is distinguishing menu state from client state, howver lua_load also passes the chunk name as the 4rth arg (in garrysmod this will be the file path). If you check the chunk name , and it's "@includes/init.lua", then that means every lua_load call from then on will be the client state and you can load your custom lua at any time, ideally right before includes/init.lua is loaded.
The fact that you don't have a vac ban yet doesn't mean anything. It usually takes them a few days/weeks to actually ban you after detecting it.
Also, even though you have your hack, my point still stands. sv_allowcslua is more than enough to protect him. If someone like you does come along however (and this is a very low chance) he can simply ban them manually.
Edit: I wish I knew enough about lua to understand what you said in your last post lol.
[QUOTE=sabreman;38259281]The fact that you don't have a vac ban yet doesn't mean anything. It usually takes them a few days/weeks to actually ban you after detecting it.
[/QUOTE]
Thats not how vac works in garry's mod
In all VAC enabled games: Certain things get flagged as "potentially cheats" and can be manually reviewed. Once a "potential cheat" signature has been identified as a cheat, automated bans start getting thrown out. So, if any of VAC's detection methods find abnormalities in your game, you could be safe - or you could be banned.
In GMod: The "potential cheats" rarely get flagged as a cheat (BBot being the only case so far I believe).
Not sure why people are bashing OP or anyone else for making robust code. You can't lean on Garry to defend you from every single hack, exploit and workaround. And you can't (or shouldn't, anyway) depend on your cracksquad of admins to somehow magically peer into players' clients and deduce whether or not they're hacking with 100% certainty. He's going the extra mile to be sure his gamemode is impervious from hackers with a method that's built into his code. That seems like a noble goal to me, and I would consider that exceptional coding practice.
It does look like sv_pure would do the job for material hacks, though. While setting sv_pure for all assets might be a tad overkill, it looks like you can force specific assets to be pure in pure_server_whitelist.txt or whitelist.cfg. I believe that simply stating the filepath of the transparent model and using the flag allow_from_disk+check_crc should suffice in your case, twoski.
[URL="https://developer.valvesoftware.com/wiki/Pure_Servers"]Further reading on sv_pure[/URL]
-snip-
[editline]31st October 2012[/editline]
[QUOTE=JustSoFaded;38258537]All standard lua functions push a lua_State pointer as the very first arg. Detour any single one, grab the first arg, and now you have a valid lua state pointer. From there all it takes is loading into the state, essentially you could sigscan (or possibly vhook, assuming the lua functions are virtual. I can't quite remember) for lua_load (or possibly lua_pcall), and call your local version of lua_load passing the lua_State pointer as the first arg. That's literally all it takes, the hardest part is distinguishing menu state from client state, howver lua_load also passes the chunk name as the 4rth arg (in garrysmod this will be the file path). If you check the chunk name , and it's "@includes/init.lua", then that means every lua_load call from then on will be the client state and you can load your custom lua at any time, ideally right before includes/init.lua is loaded.[/QUOTE]
Doesn't Themida block this now? (I remember Gbps had a way of `unpacking` the client binaries but it took him like a week to do)
[QUOTE=Drakehawke;38262199]-snip-
[editline]31st October 2012[/editline]
Doesn't Themida block this now? (I remember Gbps had a way of `unpacking` the client binaries but it took him like a week to do)[/QUOTE]
In my modules, Themidia broke anything that required sigscanning for something in the lua_shared (lua_load is located in there) or client libraries, so yeah...
Oh yeah, and I am talking without actually experimenting on it myself, but from what I read it is apparently very [URL="http://code.google.com/p/mfsinc/source/browse/trunk/VC/!_Crap_Old_and_Testing_!/goodbye_menuplugins.lua?spec=svn49&r=49"]difficult (if not impossible) to load things from the menustate in gm13[/URL].
[QUOTE=Drakehawke;38262199]Doesn't Themida block this now? (I remember Gbps had a way of `unpacking` the client binaries but it took him like a week to do)[/QUOTE]
Yeah, Themida does protect against this now. Like you said, you can unpack Themida to view the original binary that is essentially unmodified. Although, Themida is not too hard to unpack, and there is hundreds of public tutorials on unpacking it from any binary. I have no clue why Gbps said it was so hard, it definitely does [B]not[/B] take a week of work.
[QUOTE=SashaWolf;38266892][URL="http://code.google.com/p/mfsinc/source/browse/trunk/VC/!_Crap_Old_and_Testing_!/goodbye_menuplugins.lua?spec=svn49&r=49"]difficult (if not impossible) to load things from the menustate in gm13[/URL].[/QUOTE]
[IMG]http://puu.sh/1l60Z[/IMG]
[editline]31st October 2012[/editline]
Yes, that's GWEN I used for the binary module injection, I figured it fit the theme :v:
[QUOTE=JustSoFaded;38270145]Yeah, Themida does protect against this now. Like you said, you can unpack Themida to view the original binary that is essentially unmodified. Although, Themida is not too hard to unpack, and there is hundreds of public tutorials on unpacking it from any binary. I have no clue why Gbps said it was so hard, it definitely does [B]not[/B] take a week of work.
[IMG]http://puu.sh/1l60Z[/IMG]
[editline]31st October 2012[/editline]
Yes, that's GWEN I used for the binary module injection, I figured it fit the theme :v:[/QUOTE]
It is currently easy as garry disabled Themidas VM in order to keep performance, also I'm glad you are showing off the noobs how to deal with the protection.
Next time think before posting something
Sorry, you need to Log In to post a reply to this thread.
