
 MyMBR --- Batch and Script files to View your first
 =====     Hard Drive's _MBR_ (Master Boot Record) as
           text and Save it as text or a binary file.

 (Requires: the use of DEBUG.EXE and CHOICE.COM
  MyMBR can be used on a Boot Disk, as long as DEBUG and
  CHOICE exist somewhere in your PATH.  Place a copy of
  both utilities on the floppy disk itself to be sure.)

 [ Copyright(C)2000,2001 by The Starman for DOS 6.2 or 
   higher and Windows 95B / 98 / 98SE / ME. ]


          Have you ever tried using MS-DEBUG to view the
 first sector of a hard drive?  It _should_ show you the
 Master Boot Record, BUT it will NOT under most OS's run
 on a PC.  Instead, it will show you the Boot-up code of
 the OS (its Boot Record) from the Active Partition that
 was booted when you turned on the computer.  This Boot
 Record under Windows 95 (OSR2)/Win 98, for example, is
 labeled as MSWIN4.1 and is normally located on Absolute
 Sector 63 (the 64th sector) on any hard drive which has
 the first (or only) partition set active.  The MBR is
 always located on the very first sector (Sector 0) of
 your hard drive. (* See the FOOTNOTE below for an easy
 way to prove if your OS is hiding the MBR from Debug!)


    MyMBR avoids the 'big brother' aspects of the Win OS
 (and others?) by using INT13 (a low-level BIOS interrupt
 routine) to access the MBR on your first hard drive...
 Simply place the SCRIPT files READ.dsf and SAVE.dsf (the
 extension 'dsf' stands for Debug Script File here) and
 the Batch file MYMBR.bat in the same folder and execute
 the batch file...

     When you execute the Batch file (Mymbr.bat) it will
 automatically open a DOS-Window and display its purpose.
 Moving to the next screen displays an interactive Menu
 which will continue to be available for use every time
 one of its functions has completed until you choose to
 Exit(X) the program. There's also a choice of Creating a
 binary copy of your MBR to a file; mymbr.bin, Displaying
 the output on-screen, Saving the output to a text file
 called mymbr.txt in the same folder and Viewing the file
 in either Notepad or EDIT.COM -- MyMBR.bat can detect if
 you're running it in a DOS-window (under the Windows OS)
 and will try to use Notepad. If MyMBR is run under _real_
 DOS, it will try to use  EDIT.COM  instead.


            Setting up a PIF (or shortcut) File
            -----------------------------------

        Before you run the Batch file for the first time,
 you might want to Right-click on its filename and select
 the "Properties" item... I believe that setting the DOS-
 window for FULL-screen and also checking the box labeled
 "Close window on Exit" makes for a smoother running .bat
 file under Windows! After you execute the batch file, a
 .PIF file (which is a shortcut file; the .pif extension
 will not show even if you have Windows set to show all
 extensions!) will appear in the same folder as MyMBR.bat
 and can used to run it as well.  You can even change its
 icon if you want.

	NOTE: The SCRIPT files will not function without
 DEBUG.EXE; please make sure that DEBUG is in your PATH.
 If you have any problems running MyMBR, first make sure
 that DEBUG.EXE exists on your Hard Drive, and that it is
 in a folder listed in your PATH... Run the DOS command,
 PATH, to see such a listing... DEBUG is most often found
 in the folder: C:\WINDOWS\COMMAND on Win 9x machines.





     A Detailed Explanation of MyMBR's SAVE Function
 ========================================================

	For those who are interested, here's an Assembly
 listing of the x86 code with an explanation below:

 -------------------------------------------------------
  xxxx:0300  MOV     AX,0201   ; Function 2, #sectors=1
  xxxx:0303  MOV     BX,0100   ; Buffer begins at :0100
  xxxx:0306  MOV     CX,0001   ; Track 0, First Sector.
  xxxx:0309  MOV     DX,0080   ; Head 0, First HD.
  xxxx:030C  INT     13        ; Interrupt 13h; do it..
  xxxx:030E  INT     3         ; Halt execution; Break.
 -------------------------------------------------------

    This is Function 2 (AH=02h) of INT 13, called:
  _Read Disk Sectors_.

       AL = Number of sectors = 1.

  (ES:)BX => Points to the Buffer in Memory where a
            copy of the sector will be stored...
            Technically, it is ES:BX which is used,
            so it will be in the same segment that
            the OS assigns to DEBUG; there will be:
               512 bytes (0000 through 01FF h).

       CH = Track or Cylinder number = 0.
       CL = Sector Number = 1 (count does NOT begin
            with a zero as it would under DEBUG).

       DH = Head number   = 0.
       DL = Drive number (bit 7 is set for hard
            drives, so...) = 80h for first hard drive.

    Thus, in terms of the standard CHS (cylinder, head,
  and sector) terminology, we have CHS = 0, 0, 1 for
  the first sector on the drive.

    The last line (INT 3) halts execution so we can view
  a dump of the sector it copied from the hard drive...


  Script and Batch File Operations
 ----------------------------------

      The SCRIPT files ASSEMBLE (A) the code directly
  under DEBUG and run the program until 'breaking' at
  INT 3.
       READ.dsf is used to DUMP (D) the sector which
  it stored in memory. Unfortunately, all these Debug
  commands must be redirected to the screen or to the
  text file along with the actual MBR sector dump; it
  even includes a Register display(!) which gives the
  impression of being very messy to those who are
  only interested in seeing the MBR itself.
     I could have written a program in C/ASM to avoid
  displaying all this clutter, but I wanted to use a
  Batch and DEBUG script so everyone could see how it
  was done; and as an aid in teaching Assembly.

     SAVE.dsf is used to WRITE (W) the MBR sector of
  512 bytes (200 hex) to a binary file (Mymbr.bin) in
  the same folder that MyMBR.bat is run.
     You can learn a great deal about DEBUG by going
  over the commands used in this script file.



 *FOOTNOTE: Proving that Windows hides the MBR from
            the normal file commands of DEBUG ...

 --------------------
 * You can easily confirm this for yourself by using
   the following DEBUG script file:

==================================
l 0 2 0 1
d 0 1FF
q

==================================

     COPY and SAVE the lines above (between the two
  "=====" lines) _exactly_ as they appear in a text
  file; including the BLANK LINE at the end (which
  makes sure there is a carriage return after the
  'q')!  Without the carriage return after the 'q,'
  DEBUG won't be able to quit; it will "lock-up" or
  "hang" the program and no keyboard input will be
  allowed!  Anyway, as I was saying... save it as a
  text file, and change the filename to "test.dsf".

      Then ENTER the following line at a DOS PROMPT
  (Make sure test.dsf is in the same directory!):

  C:\> debug < test.dsf > bootrec.txt

   What you'll see when you open bootrec.txt is just
   the usual MSWIN4.1 (or whatever) standard Boot
   Record code...  BUT we told DEBUG to load sector
   ZERO (0) from drive 2 (the 'C' drive)! Apparently,
   the Windows OS/and others? somehow hide all the
   previous 63 sectors (0 through 62) from most of
   the programs that try to access them...

     Even when you use a low level Disk Editor, such
  as Norton's DiskEdit or PTS's DE program, you need
  to set it to search the PHYSICAL DRIVE and NOT the
  LOGICAL drive(s) in order to see the MBR.  See my
  Free Tools page for a description of the PTS Disk
  Editor (a free utility program):

 <http://www.geocities.com/thestarman3/tool/de/PTS-DE.htm>


 [ The Starman.  27 AUG 2001. ]

 < http://www.geocities.com/thestarman3/asm/ >.
