Android Studio Decompile Apk

0 views

Skip to first unread message

Marquez Feliciano

unread,

Aug 3, 2024, 12:43:43 PM8/3/24

to stanimdebki

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.

how do i decompile a thunkable app correctly
i tried to decompile and i think android studio is on drugs [unable to find]
if you are wondering why would i decompile it?
i need to add custom code to the main activity

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.

This writeup will cover some of the basic techniques and methodologies that one could use to reverse and solve android apk challenges. We will also walk-through some basic ctf challenges from picoGym.

APK is the the Android application package file formatted used by the Android operating system, mainly used for distribution and installation of apps on android devices.It is an archive (.zip) and we could open it in a file archiver tools such as winRAR and observe the package contents of the apk.

Most of the android applications are written in Java and kotlin. The Java source code written is compiled by StandardJava Compiler into Dalvik Executable (DEX) bytecode format. The bytecode finally gets executed by either one of the two different virtual machines Dalvik and Android Runtime(ART). For earlier versions of Android, the bytecode was translated by the Dalvik virtual machine. For more recent versions of Android (4.4++), Android Runtime (ART) was introduced and in subsequent versions, it replaced Dalvik.

The normal method will reverse the DEX bytecode into SMALI instructions using dex2jar, you can think of it like the assembly language which is between the high level code and the bytecode. With the Smali code, we could either continue to reverse using jd-gui and obtain the decompiled java source code but we could also modify the smali code and patch the apk to access hidden information.

The shortcut method is a direct method that will decompile the apk into its source code using decompiler.com. This method allows us to quickly obtain the apk source code and its package contents. This is the method that we will mainly rely on for the CTF challenge walk-through.

We can start off by opening the apk via Android Studio (File > PROFILE or DEBUG apk) and then running it on our emulator (Shift + F10).The android emulator will launch and the apk will run and display the following main screen.

The getFlag() function when invoked will log the output of paprika(input) and return "Not Today..." which corresponds to what we observed earlier on, it seems like the flaghas been passed into the Log.i() function invocation.

Where does the output of Log.i go?Log represents the Logger class for Android development, and serves as API for sending log output. There are different levels of problems and information that the developer could tag the log messages. The output can be captured via Android Studio or via CLI logcat.

Our aim is to locate the password at ctx.getString(R.string.password)) and after some searching within the decompiled apk, there is a suspicious file/resources/res/values/strings.xml and it contains a password field with the following data:

According to a report published by Cvedetails (The ultimate security vulnerability data source), Android seemed to have a total number of 322 security flaws in 2017. Out of which, 23% of the flaws published in 2018 were critical and 13% of them allowed malicious code to execute. Obviously this is a bad news for Android app developers, for most of their clients are security critical such as Financial & healthcare ones. In this article, we will discuss the best practices to protect an Android app from reverse engineering. We will look at some factors which make an Android app prone to code decompilation and some solution to how to prevent your android app from reverse engineering.

Android apps are always vulnerable to attack as the code is not rendered into machine code , leaving it prone to extraction and reverse engineering. The vulnerable code can then be used for a variety of reasons, which could be daunting for any serious mobile app business such as:

An extracted code can result in decreased security, freely available in-app purchases and can lead to misleading user data that could result in bad pricing elasticity. These are some of the common reasons why someone would de-compile your code, and you can now understand a little bit of the damage they can put you through.

You may rely on remote procedure calls to a well protected server. This reduces the chance of your codes being stolen as the code will always remain on the server and nothing other than the results can be seen. However this does have a shortcoming, if your app is going to be used by a lot of users(millions), you will need to have a huge server farm.

There are some other creative ways to safeguard your code from decompiling. They involve using debugger detection techniques that you can utilize to prevent run-time-analysis and combine it with encryption of portions of binary codes. But, any enthusiastic attacker can find a way to work around it. If you are looking for more information on a specific debugger detection technique, you should have a look at OpenRCE Anti Reverse Engineering Techniques Database. It provides analysis and descriptions for various anti debugging, disassembly and dumping tricks. Many of the techniques are listed in conjunction with a specific target, but they may be adaptable to other targets.

You can also write the important parts of your code in C/C++ and add them as a compiled library. While it can be disassembled into assembly code, reverse engineering a large library from assembly is extremely time-consuming. Java is easier to decompile in comparison to C/C++.

Using NDK you can write the files natively into .so files, which are much less likely to be decompiled than APKs. There are a few good decompilers available, but that would require the attacker to be proficient in ARM processor architecture, assembler language, JNI Conventions, and Compiler ABI. You are giving the proficient attacker a few sleepless nights.

It is recommended to secure your user-credentials with extra security layer in order to avoid reverse engineering of the application. As a rule of thumb, the credentials should not be reused in many sites. This will prevent the likelihood of an app to reverse engineered. Moreover, the credentials should not be stored on the device. Wherever possible, use a short-lived authorization token to safeguard your account access.

Majority of the hash functions such as MD2, MD5, SHA1 are not secure and prone to malware attacks on Android. Having said that, If they are used to store confidential information, security can be easily compromised. Instead, use secure functions such as SHA-2. A typical hash function should be resistant to collisions and not too fast. If a hash function is too fast, it complicates the attack by exhaustive search. For this specific purpose, specialized hash functions are developed such as PBKDF2, bcrypt, scrypt.

Mobile security in Android can also be enhanced by securing database files. If you are using SQLite then it is advisable to use SQLCipher extension which is completely open-source. Although, SQlite is quite popular among iOS developers, Android developers can also use the benefits of encryption thereby taking the utmost benefits of it in terms of security.