No announcement yet.

file attributes

  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.


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


  • #2
    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

    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.


    • #3

      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

      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.


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


      • #4
        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


        • #5

          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


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


          • #6

            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


            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.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,


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

            Mark Collins
            Member posted March 21, 2002 07:29 AM
            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
            DriveNum% = DriveNum% + 125
            END IF

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

            SELECT CASE X13Command?
            REG %BX,&H55AA

            IF (NumberOfSectors?? = 0) OR (NumberOfSectors?? = 1) THEN
            DIM SectorBuffer AS X13Buffer
            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)

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

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

            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
            SHIFT RIGHT AXRegister%, 8
            CALL DiskStatus(ByCopy Register%)
            END IF
            END IF
            FUNCTION = %False
            END IF


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

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



            • #7
              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!



              • #8
                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


                • #9
                  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.



                  • #10
                    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


                    • #11

                      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

                      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.




                      • #12
                        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:
                        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>
                        Sebastian Groeneveld
                        mailto:[email protected][email protected]</A>


                        • #13

                          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,