4-2.2) FAT32 분석 2(FAT, LFN, 삭제)

FAT32의 FAT, LFN 그리고 삭제를 알아보면 자연스레 복구도 알게 될 것입니다.

2-5) FAT 영역 분석

1. 먼저 HxD, FTK Imager, Active Disk Editor 와 같은 분석도구를 모두 종료한 뒤 FAT32 로 파일 시스템을 구축한 드라이브에서 파일을 만들어 봅시다.

2. "a"로 가득 찬 1300 bytes 짜리 텍스트 파일을 한번 만들어보면. 1클러스터에 512 bytes 이기 1300 bytes 파일은 3개의 클러스터를 사용할 것인데, 정말로 그런지, 그럼 3개의 클러스터는 어떻게 나타내는지 확인하기 위해 FAT를 분석하면서 친해져보도록 합시다.

3. 방법은 여러가지가 있으나 python 이나 powershell 과 같은 다양한 도구를 이용하여 명령어를 입력하여 간단히 만들 수 있습니다. (무조건 아래의 방법으로 할 필요는 없고, 그냥 메모장으로 원하는 크기의 글을 작성하여도 무방) > {FAT32 드라이브명}: ex) D: > python -c "with open('1300.txt', 'w') as file: file.write('a' * 1300)"

   

   *명령어로 만들 수 있다는 것을 보여주는 이유는 추후에 어떤 대량의 더미 데이터를 만들 때 이러한 명령어를 이용하면 원하는 크기의 원하는 내용 혹은 랜덤 내용을 원하는 수로 얼만든지 만들 수 있습니다. ChatGPT 에게 물어보면 쉽게 사용법을 알려줄 것이니 참고하여 필요시 활용하길 바랍니다.

4. 우선 크기는 우리가 1300 bytes 로 만들었었죠. 그렇다면 디스크 할당 크기는 3개의 클러스터를 쓸 것이기 때문에 클러스터 크기 (512) X 3 = 1,536 bytes 입니다. 실제로 사용하는 데이터의 크기는 a, 1300개로 1300bytes

   
5. 우선 FTK Imager를 새로 실행 후 Add Evidence item - Physical Drive 에서 FAT32 드라이브를 열고 root 디렉토리 부분을 살펴봅시다. 1300.txt 파일이 보이고, 해당 파일을 클릭하면 우리가 "a"로 가득 채워둔 파일을 확인할 수 있습니다.

   
6. 우선 우리는 해당 파일에 어떻게 접근하는지 알고 있다. 다시 한번 살펴보도록 합시다. 0번부터 시작하자면, 파티션 테이블을 보고 1번 파티션 시작 위치를 파악하고 FAT32의 BR이 위치한 섹터 확인 후 Reserved + FAT1 + FAT2 하면 Cluster2번이 시작합니다. 이곳이 루트디렉토리의 데이터영역에 해당하고 루트디렉토리의 데이터 영역에 파일들의 정보를 가진 디렉토리 엔트리를 확인할 수 있습니다.

   자 여기서 우리는 방금 생성한 1300.txt 파일의 디렉토리 엔트리를 찾고, 클러스터 시작 위치값을 나타내는 Cluster high, Cluster Low를 찾으면 아래 그림에서 확인할 수 있습니다.

   

   8번 클러스터에 시작 위치라는 것을 확인할 수 있으며, 8 번 클러스터를 가기 위해선 (8-2) X 1(클러스터당 섹터 수) = 6 데이터영역 시작기준(루트디렉토리 위치) 6 섹터가 8번클러스터가 시작된다는 것입니다. 즉, 8320 + 6 = 8,326 물리섹터에 8번 클러스터가 시작되는 위치입니다.

   
7. a가 1300 바이트가 있으면 3개의 섹터를 사용할텐데 3개의 섹터가 어디어디에 해당하는지 파악을 해야할 필요가 있습니다. 그냥 간단히 한번 생각해보면 8,326 섹터(8번 클러스터)가 시작이니, 8,327(9번 클러스터), 8,328(10번 클러스터) 연달아 사용하면 좋을거 같습니다. 실제로 그런지 한번 살짝 내려봅시다.

   

   우선은 8, 9, 10번 클러스터를 사용 합니다. 그렇다면, 파일을 새로 만들때 9번, 10번 클러스터가 이미 사용 중이라는 것을 알아야할 텐데.. 그래야 9번, 10번 클러스터에 덮어쓰지 않을 것이죠..

8. 자 이제 8,9,10번 클러스터가 하나의 파일이라는 것, 8,9,10클러스터가 쓰고 있다는 것을 모두에게 알릴 필요가 있습니다. FAT32에서는 어떻게 특정 클러스터가 사용 중 이라는 것을 알리는지 알아아봅시다. 이제 FAT영역을 분석 해봅시다.

9. FAT 영역 시작 위치를 계산해보면..

   

   먼저 부트레코드에서 예약영역 값을 다시 한번 계산해 봅시다 - Reserved Sector Counter : 3E 1A (리틀엔디안) -> 1A 3E (16진수) = 6,718 (10진수) - FAT 크기 : E1 02 00 00 -> 00 00 02 E1 (16진수) = 737 > FAT32 BR (128) + Reserved (6,718) = 6,846 섹터 (FAT 위치)

   

   6,846 섹터(물리 섹터)로 가봅시다. 아직은 잘 모르지만 어떤 데이터들이 있는 것을 알 수 있습니다.

   

   FAT1 , FAT2가 있는데 FAT2는 FAT1의 복사본이라고 생각하면 됩니다. FAT2는 FAT1 뒤에 있는 것을 알 수 있습니다. 한번 가보도록 합시다.

   6,846 + 737(FAT 크기) = 7,583 섹터

   
10. 정리하면 FAT1 은 6,846 섹터, FAT2는 7,583에 위치하는 것을 알 수 있습니다. 매번 이렇게 접근해야 할까? 이미 FTK Imager에서는 FAT1, FAT2 위치를 그리고 Reserved 섹터 위치도 가리키고 있습니다.

    
11. [FAT Entry] FAT 영역을 분석 해봅시다! 기본 구조는 4 Bytes 단위(FAT Entry)로 클러스터 번호의 정보를 가지고 있습니다. 처음 보면 눈에 잘 안들어오니 우선 우리의 목표인 클러스터 8, 9, 10번에 대한 부분만 살펴보면..

    

    클러스터 8 : 09 00 00 00 -> 00 00 00 09 (16진수) -> 9 (10진수) 클러스터 9 : 0A 00 00 00 -> 00 00 00 0A (16진수) ->10 (10진수) 클러스터 10 : FF FF FF 0F -> 0F FF FF FF (마지막 의미) 즉, 1300.txt 는 8~10번 클러스터를 사용합니다.

12. 먼가 느낌적인 느낌이 오지 않으신가요? 클러스터 8번의 정보를 가진 FAT 엔트리는 다음 클러스터 9번을 가리키고 있고 클러스터 9번의 정보를 가진 FAT 엔트리는 다음 클러스터 10번을 가리킨다. 클러스터 10번의 경우 마지막 클러스터를 의미하는 값을 가지고 있습니다. 즉, 클러스터 8~10번까지 사용하고 끝난다는 의미인 것이죠. [FAT 영역 속성 종류] - 00 00 00 00 : 해당 클러스터가 사용 가능. 비할당 상태이다. - 0F FF FF F7 : Bad Cluster - 0F FF FF F8(보다 큰 값) : 파일의 끝을 나타낸다. / 보통 0F FF FF FF *우리는 0번, 1번 클러스터가 이미 다른 이유로 쓸 수 없다는 것을 알고 있기 때문에 당연히 0000000, 00000001 값은 올 수 없을 것입니다. 만약 파일의 수가 많고, 지웠다가 다시 파일 생성을 반복하다 보면 데이터가 저장된 클러스터가 마구 섞일 수 있으나, FAT 영역만 정확하다면 클러스터 번호를 잘 가리켜서 연결하면 하나의 파일의 처음부터 끝까지의 클러스터를 가리켜 제대로 접근이 가능하게 될 것입니다.

2-6) 클러스터 수와 비할당 영역 확인

1. FAT와 클러스터와의 관계를 조금 더 고민해봅시다. 우선, 1섹터에 FAT Entry 가 총 몇 개가 들어갈까? 1섹터 / FAT Entry 크기 = 512 / 4 = 128

   그렇다면, 전체 FAT Entry는 몇 개일까? FAT 크기 : 737 [FAT 부트레코드 참고] > 737 X 128(1섹터당= FAT Entry 수) = 94,336 여기서 0번, 1번은 제외해봅시다. > 94,336 -2 = 94,334 개의 클러스터를 이론상 나타낼 수는 있습니다.

   그렇다면 데이터 영역의 크기안에 클러스터 갯수는 몇 개일까? - 전체 섹터 수 - (예약영역 + FAT1 + FAT2) = 데이터 영역 섹터 [FAT 부트레코드 참고] -> 102,400 - (6,718 + 737 + 737) = 94,208 섹터

   데이터 영역의 실제 클러스터 수는 몇 개 일까? - 94,208 섹터 / 클러스터 당 섹터 수(1) = 94,208 클러스터

   음.. 이상하지 않는가? FAT 크기는 737섹터여서 94,334를 나타낼 수 있는데 실제 데이터 영역의 클러스터 수는 94,208입니다. 한번 FAT 크기를 1섹터 - 736 X 128 = 94,208 (딱 맞네..?) 그럼 클러스터 개수의 기준을 뭘로 잡아야 할까..? FAT Entry 갯 수? 실제로 구현되어있는 데이터 영역 섹터에서 클러스터당 섹터 수를 나눈 값?

ChatGPT 한테 물어보자!

차이의 원인

FAT 크기를 737 섹터가 아닌 736 섹터로 계산하는 이유는 다음과 같은 이유로 설명될 수 있습니다

1. 실제 사용 가능한 클러스터 수

• 데이터 영역의 실제 클러스터 수는 94,208입니다. 이는 실제로 사용할 수 있는 클러스터 수를 나타냅니다.

• 그러나 FAT 크기를 계산할 때는 파일 시스템의 일부 예약된 섹터나 시스템에서 사용하는 추가적인 섹터를 고려하지 않기 때문에 약간의 차이가 발생할 수 있습니다.

1. 파일시스템의내부관리

• FAT 테이블의 일부는 파일 시스템의 내부 관리 목적으로 사용되며, 이는 일반적으로 사용자가 접근할 수 있는 데이터 영역에 포함되지 않습니다. 예를 들어, 파일 시스템의 구조적 요구사항이나 메타데이터 관리 등을 위해 일부 섹터가 할당될 수 있습니다.

1. 여유 공간 및 정렬

• FAT 테이블의 크기를 계산할 때, 파일 시스템이 여유 공간을 확보하거나 특정 정렬 요구사항을 만족시키기 위해 일부 섹터를 할당하지 않을 수 있습니다. 이는 성능 최적화나 데이터 무결성을 유지하기 위한 조치일 수 있습니다.

결론

• FAT32 파일 시스템에서 FAT 크기를 737 섹터로 계산하더라도, 실제 데이터 영역의 클러스터 수는 736 섹터를 기준으로 계산하는 것이 더 정확할 수 있습니다. 이는 파일 시스템 구조와 관리 방식에서 기인하는 차이이며, 실제로 사용 가능한 클러스터 수를 정확히 반영하기 위한 조치입니다. 따라서, 736 섹터를 기준으로 계산하여 94,208 클러스터를 얻는 것이 더 일치하는 결과를 제공합니다.

1. 우선 포렌식 도구들을 살펴보면.. 94,208로 데이터 영역 기준으로 클러스터 크기를 나눈 클러스터 갯 수를 표시하는 것으로 보이네요. 사실 이게 정확할 거 같은게 설령 FAT Entry가 데이터 영역을 벗어난 클러스터를 가리키게 된다면, 파일시스템의 전체 크기를 넘어설 수 있게 되는 것입니다.

1. 정리하면, 클러스터 수는 데이터 영역 섹터 수 / 클러스터당 섹터 수 = 클러스터 수가 될 것이고 FAT 영역에서 FAT Entry 값이 00 00 00 00 인 갯수가 아직 사용하지 않은 전체 클러스터 개수로, 비할당영역으로 앞으로 우리가 사용 가능한 데이터 영역이 될 것입니다. 보다 정확하게 하려면 전체 클러스터 수 - (FAT Entry 가 빈값이 아닌 개수) = 사용 가능한 클러스터 수가 될 것입니다. 우선 우리가 실습하던 파일시스템에서는 00 00 00 00이 아닌게 총 11개가 있습니다. (실습환경마다 갯수가 조금 다를 수 있습니다.) 그러나 0, 1번은 해당되지 않고 처음 2번부터 시작하다보니 2개를 제외하고 계산하여야 합니다. 2 ~ 11 개로 9개가 사용중인 클러스터에 해당하는 것입니다.

   
2. 전체 클러스터 수 - 사용중인 클러스터 수 = 사용 가능한 클러스터 수 24,208 - 9 = 94,199 가 사용 가능한 클러스터 수에 해당합니다.

   
3. 이제 정리하여 보자! - 파일시스템 크기 : 102,400 = 102,400 X 512 = 52,428,800 bytes - 예약된 영역 : 6,718 - FAT 크기 : 737 - 데이터 영역 크기 = 파일시스템 크기 - (예약된 영역 + FAT 크기 + FAT 크기) [단위 섹터] = 102,400 - (6,718 + 737 + 737) = 94,208 - 클러스터 수 = 데이터 영역 크기 / 클러스터 당 섹터 수 = 94,208 / 1 = 94,208 클러스터 - 사용 가능한 용량(Capacity) = 클러스터 수 X 클러스터 당 섹터 수 X 섹터당 클러스터 수 = 94,208 X 1 X 512 = 48,234,496 bytes (46MB) - 사용중인 클러스터 수 = FAT 영역 분석 - 2(0, 1 클러스터 사용 안함) = 9 - 비할당 영역(사용가능 영역) = (전체 클러스터 수 - 사용 중 클러스터 수) X 클러스터 크기 = (94,208 - 9) X 512 = 48,229,888 (46 MB)

4. 사실 위의 공식등은 전혀 외우거나 알기 위해 노력할 필요는 없습니다. 대부분의 도구가 자동으로 해주기 때문이죠. 이미 FAT32는 많이 쓰인 파일시스템이기 때문에 분석 소스도 많습니다. 다만 파일시스템 처음 분석하는 과정에서 이러한 노력을 한번 정도만 한다면 왜 포렌식 도구에서 이런 값이 나온건지, 어떤 값은 보이는데, 어떤 값은 왜 없는 건지.. 등등을 알 수 있게 되는 것입니다.

2-7) Long File Name (LFN) 긴 파일명

• 자 위에서 Directory Entry 를 보면서 약간 의문이 드는게 있을 것입니다. 파일명의 길이가 긴건 어떻게 되는거지..? 기본 Direcotry 에서는 파일명이 최대 8byte 밖에 안되는데.. 이제 FAT 32 에서는 어떻게 긴 파일명을 표시하는지 알아보도록 합시다.

1. 우선 FTK Imager 등을 모두 종료 한 뒤 다시 FAT32 디스크를 열어봅시다. 먼저 파일명을 길게 만들어 봅시다. 기존의 것을 복붙 해서 이름 변경하거나 새로 아래와 같이 만들어 보자. 가능하면 이어지는 숫자, 영문을 표시하도록 합시다.(한글은 디렉토리 엔트리에서 찾기가 어려우니..)

   
2. 처음에는 파일명 긴거에 대한 디렉토리 엔트리 + LFN 찾기가 조금 힘들긴 하지만 우선은 한번 흐름을 보고 찾아보도록 합시다.

   
3. 제일 하단에 위에서 알아봤었던 Direcotry Entry 가 가장 밑으로 오고 위에 파일길이 만큼 LFN 여러개가 올라가면서 긴 파일명을 표시해줍니다.

   

   LFN(Long File Name)

   

   Directory Entry

   
4. 자 차근차근 위 구조를 파악해봅시다. 우선 최하단은 위에서 분석 했던 것 처럼 파일명, 파일의 시간정보, 시작섹터 번호, 전체크기 등이 있는건 동일합니다.

5. [order] 우선 Order 부분에 해당 하는 부분만 먼저 확인하여 보면 1번째 LFN의 경우 01, 2번째 LFN의 경우 02, 마지막 LFN의 경우 43을 나타냅니다. 마지막의 경우 4X가 추가되는 것을 알 수 있습니다.

   

6. [Name] 부분만 살펴봅시다. 차근차근 LFN 순서대로 파일명이 나열되는 것을 알 수 있으며 - LFN에서는 최하단에 있는 Name 은 깔끔히 무시하고 처음부터 "." 과 확장자 까지 표시한다. - 또한 한글자 표현하는데 2bytes 씩 표현되는 것을 알 수 있습니다. > 이는 유니코드를 이용하여 저장하는 방식으로 유니코드를 해석해주는 에디터에서는 조금 더 보기 편할 것입니다.

   
7. [Attr] , [Type],[Chksum], [First Clus low] - 속성 : 항상 0F - 타입 : 항상 00 - 체크섬 : 2A -"123456~1TXT" 의 체크썸 계산값 * 체크섬의 경우 Direcotry Entry Name 에 있는 "123456~1.TXT" 부분을 체크썸 계산한 값입니다. LFN과 하단에 있는 Directory Entry 의 텍스트값이 정확하다는 것을 체크하기 위한용도 - First Clus low : 항상 00 00

   

체크썸 계산 파이썬 소스

def calculate_checksum(buf):
    checksum = 0
    
    for i in range(11):  # 8.3 형식의 파일 이름은 항상 11바이트입니다.
        checksum = ((checksum & 1) * 0x80) + (checksum >> 1) + ord(buf[i])
        checksum &= 0xFF  # Ensure it stays within byte range
    
    return checksum

# 예제 파일 이름 (8.3 형식, 11바이트)
short_name = "123456~1TXT"

# 체크섬 계산
checksum = calculate_checksum(short_name)
print(f"Checksum for '{short_name}' is: {checksum:02X}")

• 긴 파일명을 다시 짧게 변경하면 어떻게 될까..?

  

  결과만 한번 보도록 해보겠습니다. 디렉토리 엔트리 해당 섹터 찾는 건 이제 금방 하실 수 있으실 겁니다. 살펴보면.. LFN의 맨 앞이 E5고 나머지는 그대로. 하단에 새롭게 디렉토리 엔트리가 추가되었습니다. E5는 무슨 의미일지는 아래에서 확인해보도록 합시다.

  

  자 먼가 장난을 쳐보고 싶어 집니다... E5로 바뀐걸 원래값으로 수정한다면 해당파일은 어떻게 될까요? 그리고 둘다 같은 클러스터 번호를 가리키고 있으니 당연히 같은 내용을 가지고 있을까요..? 그리고 데이터 부분을 수정한다면 어떻게 될까요..? -> 이런 여러가지 장난은 추후 더 친해지기, 혹은 장난치기 시리즈에서 다양한 시도를 해보도록 하죠!

2-8) 파일의 삭제 그리고 복구..?

• 파일을 삭제하였을 때 어떤 변화가 있는지 한번 살펴보도록 합시다. 우선 우리가 생성해두었던 1300.txt (a가 1,300 바이트 저장된 파일)을 한번 삭제하고 어떤 변화가 있는지 살펴보도록 합시다.

1. 기본 삭제 (휴지통 이동) 먼저 그냥 기본적인 삭제를 해보도록 합시다. 우클릭 - 삭제를 할 경우 기본적으로 휴지통으로 가게 됩니다. 한번 어떻게 되는지 살펴보도록 합시다.

   

2. 이 후 디렉토리 엔트리의 변화를 한번 보도록 하죠. 가상디스크에서 삭제한다고 해서 바로 변화가 생기는건 아니니 조금 기다렸다가 FTK Imager에서 Physical Drive로 다시 열어봅시다. 자 아래와 같이 삭제된 것이 보이고 디렉토리 엔트리에서는 가장 앞에 E5로 바뀐 것을 알 수 있습니다. 다만 나머지는 모두 그대로 있는 것을 알 수 있습니다.

   

3. 자 그럼 이제 휴지통에서 복원을 한번 해볼까요? 그리고 다시 한번 디렉토리 엔트리를 한번 살펴봅시다. 복원 후 다시 FTK 를 재시작 한 뒤 잠시 기다렸다가 FAT32 드라이브를 살펴봅시다. 기존의 것을 복원하는 것이 아닌 그냥 새로 하단에 새로운 디렉토리 엔트리를 만들었습니다.

   

4. 그런데 여기서 생각을 한번 해봅시다 1300.TXT라는 파일명의 앞에 1자리에 16진수 E5로 삭제표시를 했습니다. 그런데 복원을 하려면 E5자리가 다시 숫자1을 표시하는 값이 었다는 것을 어떻게 알죠..?

   31 33 30 30 20 20 20 20 54 58 54 (1300.txt) E5 33 30 30 20 20 20 20 54 58 54 (?300.txt) 즉, hex 값 31 -> E5로 바뀌어 저장되었습니다. 삭제 후 원래 31이였다는 것을 어떻게 알까요? 디렉토리엔트리 어디에도 31이였다는 걸 저장하는 공간이 없습니다.

5. 일단 우리는 휴지통에서 복원을 하였습니다.

   그러나 휴지통은 윈도우에서만 사용하는 것(윈도우아티팩트)으로 우선은 이번 시간에서는 휴지통에 대한 제대로된 분석을 하진 않을 것입니다.

   다만 참고적으로만 확인해보겠습니다. $RECYCLE.BIN 폴더를 보면 이상한 파일들이 있는데 $I~~ 로 시작하는 파일을 확인할 수 있습니다. 여기에 삭제된 파일의 경로가 저장되고 있습니다.

   

6. 이번엔 휴지통 삭제가 아닌 완전 삭제를 해보도록 하겠습니다. 먼저 Shift 키를 누른 상태에서 Del키 또는 우클릭 - 삭제를 하면 아래와 같이 완전히 삭제하시겠습니까? 가 나오면 삭제를 진행합니다.

   

7. 이번에도 동일하게 디렉토리 엔트리 가장 처음이 E5로 바뀌었습니다. 대신 휴지통에서는 복원할 수가 없습니다. 그런데 자세히보면, 디렉토리 엔트리에서 클러스터를 나타내는 영역이 그대로 남아 있습니다. 그리고 파일 사이즈도 남아 있습니다. * 만약 클러스터 low 부분이 00 00 으로 초기화 되었다면, 해당 클러스터 번호를 나타낼 수 있게 수정 후 실습 (운영체제, 설정마다 다른 경우 있음)

   

   FAT 영역을 한번 살펴봅시다. 클러스터번호 8,9,10번을 나타내는게 원래는 있었는데 모두 비활성화 영역으로 변경되었습니다. 이제 클러스터 8, 9, 10번은 쓸 수 있는 클러스터가 되는 것이지요.

   
8. 삭제하는 과정을 한번 살펴봤습니다. 그렇다면 한번 생각을 해보도록 하죠, 그대로 역으로 돌려서 우리가 수동으로 파일 복구할 수 있을까요? HxD를 관리자 권한으로 실행 후 읽기전용 체크 해제하여 FAT32가 있는 가상디스크를 선택합시다.

   

   자.. 디렉토리 엔트리 영역에서 1300.txt를 삭제하였던 디렉토리엔트리 영역에서 E5를 원래의 31로 변경 후 저장하여 봅시다.

   

   FAT 영역은 복구하지 않았는데 어떤 증상을 보이는지 한번 살펴볼까요?(약간의 장난치기) 우선을 파일이 보입니다. 대신 실행을 하면 아래와 같이 에러가 발생합니다. 1300.txt.가 실행되면서 실행된 메모장 먼저 프로그램을 끄고, 에러를 여러 번 종료하세요!

   

   종료가 안되면 일단 창을 치워놓고 다시 FAT영역을 정상으로 돌려 봅시다.

   

   당연히 복구가 잘 되었을 것입니다.
9. 파일 삭제과정을 간단히 보면 1. Directory Entry의 Name 의 가장 처음 부분을 E5 로 변경한다. 2. 기존의 할당되어 있던 FAT 영역의 값이 초기화 된다. > 그런데... 휴지통에서 복원할때 FAT 영역값이 만약 초기화 되었다면, FAT Entry 몇 번 몇 번이 사용되었는지 어디에 저장해두지? 한번 다시 확인해보도록 하자.

10. 다시 파일을 삭제 한 뒤 휴지통에 있는 상태에서 FAT 영역을 한번 살펴봅시다. 휴지통으로가 있는 상태에서는 FAT 영역에 변화가 없다.

    
11. 그렇다면 그냥 Directory Entry 에서 E5를 바꾸면 바로 복원되지 않을까요? E5를 원래의 31로 변경해봅시다.

    
12. 파일이 당연히 복구가 될 것입니다. 디렉토리 엔트리가 온전하고, FAT 영역이 온전하기 때문에 파일 접근이 되는 것이지요.

    

    그런데.. 그럼 휴지통에 있는건..? 우리는 복원과 상관없이 지웠기 때문에 휴지통에 남아있습니다. 복원을 했더니 덮어 쓸거냐고 물어보네요. 만약 파일 이름을 변경해두었다면 1300.txt로 복원이 될 것입니다.

    
13. 그런데.. 이 과정을 통해서 우리가 조금 이상한 것을 알 수 있습니다. Directory Entry와 FAT 영역이 바뀌는건 알겠는데 데이터영역 즉, 8, 9, 10번 클러스터는 전혀 건들지 않고 있다. 즉, 데이터가 그대로 남아 있는 다는 것이다. 또한 디렉토리 엔트리 영역쪽에 시작 클러스터를 나타내는 부분을 초기화 한다면, 시작클러스터 위치를 모르게 하는게 좋지 않을까?

    

    실제로 완전삭제를 할 경우 디렉토리엔트리의 Cluster high, low 를 초기화 하는 경우도 있습니다.

14. 파일시스템을 유지하면서 한 파일에 대해 완벽하게 지우고 싶다면 어떻게 해야할까?

    1. 디렉토리 엔트리가 가리키는 모든 데이터에 접근해서 00 으로 채움

    2. FAT Entry를 초기화 함 -> 그렇게 해야 비할당 영역으로 추후 사용가능

    3. Directory Entry도 초기화 함 -> 파일명, 삭제시간, 확장자 등 정보 모두 깔끔히 삭제, 디렉토리 엔트리 저장공간 확보

15. 그런데 현실은..? (휴지통 삭제) - Directory Entry 의 Name 앞에 1byte만 E01로 변경, FAT 초기화도 안함(복원할 때 쓰려고) > 이러면 삭제하여도 저장공간의 일부를 사용 하고 있는 중

    (완전 삭제) Directory Entry 의 Name 앞에 1byte만 E01로 변경, FAT 초기화 -> 삭제한 공간 확보됨

    • 운영체제 혹은 설정에 따라 Directory Entry 의 Cluster high, low 초기화 하는 경우 있음 만약 위 실습에서 Cluster high, low 부분이 00 이였다면 08로 수정해서 진행하면 위의 실습 가능 (또는 원래 파일의 데이터 영역의 클러스터 번호)

16. 사실 컴퓨터의 부담을 최소화를 위해 디렉토리 엔트리, FAT 영역만 수정하게 된 것으로 보입니다. 일반 컴퓨터에서 잘 지우는 것은 크게 중요한 사항이 아니기 때문에 조금이라도 빠르게 저장하고 활용하기 위해 이렇게 만든거 아닐까요..?

사실 FAT32 파일시스템 기초를 공부하는 입장에서 보면 휴지통 삭제와 완전삭제를 비교하는 것은 파일시스템을 공부한데는 적절하지 않는 접근 방법 일수도 있습니다. 단순하게 삭제할 경우 E01으로 바뀐다 정도면 충분합니다.

이유는 휴지통 방식은 윈도우에서만 해당되는 내용이고, FAT32를 윈도우에서 쓸때 복원을 용이하게 하기 위해 FAT32 구조를 이해한 상태에서 이런식으로 FAT 영역을 살려두는 방식으로 사용하고 있는 것이지 무조건 항상 이런식으로 활용하는건 아니기 때문이지요

사실 FAT32의 이러한 쉬운 구조 때문에 많은 운영체제, 시스템, USB나 SD카드와 같은 저장매체에서 사용하는 것이며, 윈도우만을 위한 것은 아닙니다. (물론 빌게이츠가 만든거라 DOS/윈도우랑 완전 별개로 개발 했다고는 할 수 없지만..)

그럼에도 한번 이렇게 휴지통과 완전 삭제 비교 분석을 해본 것은 이렇게 파일시스템 대상으로 어떤 변경을 주었을 실제로 비교해보는 실습을 하기에 가장 쉽고 당장 해볼 수 있는 실습이라 포함하게 되었습니다. 이런식으로 어떤 장난을 했을 때 어떤 변화가 생기는지 직접 분석을 해보는 과정이 필요하고, 의문점에 대하여 이러한 분석 경험을 쌓게 되면 개인적인 연구를 하거나, 도구 개발 등에 활용하는 기초연습이 될 것입니다.

2-9) 포맷

• 우리는 주로 포맷을 하면 디스크가 지워진다는 이야기를 하게 되는데 사실 포맷은 파일시스템을 새로 구축한다고 생각하면 좋을 것 같습니다. 그렇다면 포맷할 때 용어를 한번 살펴볼까요?

• 우리가 만든 50MB 짜리는 매우 작은 용량이기 때문에 단순히 우클릭 포맷 할 경우 FAT32로 포맷되지 않고 FAT = FAT16으로 포맷되네요. FAT16을 분석해보고자 할 경우 FAT32랑 거의 동일하나 몇가지 제외 되었으니 따로찾아보면서 공부하면 충분히 쉽게 파악이 가능할 것입니다.
• 윈도우에서 왜 이렇게 만들어 두었는지는 모르겠으나.. 파티션 용량을 더 크게 할 경우 기본 USB도 FAT32가 가능합니. 그러나 디스크 관리에서 볼륨 생성시에는 FAT32도 가능합니다.