Intercepting AndroidIntercept applications in newer Android phones
By Jonathan Armas | October 23, 2019
Android is an operating system
based on the
Linux kernel and used by mobile devices
such as smartphones and tablets.
Due to its popularity, it is the major target for hackers.
One of their common techniques is to intercept
and try to break an app’s web traffic
using attack methods like fuzzing and brute force.
Mobile applications usually share the same communication structure as web applications, meaning that we can intercept requests by using a proxy. If an application is using a secure channel like HTTPS, we are going to have to install a digital certificate into the phone in order to make it accept our proxied requests.
Since Android 7 Nougat (API >= 24)
we can no longer use the simple method of setting our proxy
and the certificate to capture
Burpsuite page explains here.
If we try this method,
we will receive thousands of certificate failures from our proxy.
This is because the Android operating system
no longer trusts certificates installed by the user.
To solve this we need to have a rooted
then create and sign a digital certificate,
and finally put it in the system’s certificate folder in our phone.
In order to intercept the application’s traffic we are going to need some tools. The tools that we are going to use are:
Creating the certificate
So what is a
TLS CA certificate?
When you communicate with a third party
using a secure channel like
SSL (Secure Socket Layer) protocol
TLS (Transport Layer Security) protocol
include a security measure called digital certificates
that implements asymmetric encryption
by using a private and public key.
In this protocol, a public key is signed
CA (Certificate Authority) using their private key.
This way a certificate provides a link
between the public key and the
CA that signed that key.
The following process is how a connection works:
The browser connects to the server using a secure protocol.
The server responds with the digital certificate containing the server’s public key.
The browser looks to see if the
CAfrom the certificate is included on its trusted list of
CA’s. This is where we will work.
Once the browser verifies that the
CAfrom the certificate is in its trusted list of
CA’s, it uses the public key provided in
(2)to create a session key.
Finally, the browser and the server encrypt data over the connection using the session key.
CA-issued digital certificate
with its public keys stored on the trusted list
indicates to a cellphone
that it can "trust" the proxy
Without this, we cannot intercept secure channel traffic.
As we don’t have a
we are going to create a self-signed one.
First, we generate the certificate
with 3650 days of validity
and using a
It will also request some information.
We can put our personal/company information here
or leave it blank:
$ openssl req -x509 -days 3650 -nodes -newkey rsa:2048 -outform der -keyout fluidattacks.key -out fluidattacks.der -extensions v3_ca Generating a RSA private key writing new private key to 'fluidattacks.key' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [AU]:CO State or Province Name (full name) [Some-State]:Antioquia Locality Name (e.g., city) :Medellin Organization Name (e.g., company) [Internet Widgits Pty Ltd]:Fluid Attacks Organizational Unit Name (eg, section) :Fluid Attacks Common Name (e.g., server FQDN or YOUR name) :Fluid Attacks Email Address :[email protected]
After generating the certificate,
we have to convert it to
in order to import it into the phone,
DER to import it into
$ openssl x509 -inform DER -outform PEM -text -in fluidattacks.der -out fluidattacks.pem $ openssl rsa -in fluidattacks.key -inform pem -out fluidattacks.key.der -outform der
Finally, we export our key into a
in order to import it to
$ openssl pkcs8 -topk8 -in fluidattacks.key.der -inform der -out fluidattacks.key.pkcs8.der -outform der -nocrypt
Once we have all the files, we need to start configuring our phones.
The certificates installed on the phone
follow the name
so we need the hash of the certificate:
$ openssl x509 -inform PEM -subject_hash -in fluidattacks.pem | head -1
After getting the hash,
we create a copy of the certificate
with that hash in the name.
For example, something like
$ cp fluidattacks.pem <HASH>.0
Then, we need to upload our certificate to the phone.
We can do it manually by connecting the phone
and moving the file into a folder
or with the following command using
$ adb push <HASH>.0 /data/local/tmp
Once the file is in the phone,
log in as
remount the folder
/system with read and write permissions
(it is not mounted with those permissions by default),
copy our certificate to the
and change its permissions and ownership to
$ adb shell phone$ su phone# mount -o rw,remount /system phone# mv /data/local/tmp/<HASH>.0 /system/etc/security/cacerts/ phone# chmod 644 /system/etc/security/cacerts/<HASH>.0 phone# chown root:root /system/etc/security/cacerts/<HASH>.0
The last thing left to do is to restart our phone to load our changes:
Once we turn the phone back on, our certificate will be installed on the system’s trusted credentials tab and the phone will accept the responses of our proxy.
Configuring the Proxy
Now we need to set our proxy in order to use our certificate.
Burpsuite and create a new project.
Then move to the
and open the
The next step is to import our certificate
by clicking on
Import / export CA certificate,
Certificate and private key in
and choosing our
that we previously created.
Now, we need to set our proxy in our phones.
select a shared connection
between the phone and the computer;
we can use the same network
that our computer is connected to
or use our computer as a mobile hotspot
to share it with our phone.
Then, expand the
and input the
IP address and proxy’s port.
We are now capturing secure channel requests made from our phone applications and browsers without having problems with certificate failures.
If we want to have less default traffic on our proxy,
we can again modify the
WiFi settings of our phones
and fill-in the
Bypass proxy input
with the following domains:
*.google.com *.googleapis.com *.gstatic.com