Re: [hlcoders] Anti-Cheat idea - My 5 cents
about: http://www.unitedadmins.com/cdeath-why.php short response: Yes, looks like its what C-D do. (and other similar software) Mark Wales wrote: Am I being stupid, or isn't that exactly what Cheating Death does tei wrote: [...] A "black box" thats do "things" and that "autoupdate" or something similar. If another company focuses itself to this problem, the "black box" stuff will work very well. [...] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Anti-Cheat idea - My 5 cents
Am I being stupid, or isn't that exactly what Cheating Death does tei wrote: Adam "amckern" Mckern wrote: [...] back 2 point - Valve are doing there best to stop cheats, hacks, and that sorta thing - but if you make it to hard for a hacker to break the code in I.C.E., then you will also make it to hard for server admins to look after there servers, and among other things, have a very small sdk, becuase a MODers sdk is the game code, missing the render, and some other IP code Good idea, though it might to be around in HL2, and source, it might be impmented by Valve, in HL3, or by other developers in new middle ware, and game engin's amckern The solution can be something standalone, separate from valve work, something like "Punkbuster" maybe. A "black box" thats do "things" and that "autoupdate" or something similar. If another company focuses itself to this problem, the "black box" stuff will work very well. FPS history: 0) Pong (modded osciloscop machine) 1) Wizard of Wor (commodore 64), monolitic game 2) Wolfstein3D (pc 486), separate maps, monolitic render/gameplay, 3) Quake (pc 586), separate maps and resources and gameplay, render engine 3a) Quakeworld (pc 586), all above + GameSpy game browser 3b) Half-Life 1 (pc 586 + GPU) all above, also integrated game browser 4) Battlefield 1942, (pc 686 + GPU), all above + punkbuster 5) Half-Life 2 (pc 686 + GPU + Pixel Shaders?), ? + steam + ?? ? ___ 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] Anti-Cheat idea - My 5 cents
Adam "amckern" Mckern wrote: [...] back 2 point - Valve are doing there best to stop cheats, hacks, and that sorta thing - but if you make it to hard for a hacker to break the code in I.C.E., then you will also make it to hard for server admins to look after there servers, and among other things, have a very small sdk, becuase a MODers sdk is the game code, missing the render, and some other IP code Good idea, though it might to be around in HL2, and source, it might be impmented by Valve, in HL3, or by other developers in new middle ware, and game engin's amckern The solution can be something standalone, separate from valve work, something like "Punkbuster" maybe. A "black box" thats do "things" and that "autoupdate" or something similar. If another company focuses itself to this problem, the "black box" stuff will work very well. FPS history: 0) Pong (modded osciloscop machine) 1) Wizard of Wor (commodore 64), monolitic game 2) Wolfstein3D (pc 486), separate maps, monolitic render/gameplay, 3) Quake (pc 586), separate maps and resources and gameplay, render engine 3a) Quakeworld (pc 586), all above + GameSpy game browser 3b) Half-Life 1 (pc 586 + GPU) all above, also integrated game browser 4) Battlefield 1942, (pc 686 + GPU), all above + punkbuster 5) Half-Life 2 (pc 686 + GPU + Pixel Shaders?), ? + steam + ?? ? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Anti-Cheat idea - My 5 cents
Developers dont support games fater they ship, in many cases, but valve has broken the mold, and made HL a good game Steam, and VAC - even though they are still bugy (come on 30 millionish players), you will end up with bugs, even if you did test the system for 2 years, with steam beta 1, etc back 2 point - Valve are doing there best to stop cheats, hacks, and that sorta thing - but if you make it to hard for a hacker to break the code in I.C.E., then you will also make it to hard for server admins to look after there servers, and among other things, have a very small sdk, becuase a MODers sdk is the game code, missing the render, and some other IP code Good idea, though it might to be around in HL2, and source, it might be impmented by Valve, in HL3, or by other developers in new middle ware, and game engin's amckern --- Matt <[EMAIL PROTECTED]> wrote: > cheats are gonna exist until pcs are nothing more > than monitors connected to > the internet and even then someone will find a way > to cheat, the best way to > stop cheats is to have a good way to report them< > not as far as blizzard > went =/ > but a constantly monitored system, mabey > even by non valve > representatives, who can deal with complaints, using > some genious system > whereby if any anti-cheat guy/gal is online they can > join the game and see > for themselves.. ill let you pay me for it =) on the > other hand.. if the > hardware manufacturers gave it an ounce of thought > they would build special > hardware modes where only individual programs could > access the screen, and > have a hardware device connected between the modem > and the monitor cable to > turn it on and off. failing that.. the death > penalty!! hahahahahahaha! > > > ___ > To unsubscribe, edit your list preferences, or view > the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > = hl2hosting.com AIM SN - amaperman __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Anti-Cheat idea.
cheats are gonna exist until pcs are nothing more than monitors connected to the internet and even then someone will find a way to cheat, the best way to stop cheats is to have a good way to report them< not as far as blizzard went =/ > but a constantly monitored system, mabey even by non valve representatives, who can deal with complaints, using some genious system whereby if any anti-cheat guy/gal is online they can join the game and see for themselves.. ill let you pay me for it =) on the other hand.. if the hardware manufacturers gave it an ounce of thought they would build special hardware modes where only individual programs could access the screen, and have a hardware device connected between the modem and the monitor cable to turn it on and off. failing that.. the death penalty!! hahahahahahaha! ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Anti-Cheat idea.
Ok, Dominic. Thanks for the insight. Yea, I know fixing forever the cheat problem is a utopia. Or at least looks like is something hard to achieve. I guess future technology (?) will able smaller PVS so wallhacks will render much less usefull. Also cheat players play diferently than normal players, other approach, analysys statistic is posible (??) ;) Dominic wrote: As far as opengl hacks are concerned, the hacked game is executing exactly the "correct" calls, plus some the game itself doesn't know about. So even with the scenario from your "perfect idea", the game would still execute the correct calls, and the hack would add some of it's own, like disabling depth-testing, coloring models, drawing esp and so on. What you would have to check is the exact call-path of every opengl function, and compare that to what a clean machine calls. This is unfeasible for various reasons: - It would impose heavy overload on the client - models for example consist of a lot of vertices, each results in a opengl call - A hack doesn't necessarily call the opengl functions exported by opengl32.dll, it may as well call the driver directly, so you'd have to add trace support for every driver - Almost all drivers use different implementations of the function calls for different situations, like first vertex, 2nd and following vertices, current shade model, and so on, so even if you traced every possible driver (nvoglnt.dll, ati equivalent, wickedgl, ...), you'd also have to consider every possible optimization. Nvidia's nvoglnt.dll calls gl fuctions itself, for example if you issue a glColor after an glBegin (or some other basic functions, I don't remeber the two I stumbled across some weeks ago), probably to adjust to the new state of the opengl machine What I want to point out: it may be (theoretically) a good idea, but it's never going to work. Kind regards, Dominic On Mon, 24 May 2004, tei wrote: Here is pic http://telejano.berlios.de/option/anticheat1.png the perfect idea is to generate all opengl calls, but store and not draw. then send the whole data has a array to the client. the dumby client will render the whole stuff. the perfect idea is imposible, has you need infinite bandwidth and zero ping the un-perfect idea is to generate the data ALSO at clientside, and send a hash of the data from client to server, then the server will send a auth code if the hash of the render data on server side mach the un-perfect idea is ugly because client is fat, server is fat. the server will need much more horsepower to GENERATE the opengl calls for all players, but not so fat... will not need a video card, has not need to draw anithing, only to pretend so. its also ugly because to hash mach, is need to use the same exact eyecandy setup on server and client. If the client active "rain", the server will need to active rain, ..so server is need to be aware of eyecandy options on client. What people think about this idea? --Tei ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Anti-Cheat idea.
As far as opengl hacks are concerned, the hacked game is executing exactly the "correct" calls, plus some the game itself doesn't know about. So even with the scenario from your "perfect idea", the game would still execute the correct calls, and the hack would add some of it's own, like disabling depth-testing, coloring models, drawing esp and so on. What you would have to check is the exact call-path of every opengl function, and compare that to what a clean machine calls. This is unfeasible for various reasons: - It would impose heavy overload on the client - models for example consist of a lot of vertices, each results in a opengl call - A hack doesn't necessarily call the opengl functions exported by opengl32.dll, it may as well call the driver directly, so you'd have to add trace support for every driver - Almost all drivers use different implementations of the function calls for different situations, like first vertex, 2nd and following vertices, current shade model, and so on, so even if you traced every possible driver (nvoglnt.dll, ati equivalent, wickedgl, ...), you'd also have to consider every possible optimization. Nvidia's nvoglnt.dll calls gl fuctions itself, for example if you issue a glColor after an glBegin (or some other basic functions, I don't remeber the two I stumbled across some weeks ago), probably to adjust to the new state of the opengl machine What I want to point out: it may be (theoretically) a good idea, but it's never going to work. Kind regards, Dominic On Mon, 24 May 2004, tei wrote: > > Here is pic > http://telejano.berlios.de/option/anticheat1.png > > the perfect idea is to generate all opengl calls, but store and not draw. > then send the whole data has a array to the client. the dumby client > will render the whole stuff. > > the perfect idea is imposible, has you need infinite bandwidth and zero ping > > the un-perfect idea is to generate the data ALSO at clientside, and send > a hash of the data from client to server, then the server will send a > auth code if the hash of the render data on server side mach > > the un-perfect idea is ugly because client is fat, server is fat. the > server will need much more horsepower to GENERATE the opengl calls for > all players, but not so fat... will not need a video card, has not need > to draw anithing, only to pretend so. > > its also ugly because to hash mach, is need to use the same exact > eyecandy setup on server and client. If the client active "rain", the > server will need to active rain, ..so server is need to be aware of > eyecandy options on client. > > What people think about this idea? > > --Tei > > ___ > 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
