FART脱壳机的使用与进阶(2)_FART使用相关原理和知识点

如何安装pixel FART

解压FART压缩包
手机关机后 按-音量键和开机键 到 fastboot界面
点击 flash-all.bat 即可自动安装完成

修复dex错误

脱下来的dex无法使用jadx工具打开 因为缺失重要信息

拖入010edit 分析dex文件

修复head头缺失的部分

ida 分析流程

1.查看导出函数 是否有目标函数 左侧搜索函数
2.没有发现有目标函数 确认为动态注册函数 查看JNI_OnLoad函数
3.shift+f12 搜索相关字符串
3.直接f5完事 看看流程图 是不是加了ollvm这种东西 字符串加密 控制流程混淆
4.f5静态分析困难 进入动态分析流程 选择 ida动态调试 或者 frida

JVM 类加载器(3)

1.BootStrap ClassLoader 引导类加载器
2.Extends
3.

Android 类加载器(8)

加壳应用运行流程

ClassLoader修正

原因 动态加载的dex不具有生命周期

几代壳

Dex 整体保护 文件中已经可以解密出来整体的
Dex 方法抽取 动态加载 So加密 内存中可以抽出整体的
Dex Method 始终不是完整Dex 即使是在内存中 需要做主动调用填充
VMP Dex2C Java函数native化 保护效果最强 付费版本
将来 指令级别的ARM指令的VMP时代

SO加固种类

1.基于init init_arry JNI_OnLoad函数的加壳
2.基于自定义的linker的加壳

识别加壳技术版本

1.识别厂商
2.识别是否抽取

整体加固 函数抽取 VMP Java2C

函数抽取特征:dex dump 后方法丢失

可以配合ollvm避免直接被查出来虚拟化后的方法

VMP特征:dex dump 后 普通 虚拟化指令 重置解析器

保护函数注册地址相识 函数逻辑类似

adb logcat|grep

Java2C: java函数变成native 非常影响效率 不建议全量使用 核心函数使用

保护函数注册地址不同 函数逻辑不同

混合使用 先使用vmp/java2c 然后进行 抽取

Dalvik虚拟机脱壳技术(4.4以及之前系统)

源代码 libcore DexClassLoader.java

BaseDexClassLoader

makerDexElements

loadDexFile

new DexFile

openDexFile

openDexFileNative ->进入C层实现加载

dalvik目录

OptMain.cpp

DexPrepare.cpp

rewriteDex 优化重写dex文件

dexFileparse

非常多的时机可以作为脱壳点 只要包含了dex文件的地址

比如脱壳点:

dexFileParse
dvmDexFileOpemPartial

dexSwapAndVerify
dvmContinueOptimization
rewriteDex

grep -ril "testActivity" ./*.dex

对于现代壳依然有效果(apk支持4.4以下可以尝试脱壳)
如果失效 可能是针对脱壳点做了优化 尝试更换脱壳点

当然如果有函数抽取 依然需要修复

源码定制实现脱壳dump:

hook实现脱壳:

脱壳点时机选择:

ART脱壳原理和脱壳方式

InMemoryDexClassLoader( 8.0引入了) 流程 用于加载内存中的Dex 增加安全性

new DexFiel()

openInMemoryDexFile

native createCookieWithDirectBuffer

native createCookieWithArray

native CreateSingleDexFileCookie

native ConverDexFilesToJavaArray

native CreateDexFile 构建dex文件

native dex_file.cc open函数 --> openCommon

直接内存加载 不生成odex文件

可以作为dump点的函数
dex起始地址和大小

• CreateSingleDexFileCookie
• CreateDexFile
• dex_file.cc open
• dex_file.cc openCommon
• dex_file.cc DexFile构造函数

ART 下 DexClassLoder的 流程 oatdex

makeDexElements

native openDexFileNative

native OpenDexFileFromOat 首次没有oat先生成oatdex

加固的函数抽取需要阻断这个生成过程

假设阻断了流程

native dex_file.cc Open
native DexFile 构造函数
native OpenAndReadMagic
native dex_file.cc OpenFile
native dex_file.cc OpenCommon
可以作为dump点的函数
dex起始地址和大小

• OpenAndReadMagic
• dex_file.cc open
• dex_file.cc openCommon
• dex_file.cc DexFile构造函数

脱壳点优先选择 DexFile构造函数 因为两个加载方式共有了

进入dex2oat脱壳 假如没有阻止dex2oat过程
一个dex转oat的过程

• dex2oat.cc Dex2oat函数
• dex2oat.cc Setup函数可以作为脱壳点

编写系统源代码或者编写FRIDA插件

dex_file 的过程

补充还有非常多的脱壳点

frida hook libart.so 里面的相关函数

FART脱壳点介绍

FART框架组成

1.脱壳组件 dex dump
2.主动调用方法组件 生成.bin
3.修复dex组件

第一个脱壳点dx2at中转化的位置:

CompileMethod 对dex类方法进行编译 其中构造函数不进行编译 interpreter模式运行

ART运行函数模式:

1.interpreter模式 ART下的解释器执行
2.quick模式 直接运行dex2oat生成的arm指令

函数构造函数进入interpreter解释器执行

也就是interpreter.cc的Execute方法

在解析器这里拿到这个构造方法的ArtMethod

ArtMethod->GetDexFile->得到dex文件

脱壳核心:内存中找到DexFile对象 通过DexFile的begin和size dump dex文件 下来

直接搜索DexFile关键字

一个好脱壳点:
1.通用 对应大多数厂商
2.不容易被hook修改

class_linker.cc LinkCode 脱壳点 测试

FART主动调用组件

应对抽取方法的加固方式脱壳方案:

参考 dexhunter 和 Fupk3 两个Dalvik下的主动调用方式的toke方案

缺点 无法应对ART 无法修复VMP函数 很多app无法在Dalvik下运行

主动调用:构造虚假的调用 欺骗加固 对dex所有类进行类函数的虚拟调用

主动调用连越深效果越好，但是会耗费更多的时间

主动调用核心:

1.如何构造主动调用链 不影响到app的正常运行

FindClass
GetMethodID
CallVidMethod

DexFile.cc 确定 dumpMethodCode方法

判断是否是真实调用还是主动调用 参数判断

2.根据ArtMethod定位内存中CodeItem的起始地址

dumpArtMethod 方法

art_method.h

GetCodeItem 开始地址
如何确定方法讦诉地址 需要解析这个dex文件

codeItem的字段解析 确定大小

class_linker.cc 有关于CodeItm的初始化偏移量设置

异常处理相关字段

3.如何遍历dex并且做到全部调用

ActivityThread 线程中进行主动调用

对进行的所有的Class进行记录

getClassNameList

loadClassAndInvoke

主动调用才会触发生成.bin文件 自动在ActivityThread 启动 60秒

FART和frida

对抗FART:

1.是否加载了不应该的类
2.检测接口调用

没有修正dexClassLoader的插件化 需要使用frida枚举classLoader 激发主动调用脱壳过程

emumerateClassLoader 枚举主动

过滤掉垃圾类主动调用 控制粒度

FART修复组件

主动调用完成后 生成.bin文件

完成全部的主动调用后 这个时候dump下来的dex就是完整的。

修复组件就是解析dex中所有的类和函数

将脱下的dex和.bin合并起来
合成完整的dex文件

应对 VMP smali映射到自定义的方法里面

使用映射关系修复vmp保护的方法

JNI函数对应的地方填回去 需要去看CodeItem里面对应的native的偏移

fart_vmp.py

现在还没有通用的解决方案 主要是映射关系都不一样