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.