Int13 & xp

[Mel Bishop]

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?????


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

[Joep van Steen]

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).]

[Matthew Berg]

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.

[Mel Bishop]

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.


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

[George Bleck]

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

[Joep van Steen]

??? Lance and Edmond ???

Oops! sorry!

Joep 'and' van Steen ...

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

http://www.diydatarecovery.nl

[Matthew Berg]

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.

[Jean-Maurice de Courcy]

Eureka !

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