Virus damage??

  • Thread starter Thread starter mscotgrove
  • Start date Start date
M

mscotgrove

I have a FAT32 disk drive which should have about 60GB of data (the
drive is 400GB). According to my customer it crashed, and then was
brought back to life again (somehow) but many files are missing.

They are missing because the directory entries have been (randomly?)
corrupted, but in a rather odd way.

The file name still exists in both short and long format but the date,
file size, and cluster pointers are all zero. The interesting
possible pointer is that ! signs have been added. A typical failed
directory entry looks like below


4D 45 44 49 41 7E 31 20 42 41 4E 10 00 00 00 00 00 MEDIA~1 BAN
21 00 21 00 00 00 00 00 21 00 00 00 00 00 00 00
00 ! ! !

It occurrs on files and directories, but not in the long file name
section of the directory entry. The second 16 bytes of the entry have
been deleted, and just some 0x21s put in place.

With no cluster pointer, and no length recovery is not easy, but I
think the FAT is still intact

Has anyone seen this type of corruption, is it a virus?

Thanks

Michael
 
I have a FAT32 disk drive which should have about 60GB of data (the
drive is 400GB). According to my customer it crashed, and then was
brought back to life again (somehow) but many files are missing.

They are missing because the directory entries have been (randomly?)
corrupted, but in a rather odd way.

The file name still exists in both short and long format but the date,
file size, and cluster pointers are all zero. The interesting
possible pointer is that ! signs have been added. A typical failed
directory entry looks like below


4D 45 44 49 41 7E 31 20 42 41 4E 10 00 00 00 00 00 MEDIA~1 BAN
21 00 21 00 00 00 00 00 21 00 00 00 00 00 00 00
00 ! ! !

It occurrs on files and directories, but not in the long file name
section of the directory entry. The second 16 bytes of the entry have
been deleted, and just some 0x21s put in place.

With no cluster pointer, and no length recovery is not easy, but I
think the FAT is still intact

Has anyone seen this type of corruption, is it a virus?

Thanks

Michael
Click to expand...

I experimented (in a Win98SE DOS window) by creating a small text file
on a floppy diskette as follows:

echo junk > a:\blahblah.txt

After using Debug to hack the directory as per your example, a dir
listing showed the following:

BLAHBLAH TXT 0 07-31-96 12:00a blahblah.txt

I then used "chkdsk /f" to repair the file system, after which the
lost cluster/sector was saved as file0000.chk with a file size of 512
bytes.

It seems to me that in the worst case you could recover your client's
data by running scandisk on a cloned copy of the damaged file system
and then laboriously identifying and renaming each .chk file.

I suppose you could also write a program to systematically examine the
file headers to more easily determine the file type, eg .exe, .jpg,
..htm, .doc, etc.

You could generate a list of damaged files (excepting those in damaged
directories) as follows:

dir /s | find "07-31-96 12:00a" > a:\bad_list.txt

I also experimented by creating a directory as follows:

md a:\bad_dir
echo 1> a:\bad_dir\filename.one
echo 2> a:\bad_dir\filename.two

I then used Debug to damage the directory as in your example.

These are the results (edited for brevity):

C:\WIN98SE>dir a:\bad_dir\*.*

BLAHBLAH TXT 0 07-31-96 12:00a blahblah.txt
FILE0000 CHK 512 11-23-91 5:49p FILE0000.CHK
BAD_DIR <DIR> 07-31-96 12:00a bad_dir

Note that the current directory contents are listed, not the contents
of the damaged directory.

After chkdsk ...

C:\WIN98SE>chkdsk a:

A:\_
Invalid sub-directory entry

3 lost allocation units found in 3 chains.
1,536 bytes disk space would be freed

After scandisk ...

C:\WIN98SE>dir a:

DIR00001 <DIR> 11-24-07 7:39a DIR00001

Checking the contents of the damaged directory ...

C:\WIN98SE>dir a:\dir00001

Directory of A:\DIR00001

. <DIR> 11-24-07 7:30a .
.. <DIR> 11-24-07 7:30a ..
FILENAME ONE 3 11-24-07 7:31a filename.one
FILENAME TWO 3 11-24-07 7:31a filename.two
2 file(s) 6 bytes
2 dir(s) 1,000,448 bytes free

Checking the integrity of the files within the damaged directory ...

C:\WIN98SE>type a:\dir00001\filename.one
1

- Franc Zabkar
 
- Show quoted text -
Click to expand...

Franc,

Thankyou for your suggestion but fortunately my recovery program is
actually much more powerful. I can read the good files on the disk,
and then read all remaining FAT entries. This will produce nameless
files with valid sequences, so fragmented files can be handled. I then
process the new file, and determine the file type, and often with say
MP4 files, add a suitable file name. However, not all files can be
named and I do have many files of the same type ( eg .AIF music files)
that will have to be opened to determine the contents.

My question to the group does remain the same, any idea what may have
caused the initial corruption?

Regards


Michael
www.cnwrecovery.com
 
Franc,

Thankyou for your suggestion but fortunately my recovery program is
actually much more powerful. I can read the good files on the disk,
and then read all remaining FAT entries. This will produce nameless
files with valid sequences, so fragmented files can be handled. I then
process the new file, and determine the file type, and often with say
MP4 files, add a suitable file name. However, not all files can be
named and I do have many files of the same type ( eg .AIF music files)
that will have to be opened to determine the contents.

My question to the group does remain the same, any idea what may have
caused the initial corruption?

Regards


Michael
www.cnwrecovery.com
Click to expand...

Sorry, I should have paid attention in the other data recovery thread.
Nevertheless, it seems to me that in this particular case Scandisk can
do most of what is required, apart from identifying the file types.

As for what caused the damage, I have no idea, but AFAICT the actual
directory entries are still in a valid format. For example, if I use
the following commands to create a file of zero size, that file will
have no starting cluster, as is the case with your damaged files.

dir a: --> 1,000,448 bytes free
rem > a:\zerosize.ext
dir a: --> 1,000,448 bytes free

The 0x21 bytes all appear to be part of the various date fields
(DIR_CrtDate, DIR_LstAccDate, DIR_WrtDate).

I would suspect that malware was responsible for the damage, although
I wonder whether this could be due to some bizarre kind of third party
"Recycle Bin" ???

- Franc Zabkar
 
Franc Zabkar said:
Sorry, I should have paid attention in the other data recovery thread.
Nevertheless, it seems to me that in this particular case Scandisk can
do most of what is required, apart from identifying the file types.

As for what caused the damage, I have no idea, but AFAICT the actual
directory entries are still in a valid format. For example, if I use
the following commands to create a file of zero size, that file will
have no starting cluster, as is the case with your damaged files.

dir a: --> 1,000,448 bytes free
rem > a:\zerosize.ext
dir a: --> 1,000,448 bytes free

The 0x21 bytes all appear to be part of the various date fields
(DIR_CrtDate, DIR_LstAccDate, DIR_WrtDate).

I would suspect that malware was responsible for the damage, although
I wonder whether this could be due to some bizarre kind of third party
"Recycle Bin" ???
Click to expand...

The corruption wasn't caused by malware, but by the use of improper technique
for the recovery of the lost partition.

The recovery of files may still be possible, on condition that they were
contiguous (unfragmented) at the time the partition was lost.

Regards, Zvi
 
The corruption wasn't caused by malware, but by the use of improper technique
for the recovery of the lost partition.

The recovery of files may still be possible, on condition that they were
contiguous (unfragmented) at the time the partition was lost.

Regards, Zvi
--
NetZ Computing Ltd. ISRAEL www.invircible.com
InVircible Malware Protection, ResQ and Data Recovery- Hide quoted text -

- Show quoted text -
Click to expand...


I am interested why you think it was caused by "improper technique
for the recovery of the lost partition."

Why would this cause the directory entries of some files, and only
some files to be corrupted / cleared in the way they have?


I did manage to recover all the files, because the FAT was still
intact. The problem was naming the files as the 'failed' directory
entries had no size, or first cluster location value. There was no way
to tie up a file with a file name. My main solution on file naming
was to extract names from files that include a description, as this
was mainly MP3 and M4A files, 90% were OK. The rest ended up with
just dummy names.

Thanks for your suggestion

Michael
www.cnwrecovery.com
 
Back
Top