after benchmark, encrypted partition is not visible

[alanford]

Hi,

my question is related to encrypted USB device with Kali.
I made upgrade and it was long process, 9 hours, even I used Internet at the University, 100Mb/S.

therefore, I wanted to do benchmark of USB. I chose menu for Disks (/dev/sdb3), there is an option select USB and to do benchmark (write/read) of some partition,

but now when I start/boot Kali from my USB, even if I select encrypted option, I don't get the option to type password, it means I can boot Kali only in normal mode, not in encrypted mode.

when I am logged in, I try to chose encrypted partition and this is what I get:
https://s29.postimg.org/clc4izrsn/sdb3.png
here are tried one more USB, /dev/sdc, but it is the same case, it is listed in terminal but not visible in GUI: https://s28.postimg.org/jkqf9a7vx/terminal.png

[alanford]

Okay, I see there are no experts for this type of problems.

I remembered also that I used dd command, not only GUI Disk Utility benchmark, some people wrote dd command on Internet as an advice to check read/write speed of USB devices, without to mention dd is also for destroying hdd/usb.
possibly dd command did overwriting of LUKS partition of Kali (/dev/sdb3). although I got the result of speed (read/write) when I used dd command, but now the only thing I can imagine: I am trying to use photorec to try to recover files from overwritten partition.
I tried yesterday to recover files in USB devices in windows photorec, no result, files are not recovered with windows photorec, now I am trying to recover files from kali luks partition with photorec in Kali. maybe I get some files recovered, although I am skeptic.

I tried also to edit /etc/fstab, but after reboot, it is not there. kali live problem.

here is dmesg and fsck:

dmesg

Kernel command line: BOOT_IMAGE=/live/vmlinuz boot=live persistent=cryptsetup persistence-encryption=luks noconfig=sudo username=root hostname=kali persistence initrd=/live/initrd.img
[ 28.037233] ISOFS: Unable to identify CD-ROM format.
[ 28.112389] FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[ 28.449557] FAT-fs (sdb2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 401.284050] ISOFS: Unable to identify CD-ROM format.

fsck /dev/sdb3

fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb3

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

sudo fsck.ext3 -v /dev/sdb3
the same result as above

sudo mke2fs -n /dev/sdb3

mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 3172088 4k blocks and 793072 inodes
Filesystem UUID: d8054569-7dc7-4123-8e76-160fccbe6cc9
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

sudo e2fsck -b 32768 /dev/sdb3

e2fsck 1.42.13 (17-May-2015)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb3

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

[alanford]

I think Kali tutorial "How to install Kali with encrypted partition", should include important notice: Backup the LUKS header.
This Luks header contain master key which is encrypted with user password, and if this header is damaged, master key can't be used to decrypt all files stored in kali encrypted partition, it means, user can't access his files anymore.

https://www.loganmarchione.com/2015/...he_LUKS_header

The LUKS header stores metadata about the LUKS device, as well as the master key, key files, etc.
the best practice is to backup the header as soon as you create the LUKS device. If you damage the header at all (accidental formatting, wrong device when using dd, bad block, etc…), you’ll need this backup header to recover the data. The header file itself needs encrypted and should be stored in safe place (not on the same drive, obviously).

sudo cryptsetup luksHeaderBackup --header-backup-file /path/to/file.img /dev/sdb3