On Tue, Jan 10, 2017 at 09:47:30 CET, K Mmmm wrote: > Thanks for your help, Bob. I have run the keyslot checker, and there > appears to be damage. > > I read in many places that this means the data is simply > irrecoverable. But I don't understand how that could be so. Assuming I > know my password, couldn't I theoretically brute-force each of these > areas where entropy is low? Yes, you could in theory. In your case, this seems to be 8kB missing. Brute-forcing 8kB is infeasible in this universe, not enough matter, energy and remaining lifetime of the universe, regardles of whether it goes into heat-death or collapse. So in thery, yes, in practice no. > Is it because there are likely to be > other areas with low entropy that are not detected by the checker? > Would changing the sector size help? Or, is my understanding of hard > disks just so bare, that I fail to realize how difficult this would > be? If nobody answers, I'll assume it's hopeless, as based on the > following output, this is what my inclination is to believe. If > someone has a "wild idea" (the possibility of recovering the key from > RAM is long gone), then I am certainly willing to try it -- even if it > takes a decade or so to unlock. It's a crypto wallet with just enough > to pay off my first year of medical school loans... Sorry, if this is all you have, then there is no possibility to recover it. The key-slots are designed to make recovery even on slight damage infeasible, it is an anti-forensic measure. It works against you here. Regards, Arno > root@pony:/home/m/cryptsetup-master/misc/keyslot_checker# > ./chk_luks_keyslots /dev/sdb5 > > parameters (commandline and LUKS header): > sector size: 512 > threshold: 0.900000 > > - processing keyslot 0: start: 0x001000 end: 0x03f800 > low entropy at: 0x005000 entropy: 0.000000 > low entropy at: 0x005200 entropy: 0.000000 > low entropy at: 0x005400 entropy: 0.000000 > low entropy at: 0x005600 entropy: 0.000000 > low entropy at: 0x005800 entropy: 0.000000 > low entropy at: 0x005a00 entropy: 0.000000 > low entropy at: 0x005c00 entropy: 0.000000 > low entropy at: 0x005e00 entropy: 0.000000 > low entropy at: 0x038000 entropy: 0.000000 > low entropy at: 0x038200 entropy: 0.000000 > low entropy at: 0x038400 entropy: 0.000000 > low entropy at: 0x038600 entropy: 0.000000 > low entropy at: 0x038800 entropy: 0.000000 > low entropy at: 0x038a00 entropy: 0.000000 > low entropy at: 0x038c00 entropy: 0.000000 > low entropy at: 0x038e00 entropy: 0.000000 > - processing keyslot 1: keyslot not in use > - processing keyslot 2: keyslot not in use > - processing keyslot 3: keyslot not in use > - processing keyslot 4: keyslot not in use > - processing keyslot 5: keyslot not in use > - processing keyslot 6: keyslot not in use > - processing keyslot 7: keyslot not in use > > An example of one of these points with low entropy, using verbose output: > > low entropy at: 0x038600 entropy: 0.000000 > Binary dump: > 0x038600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038610 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038630 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038670 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038690 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0386a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0386b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0386c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0386d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0386e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0386f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038710 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038730 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038740 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038750 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038770 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038780 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x038790 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0387a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0387b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0387c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0387d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0387e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 0x0387f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > > > On Wed, Jan 4, 2017 at 9:34 PM, K Mmmm <1800ponysauce@xxxxxxxxx> wrote: > > Hello everyone.. > > > > About 6 months ago one of my encrypted drives crashed during a brief data > > transfer I was doing. Because it was just a transfer, I did not have the > > keys backed up for this particular hard drive. I do not have another backup > > copy of the data contained in this drive. However it is extremely important > > to my livelihood. This listserv is really my last hope. > > > > Using a platter switch, I was able to copy most of the data to a new hard > > disk. Fortunately, there does appear to be a valid version of a LUKS header > > still intact. However, the password I was using isn't working. It does use > > some special characters, but even the alternates for those characters on > > other locales aren't working. I guess I am first wondering if it is possible > > the LUKS header has changed somehow? If so, can I use the existing data on > > the drive to help me in a keysearch? Surely, some part of this header must > > be relevant to me, even if it is different? ... Is it definitely possible > > for it to have changed? ... Or could it be something else, e.g. could a > > change in blocksize during the platter switch between hard drives have > > changed the key? The original hard drive originated from a ~2011 laptop > > running Ubuntu 14~. Most of my password guesses were from Ubuntu 16. > > > > If you would like more information (the actual header, partition layout, > > etc.), see this thread: > > > > https://ubuntuforums.org/showthread.php?t=2346612 > > > > I think the partition layout might be relevant, as there is only a 2 space > > between the EXT and Linux partitions. > > > > At this point I am trying to gather as many ideas as possible. If there is > > something crazy you've thought of which could be possible, but have never > > seen yet, please suggest it and I will most likely try to investigate it. > > This data is extremely important for my livelihood. > > > > Another thread: > > http://askubuntu.com/questions/848429/why-cant-i-unlock-an-image-recovery-of-my-encrypted-disk-despite-using-the-cor > > > > Even something as simple as being able to programatically change locales > > without having to log-in and out could help a lot. The update-locale command > > does not work without loging in and out... A script like that, or just > > something a little less brute-force than brute-force-luks (which I've > > tried), would be very useful. > > > > Currently booting from an Ubuntu 14 live disk. hoping it could be a > > locale/OS-version problem since the password did use special characters and > > I may have changed the locale to Portuguese/Brazilian... although it's > > unlikely. > > > > Thanks, > > Steve > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
