[dm-crypt] Decrypting a drive; says a correct password is "incorrect"
1800ponysauce at gmail.com
Thu Jan 5 03:34:12 CET 2017
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
If you would like more information (the actual header, partition layout,
etc.), see this thread:
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt