Восстановление зашифрованного LVM поверх RAID, но заголовок LUKS смещен на 2 МБ.

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

Я пытаюсь восстановить мои данные из конфигурации, которой 8 лет. 8 лет назад я последний раз пытался подключить эту конфигурацию, но компьютер сломался. Конфигурация такова:

LUKS шифрование поверх
Группа томов поверх
RAID10 (4 диска) + RAID1 (2 диска)

Linux нашел RAID и восстановил их. Он также нашел группу томов и собрал ее, назвав “blob”, как она и называлась.

Единственная проблема в том, что когда я попытался выполнить luksOpen, он сообщил, что заголовок отсутствует на /dev/mapper/vg-blob. Действительно, hexdump показал, что первые байты на диске были просто нулями. Поэтому я начал искать заголовок LUKS и нашел его.

# strings -t d -n 4 /dev/mapper/vg-blob | grep LUKS
2097152 LUKS

2097152 байт, что, по моим расчетам (2097152 / 1024 / 1024), составляет ровно 2MB. Каковы шансы?

Итак, я использовал losetup -o 2097152 /dev/loop0 /dev/mapper/vg-blob и создал дамп LUKS с /dev/loop. LUKS сообщил, что заголовок действителен! Но как?

Попробовал пароли, которые я ожидал, но нет.

Я на странном перепутье.

Может ли быть группа томов не является правильной, вызывая странный сдвиг на 2MB (Им 8 лет. Форматы тогда были другими?). Следовательно, это та точка атаки, которую нужно исправить?
Может, я просто забыл пароль, и все в порядке, несмотря на сдвиг в 2MB в заголовке LUKS? Может, мне просто нужно вспомнить прошлые события, чтобы вспомнить?

Замечательно, что я могу видеть свой .bash_history с мертвого компьютера. Я всегда открывал его с помощью cryptsetup luksOpen /dev/mapper/vg-blob crypt-blob.

Так или иначе мои данные кажутся висящими на волоске.

Правки:
luksDump

# cryptsetup luksDump /dev/loop0 
LUKS header information for /dev/loop0

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      1e 75 ff 04 c6 0a a8 9b c5 cd 7e d3 a2 ea 1c 8f cd 8f 17 0a 
MK salt:        c5 eb 06 2a e6 50 ce 30 36 83 3e 4b 89 2c fe 94 
                9e ad d6 1f ad 77 f4 f5 d2 96 89 a2 1e 52 a7 fa 
MK iterations:  43125
UUID:           bfb21fd9-67cc-4c41-bdd1-af38af7d4355

Key Slot 0: ENABLED
        Iterations:             172042
        Salt:                   a7 61 b1 00 12 59 42 80 5d 62 89 9d 52 db e0 47 
                                a3 39 11 1f bf 06 02 34 46 3e 47 2d 26 db 21 f7 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Ответ или решение

Восстановление зашифрованного тома LVM поверх RAID сдвигом заголовка LUKS на 2 МБ представляет собой интересную задачу, особенно учитывая, что конфигурация не использовалась в течение восьми лет. Давайте разберем ситуацию детально с учетом представленной информации.

Теория

Рассмотрим, в чем заключается проблема и каковы теоретические подходы к ее решению.

LUKS и его роль: LUKS (Linux Unified Key Setup) является стандартом для обеспечения шифрования на уровне блоков в Linux. Он создает зашифрованный контейнер, который требует аутентификации для доступа к данным. LUKS заголовки обычно содержат информацию о шифровании, такую как имя шифра, режим, хэш и другую критически важную информацию, необходимую для расшифровки данных.
LVM на RAID: Ваша конфигурация включает LVM (Logical Volume Manager), работающий поверх RAID массивов (RAID10 и RAID1). LVM предоставляет гибкость в управлении хранением, объединяя несколько физических дисков в один логический том. RAID (Redundant Array of Independent Disks) обеспечивает надежность и производительность путем распределения или репликации данных на нескольких физических дисках.
Сдвиг заголовка LUKS: Ваша находка указывает на то, что LUKS заголовки начинаются на 2 МБ после начала устройства. Это необычно, и, возможно, это связано с особенностями старой конфигурации, смещением данных или ошибками в первоначальной установке.

Пример

Ваша текущая ситуация выглядит следующим образом:

Система смогла восстановить RAID массивы и собрать томовую группу LVM под именем "blob".
Обнаружено, что заголовок LUKS начинается с позиции 2097152 байт (или 2 МБ).
Не удается открыть LUKS контейнер с предполагаемым паролем.

Применение

С учетом вышеизложенного, я предлагаю следующие шаги для решения проблемы:

Проверка корректности LVM: Убедитесь, что томовая группа LVM "blob" правильно собрана. Возможно, конфигурации LVM изменялись за последние 8 лет; проверьте, все ли физические тома и логические тома находятся на своих местах. Используйте команды vgdisplay, lvdisplay и pvdisplay для получения информации о структуре.
Проверка и восстановление LUKS заголовка: Так как заголовок LUKS смещен на 2 МБ, использование команды losetup с параметром -o 2097152 является правильным шагом для создания луп устройства с правильным смещением. Однако, если предполагаемые пароли не работают, возможно, стоит рассмотреть опцию восстановления заголовка, используя резервную копию, если она имеется.
Использование криптографических атак: Если все пароли истощены, возможно использование криптоанализа для восстановления ключей, хотя это может занять значительное время и не гарантирует успеха.
Исследование и восстановление паролей: Пересмотрите ваши старые записи, .bash_history и любые другие документы, в поисках пароля. Вспоминайте события или ситуации, которые могли подтолкнуть вас к выбору конкретного пароля. Иногда, восстановление пароля может быть наиболее простой стратегией.
Консультация с экспертами по шифрованию: Если эти действия не дают результатов, вы можете обратиться к экспертам в области шифрования данных, которые могли бы провести более детальное и профессиональное расследование.

Контекст и конфигурация вашей системы уникальны, и точная причина проблемы может быть скрыта в особенностях изначальной установки или специфики работы устаревшего программного обеспечения. Аккуратные шаги и внимание к деталям помогут вам вернуть доступ к данным.