Digital Forensics2019. 10. 17. 23:32
반응형

<DFRWS USA 2019> - 2일차

 

 2019. 7. 15. 

 Session II : Files and Filesystem Forensics (DB 포렌식, 파일시스템 포렌식)

  ◦ 좌 장 : Alex Nelson, Ph.,D. (NIST)

  ◦ 발표 4

     - 주제 : NTFS 클러스터 할당행위 분석을 통한 사용자 데이터 저장위치 탐색 (원제 : Using NTFS Cluster Allocation Behavior to Find the Location of User Data)

     - 발표자 : Martin Karresand (Norwegian Univ. of Science and Technology)

     - 발표내용

       △ 분석해야 할 데이터의 양이 계속하여 증가함에 따라, 디지털포렌식의 우선순위를 설정하기 위한 연구가 필요함

       △ 본 연구는, 분석관이 검색하는 것을 찾을 가능성이 더 높은 디스크 위치를 확인하기 위해, NTFS의 클러스터 할당 알고리즘 동작을 경험적으로 연구함 (VirtubalBox 사용)

       △ 연구결과, 데이터가 디스크의 중앙부에 더 자주 할당되는 것으로 나타남

     - 시사점

       △ NTFS로 포맷된 하드디스크에 대한 디지털포렌식에서 사용자 데이터의 저장위치 예상으로, 우선순위 설정 가능

       △ 샘플링 주파수의 동적 변경으로 해시기반 카빙의 효율성 증가 가능

paper-using_ntfs_cluster_allocation_behavior_to_find_the_location_of_user_data.pdf
0.83MB

반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 17. 00:13
반응형



 3-3-3. 로그파일 수정한 Shell Script 복구하기 (Keyword Searching)

(3-3-2와 같이 Shell Script 파일 중에서 Tool을 사용하여 자동화시켜 찾아낼 수 없는 경우 사용할 수 있는 방법)

 

*. 디스크에서 무작정 '/var/log/messages/'가 들어있는 모든 파일의 앞뒤를 뒤져서 script 로 보이는 부분을 찾아내는 수작업이 필요한 방법이다. 삭제되었어도 디스크상에는 남아있으므로 삭제여부와 상관이 없으며, 시간과 노력이 많이 드는 만큼, 확실한 결과를 보증한다.

 

i. "/var/log/messages"가 조작됐다는 전자 하에(MAC Time 분석 등을 통해 알아낼 수 있음) 모든 이미지 중 해당 text 근처를 찾아보도록 한다. strings를 이용한다.

 

strings *.dd | egrep -B 10 -A 10 '/var/log/messages' > clear_log.txt

// 앞에 10라인 뒤에 10라인 찾아서 clear_log.txt 에 저장

-B 10 : before 10 lines        -A 10 : append 10 lines


ii. clear_log.txt 내용 확인
(각 이미지의 „/var/log/messgaes‟ 들어간 부분의 앞뒤 10줄씩이 모두 저장되어있는 text 파일)



     iii. clear_log.txt
중 로그파일 수정 script 추측되는 부분 확인
           (당연히 script 전체가 아닌 부분만 있다. 앞뒤 10줄만 출력한 것이기 때문이다.)


     iv.
공격코드의 일부가 있는 행의 앞, Line 수를 여러 번 수행해보며 Script 전체를 확인해본다.


      v.
찾은 공격코드


     vi. Keyword Searching
기법을 사용하는 경우 (포렌식 관점) :

로그파일을 생성하거나 수정한 실행 파일을 찾거나(지워진 경우 복구하거나),
환경설정파일을 참조한 실행파일을 찾거나(지워진 경우 복구하거나),
이미 삭제된 루트킷 설치한 script 파일을 복구하거나(설치된 파일들의 이름을 아는 경우에만 가능),
지워진 로그 파일이나 히스토리 파일을 복구하는 등 활용분야가 넓다.


4.
참고문헌

 
      
http://old.honeynet.org/challenge/index.html

      http://www.ibm.com/developerworks/kr/library/au-speakingunix14/index.html

      http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/inode.h.htm

      http://lefoot.egloos.com/tag/inode/page/1

      http://wiki.kldp.org/Translations/html/The_Linux_Kernel-KLDP/tlk9.html

 


반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 16. 02:30
반응형

3-3.  inode 가 남아있지 않는 경우 (Data Carving)

 

위의 3-2처럼 ils icat 가지고 복구할 수 없는 경우가 있다. inode table 자체가 깨진 경우이다. 이에 해당하는 경우에 사용할수 있는 방법이 있다.

바로 carving 기법이다. carving 이란 inode 가 남아있지 않아 복구가 복잡해졌을 때 쓰는 방식으로, 여러가지 기술이 있다.

예를 들자면, 파일의 signature를 통해 파일의 시작점을 찾을 수 있다.  jpeg의 경우 처음이 FF D8이고 끝부분(trailer) FF D9이다. 파일의 끝점까지 찾아서 해당 부분을 dump를 뜨는 것이 가장 완벽한 방법이나, 끝점을 찾는 것은 매우 힘들다. Jpeg과 같이 끝점에도 signature가 있는 경우는 거의 없기 때문이다. 따라서 size 정보 또는 파일의 최대 size를 이용하여 시멘트 카빙을 한 후 유의미한 data만 추출하는 방법을 사용한다.

시멘트 카빙의 경우 data가 연속배열 되어 있지 않으면 유의미한 결과를 얻을 수 없으나, 최근 hdd 용량의 대량화로 대부분 연속배열 되어있기 때문에 유용하게 사용가능하다.

 

이해를 돕기 위해, 직접 file 형태로 된 shell script 를 모두 복구해보는 예제를 들어보겠다. 위에서 실습을 위해 다운로드 받았던 이미지 파일 5(honeypot.hda5.dd )로부터, 로그 파일을 조작한 후 삭제된 shell script를 복구해보겠다.

따라해보며 개념을 익히기 바란다.

 

 

 

3-3-1. Data Carving 시 사용할 Tool 설명


        i. fsstat : Block
사이즈 살펴보기


       ii. sigfind : 디스크 상에서 signature를 포함한 Block을 찾는 툴

<사용법>  sigfind -o (offset) -b (block size) signature image위치

 

eg. sigfind BR 찾기 (BR signature 511, 512 번째에 '55 AA')


     iii. blkcat :
해당 Block Dump 하는 툴

(script 가 한 개 블록임을 가정한다. 넘어가면 짤린다.)

eg. blkcat honeypot.hda5.dd 3698    // 3698Block 스크립트를 보여준다.



iv. sigfind blkcat 툴을 사용하기 위해서는 sleuthkit 을 설치해야한다.

1.    Sleuthkit Tool download 받는다.



 

            2. 압축을 풀어 INSTALL.txt 파일을 열어본다.

 

3.    그대로 따라하며 설치한다.

 



 
3-3-2.
로그파일 수정한 Shell Script 복구하기

(Sleuthkit SIGFIND, BLKCAT Tool을 활용)

 

*. sigfind, blkcat 툴을 사용하여 shell script 파일을 싹 다 복구한 후, 로그파일을 수정한 script만 찾아내보도록 하겠다.

-> 만약 이 방법으로 나오지 않는다면, script 가 파일로 존재 하지 않는 것이므로 keyword searching 을 하는 수밖에 없다.

 

i. 각 이미지의 Block Size를 추출하는 쉘코드 작성 (Sigfind Tool 사용시 Block Size를 알아야 하기 때문)



 

ii. 추출한 fsstatdata Block Size 확인


//   honeypot.hda1.dd Block Size : 1024
      honeypot.hda5.dd Block Size : 4096

      honeypot.hda6.dd Block Size : 4096
     
honeypot.hda7.dd Block Size : 1024
      honeypot.hda8.dd Block Size : 1024 

  

iii. honeypot.hda1.dd 등에 있는 모든 script 파일을 dump

             (sript 파일의 사이즈가 하나의 Block을 넘어가지 않는다고 가정하며,
              Sleuthkit sigfind blkcat Tool을 사용하도록 한다.)


 


 

script 여부 확인 방법 : sigfind를 통해 script 파일의 맨앞 (#!/bin/sh or #!/bin/bash) 4byte 23212f62('#!/b'16진수 변환.)까지를 시그너춰로 보자. (sigfind signature 4 byte까지밖에 못준다.)

c.f) 16진수 변환 방법 : echo '문자' | xxd : 출력 중 0A는 엔터임

 

 

 

iv. 파일 복구 Shell Script 완성본!!

 쉘스크립트 파일이면서 var/log/message (로그파일 저장) 문자열을 포함하는 파일을 추려서 저장하는 기능 추가

<shell script>

#!/bin/sh

 

for i in 1 5 6 7 8            //  honeypot.hda$i.dd 로 파일 다섯개를 한번에 처리하기 위한 i 변수 지정

do

mkdir dumphda$i       //  dump shell script 를 저장할 폴더만들기

fsstat honeypot.hda$i.dd | egrep "Block Size" | awk -F ': ' '(1){print $2}'|\

//  fsstat으로 이미지 파일마다 다른 block size의 확인 후 해당부분 추출 (sigfind에서 써야함)

while read blocksize

//  변수 blocksize fsstat을 통해 추출한 이미지 별 block size 정보 넘김

do

sigfind -b $blocksize 23212f62 honeypot.hda$i.dd | awk -F ' ' '(1){print $2}' |\

while read blocknum

//  sigfind tool signature '#!/b'로 설정하여 찾은 block number 를 변수 blocknum에 넘김

do

blkcat honeypot.hda$i.dd $blocknum >> dumphda$i/$blocknum.txt

//  blkcat tool로 해당 이미지의 script가 위치한 block blocknum.txt dump

if cat dumphda$i/$blocknum.txt | grep '/var/log/message' ;then

cp dumphda$i/$blocknum.txt realhda$i/$blocknum.txt

//  blocknum.txt 파일 중 '/var/log/messages' 내용이 있는 파일을 찾아서 추출

fi

done

done

done

<그림 27. /var/log/message 문자열 포함 Shell Script 추출>

 

v. iv Shell Script 실행 결과 :


         hda5(/usr) 이미지에 일치하는 파일 1개 존재 확인


 
    hda8(/ : root) 이미지에도 일치하는 파일이 1개 확인

 

 

  

vi. 찾은 공격 스크립트 (1 block 에 해당하는 script 만 찾음)

 

반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 15. 22:04
반응형

iii.  삭제된 inode 복구하기

1.   지워진 inode , 한번이라도 쓴 inode 찾기


 
*
복구의 조건 :

· st_alloc(2번째 필드) : data block의 상태를 표시해준다.
                          
f free (사용가능) 이어야 복구 가능

                 c.f) st_alloc a (allocated)인 경우는 inode가 이미 새로운 data 저장을 위해 할당되어있는 상태임을 의미하므로 복구가 불가능하다.

· st_size(11번째 필드) : 0보다 클 것 (data 가 있음을 의미)

· 주의 : 필드는 1번부터 세고, 0은 전체를 나타낸다.



ils
awk로 복구가능한 파일만 보게 조건을 걸고 그런 파일이 나오면 첫번째 필드를 출력하라고 명령을 내린 것이다. 다음과 같은 결과가 나온다.


c.f)
' ' :
쿼팅제한! 필드구분자 -F '|'

 

awk(자동화툴)  : 필드를 처리하는 툴 중 하나다. -F Field Separater를 뜻한다. 여기에서 필드를 구분해주는 것이 |이므로 '|'로 나타낸다. 두번째 필드가 f이고, 11번째 필드의 값이 0보다 커야 하므로 (왜냐하면 virgin inode가 아닌, 한번이라도 쓴 inode를 찾아서 빼기 위해서이다.)

<awk의 사용법>

     awk [옵션] '스크립트' [변수=] [파일()]

    or

  awk [옵션] -f 스크립트 파일 [변수=] [파일()]

 

ils 명령어(숨겨진 데이터를 찾기) : ils는 마운트 되어 있는 디바이스의 inode 정보를 리스트로 만들어주며, 또한 삭제된 inode 정보를 확인할 수 있다.

  <ils 옵션>

  -e : 파일 시스템의 모든 inode 정보를 리스트로 만들어 준다.

-f : 파일시스템 타입을 정의한다. 거의 모든 UNIX 시스템의 기본 파일 시스템은 ffs(Berkeley fast file system)이며, 리눅스는 기본적으로 ext2fs(second extended file system)을 사용하고 있다.

-o : 아직 열려있거나 실행중인 삭제된 파일들의 inode 정보를 만들어준다.(-aL과 동일)

-r : 삭제된 파일들의 inode 정보를 만들어 준다.(-LZ와 동일)

-v : 상세 모드 출력(stderr)

-V : 상세 모드 출력(stdout)



2.   icat 을 사용하여 해당 inode를 파일로 복구하기

 

2-1.  icat honeypot.hda5.dd 2254 > a
        
: 2254 inode a란 파일로 복구



c.f) icat : inode 숫자에 해당되는 내용을 파일로 복사하기 위해서(보통 삭제된 파일의 inode 번호 사용) icat을 사용한다. 여기서 2254는 확인된 삭제된 inode 번호이다.
 

2-2.  icat honeypot.hda5.dd 140839 > 140839
         : 140839 번 inode를 원래의 것으로 복구





                  2-3.
위처럼 inode 번호를 일일이 커맨드에 대입하는 것이 아니라, Shell script를 써서 모든 파일을 복구해보자.


                   2-4.  r을 실행해보자. 실행권한이 없다고 표시될 것이다.


                       2-5.  chmod u+x ./r : r명령의 실행 Permission을 받는다.

 

                       2-6. r 명령을 실행하면 복구가 완료됨을 볼 수 있다.



반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 15. 15:45
반응형

3. 실습 삭제된 파일 복구하기



*. 실습시 사용하는 이미지 다운로드 주소 : http://old.honeynet.org/challenge/images.html

       (challenge-images.tar 압축을 풀어, 다음 이미지를 모두 마운트시킨다.
honeypot.hda1.dd, ~~.hda5.dd, ~~.hda6.dd, ~~..hda7.dd, ~~.hda8.dd )

 

파일을 삭제할 때는 Data는 그대로 두고 inode table에 해당 inode를 안 쓴다는 표시만 한다. (성능상의 이유로 모든 파일시스템이 동일하다.) index block에서 inode와 연결 부분 삭제하는 것이다. 따라서 이를 이용하면, 삭제된 파일의 복구가 가능하다!

 

3-1.  Bitmap 에서 inode 를 사용한다(1) 표시된 경우

-> 해당 inode 를 따라가서 data 덤프하면 파일 복구

 

3-1-1. Bell FS


boot record

super block

inode table

data block

* bitmap super block 위치.

 

3-1-2. EXT3 방식

Cylinder Group 구조 : 앞에 깨지면 뒤의 것을 가져다 복구. 퍼포먼스를 위한 구조이다.

 

3-1-3. EXT2 방식

앞서 “2-4. EXT2 파일시스템 구조 분석에서 다룸



3-2.  Bitmap 에서 inode를 사용하지 않는다(2) 표시된 경우

 

3-2-1. 한 번도 사용하지 않은 inode (Vergin inode) -> 복구할 필요 X
             
사용했다가 지워진 inode -> index를 따라가 해당 data block dump 떠서 복구함

 

3-2-2. 실습을 따라하며 원리를 익혀보자.

i. ls -ali 명령을 통해 inode와 기타 부가정보를 볼 수 있다.

-a : all의 뜻으로 시스템에 숨겨져 일반 사용자에게 나타나지 않는 파일을 포함한 모든 파일과 디렉토리 이름들을 화면에 표준출력

-l : long이라는 뜻으로 파일 및 디렉토리의 표시, 접근(access)에 대한 허가 사항, 링크수, 사용자, 등록명(홈디렉토리) 그리고 파일의 생성 및 최종적으로 수정된 시간과 파일 및 디렉토리 이름을 세부적으로 나열하여 사용자는 보다 더 많은 파일 및 디렉토리에 대한 정보 확인 가능

-i : i-node 번호를 파일 또는 디렉토리 이름 앞에 표준출력

 

  

ii. 삭제된 inode 보기



   이렇게 입력하면 결과화면은 다음과 같이 honeypot.hda5.dd (삭제된 파일이 있는 상태에서 그대로 디스크를 dump한 이미지)에 들어있는 inode들 중 삭제된 inode들을 볼 수 있다.


 

수많은 결과가 나온다. 이 중, 복구 가능한 inode를 선별할 필요가 있다. 다음에서 복구의 조건을 살펴보도록 한다.

 

 

  

c.f) 삭제된inode를 살필 때 사용한, ils 명령어를 살펴보자.

1. ils : ils는 마운트 되어 있는 디바이스의 inode 정보를 리스트로 만들어준다.


2. -r 옵션 : 삭제된 파일들의 inode 정보를 만들어준다.

3. Inode 번호, allocation, size, … 등 여러가지 필드가 있다.

  

반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 15. 15:22
반응형

2-4-5. EXT2 파일 시스템에서 파일 찾기


     리눅스 파일 이름은 다른 유닉스의 파일 이름과 같은 형식으로 되어 있다
. 이름은 앞에 슬래시('/')가 붙은 디렉토리 이름이 이어지고 마지막에 파일 이름이 오는 형태이다. 예를 들어, 파일 이름이 /home/rusling/.cshrc이라면, /home /rusling은 디렉토리 이름이고 파일 이름은 .cshrc이다. 다른 모든 유닉스 시스템과 마찬가지로 리눅스는 파일 이름 자체의 형식은 신경쓰지 않는다. 길이 제한도 없고, 인쇄 가능한 아무런 문자로 구성된다. 이 파일을 나타내는 inode EXT2 파일 시스템 안에서 찾기 위해, 시스템은 파일 이름을 해석해서 한 디렉토리씩 처리하여 파일 자체를 얻게 된다.


     처음 필요한
inode는 파일 시스템의 루트의 inode, inode 숫자값은 파일 시스템의 수퍼 블럭에서 얻는다. EXT2 inode를 읽기 위해서는 해당하는 블럭 그룹의 inode 테이블에서 찾아야 한다. 예를 들어 루트 inode의 번호가 42라면 우리는 블럭 그룹 0 inode 테이블의 42번 째 inode가 필요한 것이다. 루트 inode EXT2 디렉토리를 위한 것이다. 다시 말해서 루트 inode의 모드는 루트 inode가 디렉토리임을 나타내며 데이터 블럭에는 EXT2 디렉토리 엔트리가 들어 있다.


     home
은 여러 디렉토리 엔트리 중의 하나일 뿐 이며 /home 디렉토리를 나타내는 inode의 번호를 알려준다. 이 디렉토리를 읽어서 (디렉토리를 읽으려면 우선 inode를 읽고 그 inode 가 가리키는 데이터 블럭으로부터 디렉토리 엔트리를 읽어야 한다.) rusling 엔트리를 찾으면 그 엔트리는 /home/rusling 디렉토리를 나타내는 inode의 번호를 알려줄 것이다. 마침내 우리는 /home/rusling 디렉토리를 나타내는 inode가 가리키는 디렉토리 엔트리를 읽어서 .cshrc 파일의 inode 번호를 찾은 다음, 이 번호를 이용하여 파일의 내용을 갖고 있는 데이터 블럭을 가져오게 된다.

 

“ /dir/file.txt “ inode를 이용해 찾아가기!

1 루트 디렉토리의 inode 번호는 2 (ext)

2 루트 inode index block을 통해 Dir inode를 알아냄

3 dir inode index block을 통해 file inode를 알아냄

4 file inode index block을 통해 DATA를 찾음!

반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 2. 16:08
반응형

2-4-1. EXT2 inode


EXT2
파일 시스템에서 inode는 가장 기본이 되는 단위이다. 파일 시스템의 모든 파일이나 디렉토리는 각기 단 하나의 inode에 의하여 표현된다. 각 블럭 그룹을 위한 EXT2 inode는 어떤 inode가 할당되었는지 아닌지를 추적하기 위한 비트맵과 함께 inode 테이블에 저장된다. <그림 2. EXT2 inode> EXT2 inode의 형태를 보여준다. 저장되는 정보에는 다음과 같은 항목이 있다.
 

  • 모드(mode) 여기에는 이 inode가 어느 파일에 해당하는지를 나타내는 정보와, 접근권한을 나타내는 정보가 저장된다. EXT2에서 하나의 inode는 하나의 파일, 디렉토리, 심볼릭 링크, 블럭 장치, 문자 장치 또는 FIFO를 나타낸다.
  • 소유자 정보(Owner Information) 이 파일 또는 디렉토리에 대한 사용자와 그룹 식별자이다. 이 정보를 이용하여 파일 시스템은 접근권한을 제대로 관리할 수 있게 된다.
  • 크기(Size) 파일의 크기를 바이트 단위로 가지고 있다.
  • 타임스탬프(Timestamps) inode가 만들어진 시간과 최종적으로 수정된 시간을 기록한다.
  • 데이터블럭(Datablocks) inode가 표현하고 있는 데이터가 저장된 블럭에 대한 포인터. 맨 앞의 열두개의 포인터는 이 inode가 표현하고 있는 데이터를 저장한 실제 블럭에 대한 포인터이며 마지막 세개의 포인터는 점점 더 높은 수준의 간접적인 연결을 갖고 있다. 예를 들어, 이중 간접 블럭 포인터(double indirect block pointer)는 데이터 블럭에 대한 포인 터들의 블럭에 대한 포인터들의 블럭을 가리키고 있다. 따라서, 길이가 12개 데이터 블럭 이하인 파일은 그 보다 큰 파일보다 훨씬 빨리 액세스 된다. Data Block 사이사이에 Directory Block 존재한다. 

EXT2 inode는 특별 장치 파일을 표현할 수도 있다는 점에 주목하여야 한다. 이들 파일은 실제 파일은 아니지만 장치를 액세스하는데 사용되는 프로그램을 다룬다. /dev 디렉토리 아래 의 모든 장치 파일은 프로그램이 리눅스 장치를 액세스할 수 있도록 하기 위하여 거기에 있는 것이다. 예를 들어 마운트 프로그램은 마운트하려는 장치 파일을 인자로 사용한다.



    2-4-2. EXT2
수퍼블럭(Superblock)


    수퍼블럭에는 그 파일 시스템의 정보
(기본적인 크기나 모양에 대한 설명)가 들어 있다. 이를 이용하여 파일 시스템 관리자는 파일 시스템을 활용하고 유지한다. 보통 파일 시스템이 마운트 될 때에는 블럭 그룹 0에 들어 있는 수퍼블럭을 읽어들인다. 하지만, 모든 블럭 그룹에는 똑같은 복사본이 있어서 파일 시스템이 깨지는 경우를 대비하고 있다. 여기에 들어 있는 정보에는 다음과 같은 것들이 있다.
 

  • 매직 넘버(Magic Number) 이 값은 마운트하는 소프트웨어로 하여금 이것이 진짜 EXT2 파일 시스템의 수퍼블럭이라는 것을 확인케한다. 현재 버전의 EXT2에서는 0xEF53으로 되어 있다.
  • 개정 레벨(Revision Level) 메이저 개정 레벨과 마이너 개정 레벨로 구성되며, 마운트 프로그램이 어떤 특정한 버전에서만 지원되는 기능이 이 파일 시스템에서 지원되는지 아닌지를 확인하는데 사용된다. 또한 기능 호환성 항목라는 것이 있어서 마운트 프로그램이 이 파일 시스템에서 안전하게 사용할 수 있는 기능이 무엇인지를 판단할 수 있도록 해준다.
  • 마운트 횟수(Mount Count)와 최대 마운트 횟수(Maximum Mount Count) 이 두 개의 값을 이용하여 시스템은 파일 시스템 전부를 검사할 필요가 있는지를 확인할 수 있다. 마운트 횟수는 파일 시스템이 마운트될 때 마다 1씩 증가하며, 그 값이 최대 마운트 횟수와 같아지면 "최대 마운트 횟수에 도달하였습니다, e2fsck를 실행하는 것이 좋습니다"라는 메시지가 표시된다.
  • 블럭 그룹 번호(Block Group Number) 현재 보고 있는 수퍼블럭 복제본을 갖고 있는 블럭 그룹의 번호.
  • 블럭 크기(Block Size) 이 파일 시스템의 블럭 크기를 바이트 단위로 (예를 들어, 1024 바이 트) 표시한다. 1 I/O 가 이루어지는 양을 의미한다.
  • 그룹당 블럭수(Blocks per Group) 하나의 그룹에 속하는 블럭의 수. 블럭 크기와 마찬가지로 파일 시스템을 만들때 정해진다.
  • 프리 블럭(Free Blocks) 파일 시스템내의 프리 블럭의 수.
  • 프리 Inode(Free Inode) 파일 시스템내의 프리 inode의 수.
  • 첫번째 Inode(First Inode) 파일 시스템내의 첫번째 inode inode 번호. EXT2 루트 파일 시스템에서 첫번째 inode "/" 디렉토리에 대한 디렉토리 엔트리이다.

 

2-4-3 EXT2 그룹 기술자(Group Descriptor)


    각 블럭 그룹은 자신을 기술하는 자료구조를 가지고 있다
. 수퍼블럭과 마찬가지로 모든 블럭 그룹을 위한 그룹 기술자는 각 블럭 그룹에 복제되어 파일 시스템이 파괴되는 경우를 대비한다. 그룹 기술자는 잇달아 나타나서
전체적으로는 하나의 그룹 기술자 테이블을 형성한다. 각 블럭 그룹에는 수퍼블럭 바로 뒤에 그룹 기술자 테이블 전체가 놓여있다. EXT2 파일 시스템 에서 실제로 사용되는 것은 (블럭 그룹 0에 있는) 첫번째 복사본 뿐이다. 다른 복사본들은, 수퍼블럭의 복사본들과 마찬가지로, 원본이 깨질 경우를 대비하고 있다.

 

각 그룹 기술자는 다음과 같은 정보를 갖고 있다.
 

  • 블럭 비트맵(Blocks Bitmap) 이 블럭 그룹에서 블럭의 할당 상태를 나타내는 비트맵으로서 블럭의 수 만큼 있다. 이것은 블럭을 할당하거나 해제할 때 사용된다.
  • Inode 비트맵(Inode Bitmap) 이 블럭 그룹에서 inode의 할당 상태를 나타내는 비트맵으로서 블럭의 수 만큼 있다. 이것은 inode를 할당하거나 해제할 때 사용된다.
  • Inode 테이블(Inode Table) 이 블럭 그룹의 inode 테이블의 시작 블럭으로서 블럭의 수 만큼 있다. inode는 다음에 설명하는 EXT2 inode 자료구조에 의해 표현된다.
  • 프리 블럭 갯수(Free Blocks Count), 프리 Inode 갯수(Free Inode Count), 사용된 디렉토리 갯수(Used Directory Count)

 c.f) 슈퍼 블록과 그룹 디스크립터 테이블은 파일 시스템 전체에 대한 정보가 들어가기 때문에 그룹마다 똑같은 내용을 갖게 된다. (복구 용이)

 



2-4-4. EXT2 디렉토리



    EXT2 파일 시스템에서 디렉토리는 파일 시스템내의 파일에 대한 접근 경로를 만들고 저장 하는 특별한 파일이다. <그림 4. EXT2 디렉토리>는 메모리 상에서의 디렉토리 엔트리의 모양을 보여준다. 디렉토리 파일은 디렉토리 엔트리의 리스트이며 각각의 디렉토리 엔트리는 다음과 같은 정보를 갖고 있다.
 

  • inode 이 디렉토리 엔트리에 해당하는 inode. 이 값은 블럭 그룹의 inode 테이블에 저장되어 있는 inode 배열에 대한 인덱스이다. 그림 9.3 에서 file이라는 이름의 파일에 대한 디 렉토리 엔트리는 i1이라는 번호의 inode를 참조하고 있다.
  • 이름 길이(name length) 이 디렉토리 엔트리의 길이를 바이트로 나타낸다.
  • 이름(name) 이 디렉토리 엔트리의 이름.

 

c.f) 모든 디렉토리에서 처음 두 엔트리는 항상 "." ".." 이다. 이는 각각 "현재 디렉토리" " 부모 디렉토리" 를 의미한다.

반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 2. 16:01
반응형


2-4. EXT2 파일시스템 구조 분석



<그림 3>EXT2 파일 시스템이 블럭 구조로 된 장치에서 블럭을 어떻게 차지하고 있는지 배치 상태를 보여준다. 파일 시스템에 관한 한 블럭 장치는 그저 읽고 쓸 수 있는 일련의 블럭일 뿐이다. 파일 시스템은 실제 매체의 어느 곳에 블럭이 씌어야 하는지에 대해 신경 쓸 필요가 없다. 그것은 디바이스 드라이버가 알아서 할 일이다. 파일 시스템이 그 파일 시스템을 담고 있는 블럭 장치로부터 정보나 데이터를 읽으려고 한다면 단지 해당 디바이스 드라이버에게 몇 개의 블럭을 읽어달라고 요청하기만 하면 된다. EXT2 파일 시스템은 자신이 차지하고 있는 논리적인 파티션을 다시 블럭 그룹으로 쪼갠다. 각 블럭 그룹은 파일 시스템에서 무결성의 핵심이 되는 정보를 중복해서 갖고 있으며, 실제 파일과 디렉토리를 정보와 데이터의 블럭으로 갖고 있다. 이 중복은 파일 시스템이 깨지는 등의 재난이 발생해서 파일 시스템의 복구가 필요할 때 필수적이다.

반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 2. 15:57
반응형

 

 2-3-5. inode 와 파일의 생성, 링크, 삭제 (ext2)

 

i.             파일의 생성
새로운 파일이 만들어지면 그에 해당하는 inode i-list안에 만들어지며, inode inumber 파일 이름이 디렉토리에 등록된다.

 

# df -i : 사용할수 있는 inode의 값이 0이면 아무것도 생성할수 없다.

ii.            파일의 링크
이미 존재하고 있는 파일을 링크시킬 경우는 디렉토리에 그 파일에 대한 새로운 이름이 등록되고, inumber는 본래 있던 파일의 inumber가 복사된다. 이 때 복사되는 파일의 inode에서 파일의 링크수는 하나 증가하게 된다
.

iii.          파일의 삭제
파일을 삭제하면 그 파일에 대한 inode의 파일 링크수가 하나 감소되고 디렉토리 entry에서는 해당 파일의 inumber zero로 변한다. inode의 파일링크수가 zero가 되면 파일의 디스크 블록은 free가 되며 inode dellocate 된다.

 

è  따라서 inode에 담긴 정보가 손상되지 않았다면, 파일은 사용 가능하다. , 삭제된 파일이 복구가능한 것이다. ext2에서는 파일을 삭제 해도 inode는 파일 내용의 데이터블록들의 주소를 가지고 있으므로 새로운 파일이 삭제된 파일 위에 덮어 씌어지지 않는다면, 복구 가능하다.

 

 2-3-6. 해당 파일의 "inode"는 어떻게 찾는가

바로 "Directory Block"을 이용하는 것이다. 이 디렉토리 블럭은 데이터 영역에 존재한다. inode가 메타데이터 영역에서 데이터 영역으로의 포인터 정보를 담고 있다면, Directory Block은 반대로 데이터 영역에서 메타데이터 영역으로의 포인터 정보를 담고 있다. Directory Block데이터 영역은 형식이 정해져 있으며, Directory 밑에 있는 파일에 대한 inode 숫자가 담겨 있다.

c.f) EXT 파일시스템에서는 2 inode가 루트 디렉토리를 연결시켜 주다.


반응형
Posted by CCIBOMB
Digital Forensics/Linux2010. 3. 2. 15:43
반응형

 2-3-3. 유닉스 시스템(ext2)에서 inode를 이용한 File Addressing 

- Direct Addressing, Indirect Addressing -


유닉스에서 디스크는 일정한 크기의 블록으로 나누어져 있으며
,
각 파일이 디스크의 공간에 할당될 때도 정해진 크기의 블록으로 할당되어 사용된다. inode는 파일의 구성 블럭에 대한 물리적 위치가 포함되어 있다. 블록들의 물리적 위치를 기록하기 위하여 직접 어드레싱(Direct Addsressing) 및 간접 어드레싱(Indirect Addressing) 사용 되고 있다.

inode에 있는 블록위치에 대한 정보는 13개의 필드로 되어 있다. 필드 0부터 필드 9까지는 직접 블록을 어드레싱하는 부분이다. , 각 필드 내에 있는 내용은 디스크의 주소를 포함한다. 처음 10개의 블록은 이러한 방식으로 어드레싱 되며, 유닉스 내에 있는 파일의 크기는 대부분 작기 때문에 10개의 블록으로도 충분하지만, 방대한 파일인 경우에는 필드 10(Indirect Bolocks), 11(Double Indirect) 또는 12(Triple Indirect) 사용된다. 각각은 1, 2, 3차 간접 어드레싱 방법을 사용하게 된다. 필드 10은 실제의 어드레스가 있는 블록의 어드레스 즉, 주소의 주소를 가지고 있으며 어드레스 수를 통산 256개의 주소를 기록할 수 있다그러므로 필드 10은 실제주소가 있는 곳을 가리키고, 필드 11은 이중간접어드레스 필드를, 12는 삼중 어드레스를 각각 저장하고 있다. 이러한 방법에 의해 어떠한 크기의 파일이라도 유닉스에서 모두 다루어 질 수 있다.

 


 
2-3-4. inode
와 파일 크기, 파일 개수

inode의 크기는 64byte이며, 파일은 블럭들로 구성되어 있다.

한 블록의 크기가 1K이고 블록의 주소가 4바이트로 표현 가능하다면 한 블록은 256개의 블록 주소를 포함한다. 따라서 inode Indirect, Double Indirect, Triple Indirect Addressing 을 이용하면, 16 gigabyte 크기의 파일까지 표현 가능하다.


1K 블록을 표현할 수 있는 10개의 direct 블록(10K)
  256
개의 direct 블록을 가리키는 1개의 indirect 블록
(256K)
  256
개의 indirect 블록을 가리키는 1개의 double indirect 블록
(64M)
  256
개의 double indirect 블록을 가리키는 1개의 triple indirect 블록  

(16G = 1K * 256 * 256 * 256)

c.f) inode의 파일 크기 필드가 32비트인 경우 실제 파일 크기는 4 gigabytes로 제한된다.(2^32)

따라서 파일 시스템에서 “inode의 개수 = 파일의 개수라고 볼 수 있다.
    (inode table
size 는 파일 시스템 생성시 설정 가능하다.)

 

반응형
Posted by CCIBOMB