FDISK /MBR question

Discussion in 'Computer Support' started by Trent SC, Dec 6, 2005.

  1. Trent SC

    Noel Paton Guest

    ....and another response just in....
    (interleaved - from Chris Quirke - MVP)
    --
    Noel Paton (MS-MVP 2002-2006, Windows)

    Nil Carborundum Illegitemi
    http://www.crashfixpc.com/millsrpch.htm

    http://tinyurl.com/6oztj

    Please read http://dts-l.org/goodpost.htm on how to post messages to NG's
    True. It is OS-agnostic, system-level code. If you mark an MS extended
    partition as active, it will boot it (i.e. run code in the first sector of
    the extended partition, which will typically lock up the PC).

    True. I haven't checked the 460-byte figure, but it sounds correct.

    True - if you are dealing with standard MBR code. But that code can be
    anything, and thus do anything. Non-standard MBR code include malware, boot
    managers, DDO driver code, and possibly other utils such as disk encryption
    or system diagnostics. Such code may use an alternate partition table
    location and/or structure, or not parse any tables for OSs at all. For
    example, if I were a PC maker that was not committed to any particular OS, I
    could drop 20M of system diags into the first sectors of the physical drive
    and run this code directly, with no OS, partitions or file system present at
    all.

    True. Drive letters, files, file systems and logical volumes are all
    OS-level concepts, unknown to OS-agnostic system-level code such as MBR.

    He's losing the plot here. Additional caveat; absence of 55AAh boot sig in
    MBR causes FDisk /MBR to zero out the partition table. Malware can move
    partition table to another sector and/or encrypt it, not just change the
    offset. Boot managers such as BING may use different table structure to
    support more partitions, either via the "standard" table, or directly.

    In any case, none of this system-level code knows what OS is in a partition,
    because it is not this code that reads the partition type byte; that is done
    by whatever OS loads from the partition boot record. Some boot managers may,
    as a "courtesy", enumerate partitions according to OS type byte, but can
    only do so for those types known to the utility.

    At this level, there is no such thing as "primary" vs. "extended"
    partitions; that, too, is an OS-level concept peculiar to MS OSs and those
    that use the same conventions as MS OSs. FDisk understands logical volumes
    only because it is an OS tool, as much as it is a system tool.

    Mmmmh. In that the OS starts from the first byte of the partition, it is
    indeed the MBR code's role to initiate the loading of the OS. You can think
    of MBR as a "soft" extension of the BIOS.
    True - but this is only an expectation; it can do anything it likes, e.g.

    a malware there may trash the HD's contents as a payload. I see this code as
    being part of the OS itself, even though it is not a file within the OS's
    file system (as the concept "file system" has yet to be built)

    It is expected to behave in the same way. The expectation is that MBR code
    dropped by any OS will be functionally interchangeable, as this is supposed
    to be OS-neutral territory. FDisk is part of DOS rather than Win3.yuk,
    though Win3.yuk often drops newer versions of certain DOS files such as
    HiMem.sys, Emm386.exe etc. There was always version leapfrog between various
    DOS and Win3.yuk versions.

    True. This is why it's so attractive a place to overcome BIOS address
    limitations via a Dynamic Drive Overlay. This extends BIOS's ability to
    address the HD, so that partition that are "too big" or too far up the
    address space can be reached. The OS can either take over the addressing of
    the HD, or use the DDO's interrupt services in place and use these instead
    of the broken code within system BIOS.

    Looks like the dude knows what he's talking about, though isn't quite as
    clear as he should be (he has the concepts, but they are not really
    hard-coded into place).

    See http://cquirke.mvps.org/9x/startup.htm (yes, it's the Win9x startup
    axis, but it starts from PSU PowerGood and thus covers this system-level MBR
    stuff).

    I'm lucky in that I was aware of these issues from my first week on the PC,
    as I started off mainly in PICK R83 with DOS 3.3 as a sideline. Most folks
    start off with one vendor's OSs only, and thus don't have a clear idea of
    where the system ends and the OS should begin, and how multiple OSs are
    supposed to co-exist.
     
    Noel Paton, Dec 10, 2005
    #21
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.