☰

수동 NTFS 복구 온전성 검사

tag-icon • tag-icon ntfs hard-drive-recovery file-recovery
수동 NTFS 복구 온전성 검사

지금까지의 수동 NTFS 복구 프로세스가 난관에 부딪혔기 때문에 제대로 확인해줄 사람이 필요합니다.

배경:

  • 저는 대부분 사진이 들어 있는 1TB NTFS 외장 드라이브(WD Elements)를 가지고 있었습니다.
  • 어쨌든 손상되어 Windows에서 원시 디스크로 나타납니다.
  • 이는 Linux 시스템의 /dev/disk/by-path(및 by-id등 by-uuid) 디렉토리에 나타나며 로 나타납니다 /dev/sdb.
  • EaseUS는 빠른 스캔(무거운 딥 스캔이 아님)을 통해 거기에 있는 모든 사진을 (거의?) 찾을 수 있습니다.
  • EaseUS는 약 70GB의 파일(주로 사진)을 찾습니다.
  • NTFS 레코드가 손상된 것 같습니다. 즉, 기계적 고장이 아닙니다.
  • 재미와 이익을 위해 스스로 회복을 시도해보고 싶습니다.
  • 손상된 드라이브의 전체 이미지를 만들 수 있을 만큼 큰 다른 드라이브가 없습니다.

다음과 같은 이유로 NTFS MFT $File 레코드를 구문 분석해야 합니다.

  • 원래 파일 이름과 디렉터리 구조를 다시 가져오고 싶습니다.
  • 이미지가 인접한 클러스터에 기록되지 않은 경우 이미지 파일 서명을 찾는 것만으로는 이미지를 성공적으로 복구할 수 없습니다.

계획은 다음과 같습니다:

  1. 손상된 디스크의 일부를 이미지화합니다.
  2. MFT $File 레코드를 식별하고 읽으려면 이를 구문 분석하세요.
  3. $File 레코드(특히 $Data 속성)를 사용하여 각 파일의 데이터 실행을 결정합니다.
  4. 파일에 대한 데이터 실행을 알면 ddrescue.
  5. 완료될 때까지 헹구고 반복하세요.

첫째, 그게 합리적인 계획처럼 들리나요?

내가 한 것:

  1. $File 레코드를 많이 찾았습니다
  2. 데이터 실행을 위해 하나를 구문 분석했습니다.
  3. 데이터 실행으로 지정된 위치에서 원시 바이트를 읽습니다.

구체적으로:

  1. ddrescue손상된 디스크의 100GB(0부터 시작)를 이미지화하는 데 사용됩니다 .
    1. 관심 있는 데이터의 총 용량이 70GB이기 때문에 필요한 실제 데이터는 거의 모두 처음 100GB 내에 기록된다고 생각합니다. 필요한 경우 후속 100GB 부분에 걸쳐 이 전체 프로세스를 반복할 수 있습니다.
    2. 처음 100GB를 이미지화하는 데 사용한 명령은 ddrescue /dev/sdb ~/mydisk.img ~/mydisk.map --size=100G.
    3. ddrescueI/O 오류가 발생했으며 약 99.57%만 복구되었다고 보고했습니다.
    4. 이미지의 시작 부분(처음 20MB 정도)이 비어 있는 것처럼 보이므로 이것이 드라이브 오류의 원인일 수 있습니다. 나는 지금은 그것을 무시하고 있습니다.
  2. 100GB 이미지를 읽고 MFT에서 $File 레코드의 시작을 나타내는 ASCII 문자열 "FILE"의 모든 인스턴스를 찾았습니다.
    1. 이는 임의 파일 중간에 "PROFILE"이라는 단어와 같은 오탐(false positive)이 발생하는 경우에도 발생했습니다.
    2. 따라서 나는 "FILE"의 한 발생과 다음 발생 사이의 거리가 최대 MFT 레코드 크기이기 때문에 <= 1024바이트인 결과만 고려하고 있습니다. 한 번의 "FILE" 발생과 다음 발생 사이에 3MB가 있으면 $File 레코드가 아닐 가능성이 높습니다.
  3. 추정된 $File 레코드(크기 <= 1024바이트) 및 추출된 $Data 속성을 반복합니다.
  4. 데이터 실행을 위해 구문 분석했습니다(내가 이해한다고 생각하지만 내 질문의 일부가 아닌 상주 속성과 비거주 속성에 대한 논의를 무시함).

그래서 위의 과정을 거쳐 $File 레코드 중 하나를 선택하고 해당 데이터 실행을 확인했습니다. $Data 속성(헤더 및 내용)은 다음과 같습니다.

80 00 00 00 48 00 00 00  01 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00  FA 03 00 00 00 00 00 00
40 00 00 00 00 00 00 00  00 B0 3F 00 00 00 00 00
F4 AC 3F 00 00 00 00 00  F4 AC 3F 00 00 00 00 00
32 FB 03 ED C8 11 00 00  FF FF FF FF 82 79 47 11

FF FF FF FF데이터 실행 세부 정보는 속성 표시가 끝나기 직전인 마지막 행의 전반부입니다 .

  • 길이 바이트:32
  • 클러스터 실행 수: FB 03(리틀 엔디안) = 실행 중인 클러스터 1019개
  • 클러스터 시작 번호: ED C8 11= 1165549는 실행의 첫 번째 클러스터입니다.
  • 다음은 00더 이상 실행이 없음을 나타냅니다.

이제 섹터당 512바이트, 클러스터당 128바이트가 있다는 점을 고려하여 (1165549 * 128 * 512)에서 시작하는 100GB 이미지에서 (1019 * 128 * 512)바이트를 읽었습니다.

불행히도 결국에는 일부 데이터가 있었지만 대부분 0x00의 66.8MB 파일이 남았습니다. 나는 뭔가 문제가 있다고 확신하며 우연히 일부 데이터를 발견했습니다. (물론 JPG 파일 끝 표시(DD F9)로 끝나긴 했지만요.)

이 전체 작업에 대한 내 접근 방식이 합리적입니까? 어딘가에 작은 오류가 있었습니까?

아니면 내가 NTFS에 대한 근본적인 것을 오해한 걸까요? 이것은 완전히 잘못된 생각인가요?

답변1

첫째, 그게 합리적인 계획처럼 들리나요?

아니요. 디코딩 실행 방법을 자세히 살펴보지 않았지만 시작 클러스터는 파일 시스템 시작(NTFS에 대해 말할 때 볼륨/파티션 시작)을 기준으로 합니다. 따라서 클러스터 번호를 가리키는 모든 MFT 항목은 볼륨의 임의의 100MB 부분이 아닌 파티션 시작을 기준으로 클러스터 번호를 가리킵니다.

또한 MFT는 '자체 참조'이므로 가장 먼저 시도해야 할 것은 파생할 수 있는 MFT의 시작을 찾는 것입니다.모두MFT 항목. MFT의 시작을 찾을 수 없는 경우 대신 MFT의 미러를 찾아보세요.

따라서 MFT 항목을 적절하게 디코딩하고 참조하는 데이터를 얻으려면 다음이 필요합니다.

  • 파티션 시작 오프셋입니다.
  • 올바른 클러스터 크기

따라서 시작 클러스터를 디코딩하면 다음을 수행할 수 있습니다. (클러스터 번호 * 섹터 / 클러스터) + 오프셋 파티션

클러스터당 128개 섹터를 어떻게 결정했나요? 이건 전혀 옳지 않은 것 같아요! 여기에서 기본값을 확인하세요.https://www.disktuna.com/default-cluster-sizes-for-fat-exfat-and-ntfs/.

답변2

손상된 디스크를 귀하가 설명한 읽기 부하에 노출시키는 것은 비전문적입니다. 첫 번째 요구 사항은 추가 섹터의 손실을 방지하고 더 이상 읽을 수 없는 섹터가 없도록 해당 드라이브를 안정적인 정상 드라이브로 복제하는 것입니다. 읽을 수 없는 섹터를 복사할 수 없다는 사실은 슬프지만 중요한 것은 읽기 오류를 처리하기 위해 사용자나 복구 프로그램을 피하는 것입니다.

복구 시도로 인해 이미 해당 드라이브에 추가 손상이 발생했을 수 있습니다.

메타데이터 구조와 데이터가 반드시 선형 방식으로 배치되는 것은 아니기 때문에 나중에 어딘가에서 100GB 슬라이스를 다른 곳의 무료 드라이브 스토리지로 읽어 들여 충분히 큰 드라이브를 하나 이상 소유하지 못한 것을 보완할 수 없습니다. 무작위 액세스가 필요합니다. 불행히도 귀하의 경우 구조가 다음 100GB 슬라이스를 가리키면 100GB 저장 영역을 비워야 합니다.

선호하는 프로그래밍 언어로 이미 구조를 구문 분석하고 있는 경우 복사 작업을 위해 dd와 같은 unix 명령을 실행할 필요가 없습니다. ddrescue는 복구 시도 시작 시 한 번만 필요합니다.

NTFS 내부 기능을 배우고 싶다면 괜찮고 멋진 일이지만 이미 USB 스틱과 같은 저장소에서 배울 수 있습니다. 큰 드라이브는 필요하지 않습니다.

Easeus가 파일 이름 및 폴더 구조와 같은 원하는 메타데이터를 복구하지 못한 이유가 무엇인지 생각해 보십시오.

답변3

나는 드라이브가 클러스터 0의 섹터 0 바이트 0에서 시작하여 물리적 드라이브 끝까지 선형이라고 생각했습니다.

예, 아니오. 저장소 주소는 바이트 0부터 시작하는 선형입니다. 섹터 주소도 선형입니다.

클러스터 주소는 선형이며 클러스터 번호 0부터 시작하지만 해당 파티션에만 상대적입니다. 디스크 전체 클러스터 레이블 지정은 없으며 0부터 시작하는 파티션 전체 클러스터 레이블 지정만 있습니다.

ddrescue와 같은 도구를 사용하여 바이트 0 - 1000000을 읽는 경우 레이아웃을 설명하는 NTFS 메타데이터를 읽을 것이라고 기대하면 안 된다는 말씀이신가요?

NTFS 메타데이터에는 부팅 섹터뿐만 아니라 마스터 파일 테이블 및 기타 파일도 포함됩니다. 드라이브 시작부터 1MB를 읽을 때 해당 위치에 있는 마스터 파일 테이블의 일부만 읽게 됩니다. 해당 위치는 고정되어 있지 않으며 조각 모음 시 변경될 수 있습니다.

여기에서 전략을 사용하여 파일 시스템을 실험하고 알아보세요. https://forum.cgsecurity.org/phpBB3/viewtopic.php?p=31304#p31304

NTFS의 암호를 해독하려고 하면 이미 의도한 결과를 훨씬 더 잘 알 수 있습니다. 이는 전체 일반 텍스트를 아는 "알려진 일반 텍스트 공격"과 같은 일종의 해독 프로세스입니다.

누군가 내 답변을 반대 투표했습니다. 그렇다면 그 이유를 설명해주세요. 어딘가에 오류가 있는 걸까요? 나는 알고 싶다! 감사합니다.

관련 정보