This project has moved and is read-only. For the latest updates, please go here.
1
Vote

WILL PAY FOR HELP WITH DECRYPTION - Can't decrypt due to bad block read on one m.2 sata of encrypted raid 0 Array

description

​Help wanted - WILL PAY DOR SOLUTION

Problem: Encrypted SYSTEM Raid 0 (2 SATA m.2 drives in RAID controller set to RAID 0) drive w VERACRYPT 1.13. Windows problem required decryption. Upon attempt to decrypt w/RESCUE disk and correct password , decryption begins and encounters bad block (on one of M.2 NGFF drives in RAID 0 Array, why/how=?) and program will not, due to read error, proceed further.
How do I handle this and/or perhaps skip or get around bad block to decrypt what's after it?
Re-image M.2 encrupted to blank? Skip bad block somehow and continue after (just need the data that I hope to recover off drive after decryption) if possible? ANy advice. Will make donation and or pay by rate for help.
Response Would BE Greatly Appreciated ::)).
Thanks,
-A

115 523627

comments

hierA wrote Jan 10 at 4:59 PM

If your header is still intact, there is a chance for rescuing parts of your data. Problem with encryption is, that any bad block in a file will make it go lost.
This doesn’t apply to the container file itself.

I assume you resumed the hibernated system without the hard drive being attached and used a non-journaling filesystem like FAT, which could not catch parts of the data loss.

In case, you want me to help, you should be willing to use a terminal prompt as well as creating and booting a Linux Live CD (SystemRescueCD to be specific). It would then be required, that you give me the output of some commands. You can use the sysresccd browser for that. To increase chances for restoring parts of the container, you would need hard disk space, that can store the entire raid content. Since this is just a partition, we probably don’t need a dd image for multiple partition table restore attempts.

To make long things short, the combination of cryptsetup and badblocks could help in your case, but it can’t be guaranteed, that anything can be restored, depending on the position of the bad blocks.

Best regards,
hierA

iencrypt4me2B wrote Jan 21 at 5:19 PM

Dear hierA,

I apologize I was away.

It is 1 fully encrypted system drive, NTFS, consisting of 2 x 256GB M.2 NGFF drives in RAID 0 Array.
Windows would not start. Had crash.

Attempted full decryption with rescue disk and shortly after process began it froze, and after hitting escape several times got decryption deferred message.

Upon further examination found drive was no longer revognized as single raid volume. One of the M.2 256gb cards had dropped out as member of array. Furtyher insvestigation showed bad block on it.

I got them to be recognized as a single array again on another raid controller, and have run some tests on raw encrypted drive, but cannot get it to decrypt.

Once it reads the bad block, decryption cannot proceed.

Can we force decryption around the bad block. I am only interested in the data in an encrypted container within this encrypted system drive.

I wanted to make sure that I properly explained situation. If you think you may still be able to help, please contact me and also we can make payment arrangements.

Sincerely

iencrypt4me2B

hierA wrote Jan 23 at 5:35 AM

I don’t care about the money. I just figured, that nobody would
answer to a support request, that does not describe an actual
issue of Veracrypt and was in a cooperative mood.

From your second post I would assume, that the data is lost. If
the raid controller does not detect the raid anymore, it means
that at least one hard drive had major data loss. In a RAID 0,
which is actually just an array of independent disks, you can’t
even restore small files from a stripe on the working drive,
because of the encrypted content. Combination of RAID 0 and
encryption is the best way to put your data in danger. Putting a
file container in it, increases the risk for the container data
even further.

Did you use the same stripe size for your newly detected array?
Otherwise you did create a completely new array. I assume in
contrary to fake (bios) raid, raid information is stored on the
controller, so nothing of the veracrypt header was
overwritten. But that depends on the other tests you did so far.

By the way: Before you are doing anything else, create a backup
of the header. I assumed from your usage of the rescue disk, that
you already did that. The rescue disk itself of course could also
have data loss and therefore have a broken header.

I would try both the newly created backup header and the one from
the rescue disc. I never used one, so you can check the Veracrypt
documentation for the location on disc.

So to make things clear: If you can detect the raid with the
other raid controller and the same stripe size, then you still
would have to learn, how to use a command line, since Veracrypt
can’t create a bad block list for you. It could just use one.

So you have at least to read some tutorials on basic command line
usage in Linux. After that you still would have to look up the
manual pages for cryptsetup, badblocks and mount, which I also
would consult in such a case.

So let me outline the process:

Create and boot a SystemRescueCD (www.sysresccd.org). The easiest
method for creation is unetbootin. Otherwise you can follow the
instructions on the sysresccd website.

SystemRescueCD wouldn’t be my choice for an easy to use Linux
distribution, but it contains all necessary command line recovery
tools, especially cryptsetup in a recent enough version for
decrypting veracrypt devices.
  1. Choose your keyboard layout.
  2. Type startx to get into a rudimentary desktop. You then have
    the browser Midori and a tabbed terminal emulator for better work
    flow.
  3. Sysrecscd should have detected your raid as /dev/md0
    blkid might display it, but I didn’t use it with raids
  4. Try to map the device with cryptsetup
    If that hangs for, say 30 seconds, that would be related to a
    Veracrypt bug, otherwise continue with 5.
    4.1 kill the process with killall -9 cryptsetup
    4.2 Try again with a differently named device map name
5 If it did work, you can try mounting the mapped device, but I
would expect it to break with the badblock error. Otherwise run
badblocks using the output file option and pass the file to mount
command
  1. If it works, try to continue from 4 with the file container.
As I said, you have to read a few tutorials. Using the command
line is not that hard, but especially on data recovery you are
not allowed to do mistakes.

Basically you do now have a guide on how to fix this, as long as
the raid is still accessible and the Veracrypt headers are not
damaged. I can’t give you a step-by-step solution, because I
don’t know the exact device nodes, which Linux will create for
the raid plus the only time I used badblocks before, the hard
drive had continued data loss, so it didn’t help me. Once
the check was through, there were new bad blocks, that needed to
be handled.

Note, that I assume, that for SSDs there is no ongoing data loss
in progress, once thir data has been damaged. This would happen with
HDDs and you would then create a full image of the raid device
and work with that for rescue purposes. Also note, that
encryption can wear down your SSD life, as long as you don’t
allow discards. I would assume, that VeraCrypt does that by
default due to the minor security implications.

Best regards,
hierA