ilovechoonsik
[CTF-d] 복구 된 키 이미지 파일의... (R-Studio, MBR-VBR 구조 약간 매운맛) 본문
[CTF-d] 복구 된 키 이미지 파일의... (R-Studio, MBR-VBR 구조 약간 매운맛)
춘시기좋아 2022. 3. 18. 23:36풀이 핵심 : NTFS FILE System, MBR-VBR Structure, Extended Partition knowledge
사용 도구 : FTK Imager, HxD, R-Studio
key point : 목표 - 파티션 복구 https://wrkk.tistory.com/38
1. MBR - 파티션 정보 얻기, 찾기
2. VBR - 찾은 파티션들의 VBR로 이동 후 백업 VBR 조사
3. 정상 VBR 정보 MBR에 입력
받은 파일은 디스크 이미지 파일!
저장장치 첫 섹터에 위치하는 MBR의 시그니처를 확인할 수 있다
우선 복구 된 키 이미지 파일의 복구가 목표인 문제이기 때문에
삭제 된 파티션 존재하는지 확인해야 한다!
R-Studio를 통해 확인한 결과 DeletedPart1, 2 삭제 된 파티션이 2개 존재하는 거 확인!
각각
Part1 = 15MB
Part2 = 50MB
의 용량을 가지고 있다
FTK Imager로 확인 시 삭제 된 파티션 중 15MB 용량의 파티션만 존재
저 50MB의 파티션에 뭐가 들어 있는지, 왜 FTK Imager에는 나타나지 않는지 조사해 보자
어 근데 일단 R-Studio에서 DeletedPart2 라는 50MB의 삭제 된 파티션 안에
k3y2013.jpg라는 문제에서 복구하라는 key가 들어 있었구, 요 친구를 복구하면 될 거 같은데
Aㅏ........
R-Studio demo버전은 최대 256KB 크기까지의 파일만 복구 가능하도록 설정되어 있다..
다른 방법을 사용하여 복구해야 함! 음...
1. FTK Imager를 통한 복구
2. 현질...
현질은 무리고 FTK Imager를 통해 복구해보자!
우선 받은 디스크 이미지 파일을 분석하기 전에 관련 내용을 공부, 정리해야 함!
<저장장치 구조 및 MBR>
https://weekhack.tistory.com/43
저장장치의 구조 & MBR
안녕하세요. Luke입니다. 최근 진로를 디지털 포렌식 분야로 변경한 후 디지털 포렌식을 열심히 공부하고 있는데요. 배운 내용에 대해 정리할 겸 저장장치의 구조와 그중 일부인 MBR에 대해 글을
weekhack.tistory.com
<좀 더 상세한 버전 (여기 완전 좋음)>
https://blog.forensicresearch.kr/11
MBR(Master Boot Record) Partition Structure Analysis
이번에 분석 해볼 파일은 물리적인 저장 장치에서 확인 할 수 있는 영역인 MBR 파티션 영역 입니다. 최근에는 HDD 라고 불리는 하드디스크 뿐만 아니라 솔리드 스테이트 드라이브 라고 불리는 SSD
blog.forensicresearch.kr
문제에서 준 디스크 파일 evidence.001 분석!
1. 우선 MBR 영역의 구조가 어떻게 나뉘는 지 알아야 한다!
이번에 분석 해볼 파일은 물리적인 저장 장치에서 확인 할 수 있는 영역인 MBR 파티션 영역 입니다.
최근에는 HDD 라고 불리는 하드디스크 뿐만 아니라 솔리드 스테이트 드라이브 라고 불리는 SSD 가 생겨났습니다.
SSD의 등장에 따라서 디스크의 용량이 증가 함에 따라서 MBR의 한계점이 생기게 되었습니다.
그래서 MBR이 다룰수 있는 용량의 제한으로 인해서 MBR 대신 GPT(GUID Partition Table) 라고 불리는 영역이 생기게 되었습니다.
요건 다음에 알아보구
MBR은 Master Boot Record 의 약자로 저장매체의 첫번째 섹터인(0번섹터)에 위치하는 512바이트 크기의 영역입니다.
저장장치의 구조를 한번 살펴 보면 아래와 같은 구조를 띄고 있습니다.
Abstract Sturcture of Storage System
앞에서 말했다 싶이 MBR 이라고 불리는 영역은 저장 장치 에서 0섹터에 위치해 있습니다.
MBR은 모든 저장 장치의 가장 처음에 존재하는 구조로 최근에는 MBR의 단점을 보완한 GPT 가 사용됩니다.
MBR Slack 영역은 MBR과 VBR의 사이에 있는 영역으로 낭비 되는 공간 입니다.
해당 영역에 부트킷, 랜섬 웨어와 같은 악성코드가 악용되는 공간 이기도 하면서, 보안 솔루션으로 사용되는 공간이기도 합니다.
윈도우 XP/2K3 는 VBR의 위치가 63섹터 라고 이야기를 하고 윈도우 Vista/7/8의 VBR의 위치가 2048 섹터라고 이야기 합니다.
좀더 정확한 VBR의 위치는 뒤에서 다뤄볼 MBR의 파티션 테이블에 적혀있는 hex 값을 확인 하는 것이 정확합니다.
VBR 영역은 볼륨의 시작에 위치하는 구조로 VBR에는 해당 볼륨의 파일 시스템의 메타 데이터(BPB)가 있고, 부트로더 로딩 코드를 담고 있습니다.
볼륨의 부트로더를 로딩해서 운영체제를 부팅시키는 코드를 VBR 이라고 합니다.
Volume Data 영역은 파일 시스템에 의해서 할당 된 볼륨의 데이터가 들어있는 공간으로 메타 데이터와 파일의 데이터로 구성되어 있습니다.
Volume Data 영역의 상세한 내용은 각 파일시스템 분석 자료를 읽어보시는 것을 추천 드립니다.
이제 MBR의 구조를 한번 알아 보겠습니다.
MBR은 저장장치의 첫번째 섹터 512바이트 크기의 영역을 이야기 합니다.
OK?
HxD에서 어디서 부터 어디까지가 어떤 영역인지 감이 안 올수 있는데 그럼
블록 선택으로 나눠서 확인하면 쉽게 알 수 있당
2. 자 이제 각 영역들이 어떻게 구성되어 있는지 알아보자
1. MBR Boot Code <0x00 - 0x1BD>
MBR Boot Code는 부팅시에 POST 과정 이후에 저장매체에 존재하는 첫번째 섹터를 호출 하게 되는데 그때 호출된 섹터에 존재하는 내용입니다.
운영체제를 부팅하기 위해서 진행하는 부팅과정을 간단하게 나타내면 아래와 같습니다.
BIOS -> Pre POST -> POST(Power On Self Test) -> MBR 읽어오기 -> VBR 읽어오기 의 과정으로 운영체제가 부팅이 됩니다.
저장장치 에서 첫번 째 섹터인 MBR은 자신의 부트 코드를 수행합니다.
부트 코드는 다음과 같은 작업을 합니다.
- MBR 파티션 테이블에서 부팅 가능한 파티션을 찾기
- 부팅 가능한 파티션을 찾았을 경우 해당 파티션 테이블에 적혀있는 VBR의 위치로 이동
- 부팅 가능한 파티션이 없을 경우, 오류 메시지를 출력
오류의 메시지는 부트 코드 아래 부분(0x163 ~ 0x1B1)에 적혀 있습니다.
Invalid partition table , Error loading operating system , Missing operating system
부트 코드를 확인해 보면 아래와 같습니다.
위의 부트 코드에서 중요하게 봐야 하는 내용은 아래와 같습니다.
0x1B5 ~ 0x1B7 은 Error Message Offset을 의미합니다.
0x1B8 ~ 0x1BB 는 Device GUID(MBR Device Signature)를 의미합니다.
Device GUID는 레지스트리 키에서도 확인 할 수 있습니다.
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices 하위에서 확인 할 수 있습니다.
위의 hex 데이터는 현재 D드라이브에 마운트가 된 디스크인데 위의 레지스트리 키를 보면 D드라이브에 마운트 되어있는 디스크의 GUID 값을 확인해 보면 F4 F5 0F 22 를 띄고 있는 것을 확인 할 수 있습니다.
나머지 00 00 10 00 00 00 00 00 값은 각 파티션의 시작 섹터의 위치를 의미합니다.
파티션 테이블 엔트리가 총 4개 까지 보유 할 수 있기 때문에 부팅 가능한 주 파티션은 4개 까지 생성이 가능합니다.
따라서 멀티 부팅할 경우에 4개의 운영체제를 설치 할 수 있습니다.
하지만 주 파티션이 아닌 데이터 저장을 위한 논리 파티션은 4개 이상 생성 하는 것이 가능합니다.
2. MBR Partition Table <0x1BE - 0x1FD>
MBR 파티션 테이블 영역
MBR 파티션 영역은 MBR의 446바이트 부터 시작되며
파티션 용량, 부팅가능 여부, 파티션 시작 위치 등 현재 해당 디스크의 파티션에 대한 정보를 담고 있습니다.
※ 파티션 테이블 오프셋 구조
0-0 Boot Flag : 0x00은 부팅 불가능, 0x80은 부팅 가능 의미
1-3 Starting CHS Addr : CHS(Cylinder, Head, Sector) 주소 지정 방식 (시작 위치 정보)
4-4 Partition Type : 해당 파티션 파일 시스템 타입 (0x07은 NTFS, 0x0B는 FAT32를 의미)
5-7 Ending CHS Addr : CHS 주소 지정 방식 (끝 위치 정보)
8-11 Starting LBA Addr : LBA 주소 지정 방식 (파티션 시작 위치)
12-15 Size in Sector : 해당 파티션 총 섹터 개수
이제 직접 분석해보자
첫 번째 파티션 테이블
00 : 부팅 불가능
02 03 00 : 0x000302 해당 파티션의 시작 Offset (CHS)
07 : Partition Type - 07이면 NTFS
D4 11 03 : 0x0311D4 해당 파티션의 끝 Offset (CHS)
80 00 00 00 : 0x00000080 파티션 시작 Offset (LBA) >> 128 Sector
00 F0 00 00 : 0x0000F000 총 섹터 개수
해당 파티션이 시작하는 128 Sector로 이동해보자
실제로 이동을 해보면? 해당 파티션의 MFT이 존재하는 거 확인할 수 있다~
두 번째 파티션 테이블
00 : 부팅 불가능
D4 12 03 : 0x0312D4 해당 파티션의 시작 Offset (CHS)
01 : Partition Type - 07이면 NTFS
1B 16 05 : 0x05161B 해당 파티션의 끝 Offset (CHS)
80 F0 00 00 : 0x0000F080 파티션 시작 Offset (LBA) >> 61,568 섹털 31,522,816 byte
00 50 00 00 : 0x00005000 총 섹터 개수 >> 20,480
그럼 요 친구의 VBR은? 파티션 시작 Offset + 총 섹터 개수 = 82,048 섹털 42,008,576 byte
세 번째 파티션 테이블
00 : 부팅 불가능
04 3E 07 : 0x073E04 해당 파티션의 시작 Offset (CHS)
05 : Partition Type - 확장 파티션
FE 3F 0F : 0x0F3FFE 해당 파티션의 끝 Offset (CHS)
80 B8 01 00 : 0x0001B880 파티션 시작 Offset (LBA) >> 112,768 Sector > 57,737,216 byte
00 48 02 00 : 0x00024800 총 섹터 개수 149,504 Sector >
https://yum-history.tistory.com/256
https://kkamagistory.tistory.com/781
03.22 일단 요기까지 한 거 정리!
MBR VBR 구조를 통해 파티션을 복구해야 하는 상황!
FTK Imager에는
총 3개의 정상 파티션과 1개의 FTK Imager에서 자동으로 복구시킨? 파티션이 존재! - MBR에 Offset정보가 정확하지 않지만? 파티션의 내용은 살아있어 FTK Imager가 자동으로 복구 시킨 거 같음! 15MB
근데 우리가 복구하고 싶은 건 50MB짜리 파티션!
보면 FTK Imager에서와 다르게 파티션이 3개 존재하는 데 이유는 이제 알아봐야 함! 뭐가 뭔지 알고 싶음
파티션 Type으로 대충 추정 가능하지만 파티션 크기로 비교를 해 봐야 정확히 알 수 있을 듯!
07 NTFS
01 FAT
05 Extended Partition
이렇게 3개네 일단
여기서 확장 파티션의 개념이 명확하지 않기 때문에 지금 헸갈리는 거 같은데 정확히 분석해보자
근데?
112,768 Sector > 57,737,216 byte 요기에 VBR이 없구
NTFS VBR 시그니처로 검색해보면
112,896 Sector > 57,802,752 byte 요기에 있는 걸 확인할 수 있다!
따라서 추정할 수 있는 상황은 네 번째 파티션 테이블을 지워 놓은 걸 알 수 있다
1. 부트코드
부트코드 영역
부트코드는 말 그대로 부팅을 하기 위한 코드입니다. 파티션 중 부팅이 가능한 파티션을 찾아 해당 파티션의 부트섹터로 넘겨주는 일을 합니다. 부팅 가능한 파티션을 찾지 못해 에러가 발생될 경우에는,
부트코드 영역의 에러 메시지
위 그림과 같은 부트코드 영역에 기록된 에러 메시지를 출력하게 됩니다.
부트코드 영역에서 다시 한번 잘 살펴봐야 할 부분이 하나 더 있습니다. 바로 <0x1B8-0x1BB>에 위치한 저장장치의 고유 ID가 담긴 GUID입니다.
저장장치의 GUID
위의 DC 34 82 B8 은 해당 저장장치 고유의 ID인 GUID(Globally Unique ID)이다. 이는 윈도우의 레지스트리
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
에서 확인할 수 있습니다.
삽입되었던 저장장치는 위의 그림과 같이 레지스트리에 GUID가 남습니다. 예를 들어 D드라이브와 E드라이브의 경우 제가 예전에 삽입했었던 USB입니다. 이를 통해 특정 USB가 삽입되었는지의 여부를 확인할 수 있습니다.
아까의 GUID값이었던 dc 34 82 b8과 일치한다는 것을 알 수 있습니다. GUID 다음 8바이트는 각 파티션의 시작 섹터 위치입니다.
FTK Imager는 파티션 보여줄 때 vbr table을 기반으로 Link시켜 보여주는 건가?
그래서 안 나온건가 뭐지
Disk Forensic #30 (복구 된 키 이미지 파일의...)
디스크 포렌식 30번 문제
해당 문제 파일을 다운 받아서 FTK Imager 도구를 통해 확인해보면 특이한 점은 존재하지 않는다.
FTK Imager : 포렌식의 가장 기본 도구로, 디스크 이미징 작업에 많이 활용
다운로드 사이트 : https://accessdata.com/product-download/ftk-imager-version-4-2-1
FTK Imager version 4.2.1
AccessData provides digital forensics software solutions for law enforcement and government agencies, including the Forensic Toolkit (FTK) Product.
accessdata.com
그래서 혹시나 삭제된 파티션이 존재하는지 확인을 위해 R-Studio 프로그램을 통해서 문제 이미지 파일을 열어 확인해 보자.
R-Studio : 하드디스크 파티션 파일 복구 프로그램
참조 사이트 : https://www.r-studio.com/
Disk Recovery Software and Hard Drive Recovery tool for Windows, Mac, and Linux
Empowered by the new unique data recovery technologies, R-STUDIO is the most comprehensive data recovery solution for recovery files from NTFS, NTFS5, ReFS, FAT12/16/32, exFAT, HFS/HFS+ and APFS (Macintosh), Little and Big Endian variants of UFS1/UFS2 (Fre
www.r-studio.com
[그림 1] R-Studio -> 이미지 파일 오픈
문제 파일을 열어 실행시킨 다음, 각 파티션 내용을 보면 Empty Space19에서 [마우스 우클릭] - [Scan] 기능을 사용하여 Recognized0과 Recognized1이 생성되는 것을 확인할 수 있다. (그림 1 참고)
FTK Imager로 확인했을 때는 다른 용량의 파티션이 있음을 알 수 있으므로 Recognized1이 50MB의 용량으로 의심스러운 점을 확인할 수 있다.
[그림 2] 파티션 정보
의도적으로 삭제된 파티션이 있을 거란 추측을 해볼 수 있으며, MBR을 분석해보자.
MBR영역은 부트 코드와 파티션 테이블, 시그니처(AA 55)로 나뉘게 된다.
문제에서 주어진 evidence.001 파일을 HxD로 열어보면 파티션 테이블 영역에 총 3개의 파티션 정보가 있음을 확인할 수 있다.
[그림 3] 3개 파티션 정보 확인
위 [그림 2]에서는 보이는 파티션 정보가 4개이지만 [그림 3]에서는 파티션 테이블에 파티션이 3개만 존재하는 것을 확인할 수 있다.
또한 한 개의 파티션 정보가 확장 파티션임을 확인할 수 있다. (타입 오프셋 : 0x05)
그리고 [그림 2]의 FTK Imager에서 마지막 파티션이 Recovered로 나오는 점으로 보아 파티션에 대한 오프셋 정보만 삭제 되어 자동으로 복구가 되어 보여주는 것 같다.
하지만 R-Studio를 통해 확인했던 50MB 파티션 정보는 아니므로 추가적 분석을 진행해야 한다.
50MB의 삭제된 파티션 정보를 찾기 위해서 NTFS VBR 시그니처 (EB 52 90 4E 54 46 53)로 검색하여 분석해보면 다음과 같이 파티션 테이블에 있는 3개의 파티션 외에 112896 섹터에 파티션이 있음을 확인할 수 있다.
[그림 4] 112896 섹터
이렇게 해서 파티션 테이블에서 112896 섹터에 해당하는 파티션 정보를 의도적으로 삭제했음을 알 수 있다.
해당 파티션 정보를 파티션 테이블에 입력한 다음, 복구를 통해 문제를 해결할 수 있을 것 같다.
복구하기 이전 MBR 파티션 테이블 오프셋 구조와 NTFS BR 오프셋 구조를 파악해야 한다.
※ 파티션 테이블 오프셋 구조
0-0 : Boot Flag로 0x00은 부팅 불가능, 0x80은 부팅 가능 의미
1-3 : CHS(Cylinder, Head, Sector) 주소 지정 방식 (시작 위치 정보)
4-4 : 해당 파티션 파일 시스템 타입 (0x07은 NTFS, 0x0B는 FAT32를 의미)
5-7 : CHS 주소 지정 방식 (끝 위치 정보)
8-11 : LBA 주소 지정 방식 (파티션 시작 위치)
12-15 : 해당 파티션 총 섹터 개수
현재의 하드디스크는 LBA 주소 지정 방식을 취하고 있으므로 CHS 주소 지정 방식 내용을 제외하고는 복구를 진행할 수 있다.
112896 섹터의 VBR 정보를 분석하여 파일 시스템 타입은 NTFS(0x07)임을 확인할 수 있으며, 8-11 오프셋에 해당하는 LBA 주소 지정 방식 파티션 시작 위치는 112896 섹터임을 알 수 잇다.
112896 섹터를 파티션 테이블에 입력할 때는 16진수로 변환한 다음, 리틀 엔디안 방식으로 입력해야 한다.
112896은 16진수로 0x1B900이다.
따라서 12-15 오프셋에 해당하는 파티션의 총 섹터 개수는 NTFS BR 오프셋 구조를 통해 확인할 수 있다.
[그림 5] NTFS BR 구조
오프셋 구조 중에서 Total Sector 영역이 파티션 상의 총 섹터 개수를 의미한다.
NTFS는 파티션 정보의 마지막 섹터에 BR 백업본이 존재한다.
BR 백업본 섹터까지 포함하여 Total Sector + 1값을 파티션 테이블 12-15 오프셋에 입력한다.
[그림 6] Total Sector 영역
위 [그림 6]에서 표시한 부분이 112896 섹터 NTFS BR의 Total Sector 영역이다.
Total Sector는 0x18FFF이며 +1을 해주게 되면 0x19000이다.
지금까지 파티션 테이블에 입력할 정보를 리틀 엔디안 방식으로 정리하면 다음과 같다.
| 내용 | 오프셋 |
| 부팅 정보 | 80 |
| CHS 시작 주소 | 00 00 00 |
| 파티션 타입 | 07 |
| CHS 마지막 주소 | 00 00 00 |
| BR 시작 주소 | 00 B9 01 00 |
| 총 섹터 개수 | 00 90 01 00 |
문제 파일을 HxD로 열어 위 표의 내용을 4번째 파티션 테이블 정보에 입력해보자.
[그림 7] 정보 입력
위 [그림 7]과 같이 수정한 다음 FTK Imager로 문제 파일을 다시 열어보면 Partition 4가 새로 생성된 것을 확인할 수 있다.
[그림 8] 복구된 파티션 4
파티션 4에는 NTFS 볼륨이 있으며, 하위 root 폴더에는 문제와 관련 있어 보이는 JPG 파일이 존재한다.
이제 FTK Imager에서 [마우스 우클릭] - [Export Files...] 메뉴를 통해 해당 파일 을 추출하여 내용을 확인해보자.
[그림 9] JPG 파일 내용
내용을 확인해보면 문제에서 언급한 KEY 이미지를 확인할 수 있다.
이제 해당 파일의 MD5 Hash 값을 계산하여 플래그로 입력해주면 된다.
MD5 Hash 값 계산을 위해 HashCalc라는 도구를 이용하여 계산해보자.
HashCalc : 다양한 해시값 추출 프로그램으로, 파일 무결성 검사 도구
설치 사이트 : https://www.slavasoft.com/hashcalc/
SlavaSoft HashCalc - Hash, CRC, and HMAC Calculator
SlavaSoft HashCalc HASH, CRC, AND HMAC CALCULATOR HashCalc 2.02 FREE A fast and easy-to-use calculator that allows to compute message digests, checksums and HMACs for files, as well as for text and hex strings. It offers a choice of 13 of the most popu
www.slavasoft.com
[그림 10] HashCalc 실행 > 플래그 확인
HashCalc를 통해 해당 파일에 대한 MD5 Hash 값을 얻을 수 있으며, 플래그로 입력해주면 된다.
해당 문제는 다른 방법으로 $MFT 구조를 분석하여 $DATA 영역에서 실제 파일이 저장된 주소를 얻어 수동으로 파일을 카빙하여 답을 얻을 수도 있다.
이렇게 해서 위 과정을 통해 문제를 해결할 수 있다.
NTFS 구조, MBR, VBR, MFT Entry 위치 찾는 방법
Disk Forensic 이론 #3 - NTFS 구조
Startup 디스크 포렌식 이론 #3 - NTFS (구조) 1) NTFS 및 MFT Entry 구조 이해 - NTFS 기본 구조 - 위 구조는 MBR -> VBR -> MFT Entry -> Root Cluster 위치 가. MBR - MBR의 위치는 이미지 0번 섹터에서 확..
wrkk.tistory.com
'Digital Forensic - CTF 🚩 > [CTF-d] Disk' 카테고리의 다른 글
| [CTF-d] Find Key(ELF) (Volatility) (0) | 2022.03.08 |
|---|---|
| [CTF-d] 범죄자는 자신의 인생을 (foremost, dd OR HxD 자르기) (0) | 2022.03.08 |
| [CTF-d] Please get my key back! (Firmware-mod-kit) (0) | 2022.03.07 |
| [CTF-d] 데이터센터 중 하나가 정보의 (Thumsdb) (0) | 2022.03.06 |
| [CTF-d] 경찰청은 최근 아동 성폭력 (BEncode Editor(Torrent)) (0) | 2022.03.06 |