Dex
Dex文件结构
classes.dex文件是Android系统运行于Dalvik Virtual Machine上的可执行文件，也是Android应用程序的核心所在，所以我们首先来看下DEX文件的结构，这样能够更好的理解后续的分析，需要更加详细的信息，可以参考Google关于Dex的技术文档。
从Java源文件（当然Android也支持JNI的调用方式）到生成Dex文件的基本映射关系如图 1所示，Java源文件通过Java编译器生成class文件，再通过dx工具转换为classes.dex文件。Dex文件从整体上来看是个索引的结构，类名、方法名、字段名等信息都存储在常量池中，这样能够充分减少存储空间，一个Dex文件的基本结构如图 2所示，相关结构声明定义在DexFile.h中，在AOSP中的路径为/dalvik/libdex/DexFile.h。
图 1 Java源文件生成Dex文件的映射关系
Ÿ header: Dex文件头，包含magic字段、adler32校验值、SHA-1哈希值、string_ids的个数
图 2 Dex文件基本结构
以及偏移地址等。Dex文件头结构固定，占用0×70个字节，定义如下所示。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
struct
DexHeader
{
u1
magic
[
8
]
;
/* includes version number */
u4
checksum
;
/* adler32 checksum */
u1
signature
[
kSHA1DigestLen
]
;
/* SHA-1 hash */
u4
fileSize
;
/* length of entire file */
u4
headerSize
;
/* offset to start of next section */
u4
endianTag
;
u4
linkSize
;
u4
linkOff
;
u4
mapOff
;
u4
stringIdsSize
;
u4
stringIdsOff
;
u4
typeIdsSize
;
u4
typeIdsOff
;
u4
protoIdsSize
;
u4
protoIdsOff
;
u4
fieldIdsSize
;
u4
fieldIdsOff
;
u4
methodIdsSize
;
u4
methodIdsOff
;
u4
classDefsSize
;
u4
classDefsOff
;
u4
dataSize
;
u4
dataOff
;
}
;
|
Ÿ DexStringId: 定义了字符串数据的偏移， stringDataOff指向字符串数据；
|
1
2
3
|
struct
DexStringId
{
u4
stringDataOff
;
/* file offset to string_data_item */
}
;
|
Ÿ DexTypeId: 表示应用程序代码中使用到的具体类型，如整型、字符串等，在Dalvik字节码中表示为I、Ljava/lang/String;，descriptorIdx指向DexStringId列表的索引；
|
1
2
3
|
struct
DexTypeId
{
u4
descriptorIdx
;
/* index into stringIds list for type descriptor */
}
;
|
Ÿ DexProtoId：表示方法声明的结构体，shortyIdx是方法声明字符串，格式为返回值类型后紧跟参数列表类型，如方法声明为VI，表示返回值为V（空，无返回值），参数为I（整型），所有的引用类型用L表示；returnTypeIdx指向DexTypeId列表的索引，表示返回值类型；parametersOff指向DexTypeList的偏移，表示参数列表类型；
|
1
2
3
4
5
|
struct
DexProtoId
{
u4
shortyIdx
;
/* index into stringIds for shorty descriptor */
u4
returnTypeIdx
;
/* index into typeIds list for return type */
u4
parametersOff
;
/* file offset to type_list for parameter types */
}
;
|
Ÿ DexFieldId: 表示代码中的字段，classIdx指向DexTypeId列表索引，表示字段所属的类；typeIdx表示字段类型，nameIdx指向DexStringId列表索引，表示字段名；
|
1
2
3
4
5
|
struct
DexFieldId
{
u2
classIdx
;
/* index into typeIds list for defining class */
u2
typeIdx
;
/* index into typeIds for field type */
u4
nameIdx
;
/* index into stringIds for field name */
}
;
|
Ÿ DexMethodId: 表示代码中使用的方法，classIdx表示方法所属的类，protoIdx指向DexProtoId列表索引，表示方法原型，nameIdx表示方法名；
|
1
2
3
4
5
|
struct
DexMethodId
{
u2
classIdx
;
/* index into typeIds list for defining class */
u2
protoIdx
;
/* index into protoIds for method prototype */
u4
nameIdx
;
/* index into stringIds for method name */
}
;
|
Ÿ DexClassDef: 该结构相对要复杂一些，定义了代码中的使用的类，以及相关的代码指令。
|
1
2
3
4
5
6
7
8
9
10
|
struct
DexClassDef
{
u4
classIdx
;
/* index into typeIds for this class */
u4
accessFlags
;
u4
superclassIdx
;
/* index into typeIds for superclass */
u4
interfacesOff
;
/* file offset to DexTypeList */
u4
sourceFileIdx
;
/* index into stringIds for source file name */
u4
annotationsOff
;
/* file offset to annotations_directory_item */
u4
classDataOff
;
/* file offset to class_data_item */
u4
staticValuesOff
;
/* file offset to DexEncodedArray */
}
;
|
classIdx指向DexTypeId列表索引，表示该类的类型；accessFlags是类的访问标志，如public,private，static等；superclassIdx表示父类的类型；interfacesOff指向一个DexTypeList的偏移值，因为Java中可以实现多个接口，这里使用列表也就不难理解了；sourceFileIdx指向DexStringIdx列表的索引，表示类所在的源文件名称；annotationsOff指向注解目录结构；classDataOff指向DexClassData结构，表示类的数据部分；staticValuesOff表示类中的静态数据。
Ÿ DexClassData结构体定义在DexClass.h文件中，路径为/dalvik/libdex/DexClass.h，声明如下，header中包含静态字段个数，实例字段个数，直接方法（通过类直接访问的方法）个数，虚方法（通过类实例访问的方法）个数；
|
1
2
3
4
5
6
7
|
struct
DexClassData
{
DexClassDataHeader
header
;
DexField
*
staticFields
;
DexField
*
instanceFields
;
DexMethod
*
directMethods
;
DexMethod
*
virtualMethods
;
}
;
|
DexField表示字段的类型和访问标志， fieldIdx指向DexFieldId;
|
1
2
3
4
|
struct
DexField
{
u4
fieldIdx
;
/* index to a field_id_item */
u4
accessFlags
;
}
;
|
DexMethod结构描述了方法的原型、名称、访问标志以及代码指令的偏移地址，methodIdx指向DexMethodId索引，需要注意的是在Google的Dex文件文档中对此的定义：
index into the method_ids list for the identity of this method (includes the name and descriptor), represented as a difference from the index of previous element in the list. The index of the first element in a list is represented directly.
注意红色字体部分，表示的是在Dex文件中，methodIdx是相对于前一个DexMethod中的methodIdx的增量，例如如果一个类中有两个directMethods，第一个directMethod的methodIdx值为0×13，表示指向索引为0×13的methodIdx，那么第二个directMethod的methodIdx的值是相对于前一个值的增量，例如0×01，表示指向索引为0×14的methodIdx；accessFlags为方法的访问标志，codeOff表示指令代码的偏移地址；
|
1
2
3
4
5
|
struct
DexMethod
{
u4
methodIdx
;
/* index to a method_id_item */
u4
accessFlags
;
u4
codeOff
;
/* file offset to a code_item */
}
;
|
DexCode的结构体声明如下。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
struct
DexCode
{
u2
registersSize
;
u2
insSize
;
u2
outsSize
;
u2
triesSize
;
u4
debugInfoOff
;
/* file offset to debug info stream */
u4
insnsSize
;
/* size of the insns array, in u2 units */
u2
insns
[
1
]
;
/* followed by optional u2 padding */
/* followed by try_item[triesSize] */
/* followed by uleb128 handlersSize */
/* followed by catch_handler_item[handlersSize] */
}
;
|
需要注意的是，在DexClass.h中，所有的u4类型，实际上是uleb128类型。每个uleb128类型是leb128的无符号类型，每个leb128类型的数据包含1-5个字节，表示一个32bit的数值。每个字节只有7位有效，最高一位用来表示是否需要使用到下一个字节，比如如果第一个字节最高位为1，表示还需要使用到第2个字节，如果第二个字节的最高位为1，表示会使用到第3个字节，以此类推，最多5个字节。对于一个2个字节的leb128类型数据，其结构如图 3所示。
图 3 两字节的leb128类型数据格式
Dex中方法的隐藏
此部分内容可参考Playing Hide and Seek with Dalvik Executables。
前文分析了Dex文件的结构，根据Dex的文件结构，可以实现对Dex中特定方法的隐藏，这样在使用baksamli或者apktool工具对classes.dex文件进行反汇编时，无法发现隐藏的方法，不过会有特定的现象发生，其实也是比较容易检测出来的。
在Dex文件格式分析中关于method的结构体是DexMethod，如果将methodIdx的值指向另一个method，同时修改相应的代码偏移量codeOff（accessFlags一般不需要修改），修改后续相应的methodIdx，则可以实现特定方法的隐藏。对Dex文件修改后需要重新计算Dex文件的SHA1值以及校验值，用来更新Dex文件。
隐藏方法的步骤如下：
Ÿ 1、修改Dex文件中需要隐藏方法的DexMethod结构体，如图 4所示，图中隐藏了方法B。具体包括：
- Ÿ 将DexMethod的methodIdx值设为0×0，相当于将原先的方法指向了前一个方法；
- Ÿ 访问标志符accessFlags一般不需要修改，在Dex文件格式里，directMethods和virtualMethods是分开的；
- Ÿ 将codeOffset设置为前一个方法的代码偏移地址。
- Ÿ 更新需隐藏方法的下一个方法的methodIdx，可以使用公式：next_method_idx=original_next_method_idx + original_method_idx
图 4 Dex方法隐藏
Ÿ 2、重新计算Dex的SHA1哈希值和Adler校验值，并用以更新DexHeader，可以使用DexFixer修复classes.dex文件；
Ÿ 3、重新打包生成APK文件：
- Ÿ 将APK解压缩，提取其中出META-INF文件夹之外的所有文件；
- Ÿ 压缩成Zip格式文件；
- Ÿ 使用jarsigner或者其他工具对生成的Zip文件签名，后缀名修改成.apk。
隐藏的方法仍然需要在程序中进行调用，调用隐藏方法的步骤如下：
- Ÿ 使用反射调用android.content.res.AssetManager.openNonAsset方法打开当前应用程序的classes.dex文件，将数据保存到内存中；还可以通过调用Context.getPackageCodePath()来获得当前应用程序对应的apk文件的路径，利用此路径构造ZipFile对象，进而获取classes.dex的ZipEntry，利用ZipFile的getInputStream(ZipEntry)方法获取classes.dex的数据流，核心代码如下所示；
|
1
2
3
4
|
String
apkPath
=
this
.
getPackageCodePath
(
)
;
ZipFile
apkfile
=
new
ZipFile
(
apkPath
)
;
ZipEntry
dexentry
=
zipfile
.
getEntry
(
“classes.dex”
)
;
InputStream
dexstream
=
zipfile
.
getInputStream
(
dexentry
)
;
|
- Ÿ 修复Dex文件，将之前隐藏方法的DexMethod结构体恢复；
- Ÿ 将修复后的Dex数据使用类加载器重新加载；
- Ÿ 搜索被隐藏的方法；
- Ÿ 调用被隐藏的方法。
需要注意的是，方法在Dex文件中是按方法名的字典序排序的，所以需要隐藏的方法如果是该类中所有方法排序第一个的话，那么methodIdx值是个绝对值，如果要隐藏的话就不是很方便，所以建议可以写个无用的方法，其方法名排序为第一个，让需要隐藏的方法重新指向该方法。
使用修改methodIdx的方法，让其指向另一个DexMethodId的结构体，如果使用baksmali进行反汇编，则会发现在一个类中有两个完全相同的函数。
那有没有更加隐蔽的手段来隐藏一个方法了？考虑到在DexClassData结构体中的DexClassDataHeader头部，其中directMethodsSize和virtualMethodsSize分别表示直接方法个数和虚方法个数，因此如果希望隐藏某个方法，可以通过将相应的directMethodsSize或virtualMethodsSize减1，同时将表示该需要隐藏方法的DexMethod结构体中的数据全部修改为0，这样就可以将该方法隐藏起来，使用baksmali反汇编时，不会显示出该方法的反汇编代码，具体可以参考Hashdays 2012 Android Chanllenge。
当然，上述这两种隐藏方法，都没能隐藏掉DexMethodId结构体，这个结构体中包含了方法所属的类名、原型声明以及方法名，所以可以通过对比DexMethodId的个数和DexMethod结构体的个数来判断是否存在方法隐藏的问题。
Dex完整性校验
classes.dex在Android系统上基本负责完成所有的逻辑业务，因此很多针对Android应用程序的篡改都是针对classes.dex文件的。在APK的自我保护上，也可以考虑对classes.dex文件进行完整性校验，简单的可以通过CRC校验完成，也可以检查Hash值。由于只是检查classes.dex，所以可以将CRC值存储在string资源文件中，当然也可以放在自己的服务器上，通过运行时从服务器获取校验值。基本步骤如下：
- Ÿ 首先在代码中完成校验值比对的逻辑，此部分代码后续不能再改变，否则CRC值会发生变化；
- Ÿ 从生成的APK文件中提取出classes.dex文件，计算其CRC值，其他hash值类似；
- Ÿ 将计算出的值放入strings.xml文件中。
核心代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
String
apkPath
=
this
.
getPackageCodePath
(
)
;
Long
dexCrc
=
Long
.
parseLong
(
this
.
getString
(
R
.
string
.
dex_crc
)
)
;
try
{
ZipFile
zipfile
=
new
ZipFile
(
apkPath
)
;
ZipEntry
dexentry
=
zipfile
.
getEntry
(
“classes.dex”
)
;
if
(
dexentry
.
getCrc
(
)
!=
dexCrc
)
{
System
.
out
.
println
(
“Dex has been modified!”
)
;
}
else
{
System
.
out
.
println
(
“Dex hasn’t been modified!”
)
;
}
}
catch
(
IOException
e
)
{
// TODO Auto-generated catch block
e
.
printStackTrace
(
)
;
}
|
但是上述的保护方式容易被暴力破解， 完整性检查最终还是通过返回true/false来控制后续代码逻辑的走向，如果攻击者直接修改代码逻辑，完整性检查始终返回true，那这种方法就无效了，所以类似文件完整性校验需要配合一些其他方法，或者有其他更为巧妙的方式实现？
APK完整性校验
虽然Android程序的主要逻辑通过classes.dex文件执行，但是其他文件也会影响到整个程序的逻辑走向，以上述Dex文件校验为例，如果程序依赖strings.xml文件中的某些值，则修改这些值就会影响程序的运行，所以进一步可以整个APK文件进行完整性校验。但是如果对整个APK文件进行完整性校验，由于在开发Android应用程序时，无法知道完整APK文件的Hash值，所以这个Hash值的存储无法像Dex完整性校验那样放在strings.xml文件中，所以可以考虑将值放在服务器端。核心代码如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
MessageDigest
msgDigest
=
null
;
try
{
msgDigest
=
MessageDigest
.
getInstance
(
“MD5″
)
byte
[
]
bytes
=
new
byte
[
8192
]
;
int
byteCount
;
FileInputStream
fis
=
null
;
fis
=
new
FileInputStream
(
new
File
(
apkPath
)
)
;
while
(
(
byteCount
=
fis
.
read
(
bytes
)
)
>
0
)
msgDigest
.
update
(
bytes
,
0
,
byteCount
)
;
BigInteger
bi
=
new
BigInteger
(
1
,
msgDigest
.
digest
(
)
)
;
String
md5
=
bi
.
toString
(
16
)
;
fis
.
close
(
)
;
/*
从服务器获取存储的Hash值，并进行比较
*/
}
catch
(
Exception
e
)
{
e
.
printStackTrace
(
)
;
}
|
动态加载
Java中可以使用反射技术来更加灵活地控制程序的运行，为Java运行时的行为提供了强大的支持。Android系统提供了DexClassLoader来支持在程序运行过程中动态加载包含classes.dex的.jar或者.apk文件，如果再结合Java反射技术，可以实现执行非应用程序部分的代码。利用动态加载技术，可以提供逆向分析的难度，在一定程度上可以保护APK自身的业务逻辑防止被破解。
DexClassLoader的构造函数原型如下：
|
1
|
public
DexClassLoader
(
String
dexPath
,
String
optimizedDirectory
,
String
libraryPath
,
ClassLoader
parent
)
|
其中，dexPath为包含dex文件的.apk或者.jar路径，optimizedDirectory是优化后的dex文件的路径，libraryPath表示Native库的路径，parent是父类加载器。通过DexClassLoader实例化对象，调用loadClass加载需要调用的类，获得Class对象后，就可以进一步使用Java反射技术来调用相应的方法。如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
DexClassLoader
classLoader
=
new
DexClassLoader
(
apkPath
,
dexPath
,
null
,
getClassLoader
(
)
)
;
try
{
Class
<?
>
mLoadClass
=
classLoader
.
loadClass
(
“com.example.dexclassloaderslave.DexSlave”
)
;
Constructor
<?
>
constructor
=
mLoadClass
.
getConstructor
(
new
Class
[
]
{
}
)
;
Object
dexSlave
=
constructor
.
newInstance
(
new
Object
[
]
{
}
)
;
Method
sayHello
=
mLoadClass
.
getDeclaredMethod
(
“sayHello”
,
new
Class
[
]
{
}
)
;
sayHello
.
setAccessible
(
true
)
;
sayHello
.
invoke
(
dexSlave
,
new
Object
[
]
{
}
)
;
}
catch
(
Exception
e
)
{
e
.
printStackTrace
(
)
;
}
|
上述代码实现调用com.example.dexclassloaderslave.DexSlave类中的sayHello方法。
对于需要通过DexClassLoader被调用的.apk或者.jar文件的分发，可以将其放入Android项目的assets或者res目录下，也可以将其放在服务器端，在实际需要调用时通过网络获取文件。为了提高逆向的难度，可以对被调用的.apk或者.jar文件采取以下措施进行进一步的保护：
- Ÿ 进行完整性校验，防止文件被篡改；
- Ÿ 进行加密处理，在调用加载前进行解密；
- Ÿ 对需要调用的函数相关信息使用通过网络获取的方式，而不是硬编码在代码中，可以真正实现动态调用，提高静态分析的难度；
- Ÿ 对于使用网络服务器分发的方式，注意对网络服务器地址的保护，不要以字符串硬编码的方式写在代码中，对下载请求也需要使用cookie等辅助识别的技术。
除了使用DexClassLoader类实现动态加载外，还可以使用dalvik.system.DexFile类实现Dex文件的加载，但是DexFile类提供的构造方法在实例化过程中需要在/data/davik-cache目录下生成相应的Dex文件，而/data/davik-cache目录对于一般应用程序是没有写权限的，所以在程序中无法实例化DexFile对象，也就无法调用DexFile.loadClass方法。所以需要通过反射调用DexFile类的openDex方法，具体可以参考该代码中invokeHidden函数。
APK伪加密
APK实际上是Zip压缩文件，但是Android系统在解析APK文件时，和传统的解压缩软件在解析Zip文件时还是有所差异的，利用这种差异可以实现给APK文件加密的功能。Zip文件格式可以参考MasterKey漏洞分析的一篇文章。在Central Directory部分的File Header头文件中，有一个2字节长的名为General purpose bit flags的字段，这个字段中每一位的作用可以参考Zip文件格式规范的4.4.4部分，其中如果第0位置1，则表示Zip文件的该Central Directory是加密的，如果使用传统的解压缩软件打开这个Zip文件，在解压该部分Central Directory文件时，是需要输入密码的，如图 5所示。但是Android系统在解析Zip文件时并没有使用这一位，也就是说这一位是否置位对APK文件在Android系统的运行没有任何影响。一般在逆向APK文件时，会首先使用apktool来完成资源文件的解析，dex文件的反汇编工作，但如果将Zip文件中Central Directory的General purpose bit flags第0位置1的话，apktool(version:1.5.2)将无法完成正常的解析工作，如图 6所示，但是又不会影响到APK在Android系统上的正常运行，如图 7所示。
图 5 传统解压缩软件需要输入密码进行解压缩
图 6 apktool解析伪加密的APK文件失败
对APK文件进行伪加密可以使用这个脚本，在Python的zipfile模块中，ZipInfo类中记录了Zip文件中相应的Central Directory的相关信息，包括General purpose bit flags，在ZipInfo类中属性为flag_bits，因此上述脚本中将需加密的APK文件的每个ZipInfo的flag_bits和1做或操作，实现在General purpose bit flags的第0位置1.
而需要去除这些伪加密的标志的话，可以使用这个脚本。相关内容可以参考BlueBox之前提出的一个Android Security Analysis Chanllenge.。
图 7 伪加密的APK可以正常运行
Manifest Cheating
AndroidManifest.xml是Android应用程序的配置文件，包含了包名、应用程序名称、申请的权限信息以及组件信息等。在Android应用程序开发，生成APK时，aapt会负责完成资源的打包，打包会将文本格式的XML资源文件编译成二进制格式的XML资源文件。将文本格式的XML文件转换成二进制格式，一方面通过字符串资源池的统一管理，减少文件体积；另一方面二进制格式的XML文件解析速度也会更快。在Android开发过程中，生成的R.java文件中包含了相应的资源类型、名称以及对应的id值。资源id是32bit的整型值，格式为:0xPPTTNNNN。其中PP表示使用该资源的包，TT代表该资源的类型，而NNNN是该类型中资源的名称。对于应用程序资源，PP值固定为7f，而对于被引用的系统资源包，其PP值为01。TT和NNNN一般是aapt按照资源出现的顺序生成的。更多分析可以参考罗升阳的Android应用程序资源的编译和打包过程分析。
Manifest Cheating的基本原理是，在AndroidManifest的<application>节点中插入一个未知id(如0×0)，名称为name的属性，其值可以是一个从未定义实现的Java类文件名。而对AndroidManifest的修改需要在二进制格式下进行，这样才能不会破坏之前aapt对资源文件的处理。由于是未知的资源id，在应用程序运行过程中，Android会忽略此属性。但是在使用apktool进行重打包时，首先会将AndroidManifest.xml转换为明文，进而会包含名称为name的属性，而相应的id信息会丢失，apktool重打包会重新进行资源打包处理，由于该name属性值是一个未实现的Java类，重打包后的应用程序在运行过程中，由于application节点中定义的类是先于所有其他组件运行的，若系统找不到对应的类，会出现运行时错误，Dalvik虚拟机会直接关闭。另外，也可以实现name属性值对应的Java类，若此类被调用，则表明被重打包了，可以采取进一步的措施。这样就可以起到保护自身APK的作用，防止被重打包。但是这种方法也很容易被绕过，只需要在经过apktool解码的AndroidManifest文件中，去掉在application节点中添加的name属性即可。整个过程如下：
- Ÿ 将APK解压缩，提取其中的AndroidManifest.xml文件；
- Ÿ 使用axml工具，修改二进制的AndroidManifest.xml文件，在application节点下插入id未知(如0×0)，名为name的属性(值可以任意，只要不对应到项目中的类文件名即可，如some.class)；
- Ÿ 将除META-INF文件夹之外的文件压缩成zip文件，签名后生成.apk文件。
若是攻击者使用apktool重打包，运行重打包后的文件会出现如下运行时错误：
图 8 使用Manifest Cheating重打包后APK文件运行时错误
调试器检测
在对APK逆向分析时，往往会采取动态调试技术，可以使用netbeans+apktool对反汇编生成的smali代码进行动态调试。为了防止APK被动态调试，可以检测是否有调试器连接。Android系统在android.os.Debug类中提供了isDebuggerConnected()方法，用于检测是否有调试器连接。可以在Application类中调用isDebuggerConnected()方法，判断是否有调试器连接，如果有，直接退出程序。
除了isDebuggerConnected方法，还可以通过在AndroidManifest文件的application节点中加入android:debuggable=”false”使得程序不可被调试，这样如果希望调试代码，则需要修改该值为true，因此可以在代码中检查这个属性的值，判断程序是否被修改过，代码如下：
|
1
2
3
4
|
if
(
getApplicationInfo
(
)
.
flags
&=
ApplicationInfo
.
FLAG_DEBUGGABLE
!=
0
)
{
System
.
out
.
println
(
“Debug”
)
;
android
.
os
.
Process
.
killProcess
(
android
.
os
.
Process
.
myPid
(
)
)
;
}
|
代码混淆
使用Java编写的代码很容易被反编译，因此可以使用代码混淆的方法增加反编译代码阅读的难度。ProGuard是一款免费的Java代码混淆工具，提供了文件压缩、优化、混淆和审核功能。在Eclipse+ADT开发环境下，每个Android应用程序项目目录下会默认生成project.properties和proguard-project.txt文件。如果需要使用ProGuard进行压缩以及混淆，首先需要在project.properties文件中去掉对如下语句的注释：
|
1
|
proguard
.
config
=
$
{
sdk
.
dir
}
/
tools
/
proguard
/
proguard
-
android
.
txt
:
proguard
-
project
.
txt
|
ProGuard的相关配置信息需要在proguard-project.txt文件中声明，在其中可以设置需要混淆和保留的类或方法。由于在某些情况下，ProGuard会错误地认为某些代码没有被使用，如在只在AndroidManifest文件中引用的类，从JNI中调用的方法等。对于这些情况，需要在proguard-project.txt文件中添加-keep命令，用来保留类或方法。关于ProGuard更加详细的配置项可以参考ProGuard Manual。
除了使用ProGuard对Android代码进行混淆外，还可以使用DexGuard。DexGuard是特别针对Android的一款代码优化混淆的收费软件，提供代码优化混淆、字符串加密、类加密、Assets资源加密、隐藏对敏感API的调用、篡改检测以及移除Log代码。
关于代码混淆，还可以参考Android:Game of Obfuscation。
NDK
Android软件的开发主要使用Java语言，但是Android也提供了对本地语言C、C++的支持。借助JNI，可以在Java类中使用C语言库中的特定函数，或在C语言程序中使用Java类库。一般来说，如果代码中对处理速度有较高要求或者为了更好地控制硬件，抑或者为了复用既有的C/C++代码，都可以考虑通过JNI来实现对Native代码的调用。
由于逆向Native程序的汇编代码要比逆向Java汇编代码困难，因此可以考虑在关键代码部位使用Native代码，如注册验证，加解密操作等。一个可能的借助Native代码保护APK的方法是：将核心业务逻辑代码放入加密的.jar或者.apk文件中，在需要调用时使用Native代码进行解密，同时完成对解密后文件的完整性校验，不过不管是.jar还是.apk文件，解密后都会留在物理存储上，为了避免这种情况，可以使用反射技术直接调用dalvik.system.DexFile.openDex()方法，该方法接受classes.dex文件字节流返回DexFile对象。关于Native代码的编写，可以参考Google官方文档的Android NDK。
逆向工具对抗
在逆向分析Android应用程序时，一般会使用apktool，baksmali/smali，dex2jar，androguard，jdGUI以及IDA Pro等。因此可以考虑使得这些工具在反编译APK时出错来保护APK，这些工具大部分都是开源的，可以通过阅读其源代码，分析其在解析APK、dex等文件存在的缺陷，在开发Android应用程序时加以利用。可以参考Tim Strazzere的Dex Education:Practicing Safe Dex，相应的Demo，看雪上的中文翻译，不过其中的很多技巧已经失效了。DexLabs的Dalvik Bytecode Obfuscation on Android介绍了垃圾字节码插入的技术。
总结
以上APK自我保护的技术并不能做到完全的保护作用，只是提高了逆向分析的难度，在实际运用中应该根据情况多种技术结合使用。这些技术其实很多来源于Android恶意代码，所以可以关注Android恶意代码中使用的一些技术来应用到自己开发的Android应用程序中。
