|
阅读：1691回复：4
关于UNICODE_STRING的隐患
UNICODE_STRING这个结构在DDK里的定义是Length表示该字符串的字节长度（不含\0），MaximumLength表示该缓冲块的最大可用字节数长度。
如果我挂接了系统的一些API，例如LdrLoadDll的话，传进来的文件名也是UNICODE_STRING的，但调试发现其用Length表示字符数，MaximumLength也是表示最大可用字符数。但挂接的NtCreateFile发现传进来的UNICODE_STRING是按字节数计数的。请问应该怎样处理这种情况，或者说怎样分辨Length表示是的字符数还是字节数？ |
|
|
沙发#
发布于：2008-08-24 22:31
Length好像是按字节计数的，但是在索引buffer的时候是按字符数来的
|
|
|
板凳#
发布于：2008-08-25 03:38
引用第1楼microbe于2008-08-24 22:31发表的 : 呵呵，这个当然是清楚的。我的意思是对于通过API传进来的字符串参数，Length有时不太清楚表示的是字节，还是字符，例如系统调用ZwCreateFile打开C:\test.txt，那么对于传进来的字符串参数"C:\\test.txt"，Length有时是11，有时是22，如果按DDK上说的，正确的应该是22才对。但系统似乎都一样接受，都能正确处理。 由于我要用自己写的函数替换系统里的像NtCreateFile的API，所以如果不能处理这种情况，则没法做了，我虽然有些后备方案，但我现在需要各位给一些来源于微软的肯定的说法。。。 |
|
|
地板#
发布于：2008-08-25 08:46
引用第2楼goyejin于2008-08-25 05:38发表的 : 来源于微软的肯定的说法: always in bytes |
|
|
|
地下室#
发布于：2008-08-25 09:42
引用第3楼rayyang2000于2008-08-25 08:46发表的 : 有些是微软自己弄出来的，例如我调用Kernel32.dll的LoadLibrary，传入的参数不是UNICODE_STRING结构的，这个结构是微软自己根据传进去的字符串而构造的，然后它调用Ntdll.dll的LdrLoadDll并将这个UNICODE_STRING传进去，而我写的用于代替LdrLoadDll的函数检测到如果将Length按字节计算的话，输出的字符串不是开始调用LoadLibrary的，而是前面的一部份，验证之后发现Length表示的是字符数。但大多数时候LdrLoadDll都是使用的字节数。所以，微软的说法对我的程序很有帮助。。。 |
|