Background
This is my first post on the topic of APK Tampering written in 2018. I had roughly 3 years of experience in Ionic and was fascinated by security. My current approach to app security is bit better with resources like OWASP MASVS and MSTG. In 2025, lot has changed. There is no safetynet and Microsoft has shut down codepush. I intend to write a follow up of this post
Content
So I am working with Ionic-Cordova applications for 2–3 years or so. Today I decided to talk about APK tampering. This was one of the reasons I learnt to make my own plugins.
To know more about cordova platform, just google it. There are dozens of articles on what cordova is and the basic app structure/architecture. Tl;dr, you can write Smartphone Apps in JS-HTML using cordova and deploy them in app store.
Cordova Apps are usually client apps. Additional device functionality is provided by Native Plugins. Usually, they perform some logic on devices and the rest is performed on a backend. While I have seen offline cordova apps, they don’t really make sense.
APK tampering is, well tampering an android executable to change it’s intended execution. You can see that when you download that game-cracked with unlimited gold. Probably it comes with a lot of malware too(Bitcoin miners anyone ?). But unlimited internet monies.
To tamper normal android APKs, smali-baksmail stuff is required. This is actually an assembler/disassembler . A pain to modify. Nevertheless, it could be done.
On other hand, cordova tampering is all about changing the JS code.
Rip apart an Android APK and you will see the JS code in assets folder. Viewable/Editable to the naked eye. No assembly shenanigans involved.
Right now I can think of two ways to tamper APK
Change the cordova assets code and repack the APK. Basically you have created your own tampered APK. Recreate a debug APK with plugins and run the application code in the tampered container. This is actually recreating a client. It’s a bit complicated and sort of overkill. But it provides superior control. In both cases you have a tampered APK executing client-side logic and interacting with backend. This is not a problem if your objective is to mine user data. This is problematic when you have taken pains to create a secured APK and your application logic is not running as intended. Or basically when your app is passing sensitive data, basically anything to do with finance or healthcare.
Now I will create an imaginary case just to sell my point.
Pipey Inc. is an ecommerce platform selling pipes online. They create a cordova app that allows pipe enthusiasts to purchase pipes easily.
The payment gateway used is PayPipes which also has a public cordova plugin.
pipe-fanatic decides that he wants free pipes. On preliminary analysis he found out
The app is using cordova. The app uses 6 plugins including the official PayPipes plugin. He purchased a pipe to know the application flow & estimate a rough timeline.
Attack 1.
He modified the APK assets file such that they can purchase pipes for free. He replaced the JS assets with his own tampered assets.
First Mitigation
This works for some time until the owner gets a wind of the situation. He contacts the developer team and they do an analysis. They decide to secure the code with Hot-Code Push with Asset Verification to prevent attackers from performing an attack. Tampered payment code is not allowed to execute. They caught pipe-fanatic who served time for stealing pipes. Free pipes are now but a pipe dream.
Attack 2
pipe-fanatic is now back in action and wants revenge.(Now a part of pipe-bandits gang btw) Asset tampering could no longer work so he dives a bit deeper.
The APK now uses 7 plugins and PayPipe as payment gateway.
He replaced the functions in plugin with his own. And he recreates an APK with the help of his prelim analysis.
He releases the tampered APK in popular APK sharing sites as free PipeAPK-Cracked
Attack 3
Going a step further, he creates a phished UX similar to PayPipes.
The plugin now not only tampers payment but also phishes client-side details.
He releases the tampered APK again as free PipeAPK-Cracked-Latest
The next attacks caused considerable losses to Pipey Inc. They had to suspend all their online operations.
In attack 1, the client was tampered to gain freebies. The assets were tampered. Pipey Inc suffered in this attack
In attack 2, the client was tampered to gain freebies. However this time, the platform was targeted. Again, only Pipey Inc Suffered.
In attack 3, the plugin was targeted and distributed. This actually is a three-pronged attack. Pipey Inc, PayPipes and Pipeys’s Customers were affected.
To summarize the result, if you are using a cordova APK, it’s imperative to secure both the JS-HTML assets and the APK.
Just FYI. Attacks 2 & 3 are quite a bit difficult to execute but it’s entirely possible.
Mitigation Techniques. 1.) Assets verification https://github.com/duddu/cordova-plugin-antitampering
Github user duddu has a plugin for verifying assets. By default, the app crashes if the assets are tampered with. There is a flag that can be used to allow callbacks instead of crashes but the former is recommended. There is a flag that checks for debug mode which is handy to have.
2.) Hot code push (Deprecated) Hot code push is a technique that allows you to update application code after the app has been deployed to the app store.
https://github.com/nordnet/cordova-hot-code-push
https://github.com/Microsoft/code-push
Using Hot Code Push for asset verification is a topic for some other time. For now , just take my word for it.
It’s an effective asset verification technique. It does take time to setup and to apply this technique.
3.) SafetyNet Attestation. (Deprecated) This is a solid attestation technique, iff used in the manner google wants you to use. Primarily SafetyNet Attestation is used for verifying device integrity. But it can also be used to verify APK and APKCertificate Integrity.
A sample output JSON is below
{
"nonce": "R2Rra24fVm5xa2Mg",
"timestampMs": 9860437986543,
"apkPackageName": "com.package.name.of.requesting.app",
"apkCertificateDigestSha256": ["base64 encoded, SHA-256 hash of the
certificate used to sign requesting app"],
"apkDigestSha256": "base64 encoded, SHA-256 hash of the app’s APK",
"ctsProfileMatch": true,
"basicIntegrity": true,
}
- 1ctsProfileMatch and basicIntegrity provide spot checks for device integrity.
- apkPackageName provides spot check for package integrity.
- apkDigestSha256 provides spot check for APK integrity.
- apkCertificateDigestSha256 provides spot check for Certificate integrity.
Though it should be implemented as outlined by google and token should be processed server side. Some samples online process the x509 token inapp which is plainly wrong.
Define a critical functionality .Invoke the safetynet cycle when critical functionality is invoked. Generate nonce server side Invoke SafetyNet on device. Validate x509 token on server side. Based on output, pause or resume code execution. Maybe crash the app. Another thing, use the latest Android build tools. The APK archive generated by the latest tools is a bi different from the ones I used some years back.
There might be other mitigation techniques but I am not aware of those.
Basically use either safetynet or assets verification as a method to verify the authenticity of client. And done. It’s better than nothing.
That’s it for now. Until next time. All hail Pipe-bandits.