Announcement

Collapse
No announcement yet.

file attributes

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

  • Joep van Steen
    replied
    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

    Leave a comment:


  • Sebastian Groeneveld
    replied
    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>

    Leave a comment:


  • Robert M Green
    Guest replied
    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

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

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • David J Venable
    replied
    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.

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

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • David J Venable
    replied
    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!

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

    Leave a comment:


  • Joep van Steen
    replied
    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).]

    Leave a comment:


  • Clay Clear
    replied
    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)

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Clay Clear
    replied
    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).]

    Leave a comment:


  • Mel Bishop
    replied
    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.


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

    Leave a comment:


  • David J Venable
    started a topic file attributes

    file attributes

    I am familiar with both the attrib function and statement, as
    well as dir$()--and I don't think that either can do this
    (correct me if I'm wrong).

    I am about to work on some forensics software, and I will need to
    search for some common data hiding techniques. One of which, is
    to set a file (usually this is done manually using something like
    Norton Disk Editor) to have the Volume Label attribute (8). I was
    just wondering if anyone has any functions or anything out there
    that can look at the FAT on a lower level.

    This is also the way that Windows stores the long file names.
    The long file name is stored directly before the file's entry
    in the FAT, and it is given the Volume Label attribute. So,
    functions of either sort are welcomed. Preferably Public Domain
    or freeware.

    Also, on a different note, does anyone have any functions to
    read/write directly to the hard disk? I have some that I got
    either here or on the abc website but they don't work.

    Thanks.

    (I'm not trying to avoid doing the programming here, I'm just not
    an assembly programmer. Any help would be appreciated.)

    ------------------
Working...
X