APKTool is so great. Earlier versions Android were way more loose with everything, there were tons of undocumented APIs, permissions weren't granular, didn't map to things that well, etc.
2012-2013 I wrote a parental control app for Android that "locked" down the device so you could give it to your kid and it would only run what you wanted it to run for however long you wanted, like "30 mins of games per day". To do this properly, you needed a task manager, ability to kill other apps, guard against being uninstalled, etc. This was not possible with the permissions that were available by being an app on Google Play, it was possible only if your APK was signed by Google or the carrier with system-level permissions.
Nevertheless, I cobbled together a collection of tricks that managed to do it well enough - my app was a home launcher and when it detected a game running past allowed time, it would "kill" the app by pressing the home button, thus brining itself to the front. It had to take over the status bar to prevent you from swiping down to access settings, etc.
Anyway, I relied on APKTool a lot to disassemble other apps which were doing things that I needed (like drawing over the status bar), because they had already figured out how to use these undocumented APIs. I could not have done it without APKTool.
It's been offline since like 2014, so probably wouldn't even work on newer Android versions. But we did have competition, so it seems like there should be equivalent functionality today.
apktool is such a wonderful tool. As a side note, with newer versions of Android, it's no longer necessary to extract bytecode from odex/vdex files to disassemble systems apps or frameworks too. The apk/jar files all contain `classes<n>.dex` now (this was changed when A/B partitioning was introduced, I believe).
I love using Jadx (https://github.com/skylot/jadx) to get a better understanding of the code in Java and then use APKTool to reverse engineer, decompile and recompile the app
Reverse engineering is a very exciting field and the moment you learn and figure out one concept you realize there is a lot more out there for you to figure out.
This looks like a pretty decent write up at a quick glance, thanks!
I've been toying around in the space a little bit (primarily around patching stuff to get past https pinning) but I've been meaning to get a better understanding on how stuff works rather than just throwing darts at the wall.
I wrote a script a few years back to automate decompiling, and weaving in code in to an APK, then recompiling it using a recipe type structure -- https://github.com/elliottcarlson/Otto -- kind of abandoned it sadly, but figure it's worth sharing in case anyone has value in it.
This is the best article on Android app reverse engineering I have read. Thanks.
Some more details on this step would be nice:
> I currently have an iPhone so I installed the Android Emulator on my Linux machine and install the app on that. Then I launched mitmproxy and started intercepting the traffic from the emulator.
Is this also the emulator from Android Studio? It would be very nice to intercept app traffic, without the need for a real device, but I have never been able to get it working.
Usually you have to use (or create) an unpinner frida script. In my experience it's been easier to just write down custom dumpers to avoid having to deal with that and also modifying the request (at least some time ago mitmproxy downgraded http/2 to http) which would result in the endpoint being able to detect the tampering.
As for the emulator, I haven't ever used the official one to work, I know some people who used Anbox in Linux but I don't have much to say because I use a real device most of the times (although I pleayer with ldplayer, bluestacks and genymotion all of which behaved nicely to some extent).
FWIW mitmproxy shouldn't downgrade HTTP/2, at least if you have a version that was released in 2016 or later. If that's not the case please feel free to file a bug and I'll look into it. :)
Several UK TV apps are available on fire stick but not Android TV.
I've seen people de-Amazonify older versions of these, would Apktool be a good place to do this myself ?
I really just want to watch programs I already have access to on pretty similar hardware (Android TV), but getting more hardware for that just seems wasteful.
To some degree yes, apktool will unpack the apk and disassemble the dex files in a way in which you can modify them and then compile the project again, sign it and deploy it (as long as your device supports it).
In this case you would have to either modify the smali code itself to make those changes.
When the modifications are basic such as changing a few instructions to avoid checks or adding simplistic payloads writing them in smali is just fine but if your modifications are more substantial I'd suggest creating a placeholder java project, decompiling it and adapting that smali so it's less of a pain in the neck.
Another valid approach would be embedding a custom shared object or fridas gadget with a configuration file to run a payload on start.
As for understanding what you need to change and how, jadx is the way to go most of the times but for some nastier code you can either use dex2java and then jd on the converted file or just go straight to the smali code (honestly that's not that usual)
Also, while testing your patched version I'd suggest heavily using and abusing frida in a rooted device if possible.
Note : I don't usually use the "create a java project" option so your mileage might vary but I recon it's probably the easiest.
APKTool is amazing. I used it to reverse engineer an old version of Netflix to allow it running on my Xiaomi projector. I no longer need it now as the projector is now Netflix-certified but it was incredibly useful to me in the earlier days.
If your devices support Widevine L1 but not certified to run Netflix, you could use this little patch.
I've been puttering around for years but never really paid much attention to APKs because I hate working on my phone. I am going to play around with this to check out why some Google store apps tend to demand pretty extensive privileges for fairly benign use cases. I figured it was a huge pain in the butt and never even looked for a decompiler.
I just shoveled it off on to my never ending list of things I'm going to look at when the secret for immortality is found.
Furthermore, the very orthogonal way permissions are categorized relative to internal API architecture is woefully unintuitive at best, making it next to impossible to come up with good summary judgements of what a given app might be trying to do. For example, a given game might want access to your "cell ID information" because the analytics SDK it uses is overly invasive (while the game itself never needs the info), while a smart-device controller app might request "real-time location information" (I forget exactly what the permission is called) just because the smart device happens to use BTLE (Bluetooth LE), because BTLE's fast connect/disconnect characteristics made it ripe for abuse by indoor location tracking systems in shops and whatnot, and so Android had to make that the permission name since it's impossible to determine programmatically what a given BTLE connection is being used for.
So not only is the mapping from policy to implementation a case of a pile of arrows all pointing at each other, the current permissions model has a really big "wait what" problem because it's based around enabling access to APIs ahead-of-time so they can be used when needed. Android's trying to go down a just-in-time model where for example something requests access to storage as and when needed (I think this is called "instant" permissions); this contextualizes and thus justifies the request, allowing for more informed consent.
With the ahead-of-time way things work nowadays, though... I'd be a bit bullish that APKTool on its own would be useful. You're basically in an equivalent situation to wondering why a given Chrome extension might be asking for a certain permission, only to download the CRX, unzip it, and find everything minified. Intractable? Check. "Now what?": check. Suspicious? Good question :(
In practice a reasonable number of Chrome extensions incidentally aren't minified and contain perfectly readable source, sometimes even with comments (which is great for figuring out how other developers have solved certain complex integration problems ;D) - but the bytecode-based nature of the Java runtime means you're always working with some level of minification. Control flow is generally always somewhat permuted in much the same way pseudo-decompiled C code doesn't quite look the same as the original. If a given app isn't using obfuscation, you might be able to see some symbol names however.
Android Studio adds the Proguard obfuscator (which ships for free with 'Studio) into the build instructions of every new project by default, but switched off by default to make builds faster. Once enabled by just changing a couple build settings to "true", obfuscation Just Works™ without any additional steps. Given this state of commoditization it's often...
Just for publishing the app. The app bundles you publish get transformed into an APK specific to your hardware, which is then installed on your device.
In addition to sibling comment. APK is more or less zip file, with exception to one of signatures, all the interesting part that you want to reverse are the files inside it not the container: dalvik bytecode, binary encoded XML files of UI and other API specific resources.
When I moved the project from Google Code to GitHub, GitHub did not allow binary downloads. So I used Bitbucket, changing the download location again after moving did not seem right. So it has just been maintained since the switch. Now in present day they are also uploaded to GitHub and another mirror I host.
Having found some in vendors' native macos apps (a private key for an IAM user that happened to have the Administrator managed policy attached to it, to boot), I would personally not be the least bit surprised to find them in mobile apps.
Got a bug report about an app I did nothing about (used by some partners to check certain kinds of tickets). No one else knew anything about it. I couldn't find it on our Gitlab nor in our legacy Bitbucket. Turns out the source code was lost a long time ago, but a partner still had the APKs (there were two versions, one in English and another slightly more advanced in Italian).
Using APKTool I managed to decompile the app, add some printf logging to figure out the issue, fix it in the Italian/more advanced one, merge it with the English one and rebuild it.
The only issue is that the signing key was lost too, so partners had to uninstall and reinstall, but nothing I could do about it.
Oh, and another time I cracked the in-app purchase for the password manager I was using on a spare Android device while my Lumia was in RMA (it had separate purchases for each platform). Of course I bought it once I let go of Windows Phone and moved to Android permanently.
At one of my former jobs, I was working on an automated testing product that could MITM requests (for testing analytics, etc.)
Android has this really annoying feature where apps don't trust self-signed CA certs (but Chrome & webviews do, strangely). You either need to need to add it to the app's network_security_config.xml, or root the device and add it as a system CA.
I looked into using apktool as part of a pipeline to inject our self-signed CA as a custom trust anchor when customers uploaded their APK for testing. But in the end, we found it was easier and simpler to just add a the cert as a system CA on a custom rooted AVD.
That whole project really made me appreciate that no matter how shit I feel web dev is some days, at least I'm not an android developer.
Initial release sure, but if you are looking at the website linked that was released in 2018 and the last major release (2.6.0) was released in 2021. So don't think 2010 is accurate.
Submitter linked to the main page, which is known since 2010. Nothing much changed since.
If he would have linked to the latest news instead, it would be 2021.
APKTool is amazing and have used it before to check the security on some apps. But it doesn't do much when it comes to apps made using flutter as the code is stored in a binary form. Wish if they consider adding a way to decompile that as well.
I used this to remove ads from Instagram. It's a wonderful tool that gives you godlike powers over other people's apps when you know what you're doing.
Yes. I injected my own code in there that intercepts HTTP responses and rewrites them as needed before giving them to the rest of the app. I was able to do this in a way that's portable across versions because they use an HTTP client written in C++, which needs JNI bindings, which can't be obfuscated.
48 comments
[ 5.8 ms ] story [ 109 ms ] thread2012-2013 I wrote a parental control app for Android that "locked" down the device so you could give it to your kid and it would only run what you wanted it to run for however long you wanted, like "30 mins of games per day". To do this properly, you needed a task manager, ability to kill other apps, guard against being uninstalled, etc. This was not possible with the permissions that were available by being an app on Google Play, it was possible only if your APK was signed by Google or the carrier with system-level permissions.
Nevertheless, I cobbled together a collection of tricks that managed to do it well enough - my app was a home launcher and when it detected a game running past allowed time, it would "kill" the app by pressing the home button, thus brining itself to the front. It had to take over the status bar to prevent you from swiping down to access settings, etc.
Anyway, I relied on APKTool a lot to disassemble other apps which were doing things that I needed (like drawing over the status bar), because they had already figured out how to use these undocumented APIs. I could not have done it without APKTool.
I want to be able to put some sort of delay when opening time wasting website so that it is not as addictive.
I love using Jadx (https://github.com/skylot/jadx) to get a better understanding of the code in Java and then use APKTool to reverse engineer, decompile and recompile the app
If you are interested, Frida is also an amazing tool that makes certain type of reverse engineerings a lot easier compared to using APKTool. I wrote an article on that as well: https://yasoob.me/posts/reverse-engineering-nike-run-club-us...
Reverse engineering is a very exciting field and the moment you learn and figure out one concept you realize there is a lot more out there for you to figure out.
I've been toying around in the space a little bit (primarily around patching stuff to get past https pinning) but I've been meaning to get a better understanding on how stuff works rather than just throwing darts at the wall.
Some more details on this step would be nice:
> I currently have an iPhone so I installed the Android Emulator on my Linux machine and install the app on that. Then I launched mitmproxy and started intercepting the traffic from the emulator.
Is this also the emulator from Android Studio? It would be very nice to intercept app traffic, without the need for a real device, but I have never been able to get it working.
Usually you have to use (or create) an unpinner frida script. In my experience it's been easier to just write down custom dumpers to avoid having to deal with that and also modifying the request (at least some time ago mitmproxy downgraded http/2 to http) which would result in the endpoint being able to detect the tampering.
As for the emulator, I haven't ever used the official one to work, I know some people who used Anbox in Linux but I don't have much to say because I use a real device most of the times (although I pleayer with ldplayer, bluestacks and genymotion all of which behaved nicely to some extent).
Several UK TV apps are available on fire stick but not Android TV.
I've seen people de-Amazonify older versions of these, would Apktool be a good place to do this myself ?
I really just want to watch programs I already have access to on pretty similar hardware (Android TV), but getting more hardware for that just seems wasteful.
To some degree yes, apktool will unpack the apk and disassemble the dex files in a way in which you can modify them and then compile the project again, sign it and deploy it (as long as your device supports it).
In this case you would have to either modify the smali code itself to make those changes.
When the modifications are basic such as changing a few instructions to avoid checks or adding simplistic payloads writing them in smali is just fine but if your modifications are more substantial I'd suggest creating a placeholder java project, decompiling it and adapting that smali so it's less of a pain in the neck.
Another valid approach would be embedding a custom shared object or fridas gadget with a configuration file to run a payload on start.
As for understanding what you need to change and how, jadx is the way to go most of the times but for some nastier code you can either use dex2java and then jd on the converted file or just go straight to the smali code (honestly that's not that usual)
Also, while testing your patched version I'd suggest heavily using and abusing frida in a rooted device if possible.
Note : I don't usually use the "create a java project" option so your mileage might vary but I recon it's probably the easiest.
If your devices support Widevine L1 but not certified to run Netflix, you could use this little patch.
https://github.com/longseespace/netflix_patch
Edit, found the thread https://forum.xda-developers.com/t/rotation-lock-removal-req...
Everyone's experiences are different! It's helpful to share things we may consider "old news" because it may just end up benefiting those around us.
I've been puttering around for years but never really paid much attention to APKs because I hate working on my phone. I am going to play around with this to check out why some Google store apps tend to demand pretty extensive privileges for fairly benign use cases. I figured it was a huge pain in the butt and never even looked for a decompiler.
I just shoveled it off on to my never ending list of things I'm going to look at when the secret for immortality is found.
IIUC, the permissions apps request ultimately just enable access to certain APIs; they don't do anything on their own: https://stackoverflow.com/questions/24858462/how-to-check-if... (see 1st comment). So apps like https://play.google.com/store/apps/details?id=sk.styk.martin... and https://play.google.com/store/apps/details?id=com.ubqsoft.se... basically reason about the ceiling of everything an app might use across its lifetime. It's arguably a tad misrepresentative, like seeing a wall of text from a distance can be scary.
Furthermore, the very orthogonal way permissions are categorized relative to internal API architecture is woefully unintuitive at best, making it next to impossible to come up with good summary judgements of what a given app might be trying to do. For example, a given game might want access to your "cell ID information" because the analytics SDK it uses is overly invasive (while the game itself never needs the info), while a smart-device controller app might request "real-time location information" (I forget exactly what the permission is called) just because the smart device happens to use BTLE (Bluetooth LE), because BTLE's fast connect/disconnect characteristics made it ripe for abuse by indoor location tracking systems in shops and whatnot, and so Android had to make that the permission name since it's impossible to determine programmatically what a given BTLE connection is being used for.
So not only is the mapping from policy to implementation a case of a pile of arrows all pointing at each other, the current permissions model has a really big "wait what" problem because it's based around enabling access to APIs ahead-of-time so they can be used when needed. Android's trying to go down a just-in-time model where for example something requests access to storage as and when needed (I think this is called "instant" permissions); this contextualizes and thus justifies the request, allowing for more informed consent.
With the ahead-of-time way things work nowadays, though... I'd be a bit bullish that APKTool on its own would be useful. You're basically in an equivalent situation to wondering why a given Chrome extension might be asking for a certain permission, only to download the CRX, unzip it, and find everything minified. Intractable? Check. "Now what?": check. Suspicious? Good question :(
In practice a reasonable number of Chrome extensions incidentally aren't minified and contain perfectly readable source, sometimes even with comments (which is great for figuring out how other developers have solved certain complex integration problems ;D) - but the bytecode-based nature of the Java runtime means you're always working with some level of minification. Control flow is generally always somewhat permuted in much the same way pseudo-decompiled C code doesn't quite look the same as the original. If a given app isn't using obfuscation, you might be able to see some symbol names however.
Android Studio adds the Proguard obfuscator (which ships for free with 'Studio) into the build instructions of every new project by default, but switched off by default to make builds faster. Once enabled by just changing a couple build settings to "true", obfuscation Just Works™ without any additional steps. Given this state of commoditization it's often...
Random note: It's curious how the homepage and the linked repo are on GitHub but the binary downloads are served from bitbucket.
Using APKTool I managed to decompile the app, add some printf logging to figure out the issue, fix it in the Italian/more advanced one, merge it with the English one and rebuild it.
The only issue is that the signing key was lost too, so partners had to uninstall and reinstall, but nothing I could do about it.
Oh, and another time I cracked the in-app purchase for the password manager I was using on a spare Android device while my Lumia was in RMA (it had separate purchases for each platform). Of course I bought it once I let go of Windows Phone and moved to Android permanently.
Android has this really annoying feature where apps don't trust self-signed CA certs (but Chrome & webviews do, strangely). You either need to need to add it to the app's network_security_config.xml, or root the device and add it as a system CA.
I looked into using apktool as part of a pipeline to inject our self-signed CA as a custom trust anchor when customers uploaded their APK for testing. But in the end, we found it was easier and simpler to just add a the cert as a system CA on a custom rooted AVD.
That whole project really made me appreciate that no matter how shit I feel web dev is some days, at least I'm not an android developer.