Analysis of iOS Games tracking traffic

A little while ago, I spent a weekend analyzing a wide cross-section of applications from the iOS app store across all categories. You can read that right here. One specific topic that I had comments and questions about specifically was the games. The iPad, as an example, is not a bad gaming platform. And I know a lot of people who play free iPad games, and let their kids play them. So I figured I’d do a bit of a bigger dive into that specific category of applications and see what sort of information they track about you and your device.

I downloaded the top 25 applications on the games section of the iOS application store as of July 20th, 19:00 GMT. The list goes as following, with the number of outbound connections to different sites the application makes:

  • Fish with Attitude            14
  • CSR Racing                          8
  • Water? Free                        7
  • Battle Bears Royale         6
  • Ice Age Village                  5
  • Mutant Roadkill                5
  • Angry Birds Space Free 4
  • Fix-It Felix                          4
  • Shark Dash                           4
  • The Sandbox                       4
  • Flick Kick Football           3
  • Magic Puzzles                     3
  • SongPop Free                     3
  • Flow                                       3
  • Arms Cartel                        2
  • Betrayal HD                        2
  • My School Dance             2
  • Pyramid Run                     2
  • Super Pretzle Factory   2
  • Temple Run                       2
  • Bakery Store                     1
  • Bubble Mania                   1
  • Guess!                                  1
  • Subway Surf                     1
  • Major Mayhem               0

Here are some quick stats:

  • 25 applications
  • 48 different urls were used to track different information about the device
  • The application to communicate with the most servers was Fish with Attitude, talking to 14 different sites
  • The application to communicate with the least servers was Major Mayhem, being the only to not send any tracking information about the device
  • 11 of the servers were contacted over HTTPS (23%)
  • 37 of the servers were contacted over HTTP (77%)

Tracking sites top 10
Here is the top 10 of the different URLs that were observed to track information about the device:

-                         15
-              9
-                           4
-                     4
-                               3
-                  3
-       2
-                     2
-   2
-  2

As we can see, there are a lot of similarities between this data and that of the Overview of iOS tracking traffic analysis. Flurry, Chartboost, and Tapjoy are again back, being extremely popular. Please see the previous article for analysis of the requests made by these.

Analysis of the other sites
Between the top 10 sites as listed above, here is what is being tracked by them.

  • Specific events in the game
  • OS version
  • Device version
  • Mac Address
  • Local IP Address
  • Mobile carrier
  • Unique identifiers
  • Radio type (WiFi or 3G)
  • Timezone
  • OS locale
  • Application identifier
  • Application version
  • Screen resolution and orientation
  • Time stamp

The big pictures is owned by the company “Burstly”. It is used for developers to sell applications to be shown in their applications. It communicates over plain HTTP, and will track a lot of different values about your device.

There are two hashed/encrypted fields, seemingly being related to the mac address of the device. Also it seems to be carrying across, or at least have keys allocated for, the IP address and carrier of the device. Neither were sent across for my device, possibly because it’s a WiFi iPad. But I found that very interesting. Beyond that:

  • Platform
  • Carrier
  • Device type
  • OS Version
  • OS Locale
  • Screen resolution
  • Application build
  • Device Family
  • Unique Identifier
  • Application identifier
  • Location country
  • Radio type (WiFi/3G)
  • encMAC(Encrypted mac?)
  • IP Address
  • mac(Hashed mac address?)
Apsalar is a “mobile app analytics” platform, specifically focused as measuring “engagement”. It communicates over HTTP as well, and is very chatty. For instance, Battle Bears Royal made 13 requests over a period of 9 seconds. It specifically will also call back on specific events, such as game opened and other developer-specified events.

There appears to be a lot of encoded data sent across by this particular system. So we can’t see that much from this, but we can tell a few times:

  • Application identifier
  • Locale date
  • Radio type (WiFi in this case)
  • Platform
  • And then a lot of seemingly hashed data I can’t make very much out of.
Playhaven is a marketing platform for mobile games. It communicates over HTTP, and passes over the device UDID and a mac address.

We see that this sends across a nonce, which is quite interesting. These are generally used to prevent Cross-Site Request Forgery. It also transmits:

  • Mac Address
  • Device version
  • Unique identifier
  • A nonce
  • OS version
  • Application identifier
  • Connection (Radio type?)
  • A token
  • A signature
  • Application version
Gameloft is a game developer which develops, publishes and distributes games for smartphones. Their games all talk to a couple of different domains. All of them are HTTP, but one application communicated with the livewebapp subdomain over both HTTP and HTTPS.

What is interesting in this case is that the first request, which says that the application is loading, has all data in plain text. The second request is sending across an “id”. But this ID is in fact simply a base64 encoded string of the very same data as that above. But we can tell it sends:

  • Application identifier
  • Country
  • Language
  • Application version
  • Device version
  • OS version
  • Mac Address (Unique identifier)
  • A timestamp
Openfeint is probably the biggest social networking component used by major games. It adds features such as leaderboards, friends lists, and such thing. It communicates over HTTPS, as you’d expect from any sort of application that communicates large amount of data about your device.

## ##
Doubleclick is your standard Google advertising platform. No sort of magic here. But for whatever reason, Google has opted to use HTTP here over HTTPS, which is very interesting.

It has a bit of seemingly hashed/encrypted content. And then a bunch of the normal content:

  • Language
  • Screen resolution
  • Device model
  • Application identifier
This one is a bit tricky. I was unable to easily locate a privacy policy for this service specifically. The domain it uses redirects directly to the Tap Tap Revenge Facebook page, which was the first game made by Tapulous. The company was acquired by Disney Interactive Studios in 2010, which explains why it is being used by a Disney application. But it communicates over HTTP, and is extremely verbose due to the use of POST forms rather than query-string parameters.

This tracks these values at specific events, much like Apsalar.

  • Method called
  • A signature
  • OS version
  • A token
  • Time stamp
  • Device version
  • API Key, but that seems to be a dummy one
  • Time Zone
  • Application version

Overview of iOS tracking traffic

When I started reviewing a few iOS applications for privacy concerns, such as the SpringPad application which used your email addresses without permission, I noticed that many applications would contact third-party sites with information about your device, often including a unique identifier. At the time I didn’t have much data to back it up. But I decided to undertake a small project to study this more in depth. Here was my game plan:

  1. Download top 6 applications in each category on the App Store
  2. Launch each application, click few to no buttons at all, and close down the application
  3. Analyze the requests made by the application
  4. Note down all requests that somehow appears to have information enough to track your device
  5. Study the results

With this in mind, I went to work. It was quite a boring task, since I did it all manually. But quite quickly I noticed some trends. And this is what I want to share with everybody, since I couldn’t find any previous research done like this.

The tl;dr
Here are some very quick stats:

  • I downloaded apps from 22 categories
  • I downloaded and executed a total of 115 applications
  • They contacted 128 different servers and sent data about your device
  • Each application contacted between 0 and 10 servers with data about your device
  • 85 of the servers were contacted over HTTP (67%)
  • 42 of the servers were contacted over HTTPS (33%)
  • The applications that tracks you the most is USA TODAY, which communications information about you to 10 servers
  • The most used service is used by 29 applications (25%) of the ones tested, second most used was observed from 11 applications (9.5%)

Here are the requests contained about your device:

  • Unique identifier
  • Mac Address
  • Local IP address
  • GPS Coordinates
  • Time zone/location
  • Device type
  • Device version
  • OS type
  • OS version
  • OS locale
  • Application identifier
  • Application version
  • Screen resolution and orientation
  • Radio type (Wifi or 3G)

My method for collecting this data involved using the proxy and target mapping function of Burp Pro. By installing a MITM certificate on my iPad, I can intercept most, if not all, of the traffic going out of the device over HTTP(S). I analyzed each request, and determined whether or not this request would track your device in any way, and added it to my Maltego document. I then saved the requests, cleared out Burp and went onto the next application.

The applications are the top 6 applications of each category from the iOS application store. I used the American app store for this, since it presumably has the biggest sample of users, and thus the top 6 applications would with the most likelihood be of interest to the most users. The applications had not been launched from the device before, so there were a lot of “first startup” requests observed.

The setup used can be replicated with the free version of the excellent tool Burp. Here are the steps I used:

  • Start up burp
  • Configure a browser (Example here being Firefox) to proxy through Burp, by default localhost on port 8080
  • Go to a HTTPS site through the configured browser, which should give you a SSL warning
  • Click “Add Exception”
  • Click “View”
  • Go to the “Details” tab
  • Click on the “PortSwigger CA” tree item in the Certificate Hierarchy
  • Click export
  • Save it as burp.cer
  • Using a command line, browse to where you saved the certificate.
  • Run python.exe -m SimpleHTTPServer
  • Now pick up your iDevice and browse to port 8000 on the machine used to extract the cert
  • You’ll now get a directory listing, pick out the cert you exported and download it
  • Now you’ll be taken to your System preferences, and can install the certificate. Job done

The big pictures

Breakdown by provider top 7 (Technical!)
Flurry comes in at the top of our list, with a total of 29 applications in our sample which uses this. Their site claims that (more than 190.000 applications use it)[]. It makes a lot of requests with a lot of data. For instance, it appears to be making a request at both startup and shutdown of an application. And there’s a lot of seemingly random information. This traffic takes place over plain HTTP without SSL.

There are a few trends that we can see.

  • A unique identifier is sent across, 38XEJT2XRT2I9H9BFB29. This is seemingly unique to the application
  • The version number of the application, in this case 1.0.6
  • A unique identifier of the device, de5381e09b10d93043b50f43153f3aeeb4dcc589
  • Another seemingly unique value to the device, ID1BDCEF03-F55E-439D-BA2A-C0AAC6B7BF6B
  • Screen height, width, OS version, device model, locale, time zone
  • Followed by what seems like some application-specific information


This request looks, much like Flurry, to be tracking of the device and events taking place from the application, such as startup. It sends this content over plain HTTP, and was used by 11 of the tested applications.

Between these 4 requests, we see a number of information being transmitted:

  • The resolution of the device
  • Device type, version and locale
  • Application version
  • The connectivity of the device (Wifi or 3G)
  • Number of times the application has been started
  • Name of the application
  • The event that triggered the request (Such as starting up)

Admob is a Google service, which is used to track downloads of an application. It does so by making requests with a MD5 hash of the unique identifier of the device, and the application ID. It communicates exclusively over HTTP, and was used by 9 applications tested.

This is done by this piece of code that Google provides.

Tapjoy is another run of the mill marketing network that has had a bit of a past. It appears to be also tied to a virtual currency, which can be obtained and used in applications using this service. It tracks the user on the application startup like most other services. The interesting thing to notice here is that one application is communicating with it across HTTP, while five are doing so over HTTPS.

From these two requests, we can see that it transmits:

  • A country code
  • Device type
  • Application ID
  • OS version
  • A library version
  • Language
  • Timestamp
  • Mac Address
  • Display multiplier
  • Application version
  • A verification value

2o7 is an “online marketing and web analytics business unit owned by Adobe Systems”. All communication takes place over HTTPS, and was used by 6 applications tested

These are the items that the request contains:

  • The local time
  • VID, an unique identifier
  • Device type and model
  • OS version
  • Locale
  • Day of the week
  • Time of week (In this case, weekend)
  • Screen orientation
  • Screen resolution

ChartBoost is a system for cross-promoting applications, used by 5 of the tested applications. They are basically another marketing network. They make a request on first start over HTTPS, which looks like:

The interesting thing is that some of the applications sent across an “identity” value. I’ve yet to trace down what that value exactly means yet however.

  • OS Version
  • Unique identifier
  • An identity
  • Application ID
  • A signature of some sort
  • Country
  • Application version
  • Device language
  • Device model

Medialytics is a “rich media ad platform for mobile”. It communicates solely over HTTP, and was used by 5 of the tested applications.

The interesting thing is that it contains parameters for latitude and longitude, as well as mcc, mnc, and c which were empty during my testing. My iPad does not have GPS, which is most likely why this information was missing.

  • An application ID
  • Application version
  • Device type
  • OS version
  • Unique identifier
  • Latitude and Longitude
  • Screen resolution

Crittercism is a telemetry platform for tracking crashes and performance metrics. It is used by 5 applications which was tested and communicates over HTTPS.

From the looks of things, it collects:

  • Device model
  • OS version
  • Application version
  • Timestamp
  • OS Type
  • Locale
  • Device type
  • If the application was pirated or not
  • If the application was allowed remote notifications
  • A unique ID of some sort
  • Device name
  • Application ID
  • A key
  • Library version
  • Whether or not the request was sent through an application launch

Dissecting traffic from SpringPad for iOS

My research over the last couple of months has focused on the security ghetto of WordPress plugins. But recently @arnimarhardar turned me to the subject of mobile applications. As they often use HTTP, I felt right at home. I decided to download a few random applications onto my iPad and then go to town. I personally use my iPhone on a daily basis, so what I’m about to describe to you was quite the eye-opener for me in terms of what sort of data is sent about you to third-parties and such. Let me present to you, an extremely popular application: SpringPad.

Note: I’ve masked out parts of requests since they may contain unique identifiers and such things.

Dissecting Springpad
Armed with my recently acquired copy of Burp Pro, I booted up the application for the very first time. I was greeted with an authentication screen, asking me to sign up. Already at this point, Springpad has contacted a number of very interesting domains. There’s a few calls to Twitter and Facebook and such, but I’ve left those out since they offer no insights into what Springpad does.


Of these 4 requests, only one of them is actually related to the application at all. That seemed very odd to me. So let’s look at what they did in order listed.

Third-party requests

RedLaser is a “RedLaser is a free shopping app for iPhone, Windows Phones, and Android that has been downloaded over 19 million times.”. Ok, interesting. How that is used by a note-taking application is a mystery to me. But from what we can tell from the request, is that they sent the name of the application making the request, an unique identifier, the platform, hardware versions, sdk version, the build number, locale, application version and OS version. Of course, sending across an unique identifier is a bit questionable, given that I as an end-user have no idea what redlaser is, but let’s move on!

This one is fun, because it seems to be sending across an actual data-structure, null-byte padding and everything. But it’s sending across a couple of (unique) identifiers, resolution, model, and version information. That’s nice. Not only does there seem to be one piece of identifying information in this request like to redlaser, there’s several.

Before getting into the actual request to springpad, we need a last stop over to!

The third request to a third party consists of a lot of fun information, such as country, device type, carrier name, language, iOS version, and your devices’ mac address.

Springpad requests
And now, for the main course, Springpad. Let’s see what it’s got in store for us!

This is the first request it makes, and the very first thing that greeted me was that this communication didn’t go over HTTPS, which is a concern. But onto the request, we see some OAuth fun, and then a device identifier, which is again your mac address. Ok, not the biggest of deals, let’s now sign up!

At this point, we post our credentials to the site(Over HTTP, mind you. Ooops) with the addition of a sessionID in our cookie. Again we see the transmission of your mac address.

Hold on a minute, what is that being sent across the wire? At this point, all I’ve clicked on is for me to sign up and just finish registration. I’ve not been requested to submit all of my contacts which are stored in my iOS contact list. Huh, that’s odd! I thought maybe I missed something, so I checked again. Nope, I’m not asked if I want to upload this.

Note that these emails were a part of the HTTP request

The fine-print part of the story
So let’s go consult our privacy policy as for what information the application will automatically upload from me:

Oh, how odd. Not a word about contacts! This isn’t really what I’d expect. There’s another bit of the privacy policy which states:

Thinking that I could now log into their web-site and see which information they have obtained from me, I logged in and started reviewing it. To my surprise, not a single mention of contacts was to be found. This is starting to smell. So let’s consult the iOS Application Guidelines as put forward by Apple:

I am no lawyer, but I don’t see that this application should have, as per Apples application guidelines, taken this information from my device without permission.

Does this remind anybody else about Path?

Response from vendor
When I contacted Springpad about my concerns in regards to the lack of HTTPS and their use of contact information, they were very prompt in a reply to my concerns, specifically in regards to the lack of HTTPS and the use of contact informations. They explained that the lack of HTTPS was a result of a bug in the build process. A fix for this was being fast-tracked for submission to Apple by the end of the day.

They acknowledged that the application uploaded the emails from the contact book of the device. They noted that the data wasn’t stored, only kept in memory to see if anybody you know uses SpringPad as well. They plan to request for explicit permission in version 3.0.7, which at the time of writing is being tested by their QA.

Overall, they were extremely quick to reply and addressed my concerns quite well, despite having a bad time all at the same time.