VeraCrypt / Forums / Technical Topics: cant mount: ntfs signature is missing

Marc Lehnen - 2021-09-27

hello,

when i try to mount my vc-volume i enter my pw and after a few seconds the following message appears:

"ntfs signature is missing
failed to moun '/dev/mapper/veracrypt1': the argument is invalid
the device '/dev/mapper/veracrypt1' doenst seem to have a valid ntfs
mabye the wrong device is used? or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? or the other way around?"

a short story of my problem:

i accedently overwrote my system partition (linux mint 19) with the dd command. but after 1 second i realized my mistake and canceld. but my system was already broken. so i booted up a live linux mint. on this live system my unmounted vc-volume was shown within the file explorer and i accidently mounted it by clicking on it and it automatically opened the mounted partition (dont know why this worked). i unmounted it again but couldnt mount it via vc. it said wrong password or not a vc-drive.

now i am on a new linux mint installtion (20) and again vc said wrong password or not a vc-drive. then i wanted to restore the header but i accidently restored a wrong volume header. after that, i restored the right one. but now there is this error message.

what can i do?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2021-10-13

after restoring the header again (embedded as well as external header backup) there is a new error message (dunno why):

wrong fs type, bad option, bad superblock on /dev/mapper/veracrypt1, missing codepage or other error

what to do?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2021-10-18

so when i mount the partition without "mounting"/fs and then do a e2fsck, it sais:

Bad magic number in super-block while trying to open...
cant read superblock or invalid fs ext2/3/4

testdisk does not find any superblock as well

wrong offset?
how to check/fix?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

RealTehreal - 2021-10-18

Hey,

okay, let's start over from the beginning.

i accedently overwrote my system partition (linux mint 19) with the dd command. but after 1 second i realized my mistake and canceld. but my system was already broken.

If I get you right, you typed something like "# dd if={...} of=/dev/sda {...}" but cancelled the operation after a second.

so i booted up a live linux mint. on this live system my unmounted vc-volume was shown within the file explorer and i accidently mounted it by clicking on it and it automatically opened the mounted partition (dont know why this worked).

Now you said that you were able to simply mount your volume using a live Linux without using VeraCrypt? That's not unlikely unless it's not been a VC encrypted volume. So you seem to have mounted something else, or your volume was unencrypted. But anyway, have you copied over everything from the volume to another drive?

i unmounted it again but couldnt mount it via vc. it said wrong password or not a vc-drive.

I think the latter is correct, because otherwise you couldn't have mounted it via a file explorer without VC to begin with.

Now, to try to get anything done, please write down the exact layout of your HDD which contained your system partitions and your VC partition (or is it a container file??).

And I hope you created a backup of your raw VC volume before you did anything to the volume after the accident? Otherwise, it's quite possible to harm the volume further and further.

Greets

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2021-10-19

hi,

thank you for your answer.

If I get you right, you typed something like "# dd if={...} of=/dev/sda {...}" but cancelled the operation after a second.

thats right.

Now you said that you were able to simply mount your volume using a live Linux without using VeraCrypt?

yeah. i know it sounds very strange ^ and i was very astonished that it worked that way. i cant explain why. so maybe it was already decryptet or it was another volume but i was sure that it was my encryptet vc-drive. but there were no files

But anyway, have you copied over everything from the volume to another drive?

i made a disk dump of the whole drive cause after "accidently" mouting the drive in my live system no files were shown. i tried a few things with that image. the original drive is fully untouched (?). i only did some read operations via testdisk and mount tries.

what i did (among others), mainly with the image: https://www.cgsecurity.org/wiki/Recover_a_TrueCrypt_Volume#Recovery_under_Linux

i chose "none" as partition table

than i had to specify the fs-type (i chose ext4 but since yesterday i am not sure anymore that the fs is ext4. maybe its ntfs. because i have another vc-crypte drive that i encrypted at the same time so i think both fs are the same. when i analysed the other vc-drive, dumpe2fs ashowed me:

sudo dumpe2fs /tmp/.veracrypt_aux_mnt3/volume dumpe2fs 1.45.5 (07-Jan-2020) dumpe2fs: Ungültige magische Zahl im Superblock beim Versuch, /tmp/.veracrypt_aux_mnt3/volume zu öffnen Es kann kein gültiger Dateisystem-Superblock gefunden werden. /tmp/.veracrypt_aux_mnt3/volume hat ein ntfs-Dateisystem mit Namen „Serien“

so in english: invalid magic number in superblock
no valid fs-superblock...
volume has a ntfs-filesystem)

my steps so far with the dd-created image:

sudo losetup -o 1048576 /dev/loop0 /media/veracrypt1/filme.img

offset=512x2048

veracrypt -t --filesystem=none -k "" --pim=0 --protect-hidden=no /dev/loop0

when i use another offset at losetup, i cant mount because wrong pw, no vc volume....

sudo dumpe2fs /tmp/.veracrypt_aux_mnt2/volume dumpe2fs 1.45.5 (07-Jan-2020) dumpe2fs: Ungültige magische Zahl im Superblock beim Versuch, /tmp/.veracrypt_aux_mnt2/volume zu öffnen Es kann kein gültiger Dateisystem-Superblock gefunden werden.

so again: no valid superblock

i used some other block sizes (1024, 2048, 4096) but no superblock is found. well... if its ntfs, there are no superblock at all, right? =D

picture (td1): chose "none" as partition table

picture (td2): specified ext4 as fs-type

picture (td list files): list files

picture (td sb): searched for superblocks - found 0

i started photorec and it could find some files, mostly .swf-files. i did not do a full photrec recovery. after recovering some few files i stopped it cause the swf-files could not be opened. i also tried to rename them to .mkv because on the drive there are no swf-files

Now, to try to get anything done, please write down the exact layout of your HDD which contained your system partitions and your VC partition (or is it a container file??).

its a fully encryptet partition of 1 physical drive:

sdb 8:16 0 1,8T 0 disk └─sdb1 8:17 0 1,8T 0 part

sdb is the phsical drive, sdb1 the fully encrypted partition

sudo fdisk -l /dev/sdb Festplatte /dev/sdb: 1,84 TiB, 2000398934016 Bytes, 3907029168 Sektoren Festplattenmodell: SAMSUNG HD204UI Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: gpt Festplattenbezeichner: AC650828-9696-496C-8160-50FA72DA7616 Gerät Anfang Ende Sektoren Größe Typ /dev/sdb1 2048 3907028991 3907026944 1,8T Microsoft Basisdaten

so because i thought it could be ntfs, i booted up my windows system and mounted it via vc. it was successful but i could not open it. win said something like, volume must be formatted, cant open raw volume or so. and im not sure if "Festplattenbezeichnungstyp: gpt" is new after trying to mount it in windows.... photorec showed the following (see picture "photorec win")

except some analysing and mounting tries i did nothing to the volume. i hope it was not too much. the image should (also) be untouched. maybe more untouched than the original drive after mounting try in win :S)

regards

Last edit: Marc Lehnen 2021-10-19

td list files.jpg

td sb.jpg

td1.jpg

td2.jpg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

added the last picture (photorec win)
as you can see: no header can be found (but i stopped the search)
photorec in linux (i guess with "emulated" ext4 fs): 10/10 headers can be found

in testdisk again, i choose "none" as partition table and ntfs as filesystem:

Disk /tmp/.veracrypt_aux_mnt2/volume - 2000 GB / 1862 GiB - CHS 243185 255 63

     Partition                  Start        End    Size in sectors
>   P NTFS                     0   0  1 243184 211 35 3906764288

when i select the "boot" option:

Disk /tmp/.veracrypt_aux_mnt2/volume - 2000 GB / 1862 GiB - CHS 243185 255 63
     Partition                  Start        End    Size in sectors
   P NTFS                     0   0  1 243184 211 35 3906764288

Boot sector
Status: Bad

Backup boot sector
Status: Bad

Sectors are not identical.

A valid NTFS Boot sector must be present in order to access
any data; even if the partition is not bootable.

list:

P NTFS                     0   0  1 243184 211 35 3906764288

Can't open filesystem. Filesystem seems damaged.

Last edit: Marc Lehnen 2021-10-19

photorec win_.jpg

RealTehreal - 2021-11-17

Let's get some steps back. What exactly has been overwritten to begin with? You wrote that it was your system partition. But this means that it was not your VeraCrypt volume, as VeraCrypt does not support encryption of Linux root partitions? It would be essential to exactly know, what happened to which drive, what the original drive layout was and what's been the outcome after the accident.

Maybe have a look at this thread, too. It seems similar to your issue, where a drive got overwritten.
https://sourceforge.net/p/veracrypt/discussion/technical/thread/bed1d5d6c7/?limit=100#ce1a

Greets

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2021-12-08

What exactly has been overwritten to begin with? You wrote that it was your system partition. But this means that it was not your VeraCrypt volume, as VeraCrypt does not support encryption of Linux root partitions?

well, you are right. it was my unencryptet system partition which was accidentally overwritten. it hast nothing to do with my encryptet vc-partition in question. the overwriting is not relevant but its the reason why i started the linux live system in which i accidentally mounted the encrypted vc-partition by clicking on it in the file explorer (not in vc at this time)

It would be essential to exactly know, what happened to which drive, what the original drive layout was and what's been the outcome after the accident.

so what happened to my vc-partition in question:

the unmounted drive on which my encryptet partition is stored was listet in my file explorer under "Devices" (Geräte, like you can see on the screen01.jpg, red frame) i then (foolishly?) clicked on the device and it was mounted within the file explorer and the file explorer showed the content of the device (partition?) and it was empty as expected cause its encryptet and was not mounted in vc.

unfortunately i dont know how the layout of the encryptet device was before the accident (maybe the clicking/mounting did not harm anything but the wrong header restor did the harm). i think i created a partition within the device an encryptet the partition with vc. you can see the current unmounted layout in the 2nd pic (vc_layout.jpg, red frame is the drive with vc-partition). for comparison you can see a 2nd drive with an encryptet vc-partition (sdd2) which i created at the same time (blue frame) and maybe the layout of my 2nd drive (blue frame) is the same as it should be for my broken drive/partition? but may be they are different because of the different size etc.

Maybe have a look at this thread, too. It seems similar to your issue, where a drive got overwritten.
https://sourceforge.net/p/veracrypt/discussion/technical/thread/bed1d5d6c7/?limit=100#ce1a

ill do.

thank you

Last edit: Marc Lehnen 2021-12-08

screen01.jpg

vc_layout.jpg

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- RealTehreal - 2021-12-08
  
  the unmounted drive on which my encryptet partition is stored was listet in my file explorer under "Devices" (Geräte, like you can see on the screen01.jpg, red frame) i then (foolishly?) clicked on the device and it was mounted within the file explorer and the file explorer showed the content of the device (partition?) and it was empty as expected cause its encryptet and was not mounted in vc.
  
  Hm. I'm not quite sure about how Linux Mint handles raw volumes (that's what an encrypted VeraCrypt volume looks like to the overlying system). In Windows, it seems to be common that the OS asks the user to make the drive available, which would (at least) partially wipe the volume and format it with a filesystem.
  Maybe something similar happened, when you clicked the volume? Maybe it has been formatted with ext4 filesystem. This could be a reason why you got conflicting information about the filesystem to be ext4 and damaged NTFS after mounting it with the backup header. This would also be a reason for the drive being empty after mounting by simply clicking it.
  
  Just for testing reasons, I booted up Linux Mint 19 as a live system and tried to mount a non formatted (raw) partition — it did not work. So it seems that your sdb1 has been formatted before you tried to mount it in Linux Mint.
  
  Now, this is not easy to debug, because to me, it is still unclear what really happened to the volume — in case sdb1 was really encrypted using VeraCrypt at some point in time. When it is mountable without VC, it is very (very, very, very, …) unlikely to be a VC volume. If it was a VC volume and got formatted (and completely overwritten), it is unlikely to get much intact data back from it.
  
  If it only got partially overwritten, using a backup header to mount it without filesystem and trying data rescue is still the best approach, like you already tried. In this case, detailed knowledge of the original volume layout (size, volume position on the drive, original filesystem) are helpful.
  
  But just as mentioned, without clear knowledge of what happened to the volume, it's trial and error.
  
  for comparison you can see a 2nd drive with an encryptet vc-partition (sdd2) which i created at the same time (blue frame) and maybe the layout of my 2nd drive (blue frame) is the same as it should be for my broken drive/partition? but may be they are different because of the different size etc.
  
  The layout of sdd seems valid to me (maybe from GPT file table created in Windows). sdb probably uses MBR, so it looks fine.
  More about this: https://www.diskpart.com/articles/gpt-reserved-partition-128mb.html
  
  Please post the output of the following command. Maybe this still clears things up a little more.
  
  # lsblk -f
  
  Greets
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2021-12-09

Maybe something similar happened, when you clicked the volume?

that could be but i really dont know. maybe i can ask some linux/vc-pros.

So it seems that your sdb1 has been formatted before you tried to mount it in Linux Mint.

i cant remember doing something with the partition before the unintended mount in linux but... maybe...

in case sdb1 was really encrypted using VeraCrypt at some point in time

it should be or there is another missing partition which was encryptet like on the sdd device, and i wonder why sdd has 2 partitions while sdb only has 1.

the only write action on sdb (sdb1) was the wrong header restore i think. i did nothing else these 2 things (mount in linux (no writing?) and header restore)

If it only got partially overwritten, using a backup header to mount it without filesystem and trying data rescue is still the best approach, like you already tried. In this case, detailed knowledge of the original volume layout (size, volume position on the drive, original filesystem) are helpful.

But just as mentioned, without clear knowledge of what happened to the volume, it's trial and error.

yeah, its very tricky and i really cant remember how exactly the disk layout was. 2 long ago :( but i have time and i will try and try and try with the image so the original disk will remain untouched

Please post the output of the following command. Maybe this still clears things up a little more.
lsblk -f

lsblk -f NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sda ├─sda1 │ └─sda2 sdb ├─sdb1 │ vfat 6488-8A55 511M 0% /boot/efi ├─sdb2 │ └─sdb5 ext4 4248df7c-221b-41c2-8bb6-762d8e879082 385,3G 11% /run/times sdc └─sdc1 sdd ├─sdd1 │ ntfs System │ 3402F47602F43F04 ├─sdd2 │ │ └─truecrypt1 │ ntfs Mp3s, Apps, Uni │ FC4E044E4E04045C 140,3G 65% /media/tru ├─sdd3 │ ntfs Downloads, Bilder │ 404ED8964ED885D6 ├─sdd4 │ └─sdd5 ntfs Back-Up, Handy, Videos 465024385024315B

sda: the working "comparising" disk
sdc: the broken one

thank you very much so far. i really appreciate your help
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- RealTehreal - 2021-12-10
  
  The output looks kind of strange to me. Have you possible changed it somehow?
  
  For whatever reason, it seems that the mounted volume contains an ext4 file system. But when I get you right, it should be NTFS.
  
  What you could still try is to mount the VC volume as read only and with "do not mount" option. Then try again with photorec and let it search for NTFS:
  https://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step
  
  If you created an image of your affected drive, you could try to mount the image, mount the VC volume in it and try to recover the old file system with testdisk (or whatever tool you prefer). If that worked, try to read files directly with testdisk or try to undelete with photorec afterwards.
  
  In case, all these attempts fail, I'm currently out of ideas. Mostly because it remains unclear, what exactly happened to the volume, which makes it hard to find the best steps to take.
  
  Greets
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

The output looks kind of strange to me. Have you possible changed it somehow?

Sry, there was a display problem in my terminal.

NAME           FSTYPE LABEL                  UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                              
├─sda1                                                                                           
└─sda2                                                                                           
sdb                                                                                              
├─sdb1         vfat                          6488-8A55                               511M     0% /boot/efi
├─sdb2                                                                                           
└─sdb5         ext4                          4248df7c-221b-41c2-8bb6-762d8e879082  385,3G    11% /run/timeshift/backup
sdc                                                                                              
└─sdc1                                                                                           
sdd                                                                                              
├─sdd1         ntfs   System                 3402F47602F43F04                          2G    99% /media/XXXX/System
├─sdd2                                                                                           
│ └─truecrypt1 ntfs   Mp3s, Apps, Uni        FC4E044E4E04045C                      140,3G    65% /media/truecrypt1
├─sdd3         ntfs   Downloads, Bilder      404ED8964ED885D6                        7,2G    93% /media/XXXX/Downloads, Bilder
├─sdd4                                                                                           
└─sdd5         ntfs   Back-Up, Handy, Videos 465024385024315B

or take a look at the picture lsblk_f.jpg
sda: the working "comparising" disk (no vc-partition mounted)
sdc: the broken one

For whatever reason, it seems that the mounted volume contains an ext4 file system. But when I get you right, it should be NTFS.

i got several vc/tc-cryptet partitions but they are irrelevant. so i will post the output without the irrelevant devices:

NAME           FSTYPE LABEL                  UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                              
├─sda1                                                                                           
└─sda2                                                                                           

sdc                                                                                              
└─sdc1

or take a look at lsblk_f2.jpg

For whatever reason, it seems that the mounted volume contains an ext4 file system. But when I get you right, it should be NTFS.

so im not sure which fs it is :/ i thought it is ext4 but i think it could be ntfs instead...

What you could still try is to mount the VC volume as read only and with "do not mount" option. Then try again with photorec and let it search for NTFS:
https://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step

If you created an image of your affected drive, you could try to mount the image, mount the VC volume in it and try to recover the old file system with testdisk (or whatever tool you prefer). If that worked, try to read files directly with testdisk or try to undelete with photorec afterwards.

yes, i will do it again. i did it before but only for some minutes. i will let photorec search a bit longer for files with selecting ext4 and ntfs. i will post the search result here.

thank you

lsblk_f.jpg

lsblk_f2.jpg

Marc Lehnen - 2022-02-08

hi,

i tried some more. e.g. this (but not exactly):

https://www.cgsecurity.org/wiki/Recover_a_TrueCrypt_Volume#Recovery_under_Linux

i mounted the loop device in vc this way:

veracrypt -t --filesystem=none -m=ro,headerbak -k "" --pim=0 --protect-hidden=no /dev/loop0

with different offsets at loop setup (512x512/1024/2048/4096) and everytime the vc-password was accepted. without the mount options

-m=ro,headerbak

the password was accepted only with an loop offset of 512x2048

then i executed photorec on this device like

sudo photorec /tmp/.veracrypt_aux_mnt1/volume

and searched for files (ext & ntfs fs-"emulation") but there were only unreadable files like swf. grenier from testdisk/photorec sais that if mainly (unreadable) swf-files are recovered either the password is wrong or the loop offset is wrong. because i am convinced that the password is correct the offset must be wrong.

so now i have to try which offset is correct. but how to do it smartly?
maybe i have to buy the same hdd-model, then encrypt it with vc (ntfs and/or ext) and then find out the offset. but maybe someone here can do an educated guess or so? or maybe someone has the same hdd model and vc-setup and can tell me his offset. "hdparm" gives

Model=SAMSUNG HD204UI, FwRev=1AQ10001, SerialNo=XXXXXXXXXXXXXX Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=3907029168 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: unknown: ATA/ATAPI-0,1,2,3,4,5,6,7 * signifies the current active mode

fyi, "fdisk -l" gives

Festplatte /dev/sdc: 1,84 TiB, 2000398934016 Bytes, 3907029168 Sektoren Festplattenmodell: SAMSUNG HD204UI Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: gpt Festplattenbezeichner: AC650828-9696-496C-8160-50FA72DA7616 Gerät Anfang Ende Sektoren Größe Typ /dev/sdc1 2048 3907028991 3907026944 1,8T Microsoft Basisdaten

best regards

Last edit: Marc Lehnen 2022-02-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2022-02-08

++++ UPDATE ++++

i looked at my other vc-encryptet 4tb-partition and it starts at 512x264192=135266304 so i mounted the image of my other device with this offset (135266304) and started photorec and voilà there are readable files recovered! after a few minutes:

doc: 29 recovered jpg: 18 recovered txt: 11 recovered ifo: 4 recovered mpg: 3 recovered elf: 2 recovered exe: 1 recovered ico: 1 recovered riff: 1 recovered

i will let photorec do its job till the end and we will see if it can recover every file.

but there are vc/tc-containers on it. i read that photorec cant recover those files... maybe thats the next problem ^^ yay

so maybe i can recover the vc-partition with testdisk... gotta check it out

Last edit: Marc Lehnen 2022-02-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- RealTehreal - 2022-02-09
  
  Good to hear, that you were able to mount the volume and recovery is in progress.
  Would you be so kind to provide more details on how to set an offset when mounting the volume? I bet this would be of help for other users. Thank you in advance.
  
  Greets
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2022-02-10

yeah

i stopped the recovery with photorec cause of the eta. the hdd, on which the image is stored, was external and now it is connected directly to the mainboard via sata. i hope the recovery is faster now.

ok, so lets talk about the offset:

i created an image of the full hdd by using the dd-command in ubuntu. but the encryption was applied at a partition and not at the whole drive. therefor i used the offset-option of the loop device setup to mount just the encrypted partition:

sudo losetup -o 135266304 /dev/loop0 /media/veracrypt1/image.img

-o is the offset option of the loop device setup
135266304 is the offset in bytes. at this point the encrypted partition starts. at least i hope so ;)
/media/veracrypt1/image.img the whole drive image which will be handled as a "virtual" hdd/block device (loop device)
/dev/loop0 this will be the encrypted partition. as you can see it is like /dev/sdX so we can handle it as a "normal" bulk device. but keep in mind that this should only be a partition (if the offset is correct).

but i still have a few questions:

in photorec i chose both ntfs and ext as fs and there does not seem to be any difference in the recovery process. why? the same files are recovered.

most files are unreadable swf-files. why? maybe old deleted files? but swf-files will be recovered if the offset or password is wrong. im convinced the password is correct. so maybe the offset is still wrong? or "a bit" wrong? is this possible?

after doing the loop setup i restored the header. maybe this was wrong? but i think i did it with the real device/partition before creating an image

when trying to mount the loop device via vc command line without the headerbak option it says: wrong password or not a vc-volume -> wrong offset? why then recovery is partially successful?

best regards

Last edit: Marc Lehnen 2022-02-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- RealTehreal - 2022-02-12
  
  in photorec i chose both ntfs and ext as fs and there does not seem to be any difference in the recovery process. why? the same files are recovered.
  
  Maybe photorec assumes the wrong filesystem or sector size. I think the reason is related to the next question. Are the recovered files actually usable? Or does it just recover junk?
  
  most files are unreadable swf-files. why? maybe old deleted files? but swf-files will be recovered if the offset or password is wrong. im convinced the password is correct. so maybe the offset is still wrong? or "a bit" wrong? is this possible?
  
  In my experience, most data-recovery software thinks it finds swf files, when it actually doesn't find something useful. Perhaps it's something about file structure of actual swf files, I don't know. But mostly this happens when the filesystem got damaged or data-recovery software assumes the wrong filesystem type / sector size. At least that's what happened to me in the past.
  
  after doing the loop setup i restored the header. maybe this was wrong? but i think i did it with the real device/partition before creating an image
  
  I'm not sure if I understand what you mean. Where did you get the header backup from? Restoring a damaged header isn't wrong, as long as it's the header backup fitting the volume. Otherwise, the volume could still be mounted, but you won't be able to recover usable data.
  
  when trying to mount the loop device via vc command line without the headerbak option it says: wrong password or not a vc-volume -> wrong offset? why then recovery is partially successful?
  
  Every VeraCrypt volume has the main header at the beginning of the volume and a backup header at the volume's trail. When the main header gets damaged, the volume can still be mounted using the backup header. At least as long as it was not damaged as well.
  Have a look at VC's documentation about volume geometry.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2022-02-13

hello again,

Are the recovered files actually usable? Or does it just recover junk?

both. for example photorec (i stopped recovery after about 1 hour or so) could recover few video files which can be played (avi, mpg), pictures, txt, docs which can be viewed and some other files from which i dont know why these were recoverd (ifo, h, db...) i cant remember i had those file types on the hdd but so what. but of 102 recovered files 31 are unplayable swf-files.

But mostly this happens when the filesystem got damaged or data-recovery software assumes the wrong filesystem type / sector size.

yeah. td often says the fs is damaged. maybe after restoring a partition i could do chkdsk in windows to repair the fs. but of course i have to be sure that the partition is correct. or i can try it with the image. i always can do a disk dump again of the untouched hdd.

I'm not sure if I understand what you mean. Where did you get the header backup from? Restoring a damaged header isn't wrong, as long as it's the header backup fitting the volume. Otherwise, the volume could still be mounted, but you won't be able to recover usable data.

yeah sry. that was is bit confusing. before i did a disk dump, i restored the header from both internal and external header backup. i restored the header for the partition /dev/sdb1 as you can see in the following (sry for that it is german but i think i should be clear though):

Festplatte /dev/sdb: 1,84 TiB, 2000398934016 Bytes, 3907029168 Sektoren Festplattenmodell: SAMSUNG HD204UI Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: gpt Festplattenbezeichner: AC650828-9696-496C-8160-50FA72DA7616 Gerät Anfang Ende Sektoren Größe Typ /dev/sdb1 2048 3907028991 3907026944 1,8T Microsoft Basisdaten

so after the disk dump and setting up the dd-image as loop device with an offset of 512x2048 i restored the header again but this time for the loop device (/dev/loop0) which i thought would be the vc-partition (and for which i did a header restore before). i hope its clear now. so i wonder if the header restore did any harm to the disk, partition or whatever.

and i wonder what exactly the mount option "headerbak" does. the vc-help says:

headerbak: Use backup headers when mounting a volume.

in my understanding this command does not restore the header, right?

Every VeraCrypt volume has the main header at the beginning of the volume and a backup header at the volume's trail. When the main header gets damaged, the volume can still be mounted using the backup header. At least as long as it was not damaged as well.

ok. i also have an external header backup so the mounting shoud be no problem. i think the actual problem is to find the correct beginning (offset) of the partition. but when photorec is able to recover readable files does this mean that the loop offset (= the beginning of the partition) is correct?

Have a look at VC's documentation about volume geometry.

yes. i really should do it (and will). thank you very much so far for your help!

i did some more analysis with the offset 512x264192=135266304 at the loop setup. just for the clarity here is in short what i did:

sudo losetup -o 135266304 /dev/loop0 /media/veracrypt1/filme.img

veracrypt -t --filesystem=none -m=headerbak -k "" --pim=0 --protect-hidden=no /dev/loop0

sudo testdisk /tmp/.veracrypt_aux_mnt2/volume

i then let testdisk search for partitions. i chose "none" (or intel?) as partition table. this is the result:

TestDisk 7.1, Data Recovery Utility, July 2019 Christophe GRENIER <grenier@cgsecurity.org> https://www.cgsecurity.org Disk /tmp/.veracrypt_aux_mnt2/volume - 2000 GB / 1862 GiB - CHS 243185 255 63 The harddisk (2000 GB / 1862 GiB) seems too small! (< 7775764 TB / 7072016 TiB) Check the harddisk size: HD jumper settings, BIOS detection... The following partitions can't be recovered: Partition Start End Size in sectors > BeFS 30029 90 5 3275411016 118 54 11989385378129489 [M-+\r~PTM-91M- ^Y~RM-P~V9~SM-s%4~T~U~F$ M-B~GM-7] BeFS 43329 9 29 456752534 39 3 15187039947632989 [M-/j'nM-jt^A e1^Fg@Ƥ( SysV 4 188365 49 48 34647714 31 8 69552239050752 [ WM->M-= HFS 227634 229 51 396033 168 40 2705326082 [ Continue ] BeFS blocksize=512, 6138565 TB / 5582992 TiB BeFS blocksize=4, 7775764 TB / 7072016 TiB SysV4, 35610 TB / 32387 TiB HFS blocksize=268435456, 1385 GB / 1290 GiB

seems to be nonsense. and "The harddisk (2000 GB / 1862 GiB) seems too small!" is something to think about. for the first partition i got more details (just for curiosity maybe):

BeFS blocksize=512, 6138565 TB / 5582992 TiB: >P HFS 59236 36 2 227634 229 54 2705326082 P Sys=0C 72683 247 28 176622 155 42 1669774254 Structure: Ok. Keys T: change type, Enter: to continue HFS found using backup sector!, 1385 GB / 1290 GiB FATX, 854 GB / 796 GiB

the entry

FATX, 854 GB / 796 GiB

appears when chosing "Sys=0C". i just put it among each other. no additional value i think.

then i started testdisk again, chose "none" as partition table and got his:

Disk /tmp/.veracrypt_aux_mnt2/volume - 2000 GB / 1862 GiB - CHS 243185 255 63 Partition Start End Size in sectors > P Unknown 0 0 1 243184 211 35 3906764288

chose NTFS as fs-type, then "list" to list files:

Can't open filesystem. Filesystem seems damaged.`

went back and chose "boot":

Disk /tmp/.veracrypt_aux_mnt2/volume - 2000 GB / 1862 GiB - CHS 243185 255 63 Partition Start End Size in sectors P NTFS 0 0 1 243184 211 35 3906764288 Boot sector Status: Bad Backup boot sector Status: Bad Sectors are not identical. A valid NTFS Boot sector must be present in order to access any data; even if the partition is not bootable.

"rebuild BS". after searching:

Disk /tmp/.veracrypt_aux_mnt2/volume - 2000 GB / 1862 GiB - CHS 243185 255 63 Partition Start End Size in sectors P NTFS 0 0 1 243184 211 35 3906764288 filesystem size 3906764288 15194756643179683494 sectors_per_cluster 8 144 mft_lcn 786432 6980160655074043105 mftmirr_lcn 2 2501488079788471484 clusters_per_mft_record -10 103 clusters_per_index_record 1 42 Extrapolated boot sector and current boot sector are different.

but no files:

Directory / >dr-xr-xr-x 0 0 0 29-Jul-2021 15:03 . dr-xr-xr-x 0 0 0 29-Jul-2021 15:03 ..

so i think i have to learn a bit about hdd-geometry but maybe someone did it before and can help ;p

best regards

Last edit: Marc Lehnen 2022-02-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- RealTehreal - 2022-02-13
  
  so i wonder if the header restore did any harm to the disk, partition or whatever.
  
  Shouldn't do any harm, as only the data section of the main header gets rewritten.
  
  and i wonder what exactly the mount option "headerbak" does. the vc-help says:
  headerbak: Use backup headers when mounting a volume.
  in my understanding this command does not restore the header, right?
  
  That's right. This switch only tells VeraCrypt to use the backup header instead of the main header to decrypt ("open") the volume.
  
  i think the actual problem is to find the correct beginning (offset) of the partition. but when photorec is able to recover readable files does this mean that the loop offset (= the beginning of the partition) is correct?
  
  I'm not sure if there is still a possibility to get usable data off a partition with wrong offset. My assumption would be "no", so I think, the offset should be correct. But I could be mistaken.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2022-02-13

I'm not sure if there is still a possibility to get usable data off a partition with wrong offset. My assumption would be "no", so I think, the offset should be correct. But I could be mistaken.

ok. i will ask maybe some testdisk-pro or so to verify the offset is correct. and i will let photorec finish the recovery and check the recovered files.

then i will try to recover the partition to recover the tc/vc-containers. perhaps this needs some deeper research. or luck ;D

i will post the result here for interested users

thank you very much

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2023-01-27

so here i am again ;D

after a long pause i continued the recovery and i learned a bit about hdd layouts and examined the hdds with a hex editor. So thats the result (see picture).

my problem is to find the start and the end of the lost vc-partition. Im pretty sure the size is 2000263315968 bytes because i created a vc-testfile with wxhexeditor and this gives me the size of the „volume“ in testdisk and wxhexeditor. I only could „mount“ the testfile like this:

veracrypt -t --filesystem=none -m=nokernelcrypto -k "" --pim=0 --protect-hidden=no testfile.hc

the password was accepted but i cant recognize any pattern oder texts like „file“ so i dont know if the data was encrypted and/or if this is the correct header and/or the correct location. I remember that i restored a wrong header. Will the backup header be restored too? But after that i restored the correct one. So there must be the correct one, right? Ill do more test to clarify this.

Left in the picture my drive with the lost partition. Right is my good drive with another vc-partition. And because i created them at the same time maybe the layout should be the same?

Like this: https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html

So maybe one of these 2 solution is the right one:

start + size = end (in bytes)
1) 135396864 + 2000263315968 = 2000398712832 < - same ending like my other working vc-partition
2) 135266304 + 2000263315968 = 2000398582272 < - same start like my other working vc-partition

maybe some vc-pro can help me a little bit how to find start and end and how to check if this is correct and if the header is correct etc etc ;D

bye

ueberlick_interessante_positionen.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2023-01-30

EDIT i think i made a mistake in the calculation of the size of the vc volume in bytes. gotta correct this. maybe ignore my text for now ^^ EDIT

ok, so i did a bit more research and updated the currently partition layout (see pic). and i got a few questions that maybe can be answered by someone.

1) at byte 1048576 the current (wrong?) partition is starting. at its beginning there are 65536 bytes of encrypted data and i think this might be the restored header from my own external header backup because im pretty sure i restored it to this current partition. BUT: why only 65536 bytes? the header backup is 65536+65536=131072 bytes long. will the data only be encrypted if the complete header backup (131072 bytes long) is present although the last 65536 bytes in the backup is random data? I test-restored a backuped header to an empty vc-file and only the first 65536 bytes are restored. So does the decryption work even without the last 65536 bytes of the backuped header? Till now i could not confirm it. I should make some more tests.

When i go back another 65536 byte (1048576-65536) and make a testfile with 131072 bytes of the potential complete header backup the password is accepted as well. I cant explain that. Can you?

2) is vc only decrypting if the start of the partition is correct? Even if the header is correct (but at the wrong location)? I tried it with my other working vc-partition and it seems that the data is only decrypted if the last byte of the header and the first byte of the encrypted data are „direct neighbours“.

3) if the (main) header is restored to a partition, will the backup header be restored as well? If so, at which position? At the end of the current partition to which the main header is restored? Or does vc calculate the position where the backup header has to be restored from the data (e.g. size of the volume) which is stored in the (back uped) main header?

4) As mentioned above i mounted an image of the whole hdd with an offset of 135266304 bytes with the embedded backup header and photorec could restore readable data and when i examined the potentially decrypted partition i saw some decrypted data. But why? I did not specify a sizelimit at losetup. Did vc calculated the correct size from the data stored in the backuped header? Because the start of the potential partition (offset=135266304 bytes) is full of 00. so no header. Vc knows that the size of the vc-volume must be 2000263315968 bytes, right? So the end of the vc-volume is 135266304+2000263315968=2000398582272. but at 2000398582272 there are only 00. no backup header at 2000398582272-131072. so i really wonder how vc could get that embedded backup header!? I just tested it again and in a hexeditor i can see pattern like „tttttttttttttttttttttttttttttt“ and „0000000000000000000000“ so this is no encrypted data. Right? I even could see some plain text, a path to a file that makes sense.

But: at 135266304 of the whole physical drive there are only 00 but the potentially decrypted volume does not have these 00. thats another thing i dont understand. Do you?

ok well maybe someone can answer 1 or 2 or all questions ;P i will alter the offset at losetup while keeping the size constant so the end will alter too and see what happens.

bye

Last edit: Marc Lehnen 2023-01-30

ueberlick_interessante_positionen.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Marc Lehnen - 2023-02-01

SUCCESS!

so the offset 135266304 which i assumed at the beginning really was right ;D

DMDE could find many files incl. 3 vc/tc containers and i could recover them and open them and all files in them seem to be readable \o/ autopsy maybe can recover the containers too but i like the DMDE interface more. autopsy is a bit complicated.

thank this post which led me to DMDE.
https://sourceforge.net/p/veracrypt/discussion/general/thread/02be73c5ce/?limit=25#d149

so - again - this is what i did in short:

sudo losetup -o 135266304 --sizelimit 2000263577600 /dev/loop11 /media/veracrypt1/dd_image_of_whole_drive.img

( i dunno if sizelimit is really necessary resp. if it has to be the exact size in bytes because i tried it without sizelimit and with other sizelimits and some seems to work as well (havent applied dmde to other sizelimits))

veracrypt -t --filesystem=none -m=headerbak -k "" --pim=0 --protect-hidden=no /dev/loop11

start dmde and chose "/tmp/.veracrypt_aux_mnt2/volume" as source (disk images/logs). i think you can chose "/dev/dm-X" and "/dev/mapper/veracryptX" as well.

do a scan. open volume as ntfs (in dmde for recovery. not in your OS). there you can see your files.

thanks for everyone who helped me : )

so after recovering the most important files i will try to repair the corrupted FS resp. boot sectors etc

bye

Last edit: Marc Lehnen 2023-02-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

cant mount: ntfs signature is missing

Open source disk encryption with strong security for the Paranoid

Forums

Help

cant mount: ntfs signature is missing

cant mount: ntfs signature is missing

Open source disk encryption with strong security for the Paranoid

Forums

Help

cant mount: ntfs signature is missing document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

cant mount: ntfs signature is missing