저는 Win10 노트북을 사용하고 있으며 다음과 같은 문제가 있습니다.
폴더 > 속성 > 고급을 마우스 오른쪽 버튼으로 클릭하면 제공되는 내장 암호화 기능을 사용하여 모든 하위 폴더를 포함하는 폴더를 암호화했습니다.
일부 .cpp 파일이 포함된 이 폴더의 하위 폴더를 USB 드라이브(FAT32)로 옮겼고 거기에서 Linux HD(EXT3/EXT4)로 이동했지만 여전히 암호화되어 있다는 사실을 인식하지 못했습니다.
내 Linux PC에서는 해당 파일의 확장자가 .pfile이고 암호화되었기 때문에 해당 파일을 열 수 없었습니다. 그래서 다시 USB 드라이브로 옮겼고 거기에서 다시 노트북으로 옮겼습니다.
그러나 이제 노트북에서는 더 이상 열 수 없습니다. 속성의 해당 후크가 더 이상 설정되지 않았기 때문에 Win10은 자신이 여전히 암호화되어 있다는 사실조차 인식하지 못하는 것 같습니다.
Azure Information Protection-Viewer를 사용하여 설치했는데 파일 형식(.cpp)을 열 수 없다는 오류만 표시됩니다. (영어로 설치되어 있지 않기 때문에 영어로 된 정확한 오류 알림을 모릅니다.)
답변1
Microsoft는 FAT32 디렉터리 항목에서 이전에 사용되지 않은 필드를 사용하고 있으며 FAT32에 EFS 메타데이터를 저장하기 위해 길고 짧은 파일 이름이 있는 숨겨진 디렉터리 항목과 트릭을 사용하고 있는 것으로 보입니다.
암호화된 파일은 ".PFILE" 확장자를 가지며 8.3 디렉터리 항목은 추가 메타데이터를 저장합니다. 현재 구현에서 이 메타데이터는 6비트에 적합합니다. 2비트는 플래그로 사용되고 4비트는 패딩 크기를 저장하는 데 사용됩니다.
추가 메타데이터는 8.3 디렉터리 항목 내에서 12바이트 오프셋에 있는 NTByte 필드에 저장됩니다. 이전에 이 필드는 짧은 기본 이름이나 확장자를 소문자로 표시하는 두 개의 플래그(각각 비트 #3 및 #4)를 저장하는 데만 사용되었습니다.
이제 남은 비트도 사용됩니다. 비트 #0은 파일이 암호화될 때 설정됩니다(새로 생성된 파일을 기본적으로 암호화해야 하는 경우 디렉터리에도 설정됨). 비트 #1은 파일이 큰 EFS 헤더로 시작될 때 설정됩니다(그렇지 않으면 표준 EFS입니다). 머리글). 다른 비트(비트 #2, #5, #6 및 #7)는 패딩 크기(크기가 최대 15바이트이므로 4비트이면 충분함)를 저장하는 데 사용됩니다. 비트 #0(LSB)은 NTByte 필드의 비트 #2, 비트 #1 ~ 비트 #5, 비트 #2 ~ 비트 #6, 비트 #3 ~ 비트 #7.
(원천, 참조된 내용도 참조하세요.미국 특허 US10726147B2)
파일을 다른 곳으로 옮긴 다음 다시 넣으면 특수 메타데이터가 파괴됩니다. Linux는 이에 대해 모르기 때문입니다.
이런 말을 해서 안타깝지만 귀하의 파일은 복구할 수 없는 것이 거의 확실합니다. 그래도 숨겨진 메타데이터를 추측해 볼 수는 있습니다. 결국 가능한 값은 64개뿐입니다. 이렇게 하려면 원시 디스크 16진수 편집기나 사용자 정의 파일 시스템 드라이버가 필요합니다.
답변2
며칠간의 검색 끝에 해결책을 찾았습니다.
문제는 파일을 Linux에 복사하고 손상된 파일의 메타데이터를 다시 복사할 때 디스크 편집기를 사용하여 이 문제를 해결합니다. 동일한 크기의 파일을 만들고 암호화한 다음 FAT32 드라이브에 복사하고 파일의 메타데이터를 복사합니다. 삭제한 후 파괴된 ".PFILE"로 바꾸고 메타데이터를 교체합니다.
"Daniel B"님 감사합니다. 귀하의 답변이 큰 도움이 되었습니다.