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...
leming wrote: > To remove the client/server bundle would cause some problems, and some > kind of checksum is about all I can think of to protect mod loading. > Routines called to verify a mod can all be spoofed. And from what I've > seen (maybe actual cheaters can prove me wrong here) is that the > majority of hacks are not coming from a server exploit, but rather from > a client hack. My choice anti-hack is the one that records and compares > where the client is aiming in relation to other players, when the player > hits walls while shooting at a player on the other side, etc etc. But > the overhead for those calculations builds up over time, and its my > personal belief that there must be a better way to play multiplayer > without cheats other than confining myself to only playing on a LAN so I > know actual skill is at play. But a big problem with checksums, is what > do you compare them with? Doing some sort of addition to WON auth's for > the mod would be probably more than Valve/Sierra wants to do, and online > communications can always be spoofed. Program in a checksum and it will > only be a matter of hours after release before someone has pulled out a > hex editor. Anyone have any improvements on the idea or something better? > -- > leming > > At 18:21 1/4/2002 -0800, you wrote: > >> > An idea might be that the half-life game itself (valve guy stuff) >> would do >> > more of a "security check" on the mod being loaded. The game is >> provided >> > the location of the .dll (or .so) to load, so why not do something >> like a >> > CRC on the mod, compare it do a crc of the actual distributed file >> by the >> > mod authors, and if it matches, let it load. >> <snip> >> >> Unfortunately, CRC isn't all that reliable a way to test if two files are >> identical. If I remember correctly (can't be arsed to find my Numerical >> Recipes in C right now) the CRC of a file can be made anything you >> like by >> setting a contiguous number of bits in the file, equal to the number >> of bits of >> the CRC, to a certain value. For example, if you're doing a 32-bit >> CRC, then >> by setting 32 contiguous bits anywhere in the file to certain values, >> you can >> make the CRC be any arbitrary number. This means you can make a modified >> client.dll have the same CRC as the unmodified one, just by changing 32 >> consecutive bits of it. However, there are other kinds of checksums >> similiar >> to CRC that may be better suited to this task. >> >> I'd also like to point out that as long as the server and client are >> distributed together, cheaters and crackers will be able to find and >> exploit >> vulnerabilities in a game's multiplayer system. Even though they cannot >> *modify* the server code when playing online, they still have copies >> of the >> server on their own machines, which they can dissassemble and pick >> apart at >> will. That means they will be able to find vulnerabilities (which always >> exist, no matter how much you try to eliminate them) and exploit those >> vulnerabilities to cheat. >> ---Reedbeta >> >> __________________________________________________ >> Do You Yahoo!? >> Send FREE video emails in Yahoo! Mail! >> http://promo.yahoo.com/videomail/ >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > _______________________________________________ > 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
