Once code is loaded into memory, it's open game. It doesn't matter what the server/client relationship is. If I have a binary/application that hunts for that code in memory, then I can change any value I want.
I have written some code in my plugin that locks down certain values that I know people are using to alter game play, but to figure out all of the holes people are trying to exploit would be fruitless. Then you have 5 different games ( well L4D and L4D2 are pretty close so maybe 4 ), there's no way to handle that reasonably. If VALVe gave the server operators the choice to keep clients that have plugins running, that would cut some of them out. But even as COD6 has proved, you definitely don't need a client side plugin to cheat. Keeper -----Original Message----- From: Arg! [mailto:[email protected]] Sent: Tuesday, March 30, 2010 8:31 PM To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] Plugin Loading on clients, enough is enough. Im certainly no expert on how the libraries are being used here, but shouldnt the code explicitly state that certain cvars are to only come from the replicated source, eg the game server? Sure there might be ways around this with injection as mentioned but shouldnt the listen server (to cover the lan side) be using a seperate copy of the engine binaries which are affected here so when plugins are run in that context, they do not override the cvars being replicated from the actual gameserver the client is connected to? I was under the impression this problem existed because the client was sharing binaries with another server running on the local machine, so seperating the binaries being used would fix this surely. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
