White Hat Weapons

Ive heard that the entire area map seed is sent to the client upon zone creation. If this is indeed the case, it needs to change to a localized continuous stream or maphack will be just as ubiquitous as it was in D2.

"

ScrotieMcB wrote:

Although I understand it's your post, and you have the freedom to define terminology within your post (especially if you define it at the outset), it's very confusing to label black-hat and especially white-hat that way. Both terms define hackers who actively try to find exploits in computer systems; the principle difference is in what the choose to do about it afterwards (the white-hats doing the good-guy thing and reporting the security weakness to the proper authorities). Your idea of white-hats — hackers poised in the active defense of a system, monitoring it against attacks and counter-attacking as soon as a threat is detected — is a far cry from the reality of 90% of what white-hats do, and also pretty much illegal (they would be hacking someone's computer without legal authorization).

I'll admit to stretching the definitions a bit, but security consultants in the IT industry often play a role not only in the (I hate wikipedia btw) wikipedia defined White Hat role, but also in the design, implementation, and operation of systems used to detect and thwart attacks.

As to the legality - where do you get the idea that there would be any penetration of anyone's computer without legal authorization? Nothing I proposed would involve anything but server side data.

"

KoTao wrote:

Ive heard that the entire area map seed is sent to the client upon zone creation. If this is indeed the case, it needs to change to a localized continuous stream or maphack will be just as ubiquitous as it was in D2.

I'm of the opinion that any client side 'security' beyond the 'skeleton key front door lock to keep honest people honest' is a waste of time, a bottomless money sink. Big companies have tried their best and failed, a small company doesn't have the resources to even attempt it. It isn't even possible theoretically as long as the client portion of the game is running on an unsecured machine.

The best defense against client side hacks is to track their effects server side. You do this by logging everything and data mining, looking for statistical aberrations. You can then ghost suspect accounts in real time, watching everything that occurs on a specially modified client that is tapping the server side data stream. What you would be looking for is behaviors that indicate a map hack (in the case you raise) is in use, at some point it adds up into a certainty.

The question then becomes, what is the appropriate, most effective, response?

"

flab wrote:

What KoTao proposed would probably go a fairly long way towards fighting map hacks, if the client never has access to more than its immediate surroundings. There may be other heuristics or pattern matches from generation rulesets for map hacking beyond that though, you could probably counter that reasonably, but I can't claim to be an expert.

If it is simple enough to implement, and not knowing the details of the current implementation I can't answer that, it might be inexpensive enough to fall into the 'skeleton key front door lock' category. But if it requires more than a few hours of programming to implement, then it is probably a waste of time.

There is another concern too, bandwidth. Going to the extreme you could, theoretically at least, stream all content, and it would go far in limiting the effects of a number of possible client side hacks, but the cost would be prohibitive - at least currently.

A design group I was in some years ago examined the idea of streaming content in encrypted form in the background and sending the keys just in time for use. It can work, but it complicates things, requires significantly more bandwidth, and in the end, is still susceptible to attack. Admittedly the attacks need to be a lot more sophisticated.

A game company, especially a small one, is always in the David position in a David vs Goliath matchup where hacks and exploits are concerned (and unlike David, they don't have a sling!). They have to be very careful that they don't spend too much money in the wrong places.

I do believe KoTao should raise his concerns directly with GGG, as there are already indications elsewhere that at least one person has created such a hack.

"

flab wrote:

Yeah I really don't think there would be much use in encrypting the data. Just depends on how much range you have access to, who cares if it's unencrypted if you can guarantee the client isn't allowed to query arbitrarily.

What we were doing was dividing the content up into sections, then streaming the sections ahead of time to the client in encrypted form, and when the client would legitimately need access to a section of the content, the server would give them the key to it. Client side decryption was fast enough that it was as if the new content had been sent instead of the key - just required much less bandwidth in the main client-server channel. The streaming of the encrypted content occurred in a separate channel as soon as there was any possibility the client might need it. For one thing it speeds up zoning, as you only need a relatively small piece of the zone when you first zone in, adjacent pieces would be streamed so that anything you needed would be there before you need it.

You can get quite a bit more sophisticated but unfortunately its still not hacker proof and requires a significant increase in bandwidth over just sending the entire contents pack as part of game install or patch. Now it would be interesting to combine the idea with algorithmic world generation, define a set of possible section geometries for pathing and use algorithmic generation from seed for each section. Then just send the seeds to create, rather than keys to decrypt, each section as needed by the client. If this is what KaTao was thinking of then, yes, it could work to at least partially offset map hacks.

"

f3rret wrote:

we've had one really long (well, two I guess) posts from one self-entitled and vocal moron

I haven't been following the news. Could you link the post you're referring to? I'm eager to read about the recent developments.

Edit: nevermind, found it. Nothing to see there, move along. Conflict of interest, false pretense of intentions, smoking gun, painted all over that one.

After thinking a bit further on the map hack, I think it makes for a reasonable overall example of the difference between addressing exploits at the client level and addressing them at the server level.

To address the map hack exploit at the client level will require code changes. Code changes for the client and for the server. It also requires testing. It may require changes in artwork and even in the graphics engine depending upon actual implementation details to avoid visual artifacts. At the lowest possible end we're looking at at least an investment of one man day, up to possibly a man week or more. To address one client side hack.

Before getting into addressing it at the server end, let us ask, what are the effects of the map hack? What benefit does a cheater get by using one?

My, possibly naive, answer is: on randomized maps our cheater can get from entrance to exit by the most direct route every time, saving significant time in races.

So how do we address it at the server end instead? Statistics. Assume we've logged everything at the server. We know how long it takes each player to transit a given map configuration on average, as well as the minimum times. A cheater using a map hack will stick out like a sore thumb as a statistical aberration, consistently beating the odds and almost always having near minimum transit times. Automating detection of that, assuming we already have the logging and analysis software in place, takes less than an hour of scripting and testing.

Preventing false positives takes another step, once the potential offender has been flagged by the detection software, a real live person needs to take a look at the data and possibly ghost ride along with the possible offender to confirm the use of a hack.

Now if the investment required to put in a fix at the client level is small enough and the risk assessment is favorable - ie the fix won't be susceptible to being hacked quickly; then the cost-benefit analysis favors the fix. Otherwise, add the hack's signature to the detection software server side and deal with offenders as they are detected.

Now in some cases, there may be a third option, some genius at the gaming company may come up with a subtle change in the game mechanics that makes the hack pointless.

Which method to use? That decision is above my paygrade :) But if asked for advice, I'd almost always favor server side over client side fixes.

"

Omnivore61 wrote:

Attack of the lag monster - artificially induced lag, all server communications with the offending account are given a randomized delay of 250 milliseconds over normal processing time.

OH NOOOO!!!! I always have 250ms..... Has this already happened to me!?

Im aussie btw. Sucks to be me :(