近日，百度安全实验室发现了一款被不同病毒家族利用的新型代码加固方式，该种代码加固方式巧妙的利用了Android系统提供的NativeActivity特性完成恶意代码的解固。目前主流的加固方案代码逻辑分为java层和native层两部分。而该种加固方式实现了代码的全部native化，java层未包含任何代码逻辑。以下为传统加固方案与新型加固方案的对比：
主流加固方案 新型加固方案
一、简介
Google推出NDK（Native Development Kit）后，使用C/C++的很多开发者开始使用这种更高效的方式来进行Android程序的开发。在Android 2.3中Google开始逐渐的放宽NDK功能，新增的NativeActivity类允许Android开发者使用C/C++在NDK环境中处理 Activity的生命周期。具体NaviteActivity开发流程可查看：
http://api.apkbus.com/reference/android/app/NativeActivity.html
使用该开发模式的病毒，执行逻辑可分为两个部分：
1、DEX加载器libdexloader.so：实现Payload DEX文件的解密、动态加载。
2、Payload DEX：执行具体的恶意行为。Payload DEX存在于assets目录下，其中DEX中的方法指令已被加密处理。
其中DEX加载器利用Android NativeActivity开发模式开发。系统提供的NativeActivity作为libdexloader.so的java端入口点触发libdexloader.so的逻辑。libdexloader.so执行流程为：
1、 加载Payload DEX文件到内存。
2、 解析Payload DEX文件，解密DEX文件中的方法指令。
3、 内存加载解密后的Payload Dex数据。加载这些DEX数据，能够做到文件系统无解密DEX文件存在（注：内存加载仅适合android4.0-android4.4版本,相关技术可参考:http://blog.csdn.net/androidsecurity/article/details/9674251）。
4、 调用恶意代码。
二、恶意案例代码分析
使用该类开发模式加固的恶意样本家族中，我们选取其中一类窃取用户联系人的家族进行分析，反编译classes.dex可见，主要恶意行为的代码并不在classes.dex中：
classes.dex的类结构，未包含任何有意义代码
而实际运行，该病毒的逻辑如下图所示：
1、入口
该程序在AndroidManifest.xml文件中注册”android.app.NativeActivity”，并配置meta-data的name与value的值，从而加载ELF可执行文件作为入口：
ELF文件加载后，即会执行入口函数android_main，该函数会启动DexService和DexLoader类中的方法进行dex文件的解密和加载：
2、assets中的文件类型为dex，但实际上，方法结构中的ushort insns部分已被加密，因此不能直接被加载。下图为MainActivity的exec_post方法被加密的方法指令：
被加密的方法指令
3、libdexloader.so运行后，将DEX文件ushort insns部分解密，并重新合成一个正确的DEX文件，然后加载至内存运行。下图为还原后的正确的DEX的方法指令：
还原后的方法指令
4、经过解密，我们得出完整JAVA层代码：
分析可知该病毒主要行为是读取联系人信息，然后将这些信息发送到指定网址：
读取联系人和本机号码
发送至远端地址