Data recovery

Post by philo
A friend gave me their Windows 10 hard drive so I could try a data recovery.
I have gparted and gpart installed and it sees the data partition as NTFS
When I attempt to recover the data, it simply says : No file system
detected.
I did a file system check and all is OK
How the heck can I get it to work...or is there a better GUI based file
recovery app for Linux
Thanks

You could try rescuezilla or redorescue both of which have
shown up on the Distrowatch site recently. These are Live systems
which can be written to CD or to Flash Drive.
Can you get into the NTFS system from your Ubuntu?

If you cannot then you may need some components added to
your installation. Among these are the components that let you
access and read NTFS. Does GPartEd let you create a NTFS filesystem
on a partition or even a Flash Drive?

bliss - "Nearly any fool can use a computer. Many do.”
After all here I am...

--
bliss dash SF 4 ever at dslextreme dot com

philo

2020-11-06 11:47:46 UTC

    You could try rescuezilla or redorescue both of which have
shown up on the Distrowatch site recently. These are Live systems
which can be written to CD or to Flash Drive.
     Can you get into the NTFS system from your Ubuntu?
    If you cannot then you may need some components added to
your installation. Among these are the components that let you
access and read NTFS. Does GPartEd let you create a NTFS filesystem
on a partition or even a Flash Drive?
bliss - "Nearly any fool can use a computer. Many do.”
        After all here I am...

I can read the drive from Windows or Ubuntu but only some of the data .

If I can't recover anything, I may tell to send the drive to a data
recovery lab

red floyd

2020-11-06 02:37:44 UTC

Is it possibly a Bitlocker partition? Those show up as NTFS, but are
unreadable...

RobH

2020-11-06 09:53:41 UTC

Is it possibly a Bitlocker partition? Those show up as NTFS, but are
unreadable...

Yes, that was my thought as well.

Paul

2020-11-06 11:20:44 UTC

Post by RobH

Post by red floyd

Is it possibly a Bitlocker partition? Those show up as NTFS, but are
unreadable...

Yes, that was my thought as well.

If it's a Bitlocker partition, best-practice is to
make a Bitlocker recovery floppy/disc/key. That can
be used in emergencies, to decrypt the partition
and make plaintext of it. Normally, the instructions
for usage of Bitlocker, mention this, to encourage
the more dopey of users, to make their emergency
key disc.

Paul

philo

2020-11-06 11:53:27 UTC

Post by RobH

Is it possibly a Bitlocker partition? Those show up as NTFS, but are
unreadable...

Yes, that was my thought as well.

This is not a Bitlocker partition though

philo

2020-11-06 11:48:57 UTC

Is it possibly a Bitlocker partition? Those show up as NTFS, but are
unreadable...

It's her Windows partition but only a few folders are visible. I am
pretty sure the drive itself is defective.

Paul

2020-11-06 13:36:56 UTC

Post by red floyd

Is it possibly a Bitlocker partition? Those show up as NTFS, but are
unreadable...

It's her Windows partition but only a few folders are visible. I am
pretty sure the drive itself is defective.

ddrescue it to your spare drive. Check the ddrescue log for
evidence of any bad sectors.

Package: gddrescue

# Double-check your /dev designators before issuing the command!
$ gnome-disks can help with that.

sudo ddrescue -f -n /dev/sdb /dev/sdc /root/rescue.log

# Examine the LOG file for details. A large log file means
# there are many CRC errors.

less /root/rescue.log

# Now, the second pass reads the log, and concentrates only on the
# not-yet-captured sectors.

sudo ddrescue -d -f -r3 /dev/sdb /dev/sdc /root/rescue.log

Then, run a CHKDSK on the spare-drive-copy of the original drive.

You might also want to examine (with Disk Management or with fdisk/gdisk)
whether the partition table setup makes sense. Or, whether the partition
table has a problem (wrong size after a failed Windows "shrink" attempt).

It should also be remembered that:

1) Windows 10 damages $MFTMIRR. This prevents Linux mounts.
2) Windows 10 damages Volume Bitmap. Which is recoverable.
A CHKDSK should cover this. Like maybe a Windows 7 CHKDSK.

But any time I work on a wreck, the "dd" part comes first. CHKDSK
is a "repair in place" tool, which can damage things. That's why
you make a sector-level backup first. It's not because sector
level backups are wonderful. It's because sector level backups
(done offline, with another OS), cause the least disturbance
to the sick disk drive. Does nothing but linear reads.

Paul

philo

2020-11-07 07:09:46 UTC

Is it possibly a Bitlocker partition? Those show up as NTFS, but are
unreadable...

It's her Windows partition but only a few folders are visible. I am
pretty sure the drive itself is defective.

ddrescue it to your spare drive. Check the ddrescue log for
evidence of any bad sectors.
Package: gddrescue
   # Double-check your /dev designators before issuing the command!
   $ gnome-disks can help with that.
   sudo ddrescue -f -n /dev/sdb /dev/sdc /root/rescue.log
   # Examine the LOG file for details. A large log file means
   # there are many CRC errors.
   less /root/rescue.log
   # Now, the second pass reads the log, and concentrates only on the
   # not-yet-captured sectors.
   sudo ddrescue -d -f -r3 /dev/sdb /dev/sdc /root/rescue.log
Then, run a CHKDSK on the spare-drive-copy of the original drive.
You might also want to examine (with Disk Management or with fdisk/gdisk)
whether the partition table setup makes sense. Or, whether the partition
table has a problem (wrong size after a failed Windows "shrink" attempt).
1) Windows 10 damages $MFTMIRR. This prevents Linux mounts.
2) Windows 10 damages Volume Bitmap. Which is recoverable.
   A CHKDSK should cover this. Like maybe a Windows 7 CHKDSK.
But any time I work on a wreck, the "dd" part comes first. CHKDSK
is a "repair in place" tool, which can damage things. That's why
you make a sector-level backup first. It's not because sector
level backups are wonderful. It's because sector level backups
(done offline, with another OS), cause the least disturbance
to the sick disk drive. Does nothing but linear reads.
   Paul

No spare drive large enough, thanks

Gordon

2020-11-06 06:56:38 UTC

Post by philo
A friend gave me their Windows 10 hard drive so I could try a data recovery.

Could you tell us in more detail what you have and what you are trying to
do? Is the Win10 HD in working order? or does it not boot?

Post by philo
I have gparted and gpart installed and it sees the data partition as NTFS

gparted isnot, first anf foremost a data recovery tool.

Post by philo
When I attempt to recover the data, it simply says : No file system
detected.
I did a file system check and all is OK
How the heck can I get it to work...or is there a better GUI based file
recovery app for Linux

photorec, will recover files and some stuff which is still on the HD but not
in the file system. Might be more than what you want.

Finally, make an image of the Win10 HD before you try and recover any data.

https://www.cgsecurity.org/wiki/PhotoRec

philo

2020-11-06 12:10:59 UTC

Post by Gordon

Post by philo
A friend gave me their Windows 10 hard drive so I could try a data recovery.

Could you tell us in more detail what you have and what you are trying to
do? Is the Win10 HD in working order? or does it not boot?

Post by philo
I have gparted and gpart installed and it sees the data partition as NTFS

gparted isnot, first anf foremost a data recovery tool.

photorec, will recover files and some stuff which is still on the HD but not
in the file system. Might be more than what you want.
Finally, make an image of the Win10 HD before you try and recover any data.
https://www.cgsecurity.org/wiki/PhotoRec

I use gparted and is sees 200 gigs of data on the drive but the gpart
component does not even see a file system.

If PhotoRec does not see anything, I'm going to have her send it to a lab

thanks

Bobbie Sellers

2020-11-06 16:02:04 UTC

Post by Gordon

Post by philo
A friend gave me their Windows 10 hard drive so I could try a data recovery.

Could you tell us in more detail what you have and what you are trying to
do? Is the Win10 HD in working order? or does it not boot?

Post by philo
I have gparted and gpart installed and it sees the data partition as NTFS

gparted isnot, first anf foremost a data recovery tool.

photorec, will recover files and some stuff which is still on the HD but not
in the file system. Might be more than what you want.
Finally, make an image of the Win10 HD before you try and recover any data.
https://www.cgsecurity.org/wiki/PhotoRec

I use gparted and is sees 200 gigs of data on the drive but the gpart
component does not even see a file system.
If PhotoRec does not see anything, I'm going to have her send it to a lab
thanks

I think that you should back up an image of the drive, as others have
suggested using dd.

Of course if you have no recovery drive this may be hard or
expensive but not as expensive as the bill from data recovery will be.

bliss

--
bliss dash SF 4 ever at dslextreme dot com

philo

2020-11-07 07:09:11 UTC

Post by Bobbie Sellers

Post by Gordon

Post by philo
A friend gave me their Windows 10 hard drive so I could try a data recovery.

Could you tell us in more detail what you have and what you are trying to
do? Is the Win10 HD in working order? or does it not boot?

Post by philo
I have gparted and gpart installed and it sees the data partition as NTFS

gparted isnot, first anf foremost a data recovery tool.

photorec, will recover files and some stuff which is still on the HD but not
in the file system. Might be more than what you want.
Finally, make an image of the Win10 HD before you try and recover any data.
https://www.cgsecurity.org/wiki/PhotoRec

I use gparted and is sees 200 gigs of data on the drive but the gpart
component does not even see a file system.
If PhotoRec does not see anything, I'm going to have her send it to a lab
thanks

I think that you should back up an image of the drive, as others have
suggested using dd.
Of course if you have no recovery drive this may be hard or
expensive but not as expensive as the bill from data recovery will be.
bliss

Good idea but I have no spare drive large enough.

I am posting the rest of the details seperately

thanks

Paul

2020-11-06 11:36:05 UTC

This post might be inappropriate. Click to display it.

philo

2020-11-07 07:10:37 UTC

In Windows, use HxD and your "calibrated eyeball" to suss
what's on there. (You should be working on the disk drive using
Windows 10 for the moment, just in case you succeed in
decrypting it. Hxd works there.)
https://mh-nexus.de/en/hxd/
Select "Run as administrator" when running Hxd. This
gives permission for accessing the disk drive at
sector level. There is a menu item on the right, for
opening disk drives at the sector level.
I'm unaware of any Linux hex editor, worth using for this.
No, doing octal dumps is not a substitute :-/
If you're good at maths, you can work out the offset,
and use the Goto to go directly to the correct
address. If an NTFS file system is there, the very
first sector has binary looking stuff, but there
is a text string part way down "NTFS" to assure
you you're on the money.
If the first sector (by math) is scrambled and NTFS
is not present, then the other posters suggestion
of BitLocker is a good possibility.
The Windows 10 Bitlocker is slightly different
than the Windows 7 Bitlocker. The W7 one uses
the Elephant Diffuser, which in crypto, is a way
to put more entropy into smearing the data around.
The feds probably had too much trouble cracking that,
so the Windows 10 version has Elephant Diffuser removed.
Another thing, is that the Windows 10 version will
defer to hardware encryption if available. If the
drive supports full disk encryption, instead of using
Bitlocker, it uses the hardware feature instead.
Don't ask me what happens with the Bitlocker recovery
floppy in that situation, as hardware FDE does not
rely on key discs, but relies on a password
instead. I presume the password can be really really
long, and could be a Bitlocker inspired kind of
passphrase (salted/scrambled etc). The Bitlocker
disc/key might still be required in such a situation.
Even though the drive does the encrypting.
What I don't know, is whether hardware FDE supports
sector ranges. So only one partition can be
encrypted at a time. FDE implies the whole disk,
and that makes it "unmanageable" for Microsoft
(nothing to boot from). Microsoft could only use it,
if it supports sector ranges.
Paul

I am going to make a separate comment ,,,thanks

philo

2020-11-07 07:17:34 UTC

I now have the complete story.

The user had a problem and erroneously decided to take the repair option
the reinstall Windows.
After a few seconds she cancelled but I assume a quick format started.

She gave the drive to a friend who tried EASE-US.

It "saw" data but was not able to recover.

Rather than screw things up, I'm going to have her send it to a data
recover lab.

Thanks folks.

If anyone knows of a good lab, please advise.

Paul

2020-11-07 10:56:23 UTC

I now have the complete story.
The user had a problem and erroneously decided to take the repair option
the reinstall Windows.
After a few seconds she cancelled but I assume a quick format started.
She gave the drive to a friend who tried EASE-US.
It "saw" data but was not able to recover.
Rather than screw things up, I'm going to have her send it to a data
recover lab.
Thanks folks.
If anyone knows of a good lab, please advise.

Maybe she will get lucky, and the new $MFT won't have
written over top of the old $MFT. I'm trying to
sound positive here :-) Normally though, there isn't
a good reason for $MFT to move. It can fragment,
some defragmenter might attempt to move it, but
probably not do-able if the partition is mounted
at the time.

This is the output of nfi.exe . On this C: drive,
you can see the $MFT isn't down at the origin. This might
still be intact. Then the question would be, whether
the fragmentation makes this $MFT scavenge-able.

File 0
Master File Table ($Mft)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 6291456-6504447 (0x600000-0x633fff)
logical sectors 54384056-54619575 (0x33dd5b8-0x3416db7)
logical sectors 52664608-52700447 (0x3239920-0x324251f)
$BITMAP (nonresident)
logical sectors 7958912-7958975 (0x797180-0x7971bf)

Whereas this example, there weren't a lot of files in this
run, but it looks like it might have been a C: at one time.
This one is really close to the origin, and likely to be
totally destroyed on a quick format (new $MFT goes over top
of old $MFT).

File 0

Master File Table ($Mft)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32-86047 (0x20-0x1501f)
$BITMAP (nonresident)
logical sectors 16-23 (0x10-0x17)
logical sectors 409856-409863 (0x64100-0x64107)
logical sectors 9558456-9558463 (0x91d9b8-0x91d9bf)

The good news would be (if there is any good news),
the drive won't need to be opened up, and the
recovery effort is just "computer time". That should
cap the bill at the lower end of the billing scale.
Maybe $500 or something. No need for a clean room
in this case.

Paul

philo

2020-11-07 14:36:47 UTC