Technical Aspects

[insane snyper]

To start off, please please please keep this thread on topic.

Now maybe I'm wrong, but my understanding is that the information gathering side of AC software usually has 3 parts:

1. Files Checking

GRAW has this. In any game that is going to be modded it needs to check the files against the server's files, not against some standard set. To my knowledge this aspect of GRAW's AC works perfectly, or at least no hacker has devoted the resources to overcoming it yet. Can someone confirm this?

2. ?Other Checks?

file/memory allocations are being checked to ensure that a 3rd party app isn't accessing the executable or other game file it shouldn't be accessing.

3. Screenshots/Replays/etc

Some people seem really keen on replays for some reason, but one way or another those would seem to be a thing of the past. The main alternative I know of is screenshots, which seem to work pretty well in AA. Anyone know of alternatives out there?

My main objective here is to get people thinking about what will be involved (on the technical side, I dont want any 'political' crap in this thread) in some sort of AC system, whether it be something we put together, something from GRIN, or (I doubt it) some other system GRIN/Ubi buys into.

Edited July 17, 2006 by insane snyper

[ToW-Angel]

There is one other part of it, at least I believe there is... Community Involvement.

In the last game my squad and I played, the game folder itself got checked for files that shouldn't be there also.

I'd like to see an active anti-cheat system instead of reactive. What that w ould me is that the file/memory allocations are being checked to ensure that a 3rd party app isn't accessing the executable or other game file it shouldn't be accessing.

MD5 checks the integrity of the file and then gives it a unique signature. If that signature gets altered in some way, then the anti-cheat systems boots the player, bans them and then they cannot join the server.

[Bota:16]

What you said but also as in PB games every CD key is associated with a PB GUID. This lets PB keep track of players, specifically the one who get caught hacking. So there needs to be some sort of database (i.e PB=MBL or RA=SBL/CBL) that can easily be updated and implemented. But there would have to be some sort of servers for this as in PB so GRIN/UBI would have to be on board 100% for this to happen properly.

Edited July 17, 2006 by Athenian

[ToW-Angel]

Agree 100%, there needs to be a way to track the players.

[insane snyper]

There is one other part of it, at least I believe there is... Community Involvement.

Thats not technical, dont go taking my thread off topic

I'd like to see an active anti-cheat system instead of reactive. What that w ould me is that the file/memory allocations are being checked to ensure that a 3rd party app isn't accessing the executable or other game file it shouldn't be accessing.

Yeah, that was what I meant part 2 to be about. But now I remember what that MD5 stuff was about, so yeah I definetly had that wrong.

[FI_FlimFlam]

I would like to see the following in GRIN's AC:

1)Ability to scan config / XML files for specific or range of values. This would prevent the XML hacks and or people from using values that like speed or other key values out of a specific range. This should be admin configurable to support mods for the server.

2)File scans - for the presence of known cheat files. I would prefer to not be limited to to the game directory as that many cheat writers and cheater know NOT to put their cheat files in the game directory. Admin configurable. MD5 hashes seem to be the best way to verify files.

3)Screen shots and server side replays. SS's are a definite must for actually seeing what the client is viewing - especially right now GRIN says replays are not an option. I know GRIN has said that replays are not possible their reason was bandwidth. But maybe they can find a way to record/log all the client movement and shot information and then have a way of using the game engine to replay a match or round based on the network information from the client. That way it's all server side and replays are based on a much smaller log file than a video compression file. A combination of both would be ideal.

4)Memory signature scanning for known cheat programs. This unfortunately would require administrative rights on any computer running it - one of the critisms that PB has come under fire for. I still think it is worth it however for clean games. If you are going to blame anyone for this necessity, blame the cheaters not the people having to fight them.

5)Ban by CD key or unique id based on CD key. For goodness sake do not ban only by IP it is far too easy to cycle IPs and jump back in a server. Then admins have to resort to banning whole subnets to keep determined griefers out potentially banning 1000's of innocent people from our servers.

6)Ability to load multiple banlists. This would be ideal for managing a local and community ban list. If not loading multiple then have the banlist loaded from a txt file or xml file that can be modified allowing the community to share bans.

As mentioned before in points 1 and 2 make addittional detections and configs admin configurable. This will give the community the ability to keep the AC viable to an extent between updates/patches. Especially once the cheaters circumvent the latest patch, we can write detections to find the latest cheats keeping most of the not so sharp cheaters out that would have free reign without said detections.

Edited July 17, 2006 by FI_FlimFlam

[ToW-Angel]

2)File scans - for the presence of known cheat files. I would prefer to not be limited to to the game directory as that many cheat writers and cheater know NOT to put their cheat files in the game directory. Admin configurable. MD5 hashes seem to be the best way to verify files.

I've seen this debate many times on many different forums. It's because a privacy issue of why is an Anti-Cheat for a game scanning my entire computer? Also, think about the load time of someone into the server while it's scanning the hard drive?

While I agree that it should be able to detect a cheat anywhere, we don't want to wait for an hour or more in some cases to join a server.

The best way to combat this is to have an active anti-cheat which scans memory allocations, something you and I have already mentioned.

Everything else is right on track.

Edited July 17, 2006 by ToW-Angel

[FI_FlimFlam]

2)File scans - for the presence of known cheat files. I would prefer to not be limited to to the game directory as that many cheat writers and cheater know NOT to put their cheat files in the game directory. Admin configurable. MD5 hashes seem to be the best way to verify files.

I've seen this debate many times on many different forums. It's because a privacy issue of why is an Anti-Cheat for a game scanning my entire computer? Also, think about the load time of someone into the server while it's scanning the hard drive?

While I agree that it should be able to detect a cheat anywhere, we don't want to wait for an hour or more in some cases to join a server.

The best way to combat this is to have an active anti-cheat which scans memory allocations, something you and I have already mentioned.

Everything else is right on track.

depends on how the scan is implemented. In RvS it's done while the player is playing. The CVARs and file checks run at intervals. That way they player cant just load a config once they are in the server. If it's done like BF2 then alot of the stock file checks are done prior to joining and the client is put on hold until the stock scans are comiplete.

I don't have a problem with the privacy issue if contents of files aren't collected. Just if a file is detected. Make it something the player has to agree with to join a server running the AC and if they don't like it, they can play on non-enabled AC servers. Simple as that. Again it's a necessary step to try to be effective against cheaters who ruin MP games for everyone. Again blame the cheaters for the necessity, not the AC.

Edited July 17, 2006 by FI_FlimFlam

[VeLocityChaos]

3. Screenshots/Replays/etc

Some people seem really keen on replays for some reason, but one way or another those would seem to be a thing of the past. The main alternative I know of is screenshots, which seem to work pretty well in AA. Anyone know of alternatives out there?

My main objective here is to get people thinking about what will be involved (on the technical side, I dont want any 'political' crap in this thread) in some sort of AC system, whether it be something we put together, something from GRIN, or (I doubt it) some other system GRIN/Ubi buys into.

As far as replays/screenshots go, we kind of have a basis to start on. The game already has a spectator mode. The camera is just off center and as of now only works in the SP portion of the game. What would need to be done is just recentering the camera, and scripting it to be used somehow in MP. I dont know if this can be done. It seems possible at least in my mind. I think we will need access to the .DXE files before we could do most of this stuff.

Alternatively, The game also has a built in SS feature. If it would be possible for servers to randomly and automatically send a command to all clients to capture and upload the screenshot while in game. Not all clients at once, just a random capture and upload for each player throughout the game duration.

The game core itself does have possible options on something a community could use to build a program or script in the game itself that could help if access to the .DXE files becomes possible.

My .02 cents.

Edited July 17, 2006 by VeLocityChaos

[ToW-Angel]

Nemon is working on a DXE decompiler. Not sure how far he is in the process of completing it. Maybe we can get him over here to answer a few questions?

[Bota:16]

Alternatively, The game also has a built in SS feature. If it would be possible for servers to randomly and automatically send a command to all clients to capture and upload the screenshot while in game. Not all clients at once, just a random capture and upload for each player throughout the game duration.

My .02 cents.

Yeah but in a .tga format, which are big files. The picture the game uses for the minimap on most maps are about 1MB in size but the picture itself is only 512X512. Would need to find someway of coverting them to .jpeg or .png (PB) before they are sent to the server.

[ToW-Angel]

PNG's are large files also... It's easy to get one over 1mb too.

What could be done through PHP is an automatic way of reducing the graphic size.

In PB, there are settings that you can set for various resolutions. Standard is 320x240.

If we can keep the resolution under 640x480, but no less than 320x240, I think PNG's will work.

If we cannot keep them under that, then I suggest that we go with JPG's, as that will give you the best for the least amount of bandwidth and storage.

[-|-aMMo-|-]

I would like to see the following in GRIN's AC:

1)Ability to scan config / XML files for specific or range of values. This would prevent the XML hacks and or people from using values that like speed or other key values out of a specific range. This should be admin configurable to support mods for the server.

Well I think this should be like how most games do file configs in multi. They are server side settings, and whatvever the client puts in for the values has no effect.

But they should scan the md5 of other files, like textures.

2)File scans - for the presence of known cheat files. I would prefer to not be limited to to the game directory as that many cheat writers and cheater know NOT to put their cheat files in the game directory. Admin configurable. MD5 hashes seem to be the best way to verify files.

I dont know if whole HD checks would be a good thing, first off people may download the cheats to send them to GRiN or other AC, to use to make their own anti-cheat, to learn how the cheats work to detect them being used in game, to play single player, or multi with friends without AC. Just too many legitamite circumstances as to where someone would have cheats on their HD.

It should detect just in game directory, so they can be easliy removed if they are going to play on a AC server. But mainly it should scan running processes for known hacks.

3)Screen shots and server side replays. SS's are a definite must for actually seeing what the client is viewing - especially right now GRIN says replays are not an option. I know GRIN has said that replays are not possible their reason was bandwidth. But maybe they can find a way to record/log all the client movement and shot information and then have a way of using the game engine to replay a match or round based on the network information from the client. That way it's all server side and replays are based on a much smaller log file than a video compression file. A combination of both would be ideal.

Agreed.

4)Memory signature scanning for known cheat programs. This unfortunately would require administrative rights on any computer running it - one of the critisms that PB has come under fire for. I still think it is worth it however for clean games. If you are going to blame anyone for this necessity, blame the cheaters not the people having to fight them.

Its sounds more like your talking about md5 checks.

Anyways scanning the games memory ranges values for changes is important, also the free space needs to be watched. What the hackers do is, because of the DMA memory, means dynamic memory allocation, they have to find a pointer which points to the address of the value they want to change, and to go threw this process they need to write a code cave. A code cave is basiclly, starting at an address, then jumping to a free space in the memory/dll and writing your own code into the as what you want done, then jumping back in order of the operations so everything continues as it should.

So if its a pointer address, you jump to your free space, and put in the original game code, do the code to find out what address its pointing to, and put that address information into another free space, after your done jump back to the next operation at the original address in memory. They then use the address they found, which should be the address to the value they want to change, such as in GR1 , Names Off and On was either a value of 0 or 1, (except GR1 Names address is static so you dont need to go threw this code cave.)

Of course this is only one example of how it works, theres other ways and things they do. It may not be as simple as finding one pointer, you may have to do different level pointers. Or it could be more simple and you could find a base pointer and not need to write a code cave.

They can also use a dll injector instead of writing in the exe's free space.

I dont think theres really any critism on PB for this, other then by cheaters. The md5 checks are the issue with that really.

5)Ban by CD key or unique id based on CD key. For goodness sake do not ban only by IP it is far too easy to cycle IPs and jump back in a server. Then admins have to resort to banning whole subnets to keep determined griefers out potentially banning 1000's of innocent people from our servers.

Agreed.

6)Ability to load multiple banlists. This would be ideal for managing a local and community ban list. If not loading multiple then have the banlist loaded from a txt file or xml file that can be modified allowing the community to share bans.

As mentioned before in points 1 and 2 make addittional detections and configs admin configurable. This will give the community the ability to keep the AC viable to an extent between updates/patches. Especially once the cheaters circumvent the latest patch, we can write detections to find the latest cheats keeping most of the not so sharp cheaters out that would have free reign without said detections.

Agreed.

Also the checks shouldnt just be a one time when you join the server check.

They need to be actively scanning them, through out the game, otherwise its pointless since they can turn them on after its done checking.

Edited July 17, 2006 by -|-aMMo-|-

[FI_FlimFlam]

PNG's are large files also... It's easy to get one over 1mb too.

What could be done through PHP is an automatic way of reducing the graphic size.

In PB, there are settings that you can set for various resolutions. Standard is 320x240.

If we can keep the resolution under 640x480, but no less than 320x240, I think PNG's will work.

If we cannot keep them under that, then I suggest that we go with JPG's, as that will give you the best for the least amount of bandwidth and storage.

One of the ways PB also reduces the file size of the image while capturing more screen area is to use a sample rate of 2 which captures every other pixel IIRC. This would allow you to get a image that is actually 320x240 but show the contents of 640x480 area of the clients screen - albiet with less detail. But this is usually sufficient to catch most cheats like ESP, chams/skins/wallhack/ and other. It does make catching Retlock on games that have rets more difficult as that often times the ret lines are only 1 pixel wide. Also positioning of the screen shot caputre area is movable so for example you might be able to capture the top left quadrant or the bottom right or center top or center bottom. Not just the center of the screen.

If GRIN decides to incorporate a SS utility, they will need to find a way to take it and compress it without much load on the clients system. I think they will need to optimize the game a bit more to reduce the CPU hit on most systems and on servers. Right now hosting peggs the cpu at 100% (dual cores one core will be maxed out).

[Pulaski]

I hate to sound like a broken record, but most everything posted here Punkbuster has working. Why not pull together and push for PB to be supported?

[ToW-Angel]

Because, UBI probably doesn't want to spend the money to have it incorporated into the game.

I can guarantee you that no matter how hard we push for PB, we will not get it.

You can e-mail UBI and ask them for it, and even if we were to all band together, we cannot force UBI to pay for PB.

UBI will tell us that GRIN is developing an anti-cheat for the game, why should they spend more money to pay for PB.

Basically, it's a useless cause to continually beg for something we quite clearly are not going to get.

It's a dead debate, period. I can guarantee it. So, why continually ask for something you know you aren't going to get? Fruitless effort I might add.

We are going to have to live with the A/C system GRIN is developing.

And, to add a bonus of why they won't... "They aren't selling enough to justify paying for PB."

BTW...

Edited July 18, 2006 by ToW-Angel

[Pulaski]

I don't agree with you, not all games support PB out-of-the-box, but added later after the community's pushed. COD1 and COD2 both had PB added after the release...BF and RS also(I'm sure a few more).

AW needs a major push to get started, players and teams have moved on, they'll need more then a half-way working AC to come back. TDM will do little for AW if there's no working AC and the money spent on making one would be better spent on adding PB.

I'm not off-topic...the thread reads "What is actually needed" and in my opinion it needs PB.

Edited July 18, 2006 by Pulaski

[ToW-Angel]

That's just it... There is a working A/C, at least in the eyes of UBI Soft.

[}PW{ Postal]

I skimmed thru this post and from what i see you guys have covered pretty much everything, but what im wondering is because GRAW is so CPU intensive and utilizes 100% of single cores and 50% of dual core processors...will any of this be possible without dragging the gameplay down to next to a dead stop?

[FI_FlimFlam]

Very good question and hopefully GRIN is reading these posts and about the servers pegging the cpu's to 100%. Optimization is really needed for this game particularly with the SADS files when they hit. If the game continues to hit 100% of the cpu, then it is going to be difficulty for providers to host more than one game on a box. Or for Teams/Clans to host any other games in addition to GRAW on their dedicated boxes.

In regards to the AC it would depend on their implementation and features. If its going to do a lot of scans and writes to the disk with either client side replays or screen shots, it's a definite possibilty to have performance negatively affected. If they can reduce the cpu load, it is logical it would reduce the impact - hopefully to negligible levels.

[ROCO*AFZ*]

Very good question and hopefully GRIN is reading these posts and about the servers pegging the cpu's to 100%. Optimization is really needed for this game particularly with the SADS files when they hit. If the game continues to hit 100% of the cpu, then it is going to be difficulty for providers to host more than one game on a box. Or for Teams/Clans to host any other games in addition to GRAW on their dedicated boxes.

In regards to the AC it would depend on their implementation and features. If its going to do a lot of scans and writes to the disk with either client side replays or screen shots, it's a definite possibilty to have performance negatively affected. If they can reduce the cpu load, it is logical it would reduce the impact - hopefully to negligible levels.

I think optimization will only happen in the form of dedicated server files when released (not this patch)

If you think about it... why optimize what will be going by the wayside soon. The dedicated server won't have to render the background, video, or anything if done properly.

[FI_FlimFlam]

I was more so leaning to the CPU hit on the client side of things. Optimize the server and then also the client (even though I didn't specifically say) that reduces the impact of client side file scans and also SS's.

[RAbbi_74]

OK, so here's a question...

While I know we can't (or at least REALLY shouldn't) discuss exactly HOW the A/C works here, I was wondering if the GRIN dudes had considered the following as a way of verifying file integrity...

When Windows creates, installs, or modifies a file, it saves the DATE. When it installs a whole program (or perhaps updates one via patch) doesn't it also update the registry with that date? So also, whenever one opens any file and modifies it (perhaps to fiddle with xml or something in order to apply a hack/cheat) wouldn't the associated date ALSO be updated automatically by windows and attached to that file?

Point being, a server-side A/C could (assuming I'm not 100% off with the above) simply compare the date values of each specified bundle and xml file with the system registry date of the game's installation or latest patch/update. If a bundle containing opacity values for wall textures had been modified since the last install/patch, it would be simple to detect, and therefore trigger the A/C flag to go up on the user whose system contained the discrepant dates. THEN a more thorough scan of hashes/whatever could take place on the discrepant system.

Sure, I can manipulate the system date and time and time the press of the 'Save' button or whatever to make it all coincide. But I can't very well manage it if the files are READ-ONLY, and only accessible through InstallShield/DemoShield (which has to run to install the game or a patch to it). Password/encrypt the folders containing all the bundles and such via a randomly selected value from the CD key?

I'm kinda tossing stuff out there as it occurs to me. These things have been on the front burner in my mind for a few days now, as the A/C is getting fingered as the culprit for a lack of match playability by many, and therefore a major factor in reducing the popularity of the game overall in the PC MP world...