Question about Software RAID5 "Patch"

[Zacam]

Firstly, my apologies, this is going to be a long one. Grab a sandwich and some coffee before reading this one through.

So, in looking at the toms hardware guide on how this (the XPRAID5 Hack)was done, I examined the results.

Frankly, I was confused. Sure, it works, but it does mangle a few things. I have to wonder if the person who brought this to THG's attention (and why nobody in THG bothered) actually looked at these files with a disassembler. The fix should have and could have been a little cleaner.

Allow me to illustrate using excerpts from the dmboot.sys and dmconfig.dll files.

I'll try and make this make sense. For reference, I use tiny hexer and PE Explorer.

Here's a code snippet of DMBOOT.SYS (the original) at the location to be changed:

0002107A						   SSZ0002107A_WINNT:
 0002107A  57494E4E5400				  db	'WINNT',0
 00021080  0000						  Align	2

 00021082						   SSZ00021082_SERVERNT:
 00021082  5345525645524E5400			db	'SERVERNT',0
 0002108B  000000						Align	2

Let's see what PE Explorer Disassembler says about the recommended HEX edit chage (Hacked DMBOOT.SYS, same location):

0002107A						   L0002107A:
 0002107A  53					   		db	53h;   'S'
 0002107B  45					   		db	45h;   'E'
 0002107C  52					   		db	52h;   'R'
 0002107D  56					   		db	56h;   'V'
 0002107E  45					   		db	45h;   'E'
 0002107F  52					   		db	52h;   'R'
 00021080  4E					   		db	4Eh;   'N'
 00021081  54					   		db	54h;   'T'

 00021082						   SSZ00021082_WINNT:
 6CAC5D4C  57494E4E5400					  db	'WINNT',0
 00021088  00					   		db	00h;
 00021089  00					   		db	00h;
 0002108A  00					   		db	00h;
 0002108B  00					   		db	00h;
 0002108C  00					   		db	00h;
 0002108D  00					   		db	00h;

Guh. Granted, it works. Switching their position changes the relocations that are called, which I'll list here (these relocations are the same between the original and the hacked, with two slight differences):

000210F2						   L000210F2:
 000210F2  FF75FC						push	[ebp-04h]
 000210F5  8B353C5D0400				  mov	esi,[ntoskrnl.exe!_stricmp]
 000210FB  687A100200					push	SSZ0002107A_WINNT
*******This is how the above line looks in the hacked file*************
 000210FB  687A100200					push	L0002107A
*******End Difference One**************************************
 00021100  FFD6						  call	esi
 00021102  85C0						  test	eax,eax
 00021104  59							pop	ecx
 00021105  59							pop	ecx
 00021106  750B						  jnz	L00021113
 00021108  8B4508						mov	eax,[ebp+08h]
 0002110B  C70001000000				  mov	dword ptr [eax],00000001h
 00021111  EB39						  jmp	L0002114C

 00021113						   L00021113:
 00021113  FF75FC						push	[ebp-04h]
 00021116  6882100200					push	SSZ00021082_SERVERNT
*******This is how the above line looks in the hacked file*************
 00021116  6882100200					push	SSZ00021082_WINNT
*******End Difference Two**************************************
 0002111B  FFD6						  call	esi
 0002111D  85C0						  test	eax,eax
 0002111F  59							pop	ecx
 00021120  59							pop	ecx
 00021121  750B						  jnz	L0002112E
 00021123  8B4508						mov	eax,[ebp+08h]
 00021126  C70002000000				  mov	dword ptr [eax],00000002h
 0002112C  EB1E						  jmp	L0002114C

So, it's essentially faking it out. Swapping the relocation pointers for WINNT to assume the abilities of SERVERNT and leaving SERVERNT to do god knows what (what WINNT would do in the original, pressumably).

But what if we take a closer look at 2 lines in particular and then swap their hex code:

000210FB  687A100200					push	SSZ0002107A_WINNT
....
 00021116  6882100200					push	SSZ00021082_SERVERNT
*****swap-o-matic******
 000210FB  6882100200					push	SSZ00021082_SERVERNT
....
 00021116  687A100200					push	SSZ0002107A_WINNT

Without HEX swapping WINNT and SERVERNT at the begining of the file.

Just in case you don't want to do the mental gymnastics, here's the complete patched sequence:

0002107A						   SSZ0002107A_WINNT:
 0002107A  57494E4E5400					  db	'WINNT',0
 00021080  0000							  Align	2

 00021082						   SSZ00021082_SERVERNT:
 00021082  5345525645524E5400				db	'SERVERNT',0
 0002108B  000000							Align	2
------------
 000210F2						   L000210F2:
 000210F2  FF75FC						push	[ebp-04h]
 000210F5  8B353C5D0400				  mov	esi,[ntoskrnl.exe!_stricmp]
 000210FB  6882100200					push	SSZ00021082_SERVERNT
 00021100  FFD6						  call	esi
 00021102  85C0						  test	eax,eax
 00021104  59							pop	ecx
 00021105  59							pop	ecx
 00021106  750B						  jnz	L00021113
 00021108  8B4508						mov	eax,[ebp+08h]
 0002110B  C70001000000				  mov	dword ptr [eax],00000001h
 00021111  EB39						  jmp	L0002114C

 00021113						   L00021113:
 00021113  FF75FC						push	[ebp-04h]
 00021116  687A100200					push	SSZ0002107A_WINNT
 0002111B  FFD6						  call	esi
 0002111D  85C0						  test	eax,eax
 0002111F  59							pop	ecx
 00021120  59							pop	ecx
 00021121  750B						  jnz	L0002112E
 00021123  8B4508						mov	eax,[ebp+08h]
 00021126  C70002000000				  mov	dword ptr [eax],00000002h
 0002112C  EB1E						  jmp	L0002114C

WINNT is now pointing to (pushing, being pushed by, whatever) the section that was once labled for SERVERNT, which means it now goes through all it's subsequent routines as the spirit of the hack intended.

The same holds true of the DLL.

Original:

6CAC5D40						   SSZ6CAC5D40_LANMANNT:
 6CAC5D40  4C414E4D414E4E5400				db	'LANMANNT',0
 6CAC5D49  000000							Align	4

 6CAC5D4C						   SSZ6CAC5D4C_SERVERNT:
 6CAC5D4C  5345525645524E5400				db	'SERVERNT',0
 6CAC5D55  000000							Align	4

Hacked:

6CAC5D4C						   SSZ6CAC5D4C_WINNT:
 6CAC5D4C  57494E4E5400					  db	'WINNT',0
 6CAC5D52  00					   		db	00h;
 6CAC5D53  00					   		db	00h;
 6CAC5D54  00					   		db	00h;
 6CAC5D55  00					   		db	00h;
 6CAC5D56  00					   		db	00h;
 6CAC5D57  00					   		db	00h;

 6CAC5D58						   L6CAC5D58:
 6CAC5D58  53					   		db	53h;   'S'
 6CAC5D59  45					   		db	45h;   'E'
 6CAC5D5A  52					   		db	52h;   'R'
 6CAC5D5B  56					   		db	56h;   'V'
 6CAC5D5C  45					   		db	45h;   'E'
 6CAC5D5D  52					   		db	52h;   'R'
 6CAC5D5E  4E					   		db	4Eh;   'N'
 6CAC5D5F  54					   		db	54h;   'T'

Sure enough, same relocation swapping occuring:

6CAE415D						   L6CAE415D:
 6CAE415D  FF75FC							push	[ebp-04h]
 6CAE4160  8B35B811AC6C					  mov	esi,[msvcrt.dll!_stricmp]
 6CAE4166  68585DAC6C						push	SSZ6CAC5D58_WINNT
*******This is how the above line looks in the hacked file*************
 6CAE4166  68585DAC6C						push	L6CAC5D58
*******End Difference One**************************************
 6CAE416B  FFD6							  call	esi
 6CAE416D  85C0							  test	eax,eax
 6CAE416F  59								pop	ecx
 6CAE4170  59								pop	ecx
 6CAE4171  750B							  jnz	L6CAE417E
 6CAE4173  8B4508							mov	eax,[ebp+08h]
 6CAE4176  C70001000000					  mov	dword ptr [eax],00000001h
 6CAE417C  EB39							  jmp	L6CAE41B7

 6CAE417E						   L6CAE417E:
 6CAE417E  FF75FC							push	[ebp-04h]
 6CAE4181  684C5DAC6C						push	SSZ6CAC5D4C_SERVERNT
*******This is how the above line looks in the hacked file*************
 6CAE4181  684C5DAC6C						push	SSZ6CAC5D4C_WINNT
*******End Difference Two**************************************
 6CAE4186  FFD6							  call	esi
 6CAE4188  85C0							  test	eax,eax
 6CAE418A  59								pop	ecx
 6CAE418B  59								pop	ecx
 6CAE418C  750B							  jnz	L6CAE4199
 6CAE418E  8B4508							mov	eax,[ebp+08h]
 6CAE4191  C70002000000					  mov	dword ptr [eax],00000002h
 6CAE4197  EB1E							  jmp	L6CAE41B7

We do the same swap-o-matic:

6CAE4166  68585DAC6C			push	SSZ6CAC5D58_WINNT
....
 6CAE4181  684C5DAC6C			push	SSZ6CAC5D4C_SERVERNT
*****swap-o-matic******
 6CAE4166  684C5DAC6C			push	SSZ6CAC5D4C_SERVERNT
....
 6CAE4181  68585DAC6C			push	SSZ6CAC5D58_WINNT

and we get this:

6CAC5D4C						   SSZ6CAC5D4C_SERVERNT:
 6CAC5D4C  5345525645524E5400				db	'SERVERNT',0
 6CAC5D55  000000							Align	4

 6CAC5D58						   SSZ6CAC5D58_WINNT:
 6CAC5D58  57494E4E5400					  db	'WINNT',0
 6CAC5D5E  0000							  Align	4
...............
 6CAE415D						   L6CAE415D:
 6CAE415D  FF75FC							push	[ebp-04h]
 6CAE4160  8B35B811AC6C					  mov	esi,[msvcrt.dll!_stricmp]
 6CAE4166  684C5DAC6C						push	SSZ6CAC5D4C_SERVERNT
 6CAE416B  FFD6							  call	esi
 6CAE416D  85C0							  test	eax,eax
 6CAE416F  59								pop	ecx
 6CAE4170  59								pop	ecx
 6CAE4171  750B							  jnz	L6CAE417E
 6CAE4173  8B4508							mov	eax,[ebp+08h]
 6CAE4176  C70001000000					  mov	dword ptr [eax],00000001h
 6CAE417C  EB39							  jmp	L6CAE41B7

 6CAE417E						   L6CAE417E:
 6CAE417E  FF75FC							push	[ebp-04h]
 6CAE4181  68585DAC6C						push	SSZ6CAC5D58_WINNT
 6CAE4186  FFD6							  call	esi
 6CAE4188  85C0							  test	eax,eax
 6CAE418A  59								pop	ecx
 6CAE418B  59								pop	ecx
 6CAE418C  750B							  jnz	L6CAE4199
 6CAE418E  8B4508							mov	eax,[ebp+08h]
 6CAE4191  C70002000000					  mov	dword ptr [eax],00000002h
 6CAE4197  EB1E							  jmp	L6CAE41B7

Sadly, not much can be done about the EXE. No matter what, it's going to do this:

01002830							   SSZ01002830_winnt:
 01002830  77696E6E7400						  db	'winnt',0
 01002836  00						   		db	00h;
 01002837  00						   		db	00h;
 01002838  00						   		db	00h;
 01002839  00						   		db	00h;
 0100283A  00						   		db	00h;
 0100283B  00						   		db	00h;

So, the question is this: Is it the order that they're referenced to or listed in? DMADMIN.EXE has (prior to editing it) nothing related to WINNT, only SERVERNT and LANMANNT. Obviously, just changing the EXE alone wouldn't work, pressumably because of what the relocation pointers in the SYS and DLL do when calling WINNT, they don't accomplish the desired result. (and obviously, as WINNT isn't being called by the EXE, the WINNT sections won't work right leaving the EXE to call to them under the guise of SERVERNT).

Can switching the PUSH's so that calls to WINNT now execute what SERVERNT was responsible for be enough? (for the astute observers: the DLL and SYS list each of the three initially in reverse order of each other. SYS lists WINNT, SERVERNT, LANMANNT; DLL lists LANMANNT, SERVERNT, WINNT. For whatever that's worth.)

If anyone has the capability and willingness to test differently modified files, PM me or respond here, as I'd really like to find out if these changes to the SYS and DLL (with the original change to the EXE of course) are enough, but lack the resources/equipment to do so. (I can verify that the modified files DO work as normal under a regular XP Pro install and do not introduce any problems). Even better if you can tell me if it won't work and can explain (prove-ably) why the method currently in use is the only operable one.

(A note: The original "Hack" doesn't modify the PE Checksum of either the SYS or DLL, only the EXE. The method used here changes the PE Checksum of all three, so if you use this information to change your own files, don't forget to update those.)

*edit: realized I confused the examples and posted code from the SYS into the sections for the DLL. Corrected.*

Cab'd files for I386 Use. No nLite or Integrator INI yet.

https://www.sharemation.com/Aeenzawthi/NEW_...CAB?uniq=40a2tk

Edited May 26, 2006 by Zacam

[LLXX]

What about just changing the conditional jumps at 21106 and 21121?

[Zacam]

What about just changing the conditional jumps at 21106 and 21121?

What about them? The purpose that I can divine that the hack was aiming for was to have WINNT take SERVERNT's place. Simply changing the conditional jumps still means (even if the exe is changed) that WINNT is still doing WINNT's processes, not SERVERNT's.

And if we change the conditional's, why not the actuals as well?

DMBOOT.SYS
 00021111  EB39					  jmp	L0002114C
 0002112C  EB1E					 jmp	L0002114C

DMCONFIG.DLL
 6CAE417C  EB39					 jmp	L6CAE41B7
 6CAE4197  EB1E					  jmp	L6CAE41B7

Besides, the conditional at 21106 points us to load 21113. Reversing that means instead of skipping what WAS winnt means we'll now load right to it next, possibly breaking the intention of bypassing it altogether.

In case anyone misses the edit I made, I realized that I accidentally posted the same information in the section for the DLL from the SYS instead of the actual DLL information. That's been corrected, and I've also linked to a cabbed collection of the newly modified files. No nLite or RVM Integrator INI just yet, as I need proof other than my machines that this works. And since I don't have enough HDD's to pull off testing here, I need someone else to.

Edited May 26, 2006 by Zacam

[allen2]

Did you tried to modify this reg entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions
ProductType=WinNT

[Zacam]

Modify it to......ServerNT? It already exists as WinNT. So if it's as simple as changing the reg key, why are there hacked files at all?

In either case, I still don't have enough HDD's or ability to connect the to test for RAID5 Software solution.

[TalAloni]

Sorry for being late to the party,

The OP is right to suggest that the THG's fix should have been cleaner.

take dmio.sys for example:

in the original file:

ProductType is first checked against 'WINNT', if equal, the value 1 is stored for later use. and if not, it is checked against 'SERVERNT', if it is equal, the value 2 is stored for later use.

Note: For the fix to work, we want the value of 2 to be stored for later use.

After the suggested THG change:

ProductType is first checked against 'SERVERNTWINNT' (because we removed the null terminator), if equal, the value 1 is stored for later use. and if not, it is checked against 'WINNT', if it is equal, the value 2 is stored for later use.

This works well of course (because our ProductType is 'WINNT', but we could achieve the same result by changing a single byte (storing the value 2 for later use for 'WINNT'), and updating the checksum.

For the files with the cleaner approach, visit here:

http://iknowu.dnsalias.com/files/public/Windows-RAID/KB827913-WindowsXP.htm

[submix8c]

Reference -

http://www.tomshardware.com/reviews/windowsxp-make-raid-5-happen,925.html

FYI -

http://integrator.siginetsoftware.com/index.php?addons&id=79