Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Jul 2022 22:30:34 +0200
From: Solar Designer <solar@...nwall.com>
To: Benjamin Oppermann <ben.opp@....cc>
Cc: john-users@...ts.openwall.com
Subject: Re: bitlocker-opencl: Error creating binary cache file: File or directory not found 0: OpenCL CL_INVALID_EVENT (-58) error in opencl_common.c:1827 - clWaitForEvents

Hi Benjamin,

Summary: you're out of luck.

Detail:

On Fri, Jul 15, 2022 at 08:10:09PM +0200, Benjamin Oppermann wrote:
> > john --format=bitlocker-opencl -mask=?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?
> > d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d[-]?d?d?d?d?d?d ~/bitl-recoverypw-
> > hash
> The hash starts with $bitlocker$3$

I've just added this sentence to the wiki page you referenced:

"Please note that the number of possible Recovery Passwords is way too
large, so there's effectively no chance that this will find yours unless
you recall almost all of it (except for just a handful of digits) and
replace most of the "?d" above with the known digits."

I think we also need to add it to README.BitLocker.

> I'm getting the following output:
> 
> > -------------------------------------------------------------------------- 
> > The library attempted to open the following supporting CUDA libraries, 
> > but each of them failed.  CUDA-aware support is disabled. 
> > libcuda.so.1: cannot open shared object file: No such file or directory 
> > libcuda.dylib: cannot open shared object file: No such file or directory 
> > /usr/lib64/libcuda.so.1: cannot open shared object file: No such file or directory 
> > /usr/lib64/libcuda.dylib: cannot open shared object file: No such file or directory 
> > If you are not interested in CUDA-aware support, then run with 
> > --mca opal_warn_on_missing_libcuda 0 to suppress this message.  If you are interested 
> > in CUDA-aware support, then try setting LD_LIBRARY_PATH to the location 
> > of libcuda.so.1 to get passed this issue. 
> > -------------------------------------------------------------------------- 
> > Device 1@...l-mnj: Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz 
> > Using default input encoding: UTF-8 
> > Loaded 1 password hash (BitLocker-opencl, BitLocker [SHA256 AES OpenCL]) 
> > Cost 1 (iteration count) is 1048576 for all loaded hashes 
> > Error creating binary cache file: File or directory not found 
> > 0: OpenCL CL_INVALID_EVENT (-58) error in opencl_common.c:1827 - clWaitForEvents
> 
> This is the first time I'm trying something like this.
> I have no dedicated GPU, and afaik CUDA is something to to with Nvidia GPUs, so I think the first portion doesn't apply to me.

Right.  You can ignore this.  It's probably a packaging issue by your
distro.  Also, the "error in opencl_common.c:1827 - clWaitForEvents" is
a bug we've since fixed - you're using an older version, as you mention
below.  This also doesn't matter given that you don't have a GPU anyway.

You can simply omit the "-opencl" - use "--format=bitlocker" - or even
omit the "--format" option altogether.

> 1. Can anyone give me some pointers for fixing the error?

You don't need to.  For others (who do have GPUs), perhaps the distro
could fix this, unless it's deliberate.

> 2. I don't know if this was encrypted by the TPM (the bitlocker2john output seems to suggest it makes a difference, gotta admit I don't understand Bitlocker very well). If so, can JtR decrypt it at all? I'm attaching the bitlocker2john output without the hashes in a text file. Let me know if posting the hashes as well could be useful.

It does look like you were using TPM.  In that case, the only thing JtR
can help with is test possible Recovery Keys.

> 3. What are my chances of getting a result in a reasonable time (if at all)?

If you wrote your Recovery Key down, but now are unsure about a few
digits, JtR can help.  Chances will depend on the specifics of what you
wrote down and recall, and how reliably.

If you don't have your Recovery Key at all, there's no chance.

> You can see the machine I'm running this on above. Surprisingly, the bitlocker2john retrieval of hashes was only a matter of a few hours, less than half a day. The drive is 512GB, dd'ing it to a usb drive also didn't take more than a couple hours.
> 
> Some context: I have the user password for this drive, but it's not helping me since the Windows 10 laptop that I dd'ed it from is unbootable (a friend gave it to me to fix, and apparently she had no idea the Windows drive was encrypted). I need the 48 digit Recovery Password to continue fixing the bootloader. When going to the Windows recovery command line, it asks for the Recovery Password.

My guess is the very reason the laptop is unbootable is the TPM won't
unseal the BitLocker key anymore.  Probably nothing wrong with the
bootloader, nor anything else, but the sealing just does not match the
current firmware + configuration + OS.

Maybe you still have a chance to revert whatever change caused this -
e.g., revert a configuration change or firmware upgrade that might have
been performed outside of Windows.

It is also possible that Windows attempted predictive resealing (I don't
know if it ever does that?) and got the prediction wrong, or that it
crashed before it could get the system and TPM state in sync again.  If
so, and if it updated the TPM already, reverting the change won't help.

Theoretically, your other chance is recovering the clear text key that
Windows (sometimes?) temporarily writes to disk during Windows and
firmware updates (when it does not do predictive resealing).  There's no
guarantee it's still there (probably not!), but it might be.  I am not
aware of anyone having ever done that, so it'd be a complicated research
project.  See here:

https://twitter.com/solardiz/status/1540767258045059072

In short, you'd need to know in what circumstances the laptop got into
this state where it needs recovery, then proceed accordingly (or more
likely give up).

Finally, you could attack the TPM in a number of complicated ways.  This
is probably further complicated by it being part of another chip, rather
than a separate chip.

If the data is worth millions, you could want to explore these various
possibilities, maybe even pay others to do it even expecting likely
failure.  Otherwise, it's not worth it.

Sorry I don't have better news for you.

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.