The idea is out there.. if anything is to be done, the main part of it has to be done server side. Anyone can break their client side software, but to break something server-side, the admin of the server (or account) is the one responsible, and if he isnt responsible, well, there are laws (in the US atleast) that will put those people off of computers for a good duration of time. But as far as any implimentation goes towards any methods used to stop things like ogc, it is my personal belief that Valve themselves are going to have to take a serious approach to stopping cheating. PunkBuster guys had a good idea, but there again was external client side software. Any decent programmer can not only program, but rip apart programs. Its all a big vicious loop of making a program work the way you want it to. And if the anti-cheat is all server side, the players cant do a whole lot in the way of breaking it, unless there are flaws in the server-side patch. -- leming
At 23:04 1/3/2002 +0000, you wrote: >reply below.. > >----- Original Message ----- >From: "Nicolai Haehnle" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Thursday, January 03, 2002 3:31 PM >Subject: Re: [hlcoders] ogc required to play?? > > > > Am Mittwoch, 2. Januar 2002 22:56 schrieben Sie: > > > "Then the hook only need to listen on the network and it will get the > > > key..." > > > > > > It won't do any good to get hold of the public key. That's the beauty of > > > the public key system. You need both the private key and the public key >to > > > decrypt the message. The private key is never sent over the network. > > > > Actually, that's no problem. Remember you're man in the middle? There's a > > tool (ettercap) that can automatically log all SSH sessions on a switched >(!) > > networked from an intruding PC. > > > > All that's required is that you're listening in the initial phase, so that > > you can replace the keys used. This is obviously the case for a cheater >proxy. > > > > Now you're all forgetting another problem with the HL protocol. Protocols > > like ssh, https, etc... are stream-oriented which is crucial for the >common > > advanced encryption algorithms. Because the internal state of the >algorithm > > changes with the data, it cannot be applied to a packet-oriented protocol > > like HL's - packets can be dropped or delivered out of order, which would > > obviously mess up the algorithm. > >Game Programming Gems has a nice little section on network protocols and >gives a few ideas of how to deal with the out of order problem, as well as >getting around all but the most hardcore of packet sniffers by adding some >random data to the end of your network packets tomake it a varible lenght >and other handy stuff. > > >_______________________________________________ >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
