Trying to design low level hard disk manipulation program
|
From: ragtag99 on 19 Sep 2006 18:52 I posted this on comp.lang.asm.x86, alt.os.development, comp.arch, comp.lang.c++ Im working with windows xp professional, NTFS and programming with MASM, c++ (free compiler) or visual basic 6.0 === question 1 Primarily Im trying to design a program that has full control over a hard disk. What it needs to do is find out what sectors haven't been written to and be able to write anything there, but doesn't count towards disk space, IOW the data is user defined garbage with no consequense if overwritten. As a very gum-and-bandaid idea for an open space hard drive sweep, could i simply create a file the size of the remaining data in the hard drive save it then delete it? Would this in effect fill all available space with user defined garbage? Although ideally Id like to pinpoint empty sectors and write to them. === question 2 Secondarily make a full delete, thus where a file was is now just zeros. For this, if I were to open a file with any given language specific 'open' methood re-write the open data with the exact data length of zeros then resave it, would that accomplish this task? Or would the data be saved in a new sector and pointed to that leaving the original data intact but unattainable? IOW if you open a file from the hard disk make changes and save it, does it save to the same physical location the file was pulled from? == am i on the right track? I've scoured the web with little success. What i am working towards is using the Master Record Table (MRT) of the NTFS and seeing if i can find the sectors that aren't written to and write there for the primary task and follow the pointers and write there for the secondary task. Does anyone have a reference on how to programmatically access the MRT? Ive also come across BIOS function INT 13H which is low level disk operations. This seems to be of help, has anyone had success in using it? Thanks for any help. Jesse
From: red floyd on 19 Sep 2006 19:53 ragtag99 wrote: > [redacted question on accessing disks] This is OT for comp.lang.c++. Please post to a newsgroup relevant to your platform. Thank you.
From: bj7lewis on 19 Sep 2006 22:31 > Im working with windows xp professional, NTFS and programming with Try first working with FAT32 for HDD if you can repartition(PartitionMagic) or FAT12 using FDD) cause some here may know NTFS internals but like many like me have only looked into FAT## FS and unix/linux FSs... Using FDD is better cause you only have to start looking at the disk at a 1.14MB scale and since your HDD partition isn't near 99.999% full this file EatUpFreeSpace.dat will be too big(many MBs) to read(you as a human[using HEX editor] at first before you can code the program to read it) the cluster chain to see where all those EatUpFreeSpace.dat sectors are... > As a very gum-and-bandaid idea for an open space hard drive sweep, > could i simply create a file the size of the remaining data in the hard > drive save it then delete it? Would this in effect fill all available > space with user defined garbage? Although ideally Id like to pinpoint > empty sectors and write to them. Also note clustors and sectors can be different depending to FS so ##K(FAT32/NTFS) size cluter can take up ## * 1024 sectors and only part the first 1 sector may really be used. Example Windows for some reason needed to allocate clustor to a file ##,###,### bytes and Windows went thur and found many clustors for all but 349 bytes so Window allocates one more of size ##K and and saves the 349 bytes and the rest of clustor is wasted space [(## * 1024) - 1 sectors never getting anymore delete to hold untill the file is deleted and Windows later allocate clustors]... > Secondarily make a full delete, thus where a file was is now just > zeros. For this, if I were to open a file with any given language Doing this does will only make write zeros where EatUpFreeSpace.dat sectors actucally contained the files data any clustors(I think only the last one) allocated to EatUpFreeSpace.dat may contain wasted space [(## * 1024) - 1 sectors] in my prev example holding 349 bytes. Filling EatUpFreeSpace.dat with zeros fills all the other allocated clustor with zero and the last zero the 349 bytes... So the wasted space now contains what was there before either an ASCII format charatcer that some drive formatters write or random data the used to be valid in a old file deleted before EatUpFreeSpace.dat was created... > would the data be saved in a new sector and pointed to that leaving the > original data intact but unattainable? > IOW if you open a file from the hard disk make changes and save it, > does it save to the same physical location the file was pulled from? I don't know this... > I've scoured the web with little success. What i am working towards is > using the Master Record Table (MRT) of the NTFS and seeing if i can > find the sectors that aren't written to and write there for the primary > task and follow the pointers and write there for the secondary task. > Does anyone have a reference on how to programmatically access the MRT? I don't know this... Like I say FAT12 or FAT32 is more well known interally than NTFS in the public. So look for Master Boot Record(MBR - HDD only) and Boot Parameter Block(BPB in the bootsector of FDD and bootsector of each HDD partition pointed to by the MBR)... > Ive also come across BIOS function INT 13H which is low level disk > operations. This seems to be of help, has anyone had success in using > it? I don't know this...
From: Phil Carmody on 20 Sep 2006 02:57 "ragtag99" <spamtrap(a)crayne.org> writes: > I posted this on comp.lang.asm.x86, alt.os.development, comp.arch, > comp.lang.c++ > > Im working with windows xp professional, NTFS and programming with > MASM, c++ (free compiler) or visual basic 6.0 > > === question 1 > > Primarily Im trying to design a program that has full control over a > hard disk. What it needs to do is find out what sectors haven't been > written to and be able to write anything there, but doesn't count > towards disk space, IOW the data is user defined garbage with no > consequense if overwritten. So there's no consequence if it's not written at all. Your solution is therefore to simply not do this. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: F.J.K. on 20 Sep 2006 05:03
Oh my, so many nonos in one post :-) ragtag99 wrote: > I posted this on comp.lang.asm.x86, alt.os.development, comp.arch, > comp.lang.c++ crossposting is great. Try posting in more than 50 groups for better results though. > Im working with windows xp professional, NTFS and programming with > MASM, c++ (free compiler) or visual basic 6.0 wonderful. We would be especially interested in the VB parts of your program. > Primarily Im trying to design a program that has full control over a > hard disk. What it needs to do is find out what sectors haven't been > written to and be able to write anything there, but doesn't count > towards disk space, IOW the data is user defined garbage with no > consequense if overwritten. Sounds like an especially useful feature if you want to hide some kind of malware. We are always interested in implementations like this, as the standard way of doing things with <fstream> gets really boring over time. > Secondarily make a full delete, thus where a file was is now just > zeros. For this, if I were to open a file with any given language > specific 'open' methood re-write the open data with the exact data > length of zeros then resave it, would that accomplish this task? Perhaps. Of course this would depend largely on implementation specific / OS / fs details. As we always try to not focus too much on C++ specific issues, this is a perfect question to ask here. > Ive also come across BIOS function INT 13H which is low level disk > operations. This seems to be of help, has anyone had success in using > it? Thanks for bringing the BIOS into play. This qualifies as being kind of plattform independent, as both Linux and Windows PC's have a BIOS. Good job. > Thanks for any help. Im *really* sorry I couldn't help more. Best luck, Felix |