android加载dex

‘壹’ Android开发如何将asset文件打入dex包

1.解包dex
2.重新打包dex
c:\Documents and Settings\Anminstrator>choice /c:21'choice' 不是内部或外部命令，也不是可运行程序或批处理文件。

‘贰’ android怎么动态调试dex

1.1 安装JDK
java环境的搭建请自行查找资料，这里不做详述。
1.2 安装Android SDK
下载地址：http://developer.android.com/sdk/index.html。
下载完安装包后解压到任意一目录，然后点击运行SDK Manager.exe，然后选择你需要的版本进行安装，如图：

1.3 安装Eclipse集成开发环境
下载地址：http://www.eclipse.org/downloads。选择Eclipse for Mobile Developers，解压到任意目录即可。
1.4 创建Android Virtual Device
动态调试可以用真实的手机来做调试环境，也可以用虚拟机来做调试环境，本文采用虚拟机环境。因此创建虚拟机步骤如下：
1打开Eclipse –>windows->Android Virtual Device

2点击Create，然后选择各个参数如图：

这里Target 就是前面步骤中安装的SDK 选择任意你觉得喜欢的版本就可以。点击OK 就创建完毕。
1.5 安装 APK改之理
这个是一个很好用的辅助调试的软件，请自行搜索下载。
1.6 安装 IDA6.6
IDA6.6开始支持安卓APP指令的调试，现该版本已经提供免费下载安装，请自行搜搜。
0x02 Dalvik指令动态调试
2.1 准备工作
安卓APP应用程序后缀为apk，实际上是一个压缩包，我们把它改后缀为rar打开如图：

其中classes.dex是应用的主要执行程序，包含着所有Dalvik指令。我们用APK改之理打开apk，软件会自动对其进行反编译。反编译后会有很多smail文件，这些文件保存的就是APP的Dalvik指令。
在APK改之理里双击打开AndroidManifest.xml，为了让APP可调试，需要在application 标签里添加一句android:debuggable="true" 如图：

然后点击保存按钮，然后编译生成新的apk文件。接着打开Eclipse –>windows->Android Virtual Device，选择刚才创建的虚拟机，然后点击start，虚拟机便开始运行。偶尔如果Eclipse启动失败，报错，可以同目录下修改配置文件：

把配置参数原本为512的改为256 原本为1024的改为512，然后再尝试启动。
在SDK安装目录有个命令行下的调试工具adb shell，本机所在目录为E:\adt-bundle-windows-x86-20140702\sdk\platform-tools，把adb.exe注册到系统环境变量中，打开dos命令行窗口执行adb shell 就可以进入APP命令行调试环境，或者切换到adb所在目录来执行adb shell。

这里先不进入adb shell，在DOS命令行下执行命令：adb install d:\1.apk 来安装我们刚才重新编译好的APK文件。安装完毕会有成功提示。
2.2 利用IDA动态调试
将APP包里的classes.dex解压到任意一目录，然后拖进IDA。等待IDA加载分析完毕，点击Debugger->Debugger Options如图

按图所示勾选在进程入口挂起，然后点击Set specific options 填入APP包名称和入口activity 如图：

其中包的名称和入口activity 都可以通过APK改之理里的AndroidManifest.xml 文件获取：

1
2
3

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.simpleencryption">
<application android:allowBackup="true" android:debuggable="true" android:icon="@drawable/creakme_bg2" android:label="@string/app_name" android:theme="@style/AppTheme">
<activity android:label="@string/app_name" android:name=".MainActivity">


然后在IDA点击Debugger->Process Options

其他默认不变，端口这里改为8700。这里默认端口是23946，我在这里困扰了很久，就是因为这个端口没有改为8700所致。然后我们看看这个8700端口是怎么来的。在Android SDK里提供了一款工具DDMS，用来监视APP的运行状态和结果。在SDK的TOOLS目录有个DDMS.BAT的脚步，运行后就会启动DDMS。由于我的本机安装了SDK的ADT插件，DDMS集成到了Eclips中，打开Eclips->Open perspective->ddms就启动了DDMS。
如图所示：

在DDMS选中某个进程后面就会注释出它的调试端口,本机这里是8700。
到此所有的工作就准备就绪，然后就可以下断点来调试该APP了。我们在APK改之理中在com目录下查看smali文件 发现MainActivity.smali里有一个感兴趣的函数getPwdFromPic()，那么我们就对它下断以跟踪APP的运行。
在IDA里搜索字符串getPwdFromPic，发现onClick有调用该函数
我们在onClick 函数开始位置按F2下断如图：

然后点击上图中绿色三角形按钮启动调试如图：

调试过程中有一个问题出现了很多次，浪费了我大量的时间，就在写文章的时候，操作时还是遇到了这样的问题。就是点击启动后IDA提示can’t bind socket，琢磨了很久终于找到原因了，当打开过一次DDMS后 每次启动Eclips都会启动DDMS 而8700端口正是被这个DDMS给占用了，然后每次都会启动失败，解决办法就是 虚拟机运行起来后关闭掉Eclips，这时一切就正常了！
事例中是一个APP crackme 提示输入密码才能进入正确界面。这个时候我们输入123，点击登陆，IDA中断在了我们设置断点的地方，这时选中ida->debugger->use source level debugger，然后点击ida->debugger->debugger windows->locals打开本地变量窗口，如图：

然后按F7或F8单步跟踪程序流程，同时可以观察到变量值的变化，也可以在IDA右键选择图形视图，可以看到整个APP执行的流程图:

如上图所示 变量窗口中我们输入了123 被转化成的密码是么广亡，pw变量也显示出了正确的密码，其实这个时候已经很容易判断出正确密码了。
0x03 Andoid原生动态链接库动态调试
通常为了加密保护等措施，有时dex执行过程中会调用动态链接库文件，该文件以so为后缀，存在于APP文件包里。

这里我们以动态附加的方式来调试原生库。
3.1 准备工作
1、将IDA->dbgsrv目录下的android_server拷贝到虚拟机里，并赋予可执行权限
DOS命令分别为：
adb shell pull d:\ android_server /data/data/sv
adb shell chmod 755 /data/data/sv

2、启动调试服务器android_server
命令：adb shell /data/data/sv
服务器默认监听23946端口。
3、重新打开DOS窗口进行端口转发，命令：
adb forward tcp:23946 tcp:23946 如图：

3.2 利用IDA进行动态调试
1、虚拟机里启动要调试的APP 2、启动IDA，打开debugger->attach->remote Armlinux/andoid debugger

端口改为23946 其他保持不变，点击OK

如上图，选中要调试的APP 的数据包名，然后点击OK。
正常情况下，IDA会把APP进程挂起。
3、由于当前程序不是在动态链接库领空，这时我们要重新打开一个IDA，用它打开需要调试的so文件，找到需要下断的位置的文件偏移，并做记录，然后关闭后面打开的这个IDA。
4、在原IDA界面按下ctrl+s键，找到并找到需要调试的so，同时记录该文件的加载基址。然后点击OK 或者cancel按钮关闭对话框。
5、按下快捷键G 输入基址+文件偏移所得地址，点击OK 就跳转到SO文件需要下断的地方，这时按下F2键设置断点。当APP执行到此处时便可以断下来。
3.3 在反调试函数运行前进行动态调试
程序加载so的时候，会执行JNI_OnLoad函数，做一系列的准备工作。通常反调试函数也会放到JNI_OnLoad函数里。进行4.2中第2步时也许会遇到如下情况：

这时APP检测到了调试器，会自动退出，那么这时调试策略需要有所改变。
接着4.1第3步后，在DOS命令行执行命令：
adb shell am start -D -n com.yaotong.crackme/com.yaotong.crackme.MainActivity

来以调试模式启动APP 如图：
com.yaotong.crackme是APP包名称，com.yaotong.crackme.MainActivity是执行入口 这些可以用APK改之理查看。

这时由于APP还未运行，那么反调试函数也起不了作用，按照4.2中第2步把APP挂起。这时IDA会中断在某个位置

然后点击debugger->debugger opions设置如下：

点击OK 后按F9运行APP，然后再DOS命令下执行命令：
jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700

这时APP会断下来，然后按照4.2中的3、4、5补找到JNI_OnLoad函数的地址并下断，然后按F9 会中断下来。然后便可以继续动态跟踪调试分析。

‘叁’ android dex文件 怎么打开

apk文件是把android
sdk编译的工程打包成一个安装程序文件，格式为apk。
APK文件其实是zip格式，但后缀名被修改为apk，通过UnZip解压后，可以看到Dex文件，Dex即Android
Dalvik执行程序，你可以在安装Android操作系统的手机中执行即可安装。
望采纳

‘肆’ android手机的apk文件中的class.dex文件是什么是做什么用的呢

简单说就是优化后的android版.exe。每个apk安装包里都有。相对于PC上的java虚拟机能运行.class；android上的Davlik虚拟机能运行.dex。

作用

让dalvik能够运行。

dex好处

可以直接用DexClassLoader类加载，动态加载。于是只要在dex上加壳，在程序运行时脱壳，就可以规避静态反编译的风险。

(4)android加载dex扩展阅读

使用dex文件的原因

在Android系统中，一个App的所有代码都在一个Dex文件里面。Dex是一个类似Jar的包，存储了很多Java编译字节码的归档文件。

因为Android系统使用Dalvik虚拟机，所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件。

‘伍’ 哪位朋友能告知一下，dex文件如何安装在安卓手机上

因字数限制，因此无法详述，请参看这个链接，介绍非常详细：
http://..com/question/262114879.html

‘陆’ Android上，怎么用16进制加密apk的dex文件让别人无法反编译或进内部查看原代码

可以在Dex文件头隐藏另一个DEX数据并在运行时加载附带DEX数据。
构建非规范的Dex文件
通过反射调用DexFile类的方法加载附带DEX数据
通过反射实际调用DexFile的openDexFile方法

该种方式允许通过byte[]解析dex数据，而无须在再把DEX数据存储在设备的某个文件。
可以从安装APK文件、内存或dalvik-cache等读取dex数据。
该种方式将给自动化分析工具带来一个问题，自动化工具会按照dex格式处理DEX文件而不会处理附带的dex数据。需要特定的工具、16进制编辑器或手工提取嵌入的dex数据。
我们可以采用各种不同的方式增加嵌入数据的提取难度，比如：
对嵌入的DEX数据进行加密；
嵌入的DEX数据加密后在对其进行ZIP压缩；
使用native代码解密，直接从内存加载；
......等等

该种隐藏方式可以通过判断Dex文件头长度是否大于0x70检测。

‘柒’ android dex何时加载

1 问题
在Android系统中，一个App的所有代码都在一个Dex文件里面。Dex是一个类似Jar的存
储了多有Java编译字节码的归档文件。因为Android系统使用Dalvik虚拟机，所以需要把
使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件。这里需要强
调的是，Dex和Jar一样是一个归档文件，里面仍然是Java代码对应的字节码文件。
当Android系统启动一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的
工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这
个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文
件的效率要高很多。但是在早期的Android系统中，DexOpt有一个问题，也就是这篇文
章想要说明并解决的问题。DexOpt会把每一个类的方法id检索起来，存在一个链表结构
里面。但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过
65536个。当一个项目足够大的时候，显然这个方法数的上限是不够的。尽管在新版本的
Android系统中，DexOpt修复了这个问题，但是我们仍然需要对老系统做兼容。
2 思路
一种有效的解决思路是把Dex文件分割成多个较小的Dex。这就如同很多项目会把自己分
割成多个Jar文件一样，不同的功能在不同的Jar文件里面，通过一些配置和额外的操作，
可以让虚拟机有选择性的加载Jar文件。但是在Android系统中，一个应用是只允许有一
个Dex文件的。也就是说在编译期的时候，所有的Jar文件最终会被合并成一个Dex文件。
我们没有办法在Apk文件里面打包两个Dex，让DexOpt分别对两个Dex文件做处理，而
Android系统也不会同时为一个Apk加载两个Dex。
1
2.1 动态加载
如果我们把Dex分成多个文件，然后在程序运行的时候，再把多的那几个动态的加载进来
是否可行呢？也就是说我们能否在运行时阶段把代码加入虚拟机中。对于虚拟机来说，其
实所有的代码都是在运行时被加载进来的。而不同于C语言还存在着静态链接。虚拟机在
所有Java代码执行之前被启动，然后开始把字节码加载到环境中执行，我们可以理解成所
有的代码都是动态加载到虚拟机里的。
而说到加载，不得不说的是ClassLoader。它的工作就是加载.class文件。在Android的
Dalvik环境中，对应的是DexClassLoader，它们的功能是完全一样的。ClassLoader的
一大特点就是它是一个树状结构。每个ClassLoader都有一个父亲ClassLoader。也就是
说，ClassLoader不是把所有的Class放到一个巨大的数组或别的什么数据结构中来处理。
ClassLoader在加载一个Jar中的类的时候，需要制定另一个ClassLoader作为父亲节点，
当我们需要通过ClassLoader得到一个类类型的时候，ClassLoader会把请求优先交给父
亲ClassLoader来处理，而父亲ClassLoader又会交给它的父亲，一直到根ClassLoader。
如果根ClassLoader有这个类，而返回这个类的类类型，否则把这个请求交给这个请求的
来源子ClassLoader。这是一种向上传递，向下分发的机制。这种情况下，对于调用着来
说，子ClassLoader永远都是包含最多Class的ClassLoader。有一点我们需要注意，父亲
ClassLoader只会向请求来源分发自己的处理结果。所以如果来源是自己，那么如果没有
请求类它就会返回空，而不是遍历所有子ClassLoader去请求是否有被请求的类。
在Android系统中，对于一个应用来说，其实有两个ClassLoader，一个是SystemClassLoader，这个ClassLoader里面除了Java标准的类库之外，还有一个android.jar，所有
Android Framework层的类都在这里。而另外一个重要的ClassLoader就是基于Android
Context的ClassLoader。所有属于当前应用的类都是用这个ClassLoader来加载的，我们
可以在Android源码中看到，所有的Activity，Service，View都是使用这个ClassLoader
来反射并创建的。我们暂时把它叫做ContextClassLoader。
3 加载外部Dex
3.1 构建一个Dex文件
这一步并不复杂，首先我们把所需要的.class文件或者是Jar文件和一些源码一起编译生
成一个Jar文件。然后使用Android SDK提供的dx工具把Jar文件转成Dex文件。我们可以
提前对它进行ODex操作，让它在被DexClassLoader加载的时候，跳过DexOpt的部分工
作，从而加快加载的过程。
2
3.2 DexClassLoader
现在的工作就是在运行时加载这个Dex文件了。我们可以在Application启动的onCreate
方法里面加载Dex，但是如果你的Dex太大，那么它会让你的App启动变慢。我们也可以
使用线程去加载，但我们必须保证加载完成之后再进行某个外部类的请求。当然也可以真
正等到需要某个外部类的时候再进行Dex加载。这根本上取决于Dex文件本身的大小，太
大了可以预加载，而比较小可以等到实际需要的时候再加载。我们暂且把这个加载了外部
Dex的ClassLoader成为ExternalClassLoader
上面我们提到了树形结构和系统中的多个ClassLoader，当我们加载外部Dex的时候，我
们是否需要指定一个父ClassLoader呢？我们当然需要一个父ClassLoader，否则我们ExternalClassLoader连一些基本的Java类都没有，它根本不可能成功的加载一个Dex。进一
步的，我们要选择哪一个ClassLoader来作为我们的父亲呢？是SystemClassLoader还是
ExternalClassLoader？这是根据情况来定的，如果外部的Dex文件里没有任何和Android
相关的代码，那么SystemClassLoader是我们的首选，否则我们就应该用ContextClassLoader。如果是后者的情况，我们的树可以被看成一个链表。
3.3 外部的View, Acitivity等
我们知道，我们编写的四大组建都不是由我们自己来创建的，是由系统来给我们构造并
管理其生命周期的。那么这个过程是什么样的呢？拿Activity来举例，我们需要通过调用
当前Activity/Context的startActivity，传入一个Intent来调用启动一个新的Activity。系
统有一个ActivityManager来处理这里的逻辑。这里的逻辑相当的复杂，但简单来说，
ActivityManager会收到并处理这个Intent，从而决定是是启动一个新的，还是把旧的放
到前台。它会先查找这个Activity在哪个应用里面，这是通过扫描每个应用的AndroidManifest来确定。这些信息是在PackageManager里面被检索的。总之如果这个Activity
不再任何的manifest里面，它就不可能被启动。所以仅有一个Activity类是不够的，我们
需要在manifest里面声明它。
上面是Activity的情况，Service之类的也是同理。那么View怎么办？尽管我们可以直接创
建View，但是大部分的View都不是我们创建的，而是通过XML布局文件Inflate出来的。
也就是说，我们在XML定义了一些外部Dex里面的View，那么显然这个XML是不能被成
功的Inflate的。因为除非系统会使用我们的ExternalClassLoader，否则它肯定是找不到
我们的类的：ContextClassLoader里面并没有外部Dex中的类。
也就是说问题的根本在于，对于那些Android系统为我们创建的对象，它是不能包含在外
部Dex里面的。而Android系统中大部分的组建类的生命周期都交给了系统来管理。我们
3
不可能自己来创建这些类对象。那么另一种思路：我们是不是可以通过使用我们的ExternalClassLoader来代替ContextClassLoader呢？尽管系统的ContextClassLoader是私有
的，但是我们可以通过反射强制的把它替换成我们的ExternalClassLoader。而对于那些
外部的组建（Activity等），尽管我们没有它们的类，但是并不影响我们在AndroidManifest里面声明这个Activity。因为Android系统只是把它作为一个检索，并不会真正检查它
里面的组建是不是真的在虚拟机环境中已经被加载了，只有真正使用Intent启动某个组建
的时候才会去检查。而只要我们保证这个时候我们已经加载了外部的ClassLoader，那么
这个组建就可以被正常的启动。
还有一点，除了我们要为外部可能有的组建在AndroidManifest里面做声明一外，那些外
部组建可能用到的权限我们也需要一一声明，例如如果外部Activity使用了相机功能，那
么如果我们的Manifest里面没有声明使用相机功能的权限的话，即便这个Activity能成功
为加载出来，仍然是不能使用的。
4 核心代码段
加载外部Dex
mClassLoader = new DexClassLoader ( f . getAbsolutePath ( ) ,
mContext . getCacheDir ( ) . getAbsolutePath ( ) ,
null , mContext . getClassLoader ( ) ) ;
让系统使用ExternalClassLoader
t r y {
F ie ld mMainThread = ge t F ie ld ( A c t i v i t y . class , ”mMainThread”) ;
Object mainThread = mMainThread . get ( a c t i v i t y ) ;
Class t hreadClass = mainThread . get Class ( ) ;
F ie ld mPackages = ge t F ie ld ( threadClass , ”mPackages”) ;
WeakReference<?> r e f ;
Map< St ring , ?> map =(Map< St ring , ? >) mPackages . get (mainThread ) ;
r e f = (WeakReference<? >) map . get (mContext . getPackageName ( ) ) ;
Object apk = r e f . get ( ) ;
Class apkClass = apk . get Class ( ) ;
F ie ld mClassLoader = ge t F ie ld ( apkClass , ”mClassLoader”) ;
mClassLoader . set (apk , classLoader ) ;
} catch ( I llegalArgument Except ion e) {
i f (DEBUG) {
e . print St ackTrace ( ) ;
}
} catch ( I llega lAc c essEx c ept ion e) {
i f (DEBUG) {
4
e . print St ackTrace ( ) ;
}
}
5

‘捌’ android程序class.dex文件无法访问

Java 文件 ----- - 应用程序源文件
android 本身相当一部分都是用 java 编写而成 ( 基本上架构图里头蓝色的部份都是用
Java 开发的 ) ， android 的应用必须使用 java 来开发。
Class 文件 ------Java 编译后的目标文件
不像 J2se ， java 编译成 class 就可以直接运行， android 平台上 class 文件不能直接
在 android 上运行。由于 Google 使用了自己的 Dalvik 来运行应用，所以这里的 class 也
肯定不能在 AndroidDalvik 的 java 环境中运行， android 的 class 文件实际上只是编译
过程中的中间目标文件，需要链接成 dex 文件后才能在 dalvik 上运行。
Dex 文件-----Android 平台上的可执行文件
Android 虚拟机 Dalvik 支持的字节码文件格式 Google 在新发布的 Android 平台上使用
了自己的 Dalvik 虚拟机来定义，这种虚拟机执行的并非Java 字节码，而是另一种字节码：
dex 格式的字节码。在编译 Java 代码之 后 ，通过 Android 平台上的工具可以将 Java 字
节码转换成 Dex 字节码。虽然 Google 称 Dalvik 是为了移动设备定做的，但是业界很多人
认为这是为了规避向 sun 申请 Javalicense 。这个 DalvikVM 针对手机程式 /CPU 做过 最
佳化，可以同时执行许多 VM 而不会占用太多 Resource 。
Apk 文件 -Android 上的安装文件
Apk 是 Android 安装包的扩展名，一个 Android 安装包包含了与某个 Android 应用程序相
关的所有文件。 apk 文件将 AndroidManifest.xml 文件、应用程序代码 (.dex 文件 ) 、
资源文件和其他文件打成一个压缩包。

‘玖’ android dexclassloader 能不能卸载

不能，这个是用来加载dex文件中的类文件的，android5.0以前版本的应用程序文件都是以dex格式存在的，所以最好不要卸载，

‘拾’ Android手机的apk文件中的class.dex文件是什么是做什么用的呢

简单说就是优化后的android版.exe。每个apk安装包里都有。相对于PC上的java虚拟机能运行.class；android上的Davlik虚拟机能运行.dex。

作用

让dalvik能够运行。

dex好处

可以直接用DexClassLoader类加载，动态加载。于是只要在dex上加壳，在程序运行时脱壳，就可以规避静态反编译的风险。

(10)android加载dex扩展阅读

使用dex文件的原因

在Android系统中，一个App的所有代码都在一个Dex文件里面。Dex是一个类似Jar的包，存储了很多Java编译字节码的归档文件。

因为Android系统使用Dalvik虚拟机，所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件。