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!

royalty-source code

The Concept

Here, I’m coining a new term for the software development world.  Similar to open source software, royalty-source code would be widely available for download via a system like github.  Unlike open source, however, royalty-source includes a mechanism so that each coder gets paid as programs get downloaded.  This new mechanism should fairly distribute royalties based upon some sort of weighted system for each of the dependencies.

Typical Dependencies

The following tree shows a typical collection of dependencies pulled into a new Node.js program named MyNodeProgram, as an example, with the single command npm install mongoose:

  • MyNodeProgram
    • mongoose
      • async
        • benchmark + 22 other dependent libraries
      • bson
        • nodeunit
        • one
        • benchmark
        • colors
      • hooks-fixed
        • expresso
        • should
        • underscore
      • kareem
        • acquit
        • gulp
        • gulp-mocha
        • gulp-jscs
        • istanbul
        • jscs
        • mocha
      • mongodb
        • etc
      • mpath
        • mocha
        • benchmark
      • mpromise
        • etc
      • mquery
        • etc
      • ms
        • etc
      • muri
        • etc
      • regexp-clone
        • etc
      • sliced
        • etc

Doing a directory listing of your program’s node-modules subdirectory should then reveal just how much code got pulled from github with that single npm install command earlier.

Royalty Debt

Unlike open source coding projects, royalty-source coding projects add a new concept to the business model.  Royalty debt is the added virtual cost to your project with each npm install command you invoke.

If you envisioned charging $1.00 for each download of your own program and it now contains that mongoose dependency from before, you’ve greatly diluted your own code with the inclusion of this large collection of code that somebody else created.  If you created a typical Hello World program that uses a MongoDB database and assuming that you only add a few lines of your own code, then you might only get $0.01 of that $1.00 download royalty and everybody else would get the remaining $0.99 of that sale.  Without that mongoose inclusion, it would be unlikely that anyone would want to pay you $0.01 for your code, at least in theory.  You might then accept this 1% ratio as what it takes to make money.

Instead, you might start to rethink your entire program from the ground up.  If you could remove the mongoose dependency and store your data in a simple BSON object instead you possibly could drop that dependency completely and the royalty debt it incurs.  Assuming that you no longer had any other dependencies and people are still happy to pay the $1.00 price tag, 100% of that is now yours to keep.

One big benefit to this concept of royalty debt is that it should incentivize coders to review that stack of dependencies to look for anything that’s been included and yet which doesn’t add much value to the overall project.  The coder then should remove any unwarranted code to lower the bloat effect we often see in open source projects.  Smaller code is often better code.

Pay the House

Obviously, whoever is the new github provider will charge a commission of some kind for each download.  The download price minus the commission equals the total royalty to be split up.

Hopefully this system would include balances which would allow someone with existing credits to then use them to download other code.

Royalty Distribution

Presumably, a value system would be in place which weighs each dependency against the parent program’s code with some kind of fair distribution model.  As in the above Node.js example, the benchmark code appears at least three times as a dependency and should then get a bigger piece of the pie, so to speak.

New Tools

Given that we’d now have royalty debt to think about before adding a new dependency to our project, we should have some tools to quantify that cost.  In theory, you’d run the npm install command with an extra argument which quantifies that module’s package.json dependency list.  Let’s say that you might run the following command from your MyNodeProgram folder:  npm install mongoose --cost

At this point, npm might indicate…

mongoose @4.3.5:  Cost=$0.99/$1.00

Note that this is assumed to be a guesstimate at this time since your own program’s few lines of code were compared to the collective code and dependent modules of mongoose to return this ratio.

As a coder, you now have a build-versus-buy decision:  1) build your own database code instead or 2) expect to pay for mongoose (and dependent code) with each sale/download of your own code.

Pay the Piper

Obviously, it wouldn’t be fair to the coders of your own dependencies if you under-valued your own program.  If you decided to charge only one cent for your Hello World example above with all those dependencies, you’re distributing someone else’s code for a small fraction of what it would be worth otherwise.  In this system each module author should be able to define a minimum cost for their library.  As this code gets included into parent projects they should honor this requirement.

The benefit of this minimum cost feature is that it will gradually increase the cost of increasingly-larger code.  If the total minimum cost for the mongoose module is $0.33 then the next author must charge a minimum amount which factors this into the total download price.

Final Thoughts

So why should we bother with a royalty-source code system when open source seems to be working fine?

  1. We’re not getting paid to create software
  2. Everybody expects us to be responsive to their own needs (fixing bugs/issues) without considering that we normally expect to pay for services rendered
  3. Corporations are using open source code as a means of not paying software developers
  4. Other than a virtual tip jar, there doesn’t appear to be anywhere within the open source system where the coder gets anything for their efforts
  5. It costs a lot of money to pay rent, to eat and to otherwise afford a working computer and Internet connection as a developer