컴퓨터를 사용하면서 자주 접하는 파티션 시스템은 도스 형식의 파티션 시스템이다.
도스 파티션은 인텔 IA32 하드웨어(i386/x86) 에서 사용해 왔지만 공식적인 명세서는 없다.
Microsoft 는 이런 파티션 시스템을 MBR(Master Boot Record) 디스크라고 부른다.
도스 파티션은 도스, 윈도우, 리눅스 IA32 기반 FreeBSD와 OpenBSD 시스템에서 사용된다.
흔한 시스템이지만 의외로 복잡한 구성을 가지고 있다.
그 이유는 확장 파티션 개념인데 조금 뒤에 알아 볼 개념이다.
도스 파티션을 사용하는 Disk는 512Byte 섹터 내의 MBR을 갖고 있다.
MBR은 아래와 같은 정보를 가지고 있다.
1. 부트코드 : 파티션 테이블 처리 명령어와 운영체제 위치 파악 명령어 포함
2. 파티션 테이블
- 파티션 시작의 CHS 주소
- 파티션 마지막의 CHS 주소
- 파티션 시작의 LBA 주소
- 파티션 섹터 수
- 파티션 타입
- 플래그
3. 시그니처
파티션 테이블의 각 엔트리는 파티션의 레이아웃을 설명하는데 쓰인다.
CHS(Cylinder, Head, Sector)는 8GB 이하 디스크에서만 사용가능 하며, LBA는 TB(Terabyte) 크기의 디스크까지 사용가능 하다.
파티션 타입은 파일시스템을 나타내는 것으로 NTFS, FAT, FreeBSD 등이 있다.
운영체제들은 운영체제 별로 파티션 타입을 달리 하는데 리눅스는 파티션을 마운트(Mount) 할 때에 파티션 타입을 참조하지 않아 NTFS 파티션 타입이어도 리눅스 파티션 타입인 FAT으로 파티션을 마운트 한다.
이와 달리 윈도우의 경우 파티션 타입을 참조하여 NTFS 타입이 아니면 마운트 하지 못한다.
이와 같은 방법으로 파티션을 숨길 수 있는 방법이 있다.
간단히 방법을 설명하자면, 파티션 타입에 1비트를 변조하여 윈도우에서 파티션을 인식 못하게 하는 것이다.
플래그는 파티션 부팅여부를 나타내는 항목이며, 컴퓨터가 부팅할 때 운영체제가 어떤 파티션에 위치하고 있는지 구분할 때 사용 된다.
MBR은 4개의 파티션만 표현 할 수 있으며 4개의 엔트리를 이용해 파티션들이 할당 된 디스크 구조를 표현 할 수 있다.
하지만 사용자에 따라 4개 이상의 파티션이 필요할 때가 있다. 이러한 경우를 위해 확장 파티션 개념이 생겼다.
확장 파티션 개념은 3개의 파티션은 기본적인 파티션으로 두고 나머지 1개의 파티션을 주 확장 파티션으로 만들고 그 안에 또 다른 파티션들을 만드는 것이다.
예를 들어 12GB의 디스크에 6개의 파티션을 구성하려고 하면 확장 파티션 개념으로 해야 할 것이다.
아래 그림은 위 예를 표현한 것이다.
부 파티션 앞에 있는 MBR 들은 그림 1과 같은 방법으로 모두 부 파티션과 부 확장 파티션의 정보를 갖게 된다.
근데 꼭 위 이미지와 같이 "부 파티션1, 부 확장 파티션1" 로 나누고 또 밑으로 나누는 것은 왜 그런 것일까?
"부 파티션 1,2"를 만들고 "부 확장 파티션 1"을 만들어도 되지 않을까?
하지만 부 파티션 1,2를 만들고 부 확장 파티션 1을 만들게 되며 대부분의 OS에서는 세번째 파티션을 무시하게 되 "부 확장 파티션1" 이 인식이 되지 않는다.(크기를 잘못 인식하는 경우도 발생)
확장 파티션에는 파티션 테이블 엔트리에서 사용되는 특별한 타입들이 있는데 위와 같이 복잡한 구조가 된 것은 확장 파티션 타입이 여러가지 종류가 있고 파티션 사이를 구분하기 어렵기 때문이다.
* 참고 : 확장 파티션 일반적인 타입으로는 "도스 확장", "Windows 95 확장", "리눅스 확장" 이 있다.
부트코드에 대해서 설명 할 차례이다. 부트코드는 MBR 섹터 내에 1~446 바이트에 존재하며, 그 나머지는 파티션 테이블 엔트리이다.
부트코드는 MBR 파티션 테이블을 처리한 후 부팅 플래그가 있는 파티션을 찾고 부팅 가능한 파티션의 첫번째 섹터를 찾은 후 운영체제 코드를 실행 시킨다.
이 영역에 바이러스가 침투하면 OS 부팅 시 바이러스도 함께 OS 부팅시 매번 실행되는 것이다.
또 부트코드를 수정하면 OS 멀티 부팅이 가능하다.
도스 파티션은 인텔 IA32 하드웨어(i386/x86) 에서 사용해 왔지만 공식적인 명세서는 없다.
Microsoft 는 이런 파티션 시스템을 MBR(Master Boot Record) 디스크라고 부른다.
도스 파티션은 도스, 윈도우, 리눅스 IA32 기반 FreeBSD와 OpenBSD 시스템에서 사용된다.
흔한 시스템이지만 의외로 복잡한 구성을 가지고 있다.
그 이유는 확장 파티션 개념인데 조금 뒤에 알아 볼 개념이다.
도스 파티션을 사용하는 Disk는 512Byte 섹터 내의 MBR을 갖고 있다.
MBR은 아래와 같은 정보를 가지고 있다.
1. 부트코드 : 파티션 테이블 처리 명령어와 운영체제 위치 파악 명령어 포함
2. 파티션 테이블
- 파티션 시작의 CHS 주소
- 파티션 마지막의 CHS 주소
- 파티션 시작의 LBA 주소
- 파티션 섹터 수
- 파티션 타입
- 플래그
3. 시그니처
파티션 테이블의 각 엔트리는 파티션의 레이아웃을 설명하는데 쓰인다.
CHS(Cylinder, Head, Sector)는 8GB 이하 디스크에서만 사용가능 하며, LBA는 TB(Terabyte) 크기의 디스크까지 사용가능 하다.
파티션 타입은 파일시스템을 나타내는 것으로 NTFS, FAT, FreeBSD 등이 있다.
운영체제들은 운영체제 별로 파티션 타입을 달리 하는데 리눅스는 파티션을 마운트(Mount) 할 때에 파티션 타입을 참조하지 않아 NTFS 파티션 타입이어도 리눅스 파티션 타입인 FAT으로 파티션을 마운트 한다.
이와 달리 윈도우의 경우 파티션 타입을 참조하여 NTFS 타입이 아니면 마운트 하지 못한다.
이와 같은 방법으로 파티션을 숨길 수 있는 방법이 있다.
간단히 방법을 설명하자면, 파티션 타입에 1비트를 변조하여 윈도우에서 파티션을 인식 못하게 하는 것이다.
플래그는 파티션 부팅여부를 나타내는 항목이며, 컴퓨터가 부팅할 때 운영체제가 어떤 파티션에 위치하고 있는지 구분할 때 사용 된다.
MBR은 4개의 파티션만 표현 할 수 있으며 4개의 엔트리를 이용해 파티션들이 할당 된 디스크 구조를 표현 할 수 있다.
하지만 사용자에 따라 4개 이상의 파티션이 필요할 때가 있다. 이러한 경우를 위해 확장 파티션 개념이 생겼다.
[그림 1 - 기본 확장 파티션 구조]
확장 파티션 개념은 3개의 파티션은 기본적인 파티션으로 두고 나머지 1개의 파티션을 주 확장 파티션으로 만들고 그 안에 또 다른 파티션들을 만드는 것이다.
예를 들어 12GB의 디스크에 6개의 파티션을 구성하려고 하면 확장 파티션 개념으로 해야 할 것이다.
아래 그림은 위 예를 표현한 것이다.
[그림 2 - 예문 확장 파티션]
부 파티션 앞에 있는 MBR 들은 그림 1과 같은 방법으로 모두 부 파티션과 부 확장 파티션의 정보를 갖게 된다.
근데 꼭 위 이미지와 같이 "부 파티션1, 부 확장 파티션1" 로 나누고 또 밑으로 나누는 것은 왜 그런 것일까?
"부 파티션 1,2"를 만들고 "부 확장 파티션 1"을 만들어도 되지 않을까?
하지만 부 파티션 1,2를 만들고 부 확장 파티션 1을 만들게 되며 대부분의 OS에서는 세번째 파티션을 무시하게 되 "부 확장 파티션1" 이 인식이 되지 않는다.(크기를 잘못 인식하는 경우도 발생)
확장 파티션에는 파티션 테이블 엔트리에서 사용되는 특별한 타입들이 있는데 위와 같이 복잡한 구조가 된 것은 확장 파티션 타입이 여러가지 종류가 있고 파티션 사이를 구분하기 어렵기 때문이다.
* 참고 : 확장 파티션 일반적인 타입으로는 "도스 확장", "Windows 95 확장", "리눅스 확장" 이 있다.
부트코드에 대해서 설명 할 차례이다. 부트코드는 MBR 섹터 내에 1~446 바이트에 존재하며, 그 나머지는 파티션 테이블 엔트리이다.
부트코드는 MBR 파티션 테이블을 처리한 후 부팅 플래그가 있는 파티션을 찾고 부팅 가능한 파티션의 첫번째 섹터를 찾은 후 운영체제 코드를 실행 시킨다.
이 영역에 바이러스가 침투하면 OS 부팅 시 바이러스도 함께 OS 부팅시 매번 실행되는 것이다.
또 부트코드를 수정하면 OS 멀티 부팅이 가능하다.
'[+] Forensic' 카테고리의 다른 글
File System - Partition (3) (0) | 2012.01.19 |
---|---|
File System - Partition (2) (0) | 2012.01.18 |
File System - Volume (2) (0) | 2012.01.17 |
File System - Volume (1) (0) | 2012.01.17 |