Threats / 01 Decompilation and modification

Decompilation - transforming compiled binary machine code into a reconstructed version of the original source code - is often the first step attackers will take when targeting your app. The aim here is to analyze your app’s code, understand its logic, and identify any vulnerabilities it contains. This can be done manually - opening the app in a decompiler, reading the decompiled code, and searching for keywords - or automatically with the help of a variety of scanning tools.

Decompilation may give attackers access to data they can use immediately, without even needing to run the app:

And it enables them to target any weak points. They might use the knowledge gleaned to exploit your app directly, or to design malware targeting those weak points in order to harvest your end users’ sensitive data.

There’s also a danger of modification or tampering with the compiled binaries, by adding, changing, or removing code. Adversaries might use this for something relatively benign, such as accessing ‘locked’ features and content on their own devices.

Or they could inject malicious code into the app, repackage it, and use social engineering techniques like phishing to distribute the malicious clone to your legitimate customers.

And here’s an additional problem with attackers modifying the compiled binaries: they may be able to remove or override any RASP (Runtime Application Self-Protection) or network security features. This would allow them to run (and/or to redistribute) an unprotected version of what you might think is a secure application.

Decompilation and modification, in other words, can be used to target all of your application’s key assets:

This is why it’s so crucial that applications have comprehensive protection, including:

When we think of APKs and IPAs, we usually think of them being downloaded from Google Play or the App Store. And these distribution services (and others like Huawei AppGallery and the Amazon AppStore) offer some reassurance to developers and users in terms of underwriting the integrity and authenticity of apps. 

These platforms perform analysis and validation of apps before publishing them; they offer code and package signing functionalities to associate apps with their authentic developers. They also use this to enforce the integrity of apps so that developers can be confident that users are running the same app that they built with so much care, without any modifications. 

iOS apps uploaded to and downloaded from the App Store additionally have their binaries and some assets encrypted automatically using Apple's FairPlay technology. When an app is downloaded from the App Store, it is encrypted using the unique device ID of the device that initiated the download. In principle, this means that the app can only be used on the device that downloaded it. So, it cannot be shared or used on other devices.

But since the files are decrypted after download, with a jailbroken device it is possible to extract the IPA to another machine. There, an attacker is free of the iOS device restrictions and can wield any tools they need to crack it. 

It’s even more straightforward to transfer an APK from an Android device onto another machine. And it’s easier still to download it directly from a third-party APK downloader site, of which there are dozens.

At this point, the attacker can begin decompilation and modification. So, what do these involve?

Decompilation involves the ‘reversal’ of the compilation stage of this process.

Application binaries may contain sensitive logic, some necessary secrets, and (in most cases) some unnecessary secrets as well. Decompilation allows adversaries access to all of these.

Even if developers follow secure coding practices and avoid unforced errors such as hardcoding credentials or cryptographic keys into their compiled package, there will always be information for attackers to exploit.

Strings are a typical target. And attackers can easily search for sensitive indicators such as ‘key’, ‘API’, ‘nfc’, ‘password’, ‘crypto’, ‘URL’, or ‘http’ using GUI or command-line tools.

Intellectual Property (IP) is another important example: that might be anything from image files, to prototyped new features, to proprietary algorithms. 

Decompilation also enables an attacker to identify the application’s weak spots. Likely targets are how the app

At runtime, applications request access to data and functionalities from other applications, from the system, and from the device itself. The operating system manages these requests, granting and denying access based on available APIs, the security policy, and the user’s own inputs.

Decompiling the application provides insights into what access the app requests, the permissions it asks for, and what access it provides to other applications. This information can be exploited if the attacker can identify entry points for accessing sensitive data and functionalities via the target application.

For instance by accessing ‘locked’ features and content on their own devices, cheating or spoofing functionalities, or bypassing local authentication checks.

Modifications are usually made with one of two main goals in mind:

Decompilation and modification are unpreventable in themselves, and so the priority is instead to make them pointless to the adversary.

Mitigating the danger of decompilation is fundamentally about making the decompiled code difficult (and ideally impossible) to understand. In this case, there is no benefit to decompilation. This can be achieved through code & resource hardening, mainly by means of obfuscation and encryption.

And the same basic principle applies to modification: attackers tamper with apps in order to change their functionalities, to then exploit those changes during runtime. If the tampered app is never run, then the attacker cannot take advantage of their modifications. This is the fundamental rationale behind anti-tampering & integrity controls.

To mitigate modification and tampering, both Android and iOS platforms offer code signing functionalities. The idea here is that developers sign their apps with a private key which only they can access. This private key is tied to a public key certificate which identifies the owner of the private key, i.e. the developer, and also contains cryptographic hashes - uniquely derived representations - of the contents of the app and its code. Whenever the app is installed on an Android or iOS device, the operating system calculates the cryptographic hashes of the app’s contents and checks that they match the hashes in the public certificate. If the hashes don’t match, it’s clear that the app has been modified, and the system will not allow the app to run.

This is a good solution, but it has one notable flaw: it remains possible for an adversary to modify the application and then simply re-sign the app with their own private key, creating a new public key certificate with cryptographic hashes matching the newly modified app. This means that responsibility is left to the end user to download and use apps only from trusted sources and legitimate developers.

To reinforce this mechanism, therefore, Google in addition offers the Play Integrity API, which developers can optionally integrate into their Android apps. With Play Integrity, at sensitive points during runtime (e.g. when the user performs a transaction), the app can request verifications from Google Play servers: as well as checking whether the app is running on a genuine Android device, and was installed legitimately via Google Play, Play Integrity also checks whether the app has been modified and/or re-signed by comparing the certificate of the app on the device with the certificate it has on record. If there’s any discrepancy, the Google Play server indicates to the app that the app’s integrity has been compromised, and the app (or rather its associated server) can block the transaction.

This successfully prevents wholesale repackaging and re-signing of an application, but it doesn’t guarantee the integrity of the app’s code in itself. And it remains possible to extract code for repurposed use in another app.

The Play Integrity API library can also be removed from a modified version of the app. If the backend authentication logic is secure, this will mean the modified app cannot be used to perform genuine transactions. But it can still be repackaged and redistributed to unsuspecting users who believe they are using the legitimate, unmodified version.

This exposes a general problem that anti-tampering and integrity controls must ideally solve: if some component within your app is fundamental to checking the integrity of the app, what’s to stop an attacker from simply removing or overriding that component? As we’ve seen, a digital signature is intended to confirm the authenticity and integrity of the app, but an attacker can simply modify the app and re-sign it with their own key. 

Encryption can help us here. As mentioned previously:

If those keys are algorithmically generated using the app’s file contents as inputs, any encrypted file becomes (1) impossible for an attacker to understand, and (2) impossible for an attacker to modify. If they modify any encrypted file, the inputs to the algorithms will be different, and the decryption keys will not match the encryption keys, making decryption impossible. The modified file will be unusable.