只测试了 od1.x x32dbg yzdbg 以及 cpudbg.
首先测试目标文件为小文件, 如10m以下的, 这几款调试器"几乎"感觉不到耗时差异. (可能也会有几百毫秒的差距)
今天测试了一个较大的文件. 目标文件是 [android-studio-bundle-145.3537739-windows.exe] 大小: 1.63 GB (1,756,130,200 字节)
测试 od1.x 差不多1秒左右.
测试 x32dbg 几乎就是瞬间加载. 给人的感觉可能就几十毫秒.
x32dbg似乎是首先不管三七21,直接就在cpu下的几个子窗口立即显示数据.其中
反汇编窗口: 直接定位显示ep处数据. 这速度太快了, 他似乎就直接忽略了 LOAD_DLL_DEBUG_EVENT 事件.
寄存器窗口: ip处中断的地址是 EIP : 77DF29E0 对应的 模块函数是 ntdll.RtlUserThreadStart .
信息窗口: 直接显示 bp = 0
数据窗口: 直接显示主模块的基址. 0x00400000
堆栈窗口: 和寄存器窗口应该一样, 属同一context
上面的信息显示之后,大概又过了几十毫秒. 所有的数据就又刷新了.刷新后显示的信息,就是加载目标程序后中断在EP处时的信息一样了.
x32dbg给人的感觉像是 开了线程专门处理加载事件. 还有 LOAD_DLL_DEBUG_EVENT 事件,他似乎并没有处理.有可能是专门调用的枚举模块函数来获取模块.要不然没理由加载这么快的.
测试 yzdbg 用时差不多是 15 秒左右.
测试 cpudbg debug 用时 差不多 33 秒左右 -_-#
测试 cpudbg release 用时 大概 15 秒左右.
搞不明白加载大目标程序为什么会这么长时间?
晚点再来看看
-------------------------------------------------------------------------------
2023.01.05
刚刚分析了一下原来时间都浪费在模块窗口的数据获取上. cpudbg 的模块窗口有获取 编译器/壳 md5 crc sha-1 等信息.
这些信息都是要完整的读取一次文件. 目标文件1.6G 获取这些信息就相当于要读取三四个 1.6G, 在快的处理器,也是要花费不少时间的.
为了减少时间, 我加了一个判断. 只要是大于30MB的文件, 就不获取 md5 crc sha-1 信息了.
其中 "编译器/壳" 我还没加判断去掉.因为这个函数本身就有些问题.回头还要重写.
现在去掉上面三个信息获取后, 加载速度有原先的 33秒, 现在只要 6秒左右. 如下图:
大于30MB的文件
现在还是要花费6秒时间, 应该就是 "编译器/壳" 读取文件的时间. 以及其它模块 获取信息,浪费的时间.
回头我在选项上加个 模块信息获取的选项. 打勾的信息,都会获取, 不打勾的就不获取了.
或者像我猜的x64dbg那样,开个线程处理. 主线程负责显示 UI, 模块的数据信息用线程去做延时处理. 这样子 至少用户在视觉上 感觉不到延迟.
如果在线程还未处理完时,就调用alt+e显示模块窗口,那未处理的数据栏上就先显示 "N/A" 之类的信息展示.
暂时就先这样吧. 我相信很少有人会调试上G的文件的.
至于以后用怎样的优化方案,到时候再来研究研究. 反正最终加载的速度,肯定是要做到超过od1.x. 且尽量做到和x64dbg加载速度一样.
-------------------------------------------------------------------------------
2023.01.05
刚刚又测试了一下, 把 "编译器/壳" 加上判断大于30MB的不处理, 测试了一下 加载时间只节省了1秒, 用时 5 秒左右.
然后我又把 md5 crc sha-1 都去掉了,(就是任何模块不管多大的模块,都不获取这三个信息) 测试用时 3 秒左右.
这样算下来,加载速度只比x64dbg慢2秒左右, 看来我前面猜测的用线程处理, 速度上是完全能和x64dbg做对比的.
我看了 yzdbg 模块窗口好像并没有多少耗时的数据, 其中只有 "编译器/壳" 算是最耗时的了. 其它 md5 crc 之类的都没有获取,
怎么还会用时 15 秒之久. 而且 yzdbg 再关闭时用时也挺长的. cpudbg 关闭几乎是秒关.
-------------------------------------------------------------------------------
2023.01.05
刚刚想起来, 还有一个耗时的原因. od1.x 和 x64dbg 都是不能同时支持32位和64位程序. 而 yzdbg 和 cpudbg 都是同时支持32 和 64 模式.
这样一来, yzdbg 和 cpudbg 处理的数据会比其它调试器多一些. 其中用64位调试器调试32位程序时,
遇到 64 位的 ntdll.dll wow64.dll wow64win.dll 时, od1.x和x64dbg 都是不处理相关数据的. 这样一来这两调试器也就能节省一些时间.
等回头cpudbg优化之后再做一个加载测试,到时候把最后优化的加载时间,也在本贴反馈一下 :)
-------------------------------------------------------------------------------
2023.01.06
刚刚优化了一下,
测试的 Debug 版本, 加载 1G多的文件, 用时大概是 5 秒左右.
测试的 Release 版本, 加载1G多的文件, 用时大概是 900 毫秒左右.
感觉 Release 版本的加载时间, 已经十分逼近 x96dbg 的速度了. 
现在还没有开线程, 如果再开线程处理的话, 理论上来讲加载速度应该会比 x96dbg 更快一些. 毕竟x96dbg还套层qt.
因为开线程处理改动会较大, 为防止改错, 方便回滚. 当前 0.4.0.1 版本就提交svn. 下个版本再来提升加载速度. 
-------------------------------------------------------------------------------
to be continued...
|
发表于 2023-1-5 11:13:46
