-1

EDIT3- SOLVED: I eventually changed partition to gpt, having found the header start hexadec value via test disk when selecting GPT as partition table. The hexdump had been spitting out two header position values that were different from testdisk's, which increasingly confused me. However, I did some math and determined that testdisk's location was correct based on total size in MB. After converting to GPT, I just added partition with start as the hex value testdisk IDed, and end as the last value of the original drive, and type as linux filesys data, linux LUKS. rebooted, was able to mount, and--done!! used testdisk again on the mounted partition to copy files to a /home folder on distro being used and we're all good! :)))

--

I had a flash drive with a linux FS partition and a persistent LUKS-encrypted partition (2nd partition), both of which were deleted by Etcher (in Win10) last night somehow, when having the drive mounted, while having two flash attempts of another drive fail (they both, I found out today, had been successfully flashed with the same image..). This partition is of value to me. I was fairly certain the unwanted flashed partitions (FS+boot) only overwrote most of the original FS partition (which was 1st partition), which was larger that the flashed ones' combined sizes. This, I think at least, is confirmed by having located the LUKS header with hexdump (see a bit below).

I used dd to make a byte-for-byte backup of the drive before proceeding with the following guide: https://nagimov.me/post/simple-recovery-of-luks-encrypted-partitions/. I located the LUKS header ("4c 55 4b 53 ba be" - the rightside output of hexdump table has LUKS...SKUL so it seems to be LUKS_MAGIC2). I then per the guide used command:

sudo losetup -o 0xf500000 -r -f /dev/sdd

with correct hexadecimal value. I then attempt to open the newly-mapped loop device with cryptsetup:

sudo cryptsetup luksOpen /dev/loop1 recovery

which gives me this output:

Unsupported LUKS version 83.

Device /dev/loop1 is not a valid LUKS device.

or when I try doing commands like e.g. luksHeaderBackup I just get the first line re unsupported version.

I have not deleted the unwanted partitions. Output of fdisk -l:

Disk model: datAshur PRO2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdd1  *         64 4684563 4684500  2.2G  0 Empty
/dev/sdd2       4684564 4692755    8192    4M ef EFI (FAT-12/16/32)

I'm not sure why dev/sdd1 is Empty when it's a live arch linux-based distro that I was able to boot into before I started troubleshooting.

Last thing to note is that the original partition table was GPT, whereas the current is DOS.

I found this post: How to recover LUKS encrypted hard drive? which may be applicable, but I wanted to see with you lovely readers first while I continue researching (also bc I'm not sure how to apply the answer in that post to my situation :<)

Edit: this post seems more relevant: https://askubuntu.com/questions/1131409/how-ro-recover-lost-luks-partition-on-external-harddisk. The answerer, in contrast to nagimov's guide, specifies the step of finding end of partition--they wrote a script to locate that and header, to be used in [s]fdisk, which I'm not familiar w/ using it for (edit2: this* purpose*)... don't know how the OP went for dev/sdg to /sdh i.e. does this need to be on the original drive and would that entail it being recommendable to delete the unwanted, flashed partitions? Then in other news, I created an image.dd file w/ testdisk of the loop device as testdisk seems to have recognized it as a LUKS partition (I've got my backup so might as well). Doing deep search of that .dd file is returning partition can't be recovered... still seeing if testdisk can help Edit 2 Above-noted .dd image in testdisk wasn't useful as nothing much doing without a partition table--which I think is crux of my issue. A deep search of the disk with testdisk when gpt is selected finds

New contributor
sudoplex is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
1
  • 1
    You should not edit your question to tell it's solved. You should make your own answer to your own question and mark it later as the accepted answer. What matters is to separate question and answer. Alternately since nobody else appears to have put energy to solve it, you can simply delete it. As it is, this question will reappear as a question-to-be-solved when it doesn't need anymore.
    – A.B
    May 15 at 7:07

0

Your Answer

sudoplex is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.