I do agree that downloadable code produces a virus potential, but it depends on how you structure the process. You did download the hlds binary right, how do you know that it didn't have a virus? Through careful use of digital signatures you should be able to secure this process (to a reasonable degree). I haven't though about the overheads of this process, but they can't be too demanding.
The problem with a checksum (say MD5 or SHA) is that its a static check. Break it and the client is hacked forever. What cheat detection needs is dynamics. It needs to be agile with respect to the time frame of the hacks so they can be countered. And this means it needs to be able to change hourly... Right now server ops are in a bad place. For ever new hack or update to an existing hack they need to grab a new version of an anti-hack tool. This places a great burden on server ops. The writers of the anti-hack tools also have a hard time keeping up. What is need is some way of removing the overhead from the server ops. In my model Valve (or some subsiduary...) produces anti-hack "codelets". These codelets are distributed to servers when they start up (and on map change) (with digital signatures of course :). A server only needs a selection of codelets, a random set, so that the odds of picking up any hack are good over a few days. Then the server sends the codelet to the client and waits for a response (within tight timelimits). The client can verify the codelet with a CA to make sure its not a virus and then execute it. The output can then be returned to the server and checked against expected values. When a new hack comes out, propagate a new codelet to detect it. When one is overcome remove it from the pool of possible codelets. You can use various methods to make the codelets themselves dynamic. This model is similar (if not the same?) as PB's, and while I do not know the details of how PB works I have chatted with tony about some aspects of it... Now, this scheme can be broken by "hacked" servers. It can't corrupt (put viruses) on clients but it can allow cheating clients without others knowing. The scheme also has some vunerabilities that you need to code around (like hyjacking DNS for eg....) BUT it will provide a low overhead, dynamic (agile) anti-cheat tool :) leming wrote: > Executable code downloaded and run is a spawning pool for viruses, but > good idea nonetheless. Maybe have my original idea of a checksum being > used on the client dll that was loaded by the game client-side, and > compare it to a checksum that the server the player is playing on had. > If the checksums dont match, the client is intervening with the loading > of the proper mod, and/or the server has things messed up. Also an idea > would be to not only stop at checking the client dll being loaded, but > to also do a check on the memory that the mod was loaded into. This > would prevent client-side hacks from changing around the executable > memory to do what they wanted to do. A little extra temporary overhead, > but the process can be run low-profile on the system, thus consuming > less processing power, leaving more for the game rendering etc etc (I > wouldn't want to suggest something that would leave the kids losing 3 > fps to check if they are cheating...) > -- > leming > > At 13:49 1/5/2002 +1100, you wrote: > >> hopefully Valve have some better ideas ;) >> The client should be treated as untrusted and the server trusted (if >> the server is untrusted also then you are screwed :) So you just need >> to implement some checking on the client. >> My idea would be to have executable code be downloaded from the server >> to the client to be run (ala PB), this make a hackers life hard. >> However, it can lead to vunerabilities in the client if the server >> does go bad :( Other models can use Valve (WON,Sierra,etc) as a >> trusted third party for the "codelets", but it means more >> infrastructure for them... > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Alfred Reynolds [EMAIL PROTECTED] _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
