[문제풀이] DMA Forensics FS_Day1_Warming_Up

안녕하세요 Franklin 입니다.

오늘은 DMA Team 의 FS-Day1_Warming_Up 문제를 풀어보도록 하겠습니다.

우선 ppt 에 담긴 슬라이드에 문제 내용이 있으므로 아래 링크로 이동하여 ppt 와 vmdk 파일을 다운로드 받아 문제를 풀 준비를 마쳐 주시면 되겠습니다.

http://eniac-security.tistory.com/83

이후 VMware 에 vmdk 를 적재시켜 운영체제에 문제를 풀기 위한 준비를 완료 하시면 됩니다.

1. 분석 운영체제 선택에 관해

OS 의 경우 개인 취향에 따라 리눅스, 윈도우 등.. 을 선택할 수 있지만 본 포스팅에서는 Windows XP SP3 기준으로 작성됩니다. 또한 팁이라고 한다면 Windows Vista 이후 하드디스크에 직접 관여하는 프로세스 때문에 HxD 같은 저장장치에 직접 쓰기로 관여하는 프로그램들은 저장 시도시 엑세스 거부가 되는 경우가 있습니다. 따라서 실제 직접쓰기를 가능케 하려면 MBR 영역에서 Partition Type 부분을 0x00 혹은 다른 값으로 변경하여 파티션 자체가 인식되지 않도록 한 뒤 작접을 진행해야하는 번거로움이 존재합니다. 그러나 Windows XP 의 경우 직접쓰기를 방해하는 프로세스가 없으므로 자유롭게 분석이 가능하다는 장점이 있어 분석에 용이하므로 본 포스팅에서는 Windows XP SP3 기준으로 작성하게 되었습니다.

2. 준비 단계

아래 <Picture 1-1> 과 같이 필자의 OS 는 Windows XP 이며 SP3 가 설치되어 있습니다. 웬만한 소프트웨어는 Windows XP 에서는 대부분 작동 하므로(혹은 XP 버전의 구버전 소프트웨어를 따로 지원) 분석에는 큰 무리가 없습니다.

<Picture 1-1. System Properties>

그리고 vmdk 파일을 VMware 에 적재하여 아래와 같은 화면을 볼 수 있도록 합니다. 필자의 경우 다른 디스크들과 혼동하지 않기 위해 따로 문제풀이 폴더를 만들어 문제 풀이용 vmdk 파일들을 한곳에 모아 두었습니다. 단순히 일회성 디스크라면 저렇게 하지 않아도 상관은 없지만 장기적으로 정리하며 사용할 디스크라면 아래와 같이 하는것을 권장합니다.

<Picture 1-2. Virtual Machine Settings>

디스크는 IDE 연결 방식으로 연결 하였으며 어차피 XP 라서 SATA 라고 해도 별 의미가 없습니다. 직접쓰기 방식이라 재부팅도 해야하는 상황이라 필자는 디폴트로 잡혀있는 IDE 를 선택 하였습니다.

3. 분석 시작

<Warming Up 문제 내용>

분석을 하기 위해 주로 사용할 툴은 HxD 라는 직접쓰기 툴 입니다. 물론 WinHex 라는 툴이 있으신분은 해당 툴 혹은 다른 툴을 사용 하셔도 상관 없으나 본 포스팅 기준은 HxD 로 하도록 하겠습니다. 딱히 다른 툴로 바뀐다고 해서 문제는 없겠지만 편의상 필자와 같은 툴을 사용 하시는것을 권장해 드립니다. 아래 링크로 이동하시어 HxD Editor 를 다운로드 받으실 수 있습니다. HxD Download: https://mh-nexus.de/en/hxd/

다운로드 받고 설치한 크고 아름다운 HxD 를 실행합니다. 참고로 Windows Vista 이후의 버전 Windows 들은 당연 관리자 권한으로 실행 시켜야겠죠? 그러나 저희는 XP 이기 때문에 그냥 실행 시켜주도록 합니다. 그럼 아래 <Picture 2-1> 과 같은 HxD 화면을 볼 수 있습니다.

<Picture 2-1. HxD main page>

이처럼 제대로 작동하는 HxD 를 확인 후 실질적으로 분석해야 하는 디스크에 대한 정보가 없으니 해당 정보를 얻으러 가보도록 하겠습니다. 디스크 정보는 가장 쉬운 방법인 "내컴퓨터" 로 이동하여 1차적으로 확인 작업을 거칩니다. 이는 Windows 에서 디스크를 정상적으로 인식하거나 불안정하게 인식해도 디스크의 존재 여부를 확인할 수 있는 가장 쉬운 방법이기도 합니다. "내컴퓨터" 로 이동하여 내용을 확인하도록 합니다.

<Picture 2-2. My Computer>

그런데, 디스크가 C: 밖엔 없네요. 어찌된 일인지는 모르겠으나 디스크 전체가 인식이 안되는 모양 입니다. 분명 디스크를 인식 시켰음에도 불구하고 위와 같은 상황이 벌어진다면 제 경험상 99% MBR 쪽 문제 입니다. MBR 에서는 Partition Table 영역만 살짝 바꿔주어도 해당 파티션 전체를 인식할 수 없습니다. 실제로 그러한지 좀더 자세히 알아보기 위해 관리 도구인 "diskmgmt.msc" 로 이동 하도록 하겠습니다. 이동 방법은 Win + R 후 실행(Run)창이 뜨면 diskmgmt.msc 를 입력 해 주시면 됩니다. 아래 <Picture 2-3> 을 참고 하시길 바랍니다.

<Picture 2-3. Run diskmgmt>

위와 같이 입력 후 엔터를 누르시게되면 아래의 디스크 관리도구(DIsk management)를 확인하실 수 있습니다.

<Picture 2-4. Disk Management>

오, 그래도 물리 디스크로 정상적인 인식은 되었네요. 그러나 파티션이 아예 인식이 불가능한 상태인것 같습니다. 이제부터 문제의 시작인것 같군요. 조금 스크롤을 위로 올리셔서 문제 내용을 다시 확인해 보시면 첫번째 문제는 총 파티션의 개수를 묻고 있습니다. 이는 HxD 를 이용하여 MBR 영역만 확인하면 바로 답을 알 수 있겠네요. 이제 아까 켜두었던 HxD 를 이용해 봅시다. 아래의 HxD 를 보시면 좌측 상단쪽에 CD, Floppy, HDD가 함께 있는 아래와 같은 아이콘을 확인하실 수 있습니다.

<Picture 2-5. HxD Disk Open>

그럼 "디스크 열기" 라는 팝업이 하나 뜰텐데, 거기서 저희는 HDD 전체를 분석해야 하기에 물리 디스크쪽에 가셔서 "하드 디스크2" 를 선택 하도록 합니다. 여기서 왜 하드 디스크2를 선택하냐고 묻는 분들이 간혹 계시는데요 상식적으로 생각해 봤을때 OS 를 설치하는 가장 첫번째 디스크를 넘버링으로 부여할때 1번으로 주지 2번으로 주지는 않습니다. 따라서 오름차순임을 알 수 있습니다. 이를 이용하거나 아님 "나는 정확한게 좋아" 라고 하시는 분들의 경우 둘다 열어봅니다. 그리고 실제 Windows 가 올라가 있는 디스크와 내가 현재 꼽은 문제 Disk 와 비교 하시면서 보시면 어떤게 내가 분석해야할 곳인지 쉽게 판가름 할 수 있습니다. (물론 여기까지 하실 분들은 거의 없겠지만..) 여튼 선택 후 저희는 HDD 를 편집&저장 해야 하기 때문에 당연 읽기 전용 체크를 풀어야 합니다. 체크를 풀고 "수락" 버튼을 눌러 분석 디스크를 열어주도록 합시다.

<Picture 2-6. 하드 디스크2 MBR>

정상적으로 열렸다면 위 화면을 바로 보실 수 있을 겁니다. ppt 파일을 제대로 보고 공부하신 분이라면 본 화면이 MBR 화면임을 쉽게 알 수 있을 겁니다. 그러나 앞으로의 원활한 진행을 위해 한번 더 설명 하고 가도록 하겠습니다. 아래 그림을 참고 하시길 바랍니다.

<Picture 2-7. MBR Analyz>

사진 한장으로 MBR 에 대한 설명이 모두 가능하지만 풀어서 적어보도록 하겠습니다. 우선 기계어로 작성되어있는 Boot Code 영역은 모두 446Bytes 입니다. 이 부분은 저희가 따로 분석할 영역이 아니므로 일단 패스 하도록 하겠습니다. 저희가 중요시 보아야 할 점은 아래의 Partition Table 영역과 Signature 부분 입니다. Partition Table 영역은 총 64Bytes 로 구성 되어 있으며, 한 파티션 당 16Bytes 를 이용하게 됩니다. 따라서 64/16=4 라는 결론을 얻을 수 있습니다. 이는 즉, MBR 에서 직접 로드 가능한 파티션이 최대 4개임을 의미하며 이는 곧 Disk Management 부분에서 Primary Partition(주 파티션)과 Extended Partition(확장 파티션)을 나누는 중요한 기준이 됩니다. 다시 한번 생각하면 한 하드 디스크에서 아무리 용량이 많고 뭐 이렇고 저렇고 한다고 해도 MBR 에서 로드가 가능한 파티션이 최대 4개에 불과하기 때문에 Windows 와 같은 OS 를 직접 로드할 수 있는 파티션이 4개, 다시 말해 한번에 멀티부트가 가능한 운영체제의 수가 4개 라는것 입니다. 이 Partition Table 영역을 확인하면 해당 저장 장치에 몇개의 파티션이 있는지 가늠할 수 있습니다. 포렌식은 하나의 정보만으로 결론짓지 않습니다. 앞뒤 정보를 맞춰가면서 맞다 아니다를 판단 하는것이죠. Partition Table 영역을 날려놓은 저장장치가 파티션이 아예 없다는 보장이 없는것 처럼요. 여튼 Partition Table 영역을 통해 파티션이 몇개 있는지 가늠할 수 있습니다. 이후 Signature 영역을 통해 0xAA55 임을 확인할 수 있습니다.

<Picture 2-8. Partition Table Analyz>

이해를 돕기 위해 하단에 있는 파티션 테이블을 중앙으로 끌어 올렸습니다. 파티션 테이블 내용을 보시면 빨간색으로 그어놓은 분기점 위는 어떤 데이터가 많이 있는 반면 아래 부분은 시그니처 부분을 제외한 다른 영역은 모두 0x00 으로 비어 있음을 확인할 수 있습니다. 따라서 윗쪽 내용만 확인 해보면 대략 파티션이 2개 존재 하는것을 예측할 수 있습니다.

<Picture 2-9. Partition Table>

실제로 문제 디스크의 파티션 테이블 영역을 분석해 보도록 하겠습니다. 우선 첫번째 파티션의 경우 파티션 타입이 0x00 으로 훼손되어 있으며 LBA Addr 는 0x3F 로써 63번 Sector 를 가리키고 있습니다. Size in Sector 값은 0xA0120E 로써 약 5GB 로 용량 측정이 가능 했습니다. 그럼 실제 63번 섹터로 이동하여 내용을 확인해 보도록 하겠습니다.

<Picture 2-10. BR>

63번 섹터로 이동하여 실제 내용을 확인해 보면 NTFS 라는 구문을 쉽게 발견할 수 있습니다. 여기서 많이 실수 하실 수 있는데 바로 1섹터 밑을 보시면 FAT32 에서만 볼 수 있는 Reserved Area 의 영역을 볼 수 있습니다. 그러나 BR 영역은 NTFS 의 내용을 갖고 있습니다. 따라서 첫번째 파티션이 NTFS 의 파티션인지 FAT32 의 파티션인지는 모르겠으나 밑으로 더 내려가다 보면 NTFS 영역과 일치하지 않는 영역(FAT Area 등..)을 발견할 수 있습니다. 따라서 첫번째 파티션은 FAT32 가 맞을 수 있다는 것을 염두해두고 다시 MBR 영역으로 이동하여 두번째 파티션을 살펴보도록 하겠습니다.

<Picture 2-11. Partition Table>

두번째 파티션 테이블을 보면 첫번째 파티션 테이블과 마찬가지로 파티션 타입 부분이 0x00 으로 훼손되어 있습니다. LBA Addr는 0xA0124D로써 10490445 Sector 를 가리키고 있으며 Size in Sector 는 0x9FD38C 로써 약 5GB 용량을 갖는걸 확인할 수 있었습니다. 이제 LBA Addr 를 따라 10490445 섹터로 이동해보도록 하겠습니다.

<Picture 2-12. BR>

실제 이동해본 결과 이전 BR과 동일하게 이상한 점을 발견할 수 있었습니다. BR 영역에는 FAT32 BR 내용이 있으나 바로 1섹터 뒤에는 NTLDR 를 로드하는 NTFS 영역의 코드가 들어 있음을 알 수 있습니다. 따라서 추론을 해보자면 BR 영역이 서로 스와핑 되어 있을 수 있다는 점 입니다. 또한 FAT32 영역과 NTFS 영역이 모두 나왔으므로 지금까지 나온 답안을 적어보자면 아래와 같습니다.

[중간 정리]

1. 2개    2. 존재함    3. 존재함    4. 각각 5GB    5. (없음)    6. (없음)    7. (없음)    8. (없음)

그렇다면 제 추론대로 BR 영역을 서로 스와핑 한뒤 MBR 영역을 수정후 재부팅 해보도록 하겠습니다. 아래는 수정 후 빨간색으로 변한것을 확인할 수 있습니다.

<MBR 영역>

<63번 섹터 FAT32 영역>

<10490445섹터 NTFS 영역>

+변경사항 정리+

1. MBR 영역 파티션 타입(0x0B, 0x07)

2. 63 Sector NTFS BR(63) -> FAT32 BR(10490445)

3. 10490445 Sector FAT32 BR(10490445) -> NTFS BR(63)

이제 저장 후 재부팅을 해보도록 하겠습니다. 아마 변경된 디스크 내용을 Ctrl + S 혹은 파일 -> 저장 을 통해 저장을 시도할 경우 아래와 같은 팝업창을 보실 수 있을겁니다. 저희는 저장을 해야하니까 당연히 Yes 를 눌러줍니다. 이후 변경사항이 적용되면 빨간색으로 하이라이트 되었던게 다시 검정색으로 돌아가게 됩니다. 저장을 확인하신 뒤 재부팅을 해주시면 되겠습니다. 주의하실점은 아무리 공부하는 포렌식이라고 한들 원본 디스크의 백업은 필수 입니다. 당연 복사본으로 작업해야 하구요 저희는 소프트웨어적인 디스크 vmdk 를 사용하므로 원본 디스크를 안전한곳에 저장하신 뒤 복사하시어 사용 하시는걸 권장해 드립니다.

<Picture 2-13. Popup Yes>

저장 후 재부팅을 하여 아름다운 윈도우 재부팅 장면을 보고 왔습니다. 그리고 설레이는 마음으로 내컴퓨터에 접속했을때... 아래와 같은 화면을 볼 수 있었습니다. 복구가 제대로 됬다면 저처럼 1이라는 파티션과 2라는 파티션이 정상적으로 인식 되실겁니다.

<Picture 2-14. Partition Recovery>

정말 아름다은 광경이네요. 앞에서 계산했던 대로 각 파티션의 용량은 5GB 이며 총 두개의 파티션이 존재 했습니다. 이제 해당 파티션에 각각 무엇이 들어있는지 확인해 봅시다. 확인 해보니 각각 파일이 하나씩 들어있네요. 아래 그림을 참고 해주시길 바랍니다.

<Picture 2-15. Partition Files>

일단 첫번째 파티션에 들어있는 KEEEEEEEEEEEEEY 라는 파일이 무엇인지 한번 살펴보도록 하겠습니다. 그대로 바탕화면에 복사하여 HxD 로 열면 아래와 같은 화면을 보실 수 있습니다.

<Picture 2-16. KEEEEEEEEEEEEEY>

딱 켜자마자 PNG 헤더가 눈에 바로 들어옵니다. 그럼 묻지도 따지지도 말고 바로 png 로 변경해 봅니다. 그럼 아래와 같은 화면을 볼 수 있습니다.

<Picture 2-17. KEEEEEEEEEEEEEY.png>

역시 png 확장자가 맞았네요. 그러나 사진의 내용은 FAKE!! Poor boy :D 입니다. 말 그대로 훼이크라고 하는데 훼이크일지 아닐지는 두고 봐야하겠죠. 일단 함정인지 아닌지는 모르겠으니 보류하고 두번째 파티션의 파일을 분석해 보겠습니다.

<Picture 2-18. Tail>

본 파일은 파일 이름 자체가 힌트 입니다. 이게 힌트인지 아닌지는 또 HxD 로 까보면 바로 알 수 있습니다. 열자마자 헤더 부분이 비어있음을 알 수 있습니다. 그리고 파일의 이름 Tail 즉, 꼬리 임을 생각해서 가장 아래에 존재하는 푸터를 보면 이상하게도 헤더가 푸터 자리에 있음을 확인할 수 있습니다. 이를 잘라내기하여 그대로 헤더 영역에 붙여넣고 저장한 뒤 헤더대로 zip 확장자로 변경 해보도록 하겠습니다.

<헤더 시그니처 변경>

<이름 변경을 통한 확장자 변경>

<Picture 2-19. Tail.zip>

변경 후 압축 프로그램으로 열었을땐 정상적으로 열렸으며 내부에는 KEY.rtf 이 존재함을 알 수 있었습니다. 이로써 1번 파티션에 존재했던 이미지 파일은 진짜 훼이크가 맞는것 같습니다. (는 실제로 훼이크 입니다 스스로 2중 훼이크에 걸리지 마세요 주의!) Tail.zip 은 암호가 설정 되어있지 않으므로 그냥 압축을 풀어주시면 됩니다.

<Picture 2-20. KEY.rtf>

위 그림은 압축풀기 후 KEY.rtf 를 워드패드 형식으로 열었을때 화면 입니다. 내용에는 이상한 암호? 인코딩? 문자가 나열되어 있으며 여기에 써드리자면 S2V5IGlzIDopX1N0YXJ0X0ZvcmVuc2lj 입니다. 인코딩에 관해 많이 접해보시거나 해킹대회 문제나 여러 워게임 문제들을 접하다보면 인코딩에 관한 내용이 종종 등장하곤 합니다.(종종이 아니라 어쩌면 많이..) 이걸 떠올려 봤을때 대충 저런 뉘양스를 풍기는 모양을 갖는 인코딩 방법은 Base64 인코딩 방법밖엔 없습니다. 생각이 떠올랐으면 되든 안되든 한번 해봐야 합니다. 틀린다고해서 누가 욕하는것도, 때리는것도 아니니까요. 디코딩을 한번 시도 해보도록 하겠습니다. 디코딩에 사용된 웹사이트는 https://www.base64decode.org/ 입니다.

<Picture 2-21. Base64 Decode>

오호..? S2V5IGlzIDopX1N0YXJ0X0ZvcmVuc2lj 라는 문구를 디코딩 해봤더니 Key is :)_Start_Forensic 이라는 값이 나왔네요. 아마 이게 키값인것 같습니다. 자 이제 풀이는 끝난것 같습니다. 마지막으로 최종 답안 정리를 하도록 하겠습니다.

3. 답안 확인

[내가 작성한 답안]

1. 2개    2. 존재함    3. 존재함    4. 각각 5GB    5. KEEEEEEEEEEEEEY.png or dib

6. Tail.zip    7. BR 영역 서로 스왑    8. :)_Start_Forensic

답안이 모두 작성 되었으므로 실제 답안을 확인해 볼까요?

<Picture 3-1. 답안 공개>

네, 제가 작성한 답안이 모두 맞았음을 확인할 수 있습니다. 만약 본 포스팅에 사용된 문제를 직접 푸시고자 하시는 분들께서는 제 풀이를 무작정 보시는것보단 한번 해보고 막히면 조금씩 보는게 좋습니다. 원래 이건 앞에 써야하는데 지금 쓰네요 음...ㅋㅋ;; 여튼 긴글 보시느라 수고 하셨습니다.

다음 시간에는 워밍업이 아닌 실전 트레이닝 디스크 문제를 풀어보는 시간을 갖도록 하겠습니다.

감사합니다.