Android Decompile Apk
Egisto Chancellor
An Android Package file (.apk) is a compressed archive file that contains all of the data and resources needed by an application to run on your Android device. APK file is typically created when the developer wants to share the app with others or to upload it on Google Play. Basically, an APK file is used to install an app onto your phone or tablet.
APK decompilation is the process of reverse engineering an APK file to retrieve its source code. APK decompilation is useful for understanding how an Android app works, especially if you're interested in ethical hacking or penetration testing.
Decompiling or reverse-engineering an APK file is not as complicated as it sounds. There are several free and open source APK decompiler tools available for doing this. But, the three most popular ones are:
For example, JADX is quick and convenient but sometimes resource files are partially missing in its output. So, JADX has some reliability issues. On the other hand, Apktool returns source code in detail with complete resource files.
If you want to discover all the available options (i.e. open source, online, Windows, Mac, Linux, and Android apps) then definitely check out this ultimate list of best APK decompiler tools. Here, you'll get information about the features as well as the pros/cons of each APK decompiler.
Basically, JADX is packed with a command-line utility as well as a GUI application. The Command line utility is mostly used when you want to provide an APK decompiler as a service. Whereas, the JADX GUI app is more convenient to decompile a specific APK and view its source code and resources in a better user interface.
I have worked pretty a lot analyzing Android projects with different reverse engineering tools, generally for secure purposes, to see what can be seen by a hacker when he/she gets my app. I've met a problem that I couldn't find any of decompilers capable to decompile files of "XAPK" format (not simple APK).I know, asking for a way to find a tool is not kind of questions good for stack overflow, but I am pretty sure there are many people with the same problem and I find it highly relevant.I tried apk-tool, decompilers provided with androguard tool, online-decompilers, none of them are capable of working with XAPKs.
This will unpack the package into a directory named game-apktool. It will also decode various XML files such as AndroidManifest.xml. And it will translate the code into Smali which is a kind of assembler language.
Now I have a game-procyon directory with the easy to read but not always entirely correct Java code of the game. The game-apktool directory is more complete, and its Smali code is more reliable because closer to the source.
Components not listed in the manifest can be exposed as well. For example, Content.registerReceiver() will add a receiver dynamically. In this game I also found a dynamic receiver which would accept data without proper validation.
So this class is being called via the Java reflection API which complicates affairs. A search for the class name in the game-apktool directory finds it in the global-metadata.dat file. The conclusion is: this is being called from inside the Unity engine. So there is no way around understanding its code as well. This is relevant for the impact of the vulnerabilities above as well.
I found articles explaining that Unity is based on .NET and there is supposed to be a file assets/bin/Data/Managed/Assembly-CSharp.dll in the package. Unity then uses Mono to run .NET code. Sounds good as .NET code is compiled to an intermediate language which can be decompiled fairly well, similarly to compiled Java.
Trouble is: there is no such file in this game. In fact, there are no DLL files at all here. The names of the DLL files appear in some asset files, which led me to the crazy suspicion that the DLL files are stored as assets and unpacked at runtime. A detour through the assets file format allowed me to extract the files contained here and confirmed that the DLLs are merely being referenced.
Finally I realized that the game developers used il2cpp here which provides an alternative to executing via Mono. This approach compiles code from the intermediate language further into native code. Here, the result was a library called libil2cpp.so. Most strings used here were stored separately in a global-metadata.dat file.
The tool of choice to make sense of libil2cpp.so appears to be Il2CppInspector. While it cannot revert the compilation, it will recover the entire class structure of the managed code. So it will provide the correct name and parameters for each function in the library.
A look into il2cpp-codegen.h reveals that this is the IL2CPP_RUNTIME_CLASS_INIT macro and the function called here is named il2cpp::vm::Runtime::ClassInit. Another one-time initialization block that can be ignored.
If my understood from your analysis is correct, you could retrieve some information, but not everything as it is relatively confusing translated from what it was originally designed in C# and in the end you had to guess quite often, right?
I'm trying to reproduce your steps in a similar game but I'm not able to successfully have Ghidra working with it and there are not many similar stuff on this, do you think you can explain a little better the process? Maybe even add some details in the original blog post..
There is no generic advise to be provided here. I only looked at one game, using one compilation process. My understanding is that the process is highly customizable and with other games you might find something very different.
Hello, thank you for the very thorough article, I ran into an issue with the APK I was trying to decompile. If anyone perhaps knows what I could do to fix it, I would really appreciate any and all advice, thank you!
I was able to successfully decompile the APK using both methods mentioned in the article. However, I was unable to find the Assembly-CSharp.dll, or the libil2cpp.so files. I was able to find the global-metadata.dat file, and that seemed to be readable by IL2CPPInspector, however I could not find the binary file that actually contained the data. I looked for every extension I could think of (exe, dll, so, out, bin) to no avail, and I was kind of stumped. I looked around the entire output of the decompilation, and I was not able to find anything that seemed useful, not even a linux mapping .txt file. I know the project was made in Unity, and it seems like it was compiled with ProGuard enabled. Could it be possible that my decompilation was only partially successful? If not, is there possibly an alternative way of packaging these APK's that I could possibly be missing? I figured that because I was able to find the "global-metadata.dat" file, I needed to find a "libil2cpp.so" counterpart, but I am stumped. Thanks!
JD-Core is a JAVA decompiler written in JAVA. JD-Core is a standalone JAVA library containing the JAVA decompiler of "Java Decompiler project". It support Java 1.1.8 to Java 10.0, including Lambda expressions, method references and default methods. JD-Core is the engine of JD-GUI.
APK stands for Android Application Package. It is an extension of a file that can be installed on android devices. APK is the executable file in the android device in the entire project that is generated after compiling lots of files in android studio. It is a very challenging task of generating source files from their compiled version. Android Studio generates the APK file by compiling AndroidManifest.xml, .java, or .kt files, layout files, various media files, and many more different files. Below are the steps to decompile the APK file that is getting the source files from Android Application Package. Android studio packs the files into the .dex extension and combining that .dex files generate the APK files.
@TheCoolest (or any other devs) - can you tell more about dtb structure, etc or is that explained anywhere else (some wiki, etc, where to start). I guess dtb used by CoreElec is not the same as /dev/dtb extracted (with dd command), from original Android firmware so far I noticed CE dtb is smaller.
@giaur500 With the 4.9 kernel, the DTBs for generic devices are based on the source of the original android ones. We removed some unused sections, and changed some others (such as audio related ones) to make them work properly with CE. Certain boxes, with non-standard hardware have more modification to make said hardware work.
All DTS files are located in the amlogic-4.9 branch. Our changes are an overlay over the original sources.
Maybe your v.3 box uses a different type of SoC, either not by Amlogic at all, which means CE will not work on it at all, or something newer that needs the Amlogic-ng build rather than the old Amlogic build.
Hello, I am new both in the forum and in the world of android tv. I have a stuuc s1 max 4gb of ram with soc s905x4. I have extracted the dtb from android and I would like someone to adapt it for corelect or a tutorial to adapt it myself. Thanks and great job.
dtb (256 KB)
In the past few days, I had some fun trying to understand the inner workings of an APK file.Previously, I had only used the legendary JD-GUI as a decompiler for some CTF challenges.But when dealing with more complex code, I found that looking at the output of different decompilers can help.Hence, I did a little research to find more decompilers that use different approaches.This post serves as a little reference on how to build and use these tools.
For the first approach, jadx is the way to go.If your target is an APK file, you should definitely give this tool a try.I saw that a lot of APK analyzers rely on it, which probably means that it does a good job.
The second approach requires some mechanism to translate .dex files into .class files.dex2jar is undoubtedly the most commonly known tool to do this.However, I stumbled upon Enjarify.It advertises to work better for several edge cases:
It [dex2jar] works reasonably well most of the time, but a lot of obscure features or edge cases will cause it to fail or even silently produce incorrect results. By contrast, Enjarify is designed to work in as many cases as possible, even for code where Dex2jar would fail.
c80f0f1006