Proneer | Security is a people problem...
파일은 파일시스템에 저장될 때 파일시스템의 쓰기 정책(Write Policy)에 따라 저장된다. 이러한 쓰기 정책과 저장 장치의 여유 공간에 따라 파일을 조각나 저장될 수 있다. 최근에는 대용량의 저장 장치의 사용으로 저장 장치의 여유 공간만 충분하다면 조각화 비율이 크지 않을 것이다. 하지만 저장 장치를 꽉 채워서 사용하는 경우 조각화가 많이 발생할 수 있다. 다음은 필자의 하드디스크를 대상으로 파일 조각화 비율을 측정해 본 것이다.
C: 드라이브의 경우 용량이 적기 때문에 비교적 꽉 채워진 상태로 사용을 한다. 그 때문에 다른 드라이브에 비해 조각화 비율이 매우 높았다. 일반적으로 생각할 때 평균적으로 용량이 큰 파일 (동영상 등)이 더 조각화가 많이 난다고 생각할 수 있다. 하지만 실제 실험을 해본 결과 파일의 크기도 영향을 많이 미치지만 저장 장치의 사용량이 더욱 큰 영향을 미친다. JPEG와 같이 용량이 적은 파일들도 C: 드라이브에 거의 50%가 조각이 발생했으니 말이다.
이러한 조각난 파일들은 비율이 적어 관심의 대상에서 제외될 수 있지만 포렌식 관점에서 보면 조각난 파일이 수사의 결정적인 증거가 될 만한 상황은 항상 존재하기 마련이다. 이러한 이유로 조각난 파일을 간과해서는 안될 것이다. 하지만 현재의 수사 환경에서는 인력과 시간의 부족으로 조각난 파일까지 고려하기는 참 어려울 것이다. 하지만 현실과 이론의 차이는 항상 존재하는 법이니깐 이러한 논의는 접어 둬야 겠다.
조각난 파일을 원래의 파일로 복구하기란 참 어려운 일이다. 파일 카빙 기법이 많이 발전되었다고는 아직까지 조각난 파일은 연구의 대상이다. 몇몇 파일에 대해서는 그 가능성을 보이지만 우선 현재 사용되는 대용량의 저장 장치에서 조각난 파일의 조각들을 찾는 일이 상당히 오래 걸린다.
윈도우즈 환경의 경우 파일을 저장할 때 클러스터 단위를 사용하기 때문에 조각도 클러스터 단위로 이루어진다. 100GB 용량의 저장장치의 경우 4KB 클러스터를 사용한다고 가정 했을 때 26만개 정도의 클러스터가 존재한다. 26만개의 클러스터를 조합(Combination)한다고 했을 때 가능한 경우의 수는 매우 크게 된다.
따라서 이러한 시간을 줄이기 위해서는 무엇보다도 파일 조각들을 분류하는 작업이 선행되어야 할 것이다. 파일 조각을 분류하기 위해서는 바이트 빈도수, 바이트 변화률, 엔트로피, 복잡도 등 매우 다양한 통계 및 확률적 방법이 쓰인다. 또한 파일의 고유한 특성을 이용하는 경우도 있다.
이러한 이야기를 갑자기 하는 이유는 최근 발표한 논문이 이에 관한 논문이기 때문이다. 이미 과거에 관심이 있어서 관련 논문모두 읽어본 적이 있다. 하지만 한동안 뜸하다가 최근 SADFE(Systematic Approaches to Digital Forensic Engineering) 2009에서 기존의 논문과는 다르게 파일의 특성에 초점을 맞추어 새로운 논문이 발표되었다. 항상 이것에 관해서 논문을 쓰려고 하지만 참 시간이 나질 않는다. 벌써 2년이 다 되어가지만 주말을 편하게 쉬어본적이 없는 것 같다.
혹시 관심이 있는 사람은 ForensicsWiki에서 제공하는 다음의 논문들을 참고해보기 바랍니다.
http://www.forensicswiki.org/wiki/File_Format_Identification
File Fragmentation Identification
파일은 파일시스템에 저장될 때 파일시스템의 쓰기 정책(Write Policy)에 따라 저장된다. 이러한 쓰기 정책과 저장 장치의 여유 공간에 따라 파일을 조각나 저장될 수 있다. 최근에는 대용량의 저장 장치의 사용으로 저장 장치의 여유 공간만 충분하다면 조각화 비율이 크지 않을 것이다. 하지만 저장 장치를 꽉 채워서 사용하는 경우 조각화가 많이 발생할 수 있다. 다음은 필자의 하드디스크를 대상으로 파일 조각화 비율을 측정해 본 것이다.
| Fragment Count |
C: 60 GB | D : 180 GB | E : 300 GB | I : 115 GB |
| $MFT 500 MB | $MFT 130 MB | $MFT 350 GB | $MFT 47 MB | |
| 1 | 161,766 (88%) | 85,645 (98%) | 338,975 (95%) | 30,934 (96%) |
| 2 | 10,661 | 757 | 17,675 | 386 |
| 3 | 3,772 | 344 | 229 | 229 |
| 4 | 2,673 | 309 | 73 | 148 |
| 5 | 2,094 | 175 | 7 | 311 |
| 6 | 526 | 65 | 0 | 92 |
| 7 | 539 | 49 | 0 | 54 |
| 8 | 230 | 22 | 5 | 22 |
| 9 | 191 | 29 | 4 | 21 |
| 10 | 156 | 23 | 0 | 14 |
| Total | 182,608 | 87,418 | 356,968 | 32,211 |
C: 드라이브의 경우 용량이 적기 때문에 비교적 꽉 채워진 상태로 사용을 한다. 그 때문에 다른 드라이브에 비해 조각화 비율이 매우 높았다. 일반적으로 생각할 때 평균적으로 용량이 큰 파일 (동영상 등)이 더 조각화가 많이 난다고 생각할 수 있다. 하지만 실제 실험을 해본 결과 파일의 크기도 영향을 많이 미치지만 저장 장치의 사용량이 더욱 큰 영향을 미친다. JPEG와 같이 용량이 적은 파일들도 C: 드라이브에 거의 50%가 조각이 발생했으니 말이다.
이러한 조각난 파일들은 비율이 적어 관심의 대상에서 제외될 수 있지만 포렌식 관점에서 보면 조각난 파일이 수사의 결정적인 증거가 될 만한 상황은 항상 존재하기 마련이다. 이러한 이유로 조각난 파일을 간과해서는 안될 것이다. 하지만 현재의 수사 환경에서는 인력과 시간의 부족으로 조각난 파일까지 고려하기는 참 어려울 것이다. 하지만 현실과 이론의 차이는 항상 존재하는 법이니깐 이러한 논의는 접어 둬야 겠다.
조각난 파일을 원래의 파일로 복구하기란 참 어려운 일이다. 파일 카빙 기법이 많이 발전되었다고는 아직까지 조각난 파일은 연구의 대상이다. 몇몇 파일에 대해서는 그 가능성을 보이지만 우선 현재 사용되는 대용량의 저장 장치에서 조각난 파일의 조각들을 찾는 일이 상당히 오래 걸린다.
윈도우즈 환경의 경우 파일을 저장할 때 클러스터 단위를 사용하기 때문에 조각도 클러스터 단위로 이루어진다. 100GB 용량의 저장장치의 경우 4KB 클러스터를 사용한다고 가정 했을 때 26만개 정도의 클러스터가 존재한다. 26만개의 클러스터를 조합(Combination)한다고 했을 때 가능한 경우의 수는 매우 크게 된다.
따라서 이러한 시간을 줄이기 위해서는 무엇보다도 파일 조각들을 분류하는 작업이 선행되어야 할 것이다. 파일 조각을 분류하기 위해서는 바이트 빈도수, 바이트 변화률, 엔트로피, 복잡도 등 매우 다양한 통계 및 확률적 방법이 쓰인다. 또한 파일의 고유한 특성을 이용하는 경우도 있다.
이러한 이야기를 갑자기 하는 이유는 최근 발표한 논문이 이에 관한 논문이기 때문이다. 이미 과거에 관심이 있어서 관련 논문모두 읽어본 적이 있다. 하지만 한동안 뜸하다가 최근 SADFE(Systematic Approaches to Digital Forensic Engineering) 2009에서 기존의 논문과는 다르게 파일의 특성에 초점을 맞추어 새로운 논문이 발표되었다. 항상 이것에 관해서 논문을 쓰려고 하지만 참 시간이 나질 않는다. 벌써 2년이 다 되어가지만 주말을 편하게 쉬어본적이 없는 것 같다.
File Fragmentaion Classification.pdf혹시 관심이 있는 사람은 ForensicsWiki에서 제공하는 다음의 논문들을 참고해보기 바랍니다.
http://www.forensicswiki.org/wiki/File_Format_Identification
'Data Foreniscs' 카테고리의 다른 글
| Microsoft Word 2007 (.docx)에서 이미지 파일 변환 형태 (2) | 2009/11/25 |
|---|---|
| Image Format Signatures (0) | 2009/11/23 |
| File Fragmentation Identification (0) | 2009/11/16 |
| Common File Signatures (5) | 2009/10/23 |
| INFO2 File Analysis (0) | 2009/10/23 |
| 어플리케이션 바인딩 (Application Binding) (0) | 2009/10/17 |
댓글을 달아 주세요