AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

谈谈移动应用加固(APP安全加密) by 张勇@LBE

发布者 security
发布于 1445388080222  浏览 2905 关键词 Android, 网络安全 
分享到

第1页

谈谈移动应用加固

张勇 LBE安全大师



第2页

为什么需要加固

• Android应用主要以Java语言编写,混淆作用有限

• Android为开源系统,逆向和反编译工具非常成熟

• Android系统淡化进程概念,基于消息和事件触发 运行的机制使得插入恶意代码甚至无需接触字节码

• Root后可利用ptrace API或修改system image实现 动态注入



第3页

首先,让我们看看主流的应用加固提供商…



第4页

• 代码加壳 – classes.dex整包加密方案 • 将原始classes.dex加密后单独保存,使用壳加载器 替换原始classes.dex • 运行时解密classes.dex • 梆梆,爱加密,百度,通付盾

– classes.dex字节码变形方案 • 对原始classes.dex进行预处理,隐藏关键方法的字 节码 • 腾讯,360

– 虚拟机方案 • 将关键部分代码编译为专用虚拟机代码,于专用虚拟 机中执行 • 部分厂商正在研发中



第5页

• 防篡改

– 记录加固后APK内文件hash值,在运行时比对

– (部分)记录加固前APK的签名信息,要求加固后 使用相同签名重新签名

– 记录加固前AndroidManifest.xml文件内容,在运行 时比对,防止二次打包,添加权限等



第6页

• 运行时

–classes.dex整包加密方案

• 壳Application会首先运行 –在壳Application的构造函数, attachBaseContext 或onCreate中,执行脱壳操作 –解密Dex文件并将其加载至内存中 –反射LoadedApk.mApplication,

LoadedApk.mClassLoader,

ActivityThread.mInitialApplication, ActivityThread.mAllApplications等值,将其重新 指向目标Application和ClassLoader。确保系统 稍后构造组件时能正确的加载到目标类 –最后,将控制权交回目标Application



第7页

• 运行时

–classes.dex字节码变形方案

• 相对简单,无需反射修改

• 在Application加载之前首先加载解密代码,重新连 接加密后的class和method

• 解密后,将控制权交还至目标Application



第8页

• 运行时 – Ptrace保护 • 多进程相互ptrace防止ptrace attach或者memory dump –GC, SignalCatcher线程怎么办? –/proc/[pid]/mem仍然可读 • 会轮询/proc/[pid]/status以确保TracerPid为0 –影响性能,电池在哭泣

–Android进程从zygote fork而来,直接ptrace zygote 即可绕过所有ptrace保护



第9页

• 梆梆加固分析

– 加密原始classes.dex并放置于 assets/bangcle_classes.jar内

– 修改AndroidManifest.xml,替换Application对象 – 对AndroidManifest.xml中声明的所有Receiver,

Service和ContentProvider构造对应的Stub implementation – 运行时首先在内存中解密bangcle_classes.jar,然后 使用custom classloader将其加载至内存并跳转至其 中代码运行 – 未保护资源文件和so文件 – 运行时会启动2个辅助进程实现anti-ptrace



第10页

• 梆梆加固脱壳思路 – Classes.dex并未在加固时执行预处理,运行时 memory dump即可获得完整原始文件 – zjDroid或dextractor可直接脱壳 –也可直接分析/proc/[pid]/maps并dd /proc/[pid]/mem 导出odex文件

DEMO



第11页

• 爱加密加固分析

– 加密原始classes.dex并放置于assets/ijiami.dat内 – 修改AndroidManifest.xml,替换Application对象 – 在SuperApplication.attachBaseContext处开始解密

(因此无需对Service, Receiver等对象生成Stub) – 运行时首先在内存中解密bangcle_classes.jar,然后

使用custom classloader将其加载至内存并跳转至其 中代码运行 – 未保护资源文件和so文件 – 运行时会使用3个进程相互保护ptrace



第12页

• 爱加密加固脱壳思路 – Classes.dex并未在加固时执行预处理,运行时 memory dump即可获得完整原始文件 – zjDroid或dextractor可直接脱壳 –也可直接分析/proc/[pid]/maps并dd /proc/[pid]/mem 导出odex文件

DEMO



第13页

• 百度加固分析

– 加密原始classes.dex并放置于 assets/baiduprotect.jar内

– 修改AndroidManifest.xml,替换Application对象 – 对ContentProvider生成Stub – 脱壳流程同梆梆和爱加密几乎相同 – 未保护资源文件和so文件 – 运行时会使用3个进程相互保护ptrace



第14页

• 百度加固脱壳思路 – Classes.dex并未在加固时执行预处理,运行时 memory dump即可获得完整原始文件 – zjDroid或dextractor可直接脱壳 –也可直接分析/proc/[pid]/maps并dd /proc/[pid]/mem 导出odex文件

DEMO



第15页

• 腾讯云加固分析

– 不替换原始classes.dex,也没有做任何加密处理 –修改Dex的ClassData, 将指定方法标记为native, 从

而绕过静态分析工具,原始字节码仍然未加密的保 存在dex文件中 – 应用启动时,在Application的入口点处加载libtup.so, libtup.so会在内存中修改DexFile结构体,重建 Method同CodeItem的映射关系

– 此方法和xposed的思路有异曲同工之妙

– 原理决定了不支持ART



第16页

• 腾讯云加固脱壳思路

– 虽然Classes.dex做了较多的预处理操作,但原始字 节码明文保存在classes.dex中显得非常不安全。

– 应用运行后,libtup.so会修改Method对象的 accessFlags, registersSize, outsSize, insSize, insns 等属性,将函数复原

– 使用xposed或者注入进程后,找到目标Dex文件的 DvmDex结构体,遍历pResMethods,记录每个函 数的insns偏移量。利用这个偏移量,修复加固后的 classes.dex文件即可脱壳

DEMO



第17页

• 360应用加固分析 – TODO



第18页

• 360加固脱壳思路 – TODO

DEMO



第19页

应用加固,是否名副其实?

• classes.dex加密技术可以通过memory dump或 zjDroid破解

• ptrace保护可以轻松绕过 – 现有单一应用加固不足以提供足够安全性保障

• 腾讯和360使用的字节码变形能够提高破解门槛 • 类VMProtect虚拟机技术可能是未来发展方向

• 开发者需要清醒面对宣传,做好充分的准备,多管 齐下解决安全问题。



支持文件格式:*.ppt, *.pptx, *.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。