Simple Android code analysis, ADB (Android Debug Bridge)

I. Overview

This article covers the key concepts needed for analyzing Android malware. It explores how to analyze code after decompiling an APK file, focusing on the structure of the AndroidManifest.xml file. It also provides a brief introduction to connecting with Android devices using ADB and understanding the Linux-based directory structure.

II. Fundamental Concepts for Analyzing Android Malware

When decompiling an Android application (APK) file using a program like 'jadx-gui', it's important to understand its structure. This is necessary for identifying vulnerabilities through code analysis. Let's briefly examine the structure of an APK file.

Sample using the jadx-gui program The structure of an APK file after decompilation.It's something you might have seen before, isn't it? If you've worked with Java development, you might be familiar with it. Because it's based on Java, it also functions as an Android application. Object-Oriented Programming (OOP)It has a Java class structure based on object-oriented programming. While it doesn't provide the exact code written by the developer, it is sufficient for code analysis. "com.metasploit.stage" refers to the entire package of this application, and within it, classes a through g each handle specific functions. MainActivity, MainBroadcastReceiver, MainServiceThis component, as mentioned in the previous post, is functioning as described. However, it's likely that the actual class name used in the code doesn't clearly reflect its function. While developers would typically use descriptive class names during development, the decompilation process allows for code analysis, and everyone involved is aware of this. During the commercialization (deployment) phase, the security features will be hidden.

Resource directoryThe application uses static data such as text, images, etc. META-INF, AndroidManifest.xml, Classes.dex, Resources.arscIt contains the public key used for verifying the application's signature. AndroidManifest.xmlThe package information and component details of the app (such as Activities, BroadcastReceivers, etc.) are included. Classes.dex contains the compiled source code, organized by class, converted into bytecode, and optimized into the dex format for application execution. Finally, Resources.arsc contains the compiled resources (strings, layouts, etc.).

Now, let's examine the key aspects to consider when analyzing code. First, the image above is an AndroidManifest.xml file. This file contains information about the components that make up an Android application, as well as information related to permissions and hardware. We open this file first because it provides a general overview of the application's purpose. However, this doesn't tell the whole story. Some applications include permission-related information that is not actually used. This is done to determine whether the application is currently being used on a device where it is installed. In general, uses-permission While adding this item, I noticed... The system determines whether Bluetooth is enabled or disabled, whether a network connection is available, or whether the tilt sensor is functioning correctly by performing actions such as turning Bluetooth on or off, checking network connectivity, and using the tilt sensor. This is also the case for regular user apps, in addition to malicious code apps, due to the same reasons that permissions are structured.

※ All Android applications must have unique package names. This is because the Android operating system, which is based on Linux, uses package names and PIDs to manage processes. In the image above, the package name is likely 'com.metasploit.stage', but it doesn't necessarily have to start with 'com.'.

First, let's briefly discuss the `android:targetSdkVersion` part. This refers to the minimum version of Android required for the application to run. Just as we check the Java version when running a JAR file, the application must meet this version requirement to function correctly. Looking at the `uses-permission` section, even if we don't fully understand it, we can likely infer that it specifies which system permissions the application requires to run. In essence, this section lists the permissions the application needs to access essential data and hardware. By defining these permissions in advance, the Android operating system can verify them and then allow the application to use the corresponding hardware or data.

※ You may have encountered situations where applications request permissions during installation or use. This is a practice where developers are not responsible, but instead, the responsibility is shifted to the user. You can simply understand this point.

The application's activity, receiver, and service sections Android componentsThis section defines how "intent" is structured, although a more detailed explanation is still needed. As mentioned in a previous post, "intent" refers to the purpose or goal, for example: android.intent.category.LAUNCHERThis refers to the icon displayed to users to help them access the app. Let's briefly recap the components and move on. activityThis refers to the user interface (UI) that is displayed to the user. broadcast receiverThis is for handling internal events. servicesThis refers to the background processing aspect, which is not included here, but rather concerns the content provider's role in sharing data. As an example, consider the "receiver" part. android.intent.action.BOOT_COMPLETEDThis allows users to launch the app once the phone has finished booting up.

※ Android has multiple entry points. Users can launch an app by tapping its icon, or by receiving notifications, playing music in the background, or clicking on internet ads, which then lead to apps like Coupang or KakaoTalk. Therefore, when analyzing code, it's common to start with the activity.

III. ADB Internship

ADB (Android Debug Bridge)Essentially, this tool is designed for debugging on Android devices. It allows users to perform various tasks, such as examining the internal structure of a device or identifying malicious apps among multiple applications, all from within a Windows environment.

SDK Platform Tool Release Notes  |  Android Developer  |  Android Developers

You can download this from here.

Android Debug Bridge (adb)  |  Android Developer  |  Android Developers

Detailed information about how to use it can be found here.

To begin with, here are some basic commands:

Since I needed an Android device to conduct the practical training using ADB, I installed and used Nox Player.

Nox Player: Enjoy mobile games safely and without lag on your PC.

Finally, I've also set the file path of the downloaded ADB to an environment variable, making it easy to use from any location.

The method is to go to Settings > System.

This will allow you to access the information. Once you're in, you'll see advanced system settings; please click on them.

There are environmental factors to consider. Once inside,

Simply click on that path, then click "New," and paste the ADB file path directly.

Now, let's try connecting to the device using the ADB command. (But first, make sure Nox is running.)

If you enter "adb devices" in this way, no devices will appear. So, now we need to find the Nox application that is currently running.

`tasklist` displays a list of currently running processes, while `findstr` filters the output to show only results that match a specific string. `netstat -ano` shows a list of all currently open server IP addresses and ports. In the case of Nox, it connects using port 62001.

Finally, if the connection is successful, you will be able to see the Linux shell opening through the adb shell. If you want to disconnect, you can exit the shell and then use the "adb kill-server" command to reset the connection.

※ Important directories to remember /data/app, /data/data, /system/vendor/lib, /proc, /storage/emulated/0This includes: * **/data:** This is the application shared directory, containing general data and APK files. * **/system:** This directory contains system configuration files. * **/proc:** This directory is related to processes. * **/storage:** This refers to the SD card. In Linux, user accounts are typically stored in the `/home/username` directory. This is done to prevent other users from accessing personal user information.