UNICODE_STRING到wchar_t*的转换

这两天做了点Native API的东东,很近似驱动了。以前没有接触过驱动方面的东西,结果今天程序出了莫名其妙的bug。还好只是native api而没在内核,不然估计要看一天的蓝天白云下的雪崩了。

代码是注入的钩子,由于加载很早,先于exe本身的启动,故无法以dll注入的方式实现,只能以动态代码注入的形式,这样一来就无法在C语言级进行调试,只能通过反复的注释掉代码或插入CC指令、编译运行然后附加调试器的方法调试。

最后发现问题出在从UNICODE_STRING到C字符串的转换上。

开始是这么写的,并且90%的情况都能工作正常。

const wchar_t *str = punistr->Buffer;

这样写对么?看上去是对的,反正UNICODE_STRING初始化后最后是有个0字符的。

但是就有10%的概率不正常。仔细在一堆汇编里检查才发现,UNICODE_STRING中Buffer是个正常的字符串,而Length只到中间就结束了,操作系统这么做起到一个方便的截断字符串的功能,常用于取完整文件路径的目录。

于是修改代码为:

wchar_t str[256];
wcsncpy(str, punistr->Buffer, punistr->Length / 2);

对么?看上去解决了上面的问题,但是又崩了。再次仔细在一堆汇编里检查后发现原来strncpy不会往最后填写0字符。好吧,我承认这个错误不该在我这个水平上犯,但实际上我一直在用C++,很少用到strncpy,是故不知道或者忘了。

再次修改代码:

wchar_t str[256];
wcsncpy(str, punistr->Buffer, punistr->Length / 2);
str[punistr->Length / 2] = 0;

恩。它终于活过来了。立日志一篇提醒以后的自己。从这件事看来我现在还不适合写驱动诶。

One thought on “UNICODE_STRING到wchar_t*的转换

Leave a Reply

Your email address will not be published. Required fields are marked *

Using REAL email address will help you receive reply notifications.