[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Jul 2022 23:17:37 +0200
From: "Benjamin Oppermann" <ben.opp@....cc>
To: 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
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,
Ben
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.
>> > 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.
