frejam jannys nannettah
Niklas Terki
I am experiencing very annoying problems with the application apktool problem.I do not understand what i am doing wrong, or what the problem is.I tried this on debian , and on linux mint. I used different versions of apktool,
My problem was solved by deleting the \framework\1.apk, making a backup on the files I modified, ereasing the dir and decompiling the *.apk again, etc... (on linux, the path is home/[user]/apktool/...). After the update, apktool always loaded the old resource table. N
Definitely seems like the aapt PATH problem I had awhile back. Have you added aapt to PATH? If you still have problems, I have made a good apk kit in bash to avoid all these dependency problems. It supports apktool, signapk, zipalign,adb, fastboot, and heimdall. Check it out. All you need is a current java install.
In my mind the problem is how you install apktool...I had the same problem and I did this and it worked very well:For installation you first have to remove any installed apktool by the command:sudo apt purge apktoolThen you'll have to install apktool but in a different way.To continue save the link bellow as apktool in a directory.[ ]Then open this link below and download the latest apktool.jar file: rename the file as apktool.jarAfter that give both files the permission by the command:
Referring to one of the posts here on SO about the same issue (Terminal can't run apktool), the suggestion was to run ./apktool instead of apktool and that gives me "-bash: ./apktool: No such file or directory"
The process here is the same as any binary application, with the exception that we additionally have a jar file. The apktool file is simply a helper script to prevent you having to type java -jar apktool.jar every time. With this in mind, you must have the following.
If you meet these conditions than running apktool anywhere will run the helper script, which runs apktool.jar. You can test this by cd /usr/local/bin, java -jar apktool.jar. Does that work? If so, apktool.jar is in the right place.
Honestly a combination of 2020, burnout and life changes. None of which are important to this release post. Though if you are interested - I blogged about some of the burnout of long-running open source projects.
Let's talk about maintaining a backlog. Apktool prior to this release had over 250 tickets ranging from 8 years old to 1 day old. It was frankly insane. Some of the topics hadn't even been responded to in years. So I spent roughly 20 hours over Thanksgiving and went through every single ticket. The backlog is now 40 tickets, organized and ready to be fixed. Some tough choices were made on a handful of tickets, but I had to be realistic when it came to fixing some of these anti-tamper issues.
This was blocking me for months from completing the release. However, that is enough meta discussion. Apktool development is active again, a smaller backlog has me hooked and a helpful community of authors will keep the discussions and features going.
This release packs in Android 11 support, which will require a framework update as well as upgrading to the latest and greatest smali project. We embraced GitHub Actions dropping TravisCI and started the deprecation process for 32 bit machines. (Sorry, AOSP is pushing me here)
Error messages were overhauled to help explain why things aren't working. Test cases were enhanced to prevent regressions and each pull request is automatically tested again all 3 major operating systems and a variety of Java versions.
The obfuscation war never ends and Apktool v2.5.0 makes leaps of improvements when it comes to parsing files. Apktool will survive when all namespace references have been removed. Apktool will survive with dummy resources if all resource names have been stripped. Apktool will also survive if all resources have been tweaked to the same name. This of course makes compilation very difficult, but at least the application can be disassembled now.
Binaries for aapt/aapt2 received another great set of patches aiming to lessen the errors that either will encounter during compilation. This led to patching many compression related bugs when it comes to rebuilding applications as well as patching many crashes that result when resources can't be found.
Features were added for the new compileSdkVersion property as well as a apktool list-frameworks command. Finally, some quality of life enhancements for error codes, helper scripts and copyrights. So with that, the detailed change log and author breakdown.
You might be wondering what fueled this curiosity so let me explain. I was in high school and was preparing for my advanced maths exam. I had recently learned that I could use a certain app to get step-by-step solutions to my problems. I was excited. I tried the app and it worked! It only required a one time purchase fee and that was it. I had a lot of questions about how the app worked under the hood:
I decided to have a fresh start at the problem and figure out if I even need to go as far as decompiling the APK. Maybe just a simple MITM attack would be enough to snoop the API calls and craft my own?
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. Whenever I made a query, this API call was made:
So far so good. No need for learning how to reverse-engineer the app. Surely I can figure out what those query parameters are? As it turns out it was extremely hard to figure out how the sig parameter was being generated. Everything else seemed generic enough but sig was dynamic and changed with a change in input.
I tried modifying the input slightly just to check if the API was even checking the sig parameter. As it turns out, it was. The endpoint returned an invalid signature error even on the slightest change in input:
Note: While trying to proxy the android emulator requests via mitmproxy, you might see the error: Client connection killed by block_global. To fix this, make sure you run mitmproxy with the block_global flag set to false: mitmproxy --set block_global=false. You will also have to install the mitmproxy certificate on the device to decrypt the SSL traffic. Follow these instructions to do that.
Disclaimer: I do not condone piracy. This is merely an exercise to teach you how something like this works. The same knowledge is used to reverse malware apps and to disable certificate pinning in APKs. There will be places throughout the article where I will censor the name of the application or the package I am reversing. Do not do anything illegal with this knowledge.
The very first step is to get your hands on the APK file. There are multiple ways to do that. You can either use ADB to get an APK from an Android device (emulated or real) or you can use an online APK website to download a working version of the app. I opted for the latter option. Search on Google and you should be able to find a way to download APKs pretty easily.
This is the perfect time to use JADX to decompile the APK. The hosted version of JADX is pretty neat. You can access it here. Just give it the APK and it will give you a zip file containing the decompiled source.
This is equivalent to calling the hasNext method of java.util.Iterator. Z tells us that this call returns a boolean. p1 is called a parameter register and that is what the hasNext() is being called on. move-result v2 moves the return value of this method call to the v2 register.
I started my exploration from there. I used the output of JADX to explore where this parameter was being populated. This is where having the decompiled source code was really useful. The file structure in the apktool output and jadx output is the same so we can explore the output of JADX to help us figure out where to insert the debug statements in smali.
After exploring the Java output for a while I found the method that was generating the signature. The signature was just an MD5 hash of the rest of the query parameters which were being sent to the server:
The move-result-object call was moving the output of getParameters to the p1 register. This is where I needed a log statement (or so I thought). I did some research and according to StackOverflow I could do something like this:
Firstly, I changed .locals 6 to .locals 7. This is useful because instead of tracing which register I could safely use for my custom code, why not allow the function access to a new register? That way we can be sure that no original code in the method is using the new register.
zipalign is an archive alignment tool that provides important optimization to Android application (APK) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file.
I used an Android Emulator for this step. Specifically a Pixel 3XL emulator image with API 28 and Android Oreo. Make sure that you use an emulator Android image without Google Play. This is extremely important because otherwise in later steps ADB will give you an error saying adbd cannot run as root in production builds. You can find a detailed solution on StackOverflow.
While I was at it, I added some more debug statements in a couple of additional places in the same file but different methods. There was one method that was calling this getMd5Digest method and another that outputted the actual API URL with the query parameters. I added a debug statement in both of these.
This is amazing! Now I knew which parameters, and in what order, are being used to generate the MD5 hash. I quickly whipped out my trusty Visual Studio Code and wrote down a super simple Python script for generating this hash for me based on custom inputs. This is what I came up with:
This is where I stopped my exploration. The original aims were to figure out how the sig hash was being generated and how to reverse-engineer the API to make custom query calls. I was able to accomplish both of those aims and my curiosity was satisfied.
c01484d022