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 23:17:37 +0200
From: "Benjamin Oppermann" <>
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

Hello Alexander,
Thanks a lot for all the details! Do you think this could be the result of a ransomware attack? It's possible that the attackers were unable to contact my friend - or never did (or she didn't tell me about it).
Best regards,

Am Fr, 15. Jul 2022, um 22:30, schrieb Solar Designer:
> 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. 
>> > cannot open shared object file: No such file or directory 
>> > libcuda.dylib: cannot open shared object file: No such file or directory 
>> > /usr/lib64/ 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 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:
> 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.