Method to Modify the Hex of Android Manifest

File in Android Apps for Dynamic Analysis

Suhyoo Lee(&), Junhoo Park, and Jaecheol Ryou

Department of Computer Science, CNU, Daejon, Korea

[email protected]

Abstract. Analysts sometimes need to analyze the app depending on the situa-
tion. There are two main ways to analyze Android apps. This is the static analysis
that grasps the flow of the app through the source code and the dynamic analysis
that analyzes the variable that changes during the app’s operation. For dynamic
analysis, this can be done by setting the debugging option of the Android Manifest
file. In most cases, modification is done by decompiling the app and modifying the
original source. In some cases, however, there is a problem with the decompiling
process. So we propose a way to modify the debugging option of the Android
manifest file to “true” without decompiling the app.

Keywords: Android
Dynamic analysis
Debugging
Android Manifest file

1 Introduction

Since Android’s market share is overwhelmingly higher than other operating systems,
the number of malicious apps for Android is also increasing. In 2016, 37 million
malwares were found around the world [1]. As the frequency and risk of malicious app
increases, analysts need to understand malicious apps’ operating algorithms to detect
and prevent malicious apps. Analysts use a technique called debugging to identify
operating algorithms. Debugging on various operating systems, including Android, is
divided into two types: static analysis and dynamic analysis.
Static analysis is a method of analyzing the source code to understand the operation
algorithm for the program. On Android, tools like dex2jar and jeb is used to analyze
app’s Java code. There are studies where static analysis has detected a potential risk. In
the paper by Hyun Seo et al., they detected potential threat of homeland apps thorough
static analysis [2]. However, there are obvious limitations because the static analysis
only understands the operation algorithm of the code with the source code. Analysts
therefore use a technique called dynamic analysis to overcome these limitations.
Dynamic analysis is suitable for understanding the value of a variable or the progress of
a function call during a program’s operation. Android development program, Android
Studio, provides dynamic analysis for Android developers and analysts. This feature is
only available if the debuggable option of the AndroidManifest.xml file in the Android
app is set to “true”. By default, the debuggable option is set to a “false” value for
deployed apps. Therefore, in order to use the dynamic analysis function, it is necessary
to modify the debuggable option of the AndroidManifest.xml file of Android malicious

© Springer Nature Singapore Pte Ltd. 2018

J. J. Park et al. (eds.), Advances in Computer Science
and Ubiquitous Computing, Lecture Notes in Electrical Engineering 474,
https://doi.org/10.1007/978-981-10-7605-3_125
 Method to Modify the Hex of Android Manifest File in Android Apps 785

app (or other Android application) to a “true” value. Generally, when trying to modify
AndroidManifest.xml, decompile the entire application and modify the file. It is dif-
ficult to modify AndroidManifest.xml if the decompile process is not done properly at
this time. Therefore, this paper proposes a method to modify AndroidManifest.xml
without decompiling.

2 Structure of Android Manifest File

The Android Manifest file (AndroidManifest.xml) is a file that contains essential

information about the apps that the Android system must acquire before running the
Android app. The file contains a debuggable option for dynamic analysis of Android
app the Android Manifest file is in the apk root directory. An Android Manifest file that
is not decompiled can’t check the plaintext of the contents of the file. Therefore, in
order to change the file, we decides to change the binary hex value of the file. So, in
this chapter, before changing the file, look at the structure of Android’s manifest file.
The Android manifest file can be divided into six major parts: Header, String
chunk, Resource chunk, Namespace chunk, Tag chunk and Attribute chunk. Structure
of Android Manifest file is based on 101 editor [3] and the post [4]. Values that do not
mention otherwise are inserted into Little Endian.

2.1 Header
The header contains the file signature and file size for the Android Manifest file. The
file signature of the Android Manifest file is fixed to “03 00 08 00”. The file size is the
total file size of AndroidManifest.xml.

2.2 String Chunk

A string chunk is a part that controls information on a string values. The Android
Manifest refers to the string being used through the string chunk. The beginning of the
string chunk is a string chunk signature. When the calculation of the total size of string
chunk is completed, the total number of the string (total string count) and the total
number of the style inserted. The number of string is the total number of string used by
the Android Manifest file. This is equal to the number of strings in the string list at the
end of the string chunk. We will not consider the number of styles, since it is not
necessary for changing the debuggable option which is the ultimate goal of this paper.
Further, in the future, values related to styles are just merely mentioned, detailed
explanation will be omitted. When the calculation of the number of strings is com-
pleted, the NULL value of 8 bytes and the string offset comes after. The string offset is
an address where the value of the string substantially exists in the Android Manifest
file. When the computation of the string offset is completed, the style related value is
included only 4 bytes, and the relative offset of each string value continues.
786 S. Lee et al.

The starting address starts with “00 00 00 00”, and the address for the next string
value is calculated as follows.

Addr of next str ¼ 2 þ len of prev:str  2 þ 2 ð1Þ

This is the same as each value of the string list.

The last structure of the string chunk after the calculation on the offset of each
string is the list of all the strings used in the Android Manifest file. Each string is
inserted in the same way. The first 2 bytes are the total length of the string. Next, each
character of the string and NULL value are inserted and the value of one character
string is finished with 2 bytes of NULL value.

2.3 Resource Chunk and Namespace Chunk

A resource chunk is a chunk that controls resources used in the Android Manifest. This
chunk is divided into three parts: Signature, resource chunk size, each resource.
First, the resource chunk signature has a fixed value of “80 01 08 00”. The resource
chunk size refers to the size of the entire resource chunk from the signature to the last
resource item. Finally, each resource items are inserted. For information related to
resources, refer to android source [5].
Namespace chunks are divided into a start namespace chunk (SNC) and an end
namespace chunk (ENC).
A SNC is inserted after the resource chunk, and the chunk includes the following
elements: signature, size, line number, null, prefix, and uri. The signature is a value
fixed to “00 01 10 00”. Size is the overall size from the signature part of the SNC to the
end. The 4 bytes inserted subsequently are the line numbers where the elements from
the original source were inserted. Subsequently, a fixed comment with 4 bytes of “FF
FF FF FF” is inserted. Each 4 bytes prefix and uri are added in succession. Prefix and
Uri are present in the string list of string chunk. This means that if a new string
(debuggable in this paper) is added, there is a change in the string list. So prefix and uri
modifications are unavoidable.
The structure of ENC is almost the same as SNC. However, there is a difference
that the signature value of ENC is fixed to “01 01 10 00”.

2.4 Tag Chunk and Attribute Chunk

Tag chunks are divided into start tag chunks (STC) and end tag chunks (ETC) similar
to namespace chunks. The tag chunk is divided into a signature, a size, a line number, a
namespace, a name, an attribute flag, and an attribute count. To begin with, the STC
begins with the signature “02 01 10 00”. The total size of the STC is the size from the
signature to the last attribute. This size is the value that should be modified when the
debuggable option is added. The next inserted value is the line number and the com-
ment, each 4 bytes. Then, if there is a namespace in the tag chunk, a value for the
namespace is added, and if it does not exist, it is set to the value of “FF FF FF FF”. The
Name element is the order of the corresponding string in the string list which is part of
the string chunk. The subsequent 4 bytes have an attribute start point and attribute size,
 Method to Modify the Hex of Android Manifest File in Android Apps 787

2 bytes each. In most cases this is fixed to “14 00 14 00”. The following part is directly
related to attribute. The Attribute count is the actual number of attributes belong to that
tag. When adding the debuggable option, this value is incremented by one. After 4 byte
of NULL value, actual attribute chunk begins. ENC is the same as SNC except that the
signature is fixed at “03 01 10 00”, the line number changes, and attribute chunk is not
included.
Attribute chunk belongs to tag chunk. In addition, this chunk has a simpler structure
than other chunks: Namespace uri, name, value string, type, data.
Namespace uri is the same as uri of namespace chunk. Name is 4 bytes, and its
value will be determined according to the order of string list in string chunk like the
previously used name. Value string is a string that is actually used in attribute chunk,
and that string is also defined according to the order of the string in the string chunk.
Type value is the type used in attribute. Starting with “08 00”, the type is defined by the
remaining two bytes. Every values of each types are listed in the Android source. The
remaining 4 bytes correspond to the data and depend on the type of each attribute. This
corresponds to the actual value of the attribute.

3 Method to Modify AndroidManifest.xml

Apps can have debuggable string depends on developer. So to change Android

Manifest file for dynamic debugging, we have to consider two cases: app with
debuggable option and app without debuggable option.

3.1 Case 1: Apps with Debuggable String

Before the modifying procedure, we have to find out there is a debuggable string in
app. For this, we have to extract all the list of strings. If we found debuggable in the
string list, it means that the app contains debuggable option. In this case, file can be
modified by changing data part of debuggable option to “true” value. The procedure is
as follows.
First find out order of debuggable string. Count 0 from the start of string list, we
have to find out where the debuggable string locates. The order of debuggable string
goes to name of attribute chunk. Second, we have to search the offset of application
STC. Because debuggable option is attribute chunk and attribute chunk is included in
tag chunk, finding “application” tag which is the parent tag chunk of debuggable option
is necessary. Procedure of finding application STC is accomplished with signature of
tag chunk and order of application. So compare with STC signature and the name, we
can find out STC of “application” which debuggable option belongs in. Third proce-
dure is changing value of debuggable option to true. We can find out offset of
debuggable attribute chunk, so change the data part of it to “FF FF FF FF”.

3.2 Case 2: Apps Without Debuggable String

In this case, app doesn’t contain debuggable string, so we have to create attribute chunk
for debuggable option. First string chunk should be modified. In order to add
788 S. Lee et al.

debuggable string to string chunk, string count must be increased by one. And add four
to starting point of string offset because we added debuggable string in string list. Third
procedure in string chunk is adding offset of debuggable string in string offset. Because
order of string is important, so debuggable should be added as element of “application”
tag. After adding string offset, final procedure in string chunk is inserting debuggable
string in string list. Follow the rule that mentioned in Sect. 2. Second procedure of full
modification is modifying resource chunk. Find out resource value of debuggable and
insert it in resource chunk. It should be inserted with specific order. Third procedure is
find out the location of “application” tag. Through the method mentioned in case 1, we
can easily find out location of “application” tag. We want to add one more attribute
chunk in application tag, so attribute count increases by one. After increasing, make the
attribute chunk for debuggable option. Refer to attribute chunk, input the appropriate
value for the debuggable and check the order of attributes. Finally, change every name,
prefix, and uri which is larger than order of debuggable to fit in order of string list.
After that procedure, change full size of files in Header. After all procedures, app is
successfully modified for dynamic analysis.

4 Discussion

In order to test whether the proposed method can successfully make dynamic analysis
environment, we conducted experiment. The experiment is to test the dynamic analysis
environment by changing the malicious app that was actually deployed.
The common process is as follows. Obtain the Apk file and decompress it. Extract
the Android Manifest file from the decompressed apk and modify it by using the
proposed method. Put the modified Android Manifest file in apk and compress it again.
Install Apk on your smartphone and see if it can be dynamically analyzed via Android
Studio. If the Android Manifest file has been modified and does not follow the form of
Android Manifest file, the syntax “Failure [INSTALL_FAILED_INVALID_APK]” is
invoked when installing the Android application and the application is not installed.
Since the application including modified Android manifest file using the proposed
method has been successfully installed, this can also guarantee the fact that this method
is right.
The experiment was tested with the Droid Jack, which was an Android malicious
app. The Droid Jack is an app that makes it possible to gain control of the smartphone
by changing the famous mobile game [6]. To analyze the app dynamically, we first
tried dynamic analysis through the Android Studio without modifying the Android
Manifest file. As a result, no dynamic analysis apps were found as shown in Fig. 1.
Figure 2 shows the modified application in Android Studio. This makes it possible
to confirm that the proposed method works successfully even in a malicious app not
only in a simple testing application.
 Method to Modify the Hex of Android Manifest File in Android Apps 789

Fig. 1. Original Droid Jack Fig. 2. Modified Droid Jack

5 Conclusion

In this paper, we proposed method to modify the Android Manifest file for dynamic
analysis of Android apps. With modifying attribute chunk of debuggable string,
applications can be dynamically analyzed. As described in Sect. 4, it is possible to
analyze a malware application by a proposed method. However this method is only be
used for apps which obfuscation is not applied. Therefore in the future work, we will
proceed study about obfuscated Android Manifest file to modify it for dynamic anal-
ysis. First analyze obfuscated Android Manifest file structure and find out difference
between obfuscated one and the original one. After that procedure, we will adjust our
modification method to fit the obfuscated Android Manifest file. Through the future
work, we assume that it is useful for analyze Android app dynamically.

Acknowledgments. This work was supported by Institute for Information & communications
Technology Promotion (IITP) grant funded by the Korea government (MSIT) (R0190-17-2009,
Development of endpoint protection technology using white list and context-aware).

References
1. Mcafee Android malicious apps. https://www.mcafee.com/us/resources/reports/rp-mobile-
threat-report-2016.pdf
2. Seo, S.-H., Gupta, A., Sallam, A.M., Bertino, E., Yim, K.: Detecting mobile malware threats
to homeland security through static analysis. J. Netw. Comput. Appl. 38, 43–53 (2014).
ELSEVIER
3. 010 editor. https://www.sweetscape.com/010editor/
4. Android Manifest structure. https://justanapplication.wordpress.com/category/android
5. Android source. https://android.googlesource.com/platform/frameworks/base
6. Malicious app. http://blog.alyac.co.kr/711