안 쓰던 블로그

[포렌식] FAT 파일 시스템 구조 (FAT에서 파일 복구 방법) 본문

CTF/Forensic

[포렌식] FAT 파일 시스템 구조 (FAT에서 파일 복구 방법)

proqk 2020. 8. 28. 17:27
반응형

Partition

파일 시스템을 보기 전에 파티션과 MBR에 대해 짚고 가겠습니다

파티션 Partition연속된 저장공간을 하나 이상의 연속되고 독립된 영역으로 나누어서 사용할 수 있도록 정의한 규약이다

 

파티션을 나누는 이유는, OS영역과 Data영역을 분리하여 사용하기 위해, 저장 공간을 효율적으로 사용하기 위해, 여러 개의 OS를 하나의 시스템에서 사용하기 위해서 등이 있다

 

 

DOS Partition은 MBR과 BR로 구성된다

MBR: BR을 호출하기 위한 Boot code, Partition Table을 가지며, 디스크의 첫 512 Bytes를 차지한다

BR: 각 파티션의 첫 번째 섹터에 위치한다


MBR

MBR은 Boot Code, Parition Table, Signature로 구성되어 있다

실제 디스크를 해당 크기에 맞게 나눠 보았다

파란 부분은 부트 코드, 이 중에서 파티션 부분만 따로 보면 아래처럼 나뉜다

 

Partition Table에서 한 파티션의 16바이트가 의미하는 바는 다음과 같다

1byte: 부팅여부-00이면 부팅 불가한 디스크다

3bytes: 시작 CHS주소-예전엔 사용했지만 지금은 사용하지 않는 부분이다

1byte: 파티션 타입-어떤 파티션을 쓰는지 알 수 있다

3bytes: 시작 CHS주소-시작이 있으면 끝이 있다. 지금은 사용하지 않는다

4bytes: 시작 LBA-파티션의 처음 부분

4bytes: 마지막 LBA-파티션의 끝 부분. 시작부분과 함께 크기를 알 수 있다. 지금도 쓰이는 부분이고 중요함

 

LBA 계산하는 방법

시작 LBA가 00 08 00 00이니까 리틀 엔디안으로 00 00 08 00 HEX고, DEC으로는 2048이다

즉, 2048섹터로 가면 이 파티션의 시작 섹터(BR)가 있다는 의미이다

두 번째 파티션은 LBA시작이 00 40 08 00으로 4,196,352섹터에 해당 파티션이 있다는 의미이다

세 번째, 네 번째 파티션은 00 00 00 00이므로 해당 디스크에는 3, 4번째 파티션이 없다고 생각할 수 있다

 

(만약 HxD에서 섹터값으로 이동했는데 없으면 디스크 이미지 불러오기로 불러왔는지 확인, 관리자 권한인지 확인)


FAT file system

윈도우의 대표적인 파일 시스템으로, FAT16(최대 2GB), FAT32(최대 32GB)가 있다

FAT Layout

1) BR

FAT16과 FAT32에 약간 차이가 있음

Boot Record가 망가지면 해당 볼륨을 윈도우가 인식할 수 없다

 

2) Reserved

FAT16이면 1Sector예약, FAT32면 32Sectors예약

 

3) FAT#1, FAT#2

클러스터(파티션들의 모임)를 관리하는 테이블이 모여 있음

두 개는 같은 내용인데 #1이 손상될 경우를 대비하여 #2가 있다

 

4) RootDirectory

Root Directory를 분석해야지 Data영역에 데이터가 어디있는지 알 수 있고, 복구도 가능하다

즉, FAT 파일 시스템의 핵심은 Root Directory이다

 

FAT16과 FAT32의 구조는 비슷하지만 FAT32는 Root Directory가 Data영역에 랜덤으로 존재한다는 차이점이 있다

 

5) DATA

디렉토리, 파일들이 클러스터 단위로 저장


1) BR

8바이트: FAT파일 시스템이 가지고 있는 파일 시그니쳐-MSDOS5만 보면 FAT인 걸 알 수 있다

2바이트: Bytes per Sector-512로 고정되어 있다. 섹터값이 바뀌면 바뀐다

1바이트: Bytes per Cluster-클러스터가 되기 위해서 섹터가 몇 개 들어가나? 여기선 8개 들어간다

섹터 크기*여기 값=클러스터 크기

사진에서는 512*8=4096

2바이트: Reserved Sector Count-FAT32에서만 쓴다

1바이트: Number of FATs-사진에서는 FAT수가 2개 있다

2바이트: Root Directory Entry Count-FAT16에서만 쓴다

2바이트: Total Sector 16-FAT16에서만 쓴다

1바이트: media-디스크가 고정방식이냐, 이동방식이냐. F8이면 이동방식이다(USB등등은 이동방식)

4바이트: Root Directory Cluster-루트 리렉터리의 위치지만 속으면 안 된다. FAT32에서는 루트 디렉터리가 랜덤 위치임

backup sector: 지금 보고 있는 이 섹터는 제일 중요한 거라 백업을 해 두는데, 그 백업의 위치를 의미

사진에서는 00 06이니까 섹터 6개 뒤에 위치했다. 지금 있는 BS위치가 2048이니까 +6하면 2054에 있음

Volum ID: 디스크가 가진 고유 ID저장

Volum Lavel: 볼륨의 이름

BootStrap Code: 여기가 손상되면 부팅 안 되지만, 아까 백업 섹터에 가서 복구할 수 있다


2) FAT#1, FAT#2

FAT #1 찾기 (FAT32기준)

Reserved Sector Count + FAT BR Sector

 

위에 사진에서는 Reserved Sector Count가 20 1E = DEC 8,222

FAT BR Sector는 지금 BR 섹터 위치 = DEC 2048

8222+2048=10,270

 

10,270 섹터가 FAT #1의 영역

 

FAT #2 찾기 (FAT32기준)

FAT #1 + FAT Size 32

 

사진에서는 00 00 0F F1 = DEC 4,081

10,270 + 4,081 = 14,351

 

Root Directory 찾기

FAT #2 + FAT Size 32

 

14,351 + 4,081 = 18,432


FAT32에서 파일을 복구하는 과정

그럼 이제 실제로 이미지를 복구해 봅시다

방금 위에서 계산한 루트 디렉토리 위치에서 아래로 두 섹터 쯤 내려가면 PNG 어쩌구 파일이 보인다

 

이 부분 96바이트를 잡는다

원래는 이렇게 두 줄만 분석해도 되는데 지금 11바이트 뒤에가 0F라서 뒤에도 잡아야 한다

왜냐하면 원래 8글자의 이름과 3글자 확장자가 들어가야 되는데, 여기서는 이름이 8글자를 넘어서 11을 넘어가 버렸기 때문에 이 파일은 넘어갔다 라고 0F라고 알려주고 있기 때문이다

0F는 정확히 하면 어트리뷰트라고 속성값이라고 한다

 

그래서 뒤에 32바이트를 봐야 한다

 

근데 그 아래 32바이트를 봤더니 또 11바이트 뒤에 0F가 있다

이 말은, 원래는 32바이트에 담아야 하는데 못 담아서 32바이트를 더 썼는데, 그래도 못 담아 라는 의미이다

그래서 추가적으로 32바이트를 또 증가시켜서 그 아래까지 내려가게 된 것이다

 

최종적으로 이곳의 32바이트를 보면 데이터를 알 수 있다

 

44 4F 53 50 41 52 7E 32 는 이름

50 4E 47 는 확장자. PNG라고 되어 있지만 정확히 알 수는 없다(변경될 수 있기 때문)

20 은 일반적인 파일

00 은 저장되어 있다. 안 본다

5A 는 시간값인데 의미 없다

B9 53 가 중요한데, 이게 파일이 생성된 시간이다. 파일 생성 시간을 비트로 다루기 때문에 이렇게 저장한다

EE 4A 는 데이터 생성 시간

 

*파일 생성 시간 Create Time 2 Bytes 계산 

0x B9 53

0101001110111001고 비트 별로 잘라본다

 

01010 시 10

011101 분 29

11001 초 25

 

*데이터 생성 시간 Create Data 2 Bytes 계산

0x EE 4A

0100101011101110

 

0100101 년 37+1980(FAT가 처음 만들어진 시간)=2017

0111 월 7

01110 일 14

 

 

이제 이 데이터가 있는 위치를 계산해야 한다

일단 위에 이미지를 색깔 별로 나누면 이렇게 된다

 

 

First Cluster High: 00 00

First Cluster Low: 05 0F

두 값의 길이를 합치면 00 00 05 0F = DEC 1295

쓰지 않는 영역값 2를 빼준다 1295 - 2 = 1293

Sector per cluster 값 8을 곱해준다 1293 * 8 = 10344

이 값에 루트 디렉토리 값을 더한다 10344 + Root Directory 18432 = 28776

 

28776이 실제 데이터 위치이다

 

그리고 파일의 데이터 크기 File Size: 00 00 8B 10 = DEC 35600

 

이제 복구를 해 본다

28776섹터로 이동한다

 

FF D8이 보이는데, 이건 jpg 파일이다

png는 89 50 4E 47 0D 0A 1A 0A인데 아까 PNG라는 정보가 틀렸다는 걸 알 수 있다

 

FF에 위치를 두고 블록 선택으로 아까 계산한 데이터 길이를 잡는다

이만큼이 이미지 파일이다

 

해당 부분을 복사-붙여넣기로 새 파일 만들고 확장자는 .jpg로 저장

그러면 이미지 파일이 나온다

복구 완료

 

근데 여기를 보면 크기랑 디스크 할당 크기가 다르다

아까 우리가 계산한 35600가 실제 크기지만, 디스크 할당 크기는 클러스터에 할당된 크기로 인해서 여분의 공간을 써야 하기 때문에 크기가 조금 더 크다

 

포렌식에서 데이터 자체가 중요하다 하면 그냥 이렇게까지만 해도 되는데

진짜 원본 데이터가 중요하다 하면 원본 크기로 복구해야 한다

위의 과정으로 나온 파일이 엄밀-히 따지면 원본은 아닌 것이다

 


FAT32에서 파일을 복구하는 과정_2

다른 파일을 복구해본다

아까 계산한 루트 디렉터리 위치로 돌아간다

시작이 43이므로 파일이 살아 있다(E5가 아니면 살아 있음)

0F가 보이니까 0F가 끝날 때까지 더 잡는다

 

000900140에 00 00 부분

00 00 이 First Cluster High값

시간값 넘어가고

06 00 이 First Cluster Low값

 

1. 길이 붙인다 = 00 00 00 06

2. 2 뺀다 6 - 2 = 4

3. 8 곱한다 * 8 = 32

4. 루트 디렉터리 18432 더한다 32 + 18432 = 18464

 

size는 A0 D8 11 00 = 1,169,568

 

가 보면 MZ가 있다 exe파일이다

사이즈만큼 블록 잡고 .exe으로 저장한다

실제로 실행이 되는 .exe파일이 나왔다


FAT32에서 파일을 복구하는 과정_3 (복구 되지 않는 경우)

복구가 안 되는 파일의 경우도 있다

아까 계산한 루트 디렉터리 위치로 돌아간다

이 데이터를 복구할 것이다

맨 앞이 E5면 삭제되었을 가능성이 매우 높다

E5 46 00 41 00 54 00 33 이름 00 32 00 확장자 + 0F인데 아까 본 0F가 있다

파일 이름이 8바이트 넘는다는 의미이므로 뒤에 32비트를 더 본다

 

E5 41 54 33 32 7E 31 20 이름 5A 49 50 확장자 + 20

ZIP파일이라고 하는데 실제로도 zip인지는 확인을 해 봐야 알 수 있다

20이니까 일반적인 파일이라고 알 수 있다

 

0009000B0에 00 00 부분

00 00 이 First Cluster High값

시간값 넘어가고

06 00 이 First Cluster Low값

 

1. 길이 붙인다 = 00 00 00 06

2. 2 뺀다 6 - 2 = 4

3. 8 곱한다 * 8 = 32

4. 루트 디렉터리 18432 더한다 32 + 18432 = 18464

 

size는 CB 11 01 00 = 70091

 

해당 섹터에 가보니 MZ이다. exe파일이니까 사이즈만큼 블록 잡고 .exe로 저장

근데 실제로 열리지는 않는다

E5로 되어 있는 파일은 삭제되면서 다른 데이터가 덮어씌워져서 복구가 안 될 가능성이 있다

특히 삭제해 놓고 다른 파일 넣었다 뺐다 저장했다 지웠다 그런 걸 반복하면 다른 흔적이 많이 덮어져서 복구가 안 된다고 한다

 

방금 exe파일의 경우 위에서 다룬 exe파일과 First Cluster Low값이 같았다

즉, exe파일을 지운 자리에 exe파일 데이터가 올라가서 복구가 불가능하다고 생각할 수 있다

 

반응형
Comments