Android Java Decompiler
Darios Uclaray
On this lovely and streaming hot July day, I wish to take you on a journey of my reverse engineering trip across the mountains of Android and the valleys of decompilers. Pour yourself a cold drink and enjoy this voyage.
at this point, you can either install Android tools on your machine and then use adb to pull apk to host machine with following command. Or you can creativly just email yourself apk from MyAppSherer app in the emulator. (lol)
This reverse engineering tool is the most probably most sophisticated and Android specific from this list and it can disassemble resources nearly to the original; including XMLs, images and other assets.
If you run this tool it will spit out tree-structure of the original app that looks something like this; please note that it does not convert *.smil files back to Java source code. But it does an incredible job with other resources.
The small gotcha with Java Decompiler is that you need to convert your APK to JAR before it can be decompiled and inspected by it. To do that you need to geta tool called dex2jar that will help you construct JAR.
In some cases you even might not need to install any of these tools and frameworks and you can just use the online solution like javadecompilers.com. Alghouth bit cumbersone; it can still be used to look into simple Java / Android apps.
The R class in Android projects is a special class. R.java is the dynamically generated class, created during build process to dynamically identify all assets (from strings to Android widgets to layouts), for usage in java classes in Android app. And that means that api_key is not 2131230840 but rahter something else that is defined in XML.
P.s.s.: I also received a brilliant recommendation to look into MobSF. You should definity look into if you wanna look deeper in the subject of reverse engineering of mobile apps, pen-testing and malware analysis.
I started with vscode-decompiler, hoping that githubs copilot will help me in the process. It turned out to be completely useless for such tasks.When I imported the decompiled stuff into AndriodStudio, due to obfuscation, 90% of the classes had problems.Because there are dozens of classes with the same name (i.e. a, b), imagine how many conflicts you get.
Next was to use jadx to decompile the application, which supported semi de-obfuscation. I could import the project into AndroidStudio. Now, all the obfuscated classes have unique names (e.g. C1189f), which makes the AndroidStudio happier.
Just to be crystal clear, you cannot recompile the application and run it, unless the application is simple enough!After a few hours of guessing the name of the classes and their fields, I finally found what I was looking for: the BLE protocol!To my surprise, it has so many commands. I quickly cleaned out a few BLE commands that I was interested in:
After I had enough info about BLE protocol, I began to write a Qt application to use it.I found the BLE support in Qt 6.5.1 quite good (at least on android & linux desktop) as I could use quite a few BLE commands painlessly.
Suddenly I thought, if there is any apk to java source decompiler, it would be a nice thing. You probably know, android runs on dalvik virtual machine, so when we compile android java code, its compile to dex( dalvik executable). So I search a lot to find a way how to convert dex to jar ,and I know already how to decompile jar file to java source code.
This is a great start but the instructions are very incomplete. Step 5 was the worst for the argument. What you should do is go to the Argument tab, select File promt and click OK, then apply. Then Run. It will prompt you for the location of the .APK file. Then it will finally create the jar file.
yes way, nicely worked! but i am getting $ sign in file names. for eg: original HomeForm.java results in HomeForm.java, HomeForm1.java and HomeForm2.java.
are these files part of code or should i delete those files and keep only HomeForm.java?
I followed your steps. I used Windows Explorer to create folder, copy/past .jar files. I told Eclipse to include them and saw them in the project. I set main class to com.googlecode.dex2jar.v3.Main but when I set the argument to my xxxxxxx.apk and clicked run, I received an immediate message: ERROR: com.googlecode.dex2jar.v3.Main could not be found.
This is a Decompiler that extracts the source code of an Android application (including XML files and image assets). Works directly from your android device. You can opt for CFR 0.110 or JaDX 0.6.1 to use as the decompiler.
In Android app security testing, if the application is based solely on Java and doesn't have any native code (C/C++ code), the reverse engineering process is relatively easy and recovers (decompiles) almost all the source code. In those cases, black-box testing (with access to the compiled binary, but not the original source code) can get pretty close to white-box testing.
Nevertheless, if the code has been purposefully obfuscated (or some tool-breaking anti-decompilation tricks have been applied), the reverse engineering process may be very time-consuming and unproductive. This also applies to applications that contain native code. They can still be reverse engineered, but the process is not automated and requires knowledge of low-level details.
Android decompilers go one step further and attempt to convert Android bytecode back into Java source code, making it more human-readable. Fortunately, Java decompilers generally handle Android bytecode well. The above mentioned tools embed, and sometimes even combine, popular free decompilers such as:
We're looking for a secret string stored somewhere inside the app, so the next step is to look inside. First, unzip the APK file (unzip UnCrackable-Level1.apk -d UnCrackable-Level1) and look at the content. In the standard setup, all the Java bytecode and app data is in the file classes.dex in the app root directory (UnCrackable-Level1/). This file conforms to the Dalvik Executable Format (DEX), an Android-specific way of packaging Java programs. Most Java decompilers take plain class files or JARs as input, so you need to convert the classes.dex file into a JAR first. You can do this with dex2jar or enjarify.
Once you have a JAR file, you can use any free decompiler to produce Java code. In this example, we'll use the CFR decompiler. CFR releases are available on the author's website. CFR was released under an MIT license, so you can use it freely even though its source code is not available.
The easiest way to run CFR is through apkx, which also packages dex2jar and automates extraction, conversion, and decompilation. Run it on the APK and you should find the decompiled sources in the directory Uncrackable-Level1/src. To view the sources, a simple text editor (preferably with syntax highlighting) is fine, but loading the code into a Java IDE makes navigation easier. Let's import the code into IntelliJ, which also provides on-device debugging functionality.
Open IntelliJ and select "Android" as the project type in the left tab of the "New Project" dialog. Enter "Uncrackable1" as the application name and "vantagepoint.sg" as the company name. This results in the package name "sg.vantagepoint.uncrackable1", which matches the original package name. Using a matching package name is important if you want to attach the debugger to the running app later on because IntelliJ uses the package name to identify the correct process.
Once you have created the project, expand the "1: Project" view on the left and navigate to the folder app/src/main/java. Right-click and delete the default package "sg.vantagepoint.uncrackable1" created by IntelliJ.
Now, open the Uncrackable-Level1/src directory in a file browser and drag the sg directory into the now empty Java folder in the IntelliJ project view (hold the "alt" key to copy the folder instead of moving it).
I'd like to make clear that I'm talking about avoiding the decompilation of the apk file itself, I know there are some tricks to make the code harder to understand, as using Proguard to obfuscate the code or not storing raw values (I'll also implement them), but what I want to know if there's some way in which if someone where to obtain the apk and put it on an Android decompiler he couldn't get the code (at least in some cases).
This looks hard at first but I don't think its impossible, I renember that years ago some desktop applications where able to detect that were being decompiled, and not allowing its code to be taken, if I renember well they could at least detect they were being detected by some decompiler like OllyDbg. I don't see a reason why it shouldn't be possible with an apk file.
PD: Not sure if this goes here or in reverseengineering, I think the question is in reality about anti reverse engineering which I think is a subfield of information security. But I'd like to ask an admin to move it there if needed.
and then invoking the natives with JNI. It would still be flawful but at least better than using the pure code. I'm not a proficient Java developer, but a similiar feature in C# would be DllImport. It won't prevent you from being debugged but it's harder to debug, especially against script kiddies.
OllyDbg is a debugger, not a decompiler.From your question, I see what you want is Android anti-debugging protection, then you could find some examples in the following articles: -security.gitbook.io/mobile-security-testing-guide/android-testing-guide/0x05j-testing-resiliency-against-reverse-engineering#testing-anti-debugging-detection-mstg-resilience-2
IntroductionAndroid platform uses a virtual machine which is known as Dalvik VM which is used to execute the android application code. Dalvik VM executes the code in a format called DEX (Dalvik Executable). DEX files are the compiled version of Android application code written in Java. DEX files are a form of bytecode and can be decompiled into the corresponding Java source code.When we build a project in android studio to generate the APK. The compiler will firstly convert the code to dex and then this generated dex is then converted to the APK. This APK can be installed on the mobile device.
c80f0f1006