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