Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Windows › Windows XP Ram Limit
New Posts  All Forums:Forum Nav:

Windows XP Ram Limit - Page 3

post #21 of 100
@TELVM: Many thanks to you for pointing into the right direction with the link! Much appreciated!!!

I tested it on XP SP3 with the hal.dll from XP SP1 and it worked. Be careful I have not done a lot of tests, but connecting a USB stick worked.
Be advised that the link patches another location very near my patching location. But in my opinion the patch from the link only enables up to 16 GB RAM instead of mine which should enable 64 GB RAM.

For XP SP3 we patch the following offset in ntkrpamp.exe which enables all available RAM up to 64 GB:
- WinDbg "bp nt!MiPagesInLoaderBlock+0x5d" from
e0d73851 751b jne nt!MiPagesInLoaderBlock+0x7a (e0d7386e)
to
e0d73851 90 nop
e0d73852 90 nop
- IDA from
INIT:005D0851 jnz short loc_5D086E
to
INIT:005D0851 nop
INIT:005D0852 nop
- hex editor offset 0x1B2A51 from
75 1B
to
90 90

After ntkrpamp.exe is changed we have to do the following to replace the original kernel file:
- correct the checksum of ntkrpamp.exe with LordPE
- add /PAE switch to boot.ini
Do not omit this step otherwise we can not address the full RAM! This is necessary, because
we will use hal.dll from XP SP1.
- replace the original kernel file by the patched one:
- rename the file "C:\Windows\Driver Cache\i386\driver.cab" to "driver.cab_"
- rename the file "C:\Windows\Driver Cache\i386\sp3.cab" to "sp3.cab_"
- rename the file "C:\Windows\system32\ntkrnlpa.exe" to "ntkrnlpa.exe_"
- cancel the "Windows File Protection" message box and choose "Yes"
- copy the patched file ntkrpamp.exe to "C:\Windows\system32\ntkrnlpa.exe"
- cancel the "Windows File Protection" message box and choose "Yes"
- rename the file "C:\Windows\system32\hal.dll" to "hal.dll_"
- copy hal.dll from XP SP1 (internal file name halmacpi.dll) to "C:\Windows\system32\hal.dll"
- do not forget to add the boot.ini switch /PAE, otherwise we can not address the full RAM,
because we use hal.dll from XP SP1
- reboot

Again many thanks to TELVM for clearing things up!
post #22 of 100
My pleasure thumb.gif .
HAL-9011
(14 items)
 
  
CPUMotherboardGraphicsRAM
Phenom II 960T X6 4.1GHz ASUS M4A89GTD Pro Radeon HD 6870 16 GB DDR3 1600MHz 8·8·8·24 
Hard DriveHard DriveHard DriveOptical Drive
OCZ Vertex 4 128GB OCZ Vertex 2 120GB WD Caviar Black 1TB LG DVD-RW 
CoolingCoolingOSOS
Noctua NH-D14 Accelero S1 R.2 + 2x NF-F12 Se7en x64 Se7en x32 
PowerCase
Antec TP-650W CM HAF 912 + 
  hide details  
Reply
HAL-9011
(14 items)
 
  
CPUMotherboardGraphicsRAM
Phenom II 960T X6 4.1GHz ASUS M4A89GTD Pro Radeon HD 6870 16 GB DDR3 1600MHz 8·8·8·24 
Hard DriveHard DriveHard DriveOptical Drive
OCZ Vertex 4 128GB OCZ Vertex 2 120GB WD Caviar Black 1TB LG DVD-RW 
CoolingCoolingOSOS
Noctua NH-D14 Accelero S1 R.2 + 2x NF-F12 Se7en x64 Se7en x32 
PowerCase
Antec TP-650W CM HAF 912 + 
  hide details  
Reply
post #23 of 100
Only for completeness of this thread.

After intensive testing I found out that after applying the patch my external USB HDD does hang very often and looses power. This could hang the complete computer. It seems to be related to hal.dll from XP SP1. If we switch back to the hal.dll from XP SP3 and use a patched kernel the computer won't boot anymore. But if we switch back to hal.dll from XP SP3 and install VSuite Ramdisk without adding any ram disks the system boots up fine. By investigating further we see that the driver that seems to solve the problems is rxvstor.sys, this can be installed with rxvstor.inf and installs a new virtual SCSIAdapter device. If we install the included bus driver only, named rxvbus.sys, we get one or more exclamation marks in device manager on USB devices and the problem still persists. We could also install both drivers and it works, but only rxvstor.sys is needed really. The above was verified on two of my systems. To get the drivers simply install VSuite Ramdisk and look into the program folder. In the end I recommend to use Windows 2003 Server to support more memory on x86, because I do not know what other side effects the patch will have on XP SP3.
post #24 of 100
so nice i found this thread wink.gif
thanks for all the info.
preparing to upgrade hardware to ivy bridge platform and would like to use 8 gigs of ram instead of 4, as it's already maxing out even with my current pentium 4 system.

everything seems clear, just the part about correcting the checksum of ntkrpamp.exe with LordPE... how to do it?

thx,
post #25 of 100
Necroing again! Haha!

Nice this is of some help to you pranza!

- patch ntkrnlpa.exe
- start LordPE > press button "PE Editor" > choose ntkrnlpa.exe > Open > click on the question mark symbol besides the checksum edit control >
the checksum should change > press button "Save" > OK > close LordPE
post #26 of 100
Hi - I am trying to reproduce your success but I am having issues:

SYSTEM has 4GB

I am not able to reproduce the modifications you did, tried on GERMAN XP Professional SP3 Kernel.
The hexoffsets differ, if I try to modify the same address the resulting kernel will not boot.

I would like to understand how to determine the needed offsets for each possible ntkrpamp version using windbg, but I just don't know how to use it...

What am I trying to do?
Windows XP SP3 Pro german (ntkrpamp build5.1.2600.5512 as well as latest and greatest 5.1.2600.6419) do the >4GB patch
PAE-Kernel Multiprocessor (ntkrpamp)

I also have some halmacpi to play with:
from original SP1 (5.1.2600.1106) german
as well as newer german ones (inbetween SP1 and SP2) which might solve the USB problems you ran into (I would like to try that)
as well as german SP3 5.1.2600.5512
as well as english SP3 5.1.2600.5512


My problem is: I have absolutely no clue using Windbg. Do I have to do REMOTE debugging to set breakpoints?




I played a little more:

I thought when using ENGLISH SP3 files, it might actually work,
(the hex offsets are not the same in the german one (when I try to replace the same offsets in german as you did, the system won't boot)

So here is what I did:

System is still Windows XP SP3 GERMAN + almost latest patchlevel


I downloaded SP3 english and extracted ntkrpamp as well as halmacpi from it...

expanded english sp3 ntkrpamp.ex_ into sys32\ntkrnlpa.exe 5.1.2600.5512
expanded english sp3 halmacpi.dl_ into sys32\hal.dll 5.1.2600.5512

applied your fix to ntkrnlpa.exe
- hex editor offset 0x1B2A51 from
75 1B
to
90 90

fixed the checksum in pe-header of ntkrnlpa.exe

SFC is turned off, it won't replace the files with other ones - I doublechecked that!

rebootet the system - it starts (does NOT crash - even with eng sp3 halmacpi)

tried several boot.ini settings:
/fastdetect /noexecute=OptIn
-> PAE shown in system info (3,25GB) but is used for NX
TaskManager shows 3405932kb
this represents system default boot.ini

then I tried
/fastdetect /noexecute=OptIn /PAE
-> PAE shown in system info (3,25GB) but is used for NX
TaskManager shows 3405932kb
same result as default

then I tried
/fastdetect /noexecute=AlwaysOff /PAE
-> PAE IS shown in system info (3,25GB), NX options greyed out <-PM to Kondra states otherwise, I was wrong with that....
TaskManager still shows only 3405932kb


So everything works as if I had not applied the patch at all, doesn't it?....
What am I missing?
Why does this not work?

Afterwards I tried the same with german HALMACPI from SP1 5.1.2600.1106 (although from what I've read on this topic implies that downgrading halmacpi should only be necessary if new kernel does not boot up properly)
->old halmacpi german SP1 5.1.2600.1106 gives exactly the same results


Is it because I am using english kernel files within german xp?

I would love to patch my german kernel but I still don't understand how to use WinDbg...


Do you have any idea?
Is anybody able to do the necessary changes for ntkrpamp GERMAN SP3 5512 and/or latest and greatest (different hex-offsets are necessary)?

Has anybody successfully reproduced what Kondra achieved on any XP SP3?
Edited by achm3t - 2/21/14 at 4:05pm
post #27 of 100
Code:


I decided to make a tutorial as a proof of concept, because I would really like to see more people
reversing the Windows kernel and maybe fix the USB issues I had in the past. Always keep in mind if
it does not work simply use Windows 2003 Server to support more than 4 GB RAM.


Software used
---------------

- VMWare Workstation Version 9.0.0 build-812388
- Microsoft XP SP3 with the following kernel:
  File Name: "C:\Windows\system32\ntkrnlpa.exe"
  File Version: 5.1.2600.5512 (xpsp.080413-2111)
  Internal Name: ntkrpamp.exe
- Microsoft XP SP1 with the following hal:
  File Name: hal.dll
  File Version: 5.1.2600.1106 (xpsp1.020828-1920)
  Internal Name: halmacpi.dll
- Microsoft Driver Development Kit Version 7600.16385.1
- Microsoft Debugging Symbols for Windows XP SP3
- IDA Version 5.2.0.908
- 010 Editor Version 3.1.3
- LordPE Deluxe b by yoda


Reversing Process
-------------------

- Create a new VMWare machine with at least 2 processors and 5 GB of RAM. We need at least 2 CPUs,
  otherwise XP will not use the multi processor kernel file. The 5 GB RAM are optional to check if
  the RAM patch is working at the end. Install Windows XP SP3 on this virtual machine.
- Install Microsoft Driver Development Kit Version 7600.16385.1 to "C:\WinDDK\7600.16385.1".
- Install Debugging Symbols to "C:\Symbols_XP_SP3".
post #28 of 100
Code:
- In the virtual machine open boot.ini and change the following line from:
  multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
  to
  multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /PAE /fastdetect /debugport=COM2 /baudrate=115200  Save the file after the change. We have to configure this to be COM port 2, otherwise a connection
  is not possible. The /PAE switch is set, because otherwise we get a kernel exception if patching the
  loaded kernel with WinDbg later on. If we use hal.dll from XP SP1 and do not set the /PAE switch
  Windows will load the mulit processor kernel without PAE.
- Rename the file "C:\Windows\system32\hal.dll" to "hal.dll_" and copy hal.dll from XP SP1 (internal
  file name halmacpi.dll) to "C:\Windows\system32\hal.dll".
- Shut down the virtual machine and change the settings. In VMware Menu > VM > Settings... >
  Hardware tab > Add... > select "SerialPort" > Next > choose "Output to named pipe" > Next >
  enter the following:
  - Named pipe: \\.\pipe\com_1
  - This end is the server.
  - The other end is an application.
  - Device status: check "Connect at power on"
  > Finish
  - on the right side under "I/O mode" check "Yield CPU on poll" > OK
- Create a command file named "StartWinDbg-VMWare-XP-SP3.cmd" on drive C: with the following content:
  set _NT_SYMBOL_PATH=C:\Symbols_XP_SP3
  start C:\WINDDK\7600.16385.1\Debuggers\windbg -b -k com:pipe,port=\\.\pipe\com_1,baud=115200,resets=0,reconnect
- The parameter -b means we wanna start kernel debugging. This attaches the OS as early as possible
  to WinDbg.
- Start WinDbg with the command file "StartWinDbg-VMWare-XP-SP3.cmd" and press Ctrl+Alt+K inside
  WinDbg to breakin on the first symbol load at the next boot.
- Start the VMWare machine, boot XP SP3 and wait for a debugger connect. You should see the following
  text inside WinDbg:
  Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
  Copyright (c) Microsoft Corporation. All rights reserved.
  Waiting for pipe \\.\pipe\com_1
  Waiting to reconnect...
  Will breakin on first symbol load at next boot.
  Connected to Windows XP 2600 x86 compatible target at (Sat Mar  1 08:18:31.593 2014 (UTC + 1:00)), ptr64 FALSE
  Kernel Debugger connection established.
  Symbol search path is: C:\Symbols_XP_SP3
  Executable search path is: 
  Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
  Built by: 2600.xpsp.080413-2111
  Machine Name:
  Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
  System Uptime: not available
  nt!DebugService2+0x10:
  80531eb2 cc              int     3
- If VMWare closes during the debugger connect simply start VMWare and the virtual machine once again.
- At the WinDbg kd prompt enter "bp nt!ExVerifySuite" and press "Enter". This will set a breakpoint
  at the entry point of the function ExVerifySuite inside the NT kernel. Press F5 (Go) to let the
  virtual machine run. When our breakpoint is hit press Shift + F11 (Step Out). This will return to
  the code location after the call to ExVerifySuite. Press F10 (Step Over) to go one step further.
  Now we should see the following inside the WinDbg window:
  kd> bp nt!ExVerifySuite
  kd> g
  Breakpoint 0 hit
  nt!ExVerifySuite:
  805384ce 8bff            mov     edi,edi
  kd> gu
  nt!MiPagesInLoaderBlock+0x5b:
  806a784f 3c01            cmp     al,1
  kd> p
  nt!MiPagesInLoaderBlock+0x5d:
  806a7851 751b            jne     nt!MiPagesInLoaderBlock+0x7a (806a786e)
- In the WinDbg menu go to View > Memory > on the upper left we will see "Virtual:" > enter the
  address of our last code line here "806a7851" > we now see the two bytes 75 1b these have to be
  patched to 90 90 (nop). In menu go to View > Disassembly we can now see that the code has changed
  from
  806a7851 751b            jne     nt!MiPagesInLoaderBlock+0x7a (806a786e) [br=1]
  to
  806a7851 90              nop
  806a7852 90              nop
- Type "bc 0" at the kd prompt to clear our breakpoint and press F5 (Go) to run the virtual machine.
  If we look inside the task manager or run sysdm.cpl now we see the full RAM and not only 3 to 4 GB
  as usual.
- We have verified that the patch is working. Now we need to retrieve the correct patch location
  inside the kernel file. Start up IDA 32 Bit and load ntkrpamp.exe as "PE Executable". Go to Menu >
  Search > text... > String: ExVerifySuite > check "Find all occurences" > OK. In the result window
  double click on the following line:
  INIT:005D084A  sub_5D082E  call _ExVerifySuite@4 ; ExVerifySuite(x)
- We see the following code section in IDA:
  INIT:005D084A                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
  INIT:005D084F                 cmp     al, 1
  INIT:005D0851                 jnz     short loc_5D086E  -> this jump has to be nopped
  INIT:005D0853                 cmp     [esi+64h], edi
  INIT:005D0856                 jnz     short loc_5D0861
  INIT:005D0858                 mov     [ebp+var_4], 1000000h
  INIT:005D085F                 jmp     short loc_5D08A5
- Change the tab window in IDA to "Hex View-A" and note down the byte sequence which is in our case:
  E8 7F 0C E9 FF 3C 01 75 1B
- Now it is time to launch "010 Editor" and load ntkrpamp.exe. Go to Menu > Search > Find... >
  Type: Hex Bytes (h) > Value: E8 7F 0C E9 FF 3C 01 75 1B > check "Find All Occurrences" > Find All.
  The byte sequence is found one time at offset 0x1B2A4A and our jump is located at offset 0x1B2A51.
  Now we patch the two jump bytes at 0x1B2A51 from 75 1B to 90 90, save ntkrpamp.exe and close the file.
- Launch LordPE and click on the button "PE Editor" > choose ntkrpamp.exe > click on the question
  mark button right of the checksum value > the checksum will change to 001FA1AB for the german
  version of ntkrpamp.exe and to 001F5FA3 for the english version. Click on Save, OK and Exit.
- The kernel file ntkrpamp.exe is now completely patched for a RAM usage of 64 GB in XP SP3.
- To replace the original kernel file by the patched one we have to do the following:
  - start the virtual machine without attached WinDbg
  - add /PAE switch to boot.ini (already done before)
  - if present remove the /noexecute=optin switch in boot.ini (already done before)
  - rename the file "C:\Windows\Driver Cache\i386\driver.cab" to "driver.cab_"
  - rename the file "C:\Windows\Driver Cache\i386\sp3.cab" to "sp3.cab_"
  - rename the file "C:\Windows\system32\ntkrnlpa.exe" to "ntkrnlpa.exe_"
  - cancel the "Windows File Protection" message box and choose "Yes"
  - copy the patched file ntkrpamp.exe to "C:\Windows\system32\ntkrnlpa.exe"
  - cancel the "Windows File Protection" message box and choose "Yes"
  - rename the file "C:\Windows\system32\hal.dll" to "hal.dll_" (already done before)
  - copy hal.dll from XP SP1 (internal file name halmacpi.dll) to "C:\Windows\system32\hal.dll" (already done before)
  - rename the file "C:\Windows\Driver Cache\i386\driver.cab_" back to "driver.cab"
  - rename the file "C:\Windows\Driver Cache\i386\sp3.cab_" back to "sp3.cab"
  - reboot the virtual machine and check your installed RAM in taskmanager or by running sysdm.cpl

Happy Reversing!
post #29 of 100
I hope this helps. Sorry I had to split the thread into 2 separate ones, seems to be some kind of overflow protection in this forum.
post #30 of 100
Hi Kondra,

thank you VERY much for this detailed Howto! I will definetely try this within the coming weeks.
However before this - I will try to redo my previous test with english kernel on a different machine which has more than 4GB of RAM, because I think the reason why this did not work is that my machine does not seem to support memory remapping. I think this is the case, because when I boot up the machine on Windows XP Pro 64Bit I see the same amount of free memory (3,25GB). This could be the explanation why it did not work as intended before. When I'm done with this, I will give the WinDbg-thing a try. I will let you know the results (including USB-plans).

Again: Thank you very much, I can see how much time you spent for this!
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Windows
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Windows › Windows XP Ram Limit