脚本工具:基于lldb的trace脚本(新增<block级trace命令>,辅助算法分析,过混淆等)

你的 脚本路径可能有问题,先确认下是不是全英文,以及相关的 改动。你可以从git上从新拽一哈

具体出错在:
debugger.HandleCommand(‘command script add -f lldbTrace.trace trace’)
debugger.HandleCommand(‘command script add -f lldbTrace.setDefaultPath setlogpath’)
debugger.HandleCommand(‘command script add -f lldbTrace.defaultPath logpath’)
print(‘WT::The “trace” python command has been installed and is ready for use.’)

噢,我已经重新下载了也没改动 :worried: :worried:
图片还在审核,路径也是全英文


你好,这个路径没问题呀 :worried:

没遇到过这种 debugger.HandleCommand(‘command script add -f lldbTrace.trace trace’) 出现bug的。
因为没法重现现场,所以我没法给你具体的修复意见。

你可以去 lldb 官网看看,以及对脚本做相关的调试看看… 或许能招到解决方案.

好的大哥,感谢解答 :+1:

block级trace命令研发原因和相关介绍:

1,在trace某些app的时候,发现里面的混淆代码很多都是可执行的,而且有很多没什么效果的大循环。从而 inst级 trace 的性能大大的 降低了。

2,考虑到 function 级 trace 的高效率。结合 function 级 trace 的高效率,以及 inst 级 trace 高代码完整性。决定从 block着手,弄一个 block 级 trace。

3,目前 trace 某app的大函数,效果还可以。

相关更新内容:

同时把 inst 级的 bug 修复了下。<a,函数结束位置的断点的修复;b,打印msg_send的相关信息,导致写文本出bug,暂时把这一块注释了。>

注 :trace某大型app,跑了35w+行… 基本达到预期

trace_b 输出如下:

大量的loop 都这样pass掉了:

注 :
1,loop 代码其实只跑了2次。第二次运行的时候,直接删掉循环中的断点。
2,任何循环都只跑了2次<block级的,不是逐条汇编跑的>
3,同样默认暂停其他所有线程。如果遇到线程同步锁的,需要第二次trace,trace的起始位置在跳出同步锁的位置。

前些天看到写出bug好像是编码问题,今天就看到修复了!赞

1 个赞

我这边也遇到这个问题,原因是已经有一个命令叫trace了

可以把 脚本里的命令的名字,改成你自己想要的名字就可以了.

:+1:,我之前也用unicorn做了类似的trace,比起debug速度会更快,但是,需要自己管理堆栈和参数,oc层的函数也要hook掉 :joy:

催更催更,紫薯布丁

新一版的,需要等我手头工作干完,然后对照手头工作,做优化,和相关bug处理。。

应该还要一段时间

yang神,能不能加上不带alsr的地址?

我记得 都是 ida里的地址…把 aslr 都减去了。

请问这个问题解决了嘛?我也是这个错误!

这个是不是因为过ptrace反调试的原因,因此trace被占用了呀?

你可以在 lldb 中 输入 trace 看看有么有这个命令

1 个赞

找到原因了,把代码里的trace 换个名字就ok了,可能之前的trace名字被占用了。谢谢。

貌似s寄存器的值没打印?

s寄存器? 你说的是浮点寄存器?还是 标志寄存器?
目前,主要的是 通用寄存器