eRepublik security explained; catching bots &scripters

eRepublik security explained; catching bots & scripters

Introduction
This article will attempt to explain the current security system implemented in the massive multiplayer browser game eRepublik. This article will serve as a reference to the means that the game undertakes to protect itself from multi-accounts and being automated by scripts. Once you understand how it all works, you will be able to bypass the security system in your own programs (unless,ofcourse, this article gets outdated). As with any topics concerning web applications, it will be assumed that you have some basic knowledge of HTTP protocol, HTML, PHP and Javascript (AJAX). I will also provide some tables and example code in C# to make this article as effective as possible. Besides that, I will also present some ideas on how to improve the security system and make it much harder for the cheaters to cope with.

eRepublik security explained; catching bots & scripters

General overview
Truth to be told; the eRepublik security system (presuming it can be called that way) isn't really complex. But, really, there's not much one could do to prevent the usage of scripts and tools that automate the game. However, there are quite a few techniques that could be implemented to easily find such users or atleast make their lives harder. Before talking about these techniques; let's see a general overview of the current security system implemented in eRepublik. It doesn't require a lot of research to come to the conclusion that the only shield eRepublik uses (besides cookies) against such tools are the generic, so-called form tokens. eRepublik uses an opensource web framework (coded in PHP) called symfony, which by default contains the implementation of form tokens. These tokens aren't really meant to protect the forms against automations, but are actually protection from CRSF (cross-site request forgery). Now, why this would present a problem to the scripters and bot programmers is that these form tokens are always unique and serve as a hidden field in each form that the user is sending to the server. Let's break down the Login page and see what it takes for a scripter to log in his multiaccount automatically. Form ID login_form Elements ID _token citizen_email citizen_password remember NAME _token citizen_email citizen_password remember TYPE hidden text password checkbox VALUE a21b641988c1b0f2b3f5b3003bff51d0 user@email.com 123456987 on NAME METHOD post ACTION /en/login

Anyone can easily extract the information shown above by reading through the HTML code of the eRepublik index page. I have used the Web Developer addon for Chrome for easily doing this instead of reading through the page source manually. It is rather obvious what each elements represent (only 4 elements are sent to the server however, you can disregard the button element). I presume you know how the browser works, so I'll skip that part. In order for a scripter to automate this page, all it requires for him is to get the value of the _token field, fill in the other elements and send a POST request to /en/login, specifically (http://www.erepublik.com/en/login). Now, let's say a programmer has developed his own Browser class (like I have) and can easily manipulate and traverse the DOM tree of an HTML document. Getting the token value could be done in a single line of code:
string token = Browser.FindFirst("#_token").Attributes["value"].Value;

eRepublik security explained; catching bots & scripters

Where the '#' character denotes the ID of an element (notice the ID in the elements table). Everything else that's left to the programmer is to send the data to the server:
// Parameters: URL to POST to, POST data, Is XMLHttpRequest?, Referer BrowserPost("http://www.erepublik.com/en/login","_token="+ token +"&citizen_email=user@email.com&citizen_password=123456987",false,"http://w ww.erepublik.com");

From here, we could do multiple checks such as this one to see if we logged in successfully:
if(Browser.CurrentURL =="http://www.erepublik.com/en/login"){...}

If we put in the wrong user data or sent a wrong token, we'd be redirected to the URL above. All other actions in eRepublik, such as work, train, fight would use the same mechanism for automation. The only real barrier (which is not even intended to stop automatism) is the anti-CSRF token. Reading the responses from the server is also a trivial act, a matter of reading HTML or JSON. Here's an excerpt from a real application that can automatically fight:
... string url ="http://www.erepublik.com/en/military/fight-shoot"; string post ="_token="+ token +"&battleId="+ battleId; BrowserPost(url, post,true); var response = jss.Deserialize<dynamic>(Browser.DocSource); int damage =0; if(response["error"].ToString()=="False") { var user = response["user"]; var enemy = response["enemy"]; if(response["message"].ToString()=="ENEMY_ATTACKED") { string log ="Attacked enemy "+ enemy["name"].ToString()+". He's got "+ enemy["health"].ToString()+" wellness left. "; log +="We've got "+ user["health"].ToString()+" wellness left."; Profile.Wellness = user["health"]; LogToUI(log); } ...

So, in this chapter I have shown you an example of how easily a programmer can automate the eRepublik tasks. But, it's obvious that this code has a lot of constants and it isn't very easy to maintain, especially when eRepublik updates. The major kickback of of most scripts and applications of this kind is: coping with updates. Before talking about this matter, we'll take a look at two more techniques eRepublik might be using (I haven't been able to fully confirm this technique).

eRepublik security explained; catching bots & scripters

Browser useragent
With every HTTP request, the browser sends one interesting field called useragent. Basically, it's a field which tells the server what kind of a browser is the user running. In the case of the newest Google Chrome version, the useragent field is:
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

Why this field is probably not used for the detection of cheaters is that the field can have the exact same value in both normal and script users. But, if combined with more parameters such as IP range (it's highly unlikely that ALL normal players within one range will use the exact same browser) this could be quite a powerful tool. Script users and bot masters tend to use proxies which are usually large server centers with very similiar IPs and some scripts do not spoof the useragent properly.

Referer
Another field being sent from every browser to the server is the field called referer. It's value is the URL that the user was previously on (in a nutshell); the exact definition would be what URL refered us to the current page. Imagine we were on the Battlefield page of eRepublik. Whenever we click the Fight button, we're sending a POST request to http://www.erepublik.com/en/military/fight-shoot. But, with each request the Referer field would be the battlefield URL; i.e. http://www.erepublik.com/en/military/battlefield/12544 where the number denotes the battle ID. Many scripts and automation tools forget this field and just send requests with the Referer field being empty or not set. This way, eRepublik could only accept requests that have a proper referer, and those who do not mark them for inspection and ban later.

Testing
I have tested does eRepublik check for these two fields using exactly 100 accounts. All of them were not setting referer fields while fighting and they all had the same useragent within a very close IP range. The result is that 4% of the accounts have been banned. Since that small percent doesn't really prove anything, I suspect eRepublik checks for the useragent and referer field. I didn't do extensive research on what caused those 4 accounts to be banned, but it might be that their proxies were not properly working or were not completely anonymous.

eRepublik security explained; catching bots & scripters

Catching bots
Before actually starting this chapter, I should point out that under bots I mean multi-accounts managed by botmasters using scripts. There's a huge number of such accounts in the eRepublik, although I have no approximations I believe the number is more than 20.000. So, I'm not including the multi-accounts that some users are managing manually. I have had the chance to read the sourcecodes of Polish, Hungarian and Serbian and all they can support a very large number of accounts especially the Polish one.

An idea
As I have pointed out before, the main downside of these scripts and applications is that they need to be updated whenever eRepublik updates. Now, the mistake eRepublik developers have been doing for the last 4 years is they had very rarely updated some basic modules like work and train. Instead of updating/changing these small things (but not change them fully; I'll elaborate later) they have been only doing massive updates and as such they were very noticeable. Instead of such massive updates, if I were an eRepublik developer, I would do some really small , unnoticable changes. Here's an example on how you could catch thousands of bots with minimum effort: Working in a company requires a simple AJAX request to http://www.erepublik.com/en/main/work. Considering symfony is a MVC framework, you could create a new controller which would handle work actions and do everything like the /main/work controller, and then update the My Land so it goes to this new controller, let's say /main/newwork. HOWEVER, you would not delete the old controller but instead slightly modify it: you would silently log ALL citizens which worked using this old controller and redirect them to /main/newwork so it takes care of the work. These citizens wouldn't notice anything the reason I put the word citizens under quotes is that they are actually bots. You see normal users who went to My Land normally using a browser worked using the new controller - /main/newwork. The script users (now outdated without them noticing) have all worked using the old controller and are logged so you can investigate them (probably 100% of them, since there can't be a cached version of My Land). Doing things like this on a regular basis and on random days in a week, not only on Work action but on more, can truly mark a huge number of fake accounts, pain-free. Investigating where did the gold from them go will also bring down the botmasters and their friends. I have a couple of more ideas in my mind, but since I barely had the time to write this - rather short article, I have to leave it at this.

Happy programming, skydesign04@gmail.com