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.
CLARIFICATION
This 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.
DISCLAIMER
We 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.

HACKING INGRESS – ANDROID APPLICATION REVERSE ENGINEERING
INTRODUCTION
Ingress 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 PREPARATION
EXTRACT THE PACKAGE
Before 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
www.eForensicsMag.com 13

14
FIREFOX ADD-ONS::HTTPREQUESTER
This 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 SUITE
Burp 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 ANALYSIS
OBJECTIVES
• 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 SIGNAL
MOCK LOCATIONS PREVENTION
Mock 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” PREVENTION
In 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-ingresssmalicomnianticprojectingressNemesisActivity.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
SIGNALS
Remove 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-ingresssmalicomnianticprojectingresscommonscannerk.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 MORE
Because 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-ingresssmalicomnianticprojectingresscommonitemupgradea.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 ANALYSIS
OBJECTIVES
• 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 PROXY
LAUNCH BURP SUITE
In 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.
NOTE
If 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 CERTIFICATE
Export 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 DEVICE
Once 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 INGRESS
When 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
VERIFICATION
The 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/json
Accept-Encoding – gzip
User-Agent – Nemesis (gzip)
Cookie – the session cookie of the user
X-XsrfToken – the users token
Host – 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 AUTHENTICATION
Following 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-urlencoded
User-Agent – AndroidC2DM/1.1 (ja3g JDQ39)
Host – 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::GLOBALREGIONMAP
The 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::GETINVITEINFO
The 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::GETINVITEINFO
The ‘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/json
Content-Encoding – gzip

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”:”MEE9cey2ssygjADvD5jeeuS0pqnwAqSrmFapvy4ZwZzUKlBqHF4fnZiCqmO8
aJ51IXG7m8jsomWlecgeAH7mx MLqQJOUDsQ29z/ +kW+/upF7nY3yEUQZseYCfDKHhj95P9c77LslYt5K8tlRjvIr4g0TLKSqJ0G
VGgYWy2WU0pZNSCAES2JIJSWaE6Tss43v3G1fQ9cRahmAwEyCqrdpOlFRq4y4v0Y2nIKy3j0GnIlhSMDC4rBkTPan/OJ9AoXzeifv
+g9Qi6uR/107UW9IXWMAoN46NXp4wtKrpU19AhiynyBD9uP2csbQWd0YezcomQtW/NsmrBDlJO5YuGIjFDfnjmJ83 +Eqs1zW/P93y
3mvGC +hL2fkWX6SuNpAaKm2yNs4Dh8xsAJcZWJsesX3E +6TbHpbMV7q+eFqInVW9pK6bllorMug9poIfZ6FdkHhGR5PuAqYlhOw
R4+94idOMpbC70ZD+kh82X+5y0SdrS7LeQEozYSTp +WXy2b6lQmuIfEtX0eHGBzeC5ZDk5gc8Tp6MM/EbCQGFZ4CFcMLVLguuPue
1ZONmIBN3HUn2sUK1uYxEBXdUSVqHFmN1hVFHQ3FSQsUQojw8veNvvSDjj0YSJrsGcy +kvtfsqy1sEG5+fKyWx0PNMfF75eT75yn
ZUIAOD8WFwrflRYRGy9gCHU”},”energyGlobGuids”:[],”itemGuid”:”0ac46f4c69c8b993b1e5784838ff.12”,
”knobSyncTimestamp”:1394236374863,”playerLocation”:”0f40a9b7,d834d4ff”}}
RESPONSE::COLLECTSITEMSFROMPORTAL
The 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 SERVER
MODIFYING THE REQUEST::COLLECTSITEMSFROMPORTAL DATA
To 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 POC
CyberWarrior 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
SUMMARY
In 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 Author
Eran 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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (17)

En vedette

En vedette (10)

Similaire à Hacking ingress

Similaire à Hacking ingress (20)

Dernier

Dernier (20)

Hacking ingress