Announcement

Collapse
No announcement yet.

Int13 & xp

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Int13 & xp

    Several years ago, I wrote a forensic program using DOS Int13
    direct disk sector R/W access via PB2.1f and recently xlated it
    to PB3.5. I tried it on xp and the O/S came back and said
    something to effect "can't let you do that".

    Was wondering, if this is in fact true, how are other utilities
    like PartitionMagic able to skirt this issue? Anybody know? The
    only thing I can think of is PB/DOS is 16-bit and xp is 32?????


    ------------------
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

  • #2
    Hi,

    int13h wont work in NT based systems (as 2000 and XP),
    you'll have to go through API. That's by the way also how
    PartitionMagic does that.

    It's got nothing to do with 16/32 bit,
    NT based operating systems do NOT want you to access devices
    directly. By goinf through API the OS ensures it always has the last
    say. For example, going through the API in XP will prevent you accessing
    the last cylinder on the disk. XP 'protects' this as it reserves
    this sector for the LDM database.

    PB3.5 can not handle that, consider getting the console compiler.

    Opening volumes in NT/XP/2000 is simple enough. This will read
    the boot sector of the c: drive:

    FUNCTION PBMAIN
    OPEN "\\.\c:" FOR BINARY SHARED AS #1
    GET$ #1, 512, a$
    PRINT a$
    PRINT "done"

    Reading 'LBA sectors' (Lance and Edmond deserve the credit
    for this):

    //Read MBR first disk

    #COMPILE EXE
    #INCLUDE "WIN32API.INC"


    FUNCTION PBMAIN
    LOCAL a AS ASCIIZ * %MAX_PATH
    LOCAL buffer AS STRING * 512
    LOCAL dwRead AS DWORD
    LOCAL hPhysicalDrive AS DWORD
    DIM boot AS GLOBAL STRING * 32256

    a = "\\.\PhysicalDrive0"
    hPhysicalDrive = CreateFile(a, %GENERIC_READ OR %GENERIC_WRITE, _
    %FILE_SHARE_READ OR %FILE_SHARE_WRITE, BYVAL 0, %OPEN_EXISTING, 0, 0 )

    IF hPhysicalDrive = BITS???(%INVALID_HANDLE_VALUE) THEN
    PRINT "Something broke! I can't read the device!"
    WAITKEY$
    EXIT FUNCTION
    END IF

    IF ReadFile(hPhysicalDrive, BYVAL VARPTR(buffer), SIZEOF(buffer), dwRead, BYVAL %NULL) THEN
    PRINT "The 1st sector contains the following data:"
    PRINT LEFT$(Buffer, dwRead)
    END IF

    CloseHandle hPhysicalDrive


    Regards,


    ------------------
    Joep
    http://www.diydatarecovery.nl

    [This message has been edited by Joep van Steen (edited May 07, 2003).]
    Joep

    http://www.diydatarecovery.nl

    Comment


    • #3
      Was wondering, if this is in fact true, how are other utilities like PartitionMagic able to skirt this issue?
      PartitionMagic, or at least the latest versions, have a DOS version that is started from a bootable floppy and a Windows version that is a native Win32 application. The Windows version presumably includes drivers written especially for PartitionMagic that allow the program Ring 0 access to the hardware (i.e. the HDDs), bypassing Windows' normal isolation of the hardware through the HAL.

      If you want your DOS program to have that sort of access, you'll probably need to put it on a (DOS) bootable floppy so you can be sure that Windows won't be in the way. It should be possible for you to modify your program to work under Windows 95/98/ME - depending on what it does exactly - as they are, after all, partly 16-bit just like DOS. As for NT-class Windows, I'd be surprised if you did get it working. Windows NT/2000/XP generally don't like DOS applications messing around with interrupts, especially those that interface with hardware.

      ------------------
      If you try to make something idiot-proof, someone will invent a better idiot.
      If you try to make something idiot-proof, someone will invent a better idiot.

      Comment


      • #4
        Originally posted by Joep van Steen:
        ??? Lance and Edmond ???
        Thanks Joep. That helps.

        Matthew, I kinda-sort'ta-in-a-way already had that in the back
        of my mind already. Your reply just brought it to the forefront.

        Thanks both.


        ------------------
        There are no atheists in a fox hole or the morning of a math test.
        If my flag offends you, I'll help you pack.

        Comment


        • #5
          Matthew,

          I use PM quite often, It has a Win based GUI that creates a batch file.
          When changes are applied the machine reboots and does the work in DOS mode
          on Win9x machines

          On WinNT kernel based and machines it does the same steps except, due to
          the lack of a DOS boot partion, it performs the actions just after the
          "Kernel Initialization" portion of the boot sequence.


          ------------------
          Every day I try to learn one thing new,
          but new things to learn are increasing exponentially.
          At this rate I’m becoming an idiot faster and faster !!!
          ------------------
          George W. Bleck
          Lead Computer Systems Engineer
          KeySpan Corporation
          My Email
          <b>George W. Bleck</b>
          <img src='http://www.blecktech.com/myemail.gif'>

          Comment


          • #6
            ??? Lance and Edmond ???

            Oops! sorry!

            Joep 'and' van Steen ...

            ------------------
            Joep

            http://www.diydatarecovery.nl
            Joep

            http://www.diydatarecovery.nl

            Comment


            • #7
              On WinNT kernel based and machines it does the same steps except, due to the lack of a DOS boot partion, it performs the actions just after the "Kernel Initialization" portion of the boot sequence.
              I have used PartitionMagic since version 5 and currently have installed the latest version, 8.0. The Windows version of PartitionMagic seems to be able to do some things in Windows, but you are right in that I have noticed for some operations PartitionMagic has required a reboot (in Windows 2000).

              ------------------
              If you try to make something idiot-proof, someone will invent a better idiot.
              If you try to make something idiot-proof, someone will invent a better idiot.

              Comment


              • #8
                Eureka !

                Originally posted by Joep van Steen View Post
                Hi,

                int13h wont work in NT based systems (as 2000 and XP),
                you'll have to go through API. That's by the way also how
                PartitionMagic does that.

                It's got nothing to do with 16/32 bit,
                NT based operating systems do NOT want you to access devices
                directly. By goinf through API the OS ensures it always has the last
                say. For example, going through the API in XP will prevent you accessing
                the last cylinder on the disk. XP 'protects' this as it reserves
                this sector for the LDM database.

                PB3.5 can not handle that, consider getting the console compiler.

                Opening volumes in NT/XP/2000 is simple enough. This will read
                the boot sector of the c: drive:

                FUNCTION PBMAIN
                OPEN "\\.\c:" FOR BINARY SHARED AS #1
                GET$ #1, 512, a$
                PRINT a$
                PRINT "done"

                Reading 'LBA sectors' (Lance and Edmond deserve the credit
                for this):

                //Read MBR first disk

                #COMPILE EXE
                #INCLUDE "WIN32API.INC"


                FUNCTION PBMAIN
                LOCAL a AS ASCIIZ * %MAX_PATH
                LOCAL buffer AS STRING * 512
                LOCAL dwRead AS DWORD
                LOCAL hPhysicalDrive AS DWORD
                DIM boot AS GLOBAL STRING * 32256

                a = "\\.\PhysicalDrive0"
                hPhysicalDrive = CreateFile(a, %GENERIC_READ OR %GENERIC_WRITE, _
                %FILE_SHARE_READ OR %FILE_SHARE_WRITE, BYVAL 0, %OPEN_EXISTING, 0, 0 )

                IF hPhysicalDrive = BITS???(%INVALID_HANDLE_VALUE) THEN
                PRINT "Something broke! I can't read the device!"
                WAITKEY$
                EXIT FUNCTION
                END IF

                IF ReadFile(hPhysicalDrive, BYVAL VARPTR(buffer), SIZEOF(buffer), dwRead, BYVAL %NULL) THEN
                PRINT "The 1st sector contains the following data:"
                PRINT LEFT$(Buffer, dwRead)
                END IF

                CloseHandle hPhysicalDrive


                Regards,


                ------------------
                Joep
                http://www.diydatarecovery.nl

                [This message has been edited by Joep van Steen (edited May 07, 2003).]
                Thanks Joep for this very VERY interesting answer to my unusable code to read $MFT and other system files.

                Your code is simple and work, with that I can navigate on physical disk with the seek and read anything anywhere because I am physicaly a the beginning of disk very useful, thanks a lot !

                Have a nice day !!!

                JM

                Comment

                Working...
                X