The goal of this chapter is to write a minimal application for Android. But we will never know for sure whether we were able to write something that works without trying to run it on a real device. This is what we will do in this article.

The ability to test on a smartphone is provided by ADB (Android Debug Bridge). In this article, we will set it up and run our application on a real smartphone.

What is ADB

Android Debug Bridge (ADB) is a universal command line tool that facilitates interaction between the development environment, in this case Android Studio, and AVD emulators or physical Android devices to be able to run and debug applications.

ADB consists of a client and a server, which works as background process, on the developer's computer and from a daemon that runs as a background process on each instance of the emulator or real device.

Setting up an Android device to work with ADB

In order to use ADB with a device connected via USB, you must enable USB debugging in the system settings of your phone or tablet in the "Developer Options" section (the name may vary). On some devices this section is hidden by default. Let's look at the steps in the case when the required settings section is not available.

Go to settings, section "About device"
Find "Build Number" and click on it 7 times. A window should appear notifying you that developer mode is activated.
Enable the "USB Debugging" option.

Now, when you connect your device to your computer, depending on the model, you may experience new option connections.

Setting up ADB on Windows

When setting up Windows, first make sure you have Google USB Driver installed. Go to SDK Manager in the Extras section and find Google USB Driver, install it if necessary.

Now you should update the driver. Connect your device to your computer, go to Control Panel -> Hardware and Sound -> Device Manager and find your device. Right click on your device to open context menu and select "Update drivers...". The driver can be found in the sdk directory in the subfolder \(sdk directory)\extras\google\usb_driver.

How to check if ADB settings are correct?

To check the functionality of ADB, connect the device to the computer, launch a command line in the \(sdk directory)\platform-tools folder and enter the command in it:

adb devices

A list like this should appear:

List of devices attached 5cdb2ced device

Running the application on a real device

Everything is the same as when running on an emulator. Open our project in Android Studio, click on green triangle, but in the device selection window that appears, select your device.

If it says that the device is offline, plug in the USB and allow USB debugging on the computer:

As a result, our application will appear on the screen of your phone or tablet.

Conclusion

This ends the chapter. We were successful: we were able to configure our system for developing Android applications and even run one of them on a real device.

If something is actively not working out for you or you are confused, please write in the comments and I will help you figure out your problem.

Decompilation and debugging of Android applications

Alexander Antipov

This article will show you how to attach a debugger to an Android application and step through the methods being called using the information obtained after decompiling the application.

This article will show you how to attach a debugger to an Android application and step through the methods being called using the information obtained after decompiling the application. The good news is that debugging does not require superuser privileges. The techniques described can be very useful during pentests. mobile applications, because we can "infiltrate" the code while the program is running, obtain and record information that we would not normally have access to. For example, you can intercept traffic before encryption and obtain keys, passwords and any other valuable information on the fly. The article will be useful to pentesters and mobile application developers who want to gain more in-depth knowledge about possible attacks on the Android platform.

Test environment requirements:

Operating system: Windows / Mac OS X / Linux
Java (version 1.7 recommended)
IDE (Eclipse, IntelliJ IDEA, Android Studio)
Android SDK (https://developer.android.com/sdk/index.html?hl=i)
APKTool (https://code.google.com/p/android-apktool/)/APK Studio (http://apkstudio.codeplex.com)
Android device/emulator

The following configuration will be used in this article: Windows 8, Android Studio and IntelliJ IDEA. Device: Nexus 4 with Android versions 4.4.4. I recommend adding all utilities to the PATH environment variable to make accessing these tools easier and faster.

The Android application package (APK) used in this article can be downloaded from here: com.netspi.egruber.test.apk .

Device setup

The instructions below will help you prepare the device for experiments.

Activating the Developer Options section

To begin with, USB debugging must be enabled on your Android device (USB debugging option), which will allow you to “communicate” with the device using tools from the Android SDK. However, before this you need to activate the Developer options section. On your device, go to the Settings > About Phone section and click on the Build Number item several times, after which a message should appear stating that the Developer options section is activated.

Figure 1: In order to activate the Developer options section, you need to click on Build number several times

Enable USB Debugging

To enable debugging via the USB port, go to Settings > Developer options and check the box next to USB debugging.

Figure 2: Enabling the USB debugging option

Connecting the device and launching ADB

After connecting the device to the computer via a USB port, the message “USB debugging connected on the device” should appear. You should also check if you can connect to your device using the Android Debug Bridge (ADB) app included in the Android SDK (Android SDK Platform-tools). At the command prompt, enter the following command:

The device should appear in the list.

Figure 3: List of connected devices

If the device does not appear in the list, then the most likely reason is incorrect installed drivers(on Windows). Depending on the device, the driver can be found either in the Android SDK or on the manufacturer's website.

Checking the application for debugging

Before debugging Android applications, you first need to check if this is possible. The check can be performed in several ways.

The first way is to run Android Device Monitor, included in the Android SDK (in the tools folder). IN Windows file called monitor.bat. When you open Android Device Monitor, the device will appear in the Devices section.

Figure 4: Android Device Monitor Application

If any application on the device can be debugged, that application will also appear in the list. I created a test program, but the list is empty because the program cannot be debugged.

The second way to check if an application is debugable is to examine the AndroidManifest.xml file from the application package (APK, Android application package). The APK is a zip archive containing all the information needed to run the application on your Android device.

Whenever an application is loaded from Google Play Store, the application package is also downloaded. All downloaded APK files are usually stored on the device in the /data/app folder. If you do not have superuser rights, you will not be able to list files from the /data/app directory. Although, if you know the name of the APK file, you can copy it using the utility adb. To find out the name of the APK file, enter the following command:

will appear command line devices. Then enter the following command:

pm list packages -f

A list of all packages on the device is displayed.

Figure 5: List of packages on the device

Looking at the list, we find a test application.

Figure 6: Created test application package (highlighted in white)

Now you need to copy the package file. Open the shell and enter the following command:

adb pull /data/app/[.apk file]

Figure 7: Copying the APK file from the device to the system

Now you need to open the package file and examine the contents of AndroidManifest.xml. Unfortunately, we cannot simply extract the archive because the APK file is encoded in binary format. The utility most often used for decoding is apktool although I use APK Studio, because this application is friendly GUI. The rest of the article will talk about APK Studio.

In APK Studio, click on the small green icon, name the project and specify the path to APK file. Then specify let to save the project.

Figure 8: Creating a new project in APK Studio

After opening the APK, select the AndroidManifest.xml file and look at the application tag settings. If the android:debuggable flag is missing (or present but set to false), then the application cannot be debugged.

Figure 9: Contents of AndroidManifest.xml file

Modifying the AndroidManifest.xml file

Using the apktool utility or APK Studio, we can modify the files and pack the contents back into the package. We will now modify the AndroidManifest.xml file so that the application can be debugged. Add the line android:debuggable="true" inside the application tag.

Figure 10: Changing the contents of the application tag

After adding the flag, click on the “hammer” icon and reassemble the package. The rebuilt package will be located in the build/apk directory.

Figure 11: Rebuilding the package completed successfully

After rebuilding, the package is signed and can be reinstalled on the device (all Android applications must be signed). Most applications do not verify the certificate used to sign. Otherwise, you need to change the code that performs this check.

Now you need to install the rebuilt package. First, delete the old application using the following command:

adb pm uninstall

Then install the new package:

adb install [.apk file]

You can also remove and install the package with one command:

adb install -r [.apk file]

Figure 12: Installing the rebuilt package

Check that the reinstalled application launches correctly on the device. If everything works, go back to Android Device Monitor, where the test application should appear.

Figure 13: The rebuilt application can now be debugged

Setting up the development environment (IDE)

Now you can attach a debugger to the rebuilt application, but first you need to create a project in the development environment (the article uses IntelliJ IDEA). Let's create a new project. In the Application name field, enter a custom name. In the Package name field, specify a name that exactly matches the folder hierarchy of the rebuilt package.

Figure 14: Creating a new project in IntelliJ IDEA

Typically the APK file name will match the folder structure, although if you are unsure, check the directory hierarchy in APK Studio down to the folder where the application files are located. In my case, the name and folder structure are exactly the same (com.netspi.egruber.test).

Figure 15: Test application directory hierarchy

Uncheck "Create Hello World Activity" and finish creating the project (all other options remain default). The new project should look something like this:

Figure 16: Hierarchy of folders and files of the new project

After creating the project you need to add source from the APK file so that the debugger “knows” the names of symbols, methods, variables, etc. The good news is that Android applications can be decompiled with virtually no loss of quality (the source code will be the same as the original). After decompilation, the source code is imported into the development environment (IDE).

Retrieving Sources from an Application Package

First, you need to convert the APK to a jar file. Then, using a java decompiler, we will obtain the source code of the application. We will do the conversion to jar using the utility dex2jar. dex2jar has a d2j-dex2jar.bat file which is used to convert APK to jar. The command syntax is quite simple:

d2j-dex2jar.bat [.apk file]

Figure 17: Converting APK to jar

Then open or drag the resulting file into the JD-GUI (this is a java decompiler).

Figure 18: Jar file structure

The jar file should appear as a hierarchical structure containing java files with readable source code. Go to File > Save All Sources to pack all the sources into a zip archive.

Figure 19: Saving the source texts of the decompiled file

After saving the source texts, unpack the archive into a separate directory.

Figure 20: Unpacked archive

Now you need to import both directories into the previously created project in the IDE. In IntelliJ, go to the src folder and copy the contents of the unpacked archive there (two directories).

Figure 21: Both folders are copied to the src directory

Returning to Intellij, we see the updated project.

Figure 22: Source texts appeared in the project

If we click on any element from the list, we will see the source text. As you can see in the screenshot below (source text of the LoginActivity class), the source code is obfuscated using ProGuard.

Figure 23: Obfuscated source text of the LoginActivity class

Connecting a debugger

Now that the project has source code, we can start setting breakpoints on methods and variables. When breakpoints are reached, the application will stop. As an example, I set a breakpoint on a method (right in the obfuscated code) responsible for processing information entered into a text field.

Figure 24: A breakpoint is set on an obfuscated method.

As soon as a breakpoint appears, connect the debugger to the process on the device by clicking on the screen icon in the right top corner(the icon may be different on your IDE).

Figure 25: Connecting the debugger to the process

Figure 26: List of processes for connecting a debugger

After selecting the process, the debugger will connect to the device.

Figure 27: Debugger attached to a process running on the device

I will enter the number 42 into the text field (if you remember, there is a breakpoint on the corresponding method).

Figure 28: Enter the number 42 in the text field

After pressing the Enter Code button, the application will break at the breakpoint because the debugger is aware of which method is being called on the device. A compiled Android application contains debugging information (such as variable names) that is available to any Java Debug Wire Protocol (JDWP) compliant debugger. If your application has debugging enabled, a JDWP-compatible debugger (most debuggers included with Java development environments falls into this category) will be able to connect to virtual machine Android applications and then read and execute debugging commands.

Figure 29: Breakpoint hit

The screenshot below shows the number that we previously entered in the text field.

Figure 30: List of variables of the current class instance

Conclusion

We can not only read data in the application, but also insert our own. This can be useful if, for example, we want to interrupt the flow of code execution and bypass some parts of the algorithm. Using a debugger, we can better understand the logic of the application and analyze what is inaccessible to the average user. For example, viewing the encryption functions used and dynamic keys can be very useful. Also, sometimes when debugging it is useful to know how functions interact with file system or a database to understand what information is stored by the application. Similar manipulations are available on any Android device without superuser privileges.

Sandbox

Server God September 18, 2011 at 15:55

Overview of tools for launching and debugging applications on Android

Lumber room *

While developing my first Android application, I encountered the problem of launching the application for testing and debugging. This article should help a novice user choose an emulation tool.

Android Virtual Device (AVD)

Installation:
This emulation tool is built into the Android SDK.

Setting:
(using an example of use in Eclipse)
Window > Android SDK and AVD Manager > New
We enter the name of the virtual device, platform, memory card size, display type...
Click Create AVD.

Launch:
The first launch of the emulator takes a very long time, especially on weak devices. For example, I couldn’t wait for the first launch on my netbook, and when I launched it for the first time on my computer, I was sure that the emulator had gone into an eternal loop.
Subsequent launches of the emulator will be a little faster.
The time between pressing the “Run” button and the appearance of the main activity of the test application on the emulator takes an average of 11 seconds. The measurements were carried out on a fairly powerful computer.

Advantages and disadvantages:
+ the ability to test the application on different versions Android OS, on devices with different types display...
+ various settings necessary for testing, for example, changing the screen orientation
+ SD card emulation
- a long period of time between pressing the “Run” button and launching the application on the emulator
- the emulator works very slowly, for example, what the phone processed in 1-2 seconds, the emulator did in 8-10 seconds

VirtualBox+Android x86

Installation and configuration:

Download and install VirtualBox.
Download the image.
"We are creating a virtual Linux machine 2.6/Other Linux, 512 Mb RAM, Bridged Network, HD 2 Gb, Disable Mouse Integration. Connecting ISO file and boot into one of the LiveCD options (there is an HDPI and MDPI option)” or follow these instructions.
Press Alt-F1 to exit to the console and type netcfg and remember the IP address of the emulator. To return to the GUI, press Alt-F7.
adb connect

Launch:
I didn’t record the time between pressing the “Run” button and the appearance of the main activity of the test application on the emulator, but, according to subjective feelings, this happens almost instantly.

Advantages and disadvantages:
+ a short period of time between pressing the “Run” button and launching the application on the emulator
+ quick work in places
- rather lengthy and sometimes problematic installation
- the emulator is slow in some places, there are problems with the image (especially on MDPI)
- problems with SD card emulation, changing screen orientation,...
- only two (three) available versions Android OS and only two available display types

Android phone connected via USB

Installation and configuration:

We turn on debugging mode on the phone. (Settings > Applications > Development > USB Debugging).
Download the driver for your phone.
We connect the phone to the PC.
Installing drivers. The ADB Interface section should appear in Device Manager.
adb devices. If your phone does not appear in the list, then reinstall the ADB driver.

Launch:
About 5 seconds pass between pressing the “Run” button and the main activity of the test application appearing on the phone.

Advantages and disadvantages:
+ the ability to see the application as the user will see it (a very important point, especially when creating the interface and design of the application)
+ multitouch (if your phone has it)
+ change screen orientation, accelerometer (if your phone has it)
- only one OS version and one display type
- another object will appear on the physical desktop

Conclusions:

I tried working with each of these emulation tools and settled on this option:
1. writing and testing an application using a phone;
2. testing the application on numerous Android Virtual Devices with different combinations of OS version and display type.
I hope that the reader has chosen an emulator or learned something new for himself.
Good luck with your testing!

When creating Android applications, most developers use various emulators. This is convenient because you don’t need to store a bunch of different devices in desk drawers, there is no headache with connecting devices to the computer, and there are no heaps of wires on the desk. We click the mouse and see the work of our program on the computer screen. Simple and elegant. However, an emulator is not a phone. He is limited in his capabilities. If your application uses any specific hardware functions, such as those related to the camera, Bluetooth, or USB connection, working while receiving a phone call, with a high degree of probability we can say that you cannot do without debugging on a real device. Luckily, Eclipse contains everything you need to accomplish this task.

Connecting the phone and launching the program

Before connecting your phone to your computer with via USB data cable, several preparations must be made. The fact is that Eclipse is configured to work with an emulator by default, and we need to adjust the debug mode configuration. It's simple. Select the menu item Run > Debug Configuration, and then DroidDebug. On the Target tab, in the Deployment Target Selection Mode section, you need to set the switch to Manual and click Apply. Thus included manual mode choosing a platform. Now, when you launch the application, a dialog box will appear where you can select the emulator or one of the connected phones.

In order for the phone to work in debug mode, it also needs to be configured accordingly. While on home screen, you need to click on the Menu button and find the “Settings” application. In this application, open the “Applications” section, and then the “Development” item. In the screen that opens, you need to check the box next to “USB Debugging” (USD Debgging). This sequence of actions works on most phones, but it is quite possible that on your device the UBS debugging mode is enabled somewhere else.

Connect your phone to your computer and click the Debug button in Eclipse. In the dialog box that appears, you will see two lists: “Choose a running Android device” and “Launch a new Android Virtual Device”. The first of them lists phones connected to the computer, the second - emulators. Select your phone from the first list. Eclipse will install the application you are debugging on your phone and launch it. You can debug your program.

Phone status monitoring DDMS (Dalvik Debug Monitor Service)

All information about the phone's status is available through a special tool called the DDMS (Dalvik Debug Monitor Service) monitoring service. To launch it, click the android button in the top right corner of Eclipse.

The DDMS window consists of several panels. The Devices panel displays a list of available emulators and connected phones. Here is a list of those running in this moment processes. Each process runs in its own virtual machine. Threads are displayed on a separate Threads tab. The File Explorer tab is designed to work with the phone's file system. With it, you can copy files from your computer to your phone and back. Using the Screen Capture button, you can take a screenshot of your phone screen. The green bug button allows you to attach a debugger to the selected process. To use this feature, you must have the process open source.

Also worth noting is the LogCat logging utility and its corresponding panel, which can be very useful when searching for errors. Working with the log is carried out through a special class android.util.Log. The most commonly used methods are:

Log.e() - for logging errors,
Log.w() - for logging warnings,
Log.i() - for logging information messages,
Log.d() - for debug logging,
Log.v() - for logging detailed records,

These methods must be passed two strings as parameters. The first is a tag, which can then be used for searching and filtering in LogCat. The second is the actual information that is entered into the journal.

Android studio debugging on a real device. Debugging an Android application on a smartphone