Hi there,
I did not have the opportunity to read all of the discussion, but
thought I might add in some bits.
Am 05.11.2016 um 22:58 schrieb zero.tonin@xxxxxx:
Hi again, everybody,
and yet another sorry - it is indeed weird to work on an unknown system and I ask ye to please accept my apology for causing any inconvenience with html or TOFU posts. I am slowly getting my debian VM to a workable degree, so I hope less errors occur from now on!
I did another ddrescue today after formatting one of my drives, as Michael suggested the missing 100 or so GB wouldn't cause the "no key with this passphrase" issue.
In fact only the header is really relevant to cryptsetup. If the image
was truncated the filesystem might have been partially damaged (within
the image that is), but you'd at least be able to unlock() and see the
fs-signature if you captured enough sectors at the beginning of the LUKS
container.
Running the keyslotchecker from /misc results in the same as before (start: 0x001000, end: 0x03f800) , which, if I understood correctly, would indicate that the keyslot technically is still there and no bytes have been accidentally overwritten.
Exactly, the slot itself seems to be intact, as far as analysis can go.
The hexdump also still indicates the LUKS header where, as far as a layman like me can understand in this short period of time, it should be, with a hexdump resulting in
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
The drive is also (isLuks) recognized as a LUKS drive, still so - in theory- it al looks well and "I don't understand"
Well, if the key material was damaged, then even when your password is
correct, the hash value would not match and even worse, the retrieval of
the actual disk key would fail. There is no redundancy in the keyslot
that can compensate for bit-errors.
I tried adding a key to keyslot1, hoping that maybe this somehow would work with the original key in slot0, but, alas, no joy, the same, naturally, goes for attempting to luksChangekey, --dump-master-key or crptsetup-reencrypt
Adding a key needs the drive key, which would have to be restored from a
working slot. Well, it could be retrieved from mem, when the container
is open, but that does not apply in your case.
I was going through the options fro the man page and treid all those that looked somehow relevant to my situation, I thus created a luksDump, which resolves to this:
Key Slot 0: ENABLED
Iterations: 342245
Salt: 72 3c b6 82 b3 33 a7 f6 5a 55 f9 3d 6b f3 8c b8
d9 6a 66 31 9e 03 b1 57 b9 bf 00 5d d7 4a dd c9
Key material offset: 8
AF stripes: 4000
I see there is a folder /test in the cryptsetup folder, but I could not locate a readme or something like it for them - would there be anything relevant I could try?
Did you actaully try to luksDump on the original drive from some live
system? And maybe dump the first 8MB of the LUKS container, including
the header and see if the dump is stable?(i.e. do multiple dumps and
compare hashes or diff) If it changes then you are really having issues
with unstable read results and would have to have enormous luck to get
the correct data to unlock the slot.
I am also curios what my debian (or my HW, for that matter) could have done t the drive to render this state, as after the decrypt, when I realised the issue, I shut down the laptop immediately without "playing" with the LUKS. The only thing I could imagine would be some evil wizzard genius having somehow gotten luksErase into my cronjobs (which, of course would result in an empty keyslot 0, if I understand correctly...) or something like that. I suppose that's rather unlikely, though. Could the corrupt OS have ... changed the passphrase whilst the drive had been unlocked, without further user input?
Well of course a keyslot can be overriden purposefully, cryptsetup, when
unlocking the container, does however not write to the header area at
all. The results so far do not show signs of typical errors like
overwriting with fs-signatures or so. Since the header structure seems
to be okay, something would have had to overwrite some parts of the
actual keyslot area. There are a lot of possibilities how this could
happen if there's some defect.
I also see there is a "repair" mentioned in man, but I do not understand how to call this one (I have created a header backup in the meantime) or whether it would even make sense, as I am unsure what exactly is broken in the first place...
Sorry, never had any need for it so far, better wait for an answer from
someone else regarding this.
I also understand that the mailinglist is not a personal support tool, so again my gratitude for the comments and help I receive here!
Is there anything left to try with this drive or, at this stage, is "all lost" and I might as well wipe the drive, reinstall an OS and see (as it seems to be HW related) where I can safe up some money for a new machine?
Kind regards and thanks a mill,
Mark
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
Final words: You said, you are sure the PW is correct. Are you 100% sure
that the keyboard layout was correct and no character mapping issues are
involved? Double checked on the live env?
Regards
-Sven
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
