COLLECTED hard drive usage after XP NTFS
real@hotmail.com MEB
This is a collected discussion concerning XP hard drive re-use, in which I
have personally participated, per [there may be others which I have missed]:
"Re: IBM T22 and Win 98se";
"Re: New post, ms Everest report";
"Re: Hangs on POST screen";
"Re: win 98 installation"
"Re: Updates for Win9X's & reason/logic"
"Re: No hard drive?"
"Re: Unable to install Win98 SE"
"Re: PC100 v PC133 ram"
GENERAL REFERENCE and SEARCH TERMS: XP NTFS hard drives, tools used to test
and/or recover hard drives, NTFS recovery tools, forensic tools for analysis
of hard drives, securely deleting hard drives, removing XP NTFS from hard
drives.
Present participants in this technical discussion:
Ron Badour, MS MVP for W98;
Jeff Richards MS MVP (Windows - Shell/User);
Gary S. Terhune MS MVP Shell/User
PCR;
Franc Zabkar;
and myself - Maurice Edward, Brahier;
others who may wish to participate.
BACKGROUND:
I have presented apparent issues with the re-use of former XP NTFS hard
drives for other use or re-use. Tools and techniques normally used for
fdisking and formatting, wiping and other activities, apparently do not
completely remove XP NTFS from hard drives.
Disks used for testing:
Samsung (no longer an issue as it is toast, completely un-accessible)
Maxtor 87000AB - Hard Disk Family DiamondMax 1750A (per Everest)
originally used for XP NTFS testing purposes (the OS), fully configured,
idled as a firewall only. After Samsung loss, normal "old" removal
techniques used to re-use the drive as 32bit, then additional testing.
Per early test (WinHex) on the Maxtor:
Hard disk 1
Total capacity: 7,003,586,560 bytes = 6.5 GB
Number of cylinders: 851
Number of heads: 255
Sectors per track: 63
Bytes per sector: 512
Sector count: 13,678,880
Surplus sectors at end: 7,565
Partition 1
Sectors 63 - 13,655,249
Partition table: Sector 0
File system: FAT32
Total capacity: 6,991,455,744 bytes = 6.5 GB
Sector count: 13,655,187
Usable sectors: 13,628,528
First data sector: 26,652
Bytes per sector: 512
Bytes per cluster: 4,096
Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
Total clusters: 1,703,566
Unused inter-partition space:
Sectors 1 - 62 (31.0 KB)
Sectors 13,655,250 - 13,678,879 (11.5 MB) = 11.6 MB
A recent test shows:
Hard disk 1
Total capacity: 7,003,586,560 bytes = 6.5 GB
Number of cylinders: 851
Number of heads: 255
Sectors per track: 63
Bytes per sector: 512
Sector count: 13,678,880
Surplus sectors at end: 7,565
Partition 1
Sectors 63 - 13,639,184
Partition table: Sector 0
File system: ?
Total capacity: 6,983,230,464 bytes = 6.5 GB
Sector count: 13,639,122
Bytes per sector: 512
Unused inter-partition space:
Sectors 1 - 62 (31.0 KB)
Sectors 13,639,185 - 13,678,879 (19.4 MB)
= 19.4 MB
Using GetBack Data for NTFS (an excerpt)
|TREE INFO|
Tree statistic: 395 directories, 579 files, 831 KB
can still be attempted at recovery (and yes, many CAN be viewed, except for
the encrypted/compressed files)
[Don't bother pointing out the errors shown above, this discussion wouldn't
be continuing if there were no errors.]
Tools tested so far:
hd-util [Samsung];
SH-diag [Samsung];
Sutil [Samsung];
Meandisk;
DBan;
Wipe;
Zap;
HDAT2;
AEFDISK;
GDISK (Symantec);
Killdisk;
BootitNG;
MBRWork;
PowerMax [Maxtor];
Maxtor MaxBlast;
Super FDisk;
MHDD;
OnTrack Data Advisor;
Seagate SeaTools;
Eraser;
Testdisk;
WinHex.
(may already have used several others)
Microsoft tools used:
CHKDISK (and its autochkdsk - XP versions);
Recovery Console;
Delpart;
fdisk;
format;
ISSUES:
There are hundreds (thousands) of web pages which appear to claim XP NTFS
is capable of being removed via old techniques and tools.
My testing (to date) shows this in not true. Several hundred megabytes of
hard drive space (on these small hard drives, who knows how much on larger
drives) still contain files and folders from an XP NTFS installation after
its removal.
My personal testing shows that initially, and in particular after
continually trying to remove the XP NTFS, the disk will be reduced in size.
The Maxtor (a 7 gig) now has 5.6 gigabytes of usable space available. Each
attempt to remove XP has added some amount to the original total of unusable
space (less some sensitive data manually removed via disk editor (so I don't
inadvertently place it on the eventual web pages)).
MBR has been replaced several times, drive has been "hardware" reset, and
dozens of other like activities have been tried unsuccessfully. This has
been verified NTFS recovery tools for DOS, Windows and Linux; and disk
editors/viewers of varying quality and ability.
These hidden/restricted areas are ignored or marked as bad sectors by most
tools. These areas may cause potential severe errors to occur when disk
scanning software is used on the disk, depending on its abilities and/or
configuration.
PRESENT ACTIVITIES IN THREADS WITH REPLY FROM MEB:
Re: IBM T22 and Win 98se
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:mjrgh2d6rimacerig...@4ax.com...
| On Mon, 25 Sep 2006 16:56:13 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| > I'm sorry Ron, the only thing I can presently direct you too, are the
tools
| >which will expose that they don't.
| > If you wish me to re-post them here I will. They're NTFS recovery tools
| >(DOS and Linux), and forensic tools.
|
| Are these the kinds of tools you are referring to?
| http://www.hdat2.com/
| http://vidstrom.net/stools/taft/
First yes, second will look at it.
|
| > Regretfully, I'm on my second hard drive during my testing (first, a
| >Samsung which is no longer accessible after using several techniques and
| >tools, the bios no longer recognizes it)
|
| What did you do? AFAIK, even a "low level format" cannot harm a modern
| drive because the drive ignores the command.
|
| See http://www.ariolic.com/activesmart/low-level-format.html
I'll check this info.
|
| Other than that, meddling with the HPA would, AFAICS, only render a
| portion of the drive inaccessible, unless you set a password which you
| subsequently forgot, or unless you deliberately chose to make the
| whole drive invisible. In any case, I would expect that either of the
| above utilities should be able to remove any capacity "clipping".
|
| Otherwise here is Samsung's own Hutil utility:
| http://www.samsung.com/Products/HardDiskDrive/utilities/hutil.htm
Been there done that, didn't get the t-shirt.
|
| "If you want to recover to the original size of drive, perform RECOVER
| NATIVE SIZE by pressing Enter Key. DISPLAY CURRENT STATUS represents
| the current size of drive. If you set 32GB Clip due to capacity
| limitation of system, remove the 32GB clip to adjust the LBA or SIZE."
|
| Of course if your BIOS can no longer see the HD, then your options may
| be limited ...
There are no more options for the Samsung, its toast.
|
| > ... a Maxtor, which is presently also
| >on the verge of loss unless I can find the proper info soon, which I'm
| >having difficulty locating. That would be information on what exactly XP
| >changes in its use of HPA and other changes to the hard drive.
|
| I found these links informative:
|
http://polya.computing.dcu.ie/wiki/index.php/Using_ATA_commands_on_hard_disks_..._why_bother%3F
|
http://polya.computing.dcu.ie/wiki/index.php/Bypassing_Passwords_on_Harddisks
| http://www.win.tue.nl/~aeb/linux/Large-Disk-11.html
Will check these links also.
Maxtor tools will not work (or at least what is publicly available).
|
| I can't see why Windows XP would be interfering with the drive's HPA,
| though. In fact, a search for "Host Protected Area" or "Device
| Configuration Overlay" at the MSKB produces no hits at all for *any*
| MS product.
YEAH SO>>>> did you really expect any info there.. like I didn't check,
come on...
|
| > I'm beginning to suspect this may be a possible reason for Vista not
having
| >a new file system as it was supposed to (or at least that's what I have
| >heard or read).
| >
| >--
| >MEB
|
| >"Ron Badour" <So...@NoAddress.com> wrote in message
| >news:eaZZyKM4...@TK2MSFTNGP04.phx.gbl...
|
| >| Everything I can find says they do work with NTFS--do you have a source
| >for
| >| your statement?
| >|
| >| --
| >| Regards
| >|
| >|
| >| Ron Badour, MS MVP for W98
|
| >| "MEB" <meb@not re...@hotmail.com> wrote in message
| >| news:%23squx%23K4GH...@TK2MSFTNGP02.phx.gbl...
|
| >| > Sorry, Zap and Wipe will not remove XP NTFS completely and may
severely
| >| > damage the hard drive.
| >| >
| >| > --
| >| > MEB
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
Re: IBM T22 and Win 98se
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:ehcwDeV4...@TK2MSFTNGP02.phx.gbl...
| ZAP and WIPE do not remove the NTFS file system completely. They remove
| enough of it to allow something like W98 FDISK, which can't understand
NTFS
| and refuses to do anything to a drive it can't understand, to work so that
| the user can create a FAT or FAT32 partition.
Agreed, but at what cost? The drive is NOT actually wiped and ready for
use. It just APPEARS that it is.
|
| Forensic tools will still be able to recover data, and it's possible that
a
| good NTFS recovery tool will be able to rebuild the file system These
| utilities were not promoted on the basis that they removed NTFS, only that
| they enabled FDISK to start over with a disk that was 'clean enough'.
|
| While it is technically possible for something like ZAP or WIPE to damage
a
| drive, I have used these utilities many, many times and I have never had
an
| issue. If your diagnostics are telling you that the drive is faulty then
I
| would be confident that the problems were there before you used ZAP or
WIPE.
|
| I would have no hesitation in recommending these utilities to someone who
| needs to get rid of an unknown file system so that FDISK can be used.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
Well, that may be fine for Microsoft and acceptable to you, however, I
doubt that if the people effected knew what had been done to their drives,
and that XP NTFS is unremovable by any standard means, and unless my testing
is faulty (which it might be since its unfinished), then all of these drives
are automatically headed for the dump once XP NTFS is installed.
If there is no way to adequately remove XP NTFS, then any resale of an old
computer or it's hard drive: can not be guaranteed as safe; has protected
the seller; or has protected the buyer.
"Ron Badour" <So...@NoAddress.com> wrote in message
news:exJL65V4...@TK2MSFTNGP02.phx.gbl...
| I've used and recommended these tools for several years and I have never
| heard of anyone having damage occur to their hard drives from using them
| although I guess it could be possible. If the NTFS partition is large
| enough, there would be remnants since these tools only clean out enough of
| the partition so fdisk can be used.
|
| I am not clear about what you are trying to test. Are you trying to
recover
| data on a failing drive?
|
| --
| Regards
|
|
| Ron Badour, MS MVP for W98
No, not trying to recover anything except the full hard drive and remove XP
NTFS completely. Consider it like returning the hard drive to it's pristine
state without the contamination and loss of space, and potential failures
which may be caused pursuant the corruption.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
Franc Zabkar
put finger to keyboard and composed:
>BACKGROUND:
> I have presented apparent issues with the re-use of former XP NTFS hard
>drives for other use or re-use. Tools and techniques normally used for
>fdisking and formatting, wiping and other activities, apparently do not
>completely remove XP NTFS from hard drives.
>
>Disks used for testing:
>Maxtor 87000AB - Hard Disk Family DiamondMax 1750A (per Everest)
>Per early test (WinHex) on the Maxtor:
>Hard disk 1
>Total capacity: 7,003,586,560 bytes = 6.5 GB
>Number of cylinders: 851
>Number of heads: 255
>Sectors per track: 63
>Bytes per sector: 512
>Sector count: 13,678,880
This is the drive's native capacity in LBA mode.
>Surplus sectors at end: 7,565
This is the drive's unusable capacity when it is configured in CHS
mode.
13678880 = (851 x 255 x 63) + 7565
LBA mode = CHS mode + surplus
>Partition 1
>Sectors 63 - 13,655,249
13655250 = 850 x 255 x 63 = total CHS capacity - one cylinder
It appears that Fdisk (?) reserves the last cylinder, probably for
compatibility purposes. Some older systems placed a defect map there.
See http://www.tldp.org/HOWTO/Large-Disk-HOWTO-6.html
>Partition table: Sector 0
>File system: FAT32
>Total capacity: 6,991,455,744 bytes = 6.5 GB
>Sector count: 13,655,187
>Usable sectors: 13,628,528
>First data sector: 26,652
>Bytes per sector: 512
>Bytes per cluster: 4,096
>Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
>Total clusters: 1,703,566
>Unused inter-partition space:
>Sectors 1 - 62 (31.0 KB)
This is the first track. It is unused because FAT partitions must
start and finish on a track boundary.
>Sectors 13,655,250 - 13,678,879 (11.5 MB) = 11.6 MB
= capacity of last reserved cylinder + surplus sectors
= (255 x 63) + 7565 sectors
>A recent test shows:
>Hard disk 1
>
>Total capacity: 7,003,586,560 bytes = 6.5 GB
>
>Number of cylinders: 851
>Number of heads: 255
>Sectors per track: 63
>Bytes per sector: 512
>Sector count: 13,678,880
>Surplus sectors at end: 7,565
>
>Partition 1
>Sectors 63 - 13,639,184
This is reduced from the previous case by 16065 (= 255 x 63) sectors.
This amounts to a loss of one additional cylinder. Has Fdisk become
confused by the existing partition table and erroneously reserved an
extra track?
>Partition table: Sector 0
>File system: ?
>Total capacity: 6,983,230,464 bytes = 6.5 GB
>Sector count: 13,639,122
= 13639185 - 63
>Bytes per sector: 512
>
>Unused inter-partition space:
>Sectors 1 - 62 (31.0 KB)
>Sectors 13,639,185 - 13,678,879 (19.4 MB)
>= 19.4 MB
= capacity of 2 reserved cylinders + surplus sectors
I don't think you are seeing any NTFS/Win XP issue. Instead it appears
that the drive's capacity is being reduced by some combination of
"soft" events.
Jeff Richards
> snip <
>
> There are hundreds (thousands) of web pages which appear to claim XP NTFS
> is capable of being removed via old techniques and tools.
> My testing (to date) shows this in not true. Several hundred megabytes of
> hard drive space (on these small hard drives, who knows how much on larger
> drives) still contain files and folders from an XP NTFS installation after
> its removal.
You are addressing an issue completely different than the original topic. No
part of that discussion referred to removing all trace of NTFS. The point
of recommending ZAP or WIPE was to enable Windows 98 FDISK to work. Nothing
you have mentioned here indicates in any way that ZAP or WIPE will not work
for that purpose, or will damage the disk in any way. Check the description
for these utilities - they both clearly specifiy exactly how much of the
disk gets overwritten. In terms of current disk sizes, it's not much. But it
is enough to enable FDISK to partition the disk as FAT32, which was the
point of the original query.
The fact that recovery utilities can see part of the old NTFS data after
running something like ZAP or WIPE is simply not relevant. They will
probably still be able to see the data after FDISK has partitioned the
drive, and possibly even after it's formatted (depending on the options
used). This old, recoverable data has absolutely no impact on subsequent
use of the disk. It will get overwritten as the disk fills up.
I suspect the problems you are seeing are due to data recovery or disk
inspection tools you are using which are somehow protecting data that
appears to be recoverable. Without knowing the exact sequence of utilities
you used it's impossible to say what has happened. But I have many disks
scattered around many different clients that have had NTFS removed as part
of the process of reconditioning second hand-machines, and I have never had
any problems getting access to the full capacity of the disk. Provided, of
course, I configured them correctly and used a file system that was capable
of accessing that capacity.
And to suggest that no results to your searching proves that there's a
conspiracy to keep the problem quiet is just nonsense.
Jonny
Yes there are software tools for finding files after the mbr and partition
(along with the file system table) are wiped. Writing zeroes to the entire
drive has been adequate for me using the utility from the hard drive maker.
There's others that go beyond that and write zeroes and ones multiple times.
--
Jonny
real@hotmail.com MEB
information on http://www.win.tue.nl/~aeb/linux/ BTW, though it's too soon
for Linux in this discussion; other was known or already used/viewed; one
page was not yet created];
However you fail to address:
| >Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
That's a 10% differential of disk space.
Let's see where it might be:
"Tree statistic: 395 directories, 579 files, 831 KB (the kb is the
directories, not total file kb)
can still be attempted at recovery (and yes, many CAN be viewed,
" except for the encrypted/compressed files)""
INTACT files which show their original untouched names, in their original
directories (now corrupt), and holding their same locations on the hard
drive. Unmovable, unremovable - they are apparently protected from erasure.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:bidjh2dn5t4b250rl...@4ax.com...
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:u%23Ixnih...@TK2MSFTNGP02.phx.gbl...
I note you state you have disks laying around which have been wiped for
re-use.
Could you use forensic tools to look for compressed and encrypted files on
those disks?
I know that's a lot to ask, your day is probably full, but it would be
instrumental in my research, and this thread.
Make sure the tool or tools have access to the full disk and are NOT
limited by supposed $ BAD SECTOR $ classifications, such as would be created
during fdisking and formatting, and scandisking after a "wipe".
Jeff Richards
them to do just that. I know that some tools will be able to identify the
original partitioning as NTFS, because they can recognise certain
signatures. But I also know, because I've already done it, that when the
disk is partitioned I will get full access.
And I also know that after using ZAP or WIPE and then FDISK and Format I
will sometimes get bad sectors reported. That's what I expected, since in
those cases the reason for rebuilding the disk was that the manufacturer's
diagnostic told me that there were bad sectors developing. And that's why
some of these disks are lying around here (including a near new Maxtor 80Gb
that's going back under warranty). But the bad sectors had nothing to do
with the attempts that I made at recovery. They were there before I started,
although not always reported to the operating system as such.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:ed1d$mk4GH...@TK2MSFTNGP04.phx.gbl...
real@hotmail.com MEB
Look again below then re-think what you presented.
"Jonny" <spamyo...@blackworm.net> wrote in message
news:O1GyDKk...@TK2MSFTNGP06.phx.gbl...
| "MEB" <meb@not re...@hotmail.com> wrote in message
| news:OeQ5Ura4...@TK2MSFTNGP03.phx.gbl...
| > SYNOPSIS:
| >
| > This is a collected discussion concerning XP hard drive re-use, in which
I
| > have personally participated, per [there may be others which I have
| > missed]:
| >
| > "Re: IBM T22 and Win 98se";
| > "Re: New post, ms Everest report";
| > "Re: Hangs on POST screen";
| > "Re: win 98 installation"
| > "Re: Updates for Win9X's & reason/logic"
| > "Re: No hard drive?"
| > "Re: Unable to install Win98 SE"
| > "Re: PC100 v PC133 ram"
| >
[slashed information]
[slashed information]
| > No, not trying to recover anything except the full hard drive and remove
| > XP
| > NTFS completely. Consider it like returning the hard drive to it's
| > pristine
| > state without the contamination and loss of space, and potential
failures
| > which may be caused pursuant the corruption.
| >
| > --
| > MEB
| > _______________
| >
| >
|
| Yes there are software tools for finding files after the mbr and partition
| (along with the file system table) are wiped. Writing zeroes to the
entire
| drive has been adequate for me using the utility from the hard drive
maker.
| There's others that go beyond that and write zeroes and ones multiple
times.
| --
| Jonny
|
|
I think you'll find that those tools I referenced do exactly as you've
stated and far more.
Unless you've done a forensic analysis of the disk(s) (that's actually
check it), you know no more that what you BELIEVE to be true, quite possibly
what you read somewhere as well.
Think of it like "there are weapons of mass destruction in Iraq" and "they
are months away from nuclear weapons". It's about as accurate.
real@hotmail.com MEB
them. Now we're getting somewhere.
Merely finding full hard drive space means relatively little, since there
are reserved sectors for S.M.A.R.T. activity AND other
scandisk/fdisk/format like activities. The disk will use these areas
attempting to replace inaccessible areas of the disk. That does NOT mean
they are bad, just inaccessible.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:%23P1er4n...@TK2MSFTNGP04.phx.gbl...
Franc Zabkar
put finger to keyboard and composed:
> However you fail to address:
>| >Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
>That's a 10% differential of disk space.
> Let's see where it might be:
>"Tree statistic: 395 directories, 579 files, 831 KB (the kb is the
>directories, not total file kb)
>can still be attempted at recovery (and yes, many CAN be viewed,
>" except for the encrypted/compressed files)""
> INTACT files which show their original untouched names, in their original
>directories (now corrupt), and holding their same locations on the hard
>drive. Unmovable, unremovable - they are apparently protected from erasure.
I have no experience with NTFS or Windows XP, but I wonder if XP is
able to make use of the drive's full capacity by using LBA mode rather
than CHS. This would mean that data would eventually be written to
those logical blocks (aka sectors) at the tail end of the disc. These
sectors would be invisible to any OS that restricted itself to CHS
mode, or which honoured any BIOS imposed limitation. However, a
forensic sector editor would still be able to read them.
I don't understand how 10% of the disc could become inaccessible,
though.
I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
well as the CHS numbers in an MBRtool report. If you can post the
actual raw contents of the partition table, then that may be
interesting, too.
This is how my 13GB HD looks:
http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/dcb5670fdeadb6df?dmode=source&hl=en
Note that I have yet to partition the last half of my drive. I'm
reserving this area for Linux ... if I ever get around to it.
Franc Zabkar
put finger to keyboard and composed:
>Hard disk 1
>Total capacity: 7,003,586,560 bytes = 6.5 GB
>Number of cylinders: 851
>Number of heads: 255
>Sectors per track: 63
>Bytes per sector: 512
>Sector count: 13,678,880
>Surplus sectors at end: 7,565
>Partition 1
>Sectors 63 - 13,655,249
>Partition table: Sector 0
>File system: FAT32
I've checked two of my PCs. Neither has ever seen NTFS or Win XP, yet
the hard drives in both machines show a usable capacity that is
slightly less than their native capacity. In all cases it is the BIOS
(not Fdisk, sorry) that reserves the last cylinder for its own use,
whatever that may be. In addition, there is the loss of the surplus
sectors that result from the translation to CHS mode. This is because
the BIOS tries to fit the drive's geometry into 1024 cylinders or
less. In so doing, the last cylinder is often only partially filled,
so its surplus sectors are discarded. The next full cylinder is then
reserved.
In short, I see the same behaviour in a DOS/Win9x system, so it is
clearly not an XP/NTFS phenomenon.
BTW, I'm using MBRtool to view the MBR and partition table, both in
raw hex mode and in decoded mode.
http://www.diydatarecovery.nl/downloads/MBRtool.zip
Dan
Interesting Franc. Linux intrigues me as well and I am someday looking
forward to trying it out as well. In addition, I think I will try out
Apple and see how their technology compares since I like to be
well-rounded in technology. The Ipod Mini with Apple is so sweet in my
opinion and I just love having a collection of around 50 songs that were
available for purchase for just a buck a piece.
Dan
down so far and thanks I really appreciate your comments.
real@hotmail.com MEB
Another long one for the discussion (theory)::
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:mgulh2dcg5sil1co9...@4ax.com...
| On Wed, 27 Sep 2006 11:28:37 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| > However you fail to address:
|
| >| >Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
| >That's a 10% differential of disk space.
|
| > Let's see where it might be:
| >"Tree statistic: 395 directories, 579 files, 831 KB (the kb is the
| >directories, not total file kb)
| >can still be attempted at recovery (and yes, many CAN be viewed,
| >" except for the encrypted/compressed files)""
| > INTACT files which show their original untouched names, in their
original
| >directories (now corrupt), and holding their same locations on the hard
| >drive. Unmovable, unremovable - they are apparently protected from
erasure.
|
| I have no experience with NTFS or Windows XP, but I wonder if XP is
| able to make use of the drive's full capacity by using LBA mode rather
| than CHS. This would mean that data would eventually be written to
| those logical blocks (aka sectors) at the tail end of the disc. These
| sectors would be invisible to any OS that restricted itself to CHS
| mode, or which honoured any BIOS imposed limitation. However, a
| forensic sector editor would still be able to read them.
My guess would be as you suggest, XP NTFS makes full use of the disk and
then some.
CHS changes are made when installing the OS, by the OS.
--
Yes, a quality forensic editor can access and read the extra sectors. You
can even change the CHS within some of them beyond the disk's stated
capacity, hence every part of the disk is potentially accessible.
|
| I don't understand how 10% of the disc could become inaccessible,
| though.
Remember we're dealing with a small hard drive. Were this a 30 gig or more,
would we really notice 5 or 7 hundred megs of lost space? On a 300+ gig,
would we really notice loss of a gig. Particularly as most tools would show
these areas as "bad sectors" because they couldn't access them.
Think of it like this:
These are mostly DOS based tools. DOS can NOT read or recognize dozens of
file systems, partitions, file types, etc., everyone knows that.
The other tools created to address these activities (wiping, formatting,
fdisking, etc) base their information and coding on known partition types,
and file (system) "indicators" (hex coding if you will). Many of them
respect BIOS limitations, CHS, and HPA.
What happens when they attempt to access unknown files, partitions, filing
systems, or file indicators?
Let's pull some information from a related activity.
From the "Eraser 5.8" (http://www.heidi.ie/eraser/ -
http://www.tolvanen.com/sami/) help file (a nice little erasing tool BTW):
__ QUOTE (excerpt)__
The special cases when erasing data by overwriting may not be desirable when
alternative methods should be used or when there are important matters that
need to be considered first are discussed here.
Compressed Files
You can safely erase files compressed at the file system level (file
compression requires a file system that supports it, such as NTFS). When
erasing compressed files on Windows NT or 2000, Administrator privileges are
required for low-level disk access.
Files compressed with an external application, such as ZIP files, can
naturally be erased.
If you are erasing files from a partition compressed with external
compression software (such as DriveSpace), use only pseudorandom data for
overwriting.
Compressed Drives
Files and unused space on a compressed NTFS partition can be erased
normally.
However, if your partition is compressed with external compression software
(such as DriveSpace), the following details should be considered. In
general, one should avoid storing sensitive data on a partition compressed
with external software.
Turn off cluster tip erasing for partitions that are compressed with
external software, erasing cluster tips will confuse the application that
handles the compressing and may result to dramatic loss of disk space. If
you erased cluster tips on a compressed drive and lost significant amount of
disk space, you must recompress the drive to restore the lost space.
You should use only pseudorandom data when overwriting unused space on a
partition compressed with external software, the other methods include
passes that are of highly compressible data and should not be used. Your
computer may slow down and even stop responding because the written data is
being compressed.
Files saved on the compressed drive can also be overwritten taking the
aforementioned matters into consideration.
Encrypted Files
You can safely erase files encrypted at the file system level (file
compression requires a file system that supports it). Files encrypted with
an external application, such as Pretty Good Privacy (PGP), can be erased as
well.
As the data is already stored in unreadable format, erasing is not required,
but usually increases security.
Encrypted Drives
In general, one should not erase the unused disk space on an encrypted drive
(the same applies to encrypted virtual drives, such as the ones created by
PGPDisk, ScramDisk or E4M).
The erasing will be useless because the data saved on the drive is encrypted
into unreadable format, erasing may slow down your computer and it may even
stop responding, depending on the driver that handles encryption.
Files on the encrypted drives can be overwritten, but this should be avoided
because of the reasons mentioned above.
_--END QUOTE
Pursuant the above, the "ORIGINAL SYSTEM OR PROGRAM" must/should be used
to access compressed and or encrypted data areas.
A somewhat misleading statement indicates "compressed NTFS partition can be
erased normally." The other statements must be taken into account. They may
be address "normally" THROUGH the ORIGINAL/CREATING operating system/program
(save special circumstances), so the other statements must be read as
including necessity of XP system to address XP partitions/ hidden/
protected/ encrypted/ compressed hard drives and various areas XP NTFS
creates. It also states: "Administrator privileges are required for
low-level disk access." so the system monitors access. Or is it something
else?
ERASER is a Windows program for both 98 and XP, hence when used in XP it
can address these areas of the disk BECAUSE it is working within the
"creator" environment.
Note this: " If you erased cluster tips on a compressed drive and lost
significant amount of disk space, you must recompress the drive to restore
the lost space."
So what is it we have been doing with all these DOS based tools?
http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm for fdisk
http://mirror.href.com/thestarman/asm/mbr/FORMAT98.htm for format
http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm for boot record/sector
http://mirror.href.com/thestarman/asm/mbr/95BMEMBR.htm for MBR
Let's say not the whole disk is compressed (though it basically is in
NTFS), but only certain areas of the disk. What happens when we attempt to
remove them normally? What happens if more than one compression and or
encryption scheme is used within the disk, e.g. compression within
compression or encryption within compression?
Now what happens if HPA is involved in protecting certain areas of the
disk, such as some of those compressed areas or files?
Now what happens when we use tools that "don't know Jack" about what XP
NTFS has done to the disk?
Perhaps now you can grasp why I'd like that information on XP NTFS.
|
| I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
| well as the CHS numbers in an MBRtool report. If you can post the
| actual raw contents of the partition table, then that may be
| interesting, too.
Most of that will not be worth anything.
If you have used these tools, you know everything (except the BIOS HD
SCREEN) you just asked for has already been modified extensively, many times
over. [The web pages will show some of the activity when they are created.]
Meandisk, for instance, uses the DEBUG MBR reset for the disk in addition
to it's complete zero wipe (which doesn't work).
The only thing of any real value would be the $Mft tables (that are still
intact) and one of the backup boot sectors. However, the backup boot and
partition table have also been changed.
Or have they?
Running TESTDISK !Search (extended search - searches the entire disk) pulls
up the NTFS partition information. However, placing that info as the
partition, causes the disk to extend far beyond it's stated CHS capacity. So
perhaps LBA is used>>> in non-standard areas of the disk.
The first few times a backup partition table was used or viewed, it was
similar to the CHS of the disk, except for one cylinder less. That was wiped
by one of the tools, yet this other one still pops up.
Using a disk editor shows a large amount of information stored beyond the
CHS end boundary of the disk, including what appears to be a partition table
and a boot sector.<grin>
|
| This is how my 13GB HD looks:
|
http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/dcb5670fdeadb6df?dmode=source&hl=en
|
| Note that I have yet to partition the last half of my drive. I'm
| reserving this area for Linux ... if I ever get around to it.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
Well I commend you on installing Linux. Once you get used to it,
particularly if you liked command mode DOS, you will like it. A very
powerful OS. Still a little lacking on "Window like glitse", but it's users
love it largely because it doesn't "dumb you down". I think you will too.
Dan
It certainly seems that Linux is an operating system that I should
install on this machine. Anyway, thanks for the input MEB. Wow, I
sometimes wonder if the 98 general newsgroup has one of the most
technical newsgroups that is out there within the Microsoft newsgroups.
Dan
> Johnny, please snip when the posts get super long. It get old scrolling
> down so far and thanks I really appreciate your comments.
pasting some of the vgx.dll file to this newsgroup and I was unsuccessful.
Jeff Richards
matters. In most any large capacity drive the firmware will have remapped
some reserved sectors over identified bad sectors, and that might tell you
something about the health of the drive in the same way that the SMART
reporting tools can reveal similar detail. It's not relevant to your claim
that clearing the first few sectors of the drive is not sufficient to force
NTFS to give back all the space originally allocated to it.
Scandisk and Format operate at the file system level, and any bad sector
identification they do is relevant to the file system only. Other utilities
can make more permanent identification of bad or suspect sectors, and in
some cases these can cause problems. Some procedures for marking suspect
sectors as bad interferes with the inbuilt sector remapping routines and
causes the disk to use up all its reserved sectors trying to restore
corrupted sectors that never were really bad in the first place. This is
the result of using unsuitable tools, and has nothing to do with XP or NTFS.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:eL5i$Jo4GH...@TK2MSFTNGP04.phx.gbl...
Jonny
A couple of years back, noticed similar symptom when simply changing from
auto to user settings for the only hard drive onboard. I did not change the
"user" settings it provided in the switch. The layout change was
significant enough for filename change problems and so forth. Award bios.
Think you're on to something.
--
Jonny
Jonny
The only "tools" I've used are the MS ones, and those provided by WD
website, the IBM tools, and Maxtors. The ITs in the US Navy told me about a
program that they used to clean hard drives (multiple zeroes and ones).
All I know is from my own experiences, hands on stuff. That is what I deem
most true for myself. I suspect that may be true for you as well.
--
Jonny
real@hotmail.com MEB
"Jonny" <spamyo...@blackworm.net> wrote in message
news:e5Qgicw...@TK2MSFTNGP06.phx.gbl...
| "MEB" <meb@not re...@hotmail.com> wrote in message
| news:%23PyPOFo...@TK2MSFTNGP02.phx.gbl...
| >
| >
| > Look again below then re-think what you presented.
| >
| > "Jonny" <spamyo...@blackworm.net> wrote in message
| > news:O1GyDKk...@TK2MSFTNGP06.phx.gbl...
| > | "MEB" <meb@not re...@hotmail.com> wrote in message
| > | news:OeQ5Ura4...@TK2MSFTNGP03.phx.gbl...
| > | > SYNOPSIS:
| > | >
Obviously I would have to agree, our experiences form our opinions on most
of what we believe. It isn't until we challenge those beliefs and opinions
that we can really expand our knowledge.
I would presume that what you were directed to by the Navy ITs (depending
upon the time period) revolved around tools which complied with wiping
standards such as:
One pass zeros
One pass random
US DoD 5220.22M
US DoD 5200.28
German VSITR
Russian GOST p-50739-95
Gutmann
or modifications of these or others.
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:u6tt8hu4...@TK2MSFTNGP05.phx.gbl...
| Finding the correct hard drive space (total number of sectors) is all that
| matters. In most any large capacity drive the firmware will have remapped
| some reserved sectors over identified bad sectors, and that might tell you
| something about the health of the drive in the same way that the SMART
| reporting tools can reveal similar detail. It's not relevant to your
claim
| that clearing the first few sectors of the drive is not sufficient to
force
| NTFS to give back all the space originally allocated to it.
Really,, the health huh, when some of these are apparently the files that
are created during XPs Restore Point activities.
When some of these are apparently the files created when XP backs itself up.
When some of these are apparently the protected HIVES.
When some of these are apparently from the protected system areas.
|
| Scandisk and Format operate at the file system level, and any bad sector
| identification they do is relevant to the file system only. Other
utilities
| can make more permanent identification of bad or suspect sectors, and in
| some cases these can cause problems. Some procedures for marking suspect
| sectors as bad interferes with the inbuilt sector remapping routines and
| causes the disk to use up all its reserved sectors trying to restore
| corrupted sectors that never were really bad in the first place. This is
| the result of using unsuitable tools, and has nothing to do with XP or
NTFS.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
Sure they're not... best check again.
So you really never did any forensic reviews on the bad sectors created
after using DOS tools, right.
Pull those disks out and check them. I'd love to see I'm wrong, and I may
be.
I'm fully prepared to apologize to the world if necessary, are you?
Don't take this wrong. I'm not demeaning you, or acting facetious, I am
truly concerned with this, if this is what is occurring.
| "MEB" <meb@not re...@hotmail.com> wrote in message
| news:eL5i$Jo4GH...@TK2MSFTNGP04.phx.gbl...
| > Well fine, then you do have disks available, use a quality forensic tool
| > on
| > them. Now we're getting somewhere.
| >
| > Merely finding full hard drive space means relatively little, since
there
| > are reserved sectors for S.M.A.R.T. activity AND other
| > scandisk/fdisk/format like activities. The disk will use these areas
| > attempting to replace inaccessible areas of the disk. That does NOT mean
| > they are bad, just inaccessible.
| >
| > --
| > MEB
| > _______________
| >
| > "Jeff Richards" <JRic...@msn.com.au> wrote in message
| > news:%23P1er4n...@TK2MSFTNGP04.phx.gbl...
| > | Jeff Richards
| > | MS MVP (Windows - Shell/User)
| > | "MEB" <meb@not re...@hotmail.com> wrote in message
| > | news:ed1d$mk4GH...@TK2MSFTNGP04.phx.gbl...
| > | >
| > | >
| > | > "Jeff Richards" <JRic...@msn.com.au> wrote in message
| > | > news:u%23Ixnih...@TK2MSFTNGP02.phx.gbl...
| > | > | "MEB" <meb@not re...@hotmail.com> wrote in message
| > | > | news:OeQ5Ura4...@TK2MSFTNGP03.phx.gbl...
| > | > | > snip <
| > | > |
| > | > | And to suggest that no results to your searching proves that
there's
| > a
| > | > | conspiracy to keep the problem quiet is just nonsense.
| > | > | --
| > | > | Jeff Richards
| > | > | MS MVP (Windows - Shell/User)
| > | >
| > | > I note you state you have disks laying around which have been wiped
| > for
| > | > re-use.
| > | > Could you use forensic tools to look for compressed and encrypted
| > files
| > on
| > | > those disks?
| > | > I know that's a lot to ask, your day is probably full, but it would
be
| > | > instrumental in my research, and this thread.
| > | > Make sure the tool or tools have access to the full disk and are NOT
| > | > limited by supposed $ BAD SECTOR $ classifications, such as would be
| > | > created
| > | > during fdisking and formatting, and scandisking after a "wipe".
| > | >
| > | > --
| > | > MEB
| > | > _______________
Franc Zabkar
<fza...@iinternode.on.net> put finger to keyboard and composed:
>I've checked two of my PCs. Neither has ever seen NTFS or Win XP, yet
>the hard drives in both machines show a usable capacity that is
>slightly less than their native capacity. In all cases it is the BIOS
>(not Fdisk, sorry) that reserves the last cylinder for its own use,
>whatever that may be. In addition, there is the loss of the surplus
>sectors that result from the translation to CHS mode. This is because
>the BIOS tries to fit the drive's geometry into 1024 cylinders or
>less. In so doing, the last cylinder is often only partially filled,
>so its surplus sectors are discarded. The next full cylinder is then
>reserved.
I've just checked my third PC with an AMI BIOS dated 03/13/03. Unlike
earlier BIOSes (1999, 1996), the BIOS in this machine does not reserve
the last cylinder. Therefore Win98SE is able to see the drive's full
capacity (apart from the surplus sectors).
Franc Zabkar
put finger to keyboard and composed:
>Another long one for the discussion (theory)::
With respect, I'm still convinced that you've created a problem where
there originally was none. I say this because in your first post in
this thread you have failed to notice that your BIOS has reserved the
last cylinder of your HD. Instead you've blamed XP/NTFS for this
reduced capacity. I suspect that you may have then used various
forensic utilities in a fruitless attempt to recover this space,
resulting in additional loss.
As to why you have not been able to get Zap or Wipe to restore your
drive to its original pristine condition, I can only speculate.
Perhaps you have attempted to run these utilities inside a Windows DOS
box? Maybe these old IBM (?) utilities have problems with modern
non-IBM drives or BIOSes? For example, some 15 years ago I used
Seagate's Find-ATA utility to retrieve the specs for 40MB IDE drives.
Today the same utility produces a screen with garbled output, even for
a Seagate HD.
On the question of your 10% loss of free space, I can only speculate
that Winhex has done its best to make sense of a file system that has
been damaged by Fdisk. A clue may lie at this URL which you provided
earlier:
http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm
The author writes that the first "Verifying Drive Integrity" process
"writes to and verifies sectors full of F6 bytes on your hard drive;
... These 'F6 sectors' are written to the 1st and 7th sectors of each
'Head' number (except for Head 0) until a calculated number of sectors
(depending upon the size of the partition) at the beginning of the
drive (or partition) have been 'verified' by FDISK."
Elsewhere ...
http://mirror.href.com/thestarman/asm/mbr/FORMAT98.htm
http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm
... the author states that the Format command writes the FSinfo data
to sectors 2 and 8 of the first track. The FSinfo sector keeps track
of the number of "Free Clusters on Disk". The File Access Table (FAT)
tracks the usage of each cluster, ie it knows which clusters are free
and which are in use. So it would be easy for a utility (eg Scandisk)
to check whether the amount of free disc space is being correctly
reported. It could do this by scanning the FAT for free clusters and
comparing what it finds with the total recorded in the FSInfo sector.
In fact Scandisk invariably reports a free space mismatch error on my
HD after a crash. In your case you would expect a mismatch because the
1st and 7th sectors of every track that falls within your FATs would
have been "F6-ed" by Fdisk.
As for why a forensic utility can still see your old file data, I
think it is because a standard Format is essentially non-destructive.
The format process first verifies that every sector can be read, and
then writes the boot sectors, FATs, and root directory. The data area
is not disturbed. A destructive "unconditional" format, ie one that
writes F6 to every sector of the partition, requires the /u switch:
format c: /u
>The other tools created to address these activities (wiping, formatting,
>fdisking, etc) base their information and coding on known partition types,
I doubt that a wipe utility would care about partition types. Instead
I would think that it would treat the entire disc as raw physical
sectors.
> What happens when they attempt to access unknown files, partitions, filing
>systems, or file indicators?
>
> Let's pull some information from a related activity.
>
> From the "Eraser 5.8" (http://www.heidi.ie/eraser/ -
>http://www.tolvanen.com/sami/) help file (a nice little erasing tool BTW):
I would think that compression and encryption happen at the OS level.
I can't see how they would impact on the hard disc at the sector
level.
> Pursuant the above, the "ORIGINAL SYSTEM OR PROGRAM" must/should be used
>to access compressed and or encrypted data areas.
I still can't see why zeroing physical sector 0 would not be
sufficient to reclaim this space.
> So what is it we have been doing with all these DOS based tools?
>http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm for fdisk
>http://mirror.href.com/thestarman/asm/mbr/FORMAT98.htm for format
>http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm for boot record/sector
>http://mirror.href.com/thestarman/asm/mbr/95BMEMBR.htm for MBR
The author of these pages has done some great detective work. Thanks
for the links.
> Now what happens if HPA is involved in protecting certain areas of the
>disk, such as some of those compressed areas or files?
If the BIOS can see the whole disc (apart from one reserved cylinder),
then isn't that enough to tell you that its capacity is not being
clipped by some entry in the HPA?
> Now what happens when we use tools that "don't know Jack" about what XP
>NTFS has done to the disk?
Have you examined the HPA? Have you found any evidence that anything
has been done? If so, what?
>Perhaps now you can grasp why I'd like that information on XP NTFS.
>
>|
>| I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
>| well as the CHS numbers in an MBRtool report. If you can post the
>| actual raw contents of the partition table, then that may be
>| interesting, too.
>
> Most of that will not be worth anything.
Why not? At the very least it will tell you what capacity the BIOS
sees. That's where the boot process begins. The next most important
thing is the partition table. If the latter has less sectors than
reported by BIOS, then that may tell you something. At the very least
it gives us a point of reference.
> If you have used these tools, you know everything (except the BIOS HD
>SCREEN) you just asked for has already been modified extensively, many times
>over. [The web pages will show some of the activity when they are created.]
> Meandisk, for instance, uses the DEBUG MBR reset for the disk in addition
>to it's complete zero wipe (which doesn't work).
Are you saying that physical sector 0 cannot be erased? Are you trying
to do this within a Windows DOS box?
> The only thing of any real value would be the $Mft tables (that are still
>intact) and one of the backup boot sectors. However, the backup boot and
>partition table have also been changed.
> Or have they?
> Running TESTDISK !Search (extended search - searches the entire disk) pulls
>up the NTFS partition information. However, placing that info as the
>partition, causes the disk to extend far beyond it's stated CHS capacity. So
>perhaps LBA is used>>> in non-standard areas of the disk.
Does TESTDISK's NTFS partition information correctly reflect the
native capacity of the HD as specified by its manufacturer? Have you
accounted for a reserved cylinder and/or surplus sectors?
> The first few times a backup partition table was used or viewed, it was
>similar to the CHS of the disk, except for one cylinder less. That was wiped
>by one of the tools, yet this other one still pops up.
>
> Using a disk editor shows a large amount of information stored beyond the
>CHS end boundary of the disk, including what appears to be a partition table
>and a boot sector.<grin>
Are you seeing a wrap-around effect? If you make changes to the MBR
code or to the partition table, do these changes also appear at the
end of the disc? For example, change one of the text strings from
"system" to "System" and see what happens.
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:jq0nh253bgl0m5bit...@4ax.com...
Gotcha, thanks for the info..
Both of mine have Award BIOSs. It's important to know, but I'm looking at
the actual physical disk sectors.
BTW, don't be offended by the other post, because ultimately, if any one
bothers to actually test a disk for the discussion, we are going to have to
compare disk instruction sets as well as sector analysis.
Here's some more info you may not have:
AEFDISK INFO EXCERPT
Partition Information
ID Name
ÄÄ ÄÄÄÄ
00h empty
01h DOS 12-bit FAT
02h XENIX root file system
03h XENIX /usr file system (obsolete)
04h DOS 16-bit FAT (up to 32M)
05h DOS 3.3+ extended partition
06h DOS 3.31+ Large File System (16-bit FAT, over 32M)
07h QNX
07h OS/2 HPFS
07h Windows NT NTFS
07h Advanced Unix
08h OS/2 (v1.0-1.3 only)
08h AIX bootable partition, SplitDrive
08h SplitDrive
08h Commodore DOS
08h DELL partition spanning multiple drives
08h QNX 1.x and 2.x
09h AIX data partition
09h Coherent filesystem
09h QNX 1.x and 2.x
0Ah OS/2 Boot Manager
0Ah OPUS
0Ah Coherent swap partition
0Bh Windows 95 OSR2 with 32-bit FAT
0Ch Windows 95 OSR2 with 32-bit FAT (LBA-mode INT 13 extensions)
0Eh LBA VFAT (same as 06h but using LBA-mode INT 13)
0Fh LBA VFAT (same as 05h but using LBA-mode INT 13)
10h OPUS
11h Hidden 12-bit FAT partition, OS/2 FAT12
12h Compaq/HP Diagnostics partition (FAT compatible)
14h (using Novell DOS 7.0 FDISK to delete Linux Native part)
14h Hidden sub-32M 16-bit FAT partition
16h Hidden over-32M 16-bit FAT partition
17h Hidden HPFS partition
18h AST special Windows swap file
19h Willowtech partition
1Bh Hidden Windows 95 with 32-bit FAT
1Ch Hidden Windows 95 with 32-bit LBA FAT
1Eh Hidden Windows 95 with LBA BIGDOS
20h OFS1
21h officially listed as reserved, FSo2
23h officially listed as reserved
24h NEC DOS 3.x
26h officially listed as reserved
31h officially listed as reserved
33h officially listed as reserved
34h officially listed as reserved
36h officially listed as reserved
38h Theos v3.2 2GB partition
39h Theos v4 spanned partition
3Ah Theos v4 4GB partition
3Bh Theos v4 extended partition
3Ch PowerQuest PartitionMagic recovery partition
40h VENIX 80286
41h Personal RISC Boot
41h Power PC Reference Platform Boot
42h SFS (Secure File System) by Peter Gutmann
45h EUMEL/Elan
46h EUMEL/Elan
47h EUMEL/Elan
48h EUMEL/Elan
4Dh QNX4.x
4Eh QNX4.x 2nd part
4Fh QNX4.x 3rd part
4Fh Oberon
50h OnTrack Disk Manager, read-only partition
51h OnTrack Disk Manager, read/write partition
51h NOVELL
52h CP/M
52h Microport System V/386
53h OnTrack Disk Manager, write-only partition???
54h OnTrack Disk Manager (DDO)
55h EZ-Drive
56h GoldenBow VFeature
56h DM converted to EZ-BIOS
57h DrivePro
5Ch Priam EDisk
61h SpeedStor
63h Unix SysV/386, 386/ix
63h Mach, MtXinu BSD 4.3 on Mach
63h GNU HURD
64h PC-ARMOUR protected partition
64h Novell NetWare 2.xx
65h Novell NetWare 3.xx or 4.xx
67h Novell
68h Novell
69h Novell
70h DiskSecure Multi-Boot
71h officially listed as reserved
73h officially listed as reserved
74h officially listed as reserved
75h IBM PC/IX
76h officially listed as reserved
7Eh F.I.X
80h Minix v1.1 - 1.4a
81h Minix v1.4b+
81h Linux
81h Mitac Advanced Disk Manager
82h Linux Swap partition
82h Prime
82h Solaris x86
83h Linux native file system (ext2fs/xiafs)
84h OS/2-renumbered type 04h partition (hiding DOS C: drive)
84h Hibernation partition
85h Linux extended partition
86h NTFS volume set
87h HPFS Fault-Tolerant mirrored partition
8Ah Linux Kernel Partition (used by AiR-BOOT)
8Eh Linux Logical Volume Manager partition
92h Amoeba
93h Amoeba file system
94h Amoeba bad block table
99h DCE376 logical drive
A0h IBM Thinkpad hibernation partition / PQMagic
A0h Phoenix NoteBIOS Power Management "Save-to-Disk" partition
A1h officially listed as reserved
A3h officially listed as reserved
A4h officially listed as reserved
A5h FreeBSD, NetBSD, BSD/386
A6h OpenBSD
A7h NEXTSTEP
A9h NetBSD
AAh Olivetti Fat 12 1.44Mb Service Partition
B1h officially listed as reserved
B3h officially listed as reserved
B4h officially listed as reserved
B6h officially listed as reserved
B7h BSDI file system (secondarily swap)
B8h BSDI swap partition (secondarily file system)
BEh Solaris boot partition
C0h CTOS
C0h REAL/32 secure small partition / DR-DOS secondary
C1h DR DOS 6.0 LOGIN.EXE-secured 12-bit FAT partition
C4h DR DOS 6.0 LOGIN.EXE-secured 16-bit FAT partition
C6h DR DOS 6.0 LOGIN.EXE-secured Huge partition
C7h Syrinx Boot
CAh FAT-32 (?)
CBh reserved for DRDOS/secured (FAT32)
CCh reserved for DRDOS/secured (FAT32, LBA)
CEh reserved for DRDOS/secured (FAT16, LBA)
D0h REAL/32 secure big partition
D1h Old Multiuser DOS secured FAT12
D4h Old Multiuser DOS secured FAT16 <32M
D5h Old Multiuser DOS secured extended partition
D6h Old Multiuser DOS secured FAT16 >=32M
D8h CP/M-86
DBh CP/M, Concurrent CP/M, Concurrent DOS
DBh CTOS (Convergent Technologies OS)
DEh Dell diagnostic
DFh RadiSys DTS
E1h SpeedStor 12-bit FAT extended partition
E3h DOS read-only
E3h Storage Dimensions
E4h SpeedStor 16-bit FAT extended partition
E5h officially listed as reserved
E6h officially listed as reserved
EBh BeOS partition
F1h Storage Dimensions
F2h DOS 3.3+ secondary partition
F3h officially listed as reserved
F4h SpeedStor
F4h Storage Dimensions
F5h Prologue multi-volume partition
F6h officially listed as reserved
FDh Linux raid partition
FEh LANstep
FEh IBM PS/2 IML
FFh Xenix bad block table
The main characteristics of the NT file system are described by the boot
record. The file system starts at the location of the boot sector and ends
at this sector plus the sectors in the volume field. The volume is organized
in clusters of multiples of 512 bytes. The start of the volume is associated
with cluster number 0.
Any addressing within the file system is done using the cluster number
instead of a sector number. Any kind of file information is contained in a
structure called Master file table (MFT). The start of the MFT is indicated
by the boot sector's field 1st MFT cluster. The MFT is a database containing
information about every file or directory on the volume. The default size of
an entry in the MFT is 1024 bytes. Each entry describes a file or directory
on the volume (including the MFT itself) and has a record number that equals
the byte position inside the MFT divided by 1024. Each MFT entry consists of
a header and a list of attributes. The attributes describe file names, time
stamps, file sizes, data allocations and more. In the file entry details
view you can inspect any attribute of any MFT entry. Most important
attributes are:
$10 Standard information: contains time stamps and DOS attributes,
$30 File name: contains the file's name for different name spaces (usually
NT's native Unicode file name and DOS compatible DOS file name),
$80 Data: if the entry represents a file, this attribute contains the file's
data.
$90 Index root: if the entry is a directory, this attribute describes the
root of a binary tree in which the directory entries are located,
$A0 Index allocation: if the entry is a directory, this attribute contains a
list of file names.
If the attributes are too large to fit into 1024 bytes, some of them will be
non-resident, meaning the value part the specific attribute will be found
outside of the entry. In this case the outside data allocation will be
described by a run list. A run list is a list of clusters used. When in the
file entry details view you can inspect a non-resident attribute's data by
following a link.
real@hotmail.com MEB
INLINE Caution Hazardous material <grin>
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:cutoh29e7fvk5uciv...@4ax.com...
| On Wed, 27 Sep 2006 22:41:01 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| >Another long one for the discussion (theory)::
|
| With respect, I'm still convinced that you've created a problem where
| there originally was none. I say this because in your first post in
| this thread you have failed to notice that your BIOS has reserved the
| last cylinder of your HD. Instead you've blamed XP/NTFS for this
| reduced capacity. I suspect that you may have then used various
| forensic utilities in a fruitless attempt to recover this space,
| resulting in additional loss.
Sorry Franc, but I have reset the disk to the full capacity many times.
The rest of your statement would be based upon your own false assumptions.
|
| As to why you have not been able to get Zap or Wipe to restore your
| drive to its original pristine condition, I can only speculate.
| Perhaps you have attempted to run these utilities inside a Windows DOS
| box?
You must be nuts or think I'm extremely incompetent.
Which one is it?
Maybe these old IBM (?) utilities have problems with modern
| non-IBM drives or BIOSes? For example, some 15 years ago I used
| Seagate's Find-ATA utility to retrieve the specs for 40MB IDE drives.
| Today the same utility produces a screen with garbled output, even for
| a Seagate HD.
|
Know what you mean there, I used to love Pro View (by McAfee) for disk and
file activities, but tools come and go, you just have to keep pace the best
you can, I guess.
Which old IBM utilities are you talking about, wipe and zap?
I already said they don't work.
| On the question of your 10% loss of free space, I can only speculate
| that Winhex has done its best to make sense of a file system that has
| been damaged by Fdisk. A clue may lie at this URL which you provided
| earlier:
|
| http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm
|
| The author writes that the first "Verifying Drive Integrity" process
| "writes to and verifies sectors full of F6 bytes on your hard drive;
| ... These 'F6 sectors' are written to the 1st and 7th sectors of each
| 'Head' number (except for Head 0) until a calculated number of sectors
| (depending upon the size of the partition) at the beginning of the
| drive (or partition) have been 'verified' by FDISK."
|
| Elsewhere ...
|
| http://mirror.href.com/thestarman/asm/mbr/FORMAT98.htm
| http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm
|
| ... the author states that the Format command writes the FSinfo data
| to sectors 2 and 8 of the first track. The FSinfo sector keeps track
| of the number of "Free Clusters on Disk". The File Access Table (FAT)
| tracks the usage of each cluster, ie it knows which clusters are free
| and which are in use. So it would be easy for a utility (eg Scandisk)
| to check whether the amount of free disc space is being correctly
| reported.
Actually, if you've been paying attention to another thread Re: Everest
Report presntly going on, we just had someone find out how badly a disk can
be screwed up. Let's see what we come up with there, if I can only get PCR
to lay off for a bit without offending him.
As for my disk, since I monitor the activities and occurrences, NO fdisk
has done no more damage than other programs. It's the final resetting of all
this that's going to be the real pain.
It could do this by scanning the FAT for free clusters and
| comparing what it finds with the total recorded in the FSInfo sector.
| In fact Scandisk invariably reports a free space mismatch error on my
| HD after a crash. In your case you would expect a mismatch because the
| 1st and 7th sectors of every track that falls within your FATs would
| have been "F6-ed" by Fdisk.
Good theory, however it's faulty. You haven't checked the other tools
previously referenced, which I had to place into that discussion you thought
to put into that alt.hard drive group did you? Read on before you get upset
or reply.
|
| As for why a forensic utility can still see your old file data, I
| think it is because a standard Format is essentially non-destructive.
| The format process first verifies that every sector can be read, and
| then writes the boot sectors, FATs, and root directory. The data area
| is not disturbed. A destructive "unconditional" format, ie one that
| writes F6 to every sector of the partition, requires the /u switch:
|
| format c: /u
Yeah that's right.
Like I haven't done before. This is a test of DOS and other techniques and
tools.
|
| >The other tools created to address these activities (wiping, formatting,
| >fdisking, etc) base their information and coding on known partition
types,
|
| I doubt that a wipe utility would care about partition types. Instead
| I would think that it would treat the entire disc as raw physical
| sectors.
They try, but only if they recognize them or can access them.
It was actually interesting to watch through the first few tests, now
it's... well have you ever done the same task dozens of times with the same
outcome?
|
| > What happens when they attempt to access unknown files, partitions,
filing
| >systems, or file indicators?
| >
| > Let's pull some information from a related activity.
| >
| > From the "Eraser 5.8" (http://www.heidi.ie/eraser/ -
| >http://www.tolvanen.com/sami/) help file (a nice little erasing tool
BTW):
|
| I would think that compression and encryption happen at the OS level.
| I can't see how they would impact on the hard disc at the sector
| level.
So your ignoring the extended boot and partition table perhaps referenced
by the HPA.
And the "hex values" and changed disk instructions then (HINT).
|
| > Pursuant the above, the "ORIGINAL SYSTEM OR PROGRAM" must/should be
used
| >to access compressed and or encrypted data areas.
|
| I still can't see why zeroing physical sector 0 would not be
| sufficient to reclaim this space.
Because the protected sectors can't be accessed, perhaps?
|
| > So what is it we have been doing with all these DOS based tools?
| >http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm for fdisk
| >http://mirror.href.com/thestarman/asm/mbr/FORMAT98.htm for format
| >http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm for boot
record/sector
| >http://mirror.href.com/thestarman/asm/mbr/95BMEMBR.htm for MBR
|
| The author of these pages has done some great detective work. Thanks
| for the links.
YW. Don't count on more than they present and make sure you understand
EXACTLY what they present.
Then perhaps look around a bit for more info, like how hard drives are made
for instances.
|
| > Now what happens if HPA is involved in protecting certain areas of the
| >disk, such as some of those compressed areas or files?
|
| If the BIOS can see the whole disc (apart from one reserved cylinder),
| then isn't that enough to tell you that its capacity is not being
| clipped by some entry in the HPA?
No, your forgetting LBA and several other things related to hard drives.
|
| > Now what happens when we use tools that "don't know Jack" about what XP
| >NTFS has done to the disk?
|
| Have you examined the HPA? Have you found any evidence that anything
| has been done? If so, what?
Franc, do you have access to any re-formatted XP NTFS disk. I don't care if
you have installed the disk full of programs and an OS. Just use some of
these tools (be careful which ones) and LOOK AT THE DISK FOR NTFS traces.
Or beg, borrow, or steal (it's a saying) a copy of WINHEX and look at the
disk. Version 12.8 is the last one which works in 98 (if that's what your
running), it's 13+ for XP last time I checked. See what it locates for you.
(IT IS EXPENSIVE BTW) You could use the test version I think (is it still
available?).
|
| >Perhaps now you can grasp why I'd like that information on XP NTFS.
| >
| >|
| >| I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
| >| well as the CHS numbers in an MBRtool report. If you can post the
| >| actual raw contents of the partition table, then that may be
| >| interesting, too.
| >
| > Most of that will not be worth anything.
|
| Why not? At the very least it will tell you what capacity the BIOS
| sees. That's where the boot process begins. The next most important
| thing is the partition table. If the latter has less sectors than
| reported by BIOS, then that may tell you something. At the very least
| it gives us a point of reference.
Which one do you want: the present: the one after Meandisk: the one
after.....
Your missing the point, it won't tell you anything that your looking for.
Because after fdisking and formatting the disk is reduced from it's stated
full capacity, which it finds. Scandisk it, and it will be reduced even
more. Hence, it's now around 5.6 gig, which is as far as I'm willing to take
it. It will be difficult enough to recover.
|
| > If you have used these tools, you know everything (except the BIOS HD
| >SCREEN) you just asked for has already been modified extensively, many
times
| >over. [The web pages will show some of the activity when they are
created.]
| > Meandisk, for instance, uses the DEBUG MBR reset for the disk in
addition
| >to it's complete zero wipe (which doesn't work).
|
| Are you saying that physical sector 0 cannot be erased? Are you trying
| to do this within a Windows DOS box?
Are you in love with Windows or something? DOS box, what idiot would use a
DOS box for this type of activity.
Yes it can, and was, MEANDISK rewrote it.
Other programs have changed it. I've changed it following the old "tried and
true" advise. This is a test remember?
IT MAKES NO DIFFERENCE.
|
| > The only thing of any real value would be the $Mft tables (that are
still
| >intact) and one of the backup boot sectors. However, the backup boot and
| >partition table have also been changed.
| > Or have they?
| > Running TESTDISK !Search (extended search - searches the entire disk)
pulls
| >up the NTFS partition information. However, placing that info as the
| >partition, causes the disk to extend far beyond it's stated CHS capacity.
So
| >perhaps LBA is used>>> in non-standard areas of the disk.
|
| Does TESTDISK's NTFS partition information correctly reflect the
| native capacity of the HD as specified by its manufacturer? Have you
| accounted for a reserved cylinder and/or surplus sectors?
Yes
|
| > The first few times a backup partition table was used or viewed, it was
| >similar to the CHS of the disk, except for one cylinder less. That was
wiped
| >by one of the tools, yet this other one still pops up.
LET ME MODIFY THIS PART OF MY PRIOR POST
There apparently is still a Table around the center of the disk as well.
| >
| > Using a disk editor shows a large amount of information stored beyond
the
| >CHS end boundary of the disk, including what appears to be a partition
table
| >and a boot sector.<grin>
|
| Are you seeing a wrap-around effect? If you make changes to the MBR
| code or to the partition table, do these changes also appear at the
| end of the disc? For example, change one of the text strings from
| "system" to "System" and see what happens.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
Franc, if I choose to do so, I can edit the entire friggin disk by hand or
by block replacement. Heck I can make the disk a full 7 gig and beyond, if
that's what I want to look at.
I have both DOS and Windows disk editing and FORENSIC tools, capable of
just about anything, INCLUDING rewriting jump and other instructions on the
disk.
Get it yet?
What are we doing here, fixing the disk or EXPOSING Microsoft's apparent
corruption of hard disks?
I did not ask for help fixing this disk, I asked for the XP NTFS info
(which I need to recover this disk or it's trial and error) and started a
general discussion of related material, and theory, hoping to spark thought
processes.
To be relevant, one would have to have tested at least one disk with a
competent disk tool for some comparison of results.
Using the "tried and true" info, is using the same OLD information which is
mostly irrelevant, it's apparently based upon DOS and the old NT kernel
NTFS.
Now, really want to help? Then test a disk or two so we can compare
results. Heck, I may be wrong.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morphs can offer you the two pills;
Jeff Richards
> are created during XPs Restore Point activities.
> When some of these are apparently the files created when XP backs itself
> up.
> When some of these are apparently the protected HIVES.
> When some of these are apparently from the protected system areas.
>
been thoroughly explained by Franc.
> | Scandisk and Format operate at the file system level, and any bad sector
> | identification they do is relevant to the file system only. Other
> utilities
> | can make more permanent identification of bad or suspect sectors, and in
> | some cases these can cause problems. Some procedures for marking suspect
> | sectors as bad interferes with the inbuilt sector remapping routines and
> | causes the disk to use up all its reserved sectors trying to restore
> | corrupted sectors that never were really bad in the first place. This
> is
> | the result of using unsuitable tools, and has nothing to do with XP or
> NTFS.
> | --
> | Jeff Richards
> | MS MVP (Windows - Shell/User)
>
> Sure they're not... best check again
.
Not WHAT? Not really bad? That's exactly the point I made - there are some
tools that will declare sectors bad when they aren't. If this happens at
the file system level then the flagging goes away when the file system is
removed, and the space is recovered. But if the tool is 'smart' and tries
to make them permanently bad, then (a) it might succeed, and the space is
lost forever or (b) the drive firmware kicks in and tries to remap a
reserved sector, and things can go downhill from there. That's why I
commented that it is possible for these types of uutilities to 'damage' a
disk. ZAP and Wipe are not that 'smart', but in any case the issue has
nothing to do with NTFS. It's a problem of using the wrong tool..
I have seen a similar thing happen when the drive was badly configured and
two utilities got extremely confused about how many sectors, tracks and
heads there were (sectors was the critical one, IIRC). This can also happen
if overlay software is used. That's a configuration problem, and again
nothing to do with NTFS.
> So you really never did any forensic reviews on the bad sectors created
> after using DOS tools, right.
>
I have done lots of examination of bad sectors. In many cases I have
recovered data from bad sectors. I would assume that quite often the data
was some sort of XP 'special usage' area, such as system restore. But I
have never known the allocation of disk space to bad sectors to be
associated with how XP or NTFS was using that particular sector.
> Pull those disks out and check them. I'd love to see I'm wrong, and I may
> be.
> I'm fully prepared to apologize to the world if necessary, are you?
>
Check them for what? That the disk capacity visible to the file system
agrees with the physical size of the disk? That's already carefully checked
in making sure the disks are fit for use.
Jeff Richards
is coming from, then I think I can see what the problem is
> snip <
> Note this: " If you erased cluster tips on a compressed drive and lost
> significant amount of disk space, you must recompress the drive to restore
> the lost space."
the space consumed by the compressed files, becasue one of the features of
compression is that the cluster tips are never physically stored. When they
are erased, the compression software thinks the erasing data is genuine data
and compresses it and writes it, thus vastly increasing the space required.
Recompressing the volume or partition re-writes each file without the 'tip',
putting things back to how they were.
Inappropriate use of the erasing utility will increase the size of the
compressed volume and reduce free disk space, but it is all fuly
recoverable.
> snip <
>
> Let's say not the whole disk is compressed (though it basically is in
> NTFS), but only certain areas of the disk. What happens when we attempt to
> remove them normally? What happens if more than one compression and or
> encryption scheme is used within the disk, e.g. compression within
> compression or encryption within compression?
If you remove a compressed file the file entry is removed from the
compressed volume. The file contents remain, and (usually) the compressed
volume file size doesn't change. You can recompress the volume or
partition to remove unused space.
Saving a compressed file to a compressed partition (eg, zipping a file to a
compressed volume) doesn't affect anything, except that you won't save any
space other than the 'tip'.
Whether a file is encrypted or not is irrelevant, except that encruption
might change the file size and will certainly slow down file operations. It
will also make the whole file look different than the original, and this
might interfere with intelligent replacement algorithms in the compression
routine, again increasing disk access times. But it has nothing to do with
lost disk space.
> Now what happens if HPA is involved in protecting certain areas of the
> disk, such as some of those compressed areas or files?
It isn't.
> Now what happens when we use tools that "don't know Jack" about what XP
> NTFS has done to the disk?
Then you will stuff up the file system (or just get wrong information).
> snip <
> The only thing of any real value would be the $Mft tables (that are still
> intact) and one of the backup boot sectors.
The $MFT tables are just sectors of data for a recovery program. The fact
that they still exist does not indicate that the data or structures they
refer to still exist.
> However, the backup boot and partition table have also been changed.
> Or have they?
Maybe, maybe not. Depending on the utility you are using and exactly what
you are looking at, you might be seeing an original, you might be looking at
a backup (which might be out of date, or might refer to a completely
different disk organisation, such as an overlay) or you might be seeing a
reconstruction. The history of the disk is critical if you want to make use
of this type of data.
> Running TESTDISK !Search (extended search - searches the entire disk)
> pulls
> up the NTFS partition information.
Partition information can be either a reconstruction or a recoverd sector.
The recovered sector might be a backup, and it could be a backup from any
previous state of the drive. It depends on what the prior process was, the
utility you are using and which partition data you are looking at.
> However, placing that info as the
> partition, causes the disk to extend far beyond it's stated CHS capacity.
So it's probably a reconstruction, and incorrect.
> So
> perhaps LBA is used>>> in non-standard areas of the disk.
> The first few times a backup partition table was used or viewed, it was
> similar to the CHS of the disk, except for one cylinder less. That was
> wiped
> by one of the tools, yet this other one still pops up.
Using multiple tools is going to do this. They have different numbering
systems, use the same terms in slightly different ways, and calculate things
slightly differently. You have to allow for these differences if you use
more than one tool.
> Using a disk editor shows a large amount of information stored beyond the
> CHS end boundary of the disk, including what appears to be a partition
> table
> and a boot sector.<grin>
The 'large amount of information" is probably unused sectors between the
last logical sector and the last physial sector (which occurs due to
rounding to a full track). The other might be a backup (you need BIOS
details and a full history of the disk to answer that, such as special
paritioning software that may have been used). But it might also be the
disk editor is simply wrapping at the end of the disk - a commn 'feature'.
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:OBT598B5...@TK2MSFTNGP04.phx.gbl...
| If you are quoting this because you think this describes where the problem
| is coming from, then I think I can see what the problem is
[all the stuff cut]
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
|
|
Okay, I see you still don't grasp the situation, let's look at it like
this:
If this was the same old NT4 NTFS file system, then who would buy the new
friggin OS.
Almost everything included in XP was available in the NT4 version via third
party programs. Even to the extent of hardening the system, and remote
administration.
The major SELLING point and supposed major REASON for businesses to upgrade
was because of the NEW protection schemes and hardened filing activities
integrated into this NEWEST TECHNOLOGY NTFS.
Now, I appreciate the continued attempts to deal with the disks as if it's
the same old DOS based functioning as MS DOS through NT4, but to do so is
stating and indicating that Microsoft committed fraud and then could be sued
for doing so.... I don't think Microsoft would appreciate that much.
My research shows they did exactly as they said they did or would.
The failure, and potential for suit would be the blatant disregard to
create a tool to completely remove all traces of the OS and return the disk
to it's pristine state, and forewarn of the potential risks involved with
disk reuse or attempted wiping for security reasons.
Moreover, since you did check at least one disk, and FOUND evidence of XPs
protected area traces, one would think you might have done this research
yourself several years ago.
Per one of your other presentations, you stated you were about to send a
disk back to the manufacturer with LARGE amounts of potentially sensitive
data STILL INTACT on the disk. When I performed these types of activities, I
had to CERTIFY that I had securely wiped these disk of any potentially
sensitive data, and that meant EVERY trace.
Might want to think about that.
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:%2367KheB...@TK2MSFTNGP05.phx.gbl...
| > Really,, the health huh, when some of these are apparently the files
that
| > are created during XPs Restore Point activities.
| > When some of these are apparently the files created when XP backs itself
| > up.
| > When some of these are apparently the protected HIVES.
| > When some of these are apparently from the protected system areas.
| >
| Some of WHAT? The only missing space that yo have described properly has
| been thoroughly explained by Franc.
No it wasn't.
Which tool was wrong?
These tools (depending on which one) can completely ignore the BIOS, read
the actual disk, and work from there, were these the wrong tools?
Others can reset the disk from the manufactures own onboard coding and work
from there. So were these the wrong ones?
Then there are those which are highly touted tools designed for only one
purpose, and that's to wipe every sector of the disk, even "bad areas", were
these the wrong tools to use?
And still others can do some commands on disks which could, with improper
use, literally kill the disk, so were these the wrong tools?
Then we have to consider the tools which can read every part of the disk,
every sector, every bit and byte, and the instruction sets, were these the
wrong tools to use on the disk?
So in your honoured opinion which ones were wrong. Need the list again?
|
| I have seen a similar thing happen when the drive was badly configured and
| two utilities got extremely confused about how many sectors, tracks and
| heads there were (sectors was the critical one, IIRC). This can also
happen
| if overlay software is used. That's a configuration problem, and again
| nothing to do with NTFS.
Yep, programs do get confused, change a disk from hard set to AUTO and you
may have a major problem on your hands.
Beyond that, changing CHS effects how the disk is accessed, so the point is?
|
| > So you really never did any forensic reviews on the bad sectors created
| > after using DOS tools, right.
| >
| I have done lots of examination of bad sectors. In many cases I have
| recovered data from bad sectors. I would assume that quite often the data
| was some sort of XP 'special usage' area, such as system restore. But I
| have never known the allocation of disk space to bad sectors to be
| associated with how XP or NTFS was using that particular sector.
So what your saying is that 2+2 didn't equal 4 to you.
|
| > Pull those disks out and check them. I'd love to see I'm wrong, and I
may
| > be.
| > I'm fully prepared to apologize to the world if necessary, are you?
| >
| Check them for what? That the disk capacity visible to the file system
| agrees with the physical size of the disk? That's already carefully
checked
| in making sure the disks are fit for use.
|
| > Don't take this wrong. I'm not demeaning you, or acting facetious, I am
| > truly concerned with this, if this is what is occurring.
| >
|
|
So once again, you have some disk available, let's have some fun. Do some
tests.
Jeff Richards
> tests.
>
through. Other than that, I'm not interested.
Jeff Richards
>
> "Jeff Richards" <JRic...@msn.com.au> wrote in message
> news:OBT598B5...@TK2MSFTNGP04.phx.gbl...
> | If you are quoting this because you think this describes where the
> problem
> | is coming from, then I think I can see what the problem is
> [all the stuff cut]
> | --
> | Jeff Richards
> | MS MVP (Windows - Shell/User)
> |
>
> Okay, I see you still don't grasp the situation, let's look at it like
> this:
>
> If this was the same old NT4 NTFS file system, then who would buy the new
> friggin OS.
system, not a file system.
> Almost everything included in XP was available in the NT4 version via
> third
> party programs. Even to the extent of hardening the system, and remote
> administration.
> The major SELLING point and supposed major REASON for businesses to
> upgrade
> was because of the NEW protection schemes and hardened filing activities
> integrated into this NEWEST TECHNOLOGY NTFS.
which didn't require you to purchase extra third-party software.
> Now, I appreciate the continued attempts to deal with the disks as if it's
> the same old DOS based functioning as MS DOS through NT4, but to do so is
> stating and indicating that Microsoft committed fraud and then could be
> sued
> for doing so.... I don't think Microsoft would appreciate that much.
> My research shows they did exactly as they said they did or would.
You mean that the additional security really was there? Yes, I guess it
was.
I think you are saying that MS _must_ have done magical secret things to
prevent DOS tools from accessing secure data. That's not so. Take a look
at the security standards for NTFS/XP. Unless the data is encrypted it is
accessible to any software that can do sector reads. That includes all
unencrypted files, and any sectors containing the plaintext backups of
encrypted files that haven't yet been overwritten..
> The failure, and potential for suit would be the blatant disregard to
> create a tool to completely remove all traces of the OS and return the
> disk
> to it's pristine state, and forewarn of the potential risks involved with
> disk reuse or attempted wiping for security reasons.
Security standards for NTFS/XP have never included such a requirement. A
decent security protocol will not support disk re-use in any form. MS
doesn't have to forewarn security professionals of that requirement - they
know it already. (Although in fact you will find plenty of warnigns - search
on the third immutable law of security for examples).
> Moreover, since you did check at least one disk, and FOUND evidence of XPs
> protected area traces, one would think you might have done this research
> yourself several years ago.
What research? Why would I not expect to be able to see this data? I didn't
have encryption enabled. I knew that any DOS tool could get to it.
> Per one of your other presentations, you stated you were about to send a
> disk back to the manufacturer with LARGE amounts of potentially sensitive
> data STILL INTACT on the disk. When I performed these types of activities,
> I
> had to CERTIFY that I had securely wiped these disk of any potentially
> sensitive data, and that meant EVERY trace.
The data on the disk that is being returned is not potentially sensitive,
and I never indicated it was.
If your data is potentially sensitive then you have a problem deleting it.
That is a completely different issue.
In that case I would NOT recommend using ZAP or WIPE, as the disk erasing
functions actually work best within the file system (ie, as an XP process)
because that way they can identify exactly what parts of the disk have been
accessed for file storage and therefore need to be wiped. Of course, if
you've fiddled with the disk configuration or installed and removed overlay
software or shuffled partitioning around then the current configuration
might not be accessing the whole drive and the erasing software can miss
parts of it. That's why you would follow up with a certified hardware-level
erase. But that's also why a proper security protocol doesn't allow those
sorts of changes.
> Might want to think about that.
>
I won't, because my data isn't that sensitive. If yours is, then a
sledgehammer is the best erasing tool I know of (and yes, I have used one
when the client requested it).
real@hotmail.com MEB
Both disks I tested were used considerably longer, but perhaps this might
show something.
Might be easier for you if the disk is small so you don't have to spend
considerable time examining the disk.
1. Check a supposed empty disk first for any potential traces of NTFS and
bad sectors (view the disk sectors) with a competent disk editor. You have
one correct?
Make absolutely sure it contains no NTFS, and the disk is functioning
properly.
2. Install XP Pro (SP2) on the disk, run the computer through a normal set
of activities, including updates over the course of 1 week. (negate the
updates if your on phone lines, heck it would take the whole week likely).
Setup a second administrator account. Use this account for the all
activities. Your mimicking several weeks or months of use.
3. Copy several files, move several files, use the Internet, do whatever
else would be normal use for you. Copy several of the XP Installation cabs
to the disk (your mimicking continued updates and files XP may not allow to
be erased). Open the disk to the folder you copied the cabs to several
times. Open the cabs at least once, "view" a few of the files .
4. Shut down and restart during that time period several times.
5. Install several programs over the course of the week.
6. Run the disk management plugin once or twice, actually clear the disk
free space at least once.
7. Create several restore points over the course of the week. Also use the
master administrator account to create one or two restore points.
8. Take the disk out of service by following the standard routine of Windows
98SE version fdisk (we see so often here) to delete the partition. Restart
the computer.
9. Follow the standard Windows 98SE version fdisking, restarting, and
formatting (with or without the /u, note which was used) to re- establish
the disk. Note whether full disk is given. Restart the computer.
10. Run DOS version of Windows 98SE scandisk on the disk. Note any errors.
11. Recheck the disk with that competent disk editor for potential traces of
NTFS, check all sectors again. Recheck your disk status for full disk
access.
12. Install Windows 98. Install one of the NTFS recovery tools on the disk
and check to see if you can recover any files.
Let's see if this short test and standard removal produces anything.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:%23zJJgFE...@TK2MSFTNGP06.phx.gbl...
real@hotmail.com MEB
Here we go, took awhile but the discussion warms up..
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:e1r6hlE5...@TK2MSFTNGP06.phx.gbl...
| "MEB" <meb@not re...@hotmail.com> wrote in message
| news:OE00mED5...@TK2MSFTNGP05.phx.gbl...
| >
| > "Jeff Richards" <JRic...@msn.com.au> wrote in message
| > news:OBT598B5...@TK2MSFTNGP04.phx.gbl...
| > | If you are quoting this because you think this describes where the
| > problem
| > | is coming from, then I think I can see what the problem is
| > [all the stuff cut]
| > | --
| > | Jeff Richards
| > | MS MVP (Windows - Shell/User)
| > |
| >
| > Okay, I see you still don't grasp the situation, let's look at it like
| > this:
| >
| > If this was the same old NT4 NTFS file system, then who would buy the
new
| > friggin OS.
| Anyone who wanted the new features in XP. They are buying an operating
| system, not a file system.
Are you sure?
Most businesses have no need for many of the "features" XP offered. It
isn't that far from NT4 or 2000.
|
| > Almost everything included in XP was available in the NT4 version via
| > third
| > party programs. Even to the extent of hardening the system, and remote
| > administration.
| > The major SELLING point and supposed major REASON for businesses to
| > upgrade
| > was because of the NEW protection schemes and hardened filing activities
| > integrated into this NEWEST TECHNOLOGY NTFS.
| which didn't require you to purchase extra third-party software.
|
| > Now, I appreciate the continued attempts to deal with the disks as if
it's
| > the same old DOS based functioning as MS DOS through NT4, but to do so
is
| > stating and indicating that Microsoft committed fraud and then could be
| > sued
| > for doing so.... I don't think Microsoft would appreciate that much.
| > My research shows they did exactly as they said they did or would.
|
| You mean that the additional security really was there? Yes, I guess it
| was.
|
| I think you are saying that MS _must_ have done magical secret things to
| prevent DOS tools from accessing secure data. That's not so.
No? Using tools designed for operating systems and disks using older ATA
standards upon disks which use newer is not very sensible, nor does it
properly access the disk. XP happens to use far more of the standards and
some not so standard.
This is the first ATA/ATAPI standard. Released in 1994.
http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-1/
This is the second ATA/ATAPI standard. Released in 1996.
http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-2/
This is the fifth ATA/ATAPI standard. Released in 2000.
http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-5/
This is the sixth ATA/ATAPI standard. Released in 2001.
http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-6/
This is the seventh ATA/ATAPI standard. Released in 2003.
http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-7/
ATA/ATAPI-8 revision 2b — AT Attachment — 8 ATA/ATAPI Command Set (January
10, 2006, draft)
http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-8-rev2b/
Take a look
| at the security standards for NTFS/XP.
Links please if you intend to present standards, we are discussing these
issues before the world.
Unless the data is encrypted it is
| accessible to any software that can do sector reads. That includes all
| unencrypted files, and any sectors containing the plaintext backups of
| encrypted files that haven't yet been overwritten..
HMM, really, that's not exactly how Microsoft explains it in links I've
provided before.
|
| > The failure, and potential for suit would be the blatant disregard to
| > create a tool to completely remove all traces of the OS and return the
| > disk
| > to it's pristine state, and forewarn of the potential risks involved
with
| > disk reuse or attempted wiping for security reasons.
|
| Security standards for NTFS/XP have never included such a requirement. A
| decent security protocol will not support disk re-use in any form. MS
| doesn't have to forewarn security professionals of that requirement - they
| know it already. (Although in fact you will find plenty of warnigns -
search
| on the third immutable law of security for examples).
You also find them, somewhat included in various Microsoft disclaimers.
HOWEVER:
You fail to address the issue of sales to home users, and non-security
professionals.
If one presents a product as fit for a particular non-professional
audience, one must forewarn that audience or be prepared for the
consequences. Or otherwise provide a means to protect that audience.
Microsoft has apparently failed to do so.
|
| > Moreover, since you did check at least one disk, and FOUND evidence of
XPs
| > protected area traces, one would think you might have done this research
| > yourself several years ago.
|
| What research? Why would I not expect to be able to see this data? I
didn't
| have encryption enabled. I knew that any DOS tool could get to it.
Really, then look at some of those files in those bad areas. You don't need
to ENABLE this, it's done as part of the protection scheme.
You can't see anything legible because they are compressed and or encrypted
(you can check this with standard NTFS recovery software), and guess what,
most CAN be recovered. Other files can be viewed and recovered without any
trouble. So their not really bad areas are they.
|
| > Per one of your other presentations, you stated you were about to send a
| > disk back to the manufacturer with LARGE amounts of potentially
sensitive
| > data STILL INTACT on the disk. When I performed these types of
activities,
| > I
| > had to CERTIFY that I had securely wiped these disk of any potentially
| > sensitive data, and that meant EVERY trace.
|
| The data on the disk that is being returned is not potentially sensitive,
| and I never indicated it was.
|
| If your data is potentially sensitive then you have a problem deleting it.
| That is a completely different issue.
My sensitive data was deleted, securely. That's not what we're discussing
is it.
|
| In that case I would NOT recommend using ZAP or WIPE, as the disk erasing
| functions actually work best within the file system (ie, as an XP process)
| because that way they can identify exactly what parts of the disk have
been
| accessed for file storage and therefore need to be wiped. Of course, if
| you've fiddled with the disk configuration or installed and removed
overlay
| software or shuffled partitioning around then the current configuration
| might not be accessing the whole drive and the erasing software can miss
| parts of it. That's why you would follow up with a certified
hardware-level
| erase. But that's also why a proper security protocol doesn't allow those
| sorts of changes.
It's a 7 gig, 6.5 formatted disk, no overlay.
The disks were originally taken out of service by the supposed fdisking and
formatting so often recommended in these discussion groups (and not just
this
one) for the specific purpose of testing this supposed technique and other
supposed tools and techniques.
Both disk were fully checked before this activity.
|
| > Might want to think about that.
| >
| I won't, because my data isn't that sensitive. If yours is, then a
| sledgehammer is the best erasing tool I know of (and yes, I have used one
| when the client requested it).
| > --
| > MEB
| >
| >
|
|
No thanks, don't need it, I have tools that negate that type of activity..
pending some change to "SECRET" classification. <GRIN>
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
real@hotmail.com MEB
what I get for posting while half awake... (*98 brain freeze#$@^
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"MEB" <meb@not re...@hotmail.com> wrote in message
news:eWyCQLG5...@TK2MSFTNGP06.phx.gbl...
Franc Zabkar
put finger to keyboard and composed:
>Okay, here's a one week test.
<instructions snipped>
I didn't see any mention of compression or encryption. Therefore I'm
left to wonder why you've introduced these concepts at all.
>12. Install Windows 98. Install one of the NTFS recovery tools on the disk
>and check to see if you can recover any files.
Hmm. It is a *bad* idea to run a forensic tool from the same
drive/OS/filesystem that you wish to recover or examine. Instead you
should attach this drive as a primary slave, or put in on the
secondary IDE channel. Or boot from a CD or floppy diskette.
>Let's see if this short test and standard removal produces anything.
If you've been booting from your test drive and *then* running
forensic tools on it, then I'm not surprised that your results have
been odd. Ask yourself, what sort of tool would allow a user to edit
the sectors of a drive running a multitasking OS? It just beggars
belief.
Franc Zabkar
put finger to keyboard and composed:
> Actually, if you've been paying attention to another thread Re: Everest
>Report presntly going on, we just had someone find out how badly a disk can
>be screwed up. Let's see what we come up with there, ...
The OP in that thread is severely lacking in basic skills. After about
300 posts he is back to where he started. And he *still* hasn't looked
inside the box.
In any case, I suspect that he may have replaced an existing 8GB drive
with a 10GB one, and then allowed the new drive to inherit the BIOS
parameters of the old one.
> It could do this by scanning the FAT for free clusters and
>| comparing what it finds with the total recorded in the FSInfo sector.
>| In fact Scandisk invariably reports a free space mismatch error on my
>| HD after a crash. In your case you would expect a mismatch because the
>| 1st and 7th sectors of every track that falls within your FATs would
>| have been "F6-ed" by Fdisk.
>
> Good theory, however it's faulty. You haven't checked the other tools
>previously referenced, which I had to place into that discussion you thought
>to put into that alt.hard drive group did you? Read on before you get upset
>or reply.
That storage group was a disappointment. I had expected one of the
experts to offer an opinion. :-(
>| As for why a forensic utility can still see your old file data, I
>| think it is because a standard Format is essentially non-destructive.
>| The format process first verifies that every sector can be read, and
>| then writes the boot sectors, FATs, and root directory. The data area
>| is not disturbed. A destructive "unconditional" format, ie one that
>| writes F6 to every sector of the partition, requires the /u switch:
>|
>| format c: /u
>
> Yeah that's right.
> Like I haven't done before. This is a test of DOS and other techniques and
>tools.
The Format command should at least have told you the size of the
partition that was being formatted, ie "Formatting nnnnM, x%
completed" or something like that. The /u switch should have forced
Format to test every sector by writing an F6 pattern to it. Any
"protected" sector would have generated a bad sector error. If 10% of
your hard disk really was inaccessible, then you should have seen
hundreds of thousands of these errors.
>| >The other tools created to address these activities (wiping, formatting,
>| >fdisking, etc) base their information and coding on known partition
>types,
>|
>| I doubt that a wipe utility would care about partition types. Instead
>| I would think that it would treat the entire disc as raw physical
>| sectors.
>
> They try, but only if they recognize them or can access them.
> It was actually interesting to watch through the first few tests, now
>it's... well have you ever done the same task dozens of times with the same
>outcome?
Hard drive manufacturers have their own wiping utilities. These
utilities have no knowledge of any OS or file system, nor should they
be expected to. A hard drive's user data area is just a bunch of
logical blocks.
For example, see the FJ-IDE Drive Initializer Utility at this URL:
http://www.fel.fujitsu.com/home/v3__product.asp?pid=181&inf=swr&wg=0
>| If the BIOS can see the whole disc (apart from one reserved cylinder),
>| then isn't that enough to tell you that its capacity is not being
>| clipped by some entry in the HPA?
>
> No, your forgetting LBA and several other things related to hard drives.
Are you saying that the HD can report that it has less logical blocks
than would be suggested by its default CHS translation? (The reverse
is true BTW.)
> Franc, do you have access to any re-formatted XP NTFS disk.
No, and I doubt that I will in the foreseeable future.
> I don't care if
>you have installed the disk full of programs and an OS. Just use some of
>these tools (be careful which ones) and LOOK AT THE DISK FOR NTFS traces.
> Or beg, borrow, or steal (it's a saying) a copy of WINHEX and look at the
>disk. Version 12.8 is the last one which works in 98 (if that's what your
>running), it's 13+ for XP last time I checked. See what it locates for you.
>(IT IS EXPENSIVE BTW) You could use the test version I think (is it still
>available?).
I prefer to use DOS based utilities for looking at disc structures.
IMHO, a protected mode, multitasking OS is not the right platform for
this kind of work.
> Because after fdisking and formatting the disk is reduced from it's stated
>full capacity, which it finds. Scandisk it, and it will be reduced even
>more. Hence, it's now around 5.6 gig, which is as far as I'm willing to take
>it. It will be difficult enough to recover.
How are you determining the capacity of the disc? Which utility is
telling you that you now have only 5.6GB?
> Are you in love with Windows or something? DOS box, what idiot would use a
>DOS box for this type of activity.
Agreed, you'd have to be incompetent. But then I wouldn't do *any*
sector editing in a *Windows* environment, unless I was absolutely
sure of what I was doing.
>| Does TESTDISK's NTFS partition information correctly reflect the
>| native capacity of the HD as specified by its manufacturer? Have you
>| accounted for a reserved cylinder and/or surplus sectors?
>
> Yes
Well, TestDisk thinks that my 13GB Seagate HD has 12732 *more* sectors
than its native capacity. <shrug> See my latest post in the "Everest"
thread.
> LET ME MODIFY THIS PART OF MY PRIOR POST
> There apparently is still a Table around the center of the disk as well.
I suspect that the drive originally had two partitions, a primary and
an extended. What you could be seeing is the Extended Boot Record
(EBR).
See http://home.att.net/~rayknights/pc_boot/ext_tbls.htm
>| > Using a disk editor shows a large amount of information stored beyond
>the
>| >CHS end boundary of the disk, including what appears to be a partition
>table
>| >and a boot sector.<grin>
>|
>| Are you seeing a wrap-around effect? If you make changes to the MBR
>| code or to the partition table, do these changes also appear at the
>| end of the disc? For example, change one of the text strings from
>| "system" to "System" and see what happens.
>|
>| - Franc Zabkar
> Franc, if I choose to do so, I can edit the entire friggin disk by hand or
>by block replacement. Heck I can make the disk a full 7 gig and beyond, if
>that's what I want to look at.
> I have both DOS and Windows disk editing and FORENSIC tools, capable of
>just about anything, INCLUDING rewriting jump and other instructions on the
>disk.
I'm not asking you to do anything exotic. I'm merely asking you to
change *one* harmless text byte in physical sector 0 in order to test
whether the same change is reflected beyond the CHS boundary of the
disc. This will confirm whether the effect you are seeing is due to
wrapping.
>Get it yet?
>What are we doing here, fixing the disk or EXPOSING Microsoft's apparent
>corruption of hard disks?
So you say, but you haven't demonstrated this to anyone's
satisfaction.
> I did not ask for help fixing this disk, I asked for the XP NTFS info
>(which I need to recover this disk or it's trial and error)...
Who cares if the disc's ones and zeroes were written by XP or DOS or
Win9x or Linux, etc? It's all just data, nothing more. In any case,
"fixing" the disc or "recovering" it amount to the same thing,
otherwise why did you try to "wipe" it if that wasn't your intention?
Anyway, I've exhausted my ideas. Instead I'll be watching Jeff's input
with interest.
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:gd6uh2p6j89e0h0ht...@4ax.com...
| On Thu, 28 Sep 2006 23:51:39 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| > Actually, if you've been paying attention to another thread Re: Everest
| >Report presntly going on, we just had someone find out how badly a disk
can
| >be screwed up. Let's see what we come up with there, ...
|
| The OP in that thread is severely lacking in basic skills. After about
| 300 posts he is back to where he started. And he *still* hasn't looked
| inside the box.
I know, any sound advise is overlooked.
|
| In any case, I suspect that he may have replaced an existing 8GB drive
| with a 10GB one, and then allowed the new drive to inherit the BIOS
| parameters of the old one.
In part; that's one of the reasons why I posted regarding "corrupt" coding
in that thread, PARTICULARLY after he ran Maxtor's tool.
|
| >or reply.
|
| That storage group was a disappointment. I had expected one of the
| experts to offer an opinion. :-(
As it was to me as well, I thought we could work through some issues there.
The tools list likely put them off, as there are some "hefty" tools listed
which they know and many would surely have used.
|
| >| As for why a forensic utility can still see your old file data, I
| >| think it is because a standard Format is essentially non-destructive.
| >| The format process first verifies that every sector can be read, and
| >| then writes the boot sectors, FATs, and root directory. The data area
| >| is not disturbed. A destructive "unconditional" format, ie one that
| >| writes F6 to every sector of the partition, requires the /u switch:
| >|
| >| format c: /u
| >
| > Yeah that's right.
| > Like I haven't done before. This is a test of DOS and other techniques
and
| >tools.
|
| The Format command should at least have told you the size of the
| partition that was being formatted, ie "Formatting nnnnM, x%
| completed" or something like that. The /u switch should have forced
| Format to test every sector by writing an F6 pattern to it. Any
| "protected" sector would have generated a bad sector error. If 10% of
| your hard disk really was inaccessible, then you should have seen
| hundreds of thousands of these errors.
Depending upon where in the series of tests, it did exactly as you say, save
for the hundreds of thousands, these areas are in large blocks for the most
part.
At 92% both fdisk and format (per last use) stumble for awhile trying to
make sense out of what their looking at and what to do.
And yes, I read the KBs.
|
| >| >The other tools created to address these activities (wiping,
formatting,
| >| >fdisking, etc) base their information and coding on known partition
| >types,
| >|
| >| I doubt that a wipe utility would care about partition types. Instead
| >| I would think that it would treat the entire disc as raw physical
| >| sectors.
| >
| > They try, but only if they recognize them or can access them.
| > It was actually interesting to watch through the first few tests, now
| >it's... well have you ever done the same task dozens of times with the
same
| >outcome?
|
| Hard drive manufacturers have their own wiping utilities. These
| utilities have no knowledge of any OS or file system, nor should they
| be expected to. A hard drive's user data area is just a bunch of
| logical blocks.
|
| For example, see the FJ-IDE Drive Initializer Utility at this URL:
| http://www.fel.fujitsu.com/home/v3__product.asp?pid=181&inf=swr&wg=0
Franc, I have most of the manufacturers tools locally.
As do Maxtor's, but they just can't seem to understand what's been done
either. These disks were in use for several years.
As for "just a bunch of logical blocks", that's somewhat inaccurate,
because hard drives are comprised of storage disks AND another disk/side,
and the controller. Which is why I directed you to look into how hard drives
are made, so perhaps you would have a better understanding of what can
occur.
|
| >| If the BIOS can see the whole disc (apart from one reserved cylinder),
| >| then isn't that enough to tell you that its capacity is not being
| >| clipped by some entry in the HPA?
| >
| > No, your forgetting LBA and several other things related to hard drives.
|
| Are you saying that the HD can report that it has less logical blocks
| than would be suggested by its default CHS translation? (The reverse
| is true BTW.)
Franc, you haven't installed XP PRO NTFS yet. The CHS IS modified upon OS
installation.
As are, apparently several other disk related activities.
|
| > Franc, do you have access to any re-formatted XP NTFS disk.
|
| No, and I doubt that I will in the foreseeable future.
Frankly, and I know the XPers in this group hate it, but I wouldn't
recommend it.
Perhaps Vista, but we'll have to wait and see what is finally presented as
the OS.
I think of XP as, maybe, Windows 95 was, an experiment out of hand. Good
ideas, real potential, poor programming, terrible for much of anything that
was originally claimed. But then that's just me.
|
| > I don't care if
| >you have installed the disk full of programs and an OS. Just use some of
| >these tools (be careful which ones) and LOOK AT THE DISK FOR NTFS traces.
| > Or beg, borrow, or steal (it's a saying) a copy of WINHEX and look at
the
| >disk. Version 12.8 is the last one which works in 98 (if that's what your
| >running), it's 13+ for XP last time I checked. See what it locates for
you.
| >(IT IS EXPENSIVE BTW) You could use the test version I think (is it still
| >available?).
|
| I prefer to use DOS based utilities for looking at disc structures.
| IMHO, a protected mode, multitasking OS is not the right platform for
| this kind of work.
And you would be right for the most part. Buffered writes (even when turned
off), interference from the Windows environment if it thinks you're doing
something it doesn't want you to, and several other things you just don't
have at a command level environment or even Linux (no! don't go there yet)..
|
| > Because after fdisking and formatting the disk is reduced from it's
stated
| >full capacity, which it finds. Scandisk it, and it will be reduced even
| >more. Hence, it's now around 5.6 gig, which is as far as I'm willing to
take
| >it. It will be difficult enough to recover.
|
| How are you determining the capacity of the disc? Which utility is
| telling you that you now have only 5.6GB?
FDisk and format show reduced, they can't read or see the residuals.
Every tool which has the ability, show potential full capacity, they may
modify for USED space or "bad areas".
|
| > Are you in love with Windows or something? DOS box, what idiot would use
a
| >DOS box for this type of activity.
|
| Agreed, you'd have to be incompetent. But then I wouldn't do *any*
| sector editing in a *Windows* environment, unless I was absolutely
| sure of what I was doing.
Believe me, I'm careful (to myself: right idiot you trashed one disk or was
it that last program that did).
|
| >| Does TESTDISK's NTFS partition information correctly reflect the
| >| native capacity of the HD as specified by its manufacturer? Have you
| >| accounted for a reserved cylinder and/or surplus sectors?
| >
| > Yes
|
| Well, TestDisk thinks that my 13GB Seagate HD has 12732 *more* sectors
| than its native capacity. <shrug> See my latest post in the "Everest"
| thread.
You probably do. Did you read what TESTDISK is actually showing you.
|
| > LET ME MODIFY THIS PART OF MY PRIOR POST
| > There apparently is still a Table around the center of the disk as well.
|
| I suspect that the drive originally had two partitions, a primary and
| an extended. What you could be seeing is the Extended Boot Record
| (EBR).
Never did, both have only been used by me.
|
| See http://home.att.net/~rayknights/pc_boot/ext_tbls.htm
|
| >| > Using a disk editor shows a large amount of information stored beyond
| >the
| >| >CHS end boundary of the disk, including what appears to be a partition
| >table
| >| >and a boot sector.<grin>
| >|
| >| Are you seeing a wrap-around effect? If you make changes to the MBR
| >| code or to the partition table, do these changes also appear at the
ZIPPPPP
| > Franc, if I choose to do so, I can edit the entire friggin disk by hand
or
| >by block replacement. Heck I can make the disk a full 7 gig and beyond,
if
| >that's what I want to look at.
| > I have both DOS and Windows disk editing and FORENSIC tools, capable of
| >just about anything, INCLUDING rewriting jump and other instructions on
the
| >disk.
|
| I'm not asking you to do anything exotic. I'm merely asking you to
| change *one* harmless text byte in physical sector 0 in order to test
| whether the same change is reflected beyond the CHS boundary of the
| disc. This will confirm whether the effect you are seeing is due to
| wrapping.
Franc, at present I really don't care what you want, sorry, there's a test
under way (hopefully).
Moreover, as the present partition is 32 and the other referenced partition
is NTFS (so stated in the table) there is NO CHANGE. HAPPY...
So stop trying to make ME convince YOU when you apparently haven't even a
clue of what XP NTFS is or does yet.
|
| >Get it yet?
| >What are we doing here, fixing the disk or EXPOSING Microsoft's apparent
| >corruption of hard disks?
|
| So you say, but you haven't demonstrated this to anyone's
| satisfaction.
Whose, yours? Like I care about that, you apparently have ZERO experience
or knowledge of XP NTFS. You apparently haven't even run it.
So what are you using as reference, someone elses material? 1990s DOS
materials?
I chose to actually TEST the accepted, rather than do the same basic thing
as you and others, and myself, always did, prior to my testing. And as I
have repeatedly stated, I may be wrong...
|
| > I did not ask for help fixing this disk, I asked for the XP NTFS info
| >(which I need to recover this disk or it's trial and error)...
|
| Who cares if the disc's ones and zeroes were written by XP or DOS or
| Win9x or Linux, etc? It's all just data, nothing more. In any case,
| "fixing" the disc or "recovering" it amount to the same thing,
| otherwise why did you try to "wipe" it if that wasn't your intention?
To TEST the XP NTFS system and it's removal. WHAT PART OF "TEST" DO YOU NOT
UNDERSTAND!
|
| Anyway, I've exhausted my ideas. Instead I'll be watching Jeff's input
| with interest.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
As will I.
I have the next tests ready when that one is done.
Short and sweet, hope he doesn't need the disk for anything anymore, if
there is something to this.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
real@hotmail.com MEB
| On Sat, 30 Sep 2006 03:26:22 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| >Okay, here's a one week test.
|
| <instructions snipped>
|
| I didn't see any mention of compression or encryption. Therefore I'm
| left to wonder why you've introduced these concepts at all.
Because you've never installed the OS. He is installing XP NTFS.
Please read up on XP NTFS.
|
| >12. Install Windows 98. Install one of the NTFS recovery tools on the
disk
| >and check to see if you can recover any files.
|
| Hmm. It is a *bad* idea to run a forensic tool from the same
| drive/OS/filesystem that you wish to recover or examine. Instead you
| should attach this drive as a primary slave, or put in on the
| secondary IDE channel. Or boot from a CD or floppy diskette.
Second best is Secondary Master ONLY IF you need to use some other
operating systems tools. It is not recommended to install to the Primary
channel as slave for testing. The BEST is primary master, using the floppy
and/or CD for test tools, NO OS or other file installation, UNLESS that is
part of the test.
Franc, it's to mimic what is presented in these groups and elsewhere.
I would much prefer to NOT installing an OS for the test, but it negates
"well installing an OS would have overwritten those files or recovered those
areas". These are technical tests, the procedure is now set. Ask HIM to
modify if that's what YOU want, I would prefer that myself, but I doubt he
will do it; hence, the shortened test.
Granted, it will NOT reflect extended XP NTFS use, but perhaps we can find
something of value.
|
| >Let's see if this short test and standard removal produces anything.
|
| If you've been booting from your test drive and *then* running
| forensic tools on it, then I'm not surprised that your results have
| been odd.
Franc, wait for the test results and do some reading on XP NTFS so you can
put some viable material in the thread, please.
Might check on forensic activities, recovery, testing applications, and
other like data. Heck, why not become an expert on ATA/ATAPI specs. and
commands, I provided links, I may need your advise.
I did NOT boot from my test disks while testing or RUN my tests from the
test disks. The majority of tests were performed on the original system to
negate any BIOS potential difference interference. Same chipset, same bios
and settings, same processor, same .... these are TESTS, one must follow the
proper procedures to negate potential issues which may provide false
results. The computer was the same one which originally setup the disks.
I did, however, place the disks into this computer to use some of the
tools in THIS 98SE OS on the disk as secondary master. Which, of course,
places the Recycle BIN junk, which has to be ignored. But only AFTER
performing all other tests so no contamination of the tests could be
encountered.
This was to use Windows based FORENSIC tools, disk "investigators" and
recovery tools. And yes, I realize the potential problems with that, but
those were to be part of the test.
| Ask yourself, what sort of tool would allow a user to edit
| the sectors of a drive running a multitasking OS? It just beggars
| belief.
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
I personally question the extent of viable use of any Windows but
particularly NT (5 and above for sure) tool on any disk to be tested, as
apparently the disk is constantly accessed.
Let's see how the first test goes.
Jeff Richards
we started. Are you proposing to use ZAP or WIPE at that point, or some
other utility?
Formatting the FAT32 partition using /U is the only thing that comes near to
removing the NTFS data, and for reasons that Franc has explained, it won't
remove everything. You should be running the erase routine between step 8
and 9 (ie, before creating the FAT32 partition).
With that procedure, it doesn't surprise me at all that you can see remnants
of NTFS.
I will assert from personal experience that the procedure you describe will
not create bad sectors unless they were already there. It may reveal some
bad sectors that the operating system had managed to hide.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:eWyCQLG5...@TK2MSFTNGP06.phx.gbl...
real@hotmail.com MEB
Thank you for verifying that Win98 FDisk will not remove NTFS.
What is you chosen wiping technique?
You are doing the test correct?
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:eTBK0ma5...@TK2MSFTNGP04.phx.gbl...
real@hotmail.com MEB
Also, please advise of what tools you intend to use to verify and test the
disk(s).
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"MEB" <meb@not re...@hotmail.com> wrote in message
news:%23bSM1ad...@TK2MSFTNGP05.phx.gbl...
real@hotmail.com MEB
I think that it would be condusive, for this technical discussion, to
clarify whether your statement regarding fdisk failure to remove NTFS (e.g.
failure of old standard technique re: fdisk, and format) references ALL
versions of NTFS, which versions, or just XP NTFS.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"MEB" <meb@not re...@hotmail.com> wrote in message
news:%23MkA71j...@TK2MSFTNGP02.phx.gbl...
real@hotmail.com MEB
Windows, which might be encountered during Jeff's review process.
From the HDAT2 4.51 PDF (apparently written around 1999)
Partition types:
07h
1. Windows NT NTFS
It is rumored that the Windows NT boot partition must be primary, and within
the first 2 GB of the disk.
2. OS/2 HPFS
3. Advanced Unix
4. QNX 2.x pre-1988
(see partition boot record; could be any of the above or others)
0Ch
Windows FAT32 LBA-mapped
Ext.INT 13h equivalent of 0Bh; Extended FAT32-Partition (Windows FAT32
over 8.4 GB, using LBA-mode INT 13h extensions)
0Dh FAT16 Windows (?)
0Eh
Windows DOS FAT16 LBA-mapped
logical-block-addressable VFAT (same as 06h but using LBA-mode INT 13h)
Extended Fat16-Partition
0Fh
Windows Extended partition LBA-mapped
logical-block-addressable VFAT (same as 05h but using LBA-mode INT 13h);
type 0Fh is used instead of 05h if extended partition exceed 1024 cylinders
(Windows 95B/98);
Primary FAT16-Partition (Windows 95)
Windows 95 uses 0Eh and 0Fh as the extended-INT13h equivalents of 06h
and 05h.
15h Extended partition hidden
1Bh Windows FAT32 partition hidden
1Ch
Windows FAT32 partition LBA-mapped hidden
(using LBA-mode INT 13h extensions)
1Eh Windows FAT16 partition hidden (LBA VFAT)
21h
1. officially listed as reserved
(HP Volume Expansion, SpeedStor variant)
2. FSo2 (Oxygen File System)
42h
1. Windows 2000 dynamic extended partition marker (pure dynamic disks)
2. Linux swap (sharing disk with DRDOS)
3. SFS (Secure File System) for DOS
SFS is an encrypted file system driver for DOS on 386+ PCs, written by Peter
Gutmann.
44h
GoBack partition
GoBack is a utility that records changes made to the disk, allowing you to
view or go back to some earlier state. It takes over disk I/O like a Disk
Manager would, and stores its logs in its own partition.
[http://www.goback.com/]
50h
1. OnTrack Disk Manager (older versions), read-only partition
Disk Manager is program from OnTrack to access ATA disks larger than 504
MB under DOS. Linux kernel version older than 1.3.14 cannot be used
together with DM.
[http://www.ontrack.com/]
2. Lynx RTOS
[http://www.lynuxworks.com/]
3. Native Oberon (alt)
51h
1. OnTrack Disk Manager (DM6 Aux1), read/write partition
2. Novell52
53h OnTrack Disk Manager 6.0 Aux3, write-only partition?
54h OnTrack Disk Manager 6.0 DDO (Dynamic Drive Overlay)
55h StorageSoft EZ-BIOS - EZ-Drive, Maxtor, MaxBlast, and DriveGuide
(see also INT 13h/AH=FFh "EZ-Drive")
EZ-Drive is another disk manager (MicroHouse, 1992). StorageSoft is a
new mark for EZDrive and DrivePro.
[http://www.storagesoft.com/]
Linux kernel version older than 1.3.29 cannot be used with EZD.
61h SpeedStor (Disk Manager type)
86h 1. Windows NT Legacy Fault Tolerant or volume/stripe set FAT16 volume
2. Old Linux RAID partition super block
87h 1. HPFS Fault-Tolerant mirrored partition
2. Windows NT Legacy Fault Tolerant or volume/stripe set NTFS volume
8Bh Windows NT Legacy Fault Tolerant FAT32 volume
8Ch Windows NT Legacy Fault Tolerant FAT32 volume using BIOS ext. INT 13h
A0h Laptop hibernation partition
Reported for various laptops like IBM ThinkPad, Phoenix Note BIOS, Toshiba
under names like zero-volt suspend partition, suspend-to-disk partition,
saveto-
disk partition, power-management partition, and hibernation partition.
Usually at the start or end of the disk area. (This is also the number used
by
Sony on the VAIO. Recent VAIOs can also hibernate to a file in the file
system, the choice being made from the BIOS setup screen.)
Phoenix Note BIOS Power Management "Save-to-Disk" partition
A1h 1. officially listed as reserved
2. Laptop hibernation partition
Reportedly used as "Save-to-Disk" partition on a NEC 6000H notebook. Types
A0h and A1h are used on systems with Phoenix BIOS; the Phoenix PHDISK
utility is used with these.
3. HP Volume Expansion (SpeedStor variant)
According to PowerQuest ID's 21h, A1h, A3h, A4h, A6h, B1h, B3h, B4h, B6h
are for HP Volume Expansion (SpeedStor variant).
A3h 1. officially listed as reserved
2. HP Volume Expansion (SpeedStor variant)
A4h 1. officially listed as reserved
2. HP Volume Expansion (SpeedStor variant)
B1h 1. officially listed as reserved
2. HP Volume Expansion (SpeedStor variant)
B3h 1. officially listed as reserved
2. HP Volume Expansion (SpeedStor variant)
B4h 1. officially listed as reserved
2. HP Volume Expansion (SpeedStor variant)
B6h 1. officially listed as reserved
2. HP Volume Expansion (SpeedStor variant)
3. Windows NT mirror set (master), FAT16 file system
B7h 1. Windows NT mirror set (master), NTFS file system
2. BSDI BSD/386 file system (secondarily swap)
C6h 1. Windows NT FAT16 volume/stripe set (corrupted)
2. Windows NT FAT16 mirror set (slave)
3. DR-DOS 6.0 LOGIN.EXE-secured Huge FAT16 partition over 32 MB
DR-DOS 6.0 will add C0h to the partition type for a LOGIN.EXE-secured
partition (so that people cannot avoid the password check by booting from an
MS-DOS floppy). Otherwise, it seems that the types C1h, C4h, C5h, C6h and
D1h, D4h, D5h, D6h are used precisely like 01h, 04h, 05h, and 06h.
C7h 1. Windows NT NTFS volume/stripe set (corrupted)
2. Windows NT NTFS mirror set (slave)
3. Syrinx Boot
E2h DOS read-only (Florian Painke's XFDISK 1.0.4)
E3h 1. DOS read-only
2. Storage Dimensions/SpeedStor
EEh Indication that this legacy MBR is followed by an EFI header
EFh Partition with an EFI (Extensible Firmware Interface) file system
MS plans to use EEh and EFh in the future for support of non-legacy BIOS
booting. These types are used to support the Extensible Firmware Interface
specification (EFI); go to developer.intel.com and search for EFI. (For the
types EEh and EFh, see Tables 16-6 and 16-7 of the EFI specification,
EFISpec_091.pdf.)
FEh
1. Windows NT Disk Administrator hidden partition
Windows NT Disk Administrator marks hidden partitions (i.e. present but not
to be accessed) as type FEh.
A primary partition of this type is also used by
IBM to hold an image of the "Reference Diskettes" on many of their machines,
particularly newer PS/2 systems (at a rough guess, anything built after
about
1994). This clash can cause major confusion and grief if running NT on IBM
kit. When this Reference Partition is activated, it changes its type into 1
(FAT12) and hides all other partitions by adding 10h to the type.
2. SpeedStor over 1024 cyl.
3. LANstep
4. IBM PS/2 IML (Initial Microcode Load) partition (image of the Reference
Diskettes) (located at the end of disk)
5. Linux LVM (Logical Volume Manager) partition (old)
This has been in use since the early LVM days back in 1997, and has now
(Sept. 1999) been renamed 8Eh.
FFh Xenix bad block table (BBT)
____end___
There are several above which may be of interest during this discussion
(while we wait for Jeff to reply on his chosen removal technique, and
indicate how far alone the test is.).
Does anyone have others which might interfer with the removal of XP NTFS
which should be placed here, or which are known as applying in XP NTFS?
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"MEB" <meb@not re...@hotmail.com> wrote in message
news:%23bSM1ad...@TK2MSFTNGP05.phx.gbl...
Franc Zabkar
put finger to keyboard and composed:
>Step 1 completed.
>
>Thank you for verifying that Win98 FDisk will not remove NTFS.
Not according to this MVP:
http://www.michaelstevenstech.com/remove_xpntfs.html
The only hitch he mentions involves extended partitions, although I'm
not sure exactly what he means by a non-DOS *partition* inside an
extended partition.
Here is an excerpt:
====================================================================
Remove XP when XP is installed on NTFS file system
--------------------------------------------------
Use a Windows 98/Me startup disk to delete the non-dos partition.
Note you cannot delete a NON-DOS partition located inside an Extended
partition. You can use the DOS utility called delpart from a DOS boot
up.
====================================================================
Franc Zabkar
put finger to keyboard and composed:
> Perhaps it's time to address partition types associated with DOS and
>Windows, which might be encountered during Jeff's review process.
Why obfuscate the issue with a discussion of anything other than FAT32
and NTFS? After all, your contention is that Win98 is unable to
reclaim all of the space formerly assigned to a Windows XP NTFS
partition. In fact, why introduce distractions such as encryption,
compression, or even extended partitions? AFAICS, any investigation
into lost capacity only needs to look at how the hard drive reports
its size, how/where the BIOS stores this information, what
translation(s) the BIOS and/or the OS performs, and how a partition
table is structured. If Fdisk cannot correctly determine the drive's
size, then you shouldn't need to look beyond physical sector 0,
especially if there are no extended partitions. You certainly don't
need a plethora of high powered forensic utilities.
Here's how I would attempt to recover, or at least analyse, the HD in
the "Everest" thread.
First I'd find out where the BIOS stores the drive's geometry. The
following represents the contents of the first 64 bytes of my CMOS RAM
(Standard CMOS configuration).
0000 14 00 49 40 13 00 02 29-09 06 26 02 50 80 00 00
0010 40 8F FF C0 0B 80 02 FF-FF 2F 2F 90 62 10 00 00
0020 3F 62 34 0F 00 00 3F 00-00 00 6B 6B A9 A1 09 BC
0030 FF FF 20 81 80 D0 07 00-00 00 00 00 00 00 07 62
The original IBM AT spec defined a "reserved" area from bytes 19 to
2D. My machine has a 1999 version of AMI BIOS which uses this area for
its "user" drive types (my earlier 486 AMI BIOS allocates this area
slightly differently).
Some experimentation suggests that bytes 19 and 1A hold the drive
types for primary master and slave (2F = 47 dec). Bytes 1B/1C are the
low/high cylinder bytes for the primary master (x6290 = 25232), and
bytes 21/22 correspond to the slave (x3462 = 13410). Bytes 20 and 26
contain the sectors/track (x3F = 63), and bytes 1D and 23 are the
numbers of heads (x10 = 16, x0F = 15).
You can use a utility such as CMOStool to view/save/restore your CMOS
RAM:
http://cdn.simtel.net/pub/simtelnet/msdos/sysutl/cmostool.zip
Otherwise you can manipulate the CMOS RAM (IO ports 70/71) using DOS
Debug.
My next task would be to retrieve the geometry information directly
from the drive via the IDE Identify Drive command. Here is a
description of the relevant words returned by the drive:
http://tldp.org/HOWTO/Large-Disk-HOWTO-10.html#identify
Unfortunately I have yet to find a tool that produces sensible output.
All are at least 10 years old. Many produce negative figures for
capacity, some can't multiply (eg 16383 x 16 x 63 = 2000MB ???), and
Seagate's own Find-ATA utility produces hieroglyphics at the bottom of
the screen. Fortunately the latter can write the entire 512 byte block
to a file using the following command line (HD is Primary Slave):
find-ata p s d
This is ideal because it retrieves the raw data, not data that have
been manipulated, ignored, or misinterpreted by the programmer. These
data include the default CHS translation, the current CHS translation
(this could be altered by the BIOS or OS), default LBA capacity, and
48-bit LBA capacity (if the drive is large enough).
Here is a link to Find-ATA.exe and to the data files for each of my
two drives:
http://www.users.on.net/~fzabkar/IDE-identify/
Next I would retrieve the contents of physical sector 0 using MBRtool:
http://www.diydatarecovery.nl/downloads/MBRtool.zip
As stated elsewhere, this is how my 13GB HD looks:
http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/dcb5670fdeadb6df?dmode=source&hl=en
I would pay particular attention to the logical block count and how it
relates to the CHS translation that was used in creating the
partition.
Jeff Richards
confronted with partitioning it doesn't recognise, and will not delete the
partitions. It doesn't recognise NTFS and most overlays. That question has
been asked and answered here many times in the past - it's not a new
revelation.
Since it will be a Maxtor disk my chosen wiping technique is the Maxblast
write all zeroes option.
The disk will arrive in the next few days, and yes, I am doing the test
correctly.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:%23bSM1ad...@TK2MSFTNGP05.phx.gbl...
Jeff Richards
that the test results are faulty due to faulty verification tools)..news:%23MkA71j...@TK2MSFTNGP02.phx.gbl...
Jeff Richards
Some versions of FDISK will remove NTFS. No version of FDISK will remove
the data that was contained in the NTFS partition. As this data is what's
concerning you, what FDISK will or won't do with it is not relevant.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:uiHJIml5...@TK2MSFTNGP03.phx.gbl...
Jeff Richards
partition type is irrelevant.news:%23CAVVLr...@TK2MSFTNGP05.phx.gbl...
Dan W.
> W98 FDISK reports 'Unknown Partition Type" (or something similar) when
> confronted with partitioning it doesn't recognise, and will not delete the
> partitions. It doesn't recognise NTFS and most overlays. That question has
> been asked and answered here many times in the past - it's not a new
> revelation.
>
> Since it will be a Maxtor disk my chosen wiping technique is the Maxblast
> write all zeroes option.
>
> The disk will arrive in the next few days, and yes, I am doing the test
> correctly.
Jeff, would a utility such as Boot It, NG --- allow you to perform this
function -- a little off topic but I just wondered if you knew off the
top of your head and thanks in advance.
--
Dan W.
Computer User
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:eyPcZKt5...@TK2MSFTNGP05.phx.gbl...
Your suggesting I'm attempting to contaminate the test?
No. If your chosen wiping procedure was ZAP and WIPE as you had previously
presented in the other thread, then that would appear to be the one you
would have chosen, unless you use another technique for yourself.
Then perhaps, we would have found one that actually does work by using your
special technique, though then one would question why you presented ZAP and
WIPE rather than the other.
And if you have found a verification tool which validates the complete
removal, then perhaps a discussion of that tool would be in order.
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:cm94i2duvpqre0600...@4ax.com...
| On Tue, 3 Oct 2006 02:12:45 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| > Perhaps it's time to address partition types associated with DOS and
| >Windows, which might be encountered during Jeff's review process.
|
| Why obfuscate the issue with a discussion of anything other than FAT32
| and NTFS? After all, your contention is that Win98 is unable to
| reclaim all of the space formerly assigned to a Windows XP NTFS
| partition. In fact, why introduce distractions such as encryption,
| compression, or even extended partitions? AFAICS, any investigation
| into lost capacity only needs to look at how the hard drive reports
| its size, how/where the BIOS stores this information, what
| translation(s) the BIOS and/or the OS performs, and how a partition
| table is structured. If Fdisk cannot correctly determine the drive's
| size, then you shouldn't need to look beyond physical sector 0,
| especially if there are no extended partitions. You certainly don't
| need a plethora of high powered forensic utilities.
You REALLY don't get this at all do you, Franc.
When encounter any areas which can not be addressed or accessed, the areas
will be handled under one of several activities.
Read on S.M.A.R.T. activities and what they do to a drive. While your at
it, read on what fdisk and format do when they encounter areas that they
also can't address or access.
You will find they, at times, use "reserved" sectors, and by doing so, use
up available future use of the disk. Sure, you may find the disk still
offers the supposed full disk, but at the expense of potential early drive
failure, potential future corruption due to some type of disk activity which
might attempt to use the SUPPOSED bad areas, and a number of other things.
So merely looking for available disk space is not only ludicrous, it fails
to address the activities which NT NTFS in general, and in particular XP
NTFS does to the disk.
Of course your material is relevant, but it happens to address the issues,
as if hard drives are still being used as in the original DOS, BIOSs,
controller chips, hard drive controllers, and the older OSs. They are not
the same, not even close.
MEANDISK http://www.unc.edu/~ertaylor/meandisk/index.htm, which I have
referenced before, does a number of things to the disk.
Please read and compare to what you have presented.
Included in the information for the program:
Biblio-linkography:
http://home7.inet.tele.dk/batfiles/intro/contents.htm
http://www.firmware.com/support/bios/hdclear.htm
http://members.aol.com/axcel216/secrets.htm#FORMAT-SU
http://www.windrivers.com/hd/debug.htm
http://www.users.intercom.com/~ranish/part/
http://www.computing.net/faq/contentdos/badsector.html
http://support.microsoft.com/support/kb/articles/q106/4/19.asp
http://www.robvanderwoude.com/index.html
http://www.32bit.com/reviews/article/41/
http://www.32bit.com/pages/search.php3?search=bcwipe&advanced=
http://www.jetico.sci.fi/index.htm#/bcwipe.htm
____END____
Yet, my testing research shows this does NOT work to completely remove XP
NTFS or it's control of various areas of the hard drive, so apparently we
are dealing with, as Microsoft claimed, something far different.
MEANDISK completes successfully, wipes the normal NTFS areas, but fails to
remove XP NTFS most protected areas. Therefore, I thought it prudent to
include information on partitions which might be encountered in XP NTFS and
several of its activities which include compression and encryption, which
you would know had you researched XP NTFS.
SO your continued attempts to ignore these newest activities in XP NTFS
acheives nothing, and it would apparently work towards early hard drive
failure or worse, perhaps loss a large sections of the hard drive.
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:uijrvJt5...@TK2MSFTNGP03.phx.gbl...
I had presumed you would.
real@hotmail.com MEB
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:eA1OFWt5...@TK2MSFTNGP04.phx.gbl...
jt3
quarreling with the results.
:-)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:%23gvgZHx...@TK2MSFTNGP06.phx.gbl...
Franc Zabkar
<JRic...@msn.com.au> put finger to keyboard and composed:
>W98 FDISK reports 'Unknown Partition Type" (or something similar) when
>confronted with partitioning it doesn't recognise, and will not delete the
>partitions. It doesn't recognise NTFS and most overlays. That question has
>been asked and answered here many times in the past - it's not a new
>revelation.
I don't have an XP/NTFS disc to test (I'm trying very hard to get hold
of one, though), but the following text strings appear inside
fdisk.exe (64,460 bytes, 05-18-00 8:35a).
PRI DOS, XENIX, EXT DOS, PC/IX, NTFS, NOVELL, CP/M, Non-DOS
"Your computer has NTFS partitions which may require large drive
support. If you are using another operating system, such as Windows
NT, which supports large drives you should enable treating these
partitions as large. NOTE: If you answer Y and the partition display
looks incorrect or a hang or crash occurs do nothing, run FDISK again,
and answer N to this question. Should NTFS partitions on all drives be
treated as large (<Y>/<N>)?"
>Since it will be a Maxtor disk my chosen wiping technique is the Maxblast
>write all zeroes option.
>
>The disk will arrive in the next few days, and yes, I am doing the test
>correctly.
- Franc Zabkar
real@hotmail.com MEB
cloning to the new (that would be a OLD installation to work with); whether
the new disk is small enough to search and the tools he intends to use; and,
well, we'll find out, I'm sure. I'm just happy he IS doing a test.
Perhaps Franc will also find one.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"jt3" <j...@cranky.computer> wrote in message
news:%23pZqXBz...@TK2MSFTNGP03.phx.gbl...
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:ezot2Lt5...@TK2MSFTNGP05.phx.gbl...
| No, it would not be conclusive. It's entirely irrelevant.
|
| Some versions of FDISK will remove NTFS. No version of FDISK will remove
| the data that was contained in the NTFS partition. As this data is
what's
| concerning you, what FDISK will or won't do with it is not relevant.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
Sorry, don't know how I failed to respond to this. It says condusive, NOT
conclusive.
Of course it would be relevant to clarify what your statement meant,
particularly what fdisk you might have been referring to, or using.
EVERYTHING is relevant, even Franc's activities.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
Franc Zabkar
<fza...@iinternode.on.net> put finger to keyboard and composed:
>On Tue, 3 Oct 2006 19:57:47 +1000, "Jeff Richards"
><JRic...@msn.com.au> put finger to keyboard and composed:
>
>>W98 FDISK reports 'Unknown Partition Type" (or something similar) when
>>confronted with partitioning it doesn't recognise, and will not delete the
>>partitions. It doesn't recognise NTFS and most overlays. That question has
>>been asked and answered here many times in the past - it's not a new
>>revelation.
>
>I don't have an XP/NTFS disc to test (I'm trying very hard to get hold
>of one, though), but the following text strings appear inside
>fdisk.exe (64,460 bytes, 05-18-00 8:35a).
>
> PRI DOS, XENIX, EXT DOS, PC/IX, NTFS, NOVELL, CP/M, Non-DOS
>
>"Your computer has NTFS partitions which may require large drive
>support. If you are using another operating system, such as Windows
>NT, which supports large drives you should enable treating these
>partitions as large. NOTE: If you answer Y and the partition display
>looks incorrect or a hang or crash occurs do nothing, run FDISK again,
>and answer N to this question. Should NTFS partitions on all drives be
>treated as large (<Y>/<N>)?"
I've just had a chance to look at a working XP/NTFS drive using
Win98SE Fdisk and various DOS based utilities. I can confirm that the
above warning message does appear. The drive is a 200GB Western
Digital Caviar WD2000JB.
An "fdisk /status" command produces the following:
Disk Drv Mbytes Free Usage
1 19078 0 1100
%
The "%" symbol wraps to the next line.
As expected, because of Win98's lack of support for 48-bit LBA, the
above output is nonsensical. However, when I display the existing
partition table (option 4), I get the following:
Partition Status Type Volume Label Mbytes System Usage
1 A NTFS 51089 27%
2 NTFS 49623 26%
3 NTFS 48689 26%
4 NTFS 41378 22%
Total disk space is 19078 Mbytes (1 Mbyte = 1048576 bytes)
According to the spec sheet, the drive has 390,721,968 user sectors:
http://www.wdc.com/en/products/products.asp?DriveID=38
This is confirmed by Seagate's Find-ATA utility which detects 1749F1B0
sectors in 48-bit LBA mode. The 512 byte block returned by the IDE
Identify Drive command is here:
http://www.users.on.net/~fzabkar/200GBdata/ID_DRV0.ATA
These are the contents of the MBR and partition table as reported by
MBRtool:
http://www.users.on.net/~fzabkar/200GBdata/MBRTOOL.DMP (text)
http://www.users.on.net/~fzabkar/200GBdata/MBR_DRV0.128 (binary)
This is the partition table:
Geometry values (from BIOS!) for this disk : (C/H/S) - 1022/254/63
Partition Table Information
ACT TYPE START-C/H/S END----C/H/S LBA-start LBA-length
Entry 1: 128 07 0 1 1 1022 254 63 63 104631282
Entry 2: 0 07 1022 0 1 1022 254 63 104631345 101627190
Entry 3: 0 07 1022 0 1 1022 254 63 206258535 99715455
Entry 4: 0 07 1022 0 1 1022 254 63 305973990 84742875
Note that the BIOS (Intel P4 motherboard) reserves one cylinder (max
cyl number is 1022 not 1023).
The total usable capacity is 305973990 + 84742875 = 390716865 sectors.
This is 5103 sectors (= 81 tracks) short of the full LBA capacity.
This number also falls on a cylinder boundary, ie 390716865 = 24321 *
255 * 63. Strangely, the usable area includes the reserved cylinder.
FWIW, here are the first 128 bytes of CMOS RAM:
http://www.users.on.net/~fzabkar/200GBdata/CMOSBAK.BIN
Unlike AMIBIOS, I don't see any drive geometry data, nor do I see any
CHS or LBA info in any of the BIOS configuration screens.
BTW, the drive appears to have been partitioned by Paragon, so I'm not
sure if the data structures are strictly valid in the context of the
present discussion. Anyway, here are the contents of the first track:
http://www.users.on.net/~fzabkar/200GBdata/TRK0DRV0.128
Jeff Richards
data from a hard drive. It is a tool to remove the partitioning. This was
the point of the original post. You haven't been paying attention.
ZAP or Wipe will remove boot record and partition information. They are
perfectly effective at allowing FDISK to run, by overcoming the FDISK
aversion to doing anything with a partition it doesn't recognise. For this
task they DO work with NTFS, because they remove the NTFS partition details.
No-one with any knowledge of these utilities would recommend either utility
for removing all the data from the disk, and I certainly did not. The
documentation for these utilities makes this quite clear.
My chosen disk erasing tool is the utility provided by the hard drive
manufacturer.
Most verification tools work just fine and do not justify discussion. The
only exception I have come across was one that failed to recognise invalid
sector numbers and happily returned random data as the contents of a
non-existent part of the disk, but I quickly got rid of it and I now can't
remember what it was.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:%23gvgZHx...@TK2MSFTNGP06.phx.gbl...
> snip <
Jeff Richards
sense. Re-phrase the point you were trying to make.
--
Jeff Richards
MS MVP (Windows - Shell/User)
Jeff Richards
entirely sure about what will be reported, or how accurately. Certainly by
the latest W98SE version NTFS was properly identified. But the incorrect
display for large drive seems to apply to most versions. And anything over
128Mb is going to confuse it something awful.
Partition information is just numbers, and there's no reason it shouldn't be
reported correctly (apart from the known display problem). This will be
independent of whether or not the system can access these regions.
There are plenty of variables available to a partitioning program, and the
question of which is right or wrong becomes somewhat moot, as long as the
scheme works. FDISK is more conservative in rounding down to the next
cylinder than some other partitioning utilities (perhaps it's unsure of
whether the BIOS has already reserved that cylinder or not, and just adds
another in case). And all the utilities report their numbers slightly
differently. But, overall, I wouldn't trust anything that a W98 or W98SE
FDISK says about a disk larger than 128Gb, and I think that's most of what
you're seeing here.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:r7n6i2l0ldjcbu8tq...@4ax.com...
Jeff Richards
Look at the description of the process it uses. It requires the disk to be
partitioned, and then writes data to the file storage area of the partition.
This will NOT remove the previous data from the disk, because the file
storage area of the partition is only a part of the total disk space. Franc
has explained this.
Do NOT use an erasing utility that relies on an installed file system to
access the disk if you want to remove everything.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:u87p9Hx5...@TK2MSFTNGP06.phx.gbl...
>
> snip <
real@hotmail.com MEB
Your about to do a test;
Your about to produce results pursuant that test;
You have made a statement pursuant fdisk;
A test requires the variables of such test be defined, as you noted;
As you have properly noted the term would be conducive;
You were well aware of the intent;
We are now discussing grammar and semantics rather than the test;
Your apparently doing so intentionally;
The is not part of the test nor necessary to the test.
Answer the question and clarify what YOU meant.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:ugsx6q55...@TK2MSFTNGP02.phx.gbl...
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:e1SLlp55...@TK2MSFTNGP05.phx.gbl...
| Uh? The point I was making was that ZAP or Wipe is NOT a tool to remove
| data from a hard drive. It is a tool to remove the partitioning. This
was
| the point of the original post. You haven't been paying attention.
Oh, but I have.
I think if you carefully review these posting, you would note, I have
directed the discussion down a distinct path, including this one.
|
| ZAP or Wipe will remove boot record and partition information. They are
| perfectly effective at allowing FDISK to run, by overcoming the FDISK
| aversion to doing anything with a partition it doesn't recognise. For this
| task they DO work with NTFS, because they remove the NTFS partition
details.
Then you would feel comfortable using them upon the disk you intend to use
for your test, is that correct?
Your statement is "they DO work with NTFS, because they remove the NTFS
partition details. (taken in context of the paragraph)". Would you care to
modify this statement in some form, or is this the final statement?
|
| No-one with any knowledge of these utilities would recommend either
utility
| for removing all the data from the disk, and I certainly did not. The
| documentation for these utilities makes this quite clear.
|
| My chosen disk erasing tool is the utility provided by the hard drive
| manufacturer.
Then explain why you feel more comfortable using this tool, rather than ZAP
and WIPE.
|
| Most verification tools work just fine and do not justify discussion. The
| only exception I have come across was one that failed to recognise invalid
| sector numbers and happily returned random data as the contents of a
| non-existent part of the disk, but I quickly got rid of it and I now can't
| remember what it was.
Sure they do.
A broad statement may START a discussion, but when discussing issues
relevant to your test results and your intent to use this or these tools for
such verification process within your test, the tools do need some
definition and discussion.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
real@hotmail.com MEB
Maybe you missed this in the prior post, I think it's from WINHEX PDF, but
don't quote me on that, it's just part of the collected information in a
text file I created while working with these disks:
From somewhere, it remains the property of the creator, whomever that is:
The main characteristics of the NT file system are described by the boot
record. The file system starts at the location of the boot sector and ends
at this sector plus the sectors in the volume field. The volume is organized
in clusters of multiples of 512 bytes. The start of the volume is associated
with cluster number 0.
Any addressing within the file system is done using the cluster number
instead of a sector number. Any kind of file information is contained in a
structure called Master file table (MFT). The start of the MFT is indicated
by the boot sector's field 1st MFT cluster. The MFT is a database containing
information about every file or directory on the volume. The default size of
an entry in the MFT is 1024 bytes. Each entry describes a file or directory
on the volume (including the MFT itself) and has a record number that equals
the byte position inside the MFT divided by 1024. Each MFT entry consists of
a header and a list of attributes. The attributes describe file names, time
stamps, file sizes, data allocations and more....
$90 Index root: if the entry is a directory, this attribute describes the
root of a binary tree in which the directory entries are located,
$A0 Index allocation: if the entry is a directory, this attribute contains a
list of file names.
If the attributes are too large to fit into 1024 bytes, some of them will be
non-resident, meaning the value part the specific attribute will be found
outside of the entry. In this case the outside data allocation will be
described by a run list. A run list is a list of clusters used. ...
________END_
SOME MORE THEORY
Let's say NTFS does as it claims and uses cluster numbering rather than
standard CHS sector numbering to identify it's areas and files.
Let's also say that XP NTFS creates several sub-partitions within its
assigned partition. To mark these partitions it uses special partition
indicators which might have once been assigned to other programs or OSs or
which are known as applying.
Let's also say that it also creates several hidden partitions within its
assigned partition.
And to address all these new variables, it creates a master cluster list
somewhere on the disk which would include the numbering of all usable
clusters, perhaps as defined by partition indicator.
Let's theorize XP NTFS places a ECC code or other code indicating a sector
can't be used, at the proper place in the sector, but places information it
wishes to protect behind that error indicator at it's XP NTFS clustering
number.
XP NTFS can still access the data because it does not see the error at the
sector head; perhaps it uses a master clustering table (or something along
those lines) and applicable MFT to locate the EXACT clusters. All the data
is there and accessible to XP, but it's not accessible to what would have
been considered, normal use or testing.
Any normal tool which addresses the disk through the CHS values, sector
numbering, or the bios, would see the sector is not usable and return a CRC
or ECC error; it is marked that way after all (in this theory). The normal
tool would also likely respect the partition indicators even if they were
not in the standard format, or were assigned some type of hidden status (per
this theory).
Uniquely, this would also appear to effect any tools which do sector by
sector reads and/or over-writes, or individual sector analysis. Sector
recovery tools would or might balk at recovery, particularly if there were
something which was protecting those areas.
Remember, this is all theory.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:eQvnY455...@TK2MSFTNGP02.phx.gbl...
cquirke (MVP Windows shell/user)
>W98 FDISK reports 'Unknown Partition Type" (or something similar) when
>confronted with partitioning it doesn't recognise, and will not delete the
>partitions. It doesn't recognise NTFS and most overlays. That question has
>been asked and answered here many times in the past - it's not a new
>revelation.
Ah... the devil's in the details ;-)
I use the term "partition" to refer to a system-level structure that
contains and/or is for use by an OS. By "system-level", I mean before
and outside of any particular OS, much as applies to the BIOS.
BIOS jumps into Master Boot Record code that is an extension of the
system, belonging to no OS. This manages the partition table, which
is also system-level, belonging to no OS - and this table is limited
to ony 4 partition entries!!
Only once you look at entries within the partition table, and the
contents of the partitions they define, do you get into OS territory.
Each OS "owns" some type identifiers, and what it does inside those
types of partitions is the OS's own business.
One of the types "owned" by MS is the "extended partition". MS
chooses to use this partition type as a container for multiple
"logical volumes" defined within the partition itself, and to which it
assigns drive letters as it does to its own "primary partition" types.
This is great, because we can have more than 4 volumes, free of the
system-level partition table limit. In fact, we can have an
alphabet-2 number of volumes while using only 2 partitions on a
bootable drive, or 1 on a drive that doesn't have to boot.
FDisk is both a system-level and an OS-level tool.
At the system level, it can delete any type of partition (option 1:
delete primary; option 2: delete extended; option 4: delete non-MS).
At the OS level, it can create MS partitions with OS-appropriate boot
records, and it manages the logical volumes within extended
partitions, e.g. delete option 3: logical volume.
But while FDisk expects to see non-MS partitions and will delete them,
it does not expect unfamiliar intrusions into MS's own extended
partition space - there's only supposed to be "MS" things there.
It seems as if this extends to NTFS logical volumes too - even though
these are MS, they may not be known to FDisk, especially MS-DOS
versions of FDisk that predate the development of NTFS.
All of the above is from memory, BTW - hopefully I haven't got mixed
up on what FDisk will or will not do. I seldom use it anymore.
In fact, it's a bit alarming how folks still seem to be using it,
given the capacity limitations that apply. It's never going to be
safe over 137G, and the versions that ship with Win95-98SE can't cope
with capacities over 50G or so.
Even when that limitation was fixed, you can't enter capacity sizes
over 99G (the numeric input field is too small).
Perhaps folks don't notice these limitations if all they do is delete
partitions, make one big duhfault C:, and the /MBR trick?
>------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
>------------ ----- --- -- - - - -
Franc Zabkar
<JRic...@msn.com.au> put finger to keyboard and composed:
>Uh? The point I was making was that ZAP or Wipe is NOT a tool to remove
>data from a hard drive. It is a tool to remove the partitioning. This was
>the point of the original post. You haven't been paying attention.
The original *intent* of Wipe was to zero the entire drive, although
CHS addressing effectively limits it to 8GB or maybe even less.
See http://www.digitalissues.co.uk/html/os/misc/ibm-wipe-zap.html
====================================================================
1. What are the IBM Wipe and Zap Utilities?
In 1996, IBM created two excellent utilities called Wipe and Zap. ZAP
writes the first 128 logical blocks of the drive with 00h pattern,
starting at Cylinder 0, Head 0, Sector 1.
This will very quickly wipe the FAT and boot sector, often necessary
since Dos's Fdisk struggles 'seeing' non-dos partition types.
WIPE writes the COMPLETE drive with 00h pattern, starting at Cylinder
0, Head 0, Sector 1 and ending with Max Cylinder, Max Head, and Max
Sector.
====================================================================
>ZAP or Wipe will remove boot record and partition information. They are
>perfectly effective at allowing FDISK to run, by overcoming the FDISK
>aversion to doing anything with a partition it doesn't recognise. For this
>task they DO work with NTFS, because they remove the NTFS partition details.
>
>No-one with any knowledge of these utilities would recommend either utility
>for removing all the data from the disk, and I certainly did not. The
>documentation for these utilities makes this quite clear.
The author of the page referenced above writes:
"As I understand it, WIPE suffers from the old 8 GB barrier meaning it
will write zeros up to only 8GB."
Since the OP's Maxtor drive has a capacity of 7GB, I would think that
Wipe should probably still work as intended.
>My chosen disk erasing tool is the utility provided by the hard drive
>manufacturer.
>
>Most verification tools work just fine and do not justify discussion. The
>only exception I have come across was one that failed to recognise invalid
>sector numbers and happily returned random data as the contents of a
>non-existent part of the disk, but I quickly got rid of it and I now can't
>remember what it was.
- Franc Zabkar
Franc Zabkar
put finger to keyboard and composed:
>"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
>news:gd6uh2p6j89e0h0ht...@4ax.com...
>| On Thu, 28 Sep 2006 23:51:39 -0400, "MEB" <meb@not re...@hotmail.com>
>| put finger to keyboard and composed:
>| The Format command should at least have told you the size of the
>| partition that was being formatted, ie "Formatting nnnnM, x%
>| completed" or something like that. The /u switch should have forced
>| Format to test every sector by writing an F6 pattern to it. Any
>| "protected" sector would have generated a bad sector error. If 10% of
>| your hard disk really was inaccessible, then you should have seen
>| hundreds of thousands of these errors.
>
>Depending upon where in the series of tests, it did exactly as you say, save
>for the hundreds of thousands, these areas are in large blocks for the most
>part.
>At 92% both fdisk and format (per last use) stumble for awhile trying to
>make sense out of what their looking at and what to do.
If I had been presented with so many errors I would have suspected a
head crash, ie a catastrophic media fault. What makes you so sure that
you are seeing some kind of "soft" phenomenon? The clue that you may
be seeing the result of a head crash lies in your observation that
these errors occur in "large blocks". This is *exactly* what one would
expect if, say, 1 R/W head/surface out of 4 was damaged. If the faulty
"zone" had, say, 1000 physical sectors per track, then you would
expect to see up to 1000 bad sectors followed by 3000 good ones, then
1000 more bad ones, then 3000 more good ones, and so on. Of course
this assumes that the debris resulting from head-to-disc contact
haven't contaminated the other platters.
>Which is why I directed you to look into how hard drives
>are made, so perhaps you would have a better understanding of what can
>occur.
Them's fightin' words! :-)
My earliest experience with hard drives included Control Data's BK7
series of 250kg monsters with 10-platter removeable disc packs. Every
nut and bolt had an orderable part number and the drive came with
several 2" thick service manuals. I used to repair these drives, and
their controllers, down to chip level. I've also replaced heads (all
20 of them), and even voice coils, after a head crash ... dozens of
times. I know what a dibit pattern looks like, and I know how to
perform a head alignment. In fact I wrote my own head alignment
program, in machine code, some 30 16-bit words in all, for a 1980's
minicomputer system. So I understand the structure of a sector, both
physical and "soft".
As for file systems, I may not know anything about NTFS, but I *do*
understand file systems in general. In fact, I wrote another 30-word
machine code program for the abovementioned computer specifically to
locate and repair the remnants of a totally foreign undocumented file
system. Its root directory had been zeroed, and its FMINFO sector,
where critical data were stored, had been wiped. I've also hacked the
cluster allocation tables in the same machine to recover reserved (=
wasted) data areas.
As for PCs, I have quite a bit of experience repairing broken file
systems during the early DOS days using the Norton Utilities. I have
also hacked the BIOS drive tables in early [undocumented] Award BIOSes
that predated user defined drive types. I've even hacked the boot
PROMs in the abovementioned minicomputer to enable booting from
non-standard drives.
So yes, I have quite a lot of experience with storage devices,
including reel-to-reel mag tape, at both hardware and software levels.
>| I prefer to use DOS based utilities for looking at disc structures.
>| IMHO, a protected mode, multitasking OS is not the right platform for
>| this kind of work.
>
> And you would be right for the most part. Buffered writes (even when turned
>off), interference from the Windows environment if it thinks you're doing
>something it doesn't want you to, and several other things you just don't
>have at a command level environment or even Linux (no! don't go there yet)..
I would think that buffering would be the least of your problems.
Instead I'd be worried that an application might try to access the
same sector that was currently being edited. And imagine the damage
you could do by editing the FATs.
In fact I recently experimented with my slave drive by using Debug, in
a Windows environment, to edit the volume label in the first copy of
its boot sector. I changed the name from BACKUPS to BUCKUPS (I was
thinking of a slightly different name) while an Explorer window was
open. Refreshing Explorer still showed the original BACKUPS label, and
a re-examination of the drive's boot sector with Debug showed BUCKUPS.
However, after exiting both Debug and Explorer and then relaunching
the latter, the label had changed to "N". This label persisted after a
reboot. I then restored the original volume name using Explorer, and a
subsequent Scandisk found no problems.
>| > Because after fdisking and formatting the disk is reduced from it's
>stated
>| >full capacity, which it finds. Scandisk it, and it will be reduced even
>| >more. Hence, it's now around 5.6 gig, which is as far as I'm willing to
>take
>| >it. It will be difficult enough to recover.
>|
>| How are you determining the capacity of the disc? Which utility is
>| telling you that you now have only 5.6GB?
>
>FDisk and format show reduced, they can't read or see the residuals.
> Every tool which has the ability, show potential full capacity, they may
>modify for USED space or "bad areas".
Your tools would be looking at the drive's reported capacity using the
IDE Identify Drive command. Fdisk would be looking at the BIOS report,
or the existing partition table.
>| >| Does TESTDISK's NTFS partition information correctly reflect the
>| >| native capacity of the HD as specified by its manufacturer? Have you
>| >| accounted for a reserved cylinder and/or surplus sectors?
>| >
>| > Yes
>|
>| Well, TestDisk thinks that my 13GB Seagate HD has 12732 *more* sectors
>| than its native capacity. <shrug> See my latest post in the "Everest"
>| thread.
>
> You probably do. Did you read what TESTDISK is actually showing you.
Now you're sounding like a conspiracy theorist. Do you honestly
believe any disk tool has a better idea of a drive's size than the
drive's manufacturer? In fact I can't seem to find *any* tool that
doesn't have at least one error. MS-DOS itself has a bug which is
responsible for our present 255 head limitation (the head count
register can support 256 heads).
See http://www.geocities.com/thestarman3/asm/mbr/DiskTerms.htm
"All versions of MS-DOS (including MS-DOS 7 [Windows 95]) have a bug
which prevents booting on hard disks with 256 heads (FFh), so many
modern BIOSes provide mappings with at most 255 (FEh) heads."
[INTER61 Copyright©1989-2000 by Ralf Brown].
>| >| > Using a disk editor shows a large amount of information stored beyond
>| >the
>| >| >CHS end boundary of the disk, including what appears to be a partition
>| >table
>| >| >and a boot sector.<grin>
>| >|
>| >| Are you seeing a wrap-around effect? If you make changes to the MBR
>| >| code or to the partition table, do these changes also appear at the
>ZIPPPPP
>| > Franc, if I choose to do so, I can edit the entire friggin disk by hand
>or
>| >by block replacement. Heck I can make the disk a full 7 gig and beyond,
>if
>| >that's what I want to look at.
>| > I have both DOS and Windows disk editing and FORENSIC tools, capable of
>| >just about anything, INCLUDING rewriting jump and other instructions on
>the
>| >disk.
>|
>| I'm not asking you to do anything exotic. I'm merely asking you to
>| change *one* harmless text byte in physical sector 0 in order to test
>| whether the same change is reflected beyond the CHS boundary of the
>| disc. This will confirm whether the effect you are seeing is due to
>| wrapping.
>
> Franc, at present I really don't care what you want, sorry, there's a test
>under way (hopefully).
Hmmm. You've given Jeff and myself a list of things to do that is as
long as my arm, and which will require several hours of setup, several
days of usage, and more hours of analysis, yet I ask you to test your
own observations by editing *one byte* and you tell me that you can't
be bothered. <shrug>
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:v7c8i2toc4dbvjnm2...@4ax.com...
ZAP and WIPE were presented as viable to use (not by me, I cautioned
against the use) in the Everest Report discussion.
That issue is presently moot, so it really has no bearing other than you are
correct on the 8 gig apparent limit, or so it seems.
BTW, there is no OP per this discussion, we are addressing issues and
theory regarding XP NTFS, which I thought prudent to do. It is a "general
technical discussion" (microsoft.public.win98.gen_discussion, the spirit of
discussion, which now includes testing as well) in its present form, not as
yet, the normal "HELP ME PLEASE" which is generally seen in these forums.
Not stating HELP MEs are in appropriate of course.
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:98c8i2hod8c1fee1u...@4ax.com...
Hmm, perhaps for one disk, but for two? I too, began the question as you
do, until I remembered seeing these same things on other disks.
Something didn't "jive" with my mind, therefore, though I had no spare
disks; time to do some tests.
Excellent, I thought you appeared to be extremely knowledgeable. I fully
expect that you will diagnose the issues, if any. Moreover, when this is
done, perhaps we CAN discuss recovery of this disk. Perhaps you can even
make your mark by writing the code or other which would take care of this.
We shall see.
|
| >| I prefer to use DOS based utilities for looking at disc structures.
| >| IMHO, a protected mode, multitasking OS is not the right platform for
| >| this kind of work.
| >
| > And you would be right for the most part. Buffered writes (even when
turned
| >off), interference from the Windows environment if it thinks you're doing
| >something it doesn't want you to, and several other things you just don't
| >have at a command level environment or even Linux (no! don't go there
yet)..
|
| I would think that buffering would be the least of your problems.
| Instead I'd be worried that an application might try to access the
| same sector that was currently being edited. And imagine the damage
| you could do by editing the FATs.
All one needs to do, is NOT make it a drive, and access the physical disk
via it's controller.
It negates any "OS" access because it is NOT a recognized disk and has NOT
been formatted.
|
| In fact I recently experimented with my slave drive by using Debug, in
| a Windows environment, to edit the volume label in the first copy of
| its boot sector. I changed the name from BACKUPS to BUCKUPS (I was
| thinking of a slightly different name) while an Explorer window was
| open. Refreshing Explorer still showed the original BACKUPS label, and
| a re-examination of the drive's boot sector with Debug showed BUCKUPS.
| However, after exiting both Debug and Explorer and then relaunching
| the latter, the label had changed to "N". This label persisted after a
| reboot. I then restored the original volume name using Explorer, and a
| subsequent Scandisk found no problems.
And the relevance to the test is what?
|
| >| > Because after fdisking and formatting the disk is reduced from it's
| >stated
| >| >full capacity, which it finds. Scandisk it, and it will be reduced
even
| >| >more. Hence, it's now around 5.6 gig, which is as far as I'm willing
to
| >take
| >| >it. It will be difficult enough to recover.
| >|
| >| How are you determining the capacity of the disc? Which utility is
| >| telling you that you now have only 5.6GB?
| >
| >FDisk and format show reduced, they can't read or see the residuals.
| > Every tool which has the ability, show potential full capacity, they may
| >modify for USED space or "bad areas".
|
| Your tools would be looking at the drive's reported capacity using the
| IDE Identify Drive command. Fdisk would be looking at the BIOS report,
| or the existing partition table.
Not necessarily.
|
| >| >| Does TESTDISK's NTFS partition information correctly reflect the
| >| >| native capacity of the HD as specified by its manufacturer? Have you
| >| >| accounted for a reserved cylinder and/or surplus sectors?
| >| >
| >| > Yes
| >|
| >| Well, TestDisk thinks that my 13GB Seagate HD has 12732 *more* sectors
| >| than its native capacity. <shrug> See my latest post in the "Everest"
| >| thread.
| >
| > You probably do. Did you read what TESTDISK is actually showing you.
|
| Now you're sounding like a conspiracy theorist. Do you honestly
| believe any disk tool has a better idea of a drive's size than the
| drive's manufacturer? In fact I can't seem to find *any* tool that
| doesn't have at least one error. MS-DOS itself has a bug which is
| responsible for our present 255 head limitation (the head count
| register can support 256 heads).
Where the truck do you people come up with all this conspiracy theory crap,
do you carry it around in your back pocket and pull it out when confronted
with information you don't like, or what?
Read it again, you task was done IT MAKES NO DIFFERENCE, there is no XP OS
to make that change in that table.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
--
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:uPzrRR6...@TK2MSFTNGP06.phx.gbl...
| Are you quoting MEANDISK as an example of how XP data can't be erased?
|
| Look at the description of the process it uses. It requires the disk to
be
| partitioned, and then writes data to the file storage area of the
partition.
| This will NOT remove the previous data from the disk, because the file
| storage area of the partition is only a part of the total disk space.
Franc
| has explained this.
|
| Do NOT use an erasing utility that relies on an installed file system to
| access the disk if you want to remove everything.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
| "MEB" <meb@not re...@hotmail.com> wrote in message
| news:u87p9Hx5...@TK2MSFTNGP06.phx.gbl...
| >
| > snip <
SO your considered opinion, citing Franc's statements, is MEANDISK is
incapable of removing XP NTFS under and or pursuant the scenario you
described, is this correct?
What would be the considered opinion of successful XP NTFS removal
concerning:
http://www.lsoft.net/
http://www.killdisk.com/downloads/killdiskfloppysetup.exe
Active@ KILLDISK for DOS (Demo/Free Version)
Copyright (c) 1999-2003
LSoft Technologies Inc.
Dan W.
> Sure:
> Your about to do a test;
> Your about to produce results pursuant that test;
> You have made a statement pursuant fdisk;
> A test requires the variables of such test be defined, as you noted;
> As you have properly noted the term would be conducive;
> You were well aware of the intent;
> We are now discussing grammar and semantics rather than the test;
> Your apparently doing so intentionally;
> The is not part of the test nor necessary to the test.
>
> Answer the question and clarify what YOU meant.
>
>
Please MEB, Jeff was just trying to make one small correction and I
would not take it so personally. I have been corrected before and I
just apologize, take it as a learning experience and move on to the next
topic. It just takes too much time to argue back and forth and the net
result is that nothing is really ever accomplished by these actions. I
hope your test goes well and I hope you and Jeff both enjoy the rest of
your week.
Dan W.
Please start a new topic on Wipe and Zap Franc. and btw does ZAP support
current large hard drives. You are welcome to answer as a new post so
we don't irritate MEB.
Dan W.
> It seems that you are using a W98SE version of FDISK, not W98, so I'm not
> entirely sure about what will be reported, or how accurately. Certainly by
> the latest W98SE version NTFS was properly identified. But the incorrect
> display for large drive seems to apply to most versions. And anything over
> 128Mb is going to confuse it something awful.
>
> Partition information is just numbers, and there's no reason it shouldn't be
> reported correctly (apart from the known display problem). This will be
> independent of whether or not the system can access these regions.
>
> There are plenty of variables available to a partitioning program, and the
> question of which is right or wrong becomes somewhat moot, as long as the
> scheme works. FDISK is more conservative in rounding down to the next
> cylinder than some other partitioning utilities (perhaps it's unsure of
> whether the BIOS has already reserved that cylinder or not, and just adds
> another in case). And all the utilities report their numbers slightly
> differently. But, overall, I wouldn't trust anything that a W98 or W98SE
> FDISK says about a disk larger than 128Gb, and I think that's most of what
> you're seeing here.
Good Point Jeff. I think the only way that you may be able to overcome
the 137 GB hard drive barrier of 98 Second Edition is through a
controller card, but I have no experience doing this and have just read
about it in other posts.
Dan W.
So, Chris would the solution be to use a utility such as I have done
called Boot It NG that was kindly suggested by PCR to overcome these
limitations. In addition, do you know if a controller card can overcome
the software limitation of the 137 Gigabyte barrier of 98 Second
Edition? I was posting about this just before and I am not sure so I
want your input on this issue please and thanks in advance.
real@hotmail.com MEB
Did you have something to contribute to the discussion?
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Dan W." <spa...@user.nec> wrote in message
news:%23LaDajD...@TK2MSFTNGP03.phx.gbl...
Franc Zabkar
put finger to keyboard and composed:
>Step 1 completed.
>
>Thank you for verifying that Win98 FDisk will not remove NTFS.
>
> What is you chosen wiping technique?
> You are doing the test correct?
I now have a 2.5GB Western Digital Caviar HD, model AC22500L, with an
NTFS file system. The owner tells me that it probably contains bad
sectors (the reason why it was withdrawn from service?). The HD's
manufacture date is 1997, and it comes from an office environment, so
I presume the OS is NT. What would be the quickest way for me to
determine if it is NT, or Win2K or XP?
Anyway, the drive is detected by my AMI BIOS as follows:
Size Cyl Heads WPcom Sec LBA mode Block mode PIO
2560 4960 16 0 63 ON ON 4
When translated, this gives C/H/S = 620/128/63.
Fdisk /status gives ...
Disk Drv Mbytes Free Usage
2 2441 4 100%
Displaying the partitioning info using Fdisk option 4 gives ...
Partition Status Type Volume Label Mbytes System Usage
1 A NTFS 2437 100%
Total disk space is 2441 Mbytes (1 Mbyte = 1048576 bytes)
The difference of 4MB is the capacity of one track (128 * 63 * 512).
This is the partition table according to MBRtool:
Geometry values (from BIOS!) for this disk : (C/H/S) - 618/127/63
Partition Table Information
ACT TYPE START-C/H/S END----C/H/S LBA-start LBA-length
Entry 1: 128 07 0 1 1 618 127 63 63 4991553
Entry 2: 0 00 0 0 0 0 0 0 0 0
Entry 3: 0 00 0 0 0 0 0 0 0 0
Entry 4: 0 00 0 0 0 0 0 0 0 0
The total number of logical blocks is 4991616 (= 619 x 128 x 63).
Seagate's Find-ATA utility reports an LBA capacity of 4C4A00
(=4999680) sectors. This is consistent with WDC's specs:
http://www.wdc.com/en/products/legacy/Legacy.asp?r=3
The difference is 8064 sectors or exactly one track (8064 = 128 * 63).
The C/H/S values in CMOS RAM are 1360h/10h/3Fh = 4960/16/63. It may be
worth noting that the user space terminates on a cylinder boundary, so
there are no surplus sectors as in your initial Maxtor example.
I propose the following course of action.
(1) Use a DOS based sector editor to save a 2.5GB image of the HD to a
file, or several files.
(2) Attempt to delete the NTFS partition using Win98SE Fdisk.
(3) Create a single FAT32 partition.
(4) Initialise the file system and wipe the drive using Format /u.
(5) Check the MBR and rewrite it with Fdisk /mbr if necessary.
(6) Scan the disc surface for the F6 patterns that should have been
written by Format.
Franc Zabkar
put finger to keyboard and composed:
>| In fact I recently experimented with my slave drive by using Debug, in
>| a Windows environment, to edit the volume label in the first copy of
>| its boot sector. I changed the name from BACKUPS to BUCKUPS (I was
>| thinking of a slightly different name) while an Explorer window was
>| open. Refreshing Explorer still showed the original BACKUPS label, and
>| a re-examination of the drive's boot sector with Debug showed BUCKUPS.
>| However, after exiting both Debug and Explorer and then relaunching
>| the latter, the label had changed to "N". This label persisted after a
>| reboot. I then restored the original volume name using Explorer, and a
>| subsequent Scandisk found no problems.
> And the relevance to the test is what?
... that performing apparently innocuous changes at sector level in a
protected mode multitasking environment can produce completely
unexpected results. However, as you have said, accessing a foreign
volume should probably be OK.
>| >| Well, TestDisk thinks that my 13GB Seagate HD has 12732 *more* sectors
>| >| than its native capacity. <shrug> See my latest post in the "Everest"
>| >| thread.
>| >
>| > You probably do. Did you read what TESTDISK is actually showing you.
>|
>| Now you're sounding like a conspiracy theorist. Do you honestly
>| believe any disk tool has a better idea of a drive's size than the
>| drive's manufacturer? In fact I can't seem to find *any* tool that
>| doesn't have at least one error. MS-DOS itself has a bug which is
>| responsible for our present 255 head limitation (the head count
>| register can support 256 heads).
>
> Where the truck do you people come up with all this conspiracy theory crap,
>do you carry it around in your back pocket and pull it out when confronted
>with information you don't like, or what?
Whenever I am confronted with information that doesn't fit the known
facts, I try to find a logical explanation. OTOH, instead of accepting
the most plausible explanation, namely that software *does* have bugs,
you have chosen to find fault with the manufacturer or with some
unspecified nefarious component within Windows XP.
Franc Zabkar
put finger to keyboard and composed:
> When encounter any areas which can not be addressed or accessed, the areas
>will be handled under one of several activities.
> Read on S.M.A.R.T. activities and what they do to a drive. While your at
>it, read on what fdisk and format do when they encounter areas that they
>also can't address or access.
AIUI Format marks a cluster as bad by setting the appropriate bit(s)
in the FATs. Such clusters can be retested and possibly recovered by
software means. See the "format /c" option. I believe the /u switch
does the same thing.
As for errors detected by SMART, these are transparently handled by
the drive's electronics. AIUI, the drive has a reserved area which is
not accessible by the user. To see for yourself, read about "sector
sparing" or "alternate cylinders" in any hard disc's hardware manual.
If a drive exhausts its supply of spare sectors/cylinders, then you
will start seeing bad sectors appearing in the user area.
> You will find they, at times, use "reserved" sectors, and by doing so, use
>up available future use of the disk.
Fdisk and Format will transparently access the "reserved" area only
when bad sectors are remapped.
> Sure, you may find the disk still
>offers the supposed full disk, but at the expense of potential early drive
>failure, potential future corruption due to some type of disk activity which
>might attempt to use the SUPPOSED bad areas, and a number of other things.
> So merely looking for available disk space is not only ludicrous, it fails
>to address the activities which NT NTFS in general, and in particular XP
>NTFS does to the disk.
The reserved area does not "grow", so the user accessible disc space
remains constant. At worst, spare sectors will be exhausted and any
new defective sectors will not be remapped.
Dan W.
> I didn't, read what he asked for, and what I wrote.
>
> Did you have something to contribute to the discussion?
>
Nope, sorry --- I was just trying to be the peacemaker.
Jeff Richards
partitioning. WIPE was intended to write across the whole disk, but it
cannot cope with large disks. Considering the age of these utilities, I had
assumed it was much less than 8Gb (540Mb would have been my guess) but
whatever it is, I wouldn't use it to wipe a drive.
--
Jeff Richards
MS MVP (Windows - Shell/User)
> snip <
Jeff Richards
What I said was (a) MEANDISK writes to the file storage area of a partition,
not to the whole disk, and therefore (b) it will not remove the previous
data from the disk
This has been stated a number of times in the discussion. A partition may
or may not extend over ALL areas of the disk that have previously been used
for file storage. FAT32 partitions created by FDISK, in particular, tend to
leave a lot of unpartitioned space at the end of the drive in order to round
down (conservatively) to a logical cylinder boundary. They also have a
certain amount of unused space at the beginning, before the start of the
file storage area. Therefore, if your utility uses the FAT32 file system
to write to the file storage area of the partition it could easily miss
areas of the disk that have previously been used for file storage under some
other, differently organised, file system, such as NTFS.
MEANDISK is perfectly capable of removing XP NTFS provided that the
above-mentioned issues don't come into play. But if they do, it will leave
traces of the original data on the disk. It will not remove the previous
data from the disk. That is NOT the same as saying that it cannot remove XP
NTFS - it is simply saying that the results you will get with MEANDISK
depend on how you've used the disk in the past and how you've organised the
partition you are currently using. These conditions for a successful erase
make it unsuitable as a reliable way to completely erase all data from the
disk (which is precisely what the author acknowledges). Some of the data
that remains (outside the partition's file storage area) might have been
written by XP using NTFS, depending on how the NTFS partition was arranged
and how the FAT32 partition was created (remembering that there are many
partitioning tools other than FDISK). In that case, it would have failed to
remove all trace of the XP/NTFS data. But that doesn't mean it can't do it,
and it certainly doesn't mean that XP/NTFS has somehow prevented it from
doing it..
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:OHlViHD6...@TK2MSFTNGP06.phx.gbl...
Dan W.
Thanks Jeff and I will stick with the BING solution.
Dan W.
A quick aside --- Jeff and MEB --- Is Fat32 much easier to fully remove
then NTFS file system and if yes then why. We can start a new thread
about this topic if it is too long an answer and thanks in advance for
the reply that I know I will greatly appreciate.
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:4d79i253d8892c6bj...@4ax.com...
| On Sun, 1 Oct 2006 23:56:45 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| >Step 1 completed.
| >
| >Thank you for verifying that Win98 FDisk will not remove NTFS.
| >
| > What is you chosen wiping technique?
| > You are doing the test correct?
|
| I now have a 2.5GB Western Digital Caviar HD, model AC22500L, with an
| NTFS file system. The owner tells me that it probably contains bad
| sectors (the reason why it was withdrawn from service?). The HD's
| manufacture date is 1997, and it comes from an office environment, so
| I presume the OS is NT. What would be the quickest way for me to
| determine if it is NT, or Win2K or XP?
Was it wiped?
If not, your first indication would be the boot sector and partition table
and it's NTFS indication [but you knew that].
A second indication would be a search for [string] $MFT / [hex] 24 4D 46 54
indicators on the disk, within those if found, you may find the NTFS
indicators.
A third, perhaps only for NT5 and above, might be beyond the CHS end for
the disk; a table such as what I referred to which might contain the
clustering geometry for the disk.
As for which version and/or configuration, there lay my personal dilemma.
I am NOT an expert (as you and others may be) at this type of activity.
I can not supply the information which is needed to make that exact
determination. Such as: XP PRO plain; XP PRO SP1; XP PRO SP2; XP PRO
configured as a desktop work station; NTFS configured as the "disk
manager"/SYSTEM manager; server 2003; etc., or if there are specific
indicators.
Perhaps one of the other MVPs or others monitoring this thread can supply
that information for the discussion.<wink>
They may, admittedly, be a residual of the tests, or factors which are not
shown with these (older) tools your using, particularly as they are
apparently accessing the disk through the BIOS {the BIOS, chipset, and
controller, which are now foreign}.
As you've noted there is a track change / loss which may be compounded over
the course of the tests. You also may note changes over the course of
whatever tests you intend to run. Perhaps non-destructive review of that
lost track might be in order?
I suppose a quick review of the sectors, or an attempted "recovery" with
something like:
GetBack Data for DOS and NTFS might be revealing, they have a demo/test.
http://www.runtime.org/
|
| I propose the following course of action.
|
| (1) Use a DOS based sector editor to save a 2.5GB image of the HD to a
| file, or several files.
Your DOS based editor (depending upon the tool's abilities) may and or will
balk at any marked CRC and or ECC error coding, e.g. it may note the error
yet refuse to include the information behind the sector error (the sector is
unreachable/ unaddressable/ can not be read). DO you have a disk editor /
viewer not limited by such errors, to review the disk before you attempt the
activities, for the sake of your test?
I question this due to my own notice of such limitations within certain
tools, and due to NTFS cluster numbering and usage, verses old DOS sector
numbering [CHS] which is apparently and literally ignored within NTFS.
|
| (2) Attempt to delete the NTFS partition using Win98SE Fdisk.
|
| (3) Create a single FAT32 partition.
|
| (4) Initialise the file system and wipe the drive using Format /u.
|
| (5) Check the MBR and rewrite it with Fdisk /mbr if necessary.
|
| (6) Scan the disc surface for the F6 patterns that should have been
| written by Format.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
SO Franc, though I would love to be able to supply answer or suggestion
beyond what I have already given, including Theory or failures [don't
overlook that], perhaps we need someone with considerably more knowledge of
the XP / NT5 NTFS than we've been discussing.
Any "takers" out there?
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:ep79i258l3u0pk8u0...@4ax.com...
| On Tue, 3 Oct 2006 13:29:59 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| > When encounter any areas which can not be addressed or accessed, the
areas
| >will be handled under one of several activities.
| > Read on S.M.A.R.T. activities and what they do to a drive. While your at
| >it, read on what fdisk and format do when they encounter areas that they
| >also can't address or access.
|
| AIUI Format marks a cluster as bad by setting the appropriate bit(s)
| in the FATs. Such clusters can be retested and possibly recovered by
| software means. See the "format /c" option. I believe the /u switch
| does the same thing.
Those would be verified by a search for "MSDOS undocumented" [though
perhaps documented].
|
| As for errors detected by SMART, these are transparently handled by
| the drive's electronics. AIUI, the drive has a reserved area which is
| not accessible by the user.
Well, depending upon the tool and the users persistance, these areas MAY be
accessable.
To see for yourself, read about "sector
| sparing" or "alternate cylinders" in any hard disc's hardware manual.
| If a drive exhausts its supply of spare sectors/cylinders, then you
| will start seeing bad sectors appearing in the user area.
Right, but reviewing the actual physical disk, bit by bit, will show those
areas, even remapped areas.
This is a primary ability used by forensic recovery, such as; by police,
government, prosecutors, and professional data recovery businesses.
|
| > You will find they, at times, use "reserved" sectors, and by doing so,
use
| >up available future use of the disk.
|
| Fdisk and Format will transparently access the "reserved" area only
| when bad sectors are remapped.
|
| > Sure, you may find the disk still
| >offers the supposed full disk, but at the expense of potential early
drive
| >failure, potential future corruption due to some type of disk activity
which
| >might attempt to use the SUPPOSED bad areas, and a number of other
things.
| > So merely looking for available disk space is not only ludicrous, it
fails
| >to address the activities which NT NTFS in general, and in particular XP
| >NTFS does to the disk.
|
| The reserved area does not "grow", so the user accessible disc space
| remains constant. At worst, spare sectors will be exhausted and any
| new defective sectors will not be remapped.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
And that confirms my statement, they will not grow, but they certainly will
be used up.
Moreover, if the OS is sophisticated enough, perhaps it can control those
and other aspects of disk activity.
real@hotmail.com MEB
SO your "short" recommendation is not to use MEANDISK to attempt to remove
XP NTFS, is this correct?
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:eUGMIZG6...@TK2MSFTNGP04.phx.gbl...
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:2c79i253u6a76rgmr...@4ax.com...
| On Wed, 4 Oct 2006 19:52:22 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| >| In fact I recently experimented with my slave drive by using Debug, in
| >| a Windows environment, to edit the volume label in the first copy of
| >| its boot sector. I changed the name from BACKUPS to BUCKUPS (I was
| >| thinking of a slightly different name) while an Explorer window was
| >| open. Refreshing Explorer still showed the original BACKUPS label, and
| >| a re-examination of the drive's boot sector with Debug showed BUCKUPS.
| >| However, after exiting both Debug and Explorer and then relaunching
| >| the latter, the label had changed to "N". This label persisted after a
| >| reboot. I then restored the original volume name using Explorer, and a
| >| subsequent Scandisk found no problems.
|
| > And the relevance to the test is what?
|
| ... that performing apparently innocuous changes at sector level in a
| protected mode multitasking environment can produce completely
| unexpected results. However, as you have said, accessing a foreign
| volume should probably be OK.
Again, Franc, all I can presently say is, in Windows 98SE, it is fine in
the "no drive" status using DISK EDITORS, disk investigators, or the like.
Not stating editing, as that would be determined by the tools ability,
merely viewing.
As for using XP, I can no longer confirm one way or the other, as both my
XP PRO testing installations are gone until I attempt to recover this disk,
as money for replacement is non-existent.
Franc, I have done my level best to add the variables at the proper time in
this discussion, when the issue is ripe.
You are still addressing these disk as if they are the same old disks and
the OS must conform "to them". That hasn't been true for a number of years
in the NT environment.
No "nefarious component" or "conspiracy theory", but perhaps, part of the
XP NTFS protection schemes. Something of which information is sadly lacking
(protected by Microsoft and forensic specialists).
Please use some tools from this era / time frame, or you may not find what
we need to review. Your dealing with several new versions of ATA/ATAPI
specifications AND new OS uses, yet using (some) tools from an era when OSs
had to follow the HD without the ability to modify much beyond CHS.
If the disk has been allocated using clustering technology, then even the
manufacturers tools may fail if they have no access to, or know how to use
the clustering tables. All they can do is the same thing they have been
doing basically from day one, using CHS, the controller, and their own known
coding.
Using the MBR if it's been wiped or overwritten, means essentially nothing.
Nor will partitioning tools give the indications necessary to this
discussion.
Because, if the information has been wiped that they would use for
identification/use, then most have no clue what has been done previously. If
its hidden or otherwise protected, then they also fail.
Here recovery or forensic tools become necessary. Tools which look beyond
standard CHS, MBR, and even the controller code, for other indicators.
Franc Zabkar
put finger to keyboard and composed:
>| AIUI Format marks a cluster as bad by setting the appropriate bit(s)
>| in the FATs. Such clusters can be retested and possibly recovered by
>| software means. See the "format /c" option. I believe the /u switch
>| does the same thing.
>
> Those would be verified by a search for "MSDOS undocumented" [though
>perhaps documented].
Documented. See the Oldmsdos directory (or whatever it is called) on
your Win98CD. Copy the stuff to your Windows\Command directory, then
type "help format".
>| As for errors detected by SMART, these are transparently handled by
>| the drive's electronics. AIUI, the drive has a reserved area which is
>| not accessible by the user.
>
> Well, depending upon the tool and the users persistance, these areas MAY be
>accessable.
Which tool? I have a WD Caviar drive whose SMART status is bad, as
reported by the POST. A sector editor (Symantec's Diskedit from
SystemWorks? 2001) tells me that the drive has bad sectors all over
the disc.
> To see for yourself, read about "sector
>| sparing" or "alternate cylinders" in any hard disc's hardware manual.
>| If a drive exhausts its supply of spare sectors/cylinders, then you
>| will start seeing bad sectors appearing in the user area.
>
> Right, but reviewing the actual physical disk, bit by bit, will show those
>areas, even remapped areas.
>This is a primary ability used by forensic recovery, such as; by police,
>government, prosecutors, and professional data recovery businesses.
Which tool?
Franc Zabkar
put finger to keyboard and composed:
>| I now have a 2.5GB Western Digital Caviar HD, model AC22500L, with an
>| NTFS file system. The owner tells me that it probably contains bad
>| sectors (the reason why it was withdrawn from service?). The HD's
>| manufacture date is 1997, and it comes from an office environment, so
>| I presume the OS is NT. What would be the quickest way for me to
>| determine if it is NT, or Win2K or XP?
>
> Was it wiped?
No, the data appear untouched. In fact I have to be careful what I
upload because it appears to contain payroll info.
> If not, your first indication would be the boot sector and partition table
>and it's NTFS indication [but you knew that].
Yes, I saw the "NTFS" string in the boot sector. There was nothing
like that in the MBR, though.
>A second indication would be a search for [string] $MFT / [hex] 24 4D 46 54
>indicators on the disk, within those if found, you may find the NTFS
>indicators.
Found it, although it is in unicode (16-bit) format.
> A third, perhaps only for NT5 and above, might be beyond the CHS end for
>the disk; a table such as what I referred to which might contain the
>clustering geometry for the disk.
There appears to be a copy of the boot sector (not a partition table)
at the very end of the disc. It exists in the last sector of the user
space, in the last cylinder, beyond the end of the partition as
defined in the partition table. That is, the partition table defines
the end of the primary partition as logical block 4,999,616, whereas
the copy appears at 4,999,679. The Identify Drive command reports an
LBA capacity of 4,999,680 sectors. So the 4MB "free space" reported by
Fdisk appears to be used by NTFS (or the OS).
See http://www.users.on.net/~fzabkar/2GBdata/
Hopefully the file names are self explanatory.
> As for which version and/or configuration, there lay my personal dilemma.
> I am NOT an expert (as you and others may be) at this type of activity.
I'm no expert, I just have relevant experience ... I hope.
> I can not supply the information which is needed to make that exact
>determination. Such as: XP PRO plain; XP PRO SP1; XP PRO SP2; XP PRO
>configured as a desktop work station; NTFS configured as the "disk
>manager"/SYSTEM manager; server 2003; etc., or if there are specific
>indicators.
I have been unable to image the disc in its entirety. The bad sectors
start appearing at about 2%. :-(
I was hoping to find some version information such as is reported by
the VER command in Win9x DOS. Unfortunately there is a message in the
boot sector ("NTLDR is compressed") which suggests it may not be as
simple as that.
AFAICS these older DOS tools are adequate for the purpose. Find-ATA
issues an Identify Drive command and retrieves the *raw* data. Its
*interpretation* of the data is flawed, but the data are correct.
MBRtool reads physical sector 0. That's all I've asked it to do. Fdisk
does the same. I suspect even an old 286 BIOS will be able to read
physical sector 0 of a modern drive.
> As you've noted there is a track change / loss which may be compounded over
>the course of the tests. You also may note changes over the course of
>whatever tests you intend to run. Perhaps non-destructive review of that
>lost track might be in order?
I'll try, but it's going to be difficult. I'm being overwhelmed by bad
sectors.
This is an image of the last track at the present time:
http://www.users.on.net/~fzabkar/2GBdata/LAST_TRK.IMG
> I suppose a quick review of the sectors, or an attempted "recovery" with
>something like:
>GetBack Data for DOS and NTFS might be revealing, they have a demo/test.
>http://www.runtime.org/
I'll check it out. Should I attempt to re-initialise the disc with DOS
tools (fdisk and format) and then see if I can recover any remnants of
the old file system? Will that be an adequate test?
>| I propose the following course of action.
>|
>| (1) Use a DOS based sector editor to save a 2.5GB image of the HD to a
>| file, or several files.
>
> Your DOS based editor (depending upon the tool's abilities) may and or will
>balk at any marked CRC and or ECC error coding, e.g. it may note the error
>yet refuse to include the information behind the sector error (the sector is
>unreachable/ unaddressable/ can not be read). DO you have a disk editor /
>viewer not limited by such errors, to review the disk before you attempt the
>activities, for the sake of your test?
My favourite has always been Norton's Diskedit, but the 2001 version,
although it can write to a FAT32 volume, corrupted my FAT when I ran
it in pure DOS mode. Fortunately Scandisk corrected the error.
Diskedit appears to run OK in a Windows DOS box, though. As you say,
accessing a foreign physical disc should pose no problems in a Windows
environment. One annoyance with Diskedit, however, is that there
appears to be no way to tell it to automatically skip bad sectors, so
I am forever having to respond to an Abort/Retry box. More annoyingly,
Abort does not stop the current process, it only stops accessing the
current sector.
Franc Zabkar
<fza...@iinternode.on.net> put finger to keyboard and composed:
>> I suppose a quick review of the sectors, or an attempted "recovery" with
>>something like:
>>GetBack Data for DOS and NTFS might be revealing, they have a demo/test.
>>http://www.runtime.org/
>
>I'll check it out.
OK, I'm using Runtime's DiskExplorer for NTFS running on Win98SE with
the NTFS volume on a primary slave drive.
I can see a WINNT directory in the root. I can also see the following
files:
IO.SYS 10/12/98 11:21:03
MSDOS.SYS 10/12/98 11:21:03
NTDETECT.COM 17/01/00 3:05:54P 26,816 bytes
ntldr 17/01/00 3:05:54P 156,496 bytes
There is a boot.ini file containing the following text:
"Windows NT Workstation Version 4.00"
I guess that's self explanatory.
Is there any point in proceeding with my test?
BTW, DiskExplorer is a nice program.
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:ls0bi2pclcdus3kdi...@4ax.com...
| On Fri, 06 Oct 2006 07:48:02 +1000, Franc Zabkar
| <fza...@iinternode.on.net> put finger to keyboard and composed:
|
| >> I suppose a quick review of the sectors, or an attempted "recovery"
with
| >>something like:
|
| >>GetBack Data for DOS and NTFS might be revealing, they have a demo/test.
| >>http://www.runtime.org/
| >
| >I'll check it out.
|
| OK, I'm using Runtime's DiskExplorer for NTFS running on Win98SE with
| the NTFS volume on a primary slave drive.
Not the best configuration which we both noted, but...
|
| I can see a WINNT directory in the root. I can also see the following
| files:
|
| IO.SYS 10/12/98 11:21:03
| MSDOS.SYS 10/12/98 11:21:03
| NTDETECT.COM 17/01/00 3:05:54P 26,816 bytes
| ntldr 17/01/00 3:05:54P 156,496 bytes
|
| There is a boot.ini file containing the following text:
| "Windows NT Workstation Version 4.00"
|
| I guess that's self explanatory.
|
| Is there any point in proceeding with my test?
|
| BTW, DiskExplorer is a nice program.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
Not that I see, but we could "tear apart" the old system for comparison to
XP after Jeff's test. Wait a minute, what Service pack was that,, 2000, or
was that the base? Sorry, got rid of my last leased network about 6 years
ago, and information had to be replaced (in my mind).
Perhaps the early versions of the clustering tech, would compare in some
fashion, though there must be numerous changes or the NT 5 kernel and new
filing system would be a sham.
Yeah, Disk Explorer is a handy "quick view" tool if I remember correctly.
Still installed (demo) but don't use it much.
HEY, did you search for those string values in the "bad sectors"? Note any
ECC coding in the sector heading (duh yeah, so the point is?)?
Are many of them $MFT?
Did you try the recovery tools to see if those "bad sectors" contain the
hives and restore point files (most will be compressed)?
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:j3rai2pi7gdrqvqb2...@4ax.com...
| On Thu, 5 Oct 2006 13:15:12 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| >| AIUI Format marks a cluster as bad by setting the appropriate bit(s)
| >| in the FATs. Such clusters can be retested and possibly recovered by
| >| software means. See the "format /c" option. I believe the /u switch
| >| does the same thing.
| >
| > Those would be verified by a search for "MSDOS undocumented" [though
| >perhaps documented].
|
| Documented. See the Oldmsdos directory (or whatever it is called) on
| your Win98CD. Copy the stuff to your Windows\Command directory, then
| type "help format".
Understood, do that every re-install,, used to have the development kit,,
the "search" was for others to use to find more undocumented commands.
|
| >| As for errors detected by SMART, these are transparently handled by
| >| the drive's electronics. AIUI, the drive has a reserved area which is
| >| not accessible by the user.
| >
| > Well, depending upon the tool and the users persistance, these areas MAY
be
| >accessable.
|
| Which tool? I have a WD Caviar drive whose SMART status is bad, as
| reported by the POST. A sector editor (Symantec's Diskedit from
| SystemWorks? 2001) tells me that the drive has bad sectors all over
| the disc.
If you've noted, on Symantec's site there is a disclaimer regarding the
newer OSs with their older tools.
The only thing of Symantec I have from around that version is gdisk.
I could direct you to WINHEX again, but your using Win98 so the installation
would fail for the 13+ versions.
You can buy the old versions, such as the last to work with Win98 (12.8 SR
10 I think) but the cost, unless your in the business...
Beyond those you could try some or one of these:
http://www.ntfs.com/ntfs_recovery_concepts.htm - NTFS.com Hard Drive Data
Recovery Information
http://www.hddrecovery.com.au/DR_disk_failure_files_2.htm -
HDDRecovery...data recovery for failed hard drives - dead disk
http://www.mediarecover.com/advanced-file-recovery.html - Hard drive
recovery software
http://www.stellarinfo.com/ - Hard Drive Data Recovery Software Tools, Disk
Recovery Utilities -Stellar
http://www.geocities.com/thestarman3/tool/de/PTS-DE.htm - PTS Disk Editor
And the prior tools which I posted. I can't make that determination for you,
much is based upon preference, need, and intended use.
In fact, that is a major problem with trying to present these issues to any
one else, I have searched for demos and free tools, but I really couldn't
recommend any "one" of them. Some may be useful for one facet, others may be
of use for others. At minimum, I present three tools, as in the Everest
Discussion. BTW, your needed there.
|
| > To see for yourself, read about "sector
| >| sparing" or "alternate cylinders" in any hard disc's hardware manual.
| >| If a drive exhausts its supply of spare sectors/cylinders, then you
| >| will start seeing bad sectors appearing in the user area.
| >
| > Right, but reviewing the actual physical disk, bit by bit, will show
those
| >areas, even remapped areas.
| >This is a primary ability used by forensic recovery, such as; by police,
| >government, prosecutors, and professional data recovery businesses.
|
| Which tool?
The expensive one.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
--
real@hotmail.com MEB
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:a9vai2hehf5mrcc0m...@4ax.com...
| On Thu, 5 Oct 2006 13:01:24 -0400, "MEB" <meb@not re...@hotmail.com>
| put finger to keyboard and composed:
|
| >| I now have a 2.5GB Western Digital Caviar HD, model AC22500L, with an
| >| NTFS file system. The owner tells me that it probably contains bad
| >| sectors (the reason why it was withdrawn from service?). The HD's
| >| manufacture date is 1997, and it comes from an office environment, so
| >| I presume the OS is NT. What would be the quickest way for me to
| >| determine if it is NT, or Win2K or XP?
| >
| > Was it wiped?
|
| No, the data appear untouched. In fact I have to be careful what I
| upload because it appears to contain payroll info.
YIKES!!!! AH, best avoid that.
|
| > If not, your first indication would be the boot sector and partition
table
| >and it's NTFS indication [but you knew that].
|
| Yes, I saw the "NTFS" string in the boot sector. There was nothing
| like that in the MBR, though.
|
| >A second indication would be a search for [string] $MFT / [hex] 24 4D 46
54
| >indicators on the disk, within those if found, you may find the NTFS
| >indicators.
|
| Found it, although it is in unicode (16-bit) format.
Using Semantec's right. I think I read it does not support unicode
somewhere (Symantec's website maybe). Don't quote me though.
How many times did it turn up?
|
| > A third, perhaps only for NT5 and above, might be beyond the CHS end for
| >the disk; a table such as what I referred to which might contain the
| >clustering geometry for the disk.
|
| There appears to be a copy of the boot sector (not a partition table)
| at the very end of the disc. It exists in the last sector of the user
| space, in the last cylinder, beyond the end of the partition as
| defined in the partition table. That is, the partition table defines
| the end of the primary partition as logical block 4,999,616, whereas
| the copy appears at 4,999,679. The Identify Drive command reports an
| LBA capacity of 4,999,680 sectors. So the 4MB "free space" reported by
| Fdisk appears to be used by NTFS (or the OS).
|
| See http://www.users.on.net/~fzabkar/2GBdata/
|
| Hopefully the file names are self explanatory.
|
| > As for which version and/or configuration, there lay my personal
dilemma.
| > I am NOT an expert (as you and others may be) at this type of activity.
|
| I'm no expert, I just have relevant experience ... I hope.
Me too, this is going to take some real analysis.
|
| > I can not supply the information which is needed to make that exact
| >determination. Such as: XP PRO plain; XP PRO SP1; XP PRO SP2; XP PRO
| >configured as a desktop work station; NTFS configured as the "disk
| >manager"/SYSTEM manager; server 2003; etc., or if there are specific
| >indicators.
|
| I have been unable to image the disc in its entirety. The bad sectors
| start appearing at about 2%. :-(
I didn't think you could or would be successful. If they are REAL bad
sectors, then if there are that many, the disk was headed for the recovery
utility or business if the info was important.
If they're just a few REAL bad sectors, but perhaps LOST intentional ECC
protection bad sectors, then the OS would likely have to be used to attempt
recovery of those sectors, if the OS was intact (password access to the
base) and a lengthy process.
That wasn't what I was trying to point out.
You've already noted unicode in NTFS; I've noted: compressed; encrypted;
cluster technology; extended areas; new drive geometry (both manufacturer
and OS); new ATA/ATAPI spec.s and commands; new partition usage; and other,
cquirke pointed out issues with fdisk and partition issues, and .... the
point is the Seagate tools are old (I have them BTW tucked away on CDROM);
sure they use ATA commands, but they do not understand all the changes that
have been made via the OSs, HD controllers, BIOSs, mobo chipsets, and the
hard drive manufacturers. It takes quite a bit more in todays environment.
Because CHS usage and classifications are, in essence, dead. Might be OKAY
for partition setup, but beyond that, they apparently don't exist.
Think of it like this, the hard drive of today is the same physical size as
the first ATA standards compliant drive of 100 meg, yet hundreds of
gigabytes of information is there.
|
| > As you've noted there is a track change / loss which may be compounded
over
| >the course of the tests. You also may note changes over the course of
| >whatever tests you intend to run. Perhaps non-destructive review of that
| >lost track might be in order?
|
| I'll try, but it's going to be difficult. I'm being overwhelmed by bad
| sectors.
|
| This is an image of the last track at the present time:
| http://www.users.on.net/~fzabkar/2GBdata/LAST_TRK.IMG
Where we need to look is way behind that, passed some of the reserved
sectors.
Can you see any ! BAD SECTOR ! (reserved) markings at the end of the disk?
It may be behind those.
Well unless your attempting to recover that data, Symantec's Disk Editor is
too old to be of use for this project.
I'm not even sure it would be useful for any real recovery effort on XP
NTFS.
Like I said once somewhere, I used to use Pro View (McAfee) WAAAAAYYYYY back
when, but it's totally useless now (unless they updated it?) and has been
for years, same for those old Seagate (and other manufacturers) tools I used
to rely on.
Jeff Richards
remove XP NTFS, because that is not what MEANDISK is designed to do.
MEANDISK is designed to overwrite (erase) data. It has nothing to do with
any process involving removing XP NTFS, which is a file system.
To remove XP NTFS you would simply write zeroes into the first dozen or so
sectors of the disk, something which MEANDISK absolutely cannot do.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" <meb@not re...@hotmail.com> wrote in message
news:ON$OkmK6G...@TK2MSFTNGP04.phx.gbl...
Jeff Richards
>
> Let's say NTFS does as it claims and uses cluster numbering rather than
> standard CHS sector numbering to identify it's areas and files.
The two are not exclusive. Cluster numbering is used to identify portions of
the disk used to store files. By using clusters instead of sectors the
absolute magnistude of the numbers can be smaller. Depending on what process
is involved the system simply converts between the sector number and the
cluster number as required. They co-exist.
>
> Let's also say that XP NTFS creates several sub-partitions within its
> assigned partition. To mark these partitions it uses special partition
> indicators which might have once been assigned to other programs or OSs or
> which are known as applying.
>
It doesn't and there's no need for such an assumption.
> Let's also say that it also creates several hidden partitions within its
> assigned partition.
It doesn't and there's no need for such an assumption. If something needs
to be hidden then creating a partition is a kludgy way to do it.
>
> And to address all these new variables, it creates a master cluster list
> somewhere on the disk which would include the numbering of all usable
> clusters, perhaps as defined by partition indicator.
>
> Let's theorize XP NTFS places a ECC code or other code indicating a sector
> can't be used, at the proper place in the sector, but places information
> it
> wishes to protect behind that error indicator at it's XP NTFS clustering
> number.
It can't place an 'other code indicating a sector can't be used' because
anything other than XP would simply ignore the code and render it pointless.
It can (in theory) mess with the ECC (for example) because everything has to
go through the drive firmware at that level, and therefore the messing would
apply to any other attempt to access the disk. This is what the copy
protection schemes of DOS floppy days did. As a data protection measure
there are a number of problems with this theory.
1. Anything XP can do, another application can do, provided it knows the
trick. As DOS floppy copy protection demonstrates, it doesn't take all that
much investigation to find out how it's done.
2. The process depends on good knowledge of the drive hardware. DOS floppy
copy protection was viable because the floppy controller is absolutely
standard. XP runs on disks that are managed by a vast variety of different
controllers, such as SCSI, and a vast number of different disk drives, each
with their own oddities. The technique would have to be built for each
possible variation.
3. If the drive allowed such messing with its lowest level functions, then
the chance is it would trigger a response like the one I mentioned earlier,
where the drive and the application get into a fight over who is managing
the sector. The application tries to mess with it, the drive firmware swaps
in a reserve sector. The fight continues until the drive is no longer
functional. Finding a way to mess with a sector so that nothing else
accesses it, but the drive firmware still sees it as valid, would be
virtually impossible for a specific case, and actually impossible for the
general case..
Basically, if the sector is 'bad' enough to make it inaccessible to anything
else, then it's 'bad' enough for the drive firmware to refuse to return the
data it contains. Or, if it's not quite 'bad' enough to prevent the drive
from returning the contents, then it's not 'bad' enough to prevent any other
application getting access to it.
> XP NTFS can still access the data because it does not see the error at the
> sector head; perhaps it uses a master clustering table (or something along
> those lines) and applicable MFT to locate the EXACT clusters. All the data
> is there and accessible to XP, but it's not accessible to what would have
> been considered, normal use or testing.
>
> Any normal tool which addresses the disk through the CHS values, sector
> numbering, or the bios, would see the sector is not usable and return a
> CRC
> or ECC error; it is marked that way after all (in this theory). The normal
> tool would also likely respect the partition indicators even if they were
> not in the standard format, or were assigned some type of hidden status
> (per
> this theory).
A tool that does sector-level access is not going to respect partition
indicators, so special partitioning is not relevant to the theory.
>
> Uniquely, this would also appear to effect any tools which do sector by
> sector reads and/or over-writes, or individual sector analysis. Sector
> recovery tools would or might balk at recovery, particularly if there were
> something which was protecting those areas.
>
> Remember, this is all theory.
Theory with too many holes in it to be seriously considerd.
>
> --
> MEB
> http://peoplescounsel.orgfree.com/
real@hotmail.com MEB
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:OBo8cHT6...@TK2MSFTNGP03.phx.gbl...
| "MEB" <meb@not re...@hotmail.com> wrote in message
| news:%23HOyW28...@TK2MSFTNGP05.phx.gbl...
{everything cut do to reply length}
|
| >
| > --
| > MEB
| > http://peoplescounsel.orgfree.com/
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
|
|
Well Jeff, there are several other variables which I have avoided to date.
Let's review matters such as:
FROM WINHEX HELP (an older version):
Disk cloning offers options that control the behavior when bad sectors are
encountered on the source disk:
• By default, you are notified of the error and prompted for either
continuing or aborting the operation. "Log procedure silently" creates a
complete log file of the entire operation in the folder for temporary files
(filename "Cloning Log.txt"), including a report on unreadable sectors
(which cannot be copied), and prevents WinHex from reporting each unreadable
sector separately. This is useful e.g. for computer forensics.
• WinHex can either leave the destination sector that corresponds to a
damaged source sector unchanged or fill it with an ASCII pattern you specify
(e.g. your initials, or something like "BAD "). Leave the pattern edit box
blank to fill such sectors with zero bytes. BTW, this pattern is also used
to display a bad sector's contents in the disk editor.
• Bad sectors often occur in contiguous groups, and each attempt to read a
bad sector usually takes a long time. You may have WinHex avoid such damaged
disk areas. When a bad sector is encountered, WinHex can try to skip a
number of subsequent sectors you specify (25 by default). This is useful if
you wish to accelerate the cloning process and if you do not care about some
actually readable sectors not making it to the clone.
_______END_____
Note it says " BTW, this pattern is also used to display a bad sector's
contents in the disk editor.". So when using WinHex, any true bad sectors
would be essentially unreadable and inaccessible and marked as such. Yet
when using this editor (which Microsoft is a registered user of) one can
still access and view the contents of many marked "bad areas".
AGAIN FROM WINHEX HELP:
The Disk Editor, that is part of the Tools menu, allows you to access floppy
and hard disks below file system level. Disks consist of sectors (commonly
units of 512 bytes). You may access a disk either logically (i. e.
controlled by the operating system) or physically (controlled by the BIOS).
...
Usually it is preferable to open a logical drive instead of a physical disk,
because more features are provided in this case. For example, "clusters" are
defined by the file system, the allocation of clusters to files (and vice
versa) is known to WinHex, "free space" and "slack space" have a meaning.
Only if you need to edit sectors outside a logical drive (e.g. the master
boot record), if you wish to search something on several partitions of a
hard disk at the same time, or if a partition is damaged or formatted with a
file system unknown to Windows, so Windows is unable to make it accessible
as a drive letter, you would open the physical disk instead. Via the menu
that appears when clicking the "Access" button, you may also open individual
partitions from within a physical disk. WinHex understands both conventional
MBR partitioning and Windows 2000's dynamic disks as organized by the LDM
(Logical Disk Manager, specialist and forensic licenses only). All dynamic
volume types are supported: simple, spanned, striped, and RAID 5. Holding
the Ctrl key when opening hard disks disables detection and special handling
of dynamic volumes and ensures the hard disk is treated like it has been
partitioned in the conventional way.
...
[So if we wish to access a disk, but NOT corrupt it initially, we would use
a non-drive. Let's stay within WINHEX HELP but jump to another segment]
Master Boot Record
The Master Boot Record is located at the physical beginning of a hard disk,
editable using the Disk Editor. It consists of a master bootstrap loader
code (446 bytes) and four subsequent, identically structured partition
records. Finally, the hexadecimal signature 55AA completes a valid Master
Boot Record.
The format of a partition record is as follows:
Offset Size Description
0 8 bit A value of 80 designates an active partition.
1 8 bit Partition start head
2 8 bit Partition start sector (bits 0-5)
3 8 bit Partition start track (bits 8,9 in "start sector" as bits 6,7)
4 8 bit Operating system indicator
5 8 bit Partition end head
6 8 bit Partition end sector (bits 0-5)
7 8 bit Partition end track (bits 8,9 in "end sector" as bits 6,7)
8 32 bit Sectors preceding partition
C 32 bit Length of partition in sectors
Operating system indicators: (hexadecimal, incomplete list)
00 Empty partition-table entry
01 DOS FAT12
04 DOS FAT16 (up to 32 MB)
05 DOS 3.3+ extended partition
06 DOS 3.31+ FAT16 (over 32 MB)
07 OS/2 HPFS, Windows NT NTFS, Advanced Unix
08 OS/2 v1.0-1.3, AIX bootable partition, SplitDrive
09 AIX data partition
0A OS/2 Boot Manager
0B Windows 95+ FAT32
0C Windows 95+ FAT32 (using LBA-mode INT 13 extensions)
0E DOS FAT16 (over 32 MB, using INT 13 extensions)
0F Extended partition (using INT 13 extensions)
17 Hidden NTFS partition
1B Hidden Windows 95 FAT32 partition
1C Hidden Windows 95 FAT32 partition (using LBA-mode INT 13 extensions)
1E Hidden LBA VFAT partition
42 Dynamic disk volume
50 OnTrack Disk Manager, read-only partition
51 OnTrack Disk Manager, read/write partition
81 Linux
82 Linux Swap partition, Solaris (Unix)
83 Linux native file system (ext2fs/xiafs)
85 Linux EXT
86 FAT16 volume/stripe set (Windows NT)
87 HPFS fault-tolerant mirrored partition, NTFS volume/stripe set
BE Solaris boot partition
C0 DR-DOS/Novell DOS secured partition
C6 Corrupted FAT16 volume/stripe set (Windows NT)
C7 Corrupted NTFS volume/stripe set
F2 DOS 3.3+ secondary partition
[again, we'll stay in WINHEX HELP but move to a different segment]
Directory Browser
On logical drives and partitions formatted with FAT12, FAT16, FAT32, NTFS,
Ext2, Ext3, CDFS/ISO 9660/Joliet, or UDF, WinHex offers a directory browser,
which resembles the Windows Explorer's right-hand list. It can be disabled
or enabled by clicking the checkbox next to the Access button. The directory
browser lists existing files and directories first, then deleted files and
directories. Compressed files are displayed in blue, encrypted files in
green (NTFS only). Right-clicking any item in the directory browser brings
up a context menu with commands for opening a file or directory, exploring a
directory, locating the beginning of a file or directory on the disk,
locating the corresponding directory entry (FAT) or file record (NTFS),
listing the allocated clusters in a separate window, and for easily
recovering a lost or existing file or directory. The latter can recreate
entire directory structures. Double-clicking executes the default action
(locating the data, listing clusters, and exploring in the case of a
directory). Clicking items in the separate list window allows to navigate to
the listed clusters in the disk editor. [NOTE WinHex shows NTFS: compressed
[blue], encrypted [green] files; directory structure, and other by using the
clustering technology located (in part) in the MFT.]
...
Deleted files and directories are represented in the directory browser with
lighter icons. Question mark icons indicate that the original file or
directory contents may be still available. Deleted objects that WinHex knows
are no longer accessible (either because their first cluster has been
reallocated or because they have a size of 0 bytes) have icons crossed out
in red.
The directory browser can sort files and directories in ascending or
descending order, and still reveals the previous sort criterion with a
lighter arrow. For example, if you first click the filename column and then
the filename extension column, files with the same extension will internally
still be sorted by name.
On NTFS drives, the directory browser lists all deleted files on the drive
of which traces can still be found in a single dedicated virtual folder
"Deleted Objects" for reasons of convenience. These are the same files that
are also recoverable using File Recovery by Name with the "thorough search"
option disabled.
[So what we're seeing is WinHex has the ability to determine and
differentiate between deleted files [Deleted Objects, in a special virtual
folder], accessible files, actual "bad areas" verses those just marked as
such, "lost/orphaned and other files by type, by specific activities and
indications within the program.]
...
[in the same help area under available shown ATTRIBUTES]
The built-in priority when sorting by the Attr. column in descending order
is as follows:
1) NTFS alternate data streams, Linux SUID
2) NTFS $EFS streams, Linux symlinks
3) NTFS non-directory INDX streams, Linux special files
4) NTFS filesystem encryption
5) Positive mismatches (e.g. JPEG misnamed as .dll)
6) Negative mismatches (e.g. text file with no known signature named .jpg)
7) User-level encryption (e.g. in a ZIP archive)
8) User-level encryption supposed (flagged by the entropy test)
9) User-level compression (e.g. in a ZIP archive)
10) NTFS filesystem compression
11) NTFS reparse points
12) ordinary Windows attributes and Linux permissions
[There is a link on that page to follow which goes here]
Drive Contents Table
Requires a specialist or forensic license. This function is now deprecated
and will not be available any more in future versions at all. Press
Shift+F10 to access it while still available. Superseded by refined volume
snapshots in conjunction with the dynamic filter. The Create Drive Contents
Table command in the Specialist menu creates a disk "catalog" of existing
and non-existent (deleted or orphaned) files and directories on a logical
drive or partition, with user-configurable information such as attributes,
all available date & time stamps, size, allocated clusters, hash (checksum
or digest), alternate data streams (which contain hidden data, on NTFS
drives only), etc.
...
Sorting by date & time stamps will result in a good overview of what a disk
has been used for at a certain time. E.g. the NTFS attribute "encrypted"
might quickly reveal what files may turn out to be the most important ones
in a forensic analysis.
...
The result can also be output directly to the directory browser. That means
you have an "all files view" of a logical drive or partition in WinHex and
can sort by date, filename extension, etc., move to the clusters where a
file is stored, recover a file, delete irrelevant items from the list, etc.
Blue items in the directory browser indicated compressed files ("C" in the
Attr. column = files compressed at the NTFS file system level, "c" in the
Attr. column = files inside ZIP archives etc.), green items indicate
encrypted files ("E" in the Attr. column = files at the NTFS file system
level, "e" in the Attr. column = files encrypted in an archive). The reason
why items are highlighted in red is explained in the Attr. column, too
(either detected filename/file type mismatches, or alternate data streams or
named index streams in NTFS). When manually deleting irrelevant items from a
contents table that is associated with an evidence object, WinHex can save
your changes to the contents table file.
...
[moving to another segment of WINHEX HELP]
Conversions
WinHex provides the "Convert" command of the Edit menu for easy conversions
of different data formats and for encryption and decryption. The conversion
can optionally be applied to all opened files instead of only the currently
displayed one. The formats marked with an asterisk can only be converted as
a whole file, not as a block. The following formats are supported:
• ANSI ASCII, IBM ASCII (two different ASCII character sets)
• EBCDIC (an IBM mainframe character set)
• Lowercase/uppercase characters (ANSI ASCII)
• Binary* (raw data)
• Hex ASCII* (hexadecimal representation of raw data as ASCII text)
• Intel Hex* (=Extended Intellec; hex ASCII data in a special format, incl.
checksums etc.)
• Motorola S* (=Extended Exorcisor; ditto)
• Base64*
• UUCode*
...
The Convert command can also decompress raw data from any number of complete
16-cluster units compressed by the NTFS file system.
...
[from another area of WINHEX HELP]
Digests
A so-called digest is, similar to a checksum, a characteristic number used
for verification of data authenticity. But digests are more than that:
digests are strong one-way hash codes.
It is computationally feasible to manipulate any data in such a way that its
checksum remains unaffected. Verifying the checksum in such a case would
lead to the assumption that the data has not been changed, although it has.
Therefore, digests are used instead of checksums if malicious (i.e. not mere
random) modifications to the original data are to be detected. It is
computationally infeasible to find any data that corresponds to a given
digest. It is even computationally infeasible to find two pieces of data
that correspond to the same digest.
Of course, random modifications, e. g. caused by an inaccurate transmission,
can also be detected when using digests, but checksums serve better for this
purpose, because they can be calculated much faster.
WinHex incorporates the widely known 128-bit MD5 message digest, SHA-1,
SHA-256, and PSCHF ("Pukall Stream Cipher" hash function).
[a different WINHEX HELP section]
Data Interpreter
The Data Interpreter is a small window that provides "translation services"
for the data at the current cursor position. The Data Interpreter Options
dialog lets you specify the data types to interpret. These are various
integer data types (by default in decimal notation, optionally hexadecimal
or octal), the binary format (8 bits of a byte), four floating-point data
types, assembler opcodes (Intel), and date types.
...
There are redundancies in the Intel instruction set, which show up in the
Data Interpreter as duplication of both hex opcodes and mnemonics.
Floating-point instructions are generally displayed as F***.
More detailed reference can be found in the Intel Architecture Software
Developer’s Manual Volume 2: Instruction Set Reference, available in PDF
format on the Internet.
[related elsewhere in WINHEX HELP]
Integer Data Types
Format/Type Range Example
signed 8 bit -128...127 FF = -1
unsigned 8 bit 0...255 FF = 255
signed 16 bit -32,768...32,767 00 80 = -32,768
unsigned 16 bit 0...65,535 00 80 = 32,768
signed 24 bit -8,388,608...8,388,607 00 00 80 = -8,388,608
unsigned 24 bit 0...16,777,215 00 00 80 = 8,388,608
signed 32 bit -2,147,483,648...2,147,483,647 00 00 00 80 = -2,147,483,648
unsigned 32 bit 0...4,294,967,295 00 00 00 80 = 2,147,483,648
signed 64 Bit -2^63...2^63-1 00 00 00 00 00 00 00 80 = -2^63
Unless stated otherwise, multi-byte numbers are stored in little-endian
format, meaning that the first byte of a number is the least significant and
the last byte is the most significant. This is the common format for
computers running Microsoft Windows. Following the little-endian paradigm,
the hexadecimal values 10 27 can be interpreted as the hexadecimal number
2710 (decimal: 10,000).
The Data Interpreter is capable of interpreting data as all of the
aforementioned integer types.
______END___
As is noted above, NTFS contains many more "issues" than the old DOS
functioning.
I could go more in depth with just this one program and it's help file, but
I suppose what I'm trying to get across is that the general misconceptions
held by most, are what the governments, prosecutors, forensic specialists,
and others "in the business" rely upon.
The attitude that drives are wiped by various ineffective techniques and
tools are the "bread and butter" used in forensic and recovery activities.
Many of the recovery tools (such as those I directed Franc to) have
settings specifically for supposedly wiped disks, including re-fdisked and
re-formatted and reused.
real@hotmail.com MEB
comments.
--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________
"Jeff Richards" <JRic...@msn.com.au> wrote in message
news:e2BjryS6...@TK2MSFTNGP03.phx.gbl...
Jeff Richards
None of the 'issues" you identify in the WinHex help is fundamentally
different than DOS days. With DOS there are areas of the disk that are
inside and outside of the partition. DOS has directories that contain the
names of current and deleted files. DOS has the content of deleted files
still saved on disk (unless overwritten). DOS partition, directory and FAT
structures can be displayed properly formatted so you don't have to work out
the bits and bytes. Certain DOS structures can be identified by data
patterns regardless of where they are located on the disk. Some DOS files
(current or deleted) can be identified by their signature and displayed in a
sensible format.
Of course the details are different because FAT and NTFS are very different
file systems, and specifically the amount of information that can be
obtained from an NTFS directory entry is much greater than was ever stored
in a DOS directory entry, but the principal of how this information can be
recovered is identical.
You assumption about the significance of the WinHex options for bad sectors
is based on a misunderstanding of how the disk controller operates. At the
lowest level of the operating system, ie where it actually talks to the
controller, the data from a bad sector is available. Somewhere above that
level the system has to decide what to do with a sector full of data that
the disk controller tells it is bad. Normal OS operations throw the data
away and deal with a file read error by alerting the user, but there are
other possibilities. The WinHex options are simply a way of alerting you
to the error by displaying something obviously identifying it as bad; or you
can choose to see what was actually read, and take the risk that some of it
is garbage. The option to accept the data from a bad sector exists in DOS -
it was the ignore option of the famous 'Abort, retry, ignore' message, and I
have many times recovered large, usable slabs of a document by copying it
from a DOS prompt and keeping the i key pressed. Scandisk also includes the
option to accept bad data, and very often this means you can get at three
quarters of a bad cluster. So your assumption that there are some bad
sectors accessible to some programs and not accessible to others is not
correct - it's not accessibility that differs, it's what options the program
chooses to provide to the user.
I do not understand how you conclude "So if we wish to access a disk, but
NOT corrupt it initially, we would use
a non-drive." If by 'non-drive' you mean the physical disk, then WinHex
help offers three reasons - access outside the logical drive, search across
several partitions, or the partitioning is already corrupted. It does not
suggest that there is any difference in risk of further corruption between
using the two options. This risk is managed by controls within the
application that guard against writing to the disk. Or perhaps you are
saying that the best way to avoid further corruption is not to run XP, which
is certainly true but has nothing to do with whether you tell WinHex to look
at logical drives or physical drives.