Wikia

Scratchpad

Antihack

217,768pages on
this wiki
Discuss this page0

client software to query bnet to authenticate cdkey before logging onto pgt

From: borg To: x6.rocketeer Posted: Thu Aug 24, 2006 9:52 pm Subject: re: ipban hi there,

im trying to follow the different paths that the current thread is taking so forgive me if i drift a little in my note here.

we were on the subject of preventing our nodes from getting ipbanned by bnet from querying too much or with fake keys. we might delegate the ipchecking to each client that tries to log into a server like pgt. if they enter fake cdkeys or try too many times, their own ip gets banned from bnet and upon seeing this, pgt will not allow access either.

here's an example to explain what im trying to say.

1. SC user attempts to log into PGT using some client software (CS). 2. CS will send query to bnet to verify key validity and at then report the results to PGT. 3. if #2 is successful, then allow access, else deny. if user is IP banned from bnet, we might opt to do the same for their access to PGT.

does that make sense?


delegating cdkey

From: borg To: x6.rocketeer Posted: Thu Aug 24, 2006 10:54 pm Subject: Re: re: ipban x6.rocketeer wrote: yes, but this is so easy to circumvent that there is no point in implementing it. CS will simply be hacked to always report success.

keep in mind: if the hack author is determined enought to write a hack which works on pgt, then he will simply hack CS in addition to his hack. if the hack author doesnt care about pgt, then the hack (most probably) won't work with CS anyway, even without the cdkey check, since CS will have some basic hack detection.

you have to delegate the cdkey check, the question is how?


you have a valid point. in addition to reporting success, we may also include information to authenticate the CS (maybe checksum) to make sure it hasnt been altered. that's how virus scanners work too right? in fact we might capture and save the data stream that was sent to bnet, pack it and send it along with our authentication information when the client contacts PGT.

another way to solve this might be to delay checking their authentication to bnet. this will be viable with the centralized querying server method since all requests to query bnet will be queued up and processed at X time intervals to avoid being ipbanned. once verified the logged in client is allowed to stay in pgt, otherwise their connection can be terminated. this can be enhanced to include ip banning of our own if they try to flood the server with bogus requests.


cumbersome login and queue delay login

From: borg To: x6.rocketeer Posted: Fri Aug 25, 2006 12:33 am Subject: Re: re: ipban -- put these two items on shelf --

ok lets start with the assumption that all clients are untrusted. we must somehow bridge the gap btwn authenticating a cdkey with bnet and preventing the pgt server from getting banned from DOS.

Ideally, if someone is trying a DOS attack, they are the ones getting banned by bnet but our issue here is that there's no method to authenticate the client to trust their responses that they obtained from bnet.


-- coherent thoughts begin here --

What if we made the login method more cumbersome to defeat auto-logins? if each login to PGT checked out a timed lease along with a picture (selected at random) of some characters to act as a countersign, then the hacker would have to hire a legion of drones to manually log in (to type in the characters shown in picture).

another option would be to give preferential treatment to old users than new users. old, verified users with a history of successful connections get higher priority in the queue, thus get processed earlier than the newer users. new user logon might be intentionally delayed X seconds on top of the queue waiting time depending on how big the current queue is. this approach uses time as our weapon. it would resemble encryption schemes which are considered safe because it would take too long for hackers to decrypt. if a DOS is in progress, the queue will fill up to the point where new users will no longer be accepted but this leaves our regular users safe, as they are still able to log in thanks to their higher priority in the queue.


trust lists

From: borg To: x6.rocketeer Posted: Fri Aug 25, 2006 1:14 am Subject: Re: anti cheating system the system i envision revolves around getting the entire community active in going after hackers.

i dont have all the pieces of the puzzle yet so i'm hesitant to share it with many people because they might dismiss it too easily because it might seem too ambitious or unfeasible.

consider this:

first, assume a way to detect hackers and uniquely identifying them is available.

On bnet, many players have regular groups of friends they play with. Let's assume that each member of this group keeps a list of known hackers. Now because this group of friends trust each other, they allow sharing the lists with each other and create a superset list of hackers which they all trust.

Let's introduce a "trust" factor to each list. Because this group of friends have played with each other for a long time, they trust each other 100%, hence they unconditionally accept and combine each others lists. However, how do we get this group to share lists with another separate group of friends with their own lists? We have to derive a trustworthiness value to each list. This value can be based on how many hackers they have caught themselves and other historical data pertaining to how their list was created.

Now we have a bunch of players on a server, each with a list attached to their name along with a "trustworthiness" value that reflects on them as player and on their list. When they play with each other and come into contact, each player will make a decision based on their trustworthiness value whether to include their opponent's list to their own or not. Hackers are eventually ranked very lowly to any lists due to this weeding out process and as "trusted" players demand to play with other similarly "trusted" players, hackers will only have new users to play with and these new users will mark them as hackers and alienate them further.

This system has a chance to work if we assume there are more people wanting fair play than there are hackers. The easy sharing of lists (or dbs) allows this system to spread quickly through the community (similar to friendster). Also this is scalable because it scales with the addition of new players. New players = more people to act as hacker deterrents.

I realize these are some very lofty goals and I'm pretty sure I havent filled in many gaps in reasoning, I appreciate your feedback and will try to answer anything I havent covered yet.


scability

From: borg To: x6.rocketeer Posted: Fri Aug 25, 2006 3:02 am Subject: Re: anti cheating system i agree with you on reviewing replays by a real person rather than automated approach. for our localized db, a written policy is being developed by dakota_fanning (one of my admins) and we've decided to keep the exact details of the policy only known to a few admins (we dont want hackers to know how we can qualify them and make it easier for them to circumvent our techniques).

making replay reviewing scale can be treated as a necessary tax on the whole community. ie. if you want to play in a hack free community, you must do your part in contributing replays of hackers. making their trustworthiness status dependent on how many hacker replays they have reported/confirmed, should scale inherently. well... until there are fewer and fewer hackers to find, not sure what to do then.

-- extraneous thoughts -- think of how bittorrent works and how it blacklists ips that intentionally give bad blocks. also i believe clients with good connections get higher priority in trading packets. in our case, this would be the worthiness of the lists. similar logic can be used to join groups of lists.

i'll give you more feedback on your centralized approach (have to leave work now)



p2p vs centralized

From: borg To: x6.rocketeer Posted: Sat Aug 26, 2006 12:33 am Subject: Re: anti cheating system

Quote: p2p: what would happen, if a hacker joins your game, but his name is not in your list. how many lists do you have to traverse to find him? how big would be the penalty on bandwith for users? how big in terms of time? what if you don't find because he is not in you subnet?


for the p2p approach it feels like a problem that search engines have figured out... how to index all these data and retrieve fast enough. we might be able to relax the time constraints if we allow the hacker to play games normally as regular players, but a separate process is run in the background for the purposes of cleaning up the hackers from the main playerbase. this way we dont have to kick the hacker on the fly which like you say, probably will consume many resources.

Quote: centralized: every game equals at least one request per player to the server. how many bandwidth would be needed? how much does a suitable server cost per month?


for the centralized approach, the authentication server need not be the same as game server. as far as bandwidth goes, the authentication server shouldn't need more bandwidth than what the game server has. we should probably bring this question up to someone who coded one of these bnet emulators, they might have a better idea of how much is needed.

if an independant cdkey check is the way to go, how much does a bulk of say 255 ips cost per month?

by independent cdkey check, you mean validate their cdkey on the official bnet servers? i think that's the only way to go but i wonder what is keeping us from changing our own ips to log onto bnet (if we get ipbanned). obviously we dont want to foward the DOS attacks to bnet, but we may not be completely dead in the water due to bnet ipbanning us.

no sure how much ips cost, it would probably be bought off the hosting isp which resells the block that they've been allocated.



CS will be hacked

From: x6.rocketeer To: borg Posted: Thu Aug 24, 2006 10:35 pm Subject: Re: re: ipban Quote message yes, but this is so easy to circumvent that there is no point in implementing it. CS will simply be hacked to always report success.

keep in mind: if the hack author is determined enought to write a hack which works on pgt, then he will simply hack CS in addition to his hack. if the hack author doesnt care about pgt, then the hack (most probably) won't work with CS anyway, even without the cdkey check, since CS will have some basic hack detection.

you have to delegate the cdkey check, the question is how?


designing a safe system

From: x6.rocketeer To: borg Posted: Thu Aug 24, 2006 11:44 pm Subject: Re: re: ipban Quote message then the hacker just changes the function which sends the checksum to always send the correct checksum. it is so easy to circumvent protections like that... look at it this way: you are the pgt server. someone logs in and sends some data to you. you can never know it came from a real client or a hacked client which was changed to mimic the real client.

you just can't rely on the client.

delaying is an interesting approach, but it only delays the pgt ip ban. you always have to think of the worst case scenario. and that is a hacker which has access to more ips than pgt has. he logs on from every ip (not necessary at the same time). then all those fake cdkeys are in the queue and will be processed. result is a temp ban of the pgt ips.

to be safe, this is the formula: number of required ips = duration of temp ban in seconds * desired number of logons per second

now suppose you could get enough ips to allow one logon per second, i.e. 3600 different ips. what can hackers do? they can again spam the server with logon requests from different (maybe spoofed) ips. now the server only accepts 1 logon per second, so if the hacker tries to logon a few times per second (of course from different ips) it gets more and more difficult for users to logon to the server. and the pgt server can't distinguish between normal user and spammer.

ok this is all very hypothetical, such an attack might not happen. but if it does, users will be very pissed. and it is not very hard to do, the tools and the information is readily available on the internet.

the point is, we need to make the system safe enough that only a distributed denial of service attack could fuck it up, not some stupid dsl wannabe hacker.


id based on cdkeys

From: x6.rocketeer To: borg Posted: Fri Aug 25, 2006 2:22 am Subject: Re: anti cheating system Quote message Quote: What if we made the login method more cumbersome to defeat auto-logins?


that could work. i will look into the bnet and pgt login procedures and try to create a first draft. (will take time)

here is my idea how to give the community control over cdkey banning: in my opinion hacker detection can only be based on reviewing replays. a sensible policy needs to be developed to handle replay reviewing. this is also an aspect which has to scale. identification needs to be based on cdkeys. this is the only piece of information which users can't change easily. the idea is, that a user registers one or multiple accounts at a central server, which tests the key against bnet. if a hacker is detected according to the policy above his accounts are blacklisted and he won't be able to create new accounts with his cdkey.

your web of trust approach also seems promising, but it is hard to judge how such an approach will work in practice. also i'm too tired right now to give qualified feedback.

i'd like to hear your opinion about my centralized system and possibly a comparision with your p2pish approach. btw, where are you from?


bandwidth / resources considerations

From: x6.rocketeer To: borg Posted: Fri Aug 25, 2006 2:56 pm Subject: Re: anti cheating system Quote message

right now i'm thinking of the practical problems that would come with blacklisting hackers. p2p: what would happen, if a hacker joins your game, but his name is not in your list. how many lists do you have to traverse to find him? how big would be the penalty on bandwith for users? how big in terms of time? what if you don't find because he is not in you subnet? centralized: every game equals at least one request per player to the server. how many bandwidth would be needed? how much does a suitable server cost per month? if an independant cdkey check is the way to go, how much does a bulk of say 255 ips cost per month? maybe we should approach blizzard to ask to turn off ip banning for our server. but i doubt they will do that. i don't know if you have heard of the bnetd case. if i remember correctly, then they first sued them because of copyright infringement, but then they changed their accusation towards bnetd allowing players to join without valid cdkey. and they wouldn't provide a method for bnetd to validate the keys. also we are totally dependent on blizzard. if they are opposed to our method, they could just perm ban our ip range and shut us down for good :(

Around Wikia's network

Random wikia