Re: 64位windows下面的文件版本
Windows内核调试
64位windows下面的文件版本
Thomson
2009-05-27, 18:31 下午
我在64位windows下面的%systemroot%system32\下面,使用' dumpbin.exe /headers kernel32.dll | find "PE" ',命令,发现输出竟然是" 10B magic # (PE32)",说明这个文件是32位的,可以在同目录下面launch notepad.exe,用process explorer来查看该进程load的dll列表,确显示"Image: 64-bit", 并且load address也是32位的,这是为什么呢???
我在%systemroot%下面search了kernel32.dll,发现有很多存在于WinSxS目录下,并且是PE32+格式的,怎么会与这个有关系呢?
Re: 64位windows下面的文件版本
格蠹老雷
2009-05-27, 22:48 下午
对的，64位版本的Windows是把64位的系统文件放在system32目录下，而且像kernel32.dll，名字中的32仍不影响它可能是64位版本的。
Re: 64位windows下面的文件版本
Thomson
2009-05-27, 23:02 下午
我开始也认为64位版本的程序都放在system32目录下面,可以我用dumpbin来查看文件头,发现是PE32的,而不是PE32+,说明在system32下面也是32位的文件...
另外,对于64位程序,比如system32目录下面的notepad.exe,运行起来后,在windbg里面可以看到,kernel32.dll的路径指向了"c:\windows\system32\kernel32.dll", 但是用"!dh"命令可以看到文件头指示是PE32+类型的...这个观察结果上上面是矛盾的....怎么解释呢?
Re: 64位windows下面的文件版本
格蠹老雷
2009-05-28, 12:47 下午
在某些版本的Windows中，会使用NTFS的Hard Link机制使system32下的文件是WinSXS下文件的链接，可以使用下面的工具hlscan来观察：
http://www.microsoft.com/downloads/thankyou.aspx?familyId=289adee4-abb3-4e18-ab07-c77db8654979&displayLang=en&hash=m4o75%2blFR8zSvBpZwJFF7x%2bmL4H%2bwTxKVikDE06LZxyoEQvBHfbcNS869j6%2bedxYMm2%2bMPnEXIRo23Z8EaMTEA%3d%3d
Re: 64位windows下面的文件版本
格蠹老雷
2009-05-31, 21:16 下午
今天顺便看了一下XP64的情况，在一个32位的EXE进程中，使用的kernel32.dll是syswow64目录下的：
1: kd> lmv m kernel32
start end module name
00000000`7d4c0000 00000000`7d5f0000 kernel32 (pdb symbols) d:\symbols\wkernel32.pdb\A45A226167C84E5C95E55E442F5375ED2\wkernel32.pdb
Loaded symbol image file: kernel32.dll
Image path: C:\WINDOWS\syswow64\kernel32.dll
注意其PDB文件名为wkernel32.pdb，所以这个版本的kernel32.dll在开发时的本来名字很可能是wkernel32.dll.
对于普通的64位应用，比如本机的notepad.exe，使用的是system32下的kernel32.dll:
1: kd> lmv m kernel32
start end module name
00000000`78d40000 00000000`78eb2000 kernel32 (pdb symbols) d:\symbols\kernel32.pdb\BD62F2C82DBA4B84869EE8DDE076BED92\kernel32.pdb
Loaded symbol image file: kernel32.dll
Mapped memory image file: d:\symbols\kernel32.dll\42438B79172000\kernel32.dll
Image path: C:\WINDOWS\system32\kernel32.dll
Re: 64位windows下面的文件版本
Thomson
2009-06-01, 20:11 下午
嗯,是的,谢谢张老师.
我自己也看了一下,发现问题原来是在于,dumpbin.exe调用了link.exe,后者只是一个32位的process,所以正常情况下,应该是读取不了system32目录下面的文件的. 但是link.exe已经考虑了会run在64位的情况,它在读取文件前,会前把Wow64 file system redirection disable掉,再读取完后会恢复回去...这个redirection flag好像是存在TEB里面的一个值...
但是还有一个问题是,这个disable对link.exe的当前目录以子目录是无效的(使用相对路径的时候),所以出现了我前面观察到的结果,有的可以,有的不可以. 这个行为只是根据观察结果的猜测.
另外在32位下面可以使用这个alias, sysnative, 来读取实际system32目录下面的文件. 比如 c:\windows\sysnative