So suddenly modifying client.dll and lua_shared.dll is a no-go?

Since when was extending the Source engine some terrible threat?

Since when was debugging Gmod some terrible threat?

If you’re trying to stop cheaters, then why haven’t you moved your LuaC and SE code to a separate module outside of client.DLL, then protect it with Themida?

Since when has Themida protected anything?

These are all questions worth answering, my sweet Garry.

but its impossible to bypass like scriptenforcer

Sumbady shud maik an sooper anti-cheet modool to keep dem cheeters off.

But yeah, it’s impossible to completely stop ALL of the methods for cheating. :frowning:

More dumb ratings please. :smiley:

In someway, I dont belive it should be upto garry to protect the servers running his game. I belive that anything can be stopped with lua, And people are just too lazy to do it them selves.

As far as I remember he said in some thread that he want’s people to add features, not edit current ones ( Like most modules did with for example detours ).

This couldn’t be further from the truth. Measures should be taken by the game itself. Server Lua cannot prevent a binary module from injecting Lua into the client state by any means. What I am proposing is that Garry is doing it incorrectly.

Can’t prevent it but there’s always a way to detect it.

Also not true. Done correctly, the Lua from the module can interact with the game with no chance of detection. Lua runs on your machine, you control exactly what your client knows about itself.

[editline]22nd August 2012[/editline]

How would your system NOT be able to stop code on your system?

Nobodies perfect, it’s a constant battle between hacks and anti-hacks, someone finds a new way to detect a hack, the hack maker finds a way to fool the detector, another way to detect is found, hacker finds a way to fool that.

If there was a perfectly undetectable hack out there it would be known about.

I just dislike how garry thinks we shouldn’t be modifying current functionality - we need to modify it because it’s severely limited right now. Look at gatekeeper for example.

Well, the one I had ran from a completely different Lua state that was an exact copy of a newly created client state. There is no way to detect that at all.

I don’t know entirely how this works, but isn’t that redundant because you can’t access anything in the other state? If there was a way then surely that opens it up for detection?

Well, you create a separate Lua state, and use the internal functions to initiate it as a client state. All of the Lua libraries for accessing parts of the game are written to the state and work as if it were called from the other lua state. If you need any particular data from the other state, you can call some luaC functions or access the other state’s _G table to retrieve player variables and what not, then use those player variables on your new state.

Long story short, code from the regular client state cannot possibly interact or detect code from the other state, while the other state has access to everything the client state has access to.

Wow, that was the ugliest unpack I’ve ever done. It took me this entire week from monday to today to get it fully unpacked and able to run in place of the packed dll. I now have both client.dll and lua_shared.dll unpacked as if they were never packed with Themida. You have to run them with garrysmod as a sourcemod because steam likes to overwrite modifications to files when it loads it as the actual game.

Anyone interested in the files or process should just PM me.

Triple post central all up in here.

Those who were interested in the unpacked dlls can find them in my tutorial post here: