From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 10 Jan 2017 16:44:00 +0100 (CET) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cQyaX-0001Us-OQ for dm-crypt@saout.de; Tue, 10 Jan 2017 16:43:53 +0100 From: Robert Nichols Date: Tue, 10 Jan 2017 09:43:46 -0600 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Subject: Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 01/10/2017 02:47 AM, 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? 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... > > 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 That would definitely make it worth sending the drive to a professional data recovery company and ask them to try to recover just those 16 missing sectors. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.