首页
论坛
课程
招聘

[原创]梆梆&爱加密java反调试绕过

2020-5-19 13:44 2069

[原创]梆梆&爱加密java反调试绕过

2020-5-19 13:44
2069

原文链接 梆梆&爱加密java反调试绕过

 

各位道友有没有在越过重重native反调试脱掉壳之后想要调试smali的过程中突然发现在使用AndroidStdio动态调试smali的时候只要一挂载APP就会崩溃,本篇主要整理一下在调试梆梆&爱加密过程中遇到的java层反调试以及绕过的方式

 

在将梆梆&爱加密脱壳之后通过AS调试APP遇到反调试挂载失败,只要debug便会杀掉APP进程

 

Dalvik虚拟机下的反调试绕过

虽然Dalvik已经在逐步退出市场,但是这里还是由他开始,大家都知道Dalvik的核心库是libdvm.so,在调试的过程中与APP建立连接少不了对libdvm.so的引用,因此libdvm.so几乎是最有嫌疑的地方。

 

获取libdvm.so

所谓获取libdvm.so需要获取APP未启动时libdvm.so源文件,这里只要去/system/lib目录下将其提取到本地即可。
其次需要加固APP运行时libdvm.so,这里我通过IDA动态挂载APP之后将其从内存中dump出来。

static main(void)
{
  auto fp, begin, end, dexbyte;
  fp = fopen("D:\\dump.so", "wb");
  begin = 0x786A0000;
  end = begin + 0x67000 ;
  for ( dexbyte = begin; dexbyte < end; dexbyte ++ )
      fputc(Byte(dexbyte), fp);
}

小小脚本,不成敬意

比较libdvm.so

在获取到两个libdvm.so之后通过BeyondCompare进行比较

 

 

通过比较可以看出在加固的APP运行之后,libdvm.so被改了几部分数据,并不是所有修改的地方都和反调试有关,通过IDA对照便宜去看看都改了什么地方,最终发现与java调试相关的地址为0x423B0,当然其他地方也有一些小惊喜,比如梆梆&爱加密抽取函数所hook的函数什么的。

 

 

_Z12dvmDbgActivev是java调试相关函数,主要功能是啥我也不是很清楚,有清楚的大佬希望可以留言告知一下,万分感谢。

 

 

由此可见加固APP是通过hook _Z12dvmDbgActivev函数使其跳转到它自己构造的函数,并且在其中将进程kill掉防止调试。那么我们只要将Hook之后的libdvm.so再Hook修改为原始函数,让其正常运行_Z12dvmDbgActivev函数,就可以绕过反调试了。

Hook libdvm.so

这里通过frida hook _Z12dvmDbgActivev函数地址,打印内存,将原本函数正确内存数据写入对应地址中

# -*- coding: utf-8 -*-
import frida
import sys

def on_message(message, data):
    print(message)

redv = frida.get_remote_device()
session = redv.attach("com.sf.activity")

src = """
    var jnibind1 = undefined;
    var jnibind2 = undefined;
    var jnibind3 = undefined;
    var jnibind4 = undefined;
    var jnibind5 = undefined;
    var jnibind6 = undefined;
    var jnibind7 = undefined;
    var f = Module.findBaseAddress("libdvm.so");
    console.log("address: " + f);
    jnibind1 = f.add(0x000423C0);
    var p1P = new NativePointer(jnibind1);
    aryBuffer1 = Memory.readByteArray(p1P, 16);
    console.log(aryBuffer1);
    var vArray = [0x0D,0x4B,0x0E,0x4A,0x7B,0x44,0x10,0xB5,0x9C,0x58,0x94,0xF8,0xC6,0x33];
    Memory.writeByteArray(p1P, vArray);
    var p1P = new NativePointer(jnibind1);
    aryBuffer1 = Memory.readByteArray(p1P, 16);
    console.log(aryBuffer1);

"""
script = session.create_script(src)
script.on("message", on_message)
script.load()
sys.stdin.read()

frida hook之后结果

 

 

反调试已经绕过啦!!!

 

Art虚拟机下的反调试绕过

获取libart.so

art虚拟机下的反调试绕过同上述的dalvik方法相同,只是关键的运行库libdvm.so替换为libart.so,同样要去/system/lib目录下将其提取到本地,这里需要注意的是在提取之前要确认运行的是libart.so还是libart64.so。

比较libart.so

在获取到两个libart.so之后通过BeyondCompare进行比较

 

 

最终确认反调试Hook地址为0x10ABC4

 

 

_ZN3art3Dbg8GoActiveEv函数功能同Dalvik中_Z12dvmDbgActivev函数功能类似,绕过方法与Dalvik保持一致。

Hook libart.so

这里通过frida hook _ZN3art3Dbg8GoActiveEv函数地址,打印内存,将原本函数正确内存数据写入对应地址中

# -*- coding: utf-8 -*-
import frida
import sys

def on_message(message, data):
    print(message)

redv = frida.get_remote_device()
session = redv.attach("com.sf.activity")

src = """
    var jnibind1 = undefined;
    var jnibind2 = undefined;
    var jnibind3 = undefined;
    var jnibind4 = undefined;
    var jnibind5 = undefined;
    var jnibind6 = undefined;
    var jnibind7 = undefined;
    var f = Module.findBaseAddress("libart.so");
    console.log("address: " + f);
    jnibind1 = f.add(0x00115BC4);
    var p1P = new NativePointer(jnibind1);
    aryBuffer1 = Memory.readByteArray(p1P, 16);
    console.log(aryBuffer1);
    var vArray = [0x2D, 0xE9, 0xF0, 0x4F, 0x9B, 0xB0, 0xDF, 0xF8, 0xBC, 0x0D, 0xDF, 0xF8, 0xBC, 0x1D];
    Memory.writeByteArray(p1P, vArray);
    var p1P = new NativePointer(jnibind1);
    aryBuffer1 = Memory.readByteArray(p1P, 16);
    console.log(aryBuffer1);

"""
script = session.create_script(src)
script.on("message", on_message)
script.load()
sys.stdin.read()

#总结
这里再简述一下反调试的原理,壳APP通过Hook libdvm.so&libart.so中的_Z12dvmDbgActivev&_ZN3art3Dbg8GoActiveEv函数,使其跳转到自己写的函数中执行kill操作导致无法调试。
目前在脱壳之后遇到java反调试,皆可用对比libdvm.so&libart.so寻找差异点将其修复绕过反调试,感兴趣的大佬可以通过其他被hook的函数研究加固或者函数抽取的原理。



[推荐]看雪工具下载站,全新登场!(Android、Web、漏洞分析还未更新)

最后于 2020-5-19 15:59 被Night_elf编辑 ,原因:
最新回复 (19)
Ive_406746 2020-5-19 14:13
2
0
学些了~
ddsf 2020-5-19 14:21
3
0
感谢分享~
tDasm 2020-5-19 14:37
4
0

替换系统so,有这样的壳吗?按照你这个说法,没root的设备这个壳还运行不掉?梆梆和爱加密的壳都见识过没看到替换so只是hook

最后于 2020-5-19 14:39 被tDasm编辑 ,原因:
Night_elf 2020-5-19 14:59
5
0
tDasm 替换系统so,有这样的壳吗?按照你这个说法,没root的设备这个壳还运行不掉?梆梆和爱加密的壳都见识过没看到替换so只是hook
额,我没说是替换吧,so确实是被hook修改的,art那里所说的替换只是指Dalvik和Art核心so发生了改变,可能是我这边描述的不够清楚,抱歉
tDasm 2020-5-19 15:16
6
0
Night_elf 额,我没说是替换吧,so确实是被hook修改的,art那里所说的替换只是指Dalvik和Art核心so发生了改变,可能是我这边描述的不够清楚,抱歉
那你就自相矛盾了。(在将梆梆&爱加密脱壳之后通过AS调试APP遇到反调试挂载失败)
如果只是hook,壳脱掉了反调试的hook就不存在了。除非该程序在加壳前就存在反调试,换句话说,这个反调试与壳无关。
Night_elf 2020-5-19 15:22
7
0
tDasm 那你就自相矛盾了。(在将梆梆&爱加密脱壳之后通过AS调试APP遇到反调试挂载失败) 如果只是hook,壳脱掉了反调试的hook就不存在了。除非该程序在加壳前就存在反调试,换句话说,这个反调试 ...
你说的那个意思是在脱壳并修复之后调试的情况吧,我这里调试的确实是未脱壳的APP,我说的脱壳只是说将dex还原出来在本地调试,并未修复整个APP,确实是描述有问题
tDasm 2020-5-19 15:41
8
0
1、你文章中都是写修改libart.so、修改libdvm.so,任何人看了都以为你是替换so。你应该写hook libart.so或hook libdvm.so
2、脱壳后的dex,除非不需要修复否则都要修复才能运行的。即便不修复dex,也必须加载一个so才能hook系统so,你不至于还保留壳的so在apk里面吧?而且壳的so都是在壳的dex中加载,还没看到脱壳后dex中有加载壳的so的。
IUnKnow 2020-5-19 15:45
9
0
修复个鬼呀,只是hook未脱壳之前的App,进行动态调试而已。frida native hook 用过没?
Night_elf 2020-5-19 15:52
10
0
tDasm 1、你文章中都是写修改libart.so、修改libdvm.so,任何人看了都以为你是替换so。你应该写hook libart.so或hook libdvm.so 2、脱壳后的dex,除非不需要修复 ...
1、你说的太对了,我准备去改改,接受批评
2、我只是hook未脱壳的APP,手机上安装的也是未脱壳的原始APP,dex脱出来之后直接反编译成samli通过AS动态调试是可行的,现在只是通过frida hook native修改被壳hook之后的libdvm&libart绕过反调试,感觉没啥毛病吧,表述的很清楚了
bluth 6天前
11
0
这种思路不错呀,dump内存的数据进行对比就知道改动点
12
0
get 新知识
laifuling 5天前
13
0
get 新技能
机械皇帝 5天前
14
0
有个疑问?你这AS调试遇反调试挂载失败,app进程直接杀死。  IDA挂载同样的道理啊,也会反调,app进程直接杀死,你怎么能dump出app运行时的libart.so的呢
15
0
作者的思路挺不错的,利用hook 原理。指向正确的加载流程地址,反调试原理其实就是判断“全局变量gDebuggerActive”的值,这个值正是文中_Z12dvmDbgActivev函数来设置的,至于原理看一下源码就很清楚了。
ghostfevil 4天前
16
0
大佬咨询一个问题,我用IDA调试的时候没法断在DexHelper.so加载的位置,一个线程一直异常got SIGABRT signal (Abort) (exc.code 6, tid 14289)。大佬知道是啥原因嘛
Night_elf 3天前
17
0
机械皇帝 有个疑问?你这AS调试遇反调试挂载失败,app进程直接杀死。 IDA挂载同样的道理啊,也会反调,app进程直接杀死,你怎么能dump出app运行时的libart.so的呢
ida调试和这个反调试无关,可以正常挂载
Night_elf 3天前
18
0
ghostfevil 大佬咨询一个问题,我用IDA调试的时候没法断在DexHelper.so加载的位置,一个线程一直异常got SIGABRT signal (Abort) (exc.code 6, tid 14289)。 ...
你加载so的过程中清空那些信号,应该不会崩了
ghostfevil 2天前
19
0
大佬  jnibind1 = f.add(0x00115BC4);这个里面的数值是ZN3art3Dbg8GoActiveEv这个函数的偏移嘛
Night_elf 2天前
20
0
ghostfevil 大佬 jnibind1 = f.add(0x00115BC4);这个里面的数值是ZN3art3Dbg8GoActiveEv这个函数的偏移嘛
对,但是也要看你手机里libart实际便宜
游客
登录 | 注册 方可回帖
返回