One_Half infection

[Zeitkind]

Hi group,

have a One_Half infected machine here:

- I can see the "Dis was one half" and "Did you leave the room" in the
boot-sectors
- big HD (32GB), 2 partitions: 1. FAT16/2GB and 2. ext. with one big
NTFS inside
- the OS is NT4 - which doesn't boot anymore, stops at the first blue
screen (when the kernel load process starts)
- no DOS installed, so no way to boot the machine
- User didn't make *any* backups.. *sigh*

If I boot from another source, the directory of c: is scrambled (funny
chars, random filesizes etc.). No AV-program was able to detect the
virus (I tried several tools like NAV corp., AVP 3, F-Prot, McAfee..)
I'm kind of stuck now, because I see no real chance to get into the
system to start any backups while the virus-code is active. I dd'ed the
whole drive so I can reverse all changes before starting any tests.
Partition Magic doesn't show the partitions (error 110,116,120), Linux's
fdisk was at least able to see the FAT16 and an ext. partition - neither
could be mounted of course. A DOS-based NTFS-driver crashes immediatly
(to see the NTFS-partition in the extended partition), tools like
XOneHalf crash with a bogus runtime error 200 when started from a
RAM-Disk or CD.

The User had an older NAV installed, but he was (of course..) unable to
tell what NAV said a few days ago (*sigh*), but I believe, NAV tried to
disinfect without luck. The last thing he did was a normal reboot (his
Word was a bit slow, so he decided to reboot...).

Any hints, ideas how to get into NT again to backup at least the
remaining files?

TIA,
Hermann

 

[David W. Hodgins]

Hi group,

have a One_Half infected machine here:

http://www.ivi.co.il/iv_tools.php#XoneHalf

Regards, Dave Hodgins

 

[Zeitkind]

David W. Hodgins wrote:

http://www.ivi.co.il/iv_tools.php#XoneHalf

Well, I already tried all these tools. None was able to find the virus
in the bootblocks or partitiontable. But it must be still there because:
Though c: is totally scrambled (illegal chars, almots random count of
files and dirs in directory if booting from a clean DOS-floppy), it
still starts booting NT up to loading the kernel. This means: ntldr,
ntdetect and boot.ini must still be there and visible when booting from
the harddisk. I also do find the virus-messages with a diskeditor ("Dis
is one half").

Any more hints?

 

[Zeitkind]

What I can see is:

Sector 0: Code
Sector 1-9: empty
Sector 10: almost empty, some data (0190h:28 96 C4 17 00 00 00 00 02 00
00 00 24 00 00 00 00 00 00 00 01)
Sector 11-54: empty
Sector 55-63: Code, including typical virus words ("Dis is on half", the
list of not to infecting files, "Did you leave the room")
Sector 64ff: Code (NTLDR I guess: 0h:05 00 4E 00 54 00 4C 00 44 00 52 00
- which is " N T L D R")

(all numbers decimal)

 

[Keaf McRiff]

Hi,

Looks like you've inherited the notorious Gain Gator or even, God forbid,
Technic Rat.

Keaf

 

[Gabriele Neukam]

On that special day, Zeitkind, ([email protected]) said...

tools like
XOneHalf crash with a bogus runtime error 200 when started from a
RAM-Disk or CD.

This tool was probably written in an older Pascal version (six or
seven), and has a delay loop speed issue, on machines that are running
faster than 200 MHz. Try to find tppatch or a similar patching program,
which will fix the issue, hopefully.

http://www.brain.uni-freiburg.de/~klaus/pascal/runerr200/download.html


Gabriele Neukam

(e-mail address removed)

 

[Zeitkind]

Gabriele Neukam wrote:

This tool was probably written in an older Pascal version

already checked this out, both tools say no. But I found another one
still working (though this one doesn't find the virus either.. )

thx Hermann

 

[David W. Hodgins]

Well, I already tried all these tools. None was able to find the virus

There's a description of the virus at
http://vil.nai.com/vil/content/Print98226.htm

Please be a little more specific about what you've tried so far. Note that
the virus infects any floppy, that isn't write protected, that's accessed
while the virus is running. Are you sure you booted from a clean floppy
when trying the xonehalf cleaner? Have you previously tried "fdisk /mbr"
(if you haven't, DON'T!!!!), or anything similar that may have overwritten
part of the virus?

in the bootblocks or partitiontable. But it must be still there because:
Though c: is totally scrambled (illegal chars, almots random count of
files and dirs in directory if booting from a clean DOS-floppy), it
still starts booting NT up to loading the kernel. This means: ntldr,
ntdetect and boot.ini must still be there and visible when booting from
the harddisk. I also do find the virus-messages with a diskeditor ("Dis
is one half").
Any more hints?

Given that it's a dos based virus, I'm not surprised that it would have
trouble getting ntldr to run. Make sure you do not boot from anything
other then known clean floppies, until this has been solved, as each time
it boots, you'll lose two more cylinders to it's corruption routines.

Depending on how badly you need to recover what's on the disk I see the
following options.

If you have data on the drive you'd like to try to recover, but can afford to
risk losing, we can continue trial and error methods, till you either succeed,
or give up.

If you have data you must recover, contact a data recovery professional
familiar with the one-half virus, such as Zvi Netiv at
http://www.invircible.com/contact.php

If you're willing to do a format/reinstall, boot from a known clean dos floppy,
use "fdisk /mbr" to overwrite the boot code, run the clean track zero utility from
http://www.invircible.com/iv_tools.php to erase the rest of the first track, use
fdisk to delete/recreate the partition(s), reformat, and reinstall.

For the next step in the trial & error routine, if that's the way you want to go,
try ivinit, also from Zvi's site,
http://www.invircible.com/iv_tools.php

Regards, Dave Hodgins

 

[kurt wismer]

Gabriele Neukam wrote:




already checked this out, both tools say no. But I found another one
still working (though this one doesn't find the virus either.. )

i have the sneaking suspicion that you no longer actually have the
virus, only the damage left over from the payload...

 

[Zvi Netiv]

have a One_Half infected machine here:

- I can see the "Dis was one half" and "Did you leave the room" in the
boot-sectors
- big HD (32GB), 2 partitions: 1. FAT16/2GB and 2. ext. with one big
NTFS inside
- the OS is NT4 - which doesn't boot anymore, stops at the first blue
screen (when the kernel load process starts)
- no DOS installed, so no way to boot the machine
- User didn't make *any* backups.. *sigh*

One-Half became so rare that I took of the text about it from my page and only
left the xOneHalf utility, just in case ...

If I boot from another source, the directory of c: is scrambled (funny
chars, random filesizes etc.). No AV-program was able to detect the
virus (I tried several tools like NAV corp., AVP 3, F-Prot, McAfee..)
I'm kind of stuck now, because I see no real chance to get into the
system to start any backups while the virus-code is active. I dd'ed the
whole drive so I can reverse all changes before starting any tests.
Partition Magic doesn't show the partitions (error 110,116,120), Linux's
fdisk was at least able to see the FAT16 and an ext. partition - neither
could be mounted of course. A DOS-based NTFS-driver crashes immediatly
(to see the NTFS-partition in the extended partition), tools like
XOneHalf crash with a bogus runtime error 200 when started from a
RAM-Disk or CD.

That's because you are booting from DOS 7.1 or later (supports FAT-32) and the
xOneHalf program was written with an earlier version of Pascal as correctly
stated by Gabriele Neukman. BTW, the program on my site cannot be patched with
TPPATCH because it is double packed, but I fixed it (unpacked and patched) and
the version now available will work. But I am afraid that the chance to recover
the encrypted cylinders was missed by the unfortunate attempt to disinfect,
described next.

The User had an older NAV installed, but he was (of course..) unable to
tell what NAV said a few days ago (*sigh*), but I believe, NAV tried to
disinfect without luck. The last thing he did was a normal reboot (his
Word was a bit slow, so he decided to reboot...).

Could still be worth trying XONEHALF C: /D after booting of external DOS.
Download the current file at www.invircible.com/download/xonehalf.exe, with the
fix.

Regards, Zvi

 

[Zvi Netiv]

Hi group,

have a One_Half infected machine here:

On a second thought, the described problem was surely NOT caused by an One_half
infection but plain file system corruption.

- I can see the "Dis was one half" and "Did you leave the room" in the
boot-sectors

These strings are part of the One-Half virus boot overlay that is written to the
end of track zero on an infected hard drive. Yet their presence doesn't
necessarily indicate that the drive is infected. In order to load the overlay
to memory, the virus must have patched the MBR program, to instruct the computer
to read the overlay and execute it, as part of the boot process. It is THIS
portion of code, in the MBR, that antivirus software look for in order to detect
the presence of One-Half, NOT for the overlay. The presence of the OH overlay
on track 0 indicates that the One-Half virus ran in the drive's past with that
drive installed, but it could have been cleaned, or ignored, ages ago.

For reasons explained further, the damage described COULD NOT BE CAUSED by
One-Half.

- big HD (32GB), 2 partitions: 1. FAT16/2GB and 2. ext. with one big
NTFS inside

Due to its antiquity, the largest drive capacity that One-Half can treat is 8 GB
(max of 1023 cylinders). Any drive larger than that will be treated as having
just 1023 cylinders (in BIOS translation values).

- the OS is NT4 - which doesn't boot anymore, stops at the first blue
screen (when the kernel load process starts)

First, a brief explanation on how One-Half works.

After having installed its boot overlay, One-Half encrypts a couple of cylinders
on every boot, starting with the encryption of the highest cylinder (1023 in our
case). The cylinder encryption progresses until the cylinder half way between
max and zero is reached (511 in our case), when the boot process hangs and the
message "Dis is One Half ... etc." is displayed. Information about the
cylinders already encrypted, as well as the key for decrypting them, are both
retained in the MBR and any attempt to fix the MBR without first decrypting the
encoded cylinders will render that portion irrecoverable as the decryption key
will be lost.

One more important detail about One-Half: The virus overlay code must be
memory-resident throughout the entire session to correctly decrypt/encrypt the
data written or read to/from the encoded cylinders. This worked fine for DOS as
well as for early Windows versions that still have real DOS in the basement.
Yet the One-Half memory resident portion cannot make the transition through the
loading of NT, and in result, the encoded cylinders should have disclosed
themselves as corrupted data at a very early stage of the infection. IOW, a
genuine One-Half infection on an NT drive couldn't have gone that far.

- no DOS installed, so no way to boot the machine
- User didn't make *any* backups.. *sigh*

If I boot from another source, the directory of c: is scrambled (funny
chars, random filesizes etc.). No AV-program was able to detect the
virus (I tried several tools like NAV corp., AVP 3, F-Prot, McAfee..)

Virtually, almost every AV will detect One-Half in the MBR reliably, provided
the antivirus is run from DOS. As for decrypting the OH encoded cylinders, two
of the products mentioned do systematically botch the decoding, rendering the
drive unrecoverable. The only program that never failed decoding OH is
xOneHalf, which I have put on my site, courtesy of Dr. Peter Hubinsky from SAC.

As stated in a previous post, the program was fixed to run properly on newer
platforms, and was reloaded to my site.

I'm kind of stuck now, because I see no real chance to get into the
system to start any backups while the virus-code is active.

Without the OH patch in the MBR, the virus cannot go resident as the virus
overlay code doesn't get to be read in the boot process. The virus overlay that
you see is plain inert code and you can get rid of it with the CleanTrack0
utility (AFTER you made sure with xOneHalf that the OH patch cannot be found in
the MBR), from www.invircible.com/iv_tools.php#CleanTrk CleanTrackZero must
run from real DOS, and you may use the FreeDOS boot disk maker, available from
the same page as C;eanTrack0.

The most decisive proof that NOT One-Half is what messed with the drive is the
fact that this virus doesn't reach such low cylinder to manifest its doing on
cylinder 0, where both the FAT and the root directory of the FAT-16 partition
are located! The lowest cylinder that OH would encode on your drive is 511.

The damage described looks far more as plain file system corruption, and it's
possible that the extended partition is still intact and just needs to be
resurfaced.

I dd'ed the
whole drive so I can reverse all changes before starting any tests.

Good thinking.

Partition Magic doesn't show the partitions (error 110,116,120), Linux's
fdisk was at least able to see the FAT16 and an ext. partition - neither
could be mounted of course. A DOS-based NTFS-driver crashes immediatly
(to see the NTFS-partition in the extended partition), tools like
XOneHalf crash with a bogus runtime error 200 when started from a
RAM-Disk or CD.

xOneHalf was fixed, as explained above. I suspect that an erroneous setup of
the drive in the BIOS could also be part of the problem.

The User had an older NAV installed, but he was (of course..) unable to
tell what NAV said a few days ago (*sigh*), but I believe, NAV tried to
disinfect without luck. The last thing he did was a normal reboot (his
Word was a bit slow, so he decided to reboot...).

I suspect that you are on a false track, fed by unfounded speculations.

Any hints, ideas how to get into NT again to backup at least the
remaining files?

Download RESQ from www.invircible.com/resq.php, prepare a RESQ work floppy as
instructed when running resq.exe, boot the drive from floppy and run RESQDISK
/ASSESS from the *write-enabled* floppy. Post here the report file found on A:,
with the name RESQDISK.RPT. Don't attach the file, just paste in your post -
it's a plain text file.

Regards, Zvi

 

[Zeitkind]

Well.. thanks to all answers.. great group here

First - I will get almost all data back. The way is easy - if you know,
what the virus did. I still have a problem with Ontrack, but this has
nothing to do with the virus now. The whole story:


- the drive was infected two times I guess

- the virus was no longer in the bootblock - but this seemd to happen
immediatly after the infection (I think, there were 2 infections, one
some days ago - killed correctly by NAV before the virus was loaded -
and one immediatly before problems started)

- the virus(?) damaged the filesystem badly:
Running some recovery-tools I noticed a big gap searching for partitions:
Most tools showed me a 2GB BIGDOS and a damaged (unknown) with about
28GB. You never really count all blocks, so I didn't noticed the missing
2GB to get the drives capacity of 32GB.
One tool gave me a little hint that the 2GB partition was at the same
place as a 4GB NTFS.. uuups... and a 2GB-hole between the first and the
second partition (of unknown type).

0-- 2GB FAT -- 2GB empty -- 28GB unknown or
0-- 4GB NTFS -- 28GB unknown

So I tried to get that for sure and rewrote the partition-table manually
(thanks to ntfs.com) to 4GB NTFS and an extended partition with a NTFS
inside.
Reboot, started Ontrack and surprise, surprise, I saw the files from the
first partition. So the "scrambled" directories I saw was a NTFS shown
as FAT16...
What is completely unclear to me is why NT still booted up to loading
the kernel!? I believe now that the NTLDR had his own code for NTFS and
"just read the files", but the kernel was then unable to identify its
own drive (kernel driver took over) and crashed.

The second partition was simular, though not easy either. Ontrack
crashed when trying to read from the second partition, other tools I
tried never found a file or crashed.
I counted all blocks and noticed 2MB missing to fill up a "whole" 4GB. I
then rewrote the MBR again to
0-- 4GB NTFS -- 2MB unused -- extended with NTFS inside
I was then able to see the secomd partition with Ontrack.

I will now try to back up all data and check the integrity. It seems,
that the virus was started and rewrote the MBR. After the first boot,
the virus got active and damaged the 4GB-NTFS by placing a 2GB-FAT16 at
its place. The virus then got kicked out by loading NT and the computer
crashed. The wrong partition type (FAT16) is still unclear, might be a
result of the user using a bad tool to recover on its own or a poorly
written AV-program or an error in the virus' code.
The 2MB missing at the end of the 4GB are either strange or the first
attempt of the virus to shrink the partitions - how knows.

Two things are still strange to me: Why was the MBR clean and why did NT
load that far? The clean MBR was perhaps done by the user by starting a
AV-tool (no user will ever tell you the whole truth what he did.. .
And NT is a funny system.. the still booting NT fooled me a long time..

Anyway, gonna try tomorrow to backup all files (with Ontrack or whatever
is able to get the files), but this seems to be easier now and "normal"
recovery sStarting XP and its fsck was no good idea btw.. it corrected
thousands of files for hours on booting and left over 2 totally
corrupted partitons (RAW)..).

thx again for all advices,
Zeitkind



btw.. it funny. Since I posted here, I get more worm-mails than before,
indeed the first ever on this address. *sigh*

 

[Zvi Netiv]

Well.. thanks to all answers.. great group here

First - I will get almost all data back.

I am glad for the recoverable data. Yet I doubt that you drew the right
conclusions from the incident and learned what to do and especially what to NOT
do in similar cases. What happened has little to do with One-Half and viruses
in general, and everything to do with disaster recovery procedures!

The way is easy - if you know, what the virus did.

The virus didn't, but someone else did ...

I still have a problem with Ontrack, but this has
nothing to do with the virus now. The whole story:

- the drive was infected two times I guess

- the virus was no longer in the bootblock - but this seemd to happen
immediatly after the infection (I think, there were 2 infections, one
some days ago - killed correctly by NAV before the virus was loaded -
and one immediatly before problems started)

Impossible. From your current post we know that both partitions were NTFS,
hence no DOS whatsoever could ever run from that drive. One-Half is a DOS
memory resident virus and the only way it installs its hard drive boot overlay
portion is by executing an infected file, under DOS! One-Half does not infect
the floppy boot sector. Moreover, One-Half cannot not infect when accidentally
run under NT, and the suposedly infected program will terminate with a message
from NT "A process attempted direct drive access", and abort.

Therefore, the One-Half boot overlay could only be written when running an
infected file (command.com?) from external DOS boot. I very much doubt that
whoever ran that, managed to have NAV on that floppy!

One more detail about One-Half: When installing its boot overlay, the virus
patches the MBR loader portion (the tiny program that occupies the first part of
the MBR sector) and doesn't touch

- the virus(?) damaged the filesystem badly:

Who damaged the file system is a descendent of homo erectus, assisted by the
wrong disk repair application. Most probably Norton Disk Destroyer.

Running some recovery-tools I noticed a big gap searching for partitions:
Most tools showed me a 2GB BIGDOS and a damaged (unknown) with about
28GB. You never really count all blocks, so I didn't noticed the missing
2GB to get the drives capacity of 32GB.
One tool gave me a little hint that the 2GB partition was at the same
place as a 4GB NTFS.. uuups... and a 2GB-hole between the first and the
second partition (of unknown type).

0-- 2GB FAT -- 2GB empty -- 28GB unknown or
0-- 4GB NTFS -- 28GB unknown

Trying to figure out the original partition(s) layout is the first thing to do
when dealing with recovery of access to partitions. I have been explaining for
years, here and in other discussion groups, why antivirus (and disk repair) are
problematic in resolving this sort of problems.

Read the discussion on "Handling boot viruses" in the following thread:
http://groups.google.com/groups?hl=en&[email protected]

So I tried to get that for sure and rewrote the partition-table manually
(thanks to ntfs.com) to 4GB NTFS and an extended partition with a NTFS
inside.

You could do better, and easier, by following my advice on analyzing the drive
with RESQDISK /ASSESS. Then I would have told you how to reconstruct the
partition table in the MBR in a simple RESQDISK /REBUILD run.

If you hadn't messed the corrupted partitions by attaching the drive to XP, then
the drive would boot right away and the files could be available. Full recovery
could still be possible for the upper and larger partition. The lower one may
be lost due to grinding by XP's checkdisk.

Reboot, started Ontrack and surprise, surprise, I saw the files from the
first partition. So the "scrambled" directories I saw was a NTFS shown
as FAT16...

No surprise at all, if you had assessed the drive, instead of speculating
One-Half, and acting upon.

What is completely unclear to me is why NT still booted up to loading
the kernel!? I believe now that the NTLDR had his own code for NTFS and
"just read the files", but the kernel was then unable to identify its
own drive (kernel driver took over) and crashed.

The loading of NTLDR doesn't depend on the file system. Read post 76 from
Robert Green, in the above thread. It explains it.

The second partition was simular, though not easy either. Ontrack
crashed when trying to read from the second partition, other tools I
tried never found a file or crashed.

The second partition should still be fully recoverable unless you ground it too
with NDD, or by slaving the drive on an XP machine.

I counted all blocks and noticed 2MB missing to fill up a "whole" 4GB. I
then rewrote the MBR again to
0-- 4GB NTFS -- 2MB unused -- extended with NTFS inside
I was then able to see the secomd partition with Ontrack.

The correct procedure should be:

1. Locate the backup boot sector at the estimated end of the NTFS partition, and
note down the number of the logical block where the backup BS is found.

2. Read the total number of sectors in partition from the backup boot sector,
subtract from the block number found in step 1, and rewrite the backup sector to
the sector at calculated number. The sector should be number 1 on head 0 (or on
head 1, if head 0 on the same cylinder contains an extended partition table).

I will now try to back up all data and check the integrity. It seems,
that the virus was started and rewrote the MBR.

Forget that nonsense. One-Half rewrote the MBR for patching the boot loader,
but didn't touch the partition table. What modified the partition table and
converted the first partition boot sector from NTFS to FAT-16 is antivirus
software, or more likely, ignorant use of disk repair software.

After the first boot,
the virus got active and damaged the 4GB-NTFS by placing a 2GB-FAT16 at
its place.
Wrong.

The virus then got kicked out by loading NT and the computer
crashed. The wrong partition type (FAT16) is still unclear, might be a
result of the user using a bad tool to recover on its own or a poorly
written AV-program or an error in the virus' code.

You start getting it, but just barely.

The 2MB missing at the end of the 4GB are either strange or the first
attempt of the virus to shrink the partitions - how knows.

My guess is that you'll find the backup boot sector of a 6 GB NTFS partition
somewhere on the last cylinder of the first partition.

Two things are still strange to me: Why was the MBR clean and why did NT
load that far?

Post 76 in the thread above explains it.

The clean MBR was perhaps done by the user by starting a
AV-tool (no user will ever tell you the whole truth what he did.. .
And NT is a funny system.. the still booting NT fooled me a long time..

It shouldn't have. You should speculate less and reason more.

Anyway, gonna try tomorrow to backup all files (with Ontrack or whatever
is able to get the files), but this seems to be easier now and "normal"
recovery sStarting XP and its fsck was no good idea btw.. it corrected
thousands of files for hours on booting and left over 2 totally
corrupted partitons (RAW)..).

You wrote that you duplicated the drive through Linux's dd. You should be able
to attempt full restore from a clone, before it got messed by XP and the manual
editing of the MBR.

btw.. it funny. Since I posted here, I get more worm-mails than before,
indeed the first ever on this address. *sigh*

That's because you post on Usenet with your real e-mail address. Just don't, if
you don't want to be flooded with spam and bogus e-mail.

Regards, Zvi

 

[Gabriele Neukam]

On that special day, Zeitkind, ([email protected]) said...

btw.. it funny. Since I posted here, I get more worm-mails than before,
indeed the first ever on this address. *sigh*

Post with an address that "repels" the Swen worm (which reads newsgroups
for addresses to attack - swen is news spelled backwards). The addresses
which contain "spam" (like mine) or "remove" will be left alone.


Gabriele Neukam

(e-mail address removed)

 

[Zeitkind]

I am glad for the recoverable data. Yet I doubt that you drew the right
conclusions from the incident and learned what to do and especially what to NOT
do in similar cases.

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.
Six (!) years without any backups is a good point to start searching for
files.. (the first drive was replaced with this one and was erased short
after it..)

What happened has little to do with One-Half and viruses
in general, and everything to do with disaster recovery procedures!

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

The virus didn't, but someone else did ...

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

Impossible.

Fact is: I found the virus (or better its parts) in sector 55pp. 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..

Who damaged the file system is a descendent of homo erectus, assisted by the
wrong disk repair application. Most probably Norton Disk Destroyer.

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.

Trying to figure out the original partition(s) layout is the first thing to do
when dealing with recovery of access to partitions.

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.

You could do better, and easier, by following my advice on analyzing the drive
with RESQDISK /ASSESS. Then I would have told you how to reconstruct the
partition table in the MBR in a simple RESQDISK /REBUILD run.

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

^-^

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

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.

If you hadn't messed the corrupted partitions by attaching the drive to XP, then
the drive would boot right away and the files could be available.

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

No surprise at all, if you had assessed the drive, instead of speculating
One-Half, and acting upon.

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

The loading of NTLDR doesn't depend on the file system. Read post 76 from
Robert Green, in the above thread. It explains it.

NTLDR - yes. But what about boot.ini and ntdetect? Both were loaded too.

The second partition should still be fully recoverable unless you ground it too
with NDD, or by slaving the drive on an XP machine.

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.

The correct procedure should be:

1. Locate the backup boot sector at the estimated end of the NTFS partition, and
note down the number of the logical block where the backup BS is found.

There is no working backup boot sector left to work with. Just see what
resqdisk did.

2. Read the total number of sectors in partition from the backup boot sector,
subtract from the block number found in step 1, and rewrite the backup sector to
the sector at calculated number. The sector should be number 1 on head 0 (or on
head 1, if head 0 on the same cylinder contains an extended partition table).

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

Forget that nonsense. One-Half rewrote the MBR for patching the boot loader,
but didn't touch the partition table.

Whoever touched it - it touched it badly.

What modified the partition table and
converted the first partition boot sector from NTFS to FAT-16 is antivirus
software, or more likely, ignorant use of disk repair software.
ACK.

You start getting it, but just barely.

This is why I hate Windows-based stuff: It's illogical, strange and weired.

My guess is that you'll find the backup boot sector of a 6 GB NTFS partition
somewhere on the last cylinder of the first partition.

What I do find is empty space.

Post 76 in the thread above explains it.

Will read it, I am willing to learn. But I still wonder how it manages
to load boot.ini and ntdetect.

It shouldn't have. You should speculate less and reason more.

see above.

You wrote that you duplicated the drive through Linux's dd.

It was MacOS X, but this is quite the same..

That's because you post on Usenet with your real e-mail address. Just don't, if
you don't want to be flooded with spam and bogus e-mail.

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.

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.

Zeitkind

 

[Zvi Netiv]

Zvi Netiv wrote:

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