先上图,patch之后的,原来只有2.98G,现在是3.86G了
去年7月入手小黑T410,到手就装了4G的内存,WINDOWS 7的破解补丁来的很快,很顺利就用上了3.86G(纠结于剩下的140M哪里去了?至今也没搞明白,只知道主板没有映射),而所谓的XP的种种补丁,不外乎就是Ramdisk,开启PAE之类的,毫无用处,最可怜的是竟然被某网友的“开启了PAE就能用到全部4G内存,系统属性页显示还是2.98G是假的”一说给忽悠了一年,没文化真可怕。。。就这么将信将疑用了一年,中间也纠结过一段时间,没有深入分析,近日越想越感觉不对劲,再来纠结纠结。。。
用WinDbg看看
代码:
lkd> dd MmHighestPhysicalPage 8088b124 000bf7ff 000bf399 00000040 00000000 lkd> dd MmNumberOfPhysicalPages 8088b128 000bf399 00000040 00000000 7fff0000
那是不是我的PAE没有真正启用呢?
那我们再用WinDbg看看
代码:
lkd> !pte 80800000 VA 80800000 PDE at C0602020 PTE at C0404000 contains 00000000008009E3 contains 0000000000000000 pfn 800 -GLDA--KWEV LARGE PAGE pfn 800
那么是不是系统偷偷地在用我的4G内存了,而给我显示出2.96G的假象呢?
再祭出我们的法宝WinDbg
代码:
lkd> dd poi(MmPhysicalMemoryBlock) 8ad75c80 00000007 000bf3ab 00000001 0000009d 8ad75c90 00000100 000bf17c 000bf282 000000dd 8ad75ca0 000bf40f 00000060 000bf70f 00000008 8ad75cb0 000bf71f 0000004c 000bf7ff 00000001
代码:
typedef struct _PHYSICAL_MEMORY_RUN { PFN_NUMBER BasePage; PFN_NUMBER PageCount; } PHYSICAL_MEMORY_RUN, *PPHYSICAL_MEMORY_RUN; typedef struct _PHYSICAL_MEMORY_DESCRIPTOR { ULONG NumberOfRuns; PFN_NUMBER NumberOfPages; PHYSICAL_MEMORY_RUN Run[1]; } PHYSICAL_MEMORY_DESCRIPTOR, *PPHYSICAL_MEMORY_DESCRIPTOR;
那么是不是我的主板根本就不识别这么大的内存呢??
那么我们再做做实验,用nt4的源代码编译一份NTLDR,把osloader.exe探测到的物理内存输出一份,下面是通过中断获取的内存布局图,BIOS专家们都叫把它做E820图
代码:
Base Size Type 0 9E800 1 9E800 1800 2 D2000 2000 2 DC000 24000 2 100000 BF17C000 1 BF27C000 6000 2 BF282000 DD000 1 BF35F000 12000 2 BF371000 1000 4 BF3F2000 1D000 2 BF40F000 60000 1 BF46F000 1F9000 2 BF668000 80000 4 BF6E8000 27000 2 BF717000 8000 1 BF71F000 4C000 1 BF76B000 C000 4 BF777000 3000 3 BF77A000 7000 4 BF781000 1000 3 BF782000 9000 4 BF78B000 1000 3 BF78C000 13000 4 BF79F000 60000 3 BF7FF000 1000 1 BF800000 800000 2 E0000000 10000000 2 FEAFF000 1000 2 FEC00000 10000 2 FED00000 400 2 FED1C000 4000 2 FED20000 70000 2 FEE00000 1000 2 FF000000 1000000 2 100000000 38000000 1
代码:
Base Size 0 9E800 100000 BF17C000 BF282000 DD000 BF40F000 60000 BF717000 8000 BF71F000 4C000 BF7FF000 1000 100000000 38000000
Beginning with P6 family processors, the IA-32 architecture supports addressing of
up to 64 GBytes (2^36 bytes) of physical memory.
也就是说,从Intel P6家族的CPU开始,(PAE技术让)IA-32架构的CPU就支持对64G的物理内存进行寻址, P6家族可是很老CPU了,奔二,奔三就属于P6家族的,所以XP这个后来才发布的操作系统不可能连PAE都没考虑进去吧。
既然那块4G以上的内存地址被主板识别,NTLDR也探测到了,操作系统也支持,那我们为什么还是用不到呢?到底是NTLDR没有告诉ntkrnlpa.exe,还是ntkrnlpa.exe自己给我们截断了?
这怎么调试呢?Bochs?不行,我总共才4G内存,哪有那么多内存分配给Bochs用呢,要有XP的ntos的源码就好了,ntos的入口函数为
VOID KiSystemStartup(PLOADER_PARAMETER_BLOCK KissLoaderBlock)
在NTLDR向ntos交权的时候,会将内存描述链表通过结构体参数LOADER_PARAMETER_BLOCK传过去,这个结构体原型为
代码:
typedef struct _LOADER_PARAMETER_BLOCK { LIST_ENTRY LoadOrderListHead; LIST_ENTRY MemoryDescriptorListHead; LIST_ENTRY BootDriverListHead; ULONG KernelStack; …… 后面太长,省略掉 } LOADER_PARAMETER_BLOCK, *PLOADER_PARAMETER_BLOCK;
代码:
typedef struct _MEMORY_ALLOCATION_DESCRIPTOR { LIST_ENTRY ListEntry; TYPE_OF_MEMORY MemoryType; ULONG BasePage; ULONG PageCount; } MEMORY_ALLOCATION_DESCRIPTOR, *PMEMORY_ALLOCATION_DESCRIPTOR;
咦!NTLDR貌似真的没有把4G以上的地址传过来啊,怎么到FF000这块内存就完了呢?
难道NTLDR私自把4G以上的地址给裁了?难道一切罪恶的源泉在NTLDR?在此我犯了个严重的错误,以为胜利在望,加班加点研究NTLDR,最好成功跳过NTLDR截去4G以上内存的代码了,启动发现XP依然显示2.98G的可用内存,怎么回事呢?回过头来再分析NTLDR,才发现了如下的代码
代码:
if ( (_BYTE)BlUsePae_0 ) { v10 = BlpAllocatePAETables(); if ( v10 ) return v10; } else { BlpTruncateDescriptors(0xFFFFFu); }
那还是锁定ntkrnlpa.exe分析吧,充分发扬废寝忘食的精神,终于找到了一个可疑的函数ExVerifySuite,这不会就是验证我们版本的函数吧,网上一查,发现有位“老生常谈”早就发现了,他的文章在这里
http://thxlp.wordpress.com/2008/08/03/%E8%80%81%E7%94%9F%E5%B8%B8%E8%B0%88-windows%E5%92%8C4g%E4%BB%A5%E4%B8%8A%E7%89%A9%E7%90%86%E5%86%85%E5%AD%98/
汗。。。。差距啊,不过这位老大发现这么久竟然不出补丁,拯救我们广大百姓于水货,哎。。。害我熬夜伤神这么久。。。。
不过这位“老生”的代码不知道从哪里搞的,nt4源码里没有MiCheckPaeLicense这个函数,而windows2000的源代码里虽然有这个函数,但差别很大,wrk的源代码里也不是那样的,反汇编XP的ntkrnlpa.exe,代码如下
代码:
int __usercall MiCheckPaeLicense<eax>(PLOADER_PARAMETER_BLOCK LoaderBlock<eax>) { EndPage = 0; LoaderBlock1 = LoaderBlock; MaxPageCount = 0x100000u; MaxPage = 0; if ( ExVerifySuite(DataCenter) == 1 ) { if (LoaderBlock->u.I386.VirtualBias ) { MaxPageCount = 0x400000u; // booting /3gb: 16G MaxPage = 0x400000u; } else { MaxPageCount = 0x1000000u; } // DataCenter: 64G } else { if ( MmProductType == 0x690057 || ExVerifySuite(Enterprise) != 1 ) { if ( ExVerifySuite(ServerAppliance) == 1 ) MaxPageCount = 0x80000u; // 2G else MaxPage = 0x100000u; // 4G } else { MaxPageCount = 0x800000u;// Advanced Server is permitted a maximum of 32gb } }
从这段代码里可以看出,MiCheckPaeLicense函数会检查操作系统的版本,如果是DataCenter,就允许使用64G内存,Advanced Server为32G,如果为精简版则为2G,其他版本为4G,看来真是ntkrnlpa.exe在作怪,先别急着patch,验证内存限制的还有一个地方,在MmAddPhysicalMemoryEx函数里也会调用ExVerifySuite这个函数,代码如下:
代码:
if ( ExVerifySuite(DataCenter) == 1 ) { LimitPage = 0x1000000u; // DataCenter : 64G } else { if ( MmProductType == 0x690057 || (v9 = ExVerifySuite(Enterprise) == 1, LimitPage = 0x800000u, !v9) )// Advanced Server : 32G LimitPage = 0x100000u; // Other : 4G }
看成果吧
代码:
lkd> dd MmHighestPhysicalPage 8088b124 00137fff 000f7399 00000040 00000000 lkd> dd MmNumberOfPhysicalPages 8088b128 000f7399 00000040 00000000 7fff0000 lkd> !pte d0800000 VA d0800000 PDE at C0603420 PTE at C0684000 contains 00000001004DF963 contains E15C080000000400 pfn 1004df -G-DA--KWEV not valid Proto: E15C0800
再看物理内存块
代码:
lkd> dd poi(MmPhysicalMemoryBlock) 8baa3c70 00000008 000f73ab 00000001 0000009d 8baa3c80 00000100 000bf17c 000bf282 000000dd 8baa3c90 000bf40f 00000060 000bf70f 00000008 8baa3ca0 000bf71f 0000004c 000bf7ff 00000001 8baa3cb0 00100000 00038000 0001000a 6c4d6d4d
后面部分比较仓促,主要是听到重任到来的消息,没时间仔细写了,补丁没写完,估计一时半会完成不了了,仓促发帖,开始潜伏。。。
忙里偷闲,补丁写好了,赶紧传上来共享,本机测试通过,如果使用过程中发现问题请给我留言。。。
最近忙死了,几天没上网了,更没时间去研究这个,让各位失望了。。。 坛子里的牛人们如果有时间去研究研究吧,MengXP执着的钻研精神让我佩服,离成功只有一步之遥了,希望大家能齐心协力,早日解决这些问题,我只能忙过这阵子再来了。。。
---------------------------------------------------------------
实在抱歉,上个版本出的太匆忙了,严重问题都没有发现,下载这个版本XP64G20110805.rar的朋友请骂我,实在是疏忽大意,抱歉抱歉。。。。
----------------------------------------------------------------------------------------------------------------------------------------------
终于有时间继续研究一下了,发现原因主要在DMA,修改之后,USB存储设备基本可以正常使用了,先上补丁,回头再发技术帖