hacking ingress

12

HACKING INGRESS – ANDROID APPLICATION REVERSE ENGINEERING

by Eran Goldstein

Today we are going to demonstrate a quick reverse engineering and analysis process of an android mobile application called Ingress. Ingress is a near-real time augmented reality massively multiplayer online video game. It was created by Niantic Labs, a startup within Google, for the Android based devices market. The game has a complex science fiction back story which Niantic is revealing in segments.

The gameplay consists of establishing “portals” at places of public art, etc., and linking them to create virtual triangular fields over geographic areas. The progress in the game is measured by the number of Mind

Units, i.e. people, nominally controlled by each faction (as illustrated on the Intel Map). The necessary links between portals may range from meters to kilometers, or to hundreds of kilometers in operations of considerable logisti-cal complexity.

International links and fields are not uncommon, as Ingress has attracted an enthusiastic following in cities worldwide amongst both young and old, to the extent that the gameplay is itself a lifestyle for some, including tattoos.

CLARIFICATIONThis analysis started from the point of view of the frustrated Ingress players which invest their time and effort to play legally the Ingress game. The analy-sis purpose was to explain and demonstrate that while there are Ingress us-ers that play fair and legal there are some who do not.

We under do not encourage any misuse or illegal use of the Niantic Project – Ingress game or any other games/platforms. The user ‘Hatulero’ which was used during this analysis was for demonstration purpose only and has been canceled with the end of this analysis.

DISCLAIMERWe are going to analyze and implement modifications to the Niantic project – ingress application for research purposes only, by using, opening and/or reading this document you agree that your use of the Niantic project – ingress application products and/or this cyber security research documentation, in-cluding any changes you will implement in your own code will be on your own risk only. For more information please refer to Niantic project – ingress terms of use: http://www.ingress.com/terms.

What you will learn:• Analyzing and debugging pro-

cesses of an android application and examining the code within the .apk package.

• Inspecting how important func-tions operates.

• Modify and manipulate the way functions work.

• How android application commu-nicates with the web services API.

• Exploit application design weak-nesses.

What you should know:• Extracting, packing and signing

processes of an android applica-tion package (.apk).

• Mobile reverse engineering pro-cess basics.

• Web application analysis tech-niques.

www.eForensicsMag.com 13


INTRODUCTIONIngress involves near-real time augmented reality by the need to take control over portals by physically move between them which means that the ingress players’ community will have to go around cities, plac-es and sites in attempt to gain more power (XM’s), “hack”, take control or even attack Ingress portals. One of the biggest advantages every Ingress user will probably want to achieve is the ability to move be-tween portals without changing your actual physical location. This analysis document assumes that you are familiar with the process of reverse engineering process of an android mobile application and already know how to extract, sign and pack back the content of an android application package (.apk)

The security analysis will include the following sections:

• Reverse Engineering – Environment preparation• Ingress Android application – binary code analysis• Ingress web services API – server side analysis• Hacking POC

REVERSE ENGINEERING – ENVIRONMENT PREPARATIONEXTRACT THE PACKAGEBefore we begin we will need to extract/dump the content of the .apk file. You can do that using apktool or any other tool you like. Once you extract the .apk file, you will get something like:

Figure 1. Extract the package

DOWNLOAD AND INSTALL “FAKEGPS”As a part of the process you will probably want to download and install any fake GPS location app in or-der to be able to generate mock GPS location signals. You can download from “Google Play” any app you want such “Fake GPS”, “MoveMyGPS” or any other app you like:

Figure 2. MoveMyGPS

14

FIREFOX ADD-ONS::HTTPREQUESTERThis tool is useful when doing web or REST development, or when you need to make HTTP requests that are not easily done via the browser (PUT/POST/DELETE).

This is based on the Alex Milowski’s excellent Poster add-on, with a large focus on keeping a history of transactions, allowing you to go back and review, re-execute, load, and save HTTP requests.

HttpRequester can be opened via the Tools menu, or via the Add-on-bar icon.

https://addons.mozilla.org/en-us/firefox/addon/httprequester/

Figure 3. HttpRequester plugin tool

PORTSWIGGER::BURP SUITEBurp Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application’s attack surface, through to finding and exploiting security vulnerabilities.

Burp gives you full control, letting you combine advanced manual techniques with state-of-the-art au-tomation, all in order to make your work more effective, fast and fun than before.

You can download Burp suite here: http://portswigger.net/burp/downloadfree.html.

Figure 4. PortSwigger – Burp Suite web proxy analyzer



INGRESS ANDROID APPLICATION – BINARY CODE ANALYSISOBJECTIVES

• Disable the detection of mock locations in order to use fake GPS location signal.• Merge the fake and real GPS location signals and remove the “Scanner Disabled; Inaccurate Loca-

tion;” message.• Remove the protection flag for common actions and allow Hack Portal, Fire XMP, Deploy Resona-

tors and more.

OBJECTIVE ONE: DISABLE THE DETECTION OF MOCK LOCATION IN ORDER TO USE FAKE GPS LOCATION SIGNALMOCK LOCATIONS PREVENTIONMock location – developer’s option allows developers to use any fake GPS signal in order to be able to change their GPS signal while developing and debug applications. Once you will open any fake GPS loca-tion app, you will probably be asked to enable this option in the System Setting -> developer options menu.

From this point on you basically can set your location to any location you want but the problem is that “Ingress” will not allow you to use the “Allow mock locations” option L.

And this is the point where we will start our analysis.

Figure 5. Allow mock locations Figure 6. Mock locations disallowed

DISABLE THE “ALLOW MOCK LOCATIONS” PREVENTIONIn attempt to toggle the validation of the “Allow mock locations” developer option checkbox we will need to search for relevant point to start our analysis.

As in every reverse engineering process, searching for any of suspicious or problematic string you want to investigate or hack can assist you to find relevant event triggers which can lead to the point you probably looking for and will want to modify.

Let’s take a look at the following file:

16

\dump-ingress\smali\com\nianticproject\ingress\NemesisActivity.smali

At line 1426 we can observe the “mock_location” string and right after it we can see the function that put integer “0” in a register, check if the “allow mock locations” checkbox is checked (this will return “1”) and then compare the registers values and validate that v0 register value is not equal to zero, and then go to a condition (cond_b) which will block us from using Ingress while the “Allow mock locations” option is enable:

if- nez v0, :cond_b

And will set a prevention flag by moving register v7 to register v0:

move v0, v7

So as you probably guessed, we basically can do a few simple tricks here to manipulate the function that checks for the “Allow mock locations” checkbox status. First, let’s modify the function to check that the checkbox value is equal to zero (instead of not equals to zero), this will cause ingress to allow you to play only if “Allow mock locations” option is enabled.

Since we don’t want any further actions to be performed once the condition is true, we will move the pointer from ‘cond_b’ to ‘cond_3’ which originally is the pointer that continue the scanner process with-out interruptions.

From:

if- nez v0, :cond_b

To:

if-eqz v0, :cond_3

To make sure the prevention flag will not be set as true (by moving register v7 to register v0), we will comment the line below (Line 1428):

From:

move v0, v7

To:

# move v0, v7

Figure 7. Line 1426::change the term below from if-nez to if-eqz and from cond_b to cond_3

Now we can use “FakeGPS” to set our location dynamically but the “Scanner disabled; Location inac-curate.” Message appears.



Figure 8. Scanner disabled message

OBJECTIVE TWO: MERGE THE FAKE AND REAL GPS LOCATION SIGNALSRemove the “Scanner Disabled; Inaccurate Location;” message.

Once we “hacked” the “Allow mock locations” developer options to al-low us use fake GPS location (e.g. mock_location), we will cause the scanner state process to change the value of the relevant flag/register to ”1” (register v0 in our case), which will cause the Ingress app to alert the message “Scanner disabled; Location inaccurate.”


\dump-ingress\smali\com\nianticproject\ingress\common\scanner\k.smali

To disable the alert message, we will need to modify the condition at line 996 that check if the value in v0 resister is not equals to zero (‘0’) from if-nez to if-eqz:

From:

if-nez v0, :cond_4

To:

if-eqz v0, :cond_4

Figure 9. Line 996::change the term below from if-nez to if-eqz

As we can see the “Scanner disabled; Location inaccurate.” Alert message is disabled but we can’t per-form any relevant actions on the portal (even if it in our range).

18

Figure 10. Alert message is disabled Figure 11. Actions are unavailable

OBJECTIVE THREE: REMOVE THE PROTECTION FLAG FOR COMMON ACTIONS ALLOW HACK PORTAL, FIRE XMP, DEPLOY RESONATORS AND MOREBecause the scanner state has been changed from a real GPS location signal into a FakeGPS location signal and the Ingress app detects this as “Inaccurate location” event we can’t perform any relevant ac-tions on the portal (even if it is in our range).

Next we will need to modify the condition of the function that checks for the scanner state value.


\dump-ingress\smali\com\nianticproject\ingress\common\itemupgrade\a.smali

In line 2095 we can observe the function that check if the value in v0 register is less or equals to zero (‘0’) and if it is the Ingress app will alert the message “Location Inaccurate” when you will press any ac-tion button (example: “Hack”, “Deploy Status”, etc…).

Locate the “if-lez v0, :cond_0” (Line 2095) and change the condition from if-lez to if-eqz:

From:

if- lez v0, :cond_0

To:

if-gtz v0, :cond_0



Figure 12. Modifying the function’s operand

Congratulations!!! Now we can move to any location we want using FakeGPS or any other Fake GPS location signal application. Let’s start with San Jose – United States:

Figure 13. Moving to San Jose – U.S Figure 14. All action options are available

20

Figure 15. Collecting XM Figure 16. Hacking the portal

Now let’s move to Paris:

Figure 17. Moving to Paris t All action options are available



Or to Spain:

Figure 19. Moving to Spain Figure 20. All action options are available

INGRESS WEB SERVICES API – SERVER SIDE ANALYSISOBJECTIVES

• Configuring an Android device with Web-Based proxy.• Intercept, decode and explore common Ingress https requests.• Modify an Ingress https request and communicate with the server.

OBJECTIVE ONE: CONFIGURING AN ANDROID DEVICE WITH WEB-BASED PROXYLAUNCH BURP SUITEIn order to begin we will need to start burp and configure it to listen to specific port:

Figure 21. Configuring Burp Suite to listen on specific address and port

By default, when you browse an HTTPS website via Burp, the Proxy generates an SSL certificate for each host, signed by its own Certificate Authority (CA) certificate. This CA certificate is generated the first

22

time Burp will run and will be stored locally. To use Burp Proxy most effectively with HTTPS websites, you will need to install Burp’s CA certificate as a trusted root in your browser.

NOTEIf you install a trusted root certificate in your browser, then an attacker who has the private key for that certificate may be able to man-in-the-middle your SSL connections without obvious detection, even when you are not using an intercepting proxy. To protect against this, Burp generates a unique CA certificate for each installation, and the private key for this certificate is stored on your computer, in a user-specific location. If untrusted people can read local data on your computer, you may not wish to install Burp’s CA certificate.

INSTALLING THE CERTIFICATEExport Burp CA certificate and save to your local computer using .crt extension (e.g. PortSwiggerCA.crt)

• Push the “PortSwiggerCA.crt” certificate to a microSD card on your android device.• Go to: System Setting -> More tab -> Security ->install from device storage. • Follow the on screen instructions, and reboot the device once it says the certificate has been in-

stalled.

CONFIGURE THE DEVICEOnce we have configured Burp we will need to configure our Android device to use burp for external con-nections. To do this:

• Go to: Settings -> Connections -> Wi-Fi • Long press on the network connection you want to configure.• Select “Modify network config” from the menu.• Check the “Show advanced options”, click the “Proxy settings” combo box and select “Manual”. • Configure Burp suite machine address and port.

If everything works correctly you now should have a trusted certificate installed successfully on an an-droid device!

From this point you basically can intercept and explore any Ingress android app – http and https re-quests using burp. And this is the point where we will start our analysis.

LAUNCHING INGRESSWhen launching Ingress on your device and while watching burp history tab, you can observe the data and traffic between your device and the web-services API server. This data includes a few general in-gress application important processes such as authentication, verification, synchronization and more. The data also includes basic functions results such actions and events. In the next objectives we will ex-plore few Ingress android application common requests.

OBJECTIVE TWO: INTERCEPT, DECODE AND EXPLORE COMMON INGRESS HTTPS REQUESTS VERIFICATIONThe first process and requested data we will explore is the verification step. The Ingress app send an HTTPS GET request to the server in attempt to verify the user’s account. In the image below we can ob-serve the verification GET request and navigates to: m-dot-betaspike.appspot.com/handshake.



Figure 22. Verification GET request

The request contains few headers includes:

Content-Type – the content type of the request is application/jsonAccept-Encoding – gzipUser-Agent – Nemesis (gzip)Cookie – the session cookie of the userX-XsrfToken – the users tokenHost – m-dot-betaspike.appspot.com

In addition, json URL variable contains json data with information about the google user.

We can observe that the authentication step will be probably be completed by SSL handshake process.

GOOGLE AUTHENTICATIONFollowing the verification step we can observe that the Ingress app send another HTTPS POST request to google in order to authenticate the user’s account. In the image below we can observe the authentica-tion POST request which done during SSL handshake process. The first request navigates to: android.clients.google.com.

Figure 23. HTTPS POST request to google

24


Authorization – the user’s authentication challenge token.Content-Type – the content type of the request is application/x-www-form-urlencodedUser-Agent – AndroidC2DM/1.1 (ja3g JDQ39)X-XsrfToken – the users tokenHost – android.clients.google.com

The request’s data includes few parameters send to the application server:

‘X-GOOG.USER_AID’, ‘app’, ‘sender’, ‘cert’, ‘device’ and ‘device_user_id’

As a result from the last request contains the challenge token we will get the authentication response to-ken in the response HTTPS body.

Figure 24. The authentication response token

Using the authentication response token, the Ingress app generates the authentication token in order to authorize the user’s device account and the second request navigates to: play.googleapis.com

Figure 25. Ingress app generates the authentication token

The request contains few headers and the requests body contains data with information about the google user.

In the last request of the login process, Ingress app send HTTPS POST request to Ingress application server with the same token.



Figure 26. The last request of the login process

REQUEST::GLOBALREGIONMAPThe next request in the process of launching Ingress app is the globalRegionMap. In the image below we can observe the globalRegionMap HTTPS GET request which navigates to: m-dot-betaspike.appspot.com

Figure 27. The globalRegionMap HTTPS GET request

The request contains a few headers includes:


26

REQUEST::GETINVITEINFOThe last request in the process of launching Ingress app is the ‘getInviteInfo’ which will check how many agent’s invitation lefts to the user. In the image below we can observe the ‘getInviteInfo’ POST request which navigates to:

m-dot-betaspike.appspot.com/rpc/playerUndecorated/getInviteInfo

Figure 28. ’getInviteInfo’ https POST request



In addition, the body contains json data with an empty “params” array.

RESPONSE::GETINVITEINFOThe ‘getInviteInfo’ response contains https headers sent from the server back to the client and includes a json string with two arrays as well:

Figure 29. ‘getInviteInfo’ https response

‘result’ array: General array that contains information about the ‘numAvailableInvites’ remain to the user.

‘gameBasket’ array: General array that contains information about the user’s inventory, game entities and more (‘gameEntities’, ‘inventory’ and ‘deletedEntityGuids’). We will be able to observe this array po-tently in few other common requests.



REQUEST::GETINVENTORY

Figure 30. Ingress OPS button

In order to synchronize the user’s inventory database the Ingress app sends ‘getInventory’ request to the server. In the image below we can observe the HTTPS POST request which navigates to:

m-dot-betaspike.appspot.com/rpc/playerUndecorated/getInventory

Figure 31. ‘getInventory’ https POST request



In addition, the body contains json data with “params” array and ‘lastQueryTimeStemp’ parameter.

28

RESPONSE::GETINVENTORY

Figure 32. ’getInventory’ https response

The response contains https headers sent from the server back to the client and includes a json string with two arrays as well:

Result array: General array that contains the value to update the ‘lastQueryTimeStemp’ parameter that will be used for the next request.

gameBasket array: General array that contains information about the user’s inventory, game entities and more (gameEntities, inventory and deletedEntityGuids). This time we can observe the items that the user store in his inventory. We will be able to observe this array potentially in few other common request as well.

As a result the user’s inventory will be available to the user.

Figure 33. Ingress OPS – Inventory screen



REQUEST:: COLLECTSITEMSFROMPORTAL

Figure 34. Portal’s details view screen

Behind the scene, when the user click the “HACK portal” button, Ingress app sends ‘collectsItemsFromPor-tal’ request to the server. In the image below we can observe the POST request which navigates to:

m-dot-betaspike.appspot.com/rpc/gameplay/collectsItemsFromPortal

Figure 35. ‘collectsItemsFromPortal’ https request


Content-Type – the content type of the request is this case is application/jsonAccept-Encoding – gzipUser-Agent – Nemesis (gzip)Cookie – the session cookie of the userX-XsrfToken – the users tokenContent-Encoding – gzipHost – m-dot-betaspike.appspot.com

30

In addition, the body contains json gzipped data that we will have to decode. To do that we will use the built-in burp’s decoder tool:

• Select the data you want to decode from the request data below• Right-click and select “send to decoder”.

Figure 36. ‘collectsItemsFromPortal’ request – send to decoder

Now move to the “Decoder” tab in burp, and in the combo box “Decode as…” on the right, select “Gzip”:

Figure 37. ‘collectsItemsFromPortal’ request – send to decoder – decode as gzip

We can see the result data of the gzip decode process below to the encoded data:

Figure 38. ‘collectsItemsFromPortal’ request – send to decoder – decode as gzip – result

Now we can see in clear text that the body contains json gzipped data with a ‘clientBasket’ array in a “params” array. The ‘clientBasket’ array include the following parameters:

‘clientBlob’ – the client blob’s data.‘energyGlobGuids’ – with an empty value.‘itemGuid’ – the portal ‘itemGuid’ the user want to “hack”.‘playerLocation’ – the geolocation data of the user in a hexadecimal “altitude, longitude” format.



EXAMPLE REQUEST BODY DATA

{“params”:{“clientBasket”:{“clientBlob”:”MEE9cey2ssygjADvD5jeeuS0pqnwAqSrmFapvy4ZwZzUKlBqHF4fnZiCqmO8aJ51IXG7m8jsomWlecgeAH7mx MLqQJOUDsQ29z/ +kW+/upF7nY3yEUQZseYCfDKHhj95P9c77LslYt5K8tlRjvIr4g0TLKSqJ0GVGgYWy2WU0pZNSCAES2JIJSWaE6Tss43v3G1fQ9cRahmAwEyCqrdpOlFRq4y4v0Y2nIKy3j0GnIlhSMDC4rBkTPan/OJ9AoXzeifv+g9Qi6uR/107UW9IXWMAoN46NXp4wtKrpU19AhiynyBD9uP2csbQWd0YezcomQtW/NsmrBDlJO5YuGIjFDfnjmJ83 +Eqs1zW/P93y3mvGC +hL2fkWX6SuNpAaKm2yNs4Dh8xsAJcZWJsesX3E +6TbHpbMV7q+eFqInVW9pK6bllorMug9poIfZ6FdkHhGR5PuAqYlhOwR4+94idOMpbC70ZD+kh82X+5y0SdrS7LeQEozYSTp +WXy2b6lQmuIfEtX0eHGBzeC5ZDk5gc8Tp6MM/EbCQGFZ4CFcMLVLguuPue1ZONmIBN3HUn2sUK1uYxEBXdUSVqHFmN1hVFHQ3FSQsUQojw8veNvvSDjj0YSJrsGcy +kvtfsqy1sEG5+fKyWx0PNMfF75eT75ynZUIAOD8WFwrflRYRGy9gCHU”},”energyGlobGuids”:[],”itemGuid”:”0ac46f4c69c8b993b1e5784838ff.12”,”knobSyncTimestamp”:1394236374863,”playerLocation”:”0f40a9b7,d834d4ff”}}

RESPONSE::COLLECTSITEMSFROMPORTALThe result of the “HACK portal” action should get the user’s inventory new items. In the image below we can observe that the items data return in a HTTP response message body.

Figure 39. ‘collectsItemsFromPortal’ response

In our case the “HACK portal” action didn’t return any items but if we explore the HTTP response, we will see that it contains https headers sent from the server back to the client and includes a json string as body, with two arrays as well:

‘result’ array: General array that generally contains the value to update the ‘lastQueryTimeStemp’ pa-rameter that will be used for the next request but in the case of ‘collectsItemsFromPortal’ request re-mains empty.

‘gameBasket’ array: General array that contains information about the user’s inventory, game entities and more (gameEntities, inventory and deletedEntityGuids). This time we can observe the items the us-ers hacked from the portal. We will be able to observe this array potently in few other common request as well.

This response also sync the user’s inventory with the new items that were collected. This means that in case the user wants to hack the game and to add more items to his inventory by hacking the HTTP response body, it will be useless, since the fake items are not generated on the application server and do not exist on the application server’s database.

But as you probably can guess, by modifying the request data that we send to the server we can fake the user’s geo-location and to hack any remote portal we want. This will bring a full items inventory to the user. Let’s try to see how it works.

To modify the request or response data, you can use Burp suite’s repeater module. By clicking on the “Repeater” tab (in Burp Suite).

However, In order to get rid from the process of decoding and encoding the request data in your tests, we will discover another simple but useful tool.

OBJECTIVE THREE: MODIFY AN INGRESS HTTPS REQUEST AND COMMUNICATE WITH THE SERVERMODIFYING THE REQUEST::COLLECTSITEMSFROMPORTAL DATATo modify the request and to avoid from the process of encoding and decoding the data in every request in our analysis we will use the Firefox Add-ons ‘HttpRequester’.

32

To read more about the Firefox Add-ons ‘HttpRequester’ refer to the “Reverse Engineering – Environ-ment preparation” section.

Let’s modify the collectsItemsFromPortal HTTPS request data, to do this:

• Open HttpRequester Add-on via the Tools menu, or via the Add-on-bar icon.• In the URL text input, write the full request path (for example: “m-dot-betaspike.appspot.com/rpc/

gameplay/collectsItemsFromPortal”).• Click on the “Headers” tab and add all the request’s HTTPS Headers by ‘Name’ and ‘Value’ (see the

example in the image below).• OPTIONAL: modify the “Cookie” and “X-XsrfToken” values (in order to collect and add the items

from the portal to other user J account).

Figure 40. Adding the HTTPS headers

• Click on the “Content to Send” tab. In the “Content Type:” text input write: “gzip”• Copy the ‘collectsItemsFromPortal’ request body (the one we decoded earlier – Example request

body data) and paste it to the “Content” text area in ‘HttpRequester’ (see the example in the image below).

• OPTIONAL: modify the “player location” values (remember to convert the longitude and altitude val-ues from hexadecimal to decimal format)

• Click “Submit” button.

Figure 41. Modifying request body data, setting the “Content-Type” as gzip and click “Submit”



Figure 42. Paste the request body data and click “Submit” button

CONGRATULATIONS!!! In the image below we can observe the server response. It is seems that we’ve successfully collected new items from the portal by hacking the portal remotely.

Figure 43. Successfully collected new items from the portal

Which means that by intercepting and collecting more “HACK portal” actions requests from our device, we will able to hack portals remotely using any device (PC, Smart phone, Tablet, etc…) in the future.

CYBERWARRIOR | INGRESS HACKING POCCyberWarrior developed by 0xICF as proof of concept (POC) in order to demonstrate the results of auto-mated vulnerabilities exploitation of the threats and security breaches that were found during the security analysis of Google, Niantic Project – Ingress app.

Google, Niantic Project – Ingress game involve near-real time augmented reality by the need to take control over portals (real-locations) by physically moving between them which means Ingress players community will have to go around cities, places and sites in attempt to gain more power (XM’s), “hack”, take control or even attack Ingress portals.

34

Naturally, Ingress players must be physically near objects on the map to interact with them. The mobile client represents the player as a small arrow in the center of a 40-meter oval which represents the perim-eter within which direct interaction is possible.

By simply configure any Ingress player id and token, CyberWarrior allows the Ingress player to play remotely and to perform different actions in the game includes:

• Hacking portals• Attack portals• Create portals links• Create control fields• Recharge XM’s• Collect and use portal keys• And more…

Figure 44. CyberWarrior – Dashboard view

HOW CYBERWARRIOR WORKS?At the beginning of this analysis we discovered how it is possible to manipulate the scanner module of Ingress app to allow mock locations (e.g. fake GPS location signals). By exploiting this weakness, Cy-berWarrior is able to travel between portals and to collect relevant portals data remotely.

Figure 45. CyberWarrior – Portals view

CyberWarrior uses that data further to perform different actions. In the “Events” view below we can see how CyberWarrior reports about every action performed on behalf of the Ingress player.



Figure 46. CyberWarrior – Events view

SUMMARYIn this article we discovered a few weakness in the android application binary code and the web services API of Google – Niantic Project, Ingress. As we learned, the Ingress game logic suffers from multiple vul-nerability and weaknesses that allows the attacker (or in our case the cheater) to hack the Ingress game rules easily and conduct automated actions to manipulate and influence other’s experience.

It is important to mention that other vulnerabilities that were found during the analysis and related to the Google location services were not reported in this document but may influence other Googles android applications.

However, we do not encourage any misuse or illegal use of Google, Niantic Project – Ingress game (even in winter) or any other games.

It is important to remember that while a cheater is destroying other Ingress player’s portals, links and fields, he will cause to others to go out from their homes or from any other cushy place in order to fight back.

The user ‘Hatulero’ that was used during this analysis is for demonstration purpose only and has been deleted with the end of this analysis.

Hope you enjoyed reading this article, see you next time.

About the AuthorEran Goldstein is a Senior Cyber Security Researcher at Samsung Electronics and the founder of Frogteam|Security, a cyber security vendor company in USA and Israel. He is also the creator and devel-oper of “Total Cyber Security – TCS” product line.Eran Goldstein is a senior cyber security expert and a software developer with over 10 years of experience. He specializes at penetration testing, reverse engineering, code reviews and application vulnerability as-sessments.Eran has a vast experience in leading and tutoring courses in application security, software analysis and se-cure development as EC-Council Instructor (C|EI). For more information about Eran and his company you may go to: http://www.frogteam-security.com

hacking ingress

Technology

ingress user

android application

niantic project ingress

attack ingress portals

analysis document

ingress players community

android applicationand

clarificationthis analysis