The Quest for Data: Mobile OSINT

Outside of my professional work, I engage in Mobile Open Source Intelligence (OSINT). This involves gathering intelligence from publicly available sources using mobile devices. Unlike traditional OSINT, my focus is on extracting valuable data from specific, data-rich applications, often employing a hint of hacking for the best results.

The Role of Mobile Apps in OSINT

Mobile apps often have access to a wealth of data, including user profiles, geolocation information, communication logs, and more. Many apps also interact with online services and APIs, which can further enrich the available data. However, much of this information is not readily accessible due to security mechanisms and data protection policies.

Mums the word: A Case Study in App Vulnerability

Several years ago, whilst we had our first child, I encountered an app named MUSH, designed for new mothers to connect and share experiences. Upon my wife’s request to check its security, I discovered that the app stored extensive data on users without proper security measures. This included enough personal information to commit identity fraud.

My findings led to the app being significantly redeveloped, showcasing the critical need for secure app development.

How Mobile App Hacking Enhances OSINT

Mobile app hacking involves exploiting vulnerabilities in mobile applications to gain unauthorised access to data. This can uncover hidden data sources and provide deeper insights.

Hacking Tools and Techniques

To break into these “secure” apps, we start with a checklist of essential tools:

Reverse Engineering Tools: APK tool, JD GUI, Hopper disassembler for iOS binaries.

Network Tools: Burp Suite for examining app communications.

Exploitation Tools: Postman, Fiddler for interacting with APIs.

Injection: Using Frida can be invaluable when manipulating apps at runtime

Rooting/Jailbreaking: To access the most secure parts of the device.

Accessing Hidden Data:

• Many apps store data locally on the device, which may not be visible through the app’s user interface. By reverse engineering the app, OSINT practitioners can uncover this hidden data.
• Example: Extracting cached files, local databases, and logs from apps.

Intercepting Network Traffic:

• By intercepting the network traffic between a mobile app and its backend servers, valuable data transmitted over the network can be captured and analysed.
• Example: Using tools like Burp Suite to capture HTTP/HTTPS traffic and extract API endpoints, user data, and more. It’s like eavesdropping on a conversation — just, you know, legally and ethically.

Bypassing Security Mechanisms:

• Many mobile apps implement security features like encryption, obfuscation, and authentication to protect data. Hacking techniques can bypass these mechanisms to access protected data.
• Example: Decrypting encrypted data stored in local files or intercepting decrypted data in memory.

Gathering Metadata:

• Metadata from mobile apps can provide contextual information such as app usage patterns, version history, and permissions, which can be valuable for OSINT analysis.
• Example: Extracting metadata to analyse app permissions and infer potential data access capabilities.

Leaky Apps: Unveiling Data Vulnerabilities

In my investigations, I have found several apps leaking critical user data.

These vulnerabilities included:

• Geolocations: Tracking user movements and sign-up locations.
• Profile Images: Downloadable caches of user images.
• User IDs: Leaked identifiers across apps.
• Voice Notes: Cached and easily accessible voice messages.
• User Preferences: Detailed likes and interests.

This data can be exploited to construct comprehensive user profiles, making individuals vulnerable to targeted attacks.

Putting the Puzzle Together

Using standard OSINT tools combined with the hacked data, we can build comprehensive profiles. This includes personal details, social connections, employment information, and geospatial analysis of movements. Such data is invaluable for crafting targeted social engineering attacks and phishing campaigns.

Conclusions:

By combining traditional OSINT techniques with hacking, we can uncover significant vulnerabilities, underscoring the importance of robust security in protecting user data.

My explorations highlight the critical need for stringent security measures in mobile apps, indeed it’s imperative security is embedded within the development cycle of applications.

As people are increasingly required to share personal data, developers must prioritise secure coding practices and regular security testing. For users, a cautious approach to app permissions and data sharing is essential.

As mobile app security testers we use modified and jailbroken devices to do a lot of our testing; it allows us access to the filesystem, let’s us install tweaks for security mechanisms like SSL pinning and jailbreak detection, and allows use of Frida.
However, what do we do when we are tasked to security test an application which targets iOS 15 or above and all our current devices are jailbroken on iOS 14 — firstly, panic…

…secondly, figure out a new implementation.

There are not a lot of options to jailbreak for iOS 15 and above, however there is one, palera1n

palera1n is a developer-oriented jailbreak for checkm8 devices (A8-A11) on iOS 15.0–16.5.1 — https://palera.in/

The term here, ‘developer orientated’ is an interesting one, to me it conjurers up images of someone who understands almost everything they are doing, sat in a Terminal amending the open source code to get it working on their device. In general palera1n is very versatile and semi works out of the box for the devices it supports; the recent re-write to full C code has also made it more robust, streamlined and reliable, always a good thing when the downside is a bricked device.

There are numerous guides on how to install palera1n, and although we will cover that briefly, the main topic will be utilising SSH over the LAN on palera1n devices, because, out the box, this jailbreak is locked down to only allow USB. So here chronicles the steps to regain full SSH access to the device.

Installation*

*note, this process is on macOS

As mentioned, the method is now fairly seamless, open a Terminal and grab the install script.
sudo /bin/sh -c "$(curl -fsSL https://static.palera.in/scripts/install.sh)"

Once installed, run the command, and follow the on-screen instructions:
palera1n

Once completed and the idevice has rebooted, open the new palera1n app, you’ll be asked to set a password for any terminal commands and install Sileo, Zebra or both. Unfortunately it seems that the now teenage Cydia has finally died a death, but Sileo is rather good.

SSH fun

The only other issue is that although palera1n installs OpenSSH dependencies out of the box, it modifies the port to 44 (instead of the default 22) and doesn’t allow SSH over LAN.

Fair enough, we’ll get access via iproxy over USB (forwarding port 44 to 2222) and take a look at things. Of course the default SSH password is still the one we all know and love, alpine.

iproxy 2222 44 -u [device_uuid] &
ssh root@127.0.0.1 -p 2222

Great, so we’re in. When trying to SSH over the LAN before, the standard rsa authorized keys error popped up, but also that PasswordAuthentication had been disabled. Fine, we’ll turn it back on, except, due to the way palera1n works in its rootless mode, /etc/ssh/sshd_config doesn’t exist.

Wait, what?

Rootful and rootless

Generally, all jailbreaks up to this stage, and a few years prior have been rootful, they mount the / root filesystem as read/write and allow changes and modifications to this, and you have access to standard items like /etc, and /usr/bin.

This is in comparison to rootless, whereby access to the root user account is still achievable as seen, but everything is created virtually and stored within user folders, /var and /private/preboot. Nothing can be written to the main / root filesystem.

For those who work on both platforms, think of it like Android’s system and systemless rooting variations — Magisk

As this is still a fairly new concept, it’s taking tweak and jailbreak developers sometime to catch up; many tweaks don’t work with rootless jailbreaking and thus can leave you missing your favourite toolset… but it is improving, and rootless, like Android’s systemless, is definitely the way forward.

So now we now what we’re looking for, and where to find it:
find / -name sshd_config -print

Once we have found it, simply use vim, to edit the file, and delete the commented out line, replacing it with the opposite, and saving.
PasswordAuthentication yes

We should now be able to SSH in via LAN using password based auth, much like checkra1n did before, allowing easier access to the device for testing.

Hold the phone

Not quite, after any jailbreak always change the default passwords, especially if doing the above and opening up SSH to the LAN, but trying to run passwd was met with the Killed error, and sudo didn’t exist at all, but, we already know exactly where these will be.
find / -name sudo -print

Then add it to the device path:
export PATH="/private/preboot/[digit_string]/jb-xxxxxx/procursus/usr/bin:$PATH"

With this in the path and access to more standard Linux binaries, sudo and passwd should now allow you to change default passwords and run as root.

Shells

When the device connects via iproxy and USB, it always drops into the basic shell, and has reset the $PATH variable AND passwords, due to rootless using standard sh located in /cores/binpack/bin/sh.
Any password changes done to the user accounts via LAN SSH are permanent and stay changed after exit, ensuring the device security.

It is possible to drop into zsh by simply running /var/jb/usr/bin/zsh from the sh prompt giving you access to a proper terminal.

By creating a .profile file in /private/var/root with the string for the zsh (/var/jb/usr/bin/zsh) the sh spawned on USB connection will automatically run zsh, dropping you directly into it allowing access to other binaries from coreutils. Thanks autom8on

Despite palera1n changing the port to SSH via USB, that standard port 22 over LAN works fine once enabled.

Job done.

This is part 2 of our views on APIs. If you haven’t read part 1 then why are you still here? Go take a look :)

A View on APIs From a Security Professional Part 1

Leaking all app data

APIs generally have access to loads of user data; they are the middleman to the transactions between the client interface and the back-end databases. Things like search functionality or filtering will be done on data that the API receives from a back-end database query, however this should be done server side, not locally on the client with stored or received data as this risks exposing a lot of information.

Using Client-side Filtering

With this application, there was a call to api.example.com/call/data as a GET request, the response from the server was the entire listing of companies, emails, usernames, user IDs and real names held by the business; perfect for direct social engineering attacks. This data was then locally stored in a file to be used in the search bar to narrow down results based on pattern matching.

The entire data set was stored locally on the device as a cached file.

As this was a locally cached file, it meant that the data had to be updated frequently, cue numerous GET requests to this /call/data API call over the course of the user journey, all in clear text and without certificate pinning; a major issue.

The idea here is any search term required by the user should be sent as a parameter, the server does the heavy lifting and returns only the specific data required, not everything.

• App sends search term as a parameter in either a GET or POST to the back-end to perform the lookup.
• The Database performs the searching/filtering on the dataset using a query based on the parameter received by the app, and passes the filtered data back to the Server.
• The Server then returns this filtered data back to the app which is relevant to the specifics that were requested.

Admittedly there are some overhead problems to overcome, especially when scaling this up widely, however fundamentally only the data that is specifically searched for would be obtained by the user and not the entirety of the database.

Server Leaks App Data via Response

This next application was seemingly fairly robust; the app itself was quite limited so made attack points difficult to obtain, however there were two instances found where the server response back to the application included the details of the entire user base on the platform. The first involved the use of the Cache.db file on iOS devices.

The idea of the Cache.db file is that it caches all outgoing requests and incoming responses for the application when used with NSURLSession/NSMutableURLRequest functions, this helps speed up loading times if the same request is repeatedly used, much like the cache for your desktop browser. The downside to this is that if the API shares too much, as in this example, and sends back everything for client-side use, then it is all cached. This file is stored in the app private Library directory, so cannot be browsed on standard stock devices.

The same API request URLs that were found cached were also found hardcoded in the applications codebase; which after breaking the SSL pinning and utilising an inline proxy tool allowed us to manually call these to obtain the correct headers.

With the correct headers we could then call /appApi/get_friends/ which resulted in a 200 OK response and the full user base details of the application; just like the cache file but no jailbroken device required to access the data this time. Yes it is hashed, but due to the nature of the parameter names, phone_hash, and matching known hashed data with known plaintext, it was simple enough to script a brute force PoC to obtain certain information in plaintext, included names and mobile numbers; enough for further social engineering or smishing.

Scripting a simple PoC allowed us to brute force hashes to obtain plaintext.

And…?

In both of these scenarios there was a massive leakage of personal user information, knowing a name, company and application builds information for the attack; knowing either the email address or a mobile number creates the attack vector. As seen here, if the entirety of the dataset is sent back to the client we risk putting a lot of our information, and potentially sensitive user information at risk as this can be intercepted, or obtained from the device itself from cached files.

The user should only be sent data that the specific user role is allowed to view based on a set of permissions and restrictions. The entire response to a call should never to sent to the client, especially not one containing so much sensitive information.

Enumeration of Data via API Behaviour

An enumeration attack is the act of abusing the intended behaviour of the system to obtain something that you didn’t previously have, in this case user data. In this context it involves trying different inputs into certain areas to notice subtle differences in how the app or API responds to valid and invalid data. Once we find the particular nuance to identify the difference between the two, we can increment our starting value to enumerate as much data as possible to gain an awareness of what is stored. We’ll explain this a bit more with some examples.

Enumeration involves abusing the system to locate small nuances in the result to confirm or deny the presence of certain data.

The easiest example here is a login form taking an email and a password. The credentials are then checked against the user table in the database and results with either ‘incorrect email’ if the user doesn’t exist or ‘incorrect password’ if the user does exist but the password is wrong. Although both tell us we are wrong, they imply totally different things and allow us to make assumptions about the presence of data.

GET a Forgotten Password

This issue demonstrates enumeration of users based off their email address using subtle differences in the GET request URL. The idea here was to build up a list of valid users from email addresses. The authentication mechanism here wasn’t as option as responses to both valid and invalid email addresses, and an incorrect password, the error message was always ‘Login failed. Incorrect email or password’, so this didn’t help or provide any indication to which was wrong.

However, targeting the Forgotten Password form /pass.html, was more interesting. Entering both a valid and an invalid email gave a stock generic error message about password reset being sent.

However, the subtle difference here was in the GET request. When entering an email address of a user who did not exist the URL changed to append: pass.html?sent=n

When the email of a user who did exist in the system was entered, this changed to echo out the email and show that the password reset email has been sent; a different string was appended, pass.html?email=bob.hope@test.com&sent=y

By abusing the change in the URL, it was possible to build up a list of valid users registered on the platform.

Using this difference in how the app and API responded to the browser meant it was possible to identify which email address related to a valid user, and from this we can expand the number of attempts to obtain a longer list; this list could then be used for social engineering or phishing for a full credential set. Although browser based enumeration is becoming harder to find, little differences like this are still able to be found and something developers generally overlook, or don’t realise it could be used against them.

Response Status Messages

Another way to find enumeration is via an inline proxy tool and the responses that are seen via certain API requests. The differences could be a number of different things here such as HTTP status codes, API error messages or custom status messages, but trying different inputs to notice these variances starts to build an image of the behind the scenes working to help figure out what the back-end is expecting.

The following example shows a few different requests, all to the same API call but with different inputs to test. The format and length of the ID is unknown, and the responses received from the back-end greatly aid in the blind trial and error.

In the first request we can see that a customer ID of AAAAAAA* is invalid and the response, despite being 200 OK, provide a negative status for that input. Compared with the request of 1111111*, provides us with a completely different status code. Based on these two different status codes we are now aware of the correct value, and length for customer ID’s; we can continue this attack using brute force enumeration to locate further customer accounts with automated scanning and increasing the value with a step of 1.

* To get to this stage progressive requests were sent with 4, 5, 6 and 7 characters until the status code changed from input_error to OK.

Now we have a valid customer ID, we can progress deeper into the app to investigate the authentication mechanism to perhaps enumerate valid usernames. Once again, we would be looking for subtle differences in the response from the back-end server to aid in our progression through the API.

And…?

These examples have provided an insight into a couple of the numerous methods that enumeration can be done via APIs. Two totally different techniques were able to be used to an attacker’s advantage to gain knowledge of the users, these techniques were likely not even thought about by the developers. Enumeration isn’t just limited to customer IDs, emails or usernames, it could be any item of data that would be useful for an attacker to have.

APIs are now all around us for the majority of today’s technology. However, out of sight, out of mind won’t work here as whether its a security professional, or a mischievous user, these differences in how requests are handled leaves the door ajar.

Responses from APIs should be generic and not provide any positive or negative outcomes based on any set of data. Custom error codes could also be designated for certain responses which are then documented internally for troubleshooting. The typical end user will never see the API, or any of these return codes, so using certain words or language that allows the inference of how the server reacts can be a great early foothold into your system for those curious enough to be looking.

Securing the API and ensuring security is embedded into its development is just as important as implementing a secure web or mobile app. Forgetting to do so, or not understanding the ramifications of not having a secure API may lead to trouble further down the line.

Tales of API Woes From a Security Professional Part 2 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Application programming interfaces, or APIs, are a large part of today’s world; they are a set of software functions that define the way that multiple applications communicate with each other. Whenever you use an Internet aware software application whether this is a software package, web app, or mobile app it will send data to a back-end server via a request. The server then acts on this information, interpreting it, taking some action and sending it back to the client as a response; this is received via the application and translated into a format readable by humans.

Some APIs are so large that they are more like complete products of their own, not just an intermediary.

With the increase in mobile applications and the need for these apps to talk to back-end servers, APIs have started to transform into entire products themselves rather than just a connection link between two end devices. This increase in both the additional complexity and the number of APIs around means that some of these are rushed into production too quickly, introducing various security issues.

Whether insecure APIs are a product of management pressure, or developers not understanding security boundaries; insecure APIs can greatly impact the security of the application. Perhaps some of these issues are created due to reliance on security through obscurity, general users will never see API communications, so why bother protecting them.

Average users will never see the API, but this doesn’t mean they don’t need to be secure.

This post explores several of these API shortcomings and the repercussions that a lack of security design during the API SDLC provides. All of the examples were found on real engagements within the past 12 months so this is still a modern day issue! Hosts have been redacted or changed.

Not performing user checks

One of the biggest mistakes often found in API testing is the lack of distinction between users. There is either no separation between users and what they have access to, or if there is, that validation is not implemented robustly enough and can be easily bypassed by changing the request URL or the parameters. This may allow users to perform actions such as modifying user details, or submitting new orders as if they were someone else.

My Password is Your Password

In this example we will be looking at a URL obtained from intercepting the traffic from an app. It was found that that there was no user validation between the authenticated user and the target user whose password was being changed. The URL to change our own password was the following:

json/user/update_password

Immediately the attack vector is semi-obvious, attempt to change ‘user’ to our own username (un000123) to see if it is still a valid request; if so we can try to target another user (un000132).

json/un000123/update_password

json/un000132/update_password

This simple lack of separation allowed a complete takeover and control of any other user’s account on the entire platform — game over.

In both cases, us and the target, the API provides a 200 OK response and successfully updates the password on the back-end. This allows us complete control over our target’s user account. This is critical enough, but looking closer there are also a couple of other issues as well.

The Cookie in the request is blank, so this action was able to be carried out by both an authenticated and an unauthenticated user as long as they had knowledge of the API call.

There is no server-side check for the current user password, the server checks that newPassword=confirmNewPassword, and that’s all.

And…?

The issue here is that there was no validation of the users on what they could access. There was firstly no check to ensure anyone was even authenticated to the platform before being allowed to perform API calls, and secondly there were no access controls or separation mechanisms to ensure that users could not access or manipulate other accounts. There should be robust checks performed to ensure that the user who is authenticated can only access and modify their own details, straying outside your sandbox should be met with server errors.

Tales of API Woes From a Security Professional Part 2

Mobile applications are part of our daily lives, from banking, messaging, health, financial to social networking; but what do most of this type of app have in common?

They all hold some sort of private user data.

Whether that data is account numbers, private messages, credit card statements, or the location where you last checked yourself in… that nice cafe round the corner from your house. Our devices store an awful lot of information that would aid someone in potentially stealing an identity.

We rely on the app developers to adequately protect the data we put into their apps.

If we, as users, decide we want to use an app, we have to rely on the developers to create a secure app and protect our stored data; that is the implicit trust we place onto them. We have usernames, passwords, biometrics, but what about the custom security features that are added into applications in an attempt to safeguard this private information away from malicious intent; protections such as PINs?

In this post, we will take a look at an app that has a custom PIN entry mechanism as a separate line of defence should anyone else have physical access to the device or know the lock screen password. This would be a secondary authentication mechanism in an attempt to balance usability and security, so the user doesn’t have to login to the app every time they use it.

We’re not talking about how the PIN is stored or the encryption surrounding it. We‘re interested in looking at the actual logic and internal workings of the PIN implementation and the underlying weaknesses.

One PIN to Rule Them All

Code

In this first example, we will show how it is possible to patch the application so that it allows any PIN to work, regardless of the original PIN created by the user.

On looking at the Java code, we see a method called onPINSubmit(), we can see this returns void so nothing is passed back to the calling method. All the PIN function is handled here.

In order to bypass this authentication, we need to ensure we always trigger the appropriate IF conditions.

1. A PIN has previously been setup, and therefore exists.
2. The submitted PIN string is not empty.
3. Comparing the stored PIN with the one just submitted.

If the PIN is valid, the IF is passed and the code continues running on lines 153 onwards.

While looking at the smali we can clearly see these IF conditions and the result of the check being passed into the variable, v0, and jumping to cond_2 depending on the value, lines 477, 485 and 493. These statements match the three bullet points above, so the line 493 does the actual comparison of the two PIN strings which is the last check.

This comparison is done with the statement, if-eqz v0, :cond_2, whereby it jumps to cond_2, if the value of v0 is equal to zero. Equal to zero meaning that if the strings do not match the result would be 0/False. If the PIN strings matched, the result would be 1/True and jump to cond_2 would not be taken.

The result of the previous conditions, isEmpty, uses the opposite, if-nez v0, :cond_2, and therefore would jump if the result was 1/True.

Patching

It is then clear to see that we do not want to jump to cond_2 and the last check on line 493 is the most critical, as this is the last condition which changes the value of v0. If we modified the code above this, v0 would be overwritten with another value once the check finished.

By noticing the return values of the methods are Boolean, we can start to build our PIN bypass.

We can also see that the return values of isEmpty and equals methods are all Boolean values which provides our way of patching this check.

Firstly we could modify the line which accepts the value from the equals check of the strings, rather than moving the result of the actual check we could hardcode a constant of 1 into v0.

move-result v0  -->  const/4 v0, 0x1

A second patch could be simply reversing the logic of the smali conditional statement so that it jumps to cond_2 on a valid PIN, not an invalid one.
This however may trigger the user to notice something is amiss when they attempt to use the app and insert their correct PIN and it doesn’t work. Meaning option 1 would be preferable in this instance.

if-eqz v0, :cond_2  -->  if-nez v0, :cond_2

Unlimited PIN Retries

Code

The PIN authentication mechanism also had another protection; this extra piece of security was a count of the incorrect PIN attempts. After 3 incorrect tries, the app would logout and force the user to re-authenticate fully with a valid username and password.

In the same class as the PIN check above, a return void method named checkPINRetryCount() was found. This is a very simple code block that checked if the wrong attempt variable, incremented in onPINSubmit() method, equals 3.

If we look at the smali code we can immediately see the logic flaw involved in this check. The retry counter limit is hardcoded to the constant decimal value 0x3, and then the comparison is done on line 281, if-ne v0, v1, :cond_0.

• If v0 does not equal v1, then jump to cond_0.
• :cond_0 will return-void.

Patching

As with the previous example, there are multiple ways that this check can be bypassed due to the simplicity of the mechanism.

We have the following options:

• Adding a new code statement to return void as soon as the method is invoked, before the actual comparison check is performed.

• It is also possible to change the hardcoded limit value on line 279. Significantly increasing it in from 3 to 999 to allow considerably more attempts.

Note in this case we had to replace the const/4 with const/16 because we need more bits to represent an integer with the value of 999.

• Replacing the comparison instruction with its opposite equivalent, if-eq, but also changing the registers used for the comparison in order to always return True.
  The modified code would now compare, v1== v1, or 0x3 == 0x3, and always be True to jump to cond_0, the return-void statement.

We’ve looked at a couple of examples of custom implementations of an extra security mechanism in the form of PIN entry. While the idea of these extra protections seems like a great idea from a user and development point of view, by not ensuring security is part of the development lifecycle it is possible to introduce very basic flaws in the flow of the code that can be leveraged by any attacker.

While these are only simple examples, they represent a very real problem to homebrew solutions to security. Any homebrew implementation should maintain a lot more security focus than the rest of the application which may use well embedded open source libraries, or vendor backed APIs.

The attack vector here is a very real threat, as we’ve seen the hardest part would not be bypassing the defences, but socially engineering the users to install the modified app and obtain physical access to gain the information from the device.

Exploiting App PIN Mechanisms on Android was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Almost all mobile applications communicate with a backend server, whether this is transmitting app data, backups, analytics; there is some sort of back and forth of data over wireless communication channels in mobile devices.

Most developers know that they need to use HTTPS, it is 2020 after all, but in mobile applications, this doesn’t go far enough. If you don’t check the server you’re communicating with is the one you’re expecting then how do you trust that the communication is secure and not being intercepted?

If you don’t verify the server is the legitimate one, how do you know user communication is secure?

Problem and Solution

The problem is Man in the Middle (MitM) attacks, which as the name suggests refers to some sort of malicious actor sitting in the middle of communications between the client (user/app) and the server. In this position it is possible to intercept, read and modify the traffic to and from the two end devices affecting the users confidentiality, and the integrity of the data. There are numerous ways that MitM can occur, this is not just limited to smart devices, however in the context of mobile one of the biggest threats are fake Android certificates or iOS device profiles.

Luckily there is a solution to this problem, Certificate Pinning, or Public Key Pinning as its also commonly known. Pinning is where the app developers specify particular certificates to verify the legitimacy of the servers the app is connecting with to ensure they are trusted.

We can trust backend servers with the use of Certificate/Public Key Pinning to provide validation.

This method actually ‘pins’ either the certificate, or the a hash of the public key into the application and uses this to determine the trust of the server that it is connecting to, the server of course holding the private key of the PKI key pair.
However, we’re security professionals, while its great to understand the theory of these concepts, we want to understand how we can break these security protections in order to access the underlying API calls. If we can break the certificate pinning, generally it’s possible to gain further footholds into the backend system to obtain a myriad of user data, not just the data of one single user.

We’re going to take a look at two examples of implementations of certificate pinning that have left flaws in the codebase which can be leveraged by malicious users to intercept this communication and access these behind the scenes API calls.

Pinning Bypasses

We should note that SSL pinning presents a difficult challenge to bypass; there are multiple different ways an app can implement it, from standard Java APIs to entire libraries built around it. Once you identify how the app implements the pinning, the smali patch can be quite different, either easier or more sophisticated in certain circumstances. We will illustrate and discuss this in our examples.

Empty Trust Chain

Java

In our first scenario the app was partially obfuscated and used the standard Java SSL pinning. This usually means the app implements a method named “checkServerTrusted()” to validate the backend and possibly “checkClientTrusted()” if client validation is also required by using a custom Trust Manager.

public void checkServerTrusted(X509Certificate[] cert, String str)

Essentially the method authenticates the server side of the connection. The app provides the certificate as input, usually hardcoded somewhere in the app, and the implementation builds the certificate chain to the server and if trusted, returns a positive value, or in the case of a negative value, throws an Exception.

The below method takes an array of X509 certificates ‘x509CertificateArr’, which are then iterated through with the Issuer and Subject names extracted and appended to a certificate chain String then validated and in case of “Pinning not found” an Exception is thrown.

Smali

In the smali breakdown of this code block we can see the lower level representation, there are some similarities but also some nuances to take note of.

The method declaration contains standard smali, however we have:

• ‘[‘ to signify an array for the input argument.
• ‘L’ to show that the following item is an instance or class, in this case, X509Certificate.
• ‘;’ separates arguments
• a String instance, again signified with an ‘L’
• The method then returns void.

In this case, we can simply move the ‘return void’ statement to before the SSL pinning and String construction is even done. This means the certificate chain is never built, nor verified; however this also demonstrates another issue in play and problem with the logic. There is no error checking to verify that the trust chain was valid or even not null, it blindly accepts the return call and carries on communicating.

Modification of Stored Certificates

Java

This next scenario covers a more complex implementation, but again, one that is flawed in the way it creates the certificate chain and introduces vulnerabilities against the SSL pinning.

The SSL pinning was found to use a class implementing a method named init().

1. The first step of the method consists of invoking another method named getCertificates(), which is shown just few lines below; line 140

2. The method getCertificates(), reads CA certificates that are stored as raw resources and returns them in a Java list of type certificate, List<Certificate>

3. Back in init(), instantiate a Java Keystore and add each certificate in the list; lines 95–105

4. Once this Keystore is built, it is given to a Java TrustManager that will use it to initiate the SSL negotiation with Java SSL init() method; lines 105–107

The method implicitly trusts what it’s provided with whether a real certificate, or our custom fake CA.

From a security point of view this init() method is vulnerable because it entirely trusts the certificates that it is provided with, but doesn’t actually validate what these certificates are for when it is return by the method getCertificates(). Therefore, getCertificates() may return a null value, an empty list or, as we are about to show, our custom CA for the proxy tool.

Smali

In the first portion of the method getCertificates() we can observe the method call returning a List object, Ljava/util/List; creating a CertificateFactory called cf on lines 354–358, then creating and instantiating the ArrayList at lines 362–367.

• What is also important to note here is that the list of Certificates, named certificates, is stored in variable v2, line 367.

Further down the code we can start to notice a pattern as to what the code is doing.

1. Put a resource ID into a local variable.
2. Make a call to openRawResource() with this ID; a reference to the certificate.
3. Read using InputStream()
4. Append to the certificates List.
5. Close the InputStream()

This same pattern is repeated for each certificate and at the end of the method, the List stored in v2 is returned.

So this app is taking external input based off a resource ID from the resources folder and building a list of valid “trusted” certificates. What if we were to replace one of these certificates with our attacker controlled certificate?

We can replace the contents of this ‘trusted’ certificate with our own fake CA.

Using the resource ID value that is stored as a constant we can find out what raw file it relates to using a simple command line. Once we have found the resource name, we can locate the raw resource and replace this certificate text with our own.

What is important to note here is that the certificate might be called .cer but actually be a Base64 encoded DER, also known as PEM; and not the raw binary form of a certificate, (DER or CER).

In order to convert between raw binary certificates, cer and der, to Base64 encoded certificates, crt or pem, we can use OpenSSL. Once it’s in the correct format, we can overwrite the existing certificate.

openssl x509 -in proxyCert.der -inform DER -out proxyCertConvert.pem

As we have a real reference to our certificate and real code, all we need to do is to adjust the original logic of the smali. We only care about our certificate being loaded and we can ignore the rest.

• Our certificate has already been opened and read into the InputStream v0 - line 389
• Generate the certificate using the CertificateFactory method generateCertificate(), and move this into v5 - line 390–392
• Add our generated cert, v5, to our certificates List, v2 -line 395
• Close the original InputStream - line 398
• Return the certificates List back to the calling method - line 400.
  The rest of the smali code continues past this, however as we’ve already returned our certificates List object it becomes unreachable code.

The application will only read in the certificate with our modified content inside it before being returned; the filename remains the same, we merely swapped out the text. As its implicitly trusted, the app continues its communication as normal whilst passing everything through our proxy tool due to accepting our CA.

We have detailed two examples of how to bypass different implementations of Certificate Pinning, both with errors in how the protection was implemented, but shows how the smallest of flaws could be used by an attacker to push further into the system and investigate the API calls.

The first example demonstrated a method where the trust chain was implicitly trusted with no further verification other than what the method was passed. There was no error handling or checking what was returned allowing a void return call.

The second used stored application certificates within the app package, which as the mobile application is on the malicious user’s personal device is never a good idea; because as demonstrated, these can be replaced with something completely different to take advantage of code weaknesses.

Certificate pinning if used correctly can be an extensive way to protect the backend servers as well as the communication passed in client-server requests and responses. However, it should not be relied upon fully nor used as a reason to accept insecure development practises on the API, but used as part of a layered approach to mobile app network security.

Bypassing SSL Pinning on Android was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Root detection in Android apps has always been a cat and mouse game. Developers come up with new checks, or a new library comes out; the attackers then bypass these checks or hide root from the filesystem. Despite all the work that goes into coming up with new techniques for either side, root detection remains one of the first hurdles of a defence in depth solution for mobile applications; and as security researchers, one we see all the time.

Rooting

This post isn’t meant to educate about rooting or the act of obtaining root, but it is useful to understand the concepts surrounding it. To root a device means to gain access to the super user account on the operating system, in Android, which is based on Linux, this user is called ‘root’.

Rooting is the act of opening up the system, to break the operating system “chains”.

Being the super user, this account can do anything, view, edit, modify anything; but in the modern age when smartphones likely have more personal data than our other devices, being able to view any file is not always a good thing from a privacy perspective. To break out of the operating system ‘chains’ the device requires certain modifications, either through vendor approved unlocking, or device exploitation.

This is where root detection comes in. Developers add techniques into their app code to check whether this root user is accessible, whether the device has been modified, or if its possible to view files that are usually restricted and then take certain actions based on the result of these checks.

However, the downfall to this is that most of these checks are done badly, perhaps the strings are hardcoded, the result relies on a single Boolean return value, or incorrect logic means the checks don’t even run at all. By identifying and manipulating these flaws in the logic, we can tamper with this detection allowing apps to run as expected on our modified devices.

By leveraging development flaws, we can bypass these checks and allow apps to run on modified devices

We’re going to take a look at two examples of flawed implementations as well as explaining the smali patches involved to avoid having root detected.

Return Values

Its understandable that you need a return value to return the result of the checks, however this value can become a single point of failure if it’s badly implemented. Nesting if statements and then returning a single Boolean return makes for a very quick patch to easily bypass a multitude of different protections. However they’re not always simple, is it return void, return false, return the value of an object; and this is where understanding the syntax and having knowledge of smali really helps.

In this first example we’ll look at these return statements in an app that is unobfuscated and uses a very common root detection method, checking for the presence of root utilities with hardcoded names. The lack of code obfuscation on class and method names make finding the root detection code easy.

Java

In this first root detection mechanism, it is clear what the app attempts to achieve and what the root detection does.

Two specific root checks are implemented:

• checkRootMethod1() searches for strings representing files that maybe present on a rooted device, such as “Superuser.apk”, “sbin/su” etc
• checkRootMethod2() attempts to execute the command “su” by means of the Java getRuntime() method.
• These 2 methods are called inside other methods above, which are named testIsRooted() and isRooted()

What is important to notice here is that these methods do not change any part of the underlying app structure, they are called and merely return the values based on the results.
We have two options for this patch to achieve the same outcome.

• Both checkRootMethod1() and checkRootMethod2() return a Boolean. We could amend this to only return False.
• Patch the calling methods, isRooted() to return False and testIsRooted() void before it calls the real methods.

Smali

Due to the low level that smali works at, it is usually best to modify at the highest point of the calling functions causing the least changes to the codebase. Making changes to specific methods may require more complex patches.

Let us now look at the checkRootMethod1() to get an idea of some of the syntax used.

It is generally better to perform the most ‘lazy’ approach, causing minimal changes where possible.

The smali for the first root detection method is shown.

• Method code can be identified with the key word .method, and return type character; in this instance a Boolean (Z).
• We see the way the code creates String objects using local variables, v0…v8. Then creates a new String array with this range. {v0 .. v8}, [Ljava/lang/String;
• The array length is calculated, initialisation of other variables and a check, if v3 > v1, cond_1
• On line 67–71, we create a new File class, signified with L prefix; and check if the hardcoded file paths exists.
• If the path exists, put the value 0x1 (True) into the v0 local variable, line 77.
• We then return the value of v0 to the calling method.

It is worth showing both return calls here; only if the file path exists will line 77–79 be executed as it follows the flow of code.

If no path exists, if v4 == 0, line 75, branch the code to cond_0, add 0x1 to v3 and follow the goto_0 back to line 62.

###line 62
:goto_0
if-ge v3, v1, :cond_1

The variable v1 (paths left in array - 0) is now less than v3 (0x1) and thus the code jumps to cond_1, whereby return v2 is run. v2 is 0 (False) as previously initialised on line 57 with 0x0.

Note: const/4 [r] [v] puts the numerical value (v) into the specific register (r) as we have seen. The /4 stands for 4 bits and thus the value (v) has a maximum value of 0x15, 0b1111.
const/8 (255) and const/16 (65535) can also be used.

Patching

Now we have covered some of the syntax and opcodes used, let us now consider the actual methods that we are going to patch. Despite the complexities involved in learning this new language, the patches in this first example are very straight forward.
The first part of the patch involves bypassing the method which calls the actual root detection code.

We can see by the (V) type that this method returns void, this is also evident in the return-void statement on line 184.
Simply moving this statement to before the root check methods are called, from line 184 to line 179 bypasses this function completely.

We now need to target the second method, isRooted(), as seen in the method call, this returns a Boolean (Z).
This time rather than moving lines, we can add in our own code to perform the desired behaviour. We want to ensure we return 0x0 or False before the actual detection is called.

In this instance, we can manually write some new code to put a 0 into a local variable, and instantly return this before any other code is run. This can be seen on lines 143–145 in the second image.

const/4 v0, 0x0
return v0

### original code continues

Before we move onto the next example we should point out, in case it wasn’t already obvious. None of the original smali code has been modified or overwritten, we have simply moved or added statements to alter the way the application flows.

Code Modification

When we say code modification we don’t mean we plan to write swathes of complex smali ourself, we simply modify the code to suit our requirements; remember, the lazy approach is the best one.

Read, interpret and modify… The lazy approach is best.

In this next example the application is heavily obfuscated, it involves numerous checks both in Java and native C and doesn’t return just a single Boolean value at the end; however the methodology is generally the same, read, interpret and modify.

When dealing with obfuscated apps, usually the very first steps consist of identifying where the root check is performed, where the root check is implemented, and where it is actually called from. Usually we have 2 options to accomplish this:

1. We could search for strings such as “/su” and root package manager apps like “magisk” and then follow the flow. Generally quite time consuming and could lead to rabbit holes.
2. A more general approach, consists of running the app and then tracing back any error messages that are shown when the detection check fails. For root detection this is generally on launch.

When we say “tracing back”, it relies on an associated positive or negative outcome to a specific check. For example, in a positive outcome the app would continue loading and the user would be able to use the app as normal. A negative outcome we may expect an error message, either by displaying the user a pop-up window or a toast, then the app closing. If we are lucky and this error message is visible, we can trace back this pop-up by searching for the string displayed; usually this links to a resource having a similar name defined in a xml file with an associated ID. Using the ID tag we can search for this in the smali code to identify where it is used and the workflow to obtain these actions.

Java

Let us now examine this second example with the obfuscated app implementing a more sophisticated root check. After having decompiled the app, we search for the string “su” and “magisk” and we manage to find both in a large method named a() which is located in the obfuscated class: m.f.a.c.i

Despite the fact the method within this class file failed to decompile correctly we can still ascertain that the method returns a String and takes 2 Strings as input arguments. We also notice that although unclear at current, the String ‘su’ and ‘magisk’ have been hardcoded; this can also be seen when we examine the smali, however there seem to be numerous returns from multiple methods and return values of different values so we have to take a different approach compared to the previous example.

Smali

Despite not fully understanding the code from the Java point of view we can make some assumptions based on the smali opcodes.

• Already noted are the hardcoded strings in const-string vx, “str”
• Use of invoke-virtual, signifies that the method call is not private, static or final. They are generally used for native library loading.
• The {} from invoke-virtual specify the arguments that are given to the method.
• Based on the names where the actual checkForRoot() method is called, we know it is definitely using a native library — RootBeerNative

Based on the above code snippets, and the bad decompilation of the Java, it is not totally understandable what the code does at this point. However we have found these hardcoded strings which relate to rooting tools or binaries so can guess that the code is searching for these at some stage.

What if we just modify these strings to something else? Something that doesn’t exist and so they will always return False?

The modification of these two strings was the only necessary adjustments to defeat this detection and use the app as normal. You could be fooled into thinking “that was easy”, however, to get to the stage to find that it was these two strings that were being used was the biggest effort, tracing back, reading over the smali to understand the methods and return values all takes time.

Just by changing two string values the root detection was defeated, but its not always that simple.

In this post we have covered two different ways to defeat root detection by patching the smali code. We looked at modifying the return values to manipulate the behaviour without modifying the original code; and we looked at a method whereby through small changes we can trick the app into looking for a file that we know doesn’t exist and therefore making the check fail.

Root detection remains the first step of a defence in depth measure but it needs to be implemented correctly. It needs to have multiple steps and multiple different checks in order to avoid a single point of failure. Using server side verification with tools such as Google SafetyNet Attestation API¹ is a good way to move checks away from the client; however the cat is always chasing the mouse, and even SafetyNet can be bypassed with certain tools.

¹ SafetyNet Attestation — https://developer.android.com/training/safetynet/attestation

Smali: Assembler for Dalvik

Defeating Android Root Detection with Smali Patching was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

When testing Android mobile apps, quite often you can find yourself in a situation where you face a security mechanism that you wish to bypass, either because the app won’t run (e.g root detection) or there is something else you want to investigate more (e.g SSL pinning).

Usually a tester has 2 options to bypass these mechanisms:

1. Bypassing these checks at runtime when executing the app using tools such as Frida; attach the tool to the app process to inject code to manipulate the behaviour.
   Although fast and usually easier: you need to attach to the app process every time you run the app.
2. Otherwise, another more powerful approach while at the same time slightly more complex, consists in modifying the app binary for the specific checks we wish to bypass. In the Android security community this process is referred to as smali code patching.

By patching the underlying binary code, we can bypass app protections and manipulate its behaviour.

Smali

From the official git¹, “smali/baksmali is an assembler/disassembler for the dex format used by dalvik, Android’s Java VM implementation”.

The smali code, which is what we wish to modify, can be thought of as an equivalent of assembly code of a C program.

Having said this, in order to fully understand what smali code is and how it works, it is worth taking a look at the compilation process of an Android app written in Java and where dalvik and dex fit into this.

Android apps are usually written in Java and compiled to Dalvik bytecode. Dalvik bytecode is created by first compiling the Java code to .class files, then converting the JVM bytecode to the Dalvik .dex format with the dx tool.

Extracted from the OWAP Mobile Security Testing Guide²

In this comparison, it can be observed that in Android systems we have an extra compilation step rather than the usual Java program. The Java bytecode is compiled into Dalvik bytecode which is then executed by the Android environment; which in modern devices is Android RunTime (ART). ART is the modern day replacement for the Dalvik VM however still runs the .dex file format.

With this in mind, what smali/backsmali tools do is to reverse the compilation of this bytecode in this .dex format. This is exactly what tools such as apktool³ do; it uses smali/backsmali internally when decompiling an APK file.

There are still challenges that remain despite smali being a hybrid language; using opcodes as well as semi-readable code.

Despite all this, smali patching presents a couple of challenges:

• Although smali code does not look exactly like assembly (in terms of syntax), at the same time it does not look like readable code. It is a hybrid mix of the two which the tester must understand.
• Considering the complexity and how low level smali code is, quite often it is easy to modify something that breaks the logic of the app, making the app unusable or unstable.

Patching Smali

Having introduced and explained the basics of what smali code is, and the reason for modifying it, we’ll begin to talk over some of its structure and syntax, however we will not discuss all opcodes⁴

Before we start exploring the syntax and patching we first need to decompile the target apk. This can be done using apktool to reverse the application, the code and resources; the smali code files can then be found in myAppDirSrc\smali.

java -jar apktool.jar d MyAppName.apk -o myAppDirSrc

Once we’ve done the smali patches, we need to recompile our code to build it from .dex files back into an .apk.

java -jar apktool.jar b myAppDirSrc -o MyNewAppName.apk

However to ensure the modified app installs on a device, it also needs to be signed with a developer signature.

keytool -genkey -v -keystore myKey.jks -keyalg RSA -keysize 2048 -validity 10000 -alias myAlias

zipalign -v -p 4 MyNewAppName.apk MyNewAppNameAligned.apk

apksigner sign — ks myKey.jks — out MyNewAppNameSigned.apk MyNewAppNameAligned.apk

We will look at some examples of Java and the associated smali code to identify where the similarities lie between the two. It is important to be aware of the syntax when working on smali patches in order understand the workflow of the application.

Registers and opcodes

.locals x   #local variables
.field public a:Ljava/lang/String;   # instance fields
.method public constructor <init>(Ljava/lang/String;)V   #methods

v0   #local variable 0
v1   #local variable 1
...

p0   #parameter 0 (Java 'this' context)
p1   #parameter 1
...

const/4 v0, 0x1   #constant value, putting decimal 1 into v0
if-eqz v0   #if v0 is equal to zero
if-nez v0   #if v0 is not equal to zero

move-result v1   #store previous result into v1
return v1   #return value of v1 back to calling method
return void   #return a void value back to calling method

invoke-direct  #invokes non static method, e.g private/constructor
invoke-static  #invoke a static method
invoke-virtual #invoke non private/static/final, e.g native libs

Types

Single characters are used to define various Java types when used in method calls and return values.

V - void
Z - Boolean
B - byte
S - short
C - char
F - float
I - int
J - long
D - double
[ - array
L - class definition

Sample Syntax

• method declaration of myMethod with a void return type

Java
private static void myMethod()

smali
.method private static myMethod()V

• method declaration of myArgMethod with a Boolean return type and a Float argument

Java
private Boolean myArgMethod(float floatnum)

smali
.method private myArgMethod(F)Z –

• method declaration of myStrMethod with a Boolean return type and a Byte and String argument

Java
public Boolean myStrMethod(byte mybyte, String str)

smali
.method public myStrMethod(B; Ljava/lang/String)Z –

We covered a brief intro into some of the vast subject that denotes the smali language; however with only understanding the basics we can start to pull apart the app structure, understand input parameters and return types, and try to modify certain behaviours to manipulate the underlying logic.

¹ smali — https://github.com/JesusFreke/smali/wiki
² OWASP MSTG — https://owasp.org/www-project-mobile-security-testing-guide/
³ Apktool — https://github.com/iBotPeaches/Apktool
⁴ Dalvik opcodes — 1. http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html

Modifying the input arguments and return values of native functions.

We’ve observed how modules from both app execution and the app lifecycle are loaded within the app, but why would this need to be done on a pentest? What can we actually do with all the scripts?

The aim of this final post is to solve the third consideration; to push the scripts even further to manipulate the input arguments and return values of native functions to be able to modify the true workflow of the app and its designed behaviour.

The Target

Let us describe our scenario, and our goal. We are targetting the OpenSSL function named SSL_CTX_set_cipher_list() which essentially is used to specify the default ciphers to be used during the SSL negotiation.

Considering this final example is the most complex one shown and described, reference to the actual code of the OpenSSL function are used. This code is available at: https://www.openssl.org/source/old/1.0.2/

So why this function?

1. It takes 2 input arguments representing pointers, an SSL_CTX struct (similar to Java object representing SSL context) and char (array of characters representing a string)

2. It returns an int value that can be either 0 or 1; the same as a true/false Boolean in Java. In this case returning 0 would mean false, therefore the function returns with an error, otherwise it will return 1.

3. If the circumstances were correct, manipulating this function could be misused to lead to a FREAK¹ attack to downgrade the cipher to force weaker encryption, and represents an interesting case study to test vulnerable backends.

Replacing Arguments of the Function

Having studied and understood what the target function does, the idea with our script will be to attempt to force a downgrade of the default ciphers used inside the app. This is accomplished by modifying the second function argument (args[1]), the char array representing a string with following string: “ALL:EXP” to represent all ciphers including weak ones.

To accomplish this, we will make use of NativeFunction². Simply put, NativeFunction lets us call a specified function inside the target process.
It requires us to provide the memory address of the desired function as its first argument, which can be achieved using NativePointer³, (ptr for brevity), then we need to follow the target functions signature in terms of return and argument types, respectively arguments 2 and 3, in this case we know the function returns an int and it takes inputs as pointer.

Target function signature:

int <<return value>> SSL_CTX_set_cipher_list(SSL_CTX *ctx <<arg1>>, const char *str <<arg2>>)                    

Therefore, we can use the following instantiation in our script:

var mySet_cipher_list = new NativeFunction(ptr(myExportAddr), 'int’, [‘pointer’,’pointer’]);

At this stage we just need to call our function variable:

onEnter is passed the target arguments internally, so this is just called simply with function(args).
We also need to call our function inside onEnter so we can be sure it is called every time. Printing out the value returned by our function allows us to test it actually worked.

onEnter: function(args)
   var ret = mySet_cipher_list(args[0],str);
   console.log("return value " + ret);
   console.log("decoded args[1] " + Memory.readCString(args[1]));

Replacing Return Values of the Function

Having explained and illustrated how to replace arguments of a function, we can utilise the same techniques to modify return values. In this case of theorising the FREAK attack it is not required as we weren’t interested in what was returned, but what was being input.

However, let us contemplate a case where hooking a native function performs a check and returns a Boolean value indicating whether the check has passed (return 1) or not (return 0), and on failure the app would perhaps stop functioning or show an error.

A good example of this would be native backed root detection, whereby the checks to be made; checking for ‘su’ or ‘superuser’, checking for known root package names or applications are stored as strings within a .so file.

We can use this technique to bypass root detection checks which return a Boolean.

To accomplish this, we need to add some code inside the onLeave callback:

Just like the args value passed to onEnter, the retval passed to onLeave is done internally by Frida.
As we are working with integers, we use the .replace(intVal) to actually replace the returned value, in this case, with 0. A couple of log statements will test that our original value has in fact been modified.

onLeave: function(retval)
   console.log("supposed val " + retval);
   retval.replace(0);
   console.log("new val " + retval);

The full script against an app using the OpenSSL library is provided below along with the output generated from it. At the end of the output both the original return value, referred as “supposed”, and after we have modified it, “replaced”, can be observed.

It is worth noting that printing the args using JSON.stringify() will print the actual pointer value of the memory address; however using the Memory API allows us to examine the actual content.
Similarly, the script output has occurred multiple times, this is due to not only the actual function, SSL_CTX_set_cipher_list being called multiple times by the app, but also due to our modification making it retry until successful.

We can only “touch, tamper and modify” our C functions rather than creating entire new ones like in Java.

A final consideration of this technique that should be kept in mind when hooking a C function, we cannot use the same approach one may use when hooking a standard Java function.
We cannot hook the function like a Java method and do whatever we want, for example implementing a new TrustManager. When hooking C functions, we can only “touch, tamper, modify” what goes into the function before it is executed and what comes out of it after the function is executed. Therefore, we need to adapt our approaches to keep this logic in mind when examining these native libraries and manipulating them in a real world setting.

¹ FREAK attack — https://censys.io/blog/freak
² Frida NativeFunction — https://frida.re/docs/javascript-api/#nativefunction
³ Frida NativePointer — https://frida.re/docs/javascript-api/#nativepointer

Exploring Native Functions with Frida on Android — part 4 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using Frida to explore libraries during runtime

In part 2 we moved into a dynamic approach at investigating native libraries using frida-trace and frida CLI. We leveraged the power of the API to construct our own scripts to get useful information from these native functions; however we were left with two considerations.

The script can only enumerate the modules loaded at its execution — not during the app lifecycle.

Using the memory base address and the size of library, monitor the memory to extract useful values.

We will be further exploring the Frida API; and using code examples, try to solve these issues.

Exploring Runtime Lifecycle Libraries

The first point can be resolved using the Interceptor API, which, as the name suggests lets us intercept a target function. We are interested in any library that is opened at any time during the app lifecycle in order to enumerate its exports, as opposed to just at app execution. This is due to certain libraries not being called until a later stage when certain functionality is triggered by the user.

By using Interceptor.attach() it is possible to intercept calls of a desired target function while the app is running.

It is also possible to associate callbacks (functions to do something when the target function is intercepted) specified with the keyword onEnter and onLeave, respectively for when the target function is called but not executed, and when the target function is executed.

The only required input of this API is a pointer specifying the current memory address of the desired target function. Therefore, either we provide the actual address if it is known, or we use Module.findExportbyName() inline, which will return a pointer to the function given as input, in this case ‘open’ from the system libc library or null.

It is worth noting again that, when using Module.findExportbyName() it should be given an explicit library name as input, using ‘null’ only when the library is unknown or the desire is to scan all modules.

Let us now discuss the function explorerOpenedLibs().

• It first intercepts any function found with the name “open” (a proper C function not a JNI one).
• As a string we read the first input given to open() represented by args[0], which represents the file-path to be opened.
• Checking if this file-path string contains “.so”, we can determine that it is a native library and we can extract its name by using the JavaScript function .split().
• At this point we use another API, Process.findModulebyName(), which will return the module specified by its name if it is found, otherwise it will return null.
• If a match is found, we then print out its exports using the same code from previous scripts.

Explicit Library Loading

Let us take another scenario, for instance, when we know the specific module we wish to target and the function to be called, yet neither during app execution or runtime the function is ever called.
In such circumstances it is possible to manually load a specific library and target a certain call explicitly.

Let us revisit our app, myBank, with the fork of the OpenSSL native library, openssl_mybank.
It is important to note that, in order to avoid any errors, all the related libraries need to be loaded as well. In our scenario the myBank OpenSSL library also requires another library, crypto_mybank.

The JavaScript function loadMyBankLibSSL() loads the specific library by using Module.load(), using the absolute path to the library and prints out its respective information. This is done for both libraries that are required.
Then we use the Module.findExportByName() to find the pointer to the memory address of the particular function we are interested in, in our example, X509_verify_cert.

An output generated by a variant of this script shows the output of the libraries being loaded, the base addresses of these, as well as the export address of the function we are interested in. This goes to show this function actually exists, otherwise it would have been ‘null’.

Hooking Native OpenSSL Functions

Using all the techniques we have looked at we now have enough knowledge to build a script to combine all these functions together and start using callbacks to provide useful values.

Using callbacks, we can inspect function arguments - onEnter, or any returned values - onLeave.

The complete function script hookOpenSSLVerifyCert() is shown below;

• First check if the library we are interested in is ever opened by specifying the full absolute file path (var str).
• Retrieve the module (var module)
• Print out some information from it and attempt to retrieve the address of the function X509_verify_cert() that we are interested in (var myExportAddr).
• If the function is found, therefore the returned value is not null, pass this address as input to Interceptor.attach()
• Implement the callbacks for onEnter and onLeave that will be executed when and if the function is ever used by the running app.
• Inside these callbacks, print out the value for the first argument of the function args[0], using JSON or Memory, as well as the returned value.

Finally, the output generated by our script allows us to observe different values for our defined callbacks, onEnter and onLeave.

The detail in this post allowed us to find a way around a shortcoming of frida-trace, or standard Frida CLI. The use of Interceptor means we can get ahead of the game and trace modules even if they’ve not yet been called by the running app; while the use of callbacks lets us determine how a specific native function is behaving on its return and how this could affect further behaviour of the app.

In the final post of the series, we will look at how we can modify these callback values and defeat certain protections that have been put in place via native code as a deterrent to attackers.

Exploring Native Functions with Frida on Android — part 4

Exploring Native Functions with Frida on Android — part 3 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.