How best to crack wrapped-passphrase?

[Tom Vaughan]

I'm running Ubuntu 13.10 with an encrypted, private home directory. I
changed my password today via the Ubuntu control center. I either
don't remember the password, or the password utility used a password
other than the one I entered. I attempted to change my password a
second time, but all methods I tried required that I know my current
password. So I rebooted into recovery mode, re-mounted / in read-write
mode, ran passwd, and all was well, or so I thought.

Now it seems as though wrapped-passphrase is wrapped with whatever the
new password is (whatever password was used on my first attempt to
change it). Yes, I did save the encryption key, but that doesn't work
with ecrpytfs-recover-private. Perhaps I wrote it down incorrectly.
Yes, I should have verified it somehow. But I didn't. Also, there is
no copy of the new password in /etc/shadow-.

I don't care if it takes a long time, as I'm sure it will. What's the
best method for cracking wrapped-passphrase?

Thanks.

-Tom

[Artur Rataj]

Hi

I have no idea how to crack the passphrase, but just want to add, that
I once knew both the password and the passphrase, and still could not
decrypt the directory despite using two tutorials, until I have found
ecryptfs-recover-private by Dustin Kirkland. So perhaps you wrote down
the pasphrase correctly.

Unfortunately passphrase can not be disabled even if not needed in the
first place - I used ecryptfs to protect from deletion etc., and not
for encryption, a misuse that does not work anyway, as bad credentials
still allow to delete files, and even turned out to corrupt the
filesystem.

[Artur Rataj]

And if the passphrase is really mispelled, perhaps the best approach
is to "mutate" it. I would wrote some simple looping program that
would do some resonable insertions/deletions/replacements over the
original passphrase and would use the result to brute-force the
decryption. If there are some fixed time delays anywhere, removing
them and re-compiling some kernel module or tool would likely be
needed too.

[Tom Vaughan]

Post by Artur Rataj
And if the passphrase is really mispelled, perhaps the best approach
is to "mutate" it. I would wrote some simple looping program that
would do some resonable insertions/deletions/replacements over the
original passphrase and would use the result to brute-force the
decryption. If there are some fixed time delays anywhere, removing
them and re-compiling some kernel module or tool would likely be
needed too.

I'm in the process of doing this now. I wrote a script to try various
mutations of the password I think it should be. See below. This ran
over the weekend, nearly melted my laptop, and didn't unwrap the
passphrase. Each iteration takes maybe half a second. At this rate
it's not feasible to try a brute force for all possible character
permutations. My next step is to create an optimised compiled version
that does this, and run it on a cloud instance somewhere. I happen to
have another wrapped-passphrase for a different encrypted directory. I
know that passphrase, and I can unwrap it (in the script below too).
Right now my compiled version cannot unwrap the control
wrapped-passhrase.

Thanks.

-Tom


#!/bin/bash

WRAPPED_PASSPHRASE="/path/to/wrapped-passphrase"
test ! -f "${WRAPPED_PASSPHRASE}" && echo "${WRAPPED_PASSPHRASE}" does
not exist. && exit 1

function unwrap() {
echo "$@".
printf "%s" "$@" | ecryptfs-unwrap-passphrase
"${WRAPPED_PASSPHRASE}" - 2>/dev/null
test $? = 0 && exit 0
}

for x1 in some pattern 1; do
for x2 in some pattern 2; do
for x3 in some pattern 3; do
for x4 in some pattern 4; do
unwrap "${x1}${x2}${x3}${x4}"
done
done
done
done

exit 1

[Artur Rataj]

I guess a better "mutator" would be something more complex, taking
into account your personal habits of writing passwords, likely
misspellings like "O" vs "0" if you wrote the characters off the
screen, swapped pairs etc. If unsuccessful, the program would increase
the number of mutations (breadth first search).

Also, it might be worth checking if the 0.5 sec delay is not mostly a
loop for preventing attacks. System load might reveal an idle loop,
source analysis (profiling?) might reveal a busy loop.

Modifying the source of ecryptfs-unwrap-passphrase to directly include
your code might help too, as you would save on starting a process each
time.

[Tom Vaughan]

Post by Artur Rataj
I guess a better "mutator" would be something more complex, taking
into account your personal habits of writing passwords, likely
misspellings like "O" vs "0" if you wrote the characters off the
screen, swapped pairs etc. If unsuccessful, the program would increase
the number of mutations (breadth first search).

Yup. Did that.

Post by Artur Rataj
Also, it might be worth checking if the 0.5 sec delay is not mostly a
loop for preventing attacks. System load might reveal an idle loop,
source analysis (profiling?) might reveal a busy loop.

Yup. In the process of doing this now.

Post by Artur Rataj
Modifying the source of ecryptfs-unwrap-passphrase to directly include
your code might help too, as you would save on starting a process each
time.

Yup. This is what I started with. But a trivial update, like hard-code
the known passphrase for the control wrapped-passphrase, fails.