Zeitkind said:
Sorry, but I normally first believe what users say - though I always
tend to not take their words for the holy truth. The user said
"something with 'one half'" when asked for suspicious messages the last
few days before the crash. Finding the leftover of OneHalf in sector
55pp was then some kind of a first "proof" about what the users said.
The user having mentioned One-Half is a valid clue. The immediate conclusion I
would draw on observing the file system corruption would be that the drive was
subsequently manipulated with AV, and *more likely*, with NDD (and/or PM). The
difference is experience with this particular virus, and in disaster recovery.
I normally only fix MacOS partitions (for many years now) and never lost
any data, I seldom have to fix Win stuff for this is all kind of strange
and illogical
Well, there always is a first time, and FAT16/32 and NTFS structures aren't
really that complicated.
Whoever. The info about this virus wasn't that great and I won't try to
disassamble this one. My last dealing with machine-code was 6502.. ^^
No need to disassemble One-Half, virus researchers did it before, and the info
provided online in Kaspersky's virus encyclopedia is excellent! Check
http://www.viruslist.com/eng/viruslist.html?id=1701438
Fact is: I found the virus (or better its parts) in sector 55pp.
And misinterpreted the finding, which led to the next mistake ... and on your
way on a wild goose chase ...
The system always run NT. If the user ever started any CD- or floppy-based
tool - I just don't know and he won't say it..
The question to ask the user when you discovered the traces of One-Half AND the
file system corruption was: "Attempt to fixing the drive after the incident was
done! What did you use?" My guess is that someone tried an old version of NDD
that doesn't support NTFS, only FAT, or PM. The antiquity of One-Half, and of
NT4, suggests that the user still keeps an archaic copy of this harmful utility.
Here is why it's important to clear this issue: From your previous posts, it's
almost certain that One-Half was accidentally run from CD or from floppy. If
so, then the infected boot disk could still be around and may affect other PCs,
if used.
I never used NDD - except for file-pattern-based search on totally
crashed MacOS disks. There is a good reason why Symantec stopped NDD for
MacOS a few months ago.
The user may have used it.
Not if you "just have to get rid of a virus". If you see no partitions
at all or if the user blanked out the partition-table (Partition Magic,
fdisk, mkfs, whatever) - yes.
As a rule, a "virus incident" followed by a self-boot problem is no more a virus
problem but a disaster recovery one and should always be approached by disaster
recovery methods. Your case isn't the first one, nor last, where an apparently
boot virus ended in full blown disaster. The usenet archives of these groups
are full of such examples.
A basic rule in disk recovery is to not trust disk configuration parameters as
they all could be changed, starting with the drive setup parameters in the BIOS,
through partition, extended partition, and boot sectors. All could be modified
and need to be revalidated through supporting evidence.
Oh yes.. this tool was indeed funny. Its suggestions doubled the disk
space to 60GB
0-- 2GB FAT16 -- ext. -- corrupt 28GB -- ext.-X -- 28GB NTFS --|
Nonsense. Self confidence could be a merit, but when combined with ignorance
then it becomes dangerous. There is a good reason why I asked you to first
assess the drive and post the findings here, before letting you jump to hasty
conclusions and further endanger the user's data.
RESQDISK didn't "double" the disk space, it just showed you the data in all the
partition and extended partition sectors that it found. A quick inspection of
the report would reveal that the two large partitions overlap, as well as show
inconsistencies on the primary partition data. BTW, the total drive capacity is
shown in the very first part of the RESQDISK report, and obtained through the
"identify" command of the disk own BIOS. This is the only trusted parameter as
it's obtained from the hardware.
If you ran RESQDISK /NTFS /REBUILD, and rejected all potential ext-partition
sectors except the one on cylinder ~700-750, then you would get the correct
partition table in the MBR. This is on condition that you last post can be
trusted for accuracy.
I bet that you haven't read the RESQDISK documentation.
I never trust such tools. If I have a backup (suntar, dd or simular) and
can "play" with the drive, I first try to set the partition table to a
reasonable default and see what happens. And if a RAID5 is damaged, I
call Ontrack...
RESQDISK needn't to be "trusted", it's an entirely user controlled tool. If at
all, then question your competence in using it.
The only tool which was close to the original layout was Winternals Disk
Commander - expensive, but worth the money IMHO if they ever manage to
rescue complete folders... Wiping the MBR before running it gave at
least a chance to get most data back with Ontrack after rewriting the
MBR with its suggestions.
Zeroing the MBR in order to re-detect the correct drive setup parameters is
sometimes necessary, if the BIOS setup parameters are wrong, but I wouldn't know
without the ASSESS report. Zeroing the partition in the MBR with RESQDISK is
simple, just run it with the /KILL argument and reboot. Yet it wouldn't be
necessary before doing /NTFS /REBUILD if the BIOS parameters are correct. The
rebuild procedure takes care of it. The above is explained in the RESQDISK
online documentation.
There we have the difference between a real OS like Solaris and the weak
Windows. fsck would never run with these defaults. A later test with
Windows 2003 Server should btw. that M$ is willing to learn - Win2k3
didn't touch the drive. We finally run Ontrack on a 2k3-based system,
all DOS-based approaches crashed on two different machines (seg fault).
Don't blame the floor if you can't dance. ;-)
And again: The virus' code is in sector 55pp, the drive showed up
without errors (except the scrambled filenames), all tools gave me FAT16
as partition type (including yours..
.
Scrambled filenames ARE evidence of a corrupted file system. What did you
expect to see, a horror movie perhaps? As to the FAT partition type that you
saw, of course all showed FAT because THIS is what you (or the user) put there
by some bad manipulation of the drive.
NTLDR - yes. But what about boot.ini and ntdetect? Both were loaded too.
The presence of additional and overlapping partitions strongly suggests that
Partition Magic also participated in messing the drive. A possible scenario is
as follows: User panics in result of seeing the One-Half message, tries
"disinfecting" and loses access or self boot to the drive, then tries to fix it
with Partition Magic. The latter then perpetuates the mess by consolidating the
FAT-16 primary partition, PM attempts the conversion of the startup files to the
consolidated FAT partition, then crashes when it reaches a dead end.
The second partition is still damaged. Your resqdisk gave me even one
more. Ontrack somehow found a NTFS-partition with the exact size of the
space used (about 4GB I guess, the rest is just unused free space) and
was able to recover all files - though not with all directory names.
It's still possible that the higher partition is intact and the missing
directories are all there, if the partition table is correctly rebuilt.
There is no working backup boot sector left to work with. Just see what
resqdisk did.
RESQDISK did nothing to the backup boot sector, and your haste in jumping to the
wrong conclusions is in your detriment.
The free version of RESQDISK does not allow writing to sectors past track 0
(which is messed up anyway, and is always fully recoverable). The backup boot
sector should be found at the very last sector of the original NTFS partitions.
Note that NTFS partitions do not necessarily end at cylinder boundary. I very
much doubt that anything even touched that backup, not even Partition Magic.
Without the nicely written info on ntfs.com - calling Ontrack. You also
might get resqdisk counting blocks a bit better - doubling is diskspace
is nice, but.. sorry, couldn't resist..
Ignorance can be overcome with learning and experience, and displaying it loudly
isn't wise.
RESQDISK counts sectors (blocks) accurately, and the space
doubling nonsense is the fruit of plain ignorance and was discussed above.
Whoever touched it - it touched it badly.
Agreed, yet not uncommon.
This is why I hate Windows-based stuff: It's illogical, strange and weired.
As always, things start making sense with knowledge.
What I do find is empty space.
As explained above, NTFS partitions do not necessarily end on cylinder boundary,
which is why automatic recovery tools don't always find them. RESQDISK has an
hotkey that will help you in manually searching and finding the backup boot
sector of an original partition. Press ^P to toggle RESQDISK from CHS mode into
"extended" mode, navigate to the approximate CHS address you wish starting the
search (I would suggest a bit lower than 4 GB, and then a bit lower than 6 GB).
Then press ^B, and RESQDISK will search for candidate boot or extended partition
sectors. When found, an NT boot sector cannot be mistaken (you will see the
"NTLDR" string at the end of the sector), and an analysis with RESQDISK's ^A
hotkey will immediately tell whether it's FAT or NTFS, and show the BPB
parameters.
Will read it, I am willing to learn. But I still wonder how it manages
to load boot.ini and ntdetect.
Possibly PM doing, as explained above.
see above.
It was MacOS X, but this is quite the same..
Most spam gets kicked by my mailserver anyway (Helo command rejected,
RBL, spf). I still post with a real email address for this is just
normal - IMHO.
None of the regulars here thinks so, but it's up to you.
Anyway, thanx for any info regarding this virus. I do believe that your
tool is able to recover damaged system - but not this one. It made the
same wrong suggestions as most other tools did - except Winternals one.
You have a lot to learn about system recovery, and the wrong suggestions are all
yours.
Regards, Zvi
