Traditionally on NT systems the SCSI driver for an actual SCSI card was copied "verbatim" in the Root directory of the boot drive (together with NTLDR, NTDETECT.COM and BOOT.INI) and renamed to "NTBOOTDD.SYS".
If the BOOT.INI has INSTEAD of the nowadays common "multi(0)" entries a "scsi(0)" entry, it will use the NTBOOTDD.SYS to "hook" the SCSI drive(s) at boot time.
In the problem that Vortex reported whereby Windows Server 2003 was working with neither Firadisk nor WinVBlock, it turned out that GRUB4DOS doesn't protect its INTerrupt 0x13 hook, so it gets obliterated at random by Windows processes during boot, depending on whether its memory happens to be overwritten or not. Without the INT 0x13 hook, the two aforementioned drivers cannot find the GRUB4DOS virtual disks without some new mechanism. Every time a new mechanism is introduced, things will get uglier, in my opinion. Some future version of this NTBOOTDD.SYS could find MEMDISK and GRUB4DOS parameters very early and then pass them on.
Additionally, NTBOOTDD.SYS has access to disks using INT 0x13, so it can scan disks and pass on information concerning which BIOS drive numbers (pre-kernel) correspond to which Windows disks (post-kernel). We want to know this so that we know which backing disks that G4D sector-mapped disks map to.
Another goal for a future version of this NTBOOTDD.SYS would be Microsoft .VHD support for all three VHD types: Fixed, dynamically expanding, differencing. There are still tons of XP computers out there in the world, and it might be nice to boot them from VHDs.
Respects: Sha0, Karyonix, Wonko and.... all that've missed.
Even if it works and we can pass very nice information to WinVBlock or FiRaDisk, where should we pass this information? karyonix: Have you any thoughts? I'd thought about abusing the INT 0x13 vector and throwing an address in there, but that seems very ugly.
I haven't verified for absolute certain, but I believe that NTLDR only allows one file to be open at a time. What this means is that the version attached to the first post has to save NTLDR's file "table" (table of one?!), then open the HDD image file and work with it, then close it, then restore the file "table" so that whatever file NTLDR was working with is back the way it was. NTLDR loads the SYSTEM hive, HAL, kernel, drivers, fonts, etc. This save-and-restore process is very slow!
#2: Wrong! Hurray! I've improved the performance piece and NTLDR does allow for multiple files to be open. The speed is quite acceptable now.
But for #1, I'm still open to ideas. This NTBOOTDD.SYS has to pass information to the better driver, so where's a good place to pass the information? In fact, for a 32-bit system, just passing a single, 4-byte pointer would be sufficient. But where should we put it and where should the better driver look for it?
I won't bother posting a new version until this does something useful, but that depends on figuring out #1... Attached the improved-performance version to the first post in this thread. It has pretty limited use right now... It'll load Windows, but unless a driver provides a boot disk of some sort, you'll get a STOP 0x7B.
NTLDR somehow passes information to kernel.
Is it possible to attach your data to (1) or (2) ?
I don't know data structure used by NTLDR and don't want to study it. I cannot help much.
OEM field of bootsector, if Win9x/Me can ruin any otherwise good floppy and NT does the "cmdcons" trick, why we can't write a value there?
have you tried with 2003 (as opposed to XP)?
(1) Is a brilliant idea. The kernel will write all parameters starting with a / to the registry. So the second stage driver could simply read the values from registry.
Hmmm... Well the version attached to this post has some minor fun with BOOT.INI. It will look for a [wvbootdd] section in BOOT.INI and it will simply display the section. Just for fun.
Perhaps there's a way to append to the already-chosen OS load options. I don't know where they are, though.
Sure. But right now I don't even know of a hack to do which wouldn't be most disagreeable.
A 32-bit pointer will fit, but a 64-bit pointer won't fit.
Post-kernel, when we want to find the image file (file-backed) or contiguous sector range (sector-mapped), we cannot access the MBR because we do not yet have the disk; we are trying to provide it.
BOOT.INI isn't available (that I know of) post-kernel, either.
Hmmm... It's possible that 0000:7C00 might still be intact, post-kernel. El Torito would be out of luck.
Well, as mentioned, they don't even call NTDETECT.COM, so who knows?
Anyway, attached to this post is a newer version. This one has been pre-patched for the English Windows XP Professional Service Pack 3 NTLDR with MD5 hash C1B29B4E6EEA9510610DB2EC4D6DB160. I am trying to provide a variety.
This version displays any [wvbootdd] section (case-sensitive, please) in BOOT.INI, as well as introduces a dumb "command prompt." The only command available right now is exit, which will continue the boot process. You will still STOP 0x7B unless another driver provides your file-backed disk (hint: Firadisk).
Enjoy. And if you have a different NTLDR version that you'd like to test with, please let me know!
Experimental NTBOOTDD.SYS by Shao Miller, 2011.
D exit WvbOpenWinHdd(): WIN.HDD MBR loaded.
Attached version was downloaded 19 times. See original post for most recent version.
I have updated the original post with a new version: 0.0.1.9-DEV. I also have a request for your assistance in that post, if you'd be so kind.
1 Y ?? ??? ???? Found: 7B6D8AB599A57B4784A34D873C4A87D0 xxxxxx ?
2 N ?? ??? ???? Found: B840C1B30F4A6841A5B71FFE37C7F0E4 xxxxxx ?
3 Y ?? ??? ???? Found: 70DDF0681786294FB31E7B4B32BDAFDE xxxxxx ?
4 Y ?? ??? ???? Found: 4AFA75F6972FAD4C9350A7AC33EE33F4 xxxxxx ?
Don't forget to thank the developers of the board software for having completely failed to have CODE tags working, thus needing padding characters as SPACEs or TABs are not anymore left "as they are" inside CODE tags.
This is too much information for me to ask people for. All I care about is the Found: result. Nevertheless, I've updated the original post according to your suggestion.
Thanks! Bad news: It can't be supported. Maybe you have another service pack version hidden somewhere? Maybe in WindowsDriver Cachei386*.cab ?
I can find the green one searching with an hex editor, (and it is the same 5.1.2600.2180 for my file) but cannot find the red one.
In any case, as I see it, the only use of a "localized" NTLDR is that when it crashes/produces an error the error message will be in your language of choice, otherwise it is a pretty much "silent" piece of code, so I guess everyone could download the English SP2 or SP3 and replace their own "localized" NTLDR.
If Microsoft's Sysinternals' strings doesn't show it up, then it's not in your file. You can extract OsLoader.exe from NTLdr by searching for the MZ signature, then copying from the MZ (including it) to the end of the file. You can then examine the OsLoader.exe details with Explorer.
Is there really a mystery? One of your links explains to use it to initiate removal of Windows XP. Yes, it patches the boot-sector, as far as I can see, with the string undo. If SetupLdr is invoked (probably by that boot-sector), it will notice this and remove XP, as far as I can tell.
I'm not sure why your version isn't possible to support. Maybe you could EXPAND your installation media's i386OsLoader.ex_ and run WNtldr.exe on it? I might expect it to yield the same result, but maybe not!
Cool! Meanwhile I will try to make WvBootDD a bit more useful, though it does currently load Windows from a flat file called WIN.HDD in whatever directory had NTLdr, and so is useful for the "XP Kansas City Shuffle."
Yes, you can use httpdisk with that .ISO, then extract OSLoader.PDB.Exe from the disc's SupportSymbolsSymbols.Cab. Such a module can be loaded with Debugging Tools for Windows' DBH command, to be inspected for the special PdbSig70 value. The one you've referenced is already supported.
Using 7-Zip on the service pack executable requires decompressing all the files that come before OSLoader.Exe, unfortunately.
I am sorry, I dont get it.
All I care about is a particular signature. Since NTLdr contains OsLoader.Exe and the OsLoader .PDB was available outside of the service pack executable, but inside the symbols .CAB, it is certainly more easily accessible. So if you happen across any more of these downloads, please do let me know, so I can collect more signatures.
It's too bad NTLdr isn't named AALdr, as the service pack executable appears to have the files compressed alphabetically.
I believe that you were actually discussing how anyone else could obtain an NTLdr that's supported by WvBootDD. I just so happened to try it out and noticed it was a possible method for me to collect the signatures.
I did more WvBootDD development yesterday and earlier today. Then I started experimenting with using it over the network. Perhaps interestingly, anyone with a legitimate copy of Windows XP or Windows Server 2003 that has a supported NTLdr should be able to do some interesting stuff.
Then you could invoke WvBootDD without installing it to a hard disk drive, but it could access an NTFS volume on a hard disk drive.
My memory is getting worse and worse.
I seemed to remember that there was a "small" downloadable update (post SP2 and pre SP3) containing NTLDR, but I seem like not finding it anymore.
Note: these are the English versions, there are several langiages available.
Fortunately, you probably have the information that I need for WvBootDD inside your installation media's SupportSymbolsSymbols.Cab file. It's just not as easy to get at as simply running WNtldr.Exe would have been.
Also, someone might have a collection of lots of these symbols files.
To the Microsoft decision-maker(s) responsible for removing the OsLoader symbols: Please put them back. Thank you.
Because the PDB files for osloader.exe seems to be disappeared from Microsoft's website, I wrote a magic file for binwalk to find the offsets of the function and the RVA of the objects in osloader.exe that WvBootDD wants to call.
For the objects the RVA is always displayed correctly (0x4.....), don't use the offset to calculate the RVA (for the objects the displayed file offset is not related to the location of the object in the file).
# osloader.exe so they can be used by WvBootDD.
# Find the start of the code in the osloader.exe file.
# Find offsets of functions and RVA's of objects.
Version 0.0.1.9 released. This one has a cat command for displaying files. Pretty fun!