Decrypting a drive; says a correct password is "incorrect"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello everyone..

About 6 months ago one of my encrypted drives crashed during a brief data transfer I was doing. Because it was just a transfer, I did not have the keys backed up for this particular hard drive. I do not have another backup copy of the data contained in this drive. However it is extremely important to my livelihood. This listserv is really my last hope.

Using a platter switch, I was able to copy most of the data to a new hard disk. Fortunately, there does appear to be a valid version of a LUKS header still intact. However, the password I was using isn't working. It does use some special characters, but even the alternates for those characters on other locales aren't working. I guess I am first wondering if it is possible the LUKS header has changed somehow? If so, can I use the existing data on the drive to help me in a keysearch? Surely, some part of this header must be relevant to me, even if it is different? ... Is it definitely possible for it to have changed?  ... Or could it be something else, e.g. could a change in blocksize during the platter switch between hard drives have changed the key? The original hard drive originated from a ~2011 laptop running Ubuntu 14~. Most of my password guesses were from Ubuntu 16.

If you would like more information (the actual header, partition layout, etc.), see this thread:

https://ubuntuforums.org/showthread.php?t=2346612

I think the partition layout might be relevant, as there is only a 2 space between the EXT and Linux partitions.

At this point I am trying to gather as many ideas as possible. If there is something crazy you've thought of which could be possible, but have never seen yet, please suggest it and I will most likely try to investigate it. This data is extremely important for my livelihood.

Another thread:
http://askubuntu.com/questions/848429/why-cant-i-unlock-an-image-recovery-of-my-encrypted-disk-despite-using-the-cor

Even something as simple as being able to programatically change locales without having to log-in and out could help a lot. The update-locale command does not work without loging in and out... A script like that, or just something a little less brute-force than brute-force-luks (which I've tried), would be very useful.

Currently booting from an Ubuntu 14 live disk. hoping it could be a locale/OS-version problem since the password did use special characters and I may have changed the locale to Portuguese/Brazilian... although it's unlikely.

Thanks,
Steve
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux