프로니어 | Security is a people problem...
Windows의 경우 시스템에 어떤 장치가 마운트되면 레지스트리에 해당 장치를 GUID 값을 생성하고 후에 이 값을 사용해 장치를 다루게 된다. 마운트된 장치들의 GUID 값은 "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices" 키에 저장된다.
위의 이미지는 마운트된 장치의 GUID를 알아보기 위해 Windows에서 기본적으로 지원하는 레지스트리 편집기(regedit)를 이용하였다. 해당 키의 값으로 볼륨의 GUID 외에 드라이브 문자를 기준으로 한 GUID가 존재하는 것을 확인할 수 있다. 드라이브 문자로 지원하는 것은 현재 또는 가장 최근에 각 드라이브에 마운트되었던 장치의 정보이다.
각 값의 데이터에는 12바이트의 값이나 12바이트 이상의 값들이 존재한다. 12바이트의 값이 존재하는 것은 해당 장치의 MBR이 존재하는 경우이고 나머지는 CD-ROM, USB 저장장치 등을 나타낸다. 12바이트의 문자는 MBR의 정보를 이용해 생성하지만 그보다 긴 값들을 운영체제가 임의로(미지 정의된 형식) 생성한다.
MBR Disk Signatures
위의 그림은 MBR(LBA 0 Sector) 512 바이트의 내용을 보여준다.
처음 446 바이트는 부트 코드(Boot Code)영역으로 ROM BIOS에 의해 POST(Power On Self-Test)과정을 마친 후 실행되는 코드이다. 이 부트 코드의 주 역할은 파티션 테이블에서 부팅 가능한 파티션을 찾아 해당 파티션의 부트 섹터(Boot Sector)를 호출해 주는 역할을 수행한다.
다음으로 이어 나오는 64바이트의 파티션테이블은 해당 볼륨의 파티션정보를 저장한다. 각 파티션은 16바이트로 정보가 표현되기 때문에 총 4개의 파티션 정보가 저장 가능하다. 따라서 기본적으로 한 장치당 주 파티션이 4개 까지만 생성이 가능하다. 더 많은 파티션을 생성하기 위해서는 확장 파티션을 통해 논리 파티션을 생성해야 한다. 하지만 논리 파티션의 경우에는 부팅이 불가능하다. 결국 부팅가능한 파티션은 각 장치당 4개로 제한된다. 이것은 MBR의 설계 당시 정해진 값이기 때문에 만약 이를 극복하고 싶다면 별도의 파티션테이블을 사용할 수 있는 도구들을 사용해야 할 것이다.
그리고 마지막 2바이트는 해당 MBR의 시그니처(Signature)를 나타낸다. 섹터 시그니처라고도 하며 각 파티션의 부트 섹터에도 섹터 마지막 2바이트에 동일한 시그니처가 기록된다. 더 자세한 사항은 파일시스템 관련 서적을 참고하기 바란다. 아니면 조만간 파일시스템에 관해 정리해 포스팅할 예정이기 때문에 그 내용을 참고 바란다.
부트 코드(Boot Code)영역으로 사용하는 446 바이트의 영역의 Offset 440 부터 4바이트가 해당 디스크의 시그니처를 나타낸다. 위 MBR에서 디스크 시그니처는 "1C 20 1C 20" 이다. 따라서 해당 디스크가 마운트될 경우 이 시그니처 값을 사용하여 장치의 GUID를 생성한다. 앞서 삺펴본 레지스트리의 내용을 보면 C, D 드라이브가 해당 시그니처를 사용하고 있음을 알 수 있다. 현재 이 디스크는 파티션이 두개로 나눠져 있다. C:\는 Windows 설치 폴더로 사용 중이며 D:\는 데이터 저장용으로 사용한다.
레지스트리 내용을 자세히 살펴보면 앞의 4바이트는 각 장치의 MBR Disk Signature 값을 사용하는데 뒤의 8바이트는 서로 다른것을 확인할 수 있다. 그렇다면 이 8바이트는 어떻게 생성되는 것일까? 나머지 8바이트는 각 파티션의 시작 위치(바이트)를 나타낸다. MBR 이미지에서 파티션 테이블을 살펴보면 각 파티션의 정보는 16바이트로 구성된다고 언급했다. 해당 16바이트의 내용은 다음과 같다.
여기서 파티션의 시작주소를 나타내는 값은 8-11의 영역인 "Starting LBA Address" 이다. 현재 대부분의 저장매체는 용량의 한계로 CHS 대신 LBA 주소표현방식을 사용한다. 그렇다면 각 파티션 (C or D)의 시작 주소는 다음과 같다. 각 값은 섹터의 위치를 나타낸다. C\의 경우 파티션의 시작이 디스크의 63번째 섹터부터라는 의미이다.
따라서 각 섹터를 바이트로 변환하면 다음과 같다. 4바이트로 주소를 표현하기 때문에 만약 섹터가 아닌 바이트로 주소를 표현했다면 D:\와 같이 용량이 큰 경우 범위를 벗어나게 되어 버리므로 큰 용량을 표현하지 못했을 것이다.
위의 레지스트리의 C\, D\의 GUID 값의 데이터를 살펴보면 MBR Disk Signature 값과 시작 위치를 조합한 것이라는 것을 확인할 수 있다.
디지털포렌식적인 관점에서 이 내용을 살펴보면 MBR이 존재하는 디스크의 경우 사용자가 특별하게 해당 레지스트리 값을 지우지 않는다면 MountedDevice에 GUID 값이 저장된다. 만약 외장하드나 포터블 저장매체의 경우 용의자가 증거 은폐를 의도적으로 감출 수 있다. 따라서 MountedDevice의 정보를 확인하여 가장 최근에 마운트된 장치나 이전에 마운트된 장치의 정보를 기반으로 관련 장치를 요구할 수 있을 것이다.
한편, USB 장치의 경우는 형태에 따라 조금 다른 GUID 형식을 가진다. 일반적으로 USB는 다음과 같이 두가지 형태로 나눠볼 수 있다.
USB Key/Thumbdrive
USB Drive Enclosure
두 장치에 대한 Device GUID 정보가 유사할 것으로 생각하지만 전혀 다르기 때문에 분석할 때 고려해야 한다는 내용이다. USB Drive Enclosure 형태의 드라이브 장치는 논리적으로 IDE, SATA 케이블로 직접 연결한 형태로 BIOS가 해당 드라이브를 인식한다. 따라서 앞서 언급한 것처럼 디스크 시그니처(Disk Signature)를 사용한다. 다음은 USB Drive Enclosure의 Mounted Device GUID를 보여준다.
해당 그림에서 추가적으로 확인할 수 있는 정보는 C:, D: 파티션이 같은 디스크를 사용한다는 점이다. 마찬가지로 E:, F:, I: 파티션도 같은 디스크를 사용한다. 그리고 J: 파티션이 USB Drive Enclosure 형태의 외장하드가 마운트된 정보이다.
그렇다면 USB Key/Thumbdrive가 마운트되었을때에는 어떠한 GUID가 생성될까? 다음은 USB Key/Thumbdrive형태의 장치가 마운트되었을때 Mounted Device GUID를 보여준다.
USB Key에 대한 GUID는 위의 그림에 보이는 데이터외에도 상당히 긴 데이터를 가지고 있다. 해당 데이터의 내용은 다음과 같다.
데이터로으로 앞서 살펴본 Disk Signature와 파티션 시작위치를 더한 12바이트의 값을 가지는 것이 아니라
\??\STORAGE#RemovableMedia#....
형태의 데이터를 가진다. CD-ROM/RW, DVD-ROM/RW 도 이와 비슷한 형태의 값을 가진다.
결국 USB KEY 형태와 USB Drive Enclosure 형태가 남기는 Mounted Device GUID가 다르다. 이는 결국 용의자의 시스템에 마운트되었던 장비에 대해서 수사가 필요할 경우 넘겨받은 장치가 정확한 장치인지, 어떤 형태인지를 판단하는데 활용될 수 있을 것이다.
최근 SANS Computer Forensics에 MBR Disk Signature와 관련된 글이 올라왔다. 부트 영역에 저장되는 Disk Signature에 대한 내용은 알았지만 Windows에서 이 정보를 기반으로 장치의 GUID(Globally Unique Identification Number)를 생성한다는 사실은 약간 놀라웠다.
Windows의 경우 시스템에 어떤 장치가 마운트되면 레지스트리에 해당 장치를 GUID 값을 생성하고 후에 이 값을 사용해 장치를 다루게 된다. 마운트된 장치들의 GUID 값은 "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices" 키에 저장된다.
위의 이미지는 마운트된 장치의 GUID를 알아보기 위해 Windows에서 기본적으로 지원하는 레지스트리 편집기(regedit)를 이용하였다. 해당 키의 값으로 볼륨의 GUID 외에 드라이브 문자를 기준으로 한 GUID가 존재하는 것을 확인할 수 있다. 드라이브 문자로 지원하는 것은 현재 또는 가장 최근에 각 드라이브에 마운트되었던 장치의 정보이다.
각 값의 데이터에는 12바이트의 값이나 12바이트 이상의 값들이 존재한다. 12바이트의 값이 존재하는 것은 해당 장치의 MBR이 존재하는 경우이고 나머지는 CD-ROM, USB 저장장치 등을 나타낸다. 12바이트의 문자는 MBR의 정보를 이용해 생성하지만 그보다 긴 값들을 운영체제가 임의로(미지 정의된 형식) 생성한다.
MBR Disk Signatures
MBR(Master Boot Record)은 저장매체의 LBA 0번 섹터에 존재하는 영역으로 해당 볼륨의 파티션 정보와 각 파티션의 부트 섹터의 부트코드를 실행하기 위한 MBR 부트 코드가 저장된다.
 |
위의 그림은 MBR(LBA 0 Sector) 512 바이트의 내용을 보여준다.
- 0 - 445 : Boot Code
- 446 - 509 : Partition Table
- 510 - 511 : Signature
처음 446 바이트는 부트 코드(Boot Code)영역으로 ROM BIOS에 의해 POST(Power On Self-Test)과정을 마친 후 실행되는 코드이다. 이 부트 코드의 주 역할은 파티션 테이블에서 부팅 가능한 파티션을 찾아 해당 파티션의 부트 섹터(Boot Sector)를 호출해 주는 역할을 수행한다.
다음으로 이어 나오는 64바이트의 파티션테이블은 해당 볼륨의 파티션정보를 저장한다. 각 파티션은 16바이트로 정보가 표현되기 때문에 총 4개의 파티션 정보가 저장 가능하다. 따라서 기본적으로 한 장치당 주 파티션이 4개 까지만 생성이 가능하다. 더 많은 파티션을 생성하기 위해서는 확장 파티션을 통해 논리 파티션을 생성해야 한다. 하지만 논리 파티션의 경우에는 부팅이 불가능하다. 결국 부팅가능한 파티션은 각 장치당 4개로 제한된다. 이것은 MBR의 설계 당시 정해진 값이기 때문에 만약 이를 극복하고 싶다면 별도의 파티션테이블을 사용할 수 있는 도구들을 사용해야 할 것이다.
그리고 마지막 2바이트는 해당 MBR의 시그니처(Signature)를 나타낸다. 섹터 시그니처라고도 하며 각 파티션의 부트 섹터에도 섹터 마지막 2바이트에 동일한 시그니처가 기록된다. 더 자세한 사항은 파일시스템 관련 서적을 참고하기 바란다. 아니면 조만간 파일시스템에 관해 정리해 포스팅할 예정이기 때문에 그 내용을 참고 바란다.
부트 코드(Boot Code)영역으로 사용하는 446 바이트의 영역의 Offset 440 부터 4바이트가 해당 디스크의 시그니처를 나타낸다. 위 MBR에서 디스크 시그니처는 "1C 20 1C 20" 이다. 따라서 해당 디스크가 마운트될 경우 이 시그니처 값을 사용하여 장치의 GUID를 생성한다. 앞서 삺펴본 레지스트리의 내용을 보면 C, D 드라이브가 해당 시그니처를 사용하고 있음을 알 수 있다. 현재 이 디스크는 파티션이 두개로 나눠져 있다. C:\는 Windows 설치 폴더로 사용 중이며 D:\는 데이터 저장용으로 사용한다.
레지스트리 내용을 자세히 살펴보면 앞의 4바이트는 각 장치의 MBR Disk Signature 값을 사용하는데 뒤의 8바이트는 서로 다른것을 확인할 수 있다. 그렇다면 이 8바이트는 어떻게 생성되는 것일까? 나머지 8바이트는 각 파티션의 시작 위치(바이트)를 나타낸다. MBR 이미지에서 파티션 테이블을 살펴보면 각 파티션의 정보는 16바이트로 구성된다고 언급했다. 해당 16바이트의 내용은 다음과 같다.
- 0 - 0 : Bootable Flag
- 1 - 3 : Starting CHS Address
- 4 - 4 : Partition Type
- 5 - 7 : Ending CHS Address
- 8 - 11 : Starting LBA Address
- 12 - 15 : Size in Sectors
여기서 파티션의 시작주소를 나타내는 값은 8-11의 영역인 "Starting LBA Address" 이다. 현재 대부분의 저장매체는 용량의 한계로 CHS 대신 LBA 주소표현방식을 사용한다. 그렇다면 각 파티션 (C or D)의 시작 주소는 다음과 같다. 각 값은 섹터의 위치를 나타낸다. C\의 경우 파티션의 시작이 디스크의 63번째 섹터부터라는 의미이다.
- C:\ : 0x0000003F (63)
- D:\ : 0x075304A1 (122881185)
따라서 각 섹터를 바이트로 변환하면 다음과 같다. 4바이트로 주소를 표현하기 때문에 만약 섹터가 아닌 바이트로 주소를 표현했다면 D:\와 같이 용량이 큰 경우 범위를 벗어나게 되어 버리므로 큰 용량을 표현하지 못했을 것이다.
- C:\ : 0x3F(63) * 0x200(512) = 0x00007E00 (32256)
- D:\ : 0x075304A1(122881185) * 0x200(512) =0x0EA6094200 (62915166720) + 0x00007E00 (32256) = 0x0EA609C000 (62915198976)
위의 레지스트리의 C\, D\의 GUID 값의 데이터를 살펴보면 MBR Disk Signature 값과 시작 위치를 조합한 것이라는 것을 확인할 수 있다.
디지털포렌식적인 관점에서 이 내용을 살펴보면 MBR이 존재하는 디스크의 경우 사용자가 특별하게 해당 레지스트리 값을 지우지 않는다면 MountedDevice에 GUID 값이 저장된다. 만약 외장하드나 포터블 저장매체의 경우 용의자가 증거 은폐를 의도적으로 감출 수 있다. 따라서 MountedDevice의 정보를 확인하여 가장 최근에 마운트된 장치나 이전에 마운트된 장치의 정보를 기반으로 관련 장치를 요구할 수 있을 것이다.
한편, USB 장치의 경우는 형태에 따라 조금 다른 GUID 형식을 가진다. 일반적으로 USB는 다음과 같이 두가지 형태로 나눠볼 수 있다.
 |
USB Key/Thumbdrive
 |
USB Drive Enclosure
두 장치에 대한 Device GUID 정보가 유사할 것으로 생각하지만 전혀 다르기 때문에 분석할 때 고려해야 한다는 내용이다. USB Drive Enclosure 형태의 드라이브 장치는 논리적으로 IDE, SATA 케이블로 직접 연결한 형태로 BIOS가 해당 드라이브를 인식한다. 따라서 앞서 언급한 것처럼 디스크 시그니처(Disk Signature)를 사용한다. 다음은 USB Drive Enclosure의 Mounted Device GUID를 보여준다.
 |
해당 그림에서 추가적으로 확인할 수 있는 정보는 C:, D: 파티션이 같은 디스크를 사용한다는 점이다. 마찬가지로 E:, F:, I: 파티션도 같은 디스크를 사용한다. 그리고 J: 파티션이 USB Drive Enclosure 형태의 외장하드가 마운트된 정보이다.
그렇다면 USB Key/Thumbdrive가 마운트되었을때에는 어떠한 GUID가 생성될까? 다음은 USB Key/Thumbdrive형태의 장치가 마운트되었을때 Mounted Device GUID를 보여준다.
 |
USB Key에 대한 GUID는 위의 그림에 보이는 데이터외에도 상당히 긴 데이터를 가지고 있다. 해당 데이터의 내용은 다음과 같다.
 |
데이터로으로 앞서 살펴본 Disk Signature와 파티션 시작위치를 더한 12바이트의 값을 가지는 것이 아니라
\??\STORAGE#RemovableMedia#....
형태의 데이터를 가진다. CD-ROM/RW, DVD-ROM/RW 도 이와 비슷한 형태의 값을 가진다.
결국 USB KEY 형태와 USB Drive Enclosure 형태가 남기는 Mounted Device GUID가 다르다. 이는 결국 용의자의 시스템에 마운트되었던 장비에 대해서 수사가 필요할 경우 넘겨받은 장치가 정확한 장치인지, 어떤 형태인지를 판단하는데 활용될 수 있을 것이다.
'Storage Forensics' 카테고리의 다른 글
| 컴퓨터 하드웨어 (1) - 기억장치 (0) | 2009/11/16 |
|---|---|
| HPA and DCO (0) | 2009/10/14 |
| Mounted Devices GUID Analysis (2) | 2009/10/09 |
| USB 쓰기 방지 해제 (0) | 2009/10/06 |
| SCSI 이미징 하기 (0) | 2009/08/16 |
| 부팅 절차 (Boot Process) (2) | 2009/07/01 |
댓글을 달아 주세요
MBR에 이런 세밀한 장치 정보까지 보관하고 있는지는 몰랐네요.
2009/09/29 00:14 [ ADDR : EDIT/ DEL : REPLY ]항상 부트 코드 마지막 부분에 0x00 값이 아닌 특정 값이 쓰여지길래 의심하긴 했었는데 이런 정보가 있더군요..
2009/09/29 00:44 [ ADDR : EDIT/ DEL ]