Boot virus on xp

[Robert Green]

[snip]

This long thread has left me puzzled. If NT-based versions of Windows
don't allow any low-level access to floppies, how does a Windows NT/2K/XP
user format a floppy disk for use?

I think that it is only application level software that is denied low-level
access, and I'm not too sure what the OS replaces the BIOS routines
with. Witty apparently found a way to circumvent the barrier between
application and system software, as yet I haven't seen it explained.

This should help clarify the matter:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp

<QUOTE>

Physical Disks and Volumes

You can use the CreateFile function to open a physical disk drive or a
volume. The function returns a handle that can be used with the
DeviceIoControl function. This enables you to access the disk's
partition table. It is potentially dangerous to do so, since an
incorrect write to a disk could make its contents inaccessible. The
following requirements must be met for such a call to succeed:

The caller must have administrative privileges. For more information,
see Running with Special Privileges.
The dwCreationDisposition parameter must have the OPEN_EXISTING flag.
When opening a volume or floppy disk, the dwShareMode parameter must
have the FILE_SHARE_WRITE flag.
When opening a physical drive, x, the lpFileName string should be of
the form \\.\PHYSICALDRIVE<x>. Hard disk numbers start at zero. The
following table shows some example physical drive strings.

String Meaning
\\.\PHYSICALDRIVE0 Opens the first physical drive.
\\.\PHYSICALDRIVE2 Opens the third physical drive.

For an example showing how to open a physical drive, see Calling
DeviceIoControl.

When opening a volume or floppy drive, the lpFileName string should be
of the form \\.\<x>:. Do not use a trailing backslash. This would
indicate the root directory of the drive. The following table shows
some example drive strings.

String Meaning
\\.\A: Opens drive A (floppy drive).
\\.\C: Opens drive C (volume).

You can also open a volume by referring to its volume name. For more
information, see Naming a Volume.

</QUOTE>

Bob

 

[cquirke (MVP Win9x)]

On Sat, 12 Jun 2004 18:57:27 -0300, "Norman L. DeForest"

This long thread has left me puzzled. If NT-based versions of Windows
don't allow any low-level access to floppies, how does a Windows NT/2K/XP
user format a floppy disk for use?

The small print is that NT doesn't allow normal applications to
perform low-level disk access - but device drivers, system tools such
as the formatter, and other apps running in Ring 0 still have full
access. I guess that's how Witty gets to splat raw disk writes
through all the nominal NTFS security, as it's acting as the hand
using Black Ice Defender as glove puppet.

-------------------- ----- ---- --- -- - - - -

Trsut me, I won't make a mistake!

 

[Norman L. DeForest]

Formatting floppies under NT uses the Windows own functions that replace the
BIOS interrupt 13h services.

Int 13h calls are denied under NT-based OS only if the destination drive is a
fixed one (i.e. hard drive). Floppies are served.

Regards, Zvi

Thanks! That clears up *one* thing for me. I got the impression from the
discussion here that *all* low-level access to *all* drives was blocked on
NT systems.

However, doesn't that enable multipartite infectors (combination boot
*and* file infectors) to spread to floppy boot sectors from NT systems?
Other discussion here implied that it wasn't possible.

 

[FromTheRafters]

However, doesn't that enable multipartite infectors (combination boot
*and* file infectors) to spread to floppy boot sectors from NT systems?
Other discussion here implied that it wasn't possible.

I'm pretty sure that this discussion was excluding multipartite viruses.

....but it has been so long....I don't remember...

I think that the multipartite's boot vector would at best only cause the
boot sector to be corrupted if booting to NT based OSes. The file
infector would have the only viable vector.

 

[Zvi Netiv]

Thanks! That clears up *one* thing for me. I got the impression from the
discussion here that *all* low-level access to *all* drives was blocked on
NT systems.

Note: Read "NT-based operating systems" anywhere I refer to NT, plain, below.

NT doesn't allow low-level disk access. What you perceive as such are actually
Windows services that replace the BIOS and DOS interrupts by NT's own functions.
Even where NT virtually allows direct disk access, these services aren't a full
substitute for the original Int 13h. For example, Int 13 allows both the
creation and access to and from non-standard tracks on floppies (like higher
than track 80 for 1.44 floppies, or sectors with numbers beyond 18, for same
size floppies). Requests to access sectors outside the range of the standard
format aren't supported under Windows disk access, actually since Win 95.

That fact may have been noticed by users that had protected software which
required the presence of a "key floppy" in the drive, to authenticate that the
software wasn't pirated. These copy protection were based on the creation and
reading from special and non-standard tracks on the "key" floppy. The
introduction of Windows 95 killed the production of these protection schemes as
Win32 couldn't read the special tracks.

For how this is relevant to multipartites, see below.

However, doesn't that enable multipartite infectors (combination boot
*and* file infectors) to spread to floppy boot sectors from NT systems?
Other discussion here implied that it wasn't possible.

Your last question suggests a common misconception about multipartite infectors.
Contrarily to common knowledge, multipartite do not exchange virus code from
floppy to hard drive boot areas, and back. Except Junkie (I was the first to
analyze it, see
http://groups.google.com/[email protected]
) and Natas, multipartite do not affect the boot area of floppies, only that of
the hard drive (and files, of course).

The multipartite infection mechanism is this: When an infected file is opened,
the virus code copies itself into an overlay on the hard drive, usually to
unused sectors on track 0. The MBR loader is also modified so that the virus
overlay will run the next time the PC is booted. On next boot, the virus goes
resident on reading the overlay under control of the BIOS and the MBR, waits for
the OS to load, and infects additional files by intermediary of the OS services.
The OS is essential to multipartite's file infection, these will not occur
autonomously during boot time, when only BIOS services exist. Basically,
multipartite are *file infectors*, and their boot phase serves just as an
alternate channel to assist propagation.

As you can see, NT poses several obstacles on the way of multipartite: First
and foremost, reverse infection from the hard drive boot areas/overlay to floppy
boot area doesn't occur during the boot stage, not in existing boot infectors.
nor multipartite. For a multipartite to infect the boot sector of a floppy, the
resident code of the virus overlay must survive the transition from the BIOS
controlled phase and the loading of the OS. This doesn't happen as NT purges
memory before loading.

Lastly, even if a multipartite like Natas managed to load under NT, (no chance,
but suppose it did, just for the sake of the discussion) then it would fail
infecting the boot sector of floppies as Windows will not let it create the
non-standard track required on the floppy for the huge overlay that Natas uses.
An overlay of sufficient size is essential to multipartite (the Natas overlay
occupies 4096 bytes, which are eight sectors. One_Half, another multipartite
that was once common, occupies even more!). The latter is one of the reason why
Natas became extinct when Windows 95 appeared.

Regards, Zvi

 

[Zvi Netiv]

On Sat, 12 Jun 2004 18:57:27 -0300, "Norman L. DeForest"


The small print is that NT doesn't allow normal applications to
perform low-level disk access - but device drivers, system tools such
as the formatter, and other apps running in Ring 0 still have full
access.

Actually, NT-based OS disallow direct drive access only to hard drives, floppies
are served under NT even by plain 16 bit applications such as FORMAT.COM!

To prove how wrong your above statement is, here is a simple demonstration that
everyone can repeat, and learn from on the internals of Win 9x and NT-based OS.

With XP/W2K running, insert a formatted floppy into drive A:, open the CMD
shell, and issue the DEBUG command (DEBUG is a DOS command, implemented by a 16
bit application program, just as FORMAT). At the debug prompt (a dash) issue
the command L100 0 0 1 (load to memory offset 100 the first sector read from
logical drive A. Follow with the D command (dump), repeat four times, and you
get the entire content of the boot sector read from A:.

The screen dump below is the boot sector of a floppy that was formatted under XP
by aid of the FORMAT command, issued in the command shell. To exit DEBUG simply
issue the Q command (quit). Here is how the sequence looks on the display:

C:\>debug
-l100 0 0 1
-d
1900:0100 EB 3C 90 4D 53 44 4F 53-35 2E 30 00 02 01 01 00 .<.MSDOS5.0.....
1900:0110 02 E0 00 40 0B F0 09 00-12 00 02 00 00 00 00 00 ...@............
1900:0120 00 00 00 00 00 00 29 7E-A3 DC C8 4E 4F 20 4E 41 ......)~...NO NA
1900:0130 4D 45 20 20 20 20 46 41-54 31 32 20 20 20 33 C9 ME FAT12 3.
1900:0140 8E D1 BC F0 7B 8E D9 B8-00 20 8E C0 FC BD 00 7C ....{.... .....|
1900:0150 38 4E 24 7D 24 8B C1 99-E8 3C 01 72 1C 83 EB 3A 8N$}$....<.r...:
1900:0160 66 A1 1C 7C 26 66 3B 07-26 8A 57 FC 75 06 80 CA f..|&f;.&.W.u...
1900:0170 02 88 56 02 80 C3 10 73-EB 33 C9 8A 46 10 98 F7 ..V....s.3..F...

[ middle sections snipped ]

-d
1900:0280 8B F4 8A 56 24 CD 13 61-61 72 0B 40 75 01 42 03 [email protected].
1900:0290 5E 0B 49 75 06 F8 C3 41-BB 00 00 60 66 6A 00 EB ^.Iu...A...`fj..
1900:02A0 B0 4E 54 4C 44 52 20 20-20 20 20 20 0D 0A 52 65 .NTLDR ..Re
1900:02B0 6D 6F 76 65 20 64 69 73-6B 73 20 6F 72 20 6F 74 move disks or ot
1900:02C0 68 65 72 20 6D 65 64 69-61 2E FF 0D 0A 44 69 73 her media....Dis
1900:02D0 6B 20 65 72 72 6F 72 FF-0D 0A 50 72 65 73 73 20 k error...Press
1900:02E0 61 6E 79 20 6B 65 79 20-74 6F 20 72 65 73 74 61 any key to resta
1900:02F0 72 74 0D 0A 00 00 00 00-00 00 00 AC CB D8 55 AA rt............U.
-q

Repeat now the "debug" sequence but this time try reading the boot sector of the
C: (hard) drive, by modifying the load command as follows:

C:\>debug
-l100 2 0 1

NT will warn that an application is attempting to directly access the *hard
drive*, and terminate.

Rests to prove that both DEBUG and FORMAT, from XP, are plain 16 bit
applications. Here is how:

With Windows' Find, look for FORMAT.COM and DEBUG.EXE. Check that the files
found are the correct ones by double clicking them, one after the other,
verifying that they run under XP/W2K, and don't get an "incorrect DOS version"
message. Copy both programs to a Win 98 boot floppy (I checked and made sure
that both applications run under WinDOS 98!).

Boot of the Win98 floppy into pure DOS mode (the default when booting of floppy)
and run FORMAT and DEBUG, every one on its turn, to see that they function
properly, no "ring 0" whatsoever is required. ;-) As both programs run under
plain DOS, then it's clear that they are plain 16 bit applications (advanced
users could tell by the file structure, but the suggested method is preferred as
it will convince even the laymen).

Q.E.D.

Regards, Zvi

 

[cquirke (MVP Win9x)]

On Mon, 14 Jun 2004 20:45:07 +0300, Zvi Netiv

Thanks for this post and the previous one in which you explained how
current multipartite virus operate - this is great info

Actually, NT-based OS disallow direct drive access only to hard drives, floppies
are served under NT even by plain 16 bit applications such as FORMAT.COM!

With XP/W2K running, insert a formatted floppy into drive A:, open the CMD
shell, and issue the DEBUG command. At the debug prompt (a dash) issue
the command L100 0 0 1 (load to memory offset 100 the first sector read from
logical drive A. Follow with the D command (dump), repeat four times, and you
get the entire content of the boot sector read from A:.

Repeat now the "debug" sequence but this time try reading the boot sector of the
C: (hard) drive, by modifying the load command as follows:

C:\>debug
-l100 2 0 1

NT will warn that an application is attempting to directly access the *hard
drive*, and terminate.

That shows you can read raw sectors from diskette through NT, but that
these attempts to so from HD are blocked by NT. Can you write to raw
diskette sectors through NT as well?

A modern, NT-capable bipartite would have several challenges:
- surviving from pre-OS boot into OS
- accessing raw HD from OS
- linkage between pre-OS and OS components

I don't see in-memory survival from pre-OS boot to OS; more likely
communication through the third challenge. The purpose of the pre-OS
code would be to do things that are blocked by the OS.

It could infect diskettes before the OS loads, though as you say,
there's no need to do that from pre-OS code if NT is happy to allow
malware running within NT to do raw diskette writes.

The "Ring 0 factor" may be relevant to the second challenge, i.e. how
the malware running within NT can drop boot code to run before the OS.

--------------- ----- ---- --- -- - - -

Never turn your back on an installer program

 

[Zvi Netiv]

Thanks for this post and the previous one in which you explained how
current multipartite virus operate - this is great info

Actually, the description applies to boot overlays in general, from BIOS
extenders that assist old BIOSes to access large capacity drives, through boot
managers, and drive access control (those that use a boot overlay).

That shows you can read raw sectors from diskette through NT, but that
these attempts to so from HD are blocked by NT. Can you write to raw
diskette sectors through NT as well?

Of course. A thumb rule is that where function 2 (read) of int 13h is
supported, then function 3 (write) is supported too. You could try it for
yourself with DEBUG, by issuing the following sequence:

-RCX (CX register)
CX 000 (return)
:200 (set the CX register value to write 512 bytes)
-W100 0 0 1 (write 512 bytes from memory to sector 0 of drive A

(You'll have to format the floppy after the above test as the boot sector will
contain garbage)

A modern, NT-capable bipartite would have several challenges:
- surviving from pre-OS boot into OS

This is where your "NT-capable bipartite" concept collapses. We already
established that the transition cannot be done through memory, since NT clears
memory before loading itself. The only possible way to do the transition is by
intermediary of the hard drive. In other words, through file! Theoretically
this could be done by patching one of the NT files (NTLDR is the classic
candidate for the purpose).

The only problem with that scheme is that it doesn't work. Reminds me of the
scientist that could talk to dead, through direct access to the guy's brain via
super chip. The only problem was that the dead guy didn't reply! In order to
work, your bipartite boot code should be able to manipulate a file. The problem
is that only BIOS services are available at boot time and there is no way that
you can manipulate a file on base of these, prior to loading the OS. Not to
mention that there is no file system yet, that will let find and access the
targeted file.

To let you no escape, then let me add this: Suppose that the patching of the NT
file was done after the NT-based system loaded. What would then be the point in
patching NT to load your bipartite, since the virus is already active through a
common PE infection mechanism?

Sorry, but your NT-capable boot/bipartite concept is both logically flawed, and
pointless.

[snip]

That's about as specific as I want to get in a public forum <g>

Anyway, I guess that we lost almost everyone at this point. ;-)

Regards, Zvi

 

[cquirke (MVP Win9x)]

-)

[/QUOTE]

Actually, the description applies to boot overlays in general, from BIOS
extenders that assist old BIOSes to access large capacity drives, through boot
managers, and drive access control (those that use a boot overlay).

Yep. They don't do raw writes to diskettes either

Of course. A thumb rule is that where function 2 (read) of int 13h is
supported, then function 3 (write) is supported too.

Well, MS might have been smart enough to allow 13h/02h but block
13h/03h. Hey, it *could* happen!

This is where your "NT-capable bipartite" concept collapses.

I didn't say a BSV could surmount these challenges. I just stated
what a modern, NT-capable BSV would have to do. While these are
insurmountable, I agree we won't be seeing that type of malware.

The only possible way to do the transition is by intermediary of
the hard drive. In other words, through file!

Through storage. If raw or alternate access to storage was allowed,
it wouldn't have to be file. A factor is that all the most
interesting non-HD storage that the malware might use are not
supported by BIOS, so the pre-OS code would be bulked up by the
low-level code needed to access that storage.

I can't see a reason to code up reciprocal spreading viability through
BSV, except as a PoC. What I do see is the use of pre-OS access in
order to do things the OS won't allow. So anything that allows
low-level writes to bootable devices from within the OS is a problem.

For example, a NT-hosted malware could drop a data-destructive poison
pill code on diskettes. If any of those diskettes are left in a
bootable drive at boot time, the code could destroy that PC's file
system, even though it wouldn't "infect" it in spreadable form.

Mindset: Thinking malware rather than "virus".

Theoretically this could be done by patching one of the NT files
(NTLDR is the classic candidate for the purpose).

The BSV phase would have to know what raw sectors to write to, in
order to throw forward a file that could run within the OS.

Anything that allows...
- raw sector address of files to be determined
- writes to storage that can be read from the BSV phase
....would facilitate that platform shifting traffic.

For example, the NT phase of a malware could create an arbitrary file,
note the raw location of its content, and write that address into
storage somewhere. The BSV phase could get that address from storage
and then do raw writes to populate the file.

I can't think of a reason to do this; I'm just contemplating the
mechanics. The significance is that there's a safety/risk implication
to any function that allows raw sector address of files to be
determined, or that allows writes to BSV-accessible storage.

..your NT-capable boot/bipartite concept is both logically flawed, and pointless.

I wasn't claiming pointedness; just describing the challenges
involved. If these challenges are currently impossible to overcome,
then that's all well and good - but one (e.g. MS) should keep them in
mind, because future things could drop the parking brake here. If so,
the safety/risk implications may be non-obvious unless etc.

-- Risk Management is the clue that asks:

"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"

 

[FromTheRafters]

This is where your "NT-capable bipartite" concept collapses. We already
established that the transition cannot be done through memory, since NT clears
memory before loading itself. The only possible way to do the transition is by
intermediary of the hard drive. In other words, through file! Theoretically
this could be done by patching one of the NT files (NTLDR is the classic
candidate for the purpose).

While were on the subject (sort of), what is the last program (normally)
that is accessed by way of its physical location on disk, i.e. pre file system,
on the NT based systems? Does the active partition's volume boot code
pass program flow to NTLDR due to its physical location?

[snip]

 

[Zvi Netiv]

[snip]

This is where your "NT-capable bipartite" concept collapses. We already
established that the transition cannot be done through memory, since NT clears
memory before loading itself. The only possible way to do the transition is by
intermediary of the hard drive. In other words, through file! Theoretically
this could be done by patching one of the NT files (NTLDR is the classic
candidate for the purpose).

While were on the subject (sort of), what is the last program (normally)
that is accessed by way of its physical location on disk, i.e. pre file system,
on the NT based systems?

NTLDR starts on my dual boot system drive (XP/Win98SE on FAT-32) at cluster
197,158, which is rather deep in the data area. What do you learn from it?

Next, searching google for "NT boot sector structure" yields a wealth of
information from which I recommend reading:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html

The last program that is accessed based on its raw location, prior to loading
the OS, is the active partition bootstrap code, found in the active boot sector,
to which your refer as "volume boot code" (you read the pcguide page, above!).

Does the active partition's volume boot code
pass program flow to NTLDR due to its physical location?

Think: Why would NTLDR need to be specified by *name* in the OS bootstrap
program if it could be accessed by its raw location? The available space for
the bootstrap program in the boot sector occupies just about 400 bytes (the rest
of the sector is taken by the BPB and boot signature) and every available byte
must be optimally used.

I believe I know where from your question stems: In early DOS versions, the OS
boot sequence required that the OS loader should be placed first, right after
the root directory, and unfragmented. This requirement doesn't exist anymore
since MS-DOS 4.x or 5 (I am not sure which exactly).

Regards, Zvi

 

[Zvi Netiv]

[snip]

This is where your "NT-capable bipartite" concept collapses. We already
established that the transition cannot be done through memory, since NT clears
memory before loading itself. The only possible way to do the transition is by
intermediary of the hard drive. In other words, through file! Theoretically
this could be done by patching one of the NT files (NTLDR is the classic
candidate for the purpose).

While were on the subject (sort of), what is the last program (normally)
that is accessed by way of its physical location on disk, i.e. pre file system,
on the NT based systems?

NTLDR starts on my dual boot system drive (XP/Win98SE on FAT-32) at cluster
197,158, which is rather deep in the data area. What do you learn from it?

Next, searching google for "NT boot sector structure" yields a wealth of
information from which I recommend reading:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html

The last program that is accessed based on its raw location, prior to loading
the OS, is the active partition bootstrap code, found in the active boot sector,
to which your refer as "volume boot code" (you read the pcguide page, above!).

Does the active partition's volume boot code
pass program flow to NTLDR due to its physical location?

Think: Why would NTLDR need to be specified by *name* in the OS bootstrap
program if it could be accessed by its raw location? The available space for
the bootstrap program in the boot sector occupies just about 400 bytes (the rest
of the sector is taken by the BPB and boot signature) and every available byte
must be optimally used.

I believe I know where from your question stems: In early DOS versions, the OS
boot sequence required that the OS loader should be placed first, right after
the root directory, and unfragmented. This requirement doesn't exist anymore
since MS-DOS 4.x or 5 (I am not sure which exactly).

Regards, Zvi

 

[Robert Green]

"Zvi Netiv" <support@replace_with_domain.com> wrote in

message

[snip]

While were on the subject (sort of), what is the last program (normally)
that is accessed by way of its physical location on disk,

i.e. pre file >>system, on the NT based systems?

NTLDR starts on my dual boot system drive (XP/Win98SE on

FAT-32) at >cluster 197,158, which is rather deep in the
data area. What do you >learn from it?

Next, searching google for "NT boot sector structure" yields a wealth of
information from which I recommend reading:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html

Readers might find this page interesting as well...

http://bootmaster.filerecovery.biz/appnote3.html

Contains a brief description of the NTFS boot process with a
disassembly of the boot sector.

With NTFS the boot sector is part of the metadata file
$Boot, and all the boot sector IPL does is load $Boot to
memory and jump into it.

$Boot itself contains code to locate and load NTLDR, which
is a fairly complicated process, since it requires parsing
MFT file record segments as well as the root index.

To add to the speculation on this thread, a look at either
the FAT or NTFS boot sequence should make it clear that is
perfectly possible to have a multi-partite virus which can
replicate on NT via the floppy disk vector. Not practical,
just possible.

Bob

 

[FromTheRafters]

[snip]

This long thread has left me puzzled. If NT-based versions of Windows
don't allow any low-level access to floppies, how does a Windows NT/2K/XP
user format a floppy disk for use?

I think that it is only application level software that is denied low-level
access, and I'm not too sure what the OS replaces the BIOS routines
with. Witty apparently found a way to circumvent the barrier between
application and system software, as yet I haven't seen it explained.

This should help clarify the matter:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp

Thanks, Bob.

 

[FromTheRafters]

[snip]

This is where your "NT-capable bipartite" concept collapses. We already
established that the transition cannot be done through memory, since NT clears
memory before loading itself. The only possible way to do the transition is by
intermediary of the hard drive. In other words, through file! Theoretically
this could be done by patching one of the NT files (NTLDR is the classic
candidate for the purpose).

While were on the subject (sort of), what is the last program (normally)
that is accessed by way of its physical location on disk, i.e. pre file system,
on the NT based systems?

NTLDR starts on my dual boot system drive (XP/Win98SE on FAT-32) at cluster
197,158, which is rather deep in the data area. What do you learn from it?

Not much really. ;o)

Next, searching google for "NT boot sector structure" yields a wealth of
information from which I recommend reading:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html

Thanks for the links, I mightn't have found them myself.

The last program that is accessed based on its raw location, prior to loading
the OS, is the active partition bootstrap code, found in the active boot sector,
to which your refer as "volume boot code" (you read the pcguide page, above!).

Evidently the MFT contains enough information to allow the next code to be
found in the filesystem prior to that filesystem's mechanisms being implemented.
Nice trick - part of the fault tolerance aspect no doubt.

Think: Why would NTLDR need to be specified by *name* in the OS bootstrap
program if it could be accessed by its raw location?

Sometimes things are as they are despite any *need* to be so.

The available space for
the bootstrap program in the boot sector occupies just about 400 bytes (the rest
of the sector is taken by the BPB and boot signature) and every available byte
must be optimally used.
Understood.

I believe I know where from your question stems: In early DOS versions, the OS
boot sequence required that the OS loader should be placed first, right after
the root directory, and unfragmented. This requirement doesn't exist anymore
since MS-DOS 4.x or 5 (I am not sure which exactly).

Yes, that was it. It was in a known physical location and contiguous and
thereafter the file system was in place.

Thanks for your explanation(s).

 

[FromTheRafters]

Readers might find this page interesting as well...

http://bootmaster.filerecovery.biz/appnote3.html

Contains a brief description of the NTFS boot process with a
disassembly of the boot sector.

Nice. Thanks Bob.

With NTFS the boot sector is part of the metadata file
$Boot, and all the boot sector IPL does is load $Boot to
memory and jump into it.

$Boot itself contains code to locate and load NTLDR, which
is a fairly complicated process, since it requires parsing
MFT file record segments as well as the root index.

Yeah, this is what prompted my question about how it was located.