Announcement

**Mel Bishop** · 18 Jul 2002, 09:02 PM

I have an INT13 routine that reads absolute sectors. It is
limited to 1023 tracks, 255 heads (0-255) and 63 sectors per
track. That equals about 8gb and some change. For larger drives,
you will have to go the LBA route and that I don't have.

If you feel my routine will help, give my your e-mail and I will
send you a zip'd file of the source code. I am not going to
include an ABS write since I don't want to run the risk of a law
suit.

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

**Clay Clear** · 18 Jul 2002, 09:28 PM

David,

I just printed out the corresponding get/set file attributes
sections from the Rolf Brown's Interrupt Lists. It is now
11:22 PM, Thursday, July 18, CDT, USA. I will get to work
tomorrow on TRYING to come up with some viable code to do
as you need. I am going to get some sleep first, because such
interrupt services might cause grave damage to modern OS's
file systems if used inappropriately. I will first test the
code on my own system, to make sure that it does not trash
the HD. However, such code might work on my machine
(Win98SE, Pentium III 600EB), but not with other
vendors, OS's, or hardwares. So, you will have to take your
chances.

If I get some viable code working, I will post it in this
thread as two functions, one to read the attributes, and one to
set them. I will code them so they can be used as PBU's.
Note that I have PB/DOS 3.5.

Cordially,

ADDED: The code I will post, if any at all, will be Public
Domain. Anybody may use it in any way they wish.

------------------
Clay C. Clear
mailto:[email protected][email protected]</A>
Clay Clear's Software (Frames Only)

[This message has been edited by Clay Clear (edited July 18, 2002).]

**Tom Hanlin** · 18 Jul 2002, 10:15 PM

The code required will depend greatly on the target OS and OS versions.
It may not work even so, depending on hardware and software anti-virus
measures. Please tell us more about the target system(s), that we might
offer appropriate advice.

A knowledge of assembly language is likely to be useful here, but it may
be that we can work around that.

------------------
Tom Hanlin
PowerBASIC Staff

**Clay Clear** · 19 Jul 2002, 12:29 AM

Tom,

Thanks for your posting. I want David to be SURE to realize the
potential for damage to the target systems if I write the code for
him.

Cordially,

------------------
Clay C. Clear
mailto:[email protected][email protected]</A>
Clay Clear's Software (Frames Only)

**Joep van Steen** · 19 Jul 2002, 06:25 AM

Hello,

For int13h access to disk:

This code was in forum before, I have not tried it, I use different code myself.

(Robert M Green)

===================== quote start
1. Check if LBA i/o is supported
TYPE int48buffer
size AS WORD
flags AS WORD
cylinders AS DWORD
heads AS DWORD
sectorspertrack AS DWORD
totalsectors AS QUAD
bytespersector as WORD
END TYPE

int48buffer.size=1Eh

call int 13h, ah=48h

dl=BIOS drive number
ds:si=segment/offset of buffer

if carry clear, then LBA is supported and the buffer will be
filled in. You can ignore everything except the totalsectors
(which is the total number of sectors on the disk).

In some cases the total sectors returned will reflect the BIOS
address limit rather than the actual size of the disk.

If you want CHS parameters use int 13h, ah=8 to get the correct
cylinder and head counts. The only reason you would need CHS
values would be to calculate LBAs for cylinder boundries.

2. to read the disk

TYPE LBApacket
size AS BYTE
reserved AS BYTE
transfer AS WORD
buffoff AS WORD
buffseg AS WORD
LBA AS QUAD
END TYPE

Fill in the LBApacket buffer and call int 13h, ah=42h

LBApacket.size=1Eh
LBApacket.reserved=0
LBAPacket.transfer=number of sectors to read
buffoff/buffseg are offset & segment of the buffer the sectors
are read to.
LBA is the LBA address of the first sector to read.

dl=BIOS drive number
ds:si = segment/offset of LBApacket buffer.

More details can be found in Ralf Brown's Interrupt List.
===================== quote end

int13h ext read/write access works in real mode DOS, win9x ... in WinME ONLY read access works. In NT based OS'es it will NOT work.
I can think of more ways to hide info on a disk though than just setting the vol attribute bit. These are educated guesses as I have not tried them:

- One would be; replace first character of filename by E5h, and do NOT modify the FAT. This prevents the OS from seeing the file, still it wont be overwritten because the FAT entries have not been freed.
- One could edit the boot sector value 'big total sectors', this will prevent the OS from using an area of the partition, info can be stuffed there.
- In between partitions there's room available that is not used normally; from the MBR upto the first partition there's 63 sectors available, the same goes for extended partition table entries <> logical partitions. When I worked in tech support and had to patch hard disks, I had the childish habbit of writing signatures there

- edit the FAT and mark clusters as bad :- the OS will not use them and info can be stuffed in there
- In a company I worked we were forbidden to use specific software and the IT department would actually check if we hadn't installed illegal software. It is very easy to hide a partition and not have it detected by fdisk and partitioning tools (and Windows and our IT% dept) but show up as unallocated space by editing the partition table ... Another great way of hiding stuff ... The simple trick is to edit the FS descriptor in the pt-table. Yoy can set it to zero, but there is the chance it is overwritten if someone runs FDISK. It's better to replace for instance your FAT32 partition (0Bh) by FFh or whatever. If you need yor secret partition, set it back. Our freeware tool MBRtool could be used for that. A reboot is required for having the changes to take effect.

Best regards,
Joep
http://www.diydatarecovery.nl

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

Added later, found some more ... these forums are so nice:

Mark Collins
Member posted March 21, 2002 07:29 AM
--------------------------------------------------------------------------------
All,
Here is another way that you might try. It is a little cleaner
than the last piece that I sent out to you to attempt.

DIM DriveNum AS INTEGER
DIM Segment AS WORD
DIM Offset AS WORD

DriveNum% = ASCII(UCASE$(Drive$)) - 64

IF DriveNum% < 3 THEN
DriveNum% = 3
ELSE
DriveNum% = DriveNum% + 125
END IF

AXRegister% = X13Command? + &H40
SHIFT LEFT AXRegister%, 8

SELECT CASE X13Command?
CASE %CMD_INSTALLED
REG %BX,&H55AA

CASE %CMD_READ_SECTOR, %CMD_WRITE_SECTOR
IF (NumberOfSectors?? = 0) OR (NumberOfSectors?? = 1) THEN
DIM SectorBuffer AS X13Buffer
ELSE
DIM SectorBuffer(NumberOfSectors - 1) AS X13Buffer
END IF

SectorBuffer.PacketSize? = &H10
SectorBuffer.Reserved? = 0
SectorBuffer.BlocksToTransfer?? = NumberOfSectors??
SectorBuffer.TransferBuffer = Buffer
SectorBuffer.StartingBlock&& = StartingSector&&

REG %DS,VARSEG(SectorBuffer)
REG %SI,VARPTR(SectorBuffer)

CASE %CMD_GET_PARAMETERS
Offset?? = BITS??(Buffer???)
ROTATE RIGHT Buffer???, 16
Segment?? = BITS??(Buffer???)

REG %DS,Segment??
REG %SI,Offset??

CASE %CMD_SET_HARDWARE_CONFIG
AXRegister% = X13Command + &H5E
SHIFT LEFT AXRegister%, 16

CASE ELSE
END SELECT

REG %DX,DriveNum%
REG %AX,AXRegister%

CALL INTERRUPT %INT13

CarryFlag% = REG(%FLAGS)
AXRegister% = REG(%AX)
BXRegister% = REG(%BX)
CarryFlag% = BIT(CarryFlag%, 0)
IF CarryFlag% THEN
IF (X13Command = %CMD_INSTALLED) AND (BXRegister% <> &HAA55) THEN
FUNCTION = %False
ELSE
IF INSTR(UCASE$(COMMAND$), "DEBUG") THEN
SHIFT RIGHT AXRegister%, 8
CALL DiskStatus(ByCopy Register%)
END IF
END IF
FUNCTION = %False
END IF

END

'hey it ain't pretty, but it works...'

[This message has been edited by Joep van Steen (edited July 19, 2002).]

**David J Venable** · 19 Jul 2002, 07:11 PM

Due to the nature of computer forensics, the OS will be--for the
most part--plain ol' DOS, since it will be accessed by using a boot
disk. As of now it just needs to be able to read FAT12 through
FAT32. NTFS would be nice, but I'm not quite as worried about it
yet. There would be no anit-virus software running either.

Thanks a lot for all of the interest and help so far!

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

**Tom Hanlin** · 20 Jul 2002, 01:53 AM

Need to be more specific than "plain old DOS". The low-level disk
handling changed several times across the DOS versions. If you want
to be complete, you'll probably need a fair number of sets of the
same routines, depending on the DOS version.

------------------
Tom Hanlin
PowerBASIC Staff

**David J Venable** · 20 Jul 2002, 05:19 PM

DOS 7.0 (Windows 98) DOS or hopefully (eventually) freeDOS.
I'm pretty sure that 7.0 is 98SE, but if it's not, then I
actually mean the DOS that 98SE runs on.

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

**Tom Hanlin** · 20 Jul 2002, 11:53 PM

I'll look into it. Please bear in mind that I program my brains out
during the week and have few braincells left over, afterwards... may
take a while.

------------------
Tom Hanlin
PowerBASIC Staff

**Robert M Green** · 21 Jul 2002, 05:59 AM

David,

That would be MS-DOS 7.1. 7.0 does not have FAT32 support.

The current(?) release of FreeDOS (.83 Beta 32) is DOS 7.1
compatible.

With 7.1 the old int25/26 functions for sector level disk i/o
are replaced with int21, ax=7305h. 7.1 also provides an API for
file operations with LFNs, but those calls only work from within
Windows, not from pure DOS. All of this stuff is documented in
Ralf Brown's Interrupt List.

Bob

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

**Sebastian Groeneveld** · 21 Jul 2002, 08:42 AM

Quite some time ago I wrote a 'direct disk access' unit, and maybe it could be of use for you. It supports FAT12, FAT16 and should now also work with FAT32 although this has not been extensively tested. However it will never do any damage if used properly... for example, never enter CALL WriteSector("C", 0, SPACE$(512)) Heh, it will execute properly and return -1 indicating success on overwriting your bootsector

Besides the 'core' routines for drive access, it also contains some extra functions which make it easier to parse or build sector data, or follow FAT chains, extracting long filenames from directory entries, etc...

Everything will work fine under DOS 6.2 (even the long filename stuff)... Reading sectors will work under Win95/Win98 (when attempting to write, Windows starts complaining)..... WinNT/Win2k use NTFS which is not supported.

I also have some kind of 'plug-in' for this unit, that handles the use of long filenames.... with this DosLFN unit you can find, open and create files with long filenames in plain DOS (tested on DOS 6.2)

The Direct Disk Access unit can be found at: http://dracuul.tripod.com/pbdos/
Source is not included, compiled for PB 3.5

If you're interested in the DosLFN unit, mail me

Kind regards,

------------------
Sebastian Groeneveld
mailto:[email protected][email protected]</A>

**Joep van Steen** · 21 Jul 2002, 12:52 PM

Hello,

====
Need to be more specific than "plain old DOS". The low-level disk
handling changed several times across the DOS versions. If you want
to be complete, you'll probably need a fair number of sets of the
same routines, depending on the DOS version.
====

Well, not if you access the disk using the BIOS int13h extensions services ...
I use it, works for any DOS version and even Win95/98 read/write and WinME read-only.

If I am not mistaking, using DOS interupts to access the disk, you'll only be able to access logical units, so a deleted partition can not be accessed. By using int13h access you will avoid this problem. I guess that if you're goal is forensics, int13h is the way to go.

You'll need different routines to figure out the different file systems.

Best regards,
Joep

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

http://www.diydatarecovery.nl

Announcement

file attributes

file attributes

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment