The document discusses reverse engineering the Android application Ingress in order to modify its functionality. It describes extracting the application code from the APK file. The analysis aims to disable detection of mock locations, allowing fake GPS signals to be used. It also aims to remove the "Scanner Disabled" message that appears when using fake GPS. The analysis identifies specific code sections to modify to achieve these goals.
Connector Corner: Automate dynamic content and events by pushing a button
Â
Hacking ingress
1. 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.
2. 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
3. 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
4. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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:
www.eForensicsMag.com 15
5. 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.
6. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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.â
Letâs take a look at the following file:
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).
www.eForensicsMag.com 17
7. 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.
Letâs take a look at the following file:
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
8. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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
www.eForensicsMag.com 19
9. 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
10. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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
www.eForensicsMag.com 21
11. 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.
12. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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
www.eForensicsMag.com 23
13. 24
The request contains few headers includes:
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)
X-XsrfToken â the users token
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.
14. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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:
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
www.eForensicsMag.com 25
15. 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
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, 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.
16. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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
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, the body contains json data with âparamsâ array and âlastQueryTimeStempâ parameter.
www.eForensicsMag.com 27
17. 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
18. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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
The request contains few headers includes:
Content-Type â the content type of the request is this case is application/json
Accept-Encoding â gzip
User-Agent â Nemesis (gzip)
Cookie â the session cookie of the user
X-XsrfToken â the users token
Content-Encoding â gzip
Host â m-dot-betaspike.appspot.com
www.eForensicsMag.com 29
19. 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.
20. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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â.
www.eForensicsMag.com 31
21. 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â
22. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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.
www.eForensicsMag.com 33
23. 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.
24. HACKING INGRESS â ANDROID APPLICATION REVERSE ENGINEERING
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
www.eForensicsMag.com 35