CYBER321 | Modhi Bin Kulib

Practical Project: Application Threat

Analysis

dummy.sh figure
Using gedit, create a file named dummy.sh and write what is echoed in there.

We then create update-binary file that is executed by the recovery OS to apply

OTA updates.

It will copy our dummy file to /system/xbin folder, make it executable and edit the
init.sh file to include our dummy.sh so that it is automatically executed with the
root privilege when Android boots up.

| P a g e 10
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

This shows the created files; dummy.sh and update-binary and the content in them.
Also, it has shown how to make the bin file update-binary executable

Step 2: Build the OTA Package.

Now switch to directory containing AR/ folder and we archive the folder.

| P a g e 11
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

This the zipped file of AR which will help us to transfer into the recovery ubuntu
OS

Step 3: Run the OTA Package

First, we boot onto the Recovery OS in Android VM and check for the IP address
of the OS. To boot in this OS, you will press the left shift key and holding it when
starting the android OS.

| P a g e 12
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

Check the ip address using ifconfig then move the zip file over to the Recovery OS
in the /tmp folder as shown below; the password is ‘dees’.

| P a g e 13
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

This will be from the seed ubuntu VM to the recovery OS ubuntu using the scp
transfer protocol.

In the Recovery OS, we unzip the received file.

| P a g e 14
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

We then execute the update-binary file using sudo ./update-binary command and
reboot the system. When the Android VM completes rebooting, we launch the
Terminal and check the /system directory and verify result whether a dummy file
was created. Also, we check the xbin folder to see if the dummy shell script has
been created.

| P a g e 15
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

This screenshot indicates that we were successful in creating a file in a folder that
required root privileges by modifying the init.sh file that allows us to run the
program automatically with the root privileges during the initialization of the
under-lying Linux OS of the Android.

Task 2: Inject code via app process

In the previous task, the the init.sh file was modified to get our injected program to
run automatically, and with the root privilege. This initialization script file is used
by the underlying Linux operating system.
The objective of this task is to execute our injected program during this
bootstrapping process. Once the Linux is initialized, Android OS will bootstrap its
runtime that is built on top of Linux. We need to understand how Android gets
bootstrapped.

| P a g e 16
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

*Now we perform the same attack using the app_process program running with
root privileges during the bootstrapping process of Android. In addition for the
app_process to run the Zygote daemon, whose mission is to launch applications. This
means that Zygote is the parent of all app processes.

we also run something else of our own choice. We rename the original app process
binary to app process original and call our program the app process. In our
program, we first write something to the dummy file, and then invoke the original
app process program. We save this file as app_process.c.

These are the three files created:

These tree files used as app_proccess to gain root shell on the android devices.
1. app_process.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
extern char** environ;
int main(int argc, char** argv) {
//Write the dummy file
FILE* f = fopen("/system/dummy2", "w");
if (f == NULL) {
printf("Permission Denied.\n");
exit(EXIT_FAILURE);
}
fclose(f);
//Launch the original binary
char* cmd = "/system/bin/app_process_original";
execve(cmd, argv, environ);
//execve() returns only if it fails
return EXIT_FAILURE;

| P a g e 17
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

2. Application.mk
APP_ABI := x86
APP_PLATFORM := android-21
APP_STL := stlport_static
APP_BUILD_SCRIPT := Android.mk

3. Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := app_process
LOCAL_SRC_FILES := app_process.c
include $(BUILD_EXECUTABLE)

Step 1. Compile the code.

We make changes in Android.mk to include our app_process.c and then compile
Application.mk using NDK libraries. We see that the binaries have been created in
libs/x86 folder.

(NDK) is a set of tools that allows you to use C and C++ code with Android

| P a g e 18
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

Step 2. Write the update script and build OTA package.

• Finally, we archived the OTA package and send to the the recovery OS as
shown in the TASK 3. After that we unzipped the file inside the recovery OS
and running the update-binary script. Lastly we reboot the recovery OS to
make the changes

We copy the previously created binary file in the android folder of the OTA
package.

We create update-binary to rename the original app_process64 and then copy our
app_process to replace the original one and also make it executable.

We start the recover OS on the Android VM to send the zipped file like we did in
taks one files.

| P a g e 19
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

Unzip task2.zip and run update-binary and reboot to Android OS.

Execute update binary:

In Android OS, we open a terminal and check the system directory.

| P a g e 20
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

We see that dummy2 is created in /system directory which tells us that our code
was compiled successfully, and OTA was flashed. This proves that we can use the
app_process during the bootstrapping process to write to a root-protected folder.

Task 3: Implement SimpleSU for Getting Root Shell

We perform a similar attack to gain root shell. We first download Simplesu.zip and
extract it. We run bash compile_all.sh which generates the binaries of
mydaemonsu and mysu as seen in the following screenshot.

We copy these two binaries in the OTA package in the following location:
task3/x86

| P a g e 21
CYBER321 | Modhi Bin Kulib
Practical Project: Application Threat
Analysis

We also create update-binary to move our newly compiled binaries to their

corresponding locations in android /system directories. We also include the
commands to make the binaries executable.

We then start the recovery OS on the Android VM and we archive the task3 folder
and transfer the archive over to the Recovery OS. We then unzip our transferred
archive. We go over to /android directory and run update-binary. We then reboot to
Android OS.

| P a g e 22