У меня ноутбук с ОС Win10 и возникла следующая проблема:
Я зашифровал папку, включая все подпапки, с помощью встроенной функции шифрования, которая появляется, если щелкнуть правой кнопкой мыши по папке > Свойства > Дополнительно.
Я переместил подпапку этой папки, содержащую несколько файлов .cpp, на USB-накопитель (FAT32), а оттуда на жесткий диск Linux (EXT3/EXT4), не подозревая, что она все еще зашифрована.
На моем Linux PC я, очевидно, не мог открыть эти файлы, потому что они имели расширение .pfile и были зашифрованы. Поэтому я переместил их обратно на USB-накопитель, а оттуда снова на ноутбук.
Однако теперь на ноутбуке я тоже не могу их открыть. Похоже, что Win10 даже не понимает, что они все еще зашифрованы, потому что этот хук в свойствах больше не установлен.
Я выполнил установку с помощью Azure Information Protection-Viewer, но получаю только сообщение об ошибке, что не удается открыть файл filetype(.cpp). (Не знаю точного уведомления об ошибке на английском языке, поскольку у меня не английская версия)
решение1
Похоже, Microsoft использует ранее неиспользуемые поля в записях каталога FAT32, а также, возможно, скрытые записи каталога и трюки с длинными и короткими именами файлов для хранения метаданных EFS в FAT32:
Зашифрованные файлы имеют расширение «.PFILE», а их записи каталога 8.3 хранят дополнительные метаданные. В текущей реализации эти метаданные занимают 6 бит: два бита используются как флаги, а четыре бита используются для хранения размера заполнения.
Дополнительные метаданные хранятся в поле NTByte, которое находится по смещению 12 байт в записи каталога 8.3. Ранее это поле использовалось только для хранения двух флагов, помечающих краткое базовое имя или расширение как строчные буквы (биты № 3 и № 4 соответственно).
Теперь используются и оставшиеся биты. Бит № 0 устанавливается, когда файл зашифрован (он также устанавливается для каталога, когда его вновь созданные файлы должны быть зашифрованы по умолчанию), бит № 1 устанавливается, когда файл начинается с большого заголовка EFS (в противном случае это стандартный заголовок EFS). Другие биты (биты № 2, № 5, № 6 и № 7) используются для хранения размера заполнения (который составляет не более 15 байт, поэтому достаточно 4 бит) – его бит № 0 (LSB) переходит в бит № 2 поля NTByte, бит № 1 – в бит № 5, бит № 2 – в бит № 6, бит № 3 – в бит № 7.
(Источник, см. также указанныйПатент США US10726147B2)
Переместив файлы, а затем вернув их обратно, вы уничтожили специальные метаданные, поскольку Linux о них не знает.
Мне жаль это говорить, но ваши файлы почти наверняка не подлежат восстановлению. Тем не менее, вы можете попытаться угадать скрытые метаданные, в конце концов, существует всего 64 возможных значения. Для этого, однако, потребуется шестнадцатеричный редактор raw disk или пользовательский драйвер файловой системы.
решение2
После нескольких дней поисков я нашел решение,
Проблема в том, что когда вы копируете файлы в Linux и копируете их обратно, метаданные для файлов уничтожаются. Я решаю эту проблему с помощью Disk Editor. Я создаю файл того же размера, шифрую его и копирую на диск FAT32, копирую метаданные для файла, после этого удаляю его и заменяю уничтоженным «.PFILE» и заменяю метаданные.
Спасибо, "Daniel B", ваш ответ мне очень помог.