• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
Sign in to follow this  
Followers 0
Zacam

Question about Software RAID5 "Patch"

7 posts in this topic

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 by Zacam
0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites
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 by Zacam
0

Share this post


Link to post
Share on other sites

Did you tried to modify this reg entry:

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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.