wintersnowaAa
ext4 file system - Block Group (I-node Entry Extent 영역) 본문
ext4 첫번째 포스팅에서 I-node table에서 Extent 영역 설명에 이 포스팅 링크 걸어놓기!
Extent Tree 구조 (논리적 구조) 와 Extent 영역
(index node까지)
일단 Extent tree 구조는 ext4부터 사용되었다.
이유는 기존에 ext2, ext3에서 사용하던 비트맵 구조는 블록들을 하나씩 개별적으로 번호를 매겨 관리하는 방법이였는데,
이에 대한 효율이 떨어져서 NTFS의 클러스터런 구조처럼 블록들을 연속적으로 묶어서 관리하는 방법인 Extent tree 구조를 채택하게 되었다.


구조를 봐도 제대로 이해하기가 힘드니까 Extent 영역의 값들을 분석해서 어떻게 사용되는지 확인해서 구조 분석을 진행해보자.
아 근데 구조를 공부하다가 모르는게 있어서 현우한테 또 물어봐서 정답 찾음.
일단 extents 구조에서는 depth 라는 깊이를 쓰는데
예를 들어서 A라는 Inode Entry가 있는데 이 Entry의 header에 있는 depth 값이 0일때 leaf 노드이고
그 위로는 B라는 index node(interbal node) 가 여러 개 이어져 있는 구조이다.
Ext4 Disk Layout - Ext4
From Ext4 OBSOLETE CONTENT This wiki has been archived and the content is no longer updated. For latest ext4 documentation, see Kernel Docs. This document attempts to describe the on-disk format for ext4 filesystems. The same general ideas should apply to
archive.kernel.org

Extent Tree 구조를 사용하는 경우에는 Inode Entry의 flag 값이 0x80000으로 설정되어있어야한다고한다.

실제로 Journal 에 대한 Inode Entry 부분을 보면 Flag 값이 0x80000 으로 설정되어 Extent 구조를 사용한다는 것을 알 수 있다.

이제 Extent 영역을 분석해보자.

내용을 봐보면 inode.i_block 은 위의 Inode Entry 구조에서 Extent 영역과 동일한 영역을 갖고 있고
Extent 영역은 inode.i_block 이라는 구조체로 이루어진 내부 변수 값들을 담은 영역이다.
(근데 만약 ext4가 아니라 ext2,3 이라면 inode.i_block 영역은 직접, 간접 블록 주소 지정 영역으로 사용된다 이건 https://archive.kernel.org/oldwiki/ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout.html#The_Contents_of_inode.i_block 를 활용해서 확인해보면 어디서부터 어디까지 해당 오프셋이 블록 지정 주소값을 가지는지 알 수 있다 현재는 ext4를 기준으로 포스팅 할 것 이다)

내 컴퓨터의 Extent (inode.i_block) 영역의 값들을 정리해보자.
일단 첫번째로 extent header 부분이다.

| 필드 이름 | 설명 | 실제 디스크 값 (일부는 리틀엔디안 -> 빅엔디안으로 변환한 값) |
| eh_magic | 매직넘버(시그니처 넘버) | 0xF30A (Extent를 사용한다면 이 값으로 무조건 시작) |
| eh_entries | 헤더 이후의 유효한 (extent or index) entry 개수 | 0x1 |
| eh_max | 헤더 이후로 나올 수 있는 최대 entry 개수 | 0x4 |
| eh_depth | 해당 extent node 깊이 | 0x1 |
| eh_generation | ext4 에서는 사용되지 않는 영역 | 0x0 |
header 부분 이후에는 extent entry 노드가 들어오게 된다.
해당 extent entry는 Index node(Internal node) 이다.

| 필드 이름 | 설명 | 실제 디스크 값 (일부는 리틀엔디안 -> 빅엔디안으로 변환한 값) |
| ei_block | 인덱스 노드의 시작 블록 번호 (논리적 블록) | 0x0 |
| ei_leaf_lo | 자식 노드가 저장된 디스크 블록 번호 (물리적 블록) | 0x7FF7FFF |
| ei_leaf_hi | 자식 노드가 저장된 디스크 블록 번호 (물리적 블록) | |
| eh_unused | 사용되지 않는 영역 | 0x0 |
이후 또한 마찬가지로 Index node가 extent entry로가 들어온다.
근데 뭔가 이상하다.
이후의 나타나는 Extent Entry 영역은 구조가 뭔가 다르다.

이 영역은 실제로 쓰이지 않는 영역이므로 이러한 값을 가지게 된데에는 가능성이 몇가지 있다.
1. 이전에 쓰던 노드의 값이다 (하지만 Journal 에 대한 8번 Inode Entry 이므로 이 가능성은 낮다.)
2. ext4 파일시스템에서 자동적으로 공간을 사용하기 위해 준비해놓은 예비 할당 영역이다.
(사실 이게 제일 가능성이 크다.)
2번의 경우라고 하더라도 다시 2가지의 경우의 수가 나뉜다.
2-1. index node(internal node) 형태의 예비 할당 영역
2-2. leaf node 형태의 예비 할당 영역
일단 가장 마지막의 2바이트가 0x2108로 나타나므로 마지막 2바이트 영역을 아예 사용하지 않는 index node는 아닐듯하다.
그럼 leaf node 라고 가정하고 구조 분석을 해보자.
(어차피 leaf node의 구조도 알아보긴 해야하긴함.)
| 필드 이름 | 설명 | 실제 디스크 값 (일부는 리틀엔디안 -> 빅엔디안으로 변환한 값) |
| ee_block | leaf node의 논리적 블록 시작 번호 | 0x8000 |
| ee_len | 블록의 갯수 | 0x8000 |
| ee_start_hi | leaf node의 물리적 블록 시작 번호 (high) | 0x8202000 |
| ee_start_lo | leaf node의 물리적 블록 시작 번호 (low) |
이것만으로는 잘 모르겠으니까 아래의 3번째와 4번째 extent entry들도 분석해보면

| 필드 이름 | 설명 | 실제 디스크 값 (일부는 리틀엔디안 -> 빅엔디안으로 변환한 값) |
| ee_block | leaf node의 논리적 블록 시작 번호 | 0x10000 |
| ee_len | 블록의 갯수 | 0x8000 |
| ee_start_hi | leaf node의 물리적 블록 시작 번호 (high) | 0x820A000 |
| ee_start_lo | leaf node의 물리적 블록 시작 번호 (low) |

| 필드 이름 | 설명 | 실제 디스크 값 (일부는 리틀엔디안 -> 빅엔디안으로 변환한 값) |
| ee_block | leaf node의 논리적 블록 시작 번호 | 0x18000 |
| ee_len | 블록의 갯수 | 0x8000 |
| ee_start_hi | leaf node의 물리적 블록 시작 번호 (high) | 0x8212000 |
| ee_start_lo | leaf node의 물리적 블록 시작 번호 (low) |
나름대로의 패턴이 보인다.
| 2번째 extent entry | 3번째 extent entry | 4번째 extent entry | |
| ee_block | 0x8000 | 0x10000 | 0x18000 |
| ee_len | 0x8000 | 0x8000 | 0x8000 |
| ee_start_hi | 0x8202000 | 0x820A000 | 0x8212000 |
| ee_start_lo |
ee_block 값들은 0x8000 단위로 배수로 늘어난다.
ee_len은 0x8000으로 일정하고,
ee_start_hi + ee_start_lo 는 마찬가지로 0x8000 단위로 늘어난다.
2번째 extent entry
3번째 extent entry
4번째 extent entry
이 3개의 extent entry들은 논리적, 물리적으로도 연속적인 구조를 갖는다.
정말 확정적으로 확인하기 위해서는 이 노드가 어느 오프셋을 가리키는지 확인해서 그곳에 leaf node가 있는지, 아니면 그 외의 내용이 있는지 확인해보면된다.
일단 2번째 extent entry의 물리 블록 시작 번호는 0x8202000 이니까
https://wintersnowaaa.tistory.com/64
ext4 file system - Block Group (Super Block, GDT , Block & I-node Bitmap, I-node Table)
한동안 공부를 안했다.어떻게든 다시 열심히해야하지....몇가지 ext2, ext3, ext4 에서 사용하는 구조들을 알아보자.※ 이후에 포스팅 해야할거 Journal이랑 Data 블록!1. Block Group (Super block)더보기파티
wintersnowaaa.tistory.com
이전 포스팅 super block에서 block 사이즈는 4096임을 알았으니까
FTK Imager에서 그냥 클러스터 단위로 세어서 오프셋을 이동해보도록 하겠다.

뭔가...익숙하다
0x100을 기준으로 반복되는 구조...
이건 I-node Table의 I-node Table의 구조와 매우 유사하다.
자세히보면 0x20~0x27 부분인 flag 값도 0x80000으로 해당 노드가 extent를 사용한다는 값을 명시한다.
근데 또 이상한건 마지막 접근 시각은 2023년 11월 23일로 계산되는데 내 gram pro는 2024년 1월에 공개된 노트북이다...
생산을 하고 운영체제를 설치해놓고 거기에 ubuntu를 microsoft store에서 설치해놓고 2달 뒤에 제품 공개를 한다고...?
보통 그런가...?
i-node mode 값도 리틀엔디안으로 기록되었다고하면 0x81a4 인데

일반 파일에 소유자에게 rw 권한,
그룹에게 r 권한
그 외에게 r 권한
근데 leaf node라고 가정하고 일단 찾아온건데...
leaf node가 가리키는 영역이 또 다른 I-node Table 영역이라고...? 이건 뭐지...?
그리고 암만 extent entry 구조를 봐도 leaf node가 무조건 맞다.
일단...넘어가서
3번째 Extent Entry를 보면

이건 반복되는 규칙을 가진 구조가 아니다.
패키지 설치 관련 파일로 보이는데 뭐지...?
네번째도 봐보자.

여긴 또 0x0 으로 채워져있다.
결론을 내기엔 조금 이르지만, 내가 보기에는 할당되었었지만, 현재는 비할당으로 전환되어 끊긴 노드로 보인다.
물론 이에 대한 확신은 아직 아는게 없는 나로서는 혼자서 불가능하기 때문에 정말 고수이신 멘토분께 물어봐야할듯하다...
아 여기서 포스팅이 끝나면 안되는거였는데
인덱스 노드를 통해서 리프노드까지 가서 리프노드 구조까지 이야기해야했다...
leaf node
물론 위에 있는 2,3,4번째 extent entry들을 leaf node로 가정하고 분석해보긴했지만,
확정적으로 leaf node 라고는 이야기할 수 없어서
확실하게 index node인 1번째 extent entry를 통해서 leaf node 오프셋으로 옮겨서 내용을 확인해볼 것 이다.

1번째 extent entry가 가리킨 곳이고 여긴 아마도 depth 값이 0일 것이다.
빠르게 정리해보자.
어 근데 신기하게도 난 당연히 I-node Entry가 있을 줄 알았는데,
해당 오프셋의 시작부터 0x0AF3으로 extent header 매직넘버가 보인다.
그 말은 즉슨 그냥 편하게 처음부터 extent 영역이 나온다고 보면 될듯하다.

header
| 필드 이름 | 설명 | 실제 디스크 값 (일부는 리틀엔디안 -> 빅엔디안으로 변환) |
| eh_magic | 매직넘버(시그니처 넘버) | 0xF30A |
| eh_entries | 헤더 이후의 유효한 entry 개수 | 0x8 |
| eh_max | 헤더 이후 나올 수 있는 최대 entry 개수 | 0x154 |
| eh_depth | 해당 extent node 깊이 | 0x0 |
| eh_generation | ext4 에서는 사용되지 않는 영역 | 0x0 |
어라 entry의 개수가 굉장히 많다.
최대 entry 개수도 엄청나게 많다.
몰랐는데 extent 영역은 고정적이지 않았다..
가변적이였다.
extent entry들이 늘어나면 그만큼 늘어날 수 있다.
고정적으로 0x3B가 아니였다.
실제로 봐보면

8개의 entry들이 존재하는 것을 볼 수 있다.
첫번째 entry만 먼저 분석해보자.
| 필드 이름 | 설명 | 실제 디스크 값 (일부는 리틀엔디안 -> 빅엔디안으로 변환한 값) |
| ee_block | leaf node의 논리적 블록 시작 번호 | 0x0 |
| ee_len | 블록의 갯수 | 0x800 |
| ee_start_hi | leaf node의 물리적 블록 시작 번호 (high) | 0x7FF8000 |
| ee_start_lo | leaf node의 물리적 블록 시작 번호 (low) |
0x7FF8000 블록으로 가볼까?

이건 뭘까싶긴한데
흐름상 이건 저널쪽의 데이터이여야한다.


journal 영역이 맞다.
여기까지만 일단 해야겠다 추후에 journal 부분은 따로 포스팅해서 여기에 링크 걸어두기!
출처
https://blog.naver.com/jalhaja0/221536636378
Ext4에 포함된 Extents Tree 레이아웃
익스텐트 ext3 파일 시스템은 논리적 블록에서 디스크 블록으로 일대일 매핑을 제공하는 간접 블록 매핑 체...
blog.naver.com
https://archive.kernel.org/oldwiki/ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout.html#Inode_Table
Ext4 Disk Layout - Ext4
From Ext4 OBSOLETE CONTENT This wiki has been archived and the content is no longer updated. For latest ext4 documentation, see Kernel Docs. This document attempts to describe the on-disk format for ext4 filesystems. The same general ideas should apply to
archive.kernel.org
[Digital Forensic] Android Ext4 File System Structure Analysis
Ext4Ext4(Extended File System): 리눅스 기반 시스템에서 널리 사용되는 파일 시스템으로, 주로 안드로이드의 파일 시스템으로 사용된다. 안드로이드는 리눅스 커널을 기반으로 하기 때문에,
digitalforensicmaster.tistory.com
https://ddongwon.tistory.com/66
ext4 파일 시스템_1 (기본 구조)
0. ext 파일 시스템 각각의 운영체제들을 저마다 파일들을 관리하는 파일 시스템을 채택하고 있다. 대표적으로 윈도우는 NTFS를, 맥 os는 APFS를 사용한다. 리눅스의 경우 ext 파일시스템을 사용한다.
ddongwon.tistory.com
'포렌식 통합' 카테고리의 다른 글
| Portable Executable - PE Header (0) | 2025.07.01 |
|---|---|
| ext4 file system - Block Group (Journal) (0) | 2025.06.26 |
| ext4 file system - Block Group (Super Block, GDT , Block & I-node Bitmap, I-node Table) (1) | 2025.06.07 |
| 이벤트 로그 (참고) [지속수정] (1) | 2024.11.16 |
| 참고문헌 및 파일 (지속 수정) (1) | 2024.10.23 |
