hacking agar.io, part 2

This would be the second post in a series. You might want to read the first in the series if you haven’t already done so. Here, I continue with the work related to redirecting the game’s server traffic to my own website so that I can discover the interface.

DNS server

I first install Dnsmasq on my MacBook, add a single entry to its /etc/hosts file to redirect traffic for m.agar.io to my MacBook’s private IP address. Starting up Dnsmasq I then have a DNS server which will redirect game traffic to my own website. Make sure that the program is running by entering ps aux|grep dnsmasq|grep -v grep. You should see an entry for this program.

It’s probably a good idea to test your DNS server to verify that it returns the expected information.

nslookup
> server myip
> m.agar.io.
> exit

After entering the third line above you should see a DNS lookup which returns your server’s private IP address.

Our website

In my ~/sites folder, I run the following command to use Express to generate a generic website: express agar. As is usual for Express, I change into the newly-created agar directory and then run npm install to bring in the dependencies. Since the default installation binds to an upper TCP port and we want the standard port 80 instead, I then edit the bin/www file in this folder and replace the port number 3000 with 80 on a single line.

Note that Node.js, the underlying program that serves up an Express website, will not be able to bind to port 80 since it’s reserved unless I’m running as the root user. If your own user is setup to run the su command then you should be able to start this website with the command su npm start in the agar folder. Otherwise, you’ll have to run just su to become the root user, navigate back into your user folder area to find this folder and then just run npm start instead.

It’s probably a good idea to test the website by bringing up Safari and entering the address http://myip/ (substituting my private IP address) to see if it works.

Configuring the iPad

At this step, I’ll need to tell the iPad’s Wi-Fi configuration to use my own DNS server first and then the existing set of DNS servers next. You’ll find this under Settings -> Wi-Fi -> select the i button next to your own connected Wi-Fi network -> DHCP -> DNS -> prepend your own server’s private IP address and a comma at the beginning of the list.

This is the initial preparation for redirecting the game traffic to your own website. Note that the Node.js website while running will write to its log file and this will be our method of discovering the interface for Agar.io.

Discovery phase

By now attempting to play the Agar.io game on the iPad, it makes requests to what it thinks is the server. Only these requests are now being sent to my website instead. As each attempt is logged as a failure on my own website, I then make this call manually in another computer to the actual Agar.io website to see what it’s supposed to return.

For example, the game makes a request to the game server’s interface with just /info as the URL.

/info returns:

{"regions":{
  "CN-China":{"avgPlayersPerServer":368.5,"avgPlayersPerRealm":147.4,"numPlayers":737,"numServers":5,"numRealms":5},
  "US-Atlanta":{"avgPlayersPerServer":445.1034482758621,"avgPlayersPerRealm":203.2755905511811,"numPlayers":25816,"numServers":267,"numRealms":127},
  "EU-London":{"avgPlayersPerServer":430.6,"avgPlayersPerRealm":191.37777777777777,"numPlayers":8612,"numServers":179,"numRealms":45},
  "SG-Singapore":{"avgPlayersPerServer":546.0,"avgPlayersPerRealm":136.5,"numPlayers":1092,"numServers":9,"numRealms":8},
  "Unknown":{"numPlayers":0,"numServers":0,"numRealms":0},
  "BR-Brazil":{"avgPlayersPerServer":333.3220338983051,"avgPlayersPerRealm":200.6734693877551,"numPlayers":19666,"numServers":181,"numRealms":98},
  "RU-Russia":{"avgPlayersPerServer":473.25,"avgPlayersPerRealm":145.6153846153846,"numPlayers":1893,"numServers":45,"numRealms":13},
  "JP-Tokyo":{"avgPlayersPerServer":460.0,"avgPlayersPerRealm":172.5,"numPlayers":1380,"numServers":8,"numRealms":8},
  "TK-Turkey":{"avgPlayersPerServer":287.14285714285717,"avgPlayersPerRealm":154.6153846153846,"numPlayers":2010,"numServers":30,"numRealms":13}
  },
  "totals":{"numPlayers":61206,"numServers":724,"numEnabledServers":317,"numRealms":317}
}

As you can see, this is a fair bit of information. The format is known as json in case it’s not familiar to you. As of my writing this, there appear to be over 61,000 players in the game right now and well over 700 servers with almost half of those enabled. So this would be why it’s difficult to get a simultaneous FFA game with your friends—the odds are against you.

Without further ado, here are the other queries which I discovered.

/ returns:

37.187.171.110:1523
8QJP8

This appears to be your issued server and port on the first line and what is likely its instance alias from whichever cloud-based company they’re using.

/getLatestID returns:

131

I know, not very impressive. But it appears to be the highest user ID for your issued server.

/findServer returns:

{"ip":"151.80.98.52:1516","token":"86JYH"}

Another json response, this appears to also be issuing you a server and port. It’s possible that the first home query is asked at the beginning of the game and then /findServer is called each time your die in the game.

So far, this appears to be everything I’ve learned from this redirection technique.

Status

At this point, I now have the game interface which the Agar.io app uses to communicate with the server. It likely makes more requests but that’s good for now. I could have enough to go on in order to work up something so that multiple iOS people could join the same FFA game, for example, since we know this issuing mechanism.

hacking agar.io

In an earlier post I described an addictive game called Agar.io, an interactive eat-or-be-eaten game involving graphical dots. In this series of posts, I’ll be attempting to hack the game to see what I can get away with.

Agar-top

Define:  hacking

I suppose there are several ways of interpreting the term hack here. In the movies, some character will “hack the mainframe” or some other nonsense. And we’re also familiar with someone who attempts to use techniques to hack a website, perhaps injecting SQL code into an innocent-looking HTML form. Here, I refer to one of the original uses of the word, to hack away at a problem until it is solved. I’m interested in the game itself, how it talks to the server and I’d like to go to school on their efforts. As a coder of smartphones myself I’d call that part of the learning curve.

Goals

Ultimately, I would like to learn how the game works behind-the-scenes. I do have some secondary goals though. It would be interesting to see if it is in fact possible to edit an existing iOS app and have it still work and all without the original coder’s digital certificate. If successful, I think the first order of business would be to remove the ads you might see during game play. Another personal goal would be to allow multiple friends on iOS devices to play the FFA (free-for-all) mode of the game with each other; this could be made possible with a proxy server, I’d propose.

The platform

Currently, I play the Agar.io game on an iPad II since I prefer the interface over a browser-based version that’s available. So I will be attempting to hack the Apple store app ultimately.

This may turn out to be impossible since an app that runs on iOS is supposed to be digitally signed to prevent tampering. And yet this is what I intend to do, nonetheless. I’ll be testing that assertion to see if a hacked app will still work.

Concepts

Here, I’ll discuss some of the concepts of the approaches I’ll take.

  • Patching:  Patching is an old-school technique in which binary code, for example, is edited in place with a script. Individual characters or code is replaced in the original to create a new file. The patch program itself works together with another program called diff, used to calculate the differences between two files.
  • DNS:  This service is responsible for looking up a name like m.agar.io and replacing it with an IP address.
  • Redirection:  Using your own DNS server so that you can redirect requests to your own website instead of the intended one.
  • iOS app:  An iOS app might seem a little daunting if you’re not a coder. It’s actually a collection or manifest of files all rolled up into one .ipa file. I think it’s safe to say that the app was written in Apple’s Xcode using a computer language like Objective-C or Swift.
  • Ad-based add-ons:  It’s clear that Agar.io has many opportunities to display ads within the game itself. The programming interface to these (for the Agar.io developer) is almost always JavaScript-based.
  • Tethering:  Connecting a smartphone—or the iPad in this case—to a computer to allow for interaction (like development testing) to occur.

Throughout this series of posts keep in mind that if I’m indicating a command, it’s often being done on a MacBook with OS X 10.11.5 El Capitan at a shell prompt. Otherwise, I could be referring to something I’m doing on an iPad II with iOS 9.3.2 installed.

DNS server

I’ll be using the Dnsmasq easy-to-implement DNS server for redirecting Agar.io’s server requests to my own website. I’ll then configure my iPad to use this server first when doing DNS lookups.

Discovery website

And since I’m familiar with Node.js and Express I’ll be using this to mockup a website for those redirected app requests. When the iPad makes a request to what it thinks is the Agar.io website, I will see that request in my website’s logs.

This could be technically called a man-in-the-middle technique since I could then have my own website forward the request to Agar.io’s actual server and then answer the iPad with that response, adjusting it if I wanted to. I guess technically you could also call this a proxy approach.

Binary editor

I’ll likely also use Hex Fiend at least minimally to find the location within the main program app where I’ll be patching the code.

Installing a modified app

Normally, you would download an app directly to our iPad straight from the Apple iTunes store. Technically, I suppose, I could have taken advantage of the redirection concept from before to steer the iPad to my own website to deliver the edited content but it’s not that difficult. There appears to be a mechanism so that you can download iOS applications on an OS X computer and then, while tethered, install them remotely using iTunes. This actually allows us to use a MacBook in this case to snag the code package itself and to start all the fun. We’ll be taking advantage of this in order to then try to push a modified app package to the iPad.

If you’re on a standard OS X computer and you get the Agar.io app, it won’t seemingly do anything after the download; you’re not presented with the usual Open button after it has downloaded. It does, however, get silently copied to your hard drive under your user folder in /Users/username/Music/iTunes/iTunes Media/Mobile Applications. Having downloaded it, you should find a file called Agar.io 1.3.0.ipa which is the app (collection) itself.

Expanding the app

From here, you might not know that an .ipa file is little more than a .zip file. I’d suggest copying the Agar.io app file somewhere else (like creating a folder called AgarIO) and then open a shell so that you can decompress it.

MacBook:AgarIO$ unzip "Agar.io 1.3.0.ipa"

This command then will decompress the collection of files for you.

What’s inside the .ipa file

There are a lot of files inside this package, just like you’d find with most store apps. The first I’ll discuss is iTunesMetadata.plist which is perhaps the most aggravating of all. A .plist file is like a database for a coder, it usually stores configuration options. Opening it with TextEdit then shows me that this is the file responsible for knowing who downloaded it (myself) and how I’m then authorized to use it. I’m sure there’s a similar mechanism inside any music file you download from iTunes to prevent you from playing it on an unauthorized device. So in other words, I couldn’t just patch the Agar.io application and then make it available for download for others. Each person interested in this would need to go through the motions themselves.

Next, there is a META-INF folder which contains two files. I haven’t fully investigated them yet but the first is com.apple.FixedZipMetadata.bin which appears to again be a compressed collection of files. And the second is com.apple.ZipMetadata.plist. It appears to have some indication of how the actual program was zipped up into an .ipa file.

The final folder is Payload which includes what appears to be a single file, Agar.io. Or, is it a single file? Knowing what I do about making iOS apps, it’s actually another compressed file. In Finder, you’ll want to rename this Agar.io file to Agar.zip, for example. Back in your shell, then unzip it as you did before to expand its contents.

What’s inside the Payload file

So now we’re getting down to the actual programming itself. Everything we have seen up until now is just a wrapper so that iTunes and Apple can provision an app to you and just your device(s).

Surprisingly, there are a total of 1,111 .png graphic files inside. Most seem to represent the many skins that you’ll see in the game. There are 153 .plist files which are used to store anything from advertisement configuration information, to promotions, to language localization information and collections of available skins by category. With respect to my goals, I’m not really interested in these. And there is a single .db file for the Vundle advertising platform.

There is a folder called _CodeSignature which appears to include hashes of the collection of graphics, presumably to prevent them from being edited perhaps.

There are 65 .ccbi files which appear to be another form of .plist files. There are 15 .json files which appear to have different localized versions.

Finally, there is agar.io which is the actual program file itself. I’ll save the actual editing for a follow-up post to this one.

Status

That’s a good start so far. We’ve downloaded the Agar.io app and performed two decompression steps to get at the actual executable itself. Next, I think I’ll switch gears and build the discovery website and DNS server so that I can get at the app’s server interface.

Update

Skip to the final post in this six-part series if you’re looking for the code. Enjoy!

firebase notches things up

Looks like Firebase is likely getting an influx of capital from Google from what I’m seeing. Google announced on May 18th that they’re using Firebase as its unified platform for mobile developers after acquiring them in 2014. Too bad they didn’t give the nod to Adobe’s PhoneGap, given its traction so far in this arena, to-date.

Firebase’s pricing page now indicates that their free entry-level tier Spark now includes custom domains! This is going to be great for developers, especially. We can’t afford to pay $25 per month per concept site that we’re running—that’s just madness. But we can afford free. I can afford free all day long, in fact.

Granted, there’s a lot that you don’t get with Firebase since it really changes things up. You  don’t get server-side code like you might get with the typical Apache/Perl setup. You also don’t appear to have server logs that you’d find on most hosting plans. I think they assume that you’ll use Google Analytics and push that content to them in the form of client-side JavaScript.

Existing developers

Unfortunately, they haven’t figured out what to do with us early implementors. Their interface wants to charge me to add a custom domain to my developer tier. I assume that you’ll need to delete your existing rig, re-create a new account and then push the content back to them in order to take advantage of the new Spark tier offerings.

a new app pricing model

Personally, I don’t like the idea of “in app purchases” which seems to be the norm these days in the current app pricing model. You get the app for free, try to use it and then find out that you can’t save your results unless you pay the author for this feature. If you’re like me then you usually feel like they’ve wasted your time.

I would suggest that a better model is how we now buy music.

Changes in the recording industry

You used to have to purchase the entire album just to get a single song, that was just how things were. If an artist or band had one killer song that was enjoying a lot of airplay on the radio and assuming that you really wanted that song then you had to pay the $12 or so for the entire album. And you just crossed your fingers that one or two of the other songs made it worthwhile.

With the advent of iTunes and similar websites, we now have the ability to sample and purchase exactly which songs we want to pay for. If half of the album isn’t worth it, you don’t have to buy all of it. If the artist only has one good song then there’s no reward for them to pad the album with a lot of junk.

A new model for app pricing

So why shouldn’t we just show our app’s prices up front instead of hiding them inside? Currently, a new customer can’t see how much of the app is crippled and how much is functional until it’s been downloaded and used. How many times have you downloaded and demo’d two or even three different free apps of the same kind, trying to find one that was reasonably useful?

What we need is a venue for selling our apps like musicians sell their songs. Theoretically, it might look something like this:

PayAsYouGo_734x466.png

More feature transparency

The biggest benefit to a model like this is that it shows the potential customer what’s included in the full program and the cost of each feature. If, like me, they’re not interested in the social connector feature then they simply don’t purchase it. You pay for what you need and nothing more.

As developers, we would distribute modules of functionality and charge the user on a per-module basis. I would suggest that features be priced differently based upon the perceived value. In fact, there’s nothing to prevent the price of a popular feature from increasing over time.

Like in the iTunes model, clicking a play button next to the feature ought to bring up a demo or screenshot of the feature in action.

database app, no server-side

This is new for me. As a long-time website developer I consider myself a hardcore backend developer. For years I’ve contracted out as the guy you’d go to for the database design and subsequent server-side code to access that database. And now I find myself working on a website with a slick-looking frontend and—gasp!—no server-side coding at all.

“How is this even possible?” you ask. Even a week ago, I’d have been just as confused as you may be now.

Firebase

Fortunately, there’s a platform called Firebase which actually allows you to write a database application with no server-side code whatsoever.

Here’s a list of things you’d normally need backend code to do on behalf of activities initiated by client code (on both your users’ and your admins’ browsers):

  1. Authentication, password maintenancerights control and logged-in state management
  2. Creating database records or objects
  3. Reading from database records or objects
  4. Updating database records or objects
  5. Deleting database records or objects

It turns out that you can configure Firebase to use email/password authentication and as a result of this decision you can do your entire site design without necessarily writing any server code.

As an added benefit you then don’t have to find a hosting provider for that server-side code either. And since Firebase allows you to serve up your static HTML website then this is appears to be a win-win.

Changing your perspective

Server-centric

In other systems like Node.js, e.g., you write your application from a server-centric perspective. You might begin by creating something which listens to a particular port, sets up a router for which pages are delivered and then you setup handlers for when a page is requested or when form data is submitted to a page. Lastly, you might then write some separate templates which then are rendered to the client when a page is requested. The design approach is very much: server-side first, client-side second.

Client-centric

Firebase appears to be turning things completely around. In this case you might begin with the page design itself using something new like Google’s Polymer framework. You would focus a lot of attention on how great that design looks. But then at some point, you need to register a new account and then authenticate and this is where you’d code it from client-side JavaScript. Here, the design approach is: client look-and-feel first, client JavaScript to authenticate second.

Rendering static plus dynamic content

In the past we might have rendered pages with server-side code, merging data in with a template of some kind, say, something written in Jade. In this new version we still might have a template but it’s just on the client now. Additionally, Polymer allows custom elements to be created. If you’ve ever written server-side code Polymer does allow you to bind data as you might expect.

Page routing

The Polymer framework includes a client-side routing mechanism so that you may serve up different pages from the same HTML document. But even if you don’t use this approach then Firebase‘s hosting provider will do that for you; just create separate pages and upload them and they’ll take care of the rest.

Why you might want this

Like me, you might have built up a level of comfort with earlier approaches. I myself often think about a website design from the server’s perspective. One downside to this approach is that you possibly could end up with a website design that looks like you spent 90% of your effort on the backend code and didn’t have enough time in your schedule to make things look really awesome for your users.

By beginning your design with the UI you are now forcing yourself to break out of those old habits. You work up something that looks great and only then do you begin the process of persisting data to the database server.

firebase

This now allows you to focus on how the application will look on many different devices, screen resolutions and whether or not those devices include a touchscreen and features such as GPS, re-orientation, etc.

Google and Firebase

All of this Firebase approach works rather well with the Polymer framework and I’m sure this is the intent. In fact, there seems to be a fair bit of collaboration going on between the two with Google suggesting that you host on Firebase from their own website.

Scalability

I think one big benefit to no server-side is that there is no server-side app to scale up. The downside then is that you’ll likely have to upgrade your hosting plan with Firebase at that point and the pricing may or may not be as attractive as other platforms like Node.js on Heroku, e.g.

Custom domain

Of course, you have to pay $5/month minimally to bind your custom domain name to your free instance. I wouldn’t call that expensive necessarily unless this is just a development site for you. In this case, feel free to use the issued instance name for your design site. At this $60/year level you get 1GB of storage which is likely enough for most projects.

Pricing note

Firebase‘s pricing page mentions that if you exceed your plan’s storage and transfer limits then you will be charged for those overages. Obviously, for the free plan you haven’t entered your credit card information yet so they would instead do something in the way of a denial-of-service at that point. If you have opted for that minimum pricing tier please note that this could incur additional charges if you’ve poorly-sized your pricing tier.

Overall thoughts

So far, I think I like this. Google and Firebase may have a good approach to the future of app development. By removing the server you’ve saved the website designer a fair bit of work. By removing the client-side mobile app for smartphones then you’ve removed the necessity to digitally-sign your code with your iOS/Microsoft/Android developer certificates nor to purchase and maintain them.

All of this appears to target the very latest browser versions out there, the ones which support the very cool, new parallax scrolling effects, to name one new feature. The following illustration demonstrates how different parts of your content scroll at different rates as your end-user navigates down the page.

parallaxEffect

Since parallax scrolling is now “the new, new thing” of website design I’d suggest that this client-centric approach with Polymer and Firebase is worth taking a look.

github

I suppose most of us these days have a github repository and this blog post would be the obligatory mention of mine.  I try to work on phone apps these days (PhoneGap) and Node.js backends every chance I get.

I can’t say that I’m very active on the open source side of things.  I only manage to throw down another version about once per week or so.  I find myself fairly ignorant of what goes on with respect to active multi-person open source projects—I only really have experience in bigger Microsoft programming shops on a Visual SourceSafe repository, for example.  And I have also used Microsoft Team Foundation Server as served up via the VisualStudio.com website from the Visual Studio program itself.

Outsource Guru on Github

I may start putting some of my older projects on there, time will tell.  I tend to select things that have a tutorial component to them so that I can demonstrate to others an intro to something.

Would I add a library to github?  At the moment, I don’t think so.  Libraries are useful to other open source coders but they’re also usable to corporations who are well-financed.  I’m usually paid to code so I think I’d like to be careful what I put out there for free.

A better github paradigm

What would be nice is if you earned credits with github for every download of your code.  And then you could spend these credits by paying for your own downloads on there.  Any individual without credits would need to buy them with money first if they wanted to download code.  If you could buy a credit for $1 then in theory you ought to be able to sell a bulk of credits for $0.75 each.  Github themselves would earn the difference since they’re hosting the platform itself.

And yet, it’s the norm these days for an average open source program to be made up of other open source code as dependencies.  So the crediting scheme would necessarily need to pay out fractional royalties to the people who created those dependent portions of code.  And so, if your own code is made up of 90% of other people’s code you would only see 10% of that credit and the rest would be distributed to them.

The benefit to a system like this is that a coder like myself—who’s used to getting paid to do this—gets paid for doing this.  Anyone who downloads code has to pay a credit from the balance on their account.  Having downloaded code they’re free to then use it.  And if they then re-bundle someone else’s code into their own then it’s become part of a commissioning scheme and everyone gets paid for their effort.

“The benefit to a system like this is that a coder like myself—who’s used to getting paid to do this—gets paid for doing this.”

An additional benefit to this system is that it no longer rewards the corporations who get a free pass to download unlimited code at your expense.

So the new system would work like iTunes, perhaps.  Maybe you could buy a card in a retail store with credits and redeem them on the site.  But if you created an account and uploaded a popular library then you could start earning credits almost immediately, in theory, anyway.

Adobe PhoneGap

History

In 2011, Adobe purchased an existing mobile application development framework by Nitobi, branding it at that time with the name PhoneGap.  They’ve since released it into the open source arena as “Apache Cordova” although many of us still refer to it as PhoneGap.  If you’ve ever attempted to create native iOS, Android or Microsoft Phone applications then you’ll enjoy this new multi-platform approach.

Before PhoneGap, you’d have to install a development kit for each of the various platforms you wanted to target.  And then, you’d need to learn the platform language of each major player:  Objective-C or Swift for iOS, Java for Android and XAML with C# for the Microsoft Phone.  Good luck trying to then design and maintain three completely-different collections of phone app code which hope to provide the same functionality.

Today

But now with PhoneGap, you use what you probably already know:  HTML, JavaScript and CSS.  You then either 1) compress your collection of files using a ZIP file and upload this to Adobe’s website or 2) use the popular github.com repository to manage your software changes and then tell Adobe the location of your github.

I’ll add to this that jQuery Mobile does a great job of streamlining some of the work you can do with PhoneGap.  It includes both methods for interacting with the browser’s DOM and a nice collection of CSS for displaying and lining up the widgets your app will need, for example, phone-styled push buttons that are sized correctly for fingers.

Develop

An initial set of app code is created from a command-line interface, producing a collection of files you’ll need for your app.  You’ll usually focus on two files within this collection:  config.xml and www/index.html.  The first will configure the name, version and rights that your app will need and the second defines the interface.  Use any editor you’re comfortable with.  And if you’re familiar with the github source code management then this can be useful later when you build your app.

You usually develop with the help of the PhoneGap Desktop App plus a phone-specific version of the PhoneGap Developer App.  The Desktop App reads your code and serves up a development version of your application; the specific Developer App for your phone will allow you to test your code.  As you make changes in your code the Desktop App will send the new version to your phone so that you can instantly see the change.

Up to this point, none of this yet requires any build keys from Apple, Microsoft or in the case of an Android app, your own self-signed certificate.  Since PhoneGap’s Developer App itself is signed, you’re good to go.

Test

The default set of files from PhoneGap comes pre-equipped with the Jasmine test suite built in.  Edit the www/spec/index.js file to modify the default tests, verify that the PhoneGap Desktop App is running and then execute them by bringing up the /spec folder for your application within the PhoneGap Developer App.

Build

When you’re ready to start seeing your application as a stand-alone app you can then build it on the PhoneGap Build website.

You have two choices for pushing your code to PhoneGap Build:  1) compress your files into a ZIP file and upload it or 2) use a github.com repository for your project and tell Adobe that location.

Since phone apps need to be digitally-signed to identify the developer it’s then necessary to upload to PhoneGap Build one or more keys for this purpose.  An iOS app will need an Apple Developer key, a Microsoft Phone app will need a Microsoft Developer key and finally, an Android app uses a self-signed certificate that you can create without Google’s knowledge/consent or paying them a fee (as is the case for the first two platforms).  The PhoneGap Build website provides enough guidance in this area.

Once built, the PhoneGap Build website provides one or more individual binary downloads on a per-platform basis as well as a QR Code scan image that you can use to direct your phone to fetch the appropriate one.