dbgLua,让lua脚本也能控制windbg进行调试(更新1.0.1.1)

关于dbgLua:
这是一个让windbg支持lua脚步的扩展程序。写这个程序的主要目的是希望能简单的取代windbg本身的脚本。因为我确实不喜欢windbg那种形式的脚本。

使用方法:将dbgLua.dll拷贝到windbg的winext下,编写lua脚本。调试的时候,在输入框中输入“!dbgLua.run d:\sample.lua”其中“d:\sample.lua”是你的脚步路径。

以下是1.0.0.1版本所支持的lua函数(后续可能会慢慢添加更多,看需求了)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
dbgLua 1.0.1.1 API
dprint 输出信息到windbg command窗口,例如dprint("hello")
exec 执行一条windbg命令,例如exec("bp kernel32!CreateFileW")
getreg 获得当前被调试对象的寄存器数据,例如eax_val = getreg("eax")
setreg 设置当前被调试对象的寄存器数据,例如setreg("eax", 123456)
readbyte 读取当前被调试对象的内存器数据,大小1字节
readword 同上,大小为2字节
readdword 同上,大小为4字节,例如mem_val = readxxxx(0x410000)
writebyte 写入当前被调试对象的内存器数据,大小1自己
writeword 同上,大小为2字节
writedword 同上,大小为4字节,例如writexxxx(0x410000, 654321)
readunicode 读取一个unicode字符串,例如str = readunicode(0x410000)
readascii 读取一个ascii字符串,例如str = readascii(0x410000)
wait 等待事件,例如exec("bp kernel32!CreateFileW;g");wait();
evalmasm masm表达式求值,例如val = evalmasm("11+2*3")
evalcpp cpp表达式求值,例如val = evalcpp("sizeof(char)")
getmoduleinfo 通过模块名获得模块基址和大学,例如base,size = getmoduleinfo("kernel32")
search 二进制查找,例如found = search(base, size, "cc 89 75 fc eb ")</blockquote>

具体的结合这些函数进行调试的例子还没有准备好,等有机会了,我会准备好调试案例放到这里来。

另外这是一个初始版本,不保证没有bug,如果你在使用中发现了bug,或者有好的想法,例如添加什么函数功能,不妨联系我。

下载:

dbgLua(v1.0.1.1)

dbgLua(v1.0.0.1)

Debugging

关于判断文件是否存在最高效的函数

判断文件存在方法有很多,例如CreateFile,FindFirstFile,GetFileAttributes,PathFileExists等等。但是哪一种更加高效呢?其实作为常识,可能都能判断出GetFileAttributes和PathFileExists会比较快(而实际上PathFileExists就是调用的GetFileAttributes)。

下面是google一份开源代码中提到的统计结果

1
2
3
4
5
// NOTE: This is the fastest implementation I found. The results were:
// CreateFile 1783739 avg ticks/call
// FindFirstFile 634148 avg ticks/call
// GetFileAttributes 428714 avg ticks/call
// GetFileAttributesEx 396324 avg ticks/call</blockquote>

为什么会这样呢?大概了看了下,原因应该是这样的。

1.CreateFile会创建句柄,需要一个完整IO流程,所以需要的时间比如非常长。
2.FindFirstFile回去查询文件夹的文件,虽然不会真正的打开文件句柄,并且在文件已经被缓存的情况下,走的是fastio流程,所以查询时间大幅下降,但是操作略微繁琐,导致他不是最好的选择。

  1. GetFileAttributes 和GetFileAttributesEx 也设置了QueryOnly标志,不需要获得真正的句柄,并且能够走fastio流程,也没有文件夹查询等工作,所以速度最快。

那么为什么GetFileAttributesEx 会快那么一点点呢?因为这个函数少了一个获取BasicInformation,也就是少了一个fastio流程。所以速度更快。这样看来,自己实现一个PathFileExistsEx效率可以高过PathFileExists了。(其实没多大实际意义)

google就是这样做的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
bool File::Exists(const TCHAR* file_name) {
ASSERT1(file_name && *file_name);
ASSERT1(lstrlen(file_name) > 0);
// NOTE: This is the fastest implementation I found. The results were:
// CreateFile 1783739 avg ticks/call
// FindFirstFile 634148 avg ticks/call
// GetFileAttributes 428714 avg ticks/call
// GetFileAttributesEx 396324 avg ticks/call
WIN32_FILE_ATTRIBUTE_DATA attrs = {0};
return 0 != ::GetFileAttributesEx(file_name, ::GetFileExInfoStandard, &attrs);
}

NTInternals