[hlcoders] Speed hack detection?
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hey, Im sending this to hlcoders and hlds lists. Im curious, is it possible for hlcoders via a plugin or whatnot to track player positions? What about through console messages with a cvar turned on? Surely if you can tell a player is moving at X/units per second he is using speed hack and to instantly ban, no? Or does the SDK not provide such interactivity? - Plasma -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Andrew Armstrong wrote: Im curious, is it possible for hlcoders via a plugin or whatnot to track player positions? What about through console messages with a cvar turned on? I think the biggest problem with doing this is the accuracy of the detection. The internet latency between the client and the server will mean that you aren't able to sample player's actual locations at a high rate (and certainly not a constant rate since the latency will be constantly changing as packets take different routes through the internet). This is what client-side prediction is all about, smoothing out the updates between actual packet transfers between the client and the server (so you, in effect, average out the movement between each network update to give the illusion of continuous movement). You would probably not have difficulty detecting a speed hack that was a LARGE increase from the server's max speed (i.e. 2X speed, 4X speed, etc), but trying to determine if someone is going 10% to 20% faster over a small amount of time would be more difficult (and more likely to generate false positives). If you come up with a good method of doing this that doesn't falsely accuse players who have wildly varying network latencies, please let us all know about it. ;) -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Yes, every speed hacker ive seen are zooming around the map. I want it to catch them. - Plasma - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 1:06 AM Subject: Re: [hlcoders] Speed hack detection? > Andrew Armstrong wrote: > > > > Im curious, is it possible for hlcoders via a plugin or whatnot to > > track player positions? What about through console messages with a > > cvar turned on? > > I think the biggest problem with doing this is the accuracy of the > detection. The internet latency between the client and the server will > mean that you aren't able to sample player's actual locations at a high > rate (and certainly not a constant rate since the latency will be > constantly changing as packets take different routes through the > internet). This is what client-side prediction is all about, smoothing > out the updates between actual packet transfers between the client and > the server (so you, in effect, average out the movement between each > network update to give the illusion of continuous movement). > > You would probably not have difficulty detecting a speed hack that was a > LARGE increase from the server's max speed (i.e. 2X speed, 4X speed, > etc), but trying to determine if someone is going 10% to 20% faster over > a small amount of time would be more difficult (and more likely to > generate false positives). > > If you come up with a good method of doing this that doesn't falsely > accuse players who have wildly varying network latencies, please let us > all know about it. ;) > > -- > Jeffrey "botman" Broome > > ___ > 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
Re: [hlcoders] Speed hack detection?
It's very possible to do that, but as Jeff said you will get a lot more false positives just due to altering latencies rather than real hackers. In theory it is sound but unless you have a decent thresh hold on hacking speeds and just lagging speeds, a better way of doing this without banning non hackers would be to use your eyes. It's not much of an answer but unless you want everyone who plays on your server to be banned because they had a nice little spike in their ping then it's the only real answer. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
On 5/18/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > You would probably not have difficulty detecting a speed hack that was a > LARGE increase from the server's max speed (i.e. 2X speed, 4X speed, > etc), but trying to determine if someone is going 10% to 20% faster over > a small amount of time would be more difficult (and more likely to > generate false positives). > > If you come up with a good method of doing this that doesn't falsely > accuse players who have wildly varying network latencies, please let us > all know about it. ;) Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? Obviously if you consistantly ban people going 50%+ faster the hackers will lower their speed below that threshold. However, it's a lot less annoying for others to play against that kind of limited cheating as you at least have a chance of killing the SOB. The other Jeff ;) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The "current location" (in the array of players that you keep in your plugin) becomes the "previous location". Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the "current location" field of your array of players. If the speed calculated is above the server max, increment a "hack" counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The "current location" (in the array of players that you keep in your plugin) becomes the "previous location". Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the "current location" field of your array of players. If the speed calculated is above the server max, increment a "hack" counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- Jeffrey "botman" Broome ___ 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
Re: [hlcoders] Speed hack detection?
high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.) On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: > I have created a speedhack detector for amxmodx ( Not released publicy as > of yet ), and i encountered alot of problems i dident think of before i > started. There is alot of things in a half-life map that can effect the > players speed ( Ingame Entities ), that you neeed to check for. > I also found that making sure the server FPS was stable above 60 lowered > false detections. > A aggresive high ping kicker ( ppl with constatly changning ping get easly > detected ) > > - Original Message - > From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> > To: > Sent: Thursday, May 19, 2005 12:36 AM > Subject: Re: [hlcoders] Speed hack detection? > > > > Jeff Fearn wrote: > >> > >> Say one put a threshold of 50% or 100% speed up, how would you go > >> about detecting that in a server plugin? > > > > What I would do is keep a list of players currently on the server (store > > their edict as they connect along with their current location). The > > player's location can be obtained from the > > ICollideable::GetCollisionOrigin() function. > > > > If your server plugin GetFrame() function keep checking each player's > > current location every so often (say every 0.5 seconds). > > > > The "current location" (in the array of players that you keep in your > > plugin) becomes the "previous location". Subtract the player's current > > location from the previous location to get a vector. Determine the > > length of that vector (the distance between now and then), and divide > > the distance by the time (to get speed, i.e. units/second). Store the > > new current location in the "current location" field of your array of > > players. > > > > If the speed calculated is above the server max, increment a "hack" > > counter. If the speed is below the server max, decrement the hack > > counter (not letting it fall below 0). When the hack counter reaches > > some maximum amount (let's say 6, which would be 3 seconds worth of > > compares), warn the player that the server thinks they are speed hacking > > and they will be given a 30 second grace period to turn it off or be > > banned from the server. > > > > Don't check them again for 30 seconds, then if they continue to reach > > the hack count, ban them. > > > > It's not fool proof and can lead to some false positives, but as long as > > you allow enough time between comparisons (the 0.5 second window) and as > > long as you require consecutive check failures (the counting to 6 > > thing), you should have less people failing due to high latency network > > connections. > > > > The only problem is how do you handle falling speeds (if you have a long > > drop that can last for 5 or 6 seconds) and how do you handle teleporters > > which will look like an intantaneous jump from point A to point B making > > a speed that approaches the speed of light! :) > > > > Again, averaging things out over several seconds should help avoid even > > these problems. > > > > -- > > Jeffrey "botman" Broome > > > > ___ > > 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 > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Would it easier to check if that variable or whatever they changing? Whether it would be in memory etc? Do that you would need a client / server type of detection I suppose... As botman said, there are to many factors which can cause false detections if the player is lagging. Even the physics in-game could cause false detections. Just throwing some ideas out there. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Erling K. Sæterdal" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 7:19 PM Subject: Re: [hlcoders] Speed hack detection? I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The "current location" (in the array of players that you keep in your plugin) becomes the "previous location". Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the "current location" field of your array of players. If the speed calculated is above the server max, increment a "hack" counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- Jeffrey "botman" Broome ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Is there a way to test to see if someone's systems clock is running slower or quicker? From the server itself? You could probably do this in a mod where the client would notify the server of the clock speed of the client. Compared to the servers if it is "threshold" faster (or slower) they are speed hacking. Plugin probably wouldn't work so well unless there was some kind of client part of the plugin. Just another idea... I wonder if vac2 would be able to detect this? r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 7:54 PM Subject: Re: [hlcoders] Speed hack detection? r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). -- Jeffrey "botman" Broome ___ 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
Re: [hlcoders] Speed hack detection?
I dont know what LPBs firstly. If someone has a constant ping of 400 im sure that fine, but the problem with when a users ping spikes, when this happens your speedhack detectors gets a false detection. This can easly be seen if a user is running a p2p program in the background, his ping can easly go from 50 ish to 400+++ for a minor second. Its posible someone with a better understand of the HL engine can make a better solution then what i made. You could proberbly add a ping check that made sure his ping at least was stable, as a midle ground. - Original Message - From: "Andrew Foss" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 1:32 AM Subject: Re: [hlcoders] Speed hack detection? high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.) On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? > Jeff Fearn wrote: >> >> Say one put a threshold of 50% or 100% speed up, how would you go >> about detecting that in a server plugin? > > What I would do is keep a list of players currently on the server (store > their edict as they connect along with their current location). The > player's location can be obtained from the > ICollideable::GetCollisionOrigin() function. > > If your server plugin GetFrame() function keep checking each player's > current location every so often (say every 0.5 seconds). > > The "current location" (in the array of players that you keep in your > plugin) becomes the "previous location". Subtract the player's current > location from the previous location to get a vector. Determine the > length of that vector (the distance between now and then), and divide > the distance by the time (to get speed, i.e. units/second). Store the > new current location in the "current location" field of your array of > players. > > If the speed calculated is above the server max, increment a "hack" > counter. If the speed is below the server max, decrement the hack > counter (not letting it fall below 0). When the hack counter reaches > some maximum amount (let's say 6, which would be 3 seconds worth of > compares), warn the player that the server thinks they are speed hacking > and they will be given a 30 second grace period to turn it off or be > banned from the server. > > Don't check them again for 30 seconds, then if they continue to reach > the hack count, ban them. > > It's not fool proof and can lead to some false positives, but as long as > you allow enough time between comparisons (the 0.5 second window) and as > long as you require consecutive check failures (the counting to 6 > thing), you should have less people failing due to high latency network > connections. > > The only problem is how do you handle falling speeds (if you have a long > drop that can last for 5 or 6 seconds) and how do you handle teleporters > which will look like an intantaneous jump from point A to point B making > a speed that approaches the speed of light! :) > > Again, averaging things out over several seconds should help avoid even > these problems. > > -- > Jeffrey "botman" Broome > > ___ > 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 ___ 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
Re: [hlcoders] Speed hack detection?
But then whoever writes the hacks would find that exploit and make it so it tricks the server to make him think is ping was 400++ a lag hack On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: > I dont know what LPBs firstly. > > If someone has a constant ping of 400 im sure that fine, but the problem > with when a users ping spikes, when this happens your speedhack detectors > gets a false detection. > This can easly be seen if a user is running a p2p program in the background, > his ping can easly go from 50 ish to 400+++ for a minor second. Its posible > someone with a better understand of the HL engine can make a better solution > then what i made. > You could proberbly add a ping check that made sure his ping at least was > stable, as a midle ground. > > - Original Message - > From: "Andrew Foss" <[EMAIL PROTECTED]> > To: > Sent: Thursday, May 19, 2005 1:32 AM > Subject: Re: [hlcoders] Speed hack detection? > > > high ping kicking is mean and spiteful. I don't want to rant about it, > but lag comp nullifies any complaints LPBs have. (which should be > none, because HPBs don't lag the game. if anything LPBs with > aggressive settings do.) > > On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: > > I have created a speedhack detector for amxmodx ( Not released publicy as > > of yet ), and i encountered alot of problems i dident think of before i > > started. There is alot of things in a half-life map that can effect the > > players speed ( Ingame Entities ), that you neeed to check for. > > I also found that making sure the server FPS was stable above 60 lowered > > false detections. > > A aggresive high ping kicker ( ppl with constatly changning ping get easly > > detected ) > > > > ----- Original Message - > > From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> > > To: > > Sent: Thursday, May 19, 2005 12:36 AM > > Subject: Re: [hlcoders] Speed hack detection? > > > > > > > Jeff Fearn wrote: > > >> > > >> Say one put a threshold of 50% or 100% speed up, how would you go > > >> about detecting that in a server plugin? > > > > > > What I would do is keep a list of players currently on the server (store > > > their edict as they connect along with their current location). The > > > player's location can be obtained from the > > > ICollideable::GetCollisionOrigin() function. > > > > > > If your server plugin GetFrame() function keep checking each player's > > > current location every so often (say every 0.5 seconds). > > > > > > The "current location" (in the array of players that you keep in your > > > plugin) becomes the "previous location". Subtract the player's current > > > location from the previous location to get a vector. Determine the > > > length of that vector (the distance between now and then), and divide > > > the distance by the time (to get speed, i.e. units/second). Store the > > > new current location in the "current location" field of your array of > > > players. > > > > > > If the speed calculated is above the server max, increment a "hack" > > > counter. If the speed is below the server max, decrement the hack > > > counter (not letting it fall below 0). When the hack counter reaches > > > some maximum amount (let's say 6, which would be 3 seconds worth of > > > compares), warn the player that the server thinks they are speed hacking > > > and they will be given a 30 second grace period to turn it off or be > > > banned from the server. > > > > > > Don't check them again for 30 seconds, then if they continue to reach > > > the hack count, ban them. > > > > > > It's not fool proof and can lead to some false positives, but as long as > > > you allow enough time between comparisons (the 0.5 second window) and as > > > long as you require consecutive check failures (the counting to 6 > > > thing), you should have less people failing due to high latency network > > > connections. > > > > > > The only problem is how do you handle falling speeds (if you have a long > > > drop that can last for 5 or 6 seconds) and how do you handle teleporters > > > which will look like an intantaneous jump from point A to point B making > > > a speed that approaches the speed of light! :) > > > > > > Again, averaging things out over several seconds should help avoid eve
Re: [hlcoders] Speed hack detection?
On 5/19/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > r00t 3:16 wrote: > > Does anyone know (please do not post it if you do know) how the speed hack > > actually works? > > It seems they are somehow changing a variable in memory ? Or are they > > tricking the server somehow ? > > Usually the client's system clock is running faster (slower?) than > normal, I can't remember which way the system clock needs to go to make > the game engine think time is passing more slowly. Your client machine > is running faster than normal so normal movement speed on your machine > become high movement speed on the server (who's running on a different > clock speed). > > If the client's game engine is ticking faster/slower than the server's > game engine, the client will be able to move larger distances over the > same amount of time. It's sort of like the reverse of Einstein's theory > of relativity. Distances become smaller for people who are moving > faster in time (or something like that). Surely this is where it should be caught by the engine. I don't mean the engine should ban/stop/warn the player, but that the engine should know that even though the cheater is saying this is tick 3000, the server is only at tick 2000, and thus the movement should not be processed until tick 3000. i.e even if the game plays faster on the cheaters computer, those extra ticks should not be processed inline by the server and should not be propigated to the other clients until it's the right time. Obviously I am very wrong, because if it was that easy it would be fixed ... google is my friend, I go visit him now ;) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
True. Any anti cheat for that matter needs to be update constantly to be affective. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Michael Kramer" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 8:54 PM Subject: Re: [hlcoders] Speed hack detection? But then whoever writes the hacks would find that exploit and make it so it tricks the server to make him think is ping was 400++ a lag hack On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: I dont know what LPBs firstly. If someone has a constant ping of 400 im sure that fine, but the problem with when a users ping spikes, when this happens your speedhack detectors gets a false detection. This can easly be seen if a user is running a p2p program in the background, his ping can easly go from 50 ish to 400+++ for a minor second. Its posible someone with a better understand of the HL engine can make a better solution then what i made. You could proberbly add a ping check that made sure his ping at least was stable, as a midle ground. - Original Message - From: "Andrew Foss" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 1:32 AM Subject: Re: [hlcoders] Speed hack detection? high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.) On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: > I have created a speedhack detector for amxmodx ( Not released publicy > as > of yet ), and i encountered alot of problems i dident think of before i > started. There is alot of things in a half-life map that can effect the > players speed ( Ingame Entities ), that you neeed to check for. > I also found that making sure the server FPS was stable above 60 lowered > false detections. > A aggresive high ping kicker ( ppl with constatly changning ping get > easly > detected ) > > - Original Message - > From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> > To: > Sent: Thursday, May 19, 2005 12:36 AM > Subject: Re: [hlcoders] Speed hack detection? > > > > Jeff Fearn wrote: > >> > >> Say one put a threshold of 50% or 100% speed up, how would you go > >> about detecting that in a server plugin? > > > > What I would do is keep a list of players currently on the server > > (store > > their edict as they connect along with their current location). The > > player's location can be obtained from the > > ICollideable::GetCollisionOrigin() function. > > > > If your server plugin GetFrame() function keep checking each player's > > current location every so often (say every 0.5 seconds). > > > > The "current location" (in the array of players that you keep in your > > plugin) becomes the "previous location". Subtract the player's > > current > > location from the previous location to get a vector. Determine the > > length of that vector (the distance between now and then), and divide > > the distance by the time (to get speed, i.e. units/second). Store the > > new current location in the "current location" field of your array of > > players. > > > > If the speed calculated is above the server max, increment a "hack" > > counter. If the speed is below the server max, decrement the hack > > counter (not letting it fall below 0). When the hack counter reaches > > some maximum amount (let's say 6, which would be 3 seconds worth of > > compares), warn the player that the server thinks they are speed > > hacking > > and they will be given a 30 second grace period to turn it off or be > > banned from the server. > > > > Don't check them again for 30 seconds, then if they continue to reach > > the hack count, ban them. > > > > It's not fool proof and can lead to some false positives, but as long > > as > > you allow enough time between comparisons (the 0.5 second window) and > > as > > long as you require consecutive check failures (the counting to 6 > > thing), you should have less people failing due to high latency > > network > > connections. > > > > The only problem is how do you handle falling speeds (if you have a > > long > > drop that can last for 5 or 6 seconds) and how do you handle > > teleporters > > which will look like an intantaneous jump from point A to point B > > making > > a speed that approaches the speed of light! :) > > > > Again, averaging things out over several seconds should help avoid > > even > > th
Re: [hlcoders] Speed hack detection?
Yes, that is kind of crazy really. But what is weird, if they are speeding up the clock would you foot alot faster and throw grenades faster etc? I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire faster but it might be hard to tell dunno.. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeff Fearn" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 9:32 PM Subject: Re: [hlcoders] Speed hack detection? On 5/19/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: r00t 3:16 wrote: > Does anyone know (please do not post it if you do know) how the speed > hack > actually works? > It seems they are somehow changing a variable in memory ? Or are they > tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). Surely this is where it should be caught by the engine. I don't mean the engine should ban/stop/warn the player, but that the engine should know that even though the cheater is saying this is tick 3000, the server is only at tick 2000, and thus the movement should not be processed until tick 3000. i.e even if the game plays faster on the cheaters computer, those extra ticks should not be processed inline by the server and should not be propigated to the other clients until it's the right time. Obviously I am very wrong, because if it was that easy it would be fixed ... google is my friend, I go visit him now ;) Jeff ___ 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
Re: [hlcoders] Speed hack detection?
What I find puzzling is why the hl/src server is not authorative over the players movement? How come it doesnt internally say, hey, you cant move that fast, im sorry, back you go to where you should be. Surely going on what the client says they should be in the map is rediculous. - Plasma - Original Message - From: "r00t 3:16" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 11:56 AM Subject: Re: [hlcoders] Speed hack detection? > Yes, that is kind of crazy really. > But what is weird, if they are speeding up the clock would you foot alot > faster and throw grenades faster etc? > I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire > faster but it might be hard to tell dunno.. > > > r00t 3:16 > CQC Gaming > www.cqc-gaming.com > - Original Message - > From: "Jeff Fearn" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, May 18, 2005 9:32 PM > Subject: Re: [hlcoders] Speed hack detection? > > > > On 5/19/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > >> r00t 3:16 wrote: > >> > Does anyone know (please do not post it if you do know) how the speed > >> > hack > >> > actually works? > >> > It seems they are somehow changing a variable in memory ? Or are they > >> > tricking the server somehow ? > >> > >> Usually the client's system clock is running faster (slower?) than > >> normal, I can't remember which way the system clock needs to go to make > >> the game engine think time is passing more slowly. Your client machine > >> is running faster than normal so normal movement speed on your machine > >> become high movement speed on the server (who's running on a different > >> clock speed). > >> > >> If the client's game engine is ticking faster/slower than the server's > >> game engine, the client will be able to move larger distances over the > >> same amount of time. It's sort of like the reverse of Einstein's theory > >> of relativity. Distances become smaller for people who are moving > >> faster in time (or something like that). > > > > Surely this is where it should be caught by the engine. I don't mean > > the engine should ban/stop/warn the player, but that the engine should > > know that even though the cheater is saying this is tick 3000, the > > server is only at tick 2000, and thus the movement should not be > > processed until tick 3000. > > > > i.e even if the game plays faster on the cheaters computer, those > > extra ticks should not be processed inline by the server and should > > not be propigated to the other clients until it's the right time. > > > > Obviously I am very wrong, because if it was that easy it would be > > fixed ... google is my friend, I go visit him now ;) > > > > Jeff > > > > ___ > > 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 > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Yes, speed hacks enable you to fire faster. With a 6x speed hack you can empty a clip of the AK47 in practically no time. It doesn't let you reload faster, though. - Original Message - From: "r00t 3:16" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 6:56 PM Subject: Re: [hlcoders] Speed hack detection? > Yes, that is kind of crazy really. > But what is weird, if they are speeding up the clock would you foot alot > faster and throw grenades faster etc? > I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire > faster but it might be hard to tell dunno.. > > > r00t 3:16 > CQC Gaming > www.cqc-gaming.com > - Original Message - > From: "Jeff Fearn" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, May 18, 2005 9:32 PM > Subject: Re: [hlcoders] Speed hack detection? > > > > On 5/19/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > >> r00t 3:16 wrote: > >> > Does anyone know (please do not post it if you do know) how the speed > >> > hack > >> > actually works? > >> > It seems they are somehow changing a variable in memory ? Or are they > >> > tricking the server somehow ? > >> > >> Usually the client's system clock is running faster (slower?) than > >> normal, I can't remember which way the system clock needs to go to make > >> the game engine think time is passing more slowly. Your client machine > >> is running faster than normal so normal movement speed on your machine > >> become high movement speed on the server (who's running on a different > >> clock speed). > >> > >> If the client's game engine is ticking faster/slower than the server's > >> game engine, the client will be able to move larger distances over the > >> same amount of time. It's sort of like the reverse of Einstein's theory > >> of relativity. Distances become smaller for people who are moving > >> faster in time (or something like that). > > > > Surely this is where it should be caught by the engine. I don't mean > > the engine should ban/stop/warn the player, but that the engine should > > know that even though the cheater is saying this is tick 3000, the > > server is only at tick 2000, and thus the movement should not be > > processed until tick 3000. > > > > i.e even if the game plays faster on the cheaters computer, those > > extra ticks should not be processed inline by the server and should > > not be propigated to the other clients until it's the right time. > > > > Obviously I am very wrong, because if it was that easy it would be > > fixed ... google is my friend, I go visit him now ;) > > > > Jeff > > > > ___ > > 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 > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
but it should reload faster though cause reloading is tick based ? Weird stuff... I know in some other games you can turn the game speed up on the server. The first speed hack I ever seen was on one of those games and it was like the client had their game speed way up but the servers and the other clients had their's set to the normal. I guess that is what botman was saying... As Andrew said you would think the server would do sanity checks on those sort of things, because those seem to be a global variable? r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Daniel Jennings" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 10:22 PM Subject: Re: [hlcoders] Speed hack detection? Yes, speed hacks enable you to fire faster. With a 6x speed hack you can empty a clip of the AK47 in practically no time. It doesn't let you reload faster, though. - Original Message - From: "r00t 3:16" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 6:56 PM Subject: Re: [hlcoders] Speed hack detection? Yes, that is kind of crazy really. But what is weird, if they are speeding up the clock would you foot alot faster and throw grenades faster etc? I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire faster but it might be hard to tell dunno.. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeff Fearn" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 18, 2005 9:32 PM Subject: Re: [hlcoders] Speed hack detection? > On 5/19/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: >> r00t 3:16 wrote: >> > Does anyone know (please do not post it if you do know) how the >> > speed >> > hack >> > actually works? >> > It seems they are somehow changing a variable in memory ? Or are >> > they >> > tricking the server somehow ? >> >> Usually the client's system clock is running faster (slower?) than >> normal, I can't remember which way the system clock needs to go to >> make >> the game engine think time is passing more slowly. Your client >> machine >> is running faster than normal so normal movement speed on your machine >> become high movement speed on the server (who's running on a different >> clock speed). >> >> If the client's game engine is ticking faster/slower than the server's >> game engine, the client will be able to move larger distances over the >> same amount of time. It's sort of like the reverse of Einstein's theory >> of relativity. Distances become smaller for people who are moving >> faster in time (or something like that). > > Surely this is where it should be caught by the engine. I don't mean > the engine should ban/stop/warn the player, but that the engine should > know that even though the cheater is saying this is tick 3000, the > server is only at tick 2000, and thus the movement should not be > processed until tick 3000. > > i.e even if the game plays faster on the cheaters computer, those > extra ticks should not be processed inline by the server and should > not be propigated to the other clients until it's the right time. > > Obviously I am very wrong, because if it was that easy it would be > fixed ... google is my friend, I go visit him now ;) > > Jeff > > ___ > 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 ___ 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
Re: [hlcoders] Speed hack detection?
At 07:51 PM 5/18/2005, root 3:16 wrote: but it should reload faster though cause reloading is tick based ? Weird stuff... Not wierd at all. The server's clock is what determine's server tick rate and therefore the timing of Think() functions. Server alone decides when you have reloaded. Michael A. Hobson email: [EMAIL PROTECTED] (310) 344-3585 (cell) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
If the server knows that you are reloading and won't let you reload any faster, why can't it stop you from walking or running, hell even firing really fast? I know there are a lot of ambiguous cases like teleporters and stuff, but still it seems a bit odd that you can haul balls accross a map and the server couldn't care less, yet it controls how long it takes you to reload your gun. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Sometimes a player will lag out for a couple seconds and then when his posistion is updated he "jumps" to his actual location. It seems like that would appear to be a speed hack if you weren't checking an "average" speed for a long enough period of game history (10-20 seconds?). I think the problem of detecting a speed hack is much more complex than it sounds at first. On 5/19/05, Andrew (British_Bomber) <[EMAIL PROTECTED]> wrote: > If the server knows that you are reloading and won't let you reload > any faster, why can't it stop you from walking or running, hell even > firing really fast? I know there are a lot of ambiguous cases like > teleporters and stuff, but still it seems a bit odd that you can haul > balls accross a map and the server couldn't care less, yet it controls > how long it takes you to reload your gun. > > ___ > 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
Re: [hlcoders] Speed hack detection?
That is exacly why my solution required a aggressive high ping kicker. I would love to see someone make a more robust solution then mine is. - Original Message - From: "Michael Kramer" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 2:54 AM Subject: Re: [hlcoders] Speed hack detection? But then whoever writes the hacks would find that exploit and make it so it tricks the server to make him think is ping was 400++ a lag hack On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: I dont know what LPBs firstly. If someone has a constant ping of 400 im sure that fine, but the problem with when a users ping spikes, when this happens your speedhack detectors gets a false detection. This can easly be seen if a user is running a p2p program in the background, his ping can easly go from 50 ish to 400+++ for a minor second. Its posible someone with a better understand of the HL engine can make a better solution then what i made. You could proberbly add a ping check that made sure his ping at least was stable, as a midle ground. - Original Message - From: "Andrew Foss" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 1:32 AM Subject: Re: [hlcoders] Speed hack detection? high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.) On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote: > I have created a speedhack detector for amxmodx ( Not released publicy > as > of yet ), and i encountered alot of problems i dident think of before i > started. There is alot of things in a half-life map that can effect the > players speed ( Ingame Entities ), that you neeed to check for. > I also found that making sure the server FPS was stable above 60 lowered > false detections. > A aggresive high ping kicker ( ppl with constatly changning ping get > easly > detected ) > > - Original Message - > From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> > To: > Sent: Thursday, May 19, 2005 12:36 AM > Subject: Re: [hlcoders] Speed hack detection? > > > > Jeff Fearn wrote: > >> > >> Say one put a threshold of 50% or 100% speed up, how would you go > >> about detecting that in a server plugin? > > > > What I would do is keep a list of players currently on the server > > (store > > their edict as they connect along with their current location). The > > player's location can be obtained from the > > ICollideable::GetCollisionOrigin() function. > > > > If your server plugin GetFrame() function keep checking each player's > > current location every so often (say every 0.5 seconds). > > > > The "current location" (in the array of players that you keep in your > > plugin) becomes the "previous location". Subtract the player's > > current > > location from the previous location to get a vector. Determine the > > length of that vector (the distance between now and then), and divide > > the distance by the time (to get speed, i.e. units/second). Store the > > new current location in the "current location" field of your array of > > players. > > > > If the speed calculated is above the server max, increment a "hack" > > counter. If the speed is below the server max, decrement the hack > > counter (not letting it fall below 0). When the hack counter reaches > > some maximum amount (let's say 6, which would be 3 seconds worth of > > compares), warn the player that the server thinks they are speed > > hacking > > and they will be given a 30 second grace period to turn it off or be > > banned from the server. > > > > Don't check them again for 30 seconds, then if they continue to reach > > the hack count, ban them. > > > > It's not fool proof and can lead to some false positives, but as long > > as > > you allow enough time between comparisons (the 0.5 second window) and > > as > > long as you require consecutive check failures (the counting to 6 > > thing), you should have less people failing due to high latency > > network > > connections. > > > > The only problem is how do you handle falling speeds (if you have a > > long > > drop that can last for 5 or 6 seconds) and how do you handle > > teleporters > > which will look like an intantaneous jump from point A to point B > > making > > a speed that approaches the speed of light! :) > > > > Again, averaging things out over several seconds should help avoid > >
Re: [hlcoders] Speed hack detection?
On 5/19/05, LDuke <[EMAIL PROTECTED]> wrote: > Sometimes a player will lag out for a couple seconds and then when his > posistion is updated he "jumps" to his actual location. It seems like > that would appear to be a speed hack if you weren't checking an > "average" speed for a long enough period of game history (10-20 > seconds?). How does this account, or not as is the case, for game time? If the client says its game time A and I'm here, then, it's game time B and I'm there, how is that in anyway difficult to calculate distance/time? This is only a problem if the client doesn't send or the server doesn't use the idea of game time. I understood that this is how the prediction stuff works, using game time to schedule and co-ordinate events between client and server. > I think the problem of detecting a speed hack is much more complex > than it sounds at first. It must be :) Anyone have any links to some dicussion on this? Google has forsaken me! ;) Jeff. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
From what I have read they are using speederxp to increase the application's speed or something. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeff Fearn" <[EMAIL PROTECTED]> To: Sent: Thursday, May 19, 2005 10:15 PM Subject: Re: [hlcoders] Speed hack detection? On 5/19/05, LDuke <[EMAIL PROTECTED]> wrote: Sometimes a player will lag out for a couple seconds and then when his posistion is updated he "jumps" to his actual location. It seems like that would appear to be a speed hack if you weren't checking an "average" speed for a long enough period of game history (10-20 seconds?). How does this account, or not as is the case, for game time? If the client says its game time A and I'm here, then, it's game time B and I'm there, how is that in anyway difficult to calculate distance/time? This is only a problem if the client doesn't send or the server doesn't use the idea of game time. I understood that this is how the prediction stuff works, using game time to schedule and co-ordinate events between client and server. I think the problem of detecting a speed hack is much more complex than it sounds at first. It must be :) Anyone have any links to some dicussion on this? Google has forsaken me! ;) Jeff. ___ 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
Re: [hlcoders] Speed hack detection?
> If the client says its game time A and I'm here, then, it's game time > B and I'm there, how is that in anyway difficult to calculate > distance/time? This is only a problem if the client doesn't send or > the server doesn't use the idea of game time. > I would think that the issue is, that they both know that time has passed, but they also know that player should be somewhere new and through the general confusion that is lag, the server or client decides he should be *points at a location* there. So they make him be "there". I dont know the exact technicalities but through that extreme change in location the ground is made up quite quickly and the speed hack detects them. I could be horribly wrong on this, infact I know I am wrong and would love to find out the REAL answer, rather than my made up story. so pick it appart all you want :D ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
On 5/23/05, Andrew (British_Bomber) <[EMAIL PROTECTED]> wrote: > > If the client says its game time A and I'm here, then, it's game time > > B and I'm there, how is that in anyway difficult to calculate > > distance/time? This is only a problem if the client doesn't send or > > the server doesn't use the idea of game time. > > > > I would think that the issue is, that they both know that time has > passed, but they also know that player should be somewhere new and > through the general confusion that is lag, the server or client > decides he should be *points at a location* there. So they make him > be "there". I dont know the exact technicalities but through that > extreme change in location the ground is made up quite quickly and the > speed hack detects them. > > I could be horribly wrong on this, infact I know I am wrong and would > love to find out the REAL answer, rather than my made up story. so > pick it appart all you want :D I'll do that as soon as I'm not as horribly wrong as you are :) C'mon Yahn, all this ignorance must be aggravating you! ;) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Speed hack detection, was new SDK version is live
On 6/3/05, Mike Dussault <[EMAIL PROTECTED]> wrote: > http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? I note that the server can specify the maximum rate clients can request updates from the server. Would it be possible to have a sever variable to control the maximum number of ticks/updates recieved from the client per second? If a server received more than this setting the extra updates would be dropped or averaged. Jeff "Codiac" Fearn ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? Yes, I believe that is correct. The player sends movement commands to the server and the server says "H, okay you are moving in this direction, let me calculate your new velocity and location based on where I think you were before and which way you were going before and then I'll send that information back to you." The client doesn't even specify HOW MUCH they moved (i.e. the distance during that update). The client only says "I'm moving THIS way now". But note that the client is also simulating this movement update purely client-side (it just isn't authoritative since the server is the only one that keeps track of where everything REALLY is as far as collisions and bullet hits, etc.). -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/3/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeff Fearn wrote: > > > > Am I correct that a player does not actually state their position in > > the world but simply gives impulses (buttons), and therefore it's the > > number of impulses per second that allows speed hacking? > > Yes, I believe that is correct. The player sends movement commands to > the server and the server says "H, okay you are moving in this > direction, let me calculate your new velocity and location based on > where I think you were before and which way you were going before and > then I'll send that information back to you." The client doesn't even > specify HOW MUCH they moved (i.e. the distance during that update). The > client only says "I'm moving THIS way now". > > But note that the client is also simulating this movement update purely > client-side (it just isn't authoritative since the server is the only > one that keeps track of where everything REALLY is as far as collisions > and bullet hits, etc.). Except the server can be fooled if you send it lots of updates because it doesn't seem to validate how often you send updates ... assuming that's how the speed hack actually works :) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
I don't think you can speed hack by increasing your cl_cmdrate. Check out this bit of networking doco valve published recently: "The client creates user commands from sampling input devices with the same tick rate that the server is running with. A user command is basically a snapshot of the current keyboard and mouse state." http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html So sending more snapshots is still only telling the server you're holding down the forwards button. And the server dosen't add your velocity every time it gets the user commands, it does it once per server frame. On 6/4/05, Jeff Fearn <[EMAIL PROTECTED]> wrote: > On 6/3/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > > Jeff Fearn wrote: > > > > > > Am I correct that a player does not actually state their position in > > > the world but simply gives impulses (buttons), and therefore it's the > > > number of impulses per second that allows speed hacking? > > > > Yes, I believe that is correct. The player sends movement commands to > > the server and the server says "H, okay you are moving in this > > direction, let me calculate your new velocity and location based on > > where I think you were before and which way you were going before and > > then I'll send that information back to you." The client doesn't even > > specify HOW MUCH they moved (i.e. the distance during that update). The > > client only says "I'm moving THIS way now". > > > > But note that the client is also simulating this movement update purely > > client-side (it just isn't authoritative since the server is the only > > one that keeps track of where everything REALLY is as far as collisions > > and bullet hits, etc.). > > Except the server can be fooled if you send it lots of updates because > it doesn't seem to validate how often you send updates ... assuming > that's how the speed hack actually works :) > > Jeff > > ___ > 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
Re: [hlcoders] Speed hack detection, was new SDK version is live
One method I know about is speederxp to speed hack search google for it... It speeds up the applications and such. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Teddy" <[EMAIL PROTECTED]> To: Sent: Saturday, June 04, 2005 1:11 AM Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live I don't think you can speed hack by increasing your cl_cmdrate. Check out this bit of networking doco valve published recently: "The client creates user commands from sampling input devices with the same tick rate that the server is running with. A user command is basically a snapshot of the current keyboard and mouse state." http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html So sending more snapshots is still only telling the server you're holding down the forwards button. And the server dosen't add your velocity every time it gets the user commands, it does it once per server frame. On 6/4/05, Jeff Fearn <[EMAIL PROTECTED]> wrote: On 6/3/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeff Fearn wrote: > > > > Am I correct that a player does not actually state their position in > > the world but simply gives impulses (buttons), and therefore it's the > > number of impulses per second that allows speed hacking? > > Yes, I believe that is correct. The player sends movement commands to > the server and the server says "H, okay you are moving in this > direction, let me calculate your new velocity and location based on > where I think you were before and which way you were going before and > then I'll send that information back to you." The client doesn't even > specify HOW MUCH they moved (i.e. the distance during that update). > The > client only says "I'm moving THIS way now". > > But note that the client is also simulating this movement update purely > client-side (it just isn't authoritative since the server is the only > one that keeps track of where everything REALLY is as far as collisions > and bullet hits, etc.). Except the server can be fooled if you send it lots of updates because it doesn't seem to validate how often you send updates ... assuming that's how the speed hack actually works :) Jeff ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/4/05, Teddy <[EMAIL PROTECTED]> wrote: > I don't think you can speed hack by increasing your cl_cmdrate. Of course not, simple maths would lead anyone to that conclusion. Client sends X packets a second with Y commands per packet. If you double cl_cmdrate you get X*2 packets each containing Y/2 commands. The number of packets changes but the number of commands per second remains the same ... or at lest pretty damn close. > Check out this bit of networking doco valve published recently: > > "The client creates user commands from sampling input devices with the > same tick rate that the server is running with. A user command is > basically a snapshot of the current keyboard and mouse state." > http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html Unfortunately you didn't quote the most useful part of that paragraph: "This means two or more user commands are transmitted within the same packet." Increasing cl_cmdrate would decrease the number of commands contained in a packet as the packets get sent more often. > So sending more snapshots is still only telling the server you're > holding down the forwards button. And the server dosen't add your > velocity every time it gets the user commands, it does it once per > server frame. I believe this is wrong, if it were right, there would be no client side speed hacks. Assuming the server processes one packet per tick (we don't know this, the document does not say this is so, it may have a buffer of packets and process all packets in the buffer), each packet can contain multiple commands and each and every command in a packet will get processed by the server. By increasing your packet rate or increasing the number of commands per packet or combinations of both, you will be able to speed hack the server. This is how most of the hacks appear to work, they speed up the OS and send more packets per second and keep the commands per packet the same. The server processes these extra packets and the cheater gets to speed. What I'm suggesting is that the admin be able to set how many client commands the server should process per tick and that any extra commands for a player be dropped or use every X command to get a spread of commands from those supplied. e.g. if the max commands was 5 and the client sent 10, 10/5 == 2 so every 2nd command would be dropped. I await the appearance of the Valve team with their dreaded guns of "we know what we are doing sonny" to shoot me down in flames as this appears way to damn easy ;) As I said to a boss once "If it appears easy, you just don't understand the problem well enough!" :P Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Have a dig around in CBasePlayer::PhysicsSimulate() to see how it runs the player commands (#2779 of /dlls/player.cpp). It only runs the physics once per frame. Increasing the number of commands per packet won't change this... On 6/5/05, Jeff Fearn <[EMAIL PROTECTED]> wrote: > On 6/4/05, Teddy <[EMAIL PROTECTED]> wrote: > > I don't think you can speed hack by increasing your cl_cmdrate. > > Of course not, simple maths would lead anyone to that conclusion. > Client sends X packets a second with Y commands per packet. If you > double cl_cmdrate you get X*2 packets each containing Y/2 commands. > The number of packets changes but the number of commands per second > remains the same ... or at lest pretty damn close. > > > Check out this bit of networking doco valve published recently: > > > > "The client creates user commands from sampling input devices with the > > same tick rate that the server is running with. A user command is > > basically a snapshot of the current keyboard and mouse state." > > http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html > > Unfortunately you didn't quote the most useful part of that paragraph: > > "This means two or more user commands are transmitted within the same packet." > > Increasing cl_cmdrate would decrease the number of commands contained > in a packet as the packets get sent more often. > > > So sending more snapshots is still only telling the server you're > > holding down the forwards button. And the server dosen't add your > > velocity every time it gets the user commands, it does it once per > > server frame. > > I believe this is wrong, if it were right, there would be no client > side speed hacks. Assuming the server processes one packet per tick > (we don't know this, the document does not say this is so, it may have > a buffer of packets and process all packets in the buffer), each > packet can contain multiple commands and each and every command in a > packet will get processed by the server. By increasing your packet > rate or increasing the number of commands per packet or combinations > of both, you will be able to speed hack the server. > > This is how most of the hacks appear to work, they speed up the OS and > send more packets per second and keep the commands per packet the > same. The server processes these extra packets and the cheater gets to > speed. > > What I'm suggesting is that the admin be able to set how many client > commands the server should process per tick and that any extra > commands for a player be dropped or use every X command to get a > spread of commands from those supplied. e.g. if the max commands was 5 > and the client sent 10, 10/5 == 2 so every 2nd command would be > dropped. > > I await the appearance of the Valve team with their dreaded guns of > "we know what we are doing sonny" to shoot me down in flames as this > appears way to damn easy ;) > > As I said to a boss once "If it appears easy, you just don't > understand the problem well enough!" :P > > Jeff > > ___ > 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
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/6/05, Teddy <[EMAIL PROTECTED]> wrote: > Have a dig around in CBasePlayer::PhysicsSimulate() to see how it runs > the player commands (#2779 of /dlls/player.cpp). It only runs the > physics once per frame. Increasing the number of commands per packet > won't change this... A: The engine is what controls this not the mod dll. B: Please explain how you can get a speed hack from the client without sending more packets and/or commands. I don't mind being proven wrong, however that may require you provide an alternate explanation instead of just saying I'm wrong. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
It is based on world time, not # of commands. A speed hack is essentially an exploit of the server's lag compensation. Number of commands is irrelevant. A speed hack would still work if you were to only send a packet a second. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Monday, June 06, 2005 3:53 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live On 6/6/05, Teddy <[EMAIL PROTECTED]> wrote: > Have a dig around in CBasePlayer::PhysicsSimulate() to see how it runs > the player commands (#2779 of /dlls/player.cpp). It only runs the > physics once per frame. Increasing the number of commands per packet > won't change this... A: The engine is what controls this not the mod dll. B: Please explain how you can get a speed hack from the client without sending more packets and/or commands. I don't mind being proven wrong, however that may require you provide an alternate explanation instead of just saying I'm wrong. Jeff ___ 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
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/6/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > It is based on world time, not # of commands. A speed hack is essentially an > exploit of the server's lag compensation. Number of commands is irrelevant. > A speed hack would still work if you were to only send a packet a second. I think you are wrong, Botman said this earlier: On 6/3/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeff Fearn wrote: > > > > Am I correct that a player does not actually state their position in > > the world but simply gives impulses (buttons), and therefore it's the > > number of impulses per second that allows speed hacking? > > Yes, I believe that is correct. The player sends movement commands to > the server and the server says "H, okay you are moving in this > direction, let me calculate your new velocity and location based on > where I think you were before and which way you were going before and > then I'll send that information back to you." The client doesn't even > specify HOW MUCH they moved (i.e. the distance during that update). The > client only says "I'm moving THIS way now". So now I'm stuck, do I believe Botman or Deadman! Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
Ask someone at Valve :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Fearn Sent: 07 June 2005 08:37 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live On 6/6/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > It is based on world time, not # of commands. A speed hack is essentially an > exploit of the server's lag compensation. Number of commands is irrelevant. > A speed hack would still work if you were to only send a packet a second. I think you are wrong, Botman said this earlier: On 6/3/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeff Fearn wrote: > > > > Am I correct that a player does not actually state their position in > > the world but simply gives impulses (buttons), and therefore it's the > > number of impulses per second that allows speed hacking? > > Yes, I believe that is correct. The player sends movement commands to > the server and the server says "H, okay you are moving in this > direction, let me calculate your new velocity and location based on > where I think you were before and which way you were going before and > then I'll send that information back to you." The client doesn't even > specify HOW MUCH they moved (i.e. the distance during that update). The > client only says "I'm moving THIS way now". So now I'm stuck, do I believe Botman or Deadman! Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders * This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods Group Limited or its subsidiaries. Please note that e-mail communications may be monitored. The Registered Office of Littlewoods Group Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Group Limited is 5059352. * This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
LOl, it is the same thing. The movement command is based on time, that is why velocity not position is passed. Keep in mind velocity is a measurement of distance over time. If you advance time it thinks you traveled farther. You can look at the old quake code to get a fell how this is done. Also look on the web, there are some open source hacks out there. They basically speed time up for the program. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Tuesday, June 07, 2005 3:37 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live On 6/6/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > It is based on world time, not # of commands. A speed hack is essentially an > exploit of the server's lag compensation. Number of commands is irrelevant. > A speed hack would still work if you were to only send a packet a second. I think you are wrong, Botman said this earlier: On 6/3/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeff Fearn wrote: > > > > Am I correct that a player does not actually state their position in > > the world but simply gives impulses (buttons), and therefore it's the > > number of impulses per second that allows speed hacking? > > Yes, I believe that is correct. The player sends movement commands to > the server and the server says "H, okay you are moving in this > direction, let me calculate your new velocity and location based on > where I think you were before and which way you were going before and > then I'll send that information back to you." The client doesn't even > specify HOW MUCH they moved (i.e. the distance during that update). The > client only says "I'm moving THIS way now". So now I'm stuck, do I believe Botman or Deadman! Jeff ___ 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
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/7/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > LOl, it is the same thing. The movement command is based on time, that is > why velocity not position is passed. Keep in mind velocity is a measurement > of distance over time. If you advance time it thinks you traveled farther. I don't think it passes velocity, what Botman said was that it passes the impulse keys and that the server calculates your velocity from your existing velocity and the effect those impulse keys have on that velocity. Are you saying that the server is ticking along and the client is ticking at say twice as fast and the server processes ticks from the client that the servers knows are in future? It would seem that if the client sends it's game time with it's packets then it really is trivial to stop speed hacks. It becomes very simple to calculate velocity/time and compare that to sv_maxspeed. It also becomes trival to simply ignore any packet from the future. It's also fairly simple to modify that to handle teleporters and such, which aren't used in most mods anyway. It's a little more difficult, but not hugely so, to include the effects of known environmental effects, like explosions and vehicles etc. > You can look at the old quake code to get a fell how this is done. Also look > on the web, there are some open source hacks out there. They basically speed > time up for the program. This is an easy fix, ignore packets from more than a few seconds in the future. This wouldn't completely remove such hacks, but it would certainly limit them significantly. I suppose what I'm trying to find out is why this is hard to fix, I haven't heard any reason I would consider a blocker to significantly reducing the effectiveness of these hacks. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/7/05, McCormack, Chris <[EMAIL PROTECTED]> wrote: > Ask someone at Valve :) Good idea, I hear there is another email list where some of the guys for Valve join in the discussion, I'll go post there ;) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeffrey "botman" Broome wrote: Use the source Luke... src\game_shared\usercmd.h (see the "CUserCmd& operator =" function) src\game_shared\usercmd.cpp (see the WriteUserCmd & ReadUserCmd functions) UserCmd is what's passed from the client to the server when a client moves, jumps, ducks, fires weapon, etc. Any magic that happens will happen in side there. :) Doooh! I hit "Send" to quick. You'll notice that "forwardmove" and "sidemove" are 'floats' so I was wrong. The total amount of movement is passed from the client to the server saying "I've moved THIS much during the last tick.". Now it becomes obvious how sending packets with "I've moved X amount during the last Y seconds" can cause the player to move faster than normal on the server if the client lies about how much the client has moved or how long/short the time interval was. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: On 6/7/05, McCormack, Chris <[EMAIL PROTECTED]> wrote: Ask someone at Valve :) Good idea, I hear there is another email list where some of the guys for Valve join in the discussion, I'll go post there ;) Use the source Luke... src\game_shared\usercmd.h (see the "CUserCmd& operator =" function) src\game_shared\usercmd.cpp (see the WriteUserCmd & ReadUserCmd functions) UserCmd is what's passed from the client to the server when a client moves, jumps, ducks, fires weapon, etc. Any magic that happens will happen in side there. :) -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/8/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeffrey "botman" Broome wrote: > > > > Use the source Luke... > > > > src\game_shared\usercmd.h (see the "CUserCmd& operator =" function) > > src\game_shared\usercmd.cpp (see the WriteUserCmd & ReadUserCmd functions) > > > > UserCmd is what's passed from the client to the server when a client > > moves, jumps, ducks, fires weapon, etc. > > > > Any magic that happens will happen in side there. :) > > Doooh! I hit "Send" to quick. Two mistakes, you are HUMAN! ;) > You'll notice that "forwardmove" and "sidemove" are 'floats' so I was > wrong. The total amount of movement is passed from the client to the > server saying "I've moved THIS much during the last tick.". > > Now it becomes obvious how sending packets with "I've moved X amount > during the last Y seconds" can cause the player to move faster than > normal on the server if the client lies about how much the client has > moved or how long/short the time interval was. It still is not obvious, to me at least, why solving or at least highly limiting the spoofing of this is difficult. I don't have the SDK at work, so I can't check anything atm, but I am still working on HL1 so I'm wondering if there has been any major changes to the networking code for HL2. I think it's at least as spoofable as people seem to have similar issues. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
Based on the quake code here is what the move command passes: BYTE 3 (means move) FLOAT time (Used to calculate lag, ping, and movement) ANGLE viewangle X ANGLE viewangle Y ANGLE viewangle Z // The next three are the velocity of the player SHORT forward_movement SHORT sideway_movement SHORT up_movement BYTE bits (for attack and jump) BYTE impluse "I don't have the SDK at work, so I can't check anything atm, but I am still working on HL1 so I'm wondering if there has been any major changes to the networking code for HL2. I think it's at least as spoofable as people seem to have similar issues." As martino wrote about HL2 lag compensation: " The extra lantency caused by lower update rates is part of the general client latency. The actual code uses timestamps send with the user commands to set the execution time. These timestamps are checked against the average latency and if they are within a valid range, these timestamps are used since they are more precise then the calculation as stated in the doc. We can't fully rely on these timestamps since "speedhackers" could alter them." It appears HL2 has some level of detection for this, just do not know to what extent. "It would seem that if the client sends it's game time with it's packets then it really is trivial to stop speed hacks. It becomes very simple to calculate velocity/time and compare that to sv_maxspeed. It also becomes trival to simply ignore any packet from the future." sv_maxspeed is irrelevant. Calcs for maxspeed are already part of the velocity calculation and are correct. The key is the differences in the time stamps between packets compared to differences in real world time of when the packets arrived. If you compare the delta's of the message embedded times to the delta's of the real world times of when the packets arrived it should work (in theory). So if embedded delta's of the last two messages are 100 yet the real world delta's of when the packets arrived is 5 you would know something was up. The danger is a laggy player could appear as a speed hacker if you make the detection too sensitive (since network lag and UDP packet loss really do happen). So that leaves a window where some speed hacking will always be possible. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Tuesday, June 07, 2005 8:24 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live I don't think it passes velocity, what Botman said was that it passes the impulse keys and that the server calculates your velocity from your existing velocity and the effect those impulse keys have on that velocity. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/8/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > Based on the quake code here is what the move command passes: > > BYTE 3 (means move) > FLOAT time (Used to calculate lag, ping, and movement) > ANGLE viewangle X > ANGLE viewangle Y > ANGLE viewangle Z > > // The next three are the velocity of the player > SHORT forward_movement > SHORT sideway_movement > SHORT up_movement > > BYTE bits (for attack and jump) > BYTE impluse > > "I don't have the SDK at work, so I can't check anything atm, but I am still > working on HL1 so I'm wondering if there has been any major changes to the > networking code for HL2. I think it's at least as spoofable as people seem > to have similar issues." > > As martino wrote about HL2 lag compensation: > > " The extra lantency caused by lower update rates is part of the general > client latency. The actual code uses timestamps send with the user commands > to set the execution time. These timestamps are checked against the average > latency and if they are within a valid range, these timestamps are used > since they are more precise then the calculation as stated in the doc. We > can't fully rely on these timestamps since "speedhackers" could alter them." > > It appears HL2 has some level of detection for this, just do not know to > what extent. Where did you get that from? Not saying you're wrong, just want to read the whole thing :) > "It would seem that if the client sends it's game time with it's packets > then it really is trivial to stop speed hacks. It becomes very simple to > calculate velocity/time and compare that to sv_maxspeed. It also becomes > trival to simply ignore any packet from the future." > > sv_maxspeed is irrelevant. Calcs for maxspeed are already part of the > velocity calculation and are correct. The key is the differences in the time > stamps between packets compared to differences in real world time of when > the packets arrived. If you compare the delta's of the message embedded > times to the delta's of the real world times of when the packets arrived it > should work (in theory). So if embedded delta's of the last two messages are > 100 yet the real world delta's of when the packets arrived is 5 you would > know something was up. > > The danger is a laggy player could appear as a speed hacker if you make the > detection too sensitive (since network lag and UDP packet loss really do > happen). So that leaves a window where some speed hacking will always be > possible. Two things, first wouldn't lagged players be sending you older packets/times not future ones? Second, I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
To have a concept of future time you have to synced clocks. The engine does have a svc_time event the server can send, this event is not adequate to compensate for network lag (and does not need to be). You would not be guaranteed the clocks were exactly in sync. That is why (and rightfully so) the calcs use deltas in time rather than absolute time comparisons. " I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist." Even low ping players could still speed hack. Some one with a ping of 40 could speed hack and move at twice the speed of everyone else and appear to the server as a player with a ping of 80. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Wednesday, June 08, 2005 1:43 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live Two things, first wouldn't lagged players be sending you older packets/times not future ones? Second, I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist. Jeff ___ 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
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/8/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > To have a concept of future time you have to synced clocks. The engine does > have a svc_time event the server can send, this event is not adequate to > compensate for network lag (and does not need to be). You would not be > guaranteed the clocks were exactly in sync. That is why (and rightfully so) > the calcs use deltas in time rather than absolute time comparisons. > > " I think it should be up to the > server admin to choose to support HPB's if it's the main reason speed > hacks exist." > > Even low ping players could still speed hack. Some one with a ping of 40 > could speed hack and move at twice the speed of everyone else and appear to > the server as a player with a ping of 80. Clearly I am missing some fundamental understanding of how the lag compensation works because I don't get how you come to this conclusion from this scenario. Can you recommend a good discussion on lag compensation? Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: Clearly I am missing some fundamental understanding of how the lag compensation works because I don't get how you come to this conclusion from this scenario. Can you recommend a good discussion on lag compensation? Lag compensation basically allows the server to move everyone back in time to the point when I fired my weapon to see if I hit anybody. That's how people can run around behind cover and still get killed by somebody that they just hid from. The "multiplayer networking" tome does a pretty good job of explaining this... http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html (scroll to the bottom, see the pretty pictures). -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/9/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeff Fearn wrote: > > > > Clearly I am missing some fundamental understanding of how the lag > > compensation works because I don't get how you come to this conclusion > > from this scenario. Can you recommend a good discussion on lag > > compensation? > > > > Lag compensation basically allows the server to move everyone back in > time to the point when I fired my weapon to see if I hit anybody. > > That's how people can run around behind cover and still get killed by > somebody that they just hid from. > > The "multiplayer networking" tome does a pretty good job of explaining > this... > > http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html > > (scroll to the bottom, see the pretty pictures). hmmm I suppose what I need is a discussion of the flaws and exploits of such a system, because I still can't get how the server can allow someone to say I did this at tick 4000 and have the server process that at server tick 2000. I can see how exploiting lag compensation could allow you to speed up by a factor or two, but the hacks I have seen have been measured in magnitudes. "Let's say a player shoots at a target at client time 10.5. The firing information is packed into a user command and sent to the server. While the packet is on its way through the network, the server continues to simulate the world, and the target might have moved to a different position. The user commands arrives at server time 10.6 and the server wouldn't detect the hit, even though the player has aimed exactly at the target. This error is corrected by the server-side lag compensation" According to this it should be time based, if I speed up my comps time I'm sending commands from the games future, how the hell do these get processed when no one else is at that time? How would setting sv_unlag 0 affect a speed hack? Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Imagine that the client lags out for 5 seconds, then an update gets through. From the tick before the update to the tick after the update, the client moves 5 seconds * maxspeed. At a max speed of 320, that's 1600 units in less than a tenth of a second. How does the server know if this is a speedhack or a lagging client? Somehow it would have to average the speed over a period of time. How far back would you have to check? How much processing time would it take to check that far back? On 6/8/05, Jeff Fearn <[EMAIL PROTECTED]> wrote: > On 6/9/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > > Jeff Fearn wrote: > > > > > > Clearly I am missing some fundamental understanding of how the lag > > > compensation works because I don't get how you come to this conclusion > > > from this scenario. Can you recommend a good discussion on lag > > > compensation? > > > > > > > Lag compensation basically allows the server to move everyone back in > > time to the point when I fired my weapon to see if I hit anybody. > > > > That's how people can run around behind cover and still get killed by > > somebody that they just hid from. > > > > The "multiplayer networking" tome does a pretty good job of explaining > > this... > > > > http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html > > > > (scroll to the bottom, see the pretty pictures). > > hmmm I suppose what I need is a discussion of the flaws and exploits > of such a system, because I still can't get how the server can allow > someone to say I did this at tick 4000 and have the server process > that at server tick 2000. > > I can see how exploiting lag compensation could allow you to speed up > by a factor or two, but the hacks I have seen have been measured in > magnitudes. > > "Let's say a player shoots at a target at client time 10.5. The firing > information is packed into a user command and sent to the server. > While the packet is on its way through the network, the server > continues to simulate the world, and the target might have moved to a > different position. The user commands arrives at server time 10.6 and > the server wouldn't detect the hit, even though the player has aimed > exactly at the target. This error is corrected by the server-side lag > compensation" > > According to this it should be time based, if I speed up my comps time > I'm sending commands from the games future, how the hell do these get > processed when no one else is at that time? > > How would setting sv_unlag 0 affect a speed hack? > > Jeff > > ___ > 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
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/9/05, LDuke <[EMAIL PROTECTED]> wrote: > Imagine that the client lags out for 5 seconds, then an update gets > through. From the tick before the update to the tick after the update, > the client moves 5 seconds * maxspeed. At a max speed of 320, that's > 1600 units in less than a tenth of a second. How does the server know > if this is a speedhack or a lagging client? You need to construct the entire scenario, else you miss the parts that make no sense ... to me ;) 1: Client joins server at tick 100 2: Client starts playing 3: Client gets lagged at tick 200 4: Server gest tick 200 at tick 205 5: Server back tracks, player moves faster as ticks 200-205 are corrected See how when you are lagged the server recieves your tick from the past, the server should never process ticks from the future. I'm pretty sure that the speed hacks make your client tick faster and thus send ticks from the future, i.e. at server tick 200 client tick 205 is being processed. > Somehow it would have to average the speed over a period of time. How > far back would you have to check? How much processing time would it > take to check that far back? The server defaults to 1 second of lag compensation, so you should only be able to speed a little by fooling lag. Also it should only work in short spurts as you have to catch up for time you missed, which you actually have to miss at some point. I'm still interested in knowing if turning off lag compensation, sv_unlag 0, breaks speed hacks. It probably breaks HPB's ;) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: I can see how exploiting lag compensation could allow you to speed up by a factor or two, but the hacks I have seen have been measured in magnitudes. I don't believe lag compensation has any visual (rendering) component to it. It's solely used on the server to determine if my bullets hit anyone at the time I said I fired my gun on my client. There's nothing in lag compensation that would effect where a player appears to be (rendered) on a client. The only thing that would effect where a player appears to be on the client would be client side prediction. Speed hacks aren't exploiting lag compensation or client side prediction. Speed hacks are telling the server that my client is moving at a faster rate than the client side movement code would normally allow (because my client's clock is running faster than the servers). If distance is calculated using velocity * time, and I increase either the velocity or the time, the distance I have moved will increase. This distance is passed as the "forwardspeed" or "sidespeed" floats in the UserCmd packet between the client and the server. I think maybe you are trying to over-analyze this a little too much. Perhaps you should download a speedhack, start up a LAN dedicated server with a mod built using the SDK and log the received UserCmd data to a text file. Also log the amount of time elapsed between each tick on the server. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/10/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Jeff Fearn wrote: > > > > I can see how exploiting lag compensation could allow you to speed up > > by a factor or two, but the hacks I have seen have been measured in > > magnitudes. > > > > I don't believe lag compensation has any visual (rendering) component to > it. It's solely used on the server to determine if my bullets hit > anyone at the time I said I fired my gun on my client. There's nothing > in lag compensation that would effect where a player appears to be > (rendered) on a client. > > The only thing that would effect where a player appears to be on the > client would be client side prediction. > > Speed hacks aren't exploiting lag compensation or client side > prediction. Speed hacks are telling the server that my client is moving > at a faster rate than the client side movement code would normally allow > (because my client's clock is running faster than the servers). If > distance is calculated using velocity * time, and I increase either the > velocity or the time, the distance I have moved will increase. This > distance is passed as the "forwardspeed" or "sidespeed" floats in the > UserCmd packet between the client and the server. > > I think maybe you are trying to over-analyze this a little too much. lol have you been talking to my boss? ;) > Perhaps you should download a speedhack, start up a LAN dedicated server > with a mod built using the SDK and log the received UserCmd data to a > text file. Also log the amount of time elapsed between each tick on the > server. I wish I had some spare time, I'd definately do this ...I will do it, might have to wait a few weeks to get the time though :( Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
