Zacam

VLite and nLite make "educated" guesses about the installation media presented to them. They do not reverse or decouple anything information wise. That however is NOT the illegal conversation Kel is referring to. "So yes occasionally i do go out on the internet and try to find the windows OEM source files for a dell or whatever the brand. I am sure you all know that anytime you take this route you really have no idea what you are getting, whether it is OEM, REtail, Dell, Toshiba, 64bit x86 ect... " That is. Such discussion CANNOT be carried anywhere here. And based on the statement of the request, even if what you wanted was possible, nobody here would provide it.

Well, I do feel sheepish for not having considered that solution. I was attempting to make it easier to (if necessary) perform manual re-installs of components, without having to extract an entire motherboard set, but I will see how well this idea tests out. Thanks for the feedback and the suggestion, I'll let you know how it goes. **Edit So, it has gone well. Though, setting some sort of an instruction delay, (if you have it set to delete copied drivers) before it actually restarts the system would be nice, or did I miss something in the documentation?

Ability to scan in parent dir sub folders for compressed drivers in said sub folders.

I notice when set to use compressed, it does not sub-dir scan past provided dir for .7z (or .rar) files. How possible will it be to implement doing detect for more dirs in defined primary dir to scan them for .7z and .rar? I need to use compressed drivers, but would like to sub folder them based on name of motherboard.

So, in an effort to decrease file copy times during pre-setup, I alpahbetized the [Files] section in DOSNET.INF according to a DOS level dir command. It worked beautifully. I'm curious though if I need to retain the [FloppyFiles.#] sections or if they can be deleted as their entries also exist in [Files] section, or if they can be merged into a single [FloppyFiles] section if the windows setup is still utilizing them, even though the install is not occuring from floppy. (What are those things, anyway? j/k :-D )

Well, fortunatly I've kept all my SP2 patched files even after I converted the addons to use the Integrators [HexEdit] function. But since nLite does not have this feature, (and for informational completness) I'm sharing the various versions of the files that have been listed here. Every file was personally modified by hand using mirkes.de Tiny Hexer with offset verification done using HeavenTools PE Explorer and tested on live installs. They have been cab compressed with PECheckSum correction for inclusion into the \I386 dir. Multiple versions exist, so be sure to pick the appropriate version number. I'll be updating this frequently and will continue to maintain it concurrently with my RVM Addons (which can be found [url="http://www.ryanvm.net/forum/viewtopic.php?t=2274"]HERE[/url].). [b]SFC_OS.dll[/b]: 5.1.2600.2180: [url="http://zacam.ueuo.com/rvmprojects/dlls/SFC_OS_5-1-2600-2180.cab"](Right-Click, "Save As")[/url] [b]Syssetup.dll 5.1.2600.2180[/b]: Disable Syssetup.INF Signature Checking: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2180_INF.cab"](Right-Click, "Save As")[/url] Disable INF Checking & OOBE: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2180_INF_OOBE.cab"]: (Right-Click, "Save As")[/url] Disable OOBE[url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2180_OOBE.cab"](Right-Click, "Save As")[/url] [b]Syssetup.dll 5.1.2600.2689[/b]: **For those with [url="http://support.microsoft.com/kb/894871"]KB894871[/url] installed. Disable Syssetup.INF Signature Checking: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2689_INF.cab"](Right-Click, "Save As")[/url] Disable INF Checking & OOBE: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2689_INF_OOBE.cab"](Right-Click, "Save As")[/url] Disable OOBE: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2689_OOBE.cab"](Right-Click, "Save As")[/url] [b]TCPIP.sys for 100 concurrent connections[/b]: **I need to add more versions and more options per ver. 5.1.2600.2827[url="http://zacam.ueuo.com/rvmprojects/dlls/TCP_5-1-2600-2827.cab"](Right-Click, "Save As")[/url] [b]USBPort.sys for 500mhz Port Polling[/b]: [color="red"]**Not for Use with Wireless Mice!![/color] 5.1.2600.2180: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2180.cab"](Right-Click, "Save As")[/url] 5.1.2600.2730: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2730.cab"](Right-Click, "Save As")[/url] 5.1.2600.2783: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2783.cab"](Right-Click, "Save As")[/url] 5.1.2600.2846: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2846.cab"](Right-Click, "Save As")[/url] 5.1.2600.2891: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2891.cab"](Right-Click, "Save As")[/url] [b]UXTheme.dll for Unsigned Theme Usage[/b]: 6.0.2900.2180: [url="http://zacam.ueuo.com/rvmprojects/dlls/UXTHEME_6-0-2900-2180.cab"](Right-Click, "Save As")[/url] 6.0.2900.2523: [url="http://zacam.ueuo.com/rvmprojects/dlls/UXTHEME_6-0-2900-2523.cab"](Right-Click, "Save As")[/url] 6.0.2900.2845: [url="http://zacam.ueuo.com/rvmprojects/dlls/UXTHEME_6-0-2900-2845.cab"](Right-Click, "Save As")[/url] Hope people find this useful.

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.

albie_3177: check the message I posted here, that may help you. Also, I noticed that if you have a SATA and an IDE HDD in place when installing, even if your installing to the SATA, my motherbard atleast ends up installing to the SATA as D: and the boot files go to C: (the IDE drive). The only workaround I have for this at the moment is to disconnect the IDE HDD's before I install so that the SATA is set to C:. (And yes, my BIOS is set to SCSI first, CD-ROM second and nothing for third and fourth boot devices, boot other is disabled.)

You may need to change the HardwareIdsDatabase to reflect the actual PCI\VEN\SUBSYS of your particular SATA controller, but I use these setting in my TXTSETUP.SIF for my ECS KT-600a: [SourceDisksFiles] viamraid.sys = 1,,,,,,4_,4,1,,,1,4 [HardwareIdsDatabase] PCI\VEN_1106&DEV_3149 = "viamraid" [SCSI.load] viamraid = viamraid.sys,4 [SCSI] viamraid = "VIA SATA RAID Controller" Naturally, don't forget to compress a copy of viamraid.sys and place it in your \I386 directory. The viamraid.sys file I use is actually the one from Bashrat's Mass Storage pack, not the one from the ECS download page for my motherboard. HTH.

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.

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

That's the part that is likely to kill you. Or at the least, make you loose a lot of hair. It is possible to add drivers to the cd for installation during GUI Mode Setup, either by copying to the hard disk first or directly from the CD. Controlling how windows does it's handling for driver locations though to modify it's behavior is another matter entirely. You _could_ combine a method for inserting a disk swap phase during GUI Mode and build a second cd specifically for drivers, but there is no telling how well that would work.

Try placing the following directly into your TXTSETUP.SIF file: [SourceDisksFiles] iaStor.sys = 1,,,,,,4_,4,1,,,1,4 [HardwareIdsDatabase] PCI\VEN_8086&DEV_27C3&CC_0104 = iaStor_ICH7DH PCI\VEN_8086&DEV_27C1&CC_0106 = iaAHCI_ICH7R [scsi] iaStor_ICH7DH = "Intel® 82801GR/GH SATA RAID Controller (Desktop ICH7R/DH)" iaAHCI_ICH7R = "Intel® 82801GR/GH SATA AHCI Controller (Desktop ICH7R/DH)" [SCSI.load] iaStor_ICH7DH = iaStor.sys,4 Compress iaStor.sys into iaStor.sy_ and place in the \I386 folder. Then do the Drivers from CD method and copy into a SATA folder the following: iaStor.sys, iaStor.inf, iaStor.cat, iaAHCI.inf, iaAHCI.cat. If you preffer not installing drivers from cd, the above could be added to TXTSETUP.SIF as well, but it's more complicated in deconstrucing the INF's for the relevant information to force the installation. For further help on problems like these, a url link to where your drivers are obtainable from would be helpful.

Naturally, extract your downloaded drivers, but delete the txtsetup.oem file. Then, place the following code into TXTSETUP.SIF for step 1: [SourceDisksFiles] <--Already Exists, so just append or sort in. nvatabus.sys = 1,,,,,,4_,4,1,,,1,4 nvraid.sys = 1,,,,,,4_,4,1,,,1,4 [HardwareIdsDatabase] <-This already exists, so just append or sort in. GenNvRaidDisk = "NVRAID" *_NVRAIDBUS = "NVRAIDBUS" PCI\VEN_10DE&DEV_00EE = "CK8SSS" PCI\VEN_10DE&DEV_00E3 = "CK8SSS" [SCSI.Load] <--Already Exists, so just append or sort in. CK8SSS = nvatabus.sys,4 NVRAIDBUS = nvraid.sys,4 [SCSI] <--Already Exists, so just append or sort in. CK8SSS = "NVIDIA nForce3 250 Serial ATA Controller" NVRAID = "NVIDIA nForce(tm) RAID Class Device" NVRAIDBUS = "NVIDIA nForce(tm) RAID Class Controller" (NOTE: These are strings only for nForce3 items. All other references to other nForce material as available from INF's not included as 1: Far too confusing with item_name re-usage and 2: I don't have a either a whole lot of time right now OR an nForce motherboard.) I'd then suggest doing the drivers from cd method. Don't forget to skip to Step 4 and compress nvraid.sys -> nvraid.sy_ and nvatabus.sys -> nvatabus.sy_ and place them in "%CDSOURCE%\I386". And if all else fails, go to the DriverPacks thread where you can gather more assistance, even if you are not using a driver pack per se, you are doing something involving slipstreaming a vendor driver into your install media. Though, if you do decide to do a driver pack, I updated my ECS KT600-A drivers by extracting the ones from Bashrats MassStoragePack 6.03.1. More current for the VIA, though I'm reading there now that there are some nForce issues, you might be able to get away with using the files from the MassStoragePack (copy them from the extracted source "D\M\N\123\" instead of using the downloaded MSI zip file contents).

FYI in the Audioshell Addon, the AudioShe.inf is MISSING a ; at the begining of the first line. If you place a " ; " there, framedyn.dll and srclient.dll errors should disappear on systems where you are installing Audioshell Addon. I just did a test where I ran Integrator 1.2.2, RVM 2.03, 2.04 and 2.05 and ONLY added Audioshell. That was it, nothing else. I didn't even make it unattended to simplify things. Received framedyn.dll and srclient.dll errors. I then corrected the INF after discovering the issue and burned a new ISO with the corrected file, and obtained a perfect install.