On 17/02/2021 21:14, Volker Dormeyer wrote: > Hi Milan, > > thank you for your explanation. See, my comments below. > > On 2/17/21 8:09 PM, Milan Broz wrote: > >> On 17/02/2021 19:12, Volker Dormeyer wrote: >>> Hi all, >>> >>> I have a question. I have a detached header for a drive I created years >>> ago, where I lost the password for. So, I plan to find the password with >>> a brute-force attack. For this I have to attached the header again. I >>> thought, this would result in problems - and it did. I build for testing >>> purposes the whole situation in a VM. It seems I have to align the data >>> offset somehow. >> Why do you want to attach it to device for brute-force check? >> Header should be enough to run it. > > Hashcat for example requires a bit more then simply the header. If you > are interrested, you can read it here: > > https://hashcat.net/forum/thread-6225.html > > I proof it, it does not work by feeding it with the header file alone. Ah, ok, if it uses known signature from the decrypted data disk to check for the correct key, then yes, you need data there. (And yes, it IS the correct way how to speed up brute-force, LUKS header key digest is intentionally slow to exactly not allow easy brute-force just with the header.) > >> You can use cryptsetup for it: >> >> cryptsetup luksHeaderRestore <data device> --header-backup-file <luks header> >> >> Or did I miss anything here? >> > It does work in my VM. I never thougth it would be that simple. That is > the base to start my real brute-force work. Why it should be more complicated than needed? :-) It is simple, unless you are using some non-standard parameters. (But even then it is quite easy to manually hack it.) Thanks, Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
