"쌤, 저랑 포렌식 스터디 하나 하실래요?"


어떻게 보면, 선생님께서는 안한다고 해도 딱히 나쁠게 없던..

그렇게 툭 던진 한마디에 선생님은 당연하다는 듯이

"그러시죠."


분명히 스터디로 이야기를 했는데, 아무리봐도 스터디가 아닌.. 1:1 개인강습이 되고 있는 것 같은건 기분탓일까요.


그래도 선생님덕에 좋은 교육도 듣고있고, 많이 발전하고 있음을 느낍니다.

USB 하나로 시작했던 작은인연, 그 인연이 제겐 정말 중요한 인연이었던 모양입니다.


제 너무나도 당황스런(?) 요청에 흔쾌히 오케이 해 주셔서 진심으로 감사드립니다.

제가 여전히 배우고 있는 입장이지만.. 스스로도 준비 많이 해서 저도 좋은 자료 공유하도록 노력 하겠습니다.

감사합니다 김성대(이하 모든 내용에서는 필명인 간서치로 사용하도록 하겠습니다.) 선생님, 열심히 공부하는 모습 보여드리도록 하겠습니다.


다시한번 감사 말씀 드립니다.


위 내용처럼 참 가볍게 시작한 스터디입니다.

그럼에도 흔쾌히 허락해 주신만큼.. 저도 열심히 공부하고.. 블로그에 남겨서 공부해야겠지요.


향후 모든 대화는 이처럼 존대가 아닌 반말로 작성 될 예정입니다. 또한 이 부분은 Intro 부분으로 어떤식으로 진행될 지 작성 될 부분입니다.

근본적으로는 포렌식 전반적인 내용에 대해 체계적으로 공부할 예정이며, 이후 악성코드 분석과 같은 다른 분야도 진행 될 예정입니다.


또한 제가 개인적으로 하고 있는 또다른 Study인 DMA의 문제 풀이도 함께 블로그에 기재 될 예정입니다. 

관련해서 궁금하신 부분에 있어서는, 제가 매 글마다 메일 주소를 남겨드릴테니 그쪽으로 문의 주시면 확인하는대로 답변 드리도록 하겠습니다.


그럼 간서치 선생님과 함께하는 Forensics With 간서치! File System을 시작으로 그 닻을 올립니다!

Posted by Latte_
,

안녕하세요. Latte_ 입니다. 지난 포스팅에는 Day1의 Hard_Training Lv.1을 함께해봤습니다.

Hard_Training 문제 관련해서는 현재까지는 배포가 불가하니 양해부탁드리며, '이런식으로 문제를 푸는구나..' 정도로만 읽고 넘어가시면 되겠습니다.

또 지난 Lv.1에서 분명히 확인이 안됐던 파일은 총 3개였는데 왜 Where_am_I 파일만 분석했는지 궁금하신 분도 계실거로 생각합니다. 사실 제가 문제풀이를 하던 분석단계에서는 저도 엄청난 삽질을 경험했습니다. 그동안은 그 삽질들을 거의 다 여과없이 넣거나 하는 방식으로 진행했었으나, Hard_Training의 경우 그렇게 진행할 경우 분량조절의 상당한 어려움이 있을것이라 두 파일에 대한 분석은 추가하지 않았습니다.(실제로도 아무 의미 없기에..)


모든 CTF 문제가 그렇듯이, 포레식의 경우도 '보고서를 작성하는' 경우가 아니라면 Key값을 찾는 방식으로 진행됩니다. 이 Hard_Training의 경우도 그런 Case 입니다. 그럼 지금부터 Lv.2 문제를 풀어보도록 하겠습니다.


[그림 1. Lv.1에서 확인한 두번째 파티션의 Start LBA Addr]

Lv.1에서 Lv.2의 Start LBA Addr을 찾아냈다고 하더라도, 아직 우리가 보기에 두번째 파티션은 열려있지 않습니다. [그림 1]에서 볼 수 있는 것처럼 Start LBA만 들어가 있을 뿐 가장 중요한 Partition Type이 지정되지 않았기 때문입니다. 자 그러면 파티션 타입을 확인하기 위해 Start LBA Addr로 이동해보도록 하겠습니다.


[그림 2. 두번째 파티션의 Start LBA Addr 영역]

[그림 2]만 놓고보면 이 파티션의 타입은 FAT32 로 보입니다. 이제 아실분들은 다 아시겠지만 바로 다음 Sector를 보면 이 파티션 타입이 FAT32 라는것을 알아채셨을 겁니다. (FAT32 에서 BR영역 바로 뒤는 예약영역으로 비어있습니다.) 그러나 우리는 확실히 알아보기 위해 FAT32 의 백업 영역으로 이동해 보도록 하겠습니다.

- FAT32 백업역영 : Boot Record + Offset 6


[그림 3. 2번째 File System 의 Backup Area]

[그림 3]을 보면 [그림 2]와 같은 것을 볼 수 있습니다.(물론 세세한건 하나하나 까 봐야겠지만..) 백업 영역에도 FAT32 가 존재한다면 이 파티션은 FAT32 File System Format을 가지고 있다고 확신 할 수 있겠습니다. 이제 Master Boot Record 로 돌아가서 2번째 파티션의 타입을 FAT32를 의미하는 0x0B(혹은 0x0C)로 변경해 주도록 하겠습니다.


[그림 4. 두번째 파티션 확인 및 내부 파일들]

[그림 3]까지 확인하는 과정동안 우리가 정상적으로 값을 찾고 복구를 했다면 [그림 4]처럼 나와야 합니다. 아무래도 정확히 복구하는데 성공한것 같습니다. 아무래도 느낌상 이 파티션에서 정보를 찾아 세번째 파티션을 찾는게 목적인 듯 하네요. 한번 가 보도록 하겠습니다.


[그림 5. Lv.2 문제를 보여주는 2.txt]

Lv.1 에서는 친구가 참석한 세미나실의 위도 경도, 지번의 위치를 구해서 계산하라더니.. 이번에는 사진속 PC방의 정보를 구하라고 하는 문제입니다. 자, 그럼 문제도 있으니 실제로 그 사진을 찾아보도록 하겠습니다.


[그림 6. Where_this_PC_Room 파일의 헤더]

[그림 5]에서 출제자는 우리에게 한가지 힌트를 주었습니다. 문제와 함께 'Where_this_PC_Room.jpg' 라는 파일명을 남겨주었습니다. 그런데 [그림 6]을 자세히보면 무언가 조금 이상한 점을 찾을 수 있었습니다. 여러분은 발견하셨나요?


[그림 7. JPG 파일 확장자의 File Signature]

[그림 7]은 우리가 흔히 그림파일을 저장하는 JPG 확장자의 FIle Signature를 담고 있습니다. 보통 FF D8 FF Ex(0,1, 8)로 시작하는 파일들 입니다. 그런데 [그림 6]에서는 어느 무엇도 그렇게 시작하지 않습니다. 실제로 [그림 6]의 파일의 확장자를 .jpg 로 변경해도 그림이 제대로 열리지 않는 것을 확인 할 수 있습니다. 그러면 일단 앞에 알 수 없는 헤더부분을 날려버리고 JPG 파일 확장자 Signature가 가장 앞에 오도록 해 보겠습니다.


[그림 8. 수정한 헤더 값 및 복구한 jpg 이미지]

[그림 8]에서 가장 왼쪽에 보이는것과 같이 JPG 헤더를 정상적으로 수정하고 JPG 파일로 저장하면 오른쪽 아래 같은 사진이 나오게 됩니다. 잠시만요.. 출제자 양반.. 지금 저 사진 하나만으로 PC방의 위도, 경도, 지번을 찾으라고 주신건 아니겠죠??  이미지 그림을 조금 자세히 봐보도록 하겠습니다.


[그림 9. Where_that_PC_Room.jpg 파일의 확대 모습]

[그림 9]를 아무리 뚫어져라 살펴봐도 지역이 어디인지 나올만한 단서는 보이질 않습니다. 그런데 사진의 오른쪽 구석을 보면 'Code is Uuencode' 라고 쓰여있는 문구를 확인 할 수 있습니다. 그런데 말입니다.. 저 문구 어디서 보신것 같지 않으신가요? 그렇습니다. 우리는 저 문장을 Lv.1에서도 비슷하게 보았습니다. 바로 'code is ascii' 라는 문장으로 말입니다.

지난 Lv.1 문장에서 'code is ascii' 라는 문장을 보고나서, 그리고 문제를 풀어가면 갈수록 우리는 위도, 경도, 지번이 아무런 의미가 없는 함정이라는 것을 알았습니다. Lv.2도 과연 그런 방식일까요? 그것을 확인하려면 Uuencode가 무엇인지 확인해야 합니다.


Uuencode는 주로 Mail에서 Binary나 ascii 파일전송을 위해 사용되는 인코딩 입니다. Uuencode는 Unix - to - Unix Encoding의 약자로 과거 유닉스 시스템 사용자들간에 사용에서 비롯된 내용입니다. 그러나 현재는 모든 시스템에서 사용 할 수 있는 프로그램입니다.

이 Uuencode라는게 어디에 어떻게 숨어있는 걸까요? 그러고보니 Lv.1 에서는 HxD 에서 풀어봤을 떄 가장 위쪽에 위치하고 있었던 것으로 기억합니다. 과연 Lv.2 에서는 어떨까요?

기억하실지 모르겠지만, 처음 우리가 2번째 파티션을 열었을 때 Where_that_PC_Room은 어떠한 확장자도 가지고 있지 않은 파일이었습니다. 2.txt에서 .jpg 라는 힌트를 얻어서 확장자를 넣어주었지만 그것또한 맞지 않았습니다. 바로 시작 Signature가 맞지 않았기 때문이었는데요. 그럼 우리가 [그림 9]를 복구하기 위해 지웠던 내용은 무엇이었을까요?


[그림 6]이 바로 지우기 전의 원본입니다. 우리가 지워버린 저 부분이.. 바로 Uuencode 부분이네요! 자.. Lv.1 에서는 Ascii code 였기에 직접 대입이 가능했습니다. 근데 저 Uuencode는 도저히 직접 대입하고 싶지 않는 상황입니다. 그래서! 저는! Google 검색찬스를 사용하기로 했습니다.(왜 Naver 가 아니냐고 물으시면.. 할말 없습니다.. 그냥 Google 이 더 익숙합니다.)


[그림 10. Uuencode decoder에 대한 Google 검색 결과]

지금 우리가 원하는 정보는 저 uuencode 로 변환된 정보를 decode 하는 방법 혹은 decode 해주는 Site를 찾는 것 입니다. 그래서 Google에 검색을 해보니 상당히 많은 주소가 나오는걸 알 수 있습니다. 저는 그중에 가장 첫번째로 검색 된 Site에 접속해보았습니다.


이 Site는 UuenCode 뿐 아니라 아래 그림과 같은 여러 종류의 Encode/Decode를 사용하도록 되어있습니다.

[그림. 11. Encode/Decode Tool 종류]

또한 사용 방식도 Text를 입력하거나 File을 올리면 자동으로 분석해 주는 방식으로 되어있습니다.

[그림 12. Input Type 설정]

어떤 방법을 써도 상관은 없습니다. 제가 이 문제를 처음 풀어낼때는 파일을 복사해서 분석하는 방법을 사용했으나, 풀이작성을 위해 다시 풀 때에는 Text 방식을 사용했기에 이번에는 Text 방식으로 설명하도록 하겠습니다.


[그림 13. 파일 내 Uuencode로 Encoding 된 부분]

[그림 13]에 빨간 테두리가 되어있는 부분이 우리에게 필요한 Uuencode 입니다. Hex 부분이 아닌 Text 부분을 드래그해서 복사해서 Site에 붙여넣으면 깔끔하게 Text만 복사되는데요. 그 뒤에 Decode 버튼을 누르고 가만히 기다려 주시면 됩니다.


[그림 14. Decode 완료 된 UuenCode]

길지않은 시간(길어봐야.. 2초 이내 정도입니다. 그정도 인내심은 다들 있으시겠죠)이 지나면 Decode가 끝나고 우리가 알 수 있는 문자로 나타납니다. 우리 앞에 나타난 내용은 다음 Partition LBA를 나타내주고 있습니다.


이 3번째 파티션의 LBA을 찾음으로써 Day1_Hard_Training(Lv.2)를 완료하였습니다.

다음 포스팅은 Day1_Hard_Training(Lv.3)를 통해 찾아뵙겠습니다.

'보안 > Forensics_In_DMA' 카테고리의 다른 글

Day1 Hard_Training(Lv.1)  (0) 2016.03.16
Day1 Training 풀이  (0) 2016.03.07
Day1 Warming_Up 풀이  (0) 2016.03.06
스터디 1일차(Day1)  (0) 2016.03.02
본 디렉토리에 대하여..  (0) 2016.03.02
Posted by Latte_
,

안녕하세요. Latte_ 입니다.

지난시간까지 Day1 ppt에 출제된 두가지 문제를 풀이해봤습니다.

오늘은 그 마지막 과정인 Hard_Training(Lv.1)을 풀이해보려고 합니다.

Hard_Training의 경우 DMA 내부 규약에 따라 문제 파일이 제공되지 않고 있습니다.

따라서 이런식으로 문제를 푸는구나.. 하고 확인만 하고 넘어가시면 되겠습니다.

관련 문의는 아래 DMA 페이지에 문의주시면 답변 드리도록 하겠습니다.

 * www.facebook.com/t34m.dma(DMA 공식 FaceBook)

 * 본 Hard_Training은 총 4문제로 구성되어있습니다. 각 문제는 Level 별로 따로 풀이 할 예정입니다.

기존에 풀이했던 Warming_up과 Recovery_Training의 경우에는 따로 풀어야 할 문제가 존재했지만, Hard_Training의 경우 따로 문제가 존재하지 않습니다. 대신 파일을 삽입 할 경우 아래와 같이 하나의 파티션이 존재함을 확인 할 수 있습니다.


[그림 1. Hard_Training 파일 삽입 시 초기 화면]

[그림 1]에서 볼 수 있듯이 현재 넣은 Hard Disk는 하나의 파티션만이 정상으로 표기되어 있습니다. 나머지가 몇개의 파티션으로 구성이 되어 있는지는 모르지만, 일단 하나 이상의 파티션이 존재한다는 의미일 것입니다. 그리고 그나마 확인되는 하나의 파티션도 실제로 제대로 실행되지 않는 상태입니다.

현재 우리에게 주어진 힌트나 문제는 아무것도 없습니다. 딱 하나의 힌트가 존재한다고 한다면 바로 파티션이 하나 이상이 존재하며 무언가에 의해 손상되었다는 점입니다. 그럼 지금부터 해야 할 일은 무엇일까요? 그렇습니다. 바로 손상된 파티션을 하나하나 복구 해 가야합니다.


[그림 2. 삽입한 Hard Disk의 MBR(Master Boot Record)]

Hard DIsk의 MBR은 우리에게 생각보다 많은 정보를 줍니다. 최초 446 byte의 Boot Code는 우리에게 필요한 많은 정보를 주지는 않습니다. 물론 Boot Code의 오류메시지 부분이나 MBR Device의 Singature 같은 정보를 주기는 하지만 현 시점에서 우리가 분석하는데는 전혀 필요없을 정보이기 때문에 일단은 넘어가도록 하겠습니다.

ppt에 설명되어있을 내용입니다만 MBR은 총 512 byte로 구성이 되어있으며 이 가운데 Boot Code가 446 byte, Primary Partition Table이 64 byte, 마지막을 Signature 2 byte로 구성되어 있습니다.

이 가운데 우리가 주로 분석해야 할 부분은 64 byte를 차지하고 있는 Primary Partition Table 입니다. 이곳에서 우리는 이 Hard Disk에 존재하는 주 파티션의 총 개수(최대 4개), 각 파티션의 타입, 파티션의 크기 등을 확인 할 수 있습니다. 그 뒤에 마지막으로 Signature가 정상(0xAA55)임을 확인하면 됩니다.

[그림 2]에서 붉게 테두리가 쳐진 부분이 우리가 확인해야 할 Primary Partition Table 입니다. 위에서 간략히 설명드린 것처럼 Primary Partition Table에는 최대 4개의 주 파티션이 들어 갈 수 있습니다. 각 파티션은 16 byte의 정보를 가지고 있으며 Primary Partition Table이 총 64 byte를 가지므로 최대 4개를 가짐을 한번 더 확인 할 수 있습니다.

우리가 가지고 있는 Hard Disk는 [그림 2]에서 볼 수 있듯이 총 4개의 파티션을 가지고 있습니다. 우리는 우선 첫번째 파티션부터 하나하나 분석 해 나가도록 하겠습니다.

먼저 가장 먼저 확인 해야 할 부분은 Boot Flag 부분입니다, 각 Partition Table의 가장 앞에 오는 부분으로 0x80일 경우 부팅 가능한 파티션임을 의미 합니다. [그림 2]에서는 어느 파티션도 부팅이 가능하지 않음(0x00)을 나타내고 있습니다.


[그림 3. 각 파티션의 Partition Type]

이 Hard_Disk를 분석하면서 Boot Flag 다음으로 봐야 할 부분은 Partition Type 입니다. 모든 정보가 다 들어있다 하더라도 Partition Type이 맞지 않는다면 파티션이 제대로 열리지 않습니다. 쭉 보면 첫번째 파티션은 0x07, 즉 NTFS FIle System임을 나타내고 있으며 나머지는 0x00으로 어떤 파티션인지 확인 할 수 없는 상태입니다.

 * Partition Type : 0x0B, 0x0C(이상 FAT32 File System), 0x07(NTFS File System)

그러나 남은 아래의 파티션들이 FAT32 도 아닌, 그렇다고 NTFS도 아닌 0x00임을 봤을 때 Partition Type 부분은 임의로 변경이 가능하다는 걸 알 수 있습니다. 그렇다면 다른 부분에서 이 Partition Type이 정말 NTFS File System인지 확인 해야합니다.


[그림 4. 각 파티션의 Start LBA Addr]

[그림 3]에서 Partition Type을 확인 했다면 그 다음은 [그림 4]의 Start LBA Addr을 확인해야 할 차례입니다. Start LBA Addr은 해당 파티션의 시작 주소를 나타내며 BR이 위치해있는 Sector를 나타내기 때문에 앞에서 확인했던 Partition Type을 직접적으로 확인 할 수 있느 중요한 정보입니다.

[그림 4]는 우리가 알 수 있는 각 파티션의 Start LBA Addr을 나타내고 있습니다. 여기서 문제가 되는부분은, 우리가 실제로 확인 할 수 있는 Start LBA Addr은 첫번째 파티션 뿐이라는 점입니다.(물론, 약간의 다른 방식을 통해 남은 파티션의 Start LBA Addr을 확인 할 수도 있습니다. 일종의 꼼수이지만 본 풀이과정에서는 정석적인 방법으로만 접근해 가도록 하겠습니다.)

Little Endian 기준을 따르는 Intel의 방식에 따라서 Start LBA Addr을 게산하면 0x3F, 즉 63임을 알 수 있습니다. 앞에서 풀이한 두개의 문제에서도 설명했듯이 첫번째 파티션의 Start LBA Addr의 경우 이 하드디스크가 어디서 포멧되었는지 확인 할 수 있는 간략한 정보를 제공합니다. 

 * Window XP의 경우 Start LBA Addr 이 0x3F, 즉 63으로 시작하며 Window 7의 경우 0x800, 즉 2048로 시작하는 경우가 많다.


위 정보들을 기준으로 볼 떄 이 Hard Disk는 Window XP에서 포멧되어진것을 알 수 있습니다. 그러면 이제부터 Start LBA Addr로 이동해서 실제 이 파티션의 File System 포멧을 확인 해 보도록 하겠습니다.

[그림 5. 첫번째 파티션의 Start LBA Addr에서 확인한 BR(Boot Record)]

앞에서 계산한 값대로 첫번째 파티션의 Start LBA Addr로 이동해왔습니다. 이곳은 첫번째 파티션의 시작부분으로 BR 영역(Boot Record Area)가 위치하는 곳입니다. 그러나 여러분의 눈으로 보듯이 63 Sector는 텅 비어있습니다. 마치 누군가가 이곳의 Data를 일부러 지워버린것 같습니다. BR 영역에 Data가 비어있다면, Backup 영역으로 이동해서 Partition Type을 확인해야 합니다.

 * 앞에 두 문제를 잘 따라왔다면, 그리고 그 내용을 기억하고 있다면 Backup Area를 확인하지 않더라도 Partition Type이 무엇인지 확인 할 수 있을것이다. 바로 BR 영역 바로 뒤 Sector를 확인하는 방법이다. FAT32의 경우 BR영역 바로 뒤 Sector가 예약영역으로 비어있다. 반면에 NTFS의 경우 BR 영역의 바로 뒤 Sector에서 NTLDR이라는 문구를 확인 할 수 있으며 FAT32처럼 비어있지 않고 내용이 차있음을 알 수 있다.

위의 팁에도 설명해놨지만 [그림 5]만으로도 우리는 이 첫번째 파티션의 타입이 NTFS 인지 FAT32 인지 확인이 가능합니다. 물론 이곳의 Data를 복구하기 위해서는 Backup 영역으로 이동해서 확인 해 봐야 하겠지만 말입니다. 만약 이곳에 Data가 삭제되지 않고 남아있다면 위의 방법으로도 확인 할 수도 있다는 점을 알려드리기 위한 방법이었습니다.

그러면 팁을 생각하지 않고 보통의 방법으로 이동해 보겠습니다. [그림 3]에서 첫번째 파티션의 타입이 NTFS라고 했으니 먼저 NTFS의 Backup Area로 이동해 보도록 하겠습니다. NTFS의 경우 자신의 백업영역을 파티션 가장 끝에 위치시킵니다.

 * FAT32 의 경우 백업영역이 BR영역으로 부터 Offset 6 의 지점에 위치합니다.


[그림 6. 각 파티션의 Size in Sector 정보]

파티션의 가장 끝으로 가보기 위해서는 파티션의 크기를 알아야 합니다. Primary Partition Table 에서는 각 파티션 정보 가장 마지막 4 byte에 Sector의 크기 정보인 Size in Sector를 저장하고 있습니다.

위에서 말한 NTFS의 경우 백업 영역을 파티션 가장 끝에 위치시킨다고 말했었습니다. 즉, 마지막 섹터위치는 BR 영역 + Offset T.S(Total Sector)가 됩니다. 물론 BR 영역에서 Size in Sector 만큼 더할 경우 다음 파티션의 시작부분이 오기 때문에 -1 값을 해주는 것을 잊지 말아야 합니다.

 * NTFS 파티션의 Backup Area : BR 영역 + Offset T.S(Total Sector)

 * 혹은 BR 영역 Sector + Size in Sector -1

이를 기준으로 첫번째 파티션의 가장 마지막 섹터를 계산해 보도록 하겠습니다. [그림 4]에서 확인한 Start LBA Addr, 즉 BR 영역의 Sector는 63 입니다. 그리고 [그림 6]에서 확인 할 수 있는 첫번째 파티션의 Size in Sector는 0x601749, 즉 6297417 입니다. 이를 위에 계산식에 대입해서 구하면 6297479 Sector가 첫번째 파티션의 마지막 Sector임을 확인 할 수 있습니다. 한번 실제로 가서 확인해보도록 하겠습니다.


[그림 7. 첫번째 파티션내의 BR 영역의 Backup Area]

목표 한 Sector에 도착하니 정말 우리가 찾던 NTFS File System을 확인 할 수 있습니다. 이제 이 Sector의 내용을 복사해서 BR 영역에 넣으면 첫번째 파티션의 내용물을 볼 수 있을것입니다.

 * [그림 7]에서 볼 수 있듯이 Sector 가장 앞에 NTFS라고 쓰여있는 것을 확인할 수 있다. 이부분을 OEM Name 이라고 한다. 여기서 한가지 주의할 점은 OEM Name을 맹신하면 안된다는 점이다. OEM Name은 해당 디지털 장비(기기)의 이름이라고 보면 된다. 이 OEM Name은 컴퓨터가 참조하지 않는 부분이다. 즉 저 Sector의 OEM Name이 FAT32 라고 쓰여있다고 해서 [그림 3]의 Partition Type을 FAT32 를 나타내는 0x0B 혹은 0x0C로 바꾸어서는 안된다는 점이다. OEM Name을 보지말고 그 밑에 데이터에서 FAT를 찾거나 NTLDR(NTFS의 경우)를 찾는것이 답이다.


[그림 8. 복구한 첫번째 파티션]

[그림 7]의 내용을 첫번째 파티션의 BR영역(0x3F)에 복사 후 Window를 재부팅을 하고 난 뒤 내컴퓨터를 들어가면 아까 확인한 [그림 1]과는 조금 달라진 점이 있는것을 확인 할 수 있습니다. [그림 1]에서는 삽입 된 디스크의 이름이 '로컬 디스크'로 되어있고 제대로 열리지 않는데 반해 복구 후에는 LEVEL(1) 이라는 이름의 파티션과 안에 파일을 열람 할 수 있게 된 것입니다.

물론 안에 들어있는 파일들 중 실제로 열리는 파일은 텍스트 파일 하나뿐이지만 그래도 제대로 복구가 되었다는 의미이니 기뻐하셔도 됩니다. 그럼 파일들을 살펴보도록 하겠습니다.

txt 파일을 제외한 나머지 파일들은 모두 확장자가 지정되어있지 않아 열 수 없는 상태입니다. 우선은 확인이 가능한 텍스트 파일을 열어서 어떤 내용이 들어있을지 확인 해 봐야 할 것같습니다.


[그림 9. 1.txt 파일의 내용]

텍스트 파일은 우리에게 정말 중요한 정보를 주고 있습니다. [그림 4]에서 우리는 첫번째 파티션의 Start LBA Addr 만을 얻었을 뿐 다른 파티션의 Start LBA Addr 정보는 얻지 못했습니다. 그런데 [그림 9]에서 볼 수 있듯이 이 LEVEL(1) 이라는 파티션 안에서 2번째 파티션의 Start LBA Addr을 찾을 수 있다고 적혀있습니다. 우리가 찾아야 할 내용은 친구가 참석한 세미나 건물의 지번, 위도, 그리고 경도 값입니다. 그리고 Where_am_I 라는 파일이 jpg파일이라는 힌트도 살짝 얻을 수 있었습니다.


[그림 10. [Lv.1]Where_am_I.jpg 파일]

우리가 [그림 9]에서 얻었던 힌트를 토대로 아무 확장자도 없는 파일을 jpg 파일로 변환했습니다.(물론 백업본입니다) 그랬는데 아무런 결과가 나오질 않습니다. 무언가 잘못된 모양입니다, 아무래도 hex값을 확인 해 봐야 할 것 같습니다.

 * 포렌식에서 파일을 복원 및 분석할 때 백업은 필수이다. 원본파일은 증거로서의 가치가 있기 때문에 절대로 훼손해서는 안되며 항상 모든 작업은 백업본을 통해 진행 되어야 한다. 물론 현재는 증거가 아니기 떄문에 큰 문제가 없을지 모르지만 기초 공부 때 부터 습관을 들여놓으시는게 좋다.


[그림 11. Where_am_I 파일의 hex 값]


[그림 12. JPG 파일의 Signature 정보]

 * [그림 12] 출처 : http://www.garykessler.net/library/file_sigs.html

[그림 12]에서 볼 수 있듯이 JPG 파일은 FF D8 FF E0 로 시작합니다. 모든 JPG 파일은 저렇게 시작합니다. 그러나 [그림 11]은 그렇게 시작하질 않습니다. 도대체 무슨 의미인지 알 수 없는 정보들을 가지고 있는걸 알 수 있습니다. 그런데 그 알수없는 문자 다음줄을 보면 우리가 찾고있는 FF D8 FF E0 이라는 문구를 찾을 수 있습니다. [그림 12]에서 JPG 파일은 FF D8 FF E9라는 파일로 시작한다고 이야기 해습니다. 그럼 이 파일은 어떻게 끝날까요? Trailer를 보면 알 수 있습니다. 바로 FF D9로 끝납니다. 과연 지금 연 파일이 FF D9로 맞게 끝나는지 확인 해 보도록 하겠습니다.

[그림 13. Where_am_I 파일의 Trailer Signature]

마지막을 확인해보니 [그림 13]처럼 FF D9로 끝나는 것을 확인 할 수 있습니다. 그러면 맞는 그림파일 복구를 위해서 시작 Signature인 FF D8 FF E0 부터 마지막 Signature인 FF D9까지 복사해서 새로운 파일에 옮긴 뒤 Where_am_I.jpg로 저장 해 보도록 하겠습니다.(앞에서 저장했던 내용은 이미 삭제하였습니다.)

[그림 14. 정상 복구 된 Where_am_I.jpg 파일 사진]

아까 복구했던 [그림 10]과는 다르게 [그림 14]는 완벽히 복구된 모양은 아니지만 어느정도 인식 가능한 수준의 그림으로 복구되었습니다. 이를 토대로 분석을 해 보도록 하겠습니다. 우선 [그림 9]에서 문제의 내용은 친구가 참석한 세미나의 건물의 지번, 위도, 경도를 구해서 LBA Addr을 구하는 내용이었습니다. 문제는 빌딩의 이름이 제대로 나와있지 않다는 점입니다. 그러나 우리는 사진의 A4 용지안에 있는 '제 1회 비코닉스 IoT 비콘 세미나' 라는 내용을 기준으로 빌딩을 찾으면 어떤 빌딩인지 확인이 가능 합니다.

Google 검색을 통해 세미나를 검색하면 서울시 강남구 역삼동 683-34 새롬빌딩 6층 대강당 이라는 주소를 확인 할 수 있습니다. 이를 Naver 지도, 혹은 Google 지도를 통해 검색하면 37°30'28.0"N 127°02'42.3"E 라는 위도와 경도를 확인 할 수 있습니다.

여기서 한가지 난관에 부딧치게 됩니다. '저 정보를 확인하면 어떻게 활용 한 것인가?' 라는 점입니다. 제가 풀어간 과정중에서는 저 숫자들을 아무리 조합해도 답을 찾아 낼 수 없었습니다. 그런데 말입니다, 우리는 그림에서 이상한 내용을 하나 볼 수 있었습니다. 바로 'code is ascii' 라는 문구입니다. 자세히는 모르겠지만 ascii 코드와 연관이 있는 힌트 같습니다. 

저는 저 문구만 가지고 거의 1주일을 고민한 것 같습니다. 결국 문제 출제자이신 Eniac 님께 문의(문의라고 쓰고 힌트 강탈 이라고 씁니다) 드렸을 때 돌아온 답변은 'Code is ascii가 답이다' 라는 답변이었습니다. Ascii 코드표를 한참동안 열고 봐도 답이 나오질 않아서 고민을 굉장히 많이 했었습니다. 그리고 Eniac님이 [그림 14]파일을 다시 보내라 라고 해서 보냈을 때 제게 돌아온 대답은 큰 충격이었습니다. "처음부터 잘못되었다" 라는 답이었으니까요.

다시 처음으로 돌아가보도록 하겠습니다. 힌트인 "code is ascii" 를 얻었으니 다시 처음으로 돌아가서 ascii code로 사용할만한 것이 무엇인지 찾아봐야겠습니다. [그림 11]은 우리에게 중요 한 그림입니다. Eniac님이 제게 준 '처음부터 잘못되었다' 라는 힌트가 바로 저기서부터였기 때문입니다. [그림 14]라는 파일을 복구하기 위해 [그림 11]에서 알수없는 문자인 윗부분을 날려버렸습니다. 그러나 알 수 없던 윗부분은 사실 우리에게는 가장 중요한 단서였던 것입니다.


[그림 15. Ascii Code 표]

[그림 15]는 우리가 C언어를 배울 때 기본적으로 배우는 Ascii Code Table 입니다. 이것을 [그림 11]과 비교해 보면 어디에 대입해야 하는지 어느정도는 감이 오게됩니다. 저는 최초 모양이 비슷한 Oct에 대입 해 보려고 했습니다만 실제로 보면 Dec값에 대응해야 하는 상황입니다. 8진수는 0 ~ 7로 구성이 되어있으나 [그림 11]에서 보면 9도 보이는걸 봐서는 Dec로 검색하면 될 것 같았기 때문입니다.

바꾸기 전의 문구는 050 032 080 097 114 116 105 116 105 111 110 032 076 066 065 032 105 115 032 056 056 032 049 055 032 054 048 032 048 048 입니다. 이를 ascii code에 대입해서 해석하면 2 partition LBA is 88 17 60 00 이라는 답이 나오게 됩니다. 즉, 이 문제에서 요구한 건물의 지번, 위도, 경도는 사실상 잘못된 분석을 유도하기 위한 속임수로 실제로는 ascii code 값을 이용해서 Where_am_I 파일의 가장 앞부분을 분석하면 바로 답이 나오는 문제였던 것입니다.

축하합니다. 이것으로 Hard_Training 문제의 Lv.1을 통과하셨습니다.(저 혼자 풀었으니.. 제가 축하를 받아야 하는 부분일까요?)


'보안 > Forensics_In_DMA' 카테고리의 다른 글

Day1_Hard_Training(Lv.2)  (2) 2016.03.26
Day1 Training 풀이  (0) 2016.03.07
Day1 Warming_Up 풀이  (0) 2016.03.06
스터디 1일차(Day1)  (0) 2016.03.02
본 디렉토리에 대하여..  (0) 2016.03.02
Posted by Latte_
,

안녕하세요. Latte_ 입니다.

지난번에는 Day1 Warming_Up 문제로 여러분들과 함께 했었습니다.

어떻게.. 도움은 많이들 되셨는지요?

오늘 할 내용은 동일한 Day1 중 Recovery Training 문제를 풀어보겠습니다.

 * 실습 환경은 개인마다 다를 수 있습니다. 필자는 Widow XP SP3 를 베이스로 작업을 하고 있습니다. 기타 다른 OS에서 실습중이시라면 해당 환경에 맞춰 주시기 바랍니다.

실습 및 풀이에 필요한 PPT는 아래 적어드린 Eniac님의 블로그에서 받아주시기 바랍니다.

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


FS_Day1_Training_Disk.z01


FS_Day1_Training_Disk.z02


FS_Day1_Training_Disk.z03


FS_Day1_Training_Disk.zip


Disk FIle 삽입방법은 지난번 Warming_Up 풀이과정 때 이야기 해 드렸습니다. 

혹시 기억이 나지 않는 분들은 잠시 뒤로 돌아가셔서 보고 오시기 바랍니다.


Disk가 제대로 올라갔는지 확인하려면 Disk 삽입 후 diskmgmt.msc 에 들어가서 [그림 1]과 같이 되어있는지 확인 해 봅시다.

[그림 1. Disk 삽입 확인(디스크2)]


디스크 관리창의 아래쪽에 디스크 상태를 보면 이번에 새로 삽입한 디스크(디스크 2)는 총 3개의 파티션이 존재할 것으로 예상이됩니다. 그리고 2개의 파티션이 각각의 파일시스템으로 존재하고 있습니다. 남은 하나를 찾는게 문제일지도 모르겠네요.


그러면 HxD로 새 하드디스크를 분석해 보도록 하겠습니다.

[그림 2. 새 하드디스크의 Master Boot Record]

[그림 2]는 지난번 Warming_Up에서 봤던 하드디스크의 MBR과 비슷한 모양임을 알 수 있습니다. 앞쪽에 446 Byte의 Boot Code 부분을 제외하고 64 Byte의 Primary Partition Table을 분석 해 보도록 하겠습니다.

우선 파티션은 아래 [그림 3]과 같이 총 3개가 존재하는것을 확인 할 수 있습니다.

이것으로 문제 1번의 답을 확인 할 수 있겠습니다.

[그림 3. 새 하드디스크의 Primary Partition Table 정보]

파티션 테이블에서 각 파티션을 분석할 때 중요 한 4가지는 Boot Flag, Partition Type, Start LBA Addr, 마지막으로 Size of Sector 입니다. 지난 Warming_Up 실습때도 한번 올려드렸는데 이번에도 풀이하면서 참고하시라고 한번 더 올려드리도록 하겠습니다.


[그림 4. Partition Table에서 위치에 따른 확인 가능 정보]

[그림 3]과 [그림4]를 참고하여 각각의 파티션을 하나하나 풀어보도록 하겠습니다.

가장 먼저 분석해 볼 내용은 당연히 순서대로 첫번째 파티션입니다. 먼저 Boot Flag는 0x00 입니다. 즉, 이 첫번째 파티션으로는 OS 부팅을 할 수 없다는 의미입니다. 그 다음으로 보셔야 할 내용은 Partition Type 입니다. 보이는 값은 0x0B로 FAT32 파일시스템임을 나타내고 있습니다. 그러나 이는 수동으로 변경을 하면 충분히 변조가 가능한 부분이기 때문에 실제 파티션의 BR영역을 확인 해야 합니다.

파티션의 BR 영역은 항상 그 파티션의 시작섹터에 존재합니다. 따라서 Start LBA Addr 을 확인하면 실제 파티션 타입 정보를 확인 할 수 있습니다. 첫번째 파티션의 Start LBA Addr은 0x800(Intel은 Little Endian 방식을 사용하고 있기 때문에 실제 입력값의 역순으로 출력된다.)로 10진수로 변환하면 2048이 된다.

 * 여기서 잠깐, 지난번 Warming_Up 풀이를 하면서 Window XP의 경우 첫번째 파티션의 BR이 주로 0x3F, 즉 63에 위치한다고 설명했다. 그리고 Window 7의 경우 2048 Sector에서 주로 시작한다고 설명했다. 그럼 이 Hard Disk는 Window 7에서 만들어진 것인가?

   사실 그것은 알 수 없다. 보편적으로 그렇게 사용 될 뿐이지, 실제로 Start LBA Addr과 내부 데이터를 수작업으로 변경하면 충분히 첫번째 파티션의 BR 위치를 변경 할 수있다.


자, 그러면 실제로 2048 Sector로 이동하여 첫번째 파티션의 타입이 FAT32가 맞는지 확인해 보도록 하자.

[그림 5. 첫번째 파티션의 BR 영역]

[그림 5] 의 가장 앞부분을 보면 우리가 확인할 수 있는 가장 간단한 문구인 MSDOS5.0이 보인다. 보통 FAT32 파일시스템의 OEM Name으로 잘 나오는 이름이지만, 실제로 OEM Name은 참조하지 않으니 그냥 참고만 하고 넘어가도록 하자.

지난번 실습 풀이를 기억하고 있는 분들이라면 FAT32인지 확인하는 방법을 이미 알고 있을 것이다. 크게 두가지로 확인이 가능한데, 가장 확실한 방법은 백업 영역을 확인하는 것이다. 두번째 방법은 바로 다음 Sector를 확인하는 것이다. NTFS와 FAT32의 가장큰 차이점이 바로 BR영역 바로 다음 Sector 인데 FAT32의 경우 BR 영역 바로 다음이 예약 영역으로 항상 비어있다. 첫번째 방법보다는 두번째 방법이 더 쉽게 확인이 가능한 방법이긴 하지만 정확한 방법은 백업 영역을 확인하는 것이다.


그러면 정석적인 방법인 Backup Area를 확인해 보도록 하겠습니다.

[그림 6. 첫번째 파티션의 BR Backup Area]

FAT32 파일시스템의 경우 Backup Area는 Start LBA Addr + offset 6 이다. 이를 기준으로 값을 대입 해 계산하면 2048 + 6 = 2054 가 나옵니다. [그림 6] 처럼 2054 Sector로 이동하면 [그림 5]에서 본 값과 동일 한 내용이 위치하는 것을 볼 수 있습니다. 그렇다면 첫번째 파티션은 [그림 3]에 표시 된 것처럼 0x0B 즉, FAT32 파일시스템임을 확인 할 수 있습니다.

 * 사실 첫번째 파티션과 두번째 파티션 타입은 HxD 이전에 diskmgmt.msc에서도 확인이 가능합니다. 만약 파티션이 잘못되었거나, 변조되었다면 디스크 관리 창에서 제대로 나오지 않을 것이기 때문입니다. 그러나 본 풀이의 목표는 실제 실습에 있기 때문에 하나하나 다 해보는 것임을 참고하시기 바랍니다.


마지막으로 첫번째 파티션의 전체 Size를 확인해 보도록 하겠습니다. [그림 3]과 [그림 4]를 참고하면 첫번째 파티션의 사이즈를 구할 수 있습니다, 첫번째 파티션의 Size of Sector는 아래와 같습니다.

[그림 7. 첫번째 파티션의 Size in Sector]

글을 쓰면서 생각해보니 지난번 Warming_Up 문제 풀이 때 '파티션의 사이즈는 Size in Sector 다' 라고만 알려드리고 실제 계산하는 방법을 알려드리진 않았던것 같습니다.

사실 파티션을 제대로 복구 했다면 내 컴퓨터나 디스크 관리에서 디스크의 크기를 확인 할 수 있습니다. 하지만 지금 설명드릴 방법은 저 Size in Sector 값을 이용한 계산을 통해 디스크 크기를 확인하는 방법을 알려드리겠습니다. 디스크의 크기를 구하는 공식은 아래와 같습니다.

Size in Sector(Dec) * 512 / 1024 / 1024 / 1024 = ? GB

하나하나 설명드리도록 하겠습니다. Size in Sector는 섹터의 수 입니다. 즉, 파티션의 데이터 영역의 전체 섹터 수를 나타냅니다. 그리고 한 섹터는 512 Byte의 크기를 가지기 때문에 512를 곱해서 전체 영역을 구해 줍니다.

 * 여기서 한가지 알고가야 할 부분이 있습니다. 모든 파티션이 한 섹터의 크기가 512 byte가 되는것은 아닙니다. 최초 하드를 포멧할 때(우리가 분석할 떄가 아닌) 한 섹터의 사이즈를 가변적으로 변경할 수 있습니다. 다만 기본값이 512 Byte이기 때문에 그렇게 계산하는 것입니다. 

* 단, 한 섹터의 Default Size의 경우 FAT32 파일시스템이 512 byte 이며 NTFS 파일시스템의   경우 2048 byte가 한 섹터의 Default Size 입니다.

 * 여기서 한 섹터의 크기가 가변적인 것은 'Data Area'에 국한된 부분입니다. 아무리 초기 설정에서 한 섹터의 사이즈를 가변적으로 변경한다 하더라도 'System Area' 부분의 Size는 512 byte로 고정됩니다.

이렇게 계산을 하고나면 디스크 사이즈의 byte 크기가 나옵니다. 이를 1024로 3번 나눔으로 인해서 우리가 알기 쉬운 GB 단위까지 가는것입니다.

자 그러면, 위의 공식을 바탕으로 첫번째 파티션의 사이즈를 확인 해 보고, 실제로 계산한 크기와 시스템상에 나타난 크기가 맞는지 [그림 1]과 비교해보도록 하겠습니다.

첫번 째 파티션의 Size in Sector의 Hex 값은 0x200000 입니다. 이를 Dec값, 즉 10진수로 바꿔주면 2097152 가 나옵니다. 이를 512와 곱하면 1073741824가 되겠네요. 이를 1024로 3번 나눠보도록 하겠습니다. 그렇게 나누면 딱 1이라는 값이 나옵니다. 즉, 1GB 라는 뜻입니다. 자 그럼 [그림 1]과 비교해서 계산한 값이 맞는지 확인해보고 오시기 바랍니다.

Primary Partition Type를 통한 첫번째 파티션 분석은 이것으로 마무리 되었습니다. 이제부터는 두번째 파티션을 분석 해 보도록 하겠습니다.


[그림 8. Partition Table에서 확인 한 두번째 파티션 정보]

[그림 8]은 두번째 파티션의 정보입니다. 이를 토대로 다시 하나 하나 분석 해 보도록 하겠습니다. 먼저 이 파티션의 Boot Flag는 0x00 즉, 부팅 불가 입니다. 그럼 그 다음으로 봐야할 Partition Type을 보죠. Partition Type은 0x07, 즉 NTFS임을 나타내고 있습니다.

과연 정말 NTFS일까요? 확인해봐야겠습니다. 실제로 확인해보기 위해서는 Start LBA Addr을 찾아서 Boot Record 영역을 확인해봐야 합니다.

눈에 보이는 Start LBA Addr 은 0x200800 입니다. 이를 10진수로 바꿔주면 2099200 이 됩니다. 한번 실제로 가서 2번쨰 파티션의 Boot Record가 존재하는지 확인해 보도록 하겠습니다.


[그림 9. 2번째 파티션의 Start LBA Addr 영역에 있는 Boot Record 정보]

일단 육안상으로는 정말로 NTFS Boot Record가 보이는 듯하다. OEM Name에 NTFS라는 명칭도 그렇고, Boot Record 영역 다음 Sector가 예약 영역으로 비어있지 않는걸로 봐서는 말이다. 보통은 여기서 NTFS 임을 확인 할 수도 있지만 필자는 교육을 위함이기에 Backup Area도 확인 해 보도록 하겠다.

NTFS의 Backup Area는 전에도 설명했듯이 BR + Offset T.S(Total Sector) 이다. BR 영역은 [그림 8]에서 확인 할 수 있듯이 0x200800, 즉 2099200 이며 Total Sector에 해당하는 Size in Sector는 0x400000, 즉 4194304이 된다. 

여기서 중요한 점. BR + Offset T.S 는 NTFS 파티션의 가장 마지막에 위치한다. 그러나 지금 계산 한 BR + Size in Sector를 하면 NTFS 백업 영역이 나오지 않는다. 왜냐.. Offset T.S 라는건 현재 위치에서 Total Sector 만큼 더 가라는 의미이다. 문제는.. 컴퓨터는 항상 0부터 시작한다. 즉 현재 위치하는 BR 영역이 0이나 다름 없다는 의미이다. 죽 실제로 계산을 할 때는 BR + Size in Sector -1을 해야만이 제대로 된 백업 파티션이 나타난다는 의미이다.

[그림 10. 2번째 파티션의 NTFS Backup Area 확인] 

이제 백업 영역까지 확인을 했으니 두번째 파티션의 마지막 분석과정인 Size in Sector를 확인해보도록 하겠습니다. Size in Sector는 0x400000, 즉 4194304이 나옵니다. 이를 가지고 용량을 계산해보면 4194304 * 512 / 1024 / 1024 / 1024 = 2GB가 나옵니다. 실제로 용량을 확인해 보면 얼마가 나오는지는 스스로 확인해보시기 바랍니다.

이것으로 두번째 파티션의 간단한 분석까지 마무리가 되었다. 이제 세번째 파티션 정보를 간략히 분석해 보도록 하겠다.


[그림 11. Partition Table 상의 세번째 파티션 정보]

위 [그림 11]은 세번째 파티션의 정보를 가지고 있는 구간입니다. 그리고 우리가 확인해야 할 마지막 파티션이기도 합니다. 하나하나 확인 해 보도록 하겠습니다.

먼저 맨 처음에 오는 Boot Flag 값은 0x00, 즉 '이 파티션으로는 부팅할 수 없음'을 나타냅니다. 그 다음으로 봐야할 부분은 바로 Partition Type 입니다. 어라?? 근데 뭔가 이상합니다. 우리가 배운 Partition Type은 0x0B, 0x0C(이상 FAT32), 그리고 0x07(NTFS)뿐이 없습니다. 그런데 지금은 0x00인걸 봐서는 누군가가 MBR 영역에서 이 부분을 일부러 수정한 것으로 추정됩니다.

지금은 저 값을 바로 확인 할 수 없으니 다음 분석인 Start LBA Addr로 넘어가도록 하겠습니다. Start LBA Addr로 가면 BR영역을 확인 할 수 있으니 저 Partition Type도 확인 할 수 있을것입니다. Start LBA Addr은 0x600800, 즉 6293504 입니다. 한번 실제로 이동해 보도록 하겠습니다. 이제 BR 영역을 확인 할 수 있을것입니다.


[그림 12. 세번째 파티션의 Start LBA Addr 모습]

여기서 우리는 두번째 난관이 부딧칩니다. 아까는 Partition Type이 보이지 않더니 이번에는 BR영역에 있어야 할 내용이 아무것도 보이지를 않는 상황입니다. (눈치빠른 사람들은 이미 눈치 챘을겁니다.) 보통은 여기에 FAT32 BR이든 NTFS의 BR이든 무엇이든 보여야 할텐데 지금 이 부분은 텅 비어있습니다. 어차피 FAT32가 아니면 NTFS일테니 우선 FAT32 인지부터 확인 해 보도록 하겠습니다.


[그림 13. Start LBA Addr로부터 Offset 6 만큼의 Sector의 내용]

기존에 설명드릴 때 FAT32 File System의 백업 영역은 BR로부터 Offset 6만큼의 위치에 있다고 말씀드렸습니다. [그림 13]은 정확히 그 만큼의 위치이기도 합니다. 그러면 이게 세번째 파티션 파일시스템의 백업 영역이란 소리네요. 이 섹터의 내용을 복사해서 [그림 12]에 붙여넣도록 하겠습니다. 그리고 난 후에 MBR 영역으로 돌아가서 세번째 파티션의 Partition Type도 0x0B로 변경해 주도록 하겠습니다.

 * BR영역 바로 아래를 보고도 FAT32임을 유추해 낼 수 있습니다. 다만 그것도 확실한 정답은 아닐 수 있기 떄문에 실제로 확인하는 과정이 필요합니다.

Window를 재부팅하기 전에 마지막으로 확인해야 할 과정이 남아있습니다. 바로 Size in Sector 값을 구하는 것인데요. [그림 11]에서 세번째 파티션의 Size in Sector는 0x5FE800, 즉 6285312가 나오게 됩니다. 

마지막으로 방금 구한 SIze in Sector를 활용하여 세번째 파티션의 용량을 확인 해 보도록 하겠습니다. 구하는 공식은 Size in Sector(Dec) * 512 / 1024 / 1024 / 1024 입니다. 이를 계산해주면 2.997GB, 약 3GB가 나오게 됩니다,


Window XP를 재부팅과정까지 거쳤다면 방금전까지는 없었던 새로운 파티션이 하나 생겨납니다. 바로 훼손되어있던 Patition이 복구 된 모습입니다. 그 안에 들어가서 어떤 파일이 숨어있는지 확인 해 보겠습니다.

[그림 14. 복구 된 세번째 파티션의 FIle]

복원한 파티션 안에는 'Read me' 파일이 있고 파일을 열면 Good Job!!! 이라고 우리를 칭찬하는 문구가 보이네요. 축하드립니다. 여러분은 세번째 파티션을 복구했고 안에 있는 파일을 찾아냈습니다. 그리고 이것을 마지막으로 본 Recovery Training 문제를 클리어 하셨습니다.


마지막으로 문제의 전체 답을 풀어보도록 하겠습니다.

1. 파티션의 총 개수는? : 3개

2..각 파티션의 파티션 타입은(낮은 순으로) ? : FAT32, NTFS, FAT32

3. 손상된 파티션 테이블을 복구하라 : 세번째 파티션을 복구하는 과정입니다.

4. 각 파티션의 Start LBA Addr 은?(낮은섹터순, 단위 : 섹터(10진수) : 2097152, 4194304, 6285312

5. 각 파티션의 용량은 ? : 1GB, 2GB, 3GB

6. FAT32 포멧일 경우 해당 FAT32의 Backup BR 영역의 위치는?(낮은 섹터순, 단위 = 섹터 : 10진수) : 2054, 6293510

7. BR 영역이 손상된 파티션은 몇번째 파티션? : 3번째 파티션

8. 손상된 파티션에 들어있는 파일과 내용은? : Read_me.txt, Good Job!!! Part of the Partition table you've got it right!


이것으로 Day1 Recovery Training 풀이를 마치겠습니다.

다음은 Day1의 마지막 문제인 Hard Training 문제로 찾아뵙겠습니다.

'보안 > Forensics_In_DMA' 카테고리의 다른 글

Day1_Hard_Training(Lv.2)  (2) 2016.03.26
Day1 Hard_Training(Lv.1)  (0) 2016.03.16
Day1 Warming_Up 풀이  (0) 2016.03.06
스터디 1일차(Day1)  (0) 2016.03.02
본 디렉토리에 대하여..  (0) 2016.03.02
Posted by Latte_
,

안녕하세요. Latte_ 입니다.

이번엔 아까 링크드렸던 Day1 과정에 있는 문제풀이 중 Warming_up 과정을 풀이 할겁니다.

 * 본 실습 과정은 Window XP SP3 환경에서 진행되었습니다. 기타 OS를 사용하시는 분들께    서는 개인의 환경에 맞춰 진행 해 주시면 되겠습니다.

 * 본 과정을 위해 필요한 Tool 은 HxD 입니다. 아래 링크를 통해 다운받아 주시기 바랍니다.

   https://mh-nexus.de/en/downloads.php?product=HxD




FS_Day1_Warming_Up_Disk.z01


FS_Day1_Warming_Up_Disk.z02


FS_Day1_Warming_Up_Disk.z03


FS_Day1_Warming_Up_Disk.zip


저 파일들의 압축을 풀어주면 FS_Day1_Warming_Up_Disk.vmdk 파일을 확인 할 수 있습니다.

 * vmdk 파일은 VMware 가상 컴퓨터의 하드디스크 내용을 저장하는 가상 디스크 입니다.

   이 파일만 있으면 다른 VM에 인식시켜 다른 VM에서도 저장 내용을 불러올 수 있습니다.


해당 vmdk 파일을 아래와 같이 VMWare에 인식시킨 후 윈도우를 부팅시킵니다.

[그림 1. Virtual Machine Setting]

[그림 1]과 같이 Hard Disk 3 (뒤에 숫자는 개인 실습자 별 환경에 따라 차이가 있습니다.) 10GB로 뜨면 정상적으로 인식이 된 것입니다.

 * Hard Disk 인식 방법이 IDE 건 SCSI, 혹은 SATA 일지라도 실습에 영향은 없습니다.


작업을 마친 후 Window를 이미 켜신상태라면.. 윈도우를 반드시 재부팅 해 주시기 바랍니다.

 * XP의 경우 재부팅을 해야 새 Hard Disk를 인식 합니다.


재부팅 후 실행창에 diskmgmt.msc를 사용해서 디스크관리를 들어가면 아래와 같이 할당되지 않은 10GB 용량의 Hard Disk가 추가됨을 확인 할 수 있습니다.


[그림 2. 삽입된 Hard Disk를 확인 할 디스크 관리 창]

[그림 3. Hard Disk 삽입 후의 내 컴퓨터 화면]

[그림 2]에서 확인할 수 있는것처럼 Hard Disk가 정상적으로 삽입 되었음을 확인 할 수 있습니다. 그런데 여기서 한가지 알아야 할 점은 [그림 2]와 [그림 3]에서 보이는것처럼 실제 Hard Disk Drive에서 해당 디스크가 보이지 않는다는 점입니다.

 * [그림 2] 와 [그림 3]에서 보이는 LEVEL(1), LEVEL(2)는 추후에 다룰 Hard Traning 실습    과정에 사용되는 Hard Disk 입니다. 실제 실습자가 Warming_Up만 하고 있는 중이라면, 보    이는 화면은 로컬 디스크(C:)만 있어야 정상입니다. (물론 개인 실습 환경마다 다릅니다.)


Warming_Up 실습의 첫번쨰 과제는 이 Hard Disk에 접근할 수 있도록 세팅 해 주는 것입니다.

본래 정상적인 상태의 Hard Disk라면 삽입 후 재부팅을 했을 때 제대로 접근이 가능해야 하지만 현재의 Hard Disk는 어딘가에 이상이 있어 제대로 접근 할 수 없음을 보여줍니다.

 * 새 Hard Disk의 경우 포멧을 통한 파일시스템 설정이 필요하지만 본 과정은 이미 세팅 된      Hard Disk를 사용하는 과정이기 때문에 별도의 포멧과정이 필요하지 않습니다.


지금부터 실제 위에서 내준 문제를 하나하나 풀어보도록 하겠습니다.

먼저 HxD를 열어서 여러분이 삽입 한 Hard Disk를 선택해 주시기 바랍니다.


[그림4. HxD에서 Hard Disk 열기]

HxD는 여러분이 가지고 있는 파일/디스크 등을 Hexa Code로 보여주는 프로그램입니다. [그림 4]와 같이 디스크 모양을 클릭한 뒤 여러분의 Hard Disk 위치에 따라 맞는 Hard Disk를 선택해 주시기 바랍니다. (읽기 전용으로 보기는 향후 작업에는 해제 해야 하니 미리 해제해 주시기 바랍니다.)

 * 읽기 전용을 해지할 경우 실수로 저장을 하면 되돌릴 수 없는 상황이 나오기도 합니다.        그런 경우를 대비하여 미리 스냅샷을 이용해 언제든 복구 할 수 있도록 준비하도록 합니다.



[그림 5. 삽입 된 Hard Disk의 MBR]

실습 전 첨부한 PPT를 이미 보신 분들이라면 Hard Disk의 0번 섹터에 MBR(Master Boot Record)가 존재한다는 점을 다들 알고 계실 겁니다. 
MBR은 446 Byte의 Boot Code Area와 64 Byte의 Primary Partition Table, 그리고 2 Byte의 Signature로 구성되어 있습니다.

[그림 5]에서 주의깊게 봐야 할 부분은 붉은색 사각형으로 표시 된 Primary Partition Table 입니다. Primary Partition Table은 해당 hard Disk에 삽입 된 총 파티션의 갯수(최대 4개의 주 파티션 표기 가능)와 파티션 종류, 그리고 용량 등이 기록 된 내용입니다.

하나의 파티션 당 16 byte 씩, 총 4개의 주 파티션을 보여줄 수 있고 [그림 5]에서 볼 수 있듯이 현재 MBR에서는 2개의 파티션이 존재하는 것을 확인 할 수 있습니다.

그럼 여기서 Warming_Up 1번 문제의 답이 나왔네요. 총 파티션은 몇개인가? 2개입니다.


2번쨰 문제부터는 Primary Partition Table에서 각각이 나타내는것이 무엇인지 알아야합니다.


[그림 6. Primary Partition Table 정보]

[그림 6]과 같이 Partition Table은 각 파티션에 대한 여러가지 정보를 가지고 있습니다.

우리가 여기서 유심이 봐야할 부분은 바로 검은색 네모가 쳐진 4개 부분입니다. 과거에는 CHS Addr이 어느정도는 사용되었으나, 현재는 사용하지 않기 때문에 따로 본 풀이에서는 설명하지 않도록 하겠습니다.

 * 첨부한 PPT에 설명이 간략히 적혀있으니 참고하시기 바랍니다.


먼저 Boot Flag는 해당 파티션으로 부팅이 가능한지 여부를 알 수 있는 부분입니다. Boot Flag가 0x80이면 해당 파티션으로 부팅이 가능함을 의미하며, 0x00일 경우 부팅 할 수 없음을 나타냅니다.

[그림 5]의 첫번째 파티션 테이블과 두번째 파티션 테이블의 Boot Flag는 모두 0x00이다. 이는 두 파티션으로는 부팅을 할 수 없음을 의미한다.

그다음으로 중요시 봐야할 부분은 Partition Type이다. [그림 6]에서 보이는것처럼 CHS Addr 바로 다음에 오는 내용이 Partition Type인데 이 부분은 해당 파일시스템이 FAT32 인지 NTFS인지 알려주는 중요한 척도가 된다. 이 부분과 실제 Start LBA Addr이 같아야만 정상 작동된다.

WIndow File System의 경우 FAT32는 0x0B, 0x0C로 표기되며 NTFS의 경우 0x07로 표기된다. (0x0B나 0x0C나 어느것을 사용해도 문제가 발생하지 않는다. 다만 알파벳 표기 상 0x0B가 먼저 표기될 뿐이다.)

[그림 5]에서 각 파티션 타입은 0x00로 표시되어있다. 이는 누군가가 MBR을 건드렸다는 소리다. 이와 같은 경우에는 실제 Partition Type을 수동으로 찾아줘야 한다.


세번째 부분은 Start LBA Addr인데 이는 Partition의 시작위치를 알려준다. 즉, 이 하드디스크에서 몇번째 Sector부터 이 해당 파티션이 시작되는지를 알려주는 내용이다.

Start LBA Addr은 4 Byte로 구성되어있으며, Intel 기반의 경우 Little Endian 방식으로 저장된다. 아래 그림을 참조하자.


[그림 7. 빅 엔디언과 리틀 엔디언의 비교]

[그림 7]을 참고하여 [그림 5]의 두개의 Partition의 각각의 Start LBA Addr을 알아보도록 하겠습니다.

먼저 첫번쨰 파티션의 Start LBA Addr을 보면 3F 00 00 00 임을 알 수 있습니다. Little Endian 에 의하여 보면 실제로 저장된 값은 0x3F = 63 임을 알 수 있습니다.

두번째 파티션의 Start LBA Addr은 4D 12 A0 00 로 표기되어 있습니다. 역시 이를 Little Endian을 적용하여 확인하면 0xA0124D = 10490445 임을 확인 할 수 있습니다.

Start LBA Addr은 각 파티션의 시작을 의미하기 때문에 해당 값의 Sector로 이동하면 파티션의 BR, 즉 Boot Record로 이동하게 됩니다. BR에 대해서는 차후 스터디과정이 진행되면 다루게 될 내용이며 본 단계에서는 BR영역에서 Partition Type이 무엇인지 확인하는 과정만 다룰 예정입니다.

 * 간단한 팁입니다만, MBR에서  첫번째 파티션의 Start LBA Addr이 3F, 즉 63이면 OS가      Window XP일 확률이 굉장히 높습니다. WIndow 7의 경우는 보통 2048에서 시작합니다.


먼저 첫번째 파티션의 Start LBA Addr로 가서 파티션 타입을 알아보도록 하겠습니다.


[그림 8. 1st primary Partition의 Start LBA Addr 내용]

첫번째 파티션의 시작지인 63 Sector로 가게되면 [그림 8]과 같은 내용을 확인 할 수 있습니다. 한번 훝어보면 눈에 확 띄는 단어를 하나 확인 할 수 있습니다. 바로 NTFS 입니다. 저 NTFS가 표기되어있는 부분을 OEM Name이라고 하는데, 이 부분은 차후에 Day2에서 다룰 예정이며 OS, 혹은 Disk의 디지털 이름정도로 보시면 됩니다. 그러나 여기서 한가지 중요한 점은, OEM Name은 단순히 디지털 이름일 뿐 실제로 읽어들일 떄 참조하는 부분이 아니기 때문에 해당 내용으로 파일 시스템을 판단하시면 안됩니다. 자.. 그럼 1번 파티션 타입은 NTFS임을 확인 할 수 있네요. 0번 섹터로 가서 파티션 타입을 0x07로 수정하러 가야겠습니다.


위와 같이 생각하시는 분이 계시다면,.. 잠시만 그 손길을 멈춰 주시기 바랍니다. 모든 일에는 확인 과정이 필요합니다.

모든 BR(Boot Record)은 Backup Area를 가지고 있습니다. 이는 BR이 손상되었을 경우 Backup Area에 저장된 값을 불러와 복원하기 위함입니다. FAT32의 경우 BR영역으로 부터 Offset 6 Sector (즉, 6 sector 뒤)에 Backup 영역이 존재하며 NTFS의 경우 보통 파티션의 마지막에 Backup Area를 위치시킵니다. (NTFS Addr + NTFS Total Sector(Offset T.S))

현재 [그림 8]의 BR은 자신이 NTFS임을 가르키고있으니, 실제 Backup Area가 파티션 끝에 있는지 확인해 보도록 하겠습니다.

다시 [그림 5]로 돌아가서 첫번쨰 파티션 내용을 확인합시다. 그리고 [그림 6]으로 가서 Size in Sector를 보시기 바랍니다. Size in Sector는 파티션의 전체 크기를 나타냅니다. 

이를 기반으로 바로 위에서 설명드린 첫번쨰 파티션의 마지막 위치(NTFS Backup Area로 추정되는)를 찾아보도록 하겠습니다. NTFS의 Backup Area는 파티션 가장 끝에 위치하기 때문에 파티션의 BR을 기준으로 Size in Sector 만큼 더한 뒤 1을 빼면 파티션의 마지막 Sector가 나오게 됩니다.

 * -1이 들어가는 이유는 실제 계산 시 Start LBA Addr + Size in Sector를 하게 되면 파티션    의 마지막이 아닌 다음 파티션의 BR로 가게 되기 때문입니다. 섹터의 시작이 1이 아닌 0인    만큼 offset으로 계산할 경우 실제 더한값에서 1을 빼주어야 마지막 섹터가 오게 됩니다.

그럼 한번 계산해보도록 하겠습니다. 아까 첫번쨰 파티션의 Start LBA Addr이 0x3F 였고 Size in Sector가 0xA0120E가 나왔습니다. 알려드린 대로 계산해보면, 0x3F(63) + 0xA0230E(10490445) -1 = 10490444 라는 값이 나오게 됩니다.

실제로 해당 Sector로 이동하게 되면 아래 [그림 9]와 같이 빈 공간만 나오게 됩니다.

[그림 9, 1st Primary Partition의 가장 마지막 Sector]


여기서 한가지 이상한 점을 발견할 수 있습니다. 위에서 분명 NTFS 파일시스템의 Backup 영역은 파티션의 맨 뒤에 있다고 이야기 했습니다. 그런데 이 NTFS 파일시스템은 파티션 맨 끝으로 와도 Backup 영역이 존재하지 않습니다. 이 파티션은 Backup 영역도 날아간 걸까요??

결과부터 이야기하자면 아닙니다. 위에서 간단히 설명드렸다 싶이 OEM Name은 단순히 디지털 이름일 뿐 실제로 읽어드릴 때 참조하는 값이 아닙니다. 즉 OEM Name도 변경 가능하다는 것입니다. 

이 파티션이 NTFS가 아니라면, 남은 가능성은 FAT32 하나 뿐 입니다. 위에서 말씀드렸듯이 FAT32의 Backup Area는 BR영역으로부터 Offset 6 만큼 뒤에 존재합니다. 첫번째 파티션의 BR영역이 63 Sector에 위치했던만큼, 만약 이 파티션이 FAT32라면 Backup 영역은 69 Sector에 위치하게 될 것입니다.


[그림 10. 69 Sector에 존재하는 FAT32 Backup Area]

이럴수가..! 69 Sector에 FAT32 처럼 보이는 BR영역이 존재하네요. 기억력이 좋으신 분이나 눈치가 빨라서 위로 한번 올라가셨던 분들은 기억하실 겁니다. FAT32의 Backup Area는 BR 영역으로부터 offset 6만큼 간 지점이라는 것을 말입니다. 그리고 조금만 내려가다보면 실제로 FAT32라는 값도 확인 할 수 있습니다. 자 Backup 영역을 확인했다면 이제는 이 부분을 원본으로 그대로 복사 붙여넣기 해 주시면 됩니다. 아! 그리고 Primary Partition Table에서 Partition Type을 0x0B로 바꾸는것도 잊으시면 안됩니다.

 * 또하나의 팁을 알려드리겠습니다. BR영역 진입후에 FAT32 와 NTFS를 더 빨리 구분 할 수 있    는 방법이 있습니다. 바로 BR 영역 바로 다음 Sector를 보는 방법입니다. FAT32 의 경우 BR영    역 뒤는 예약 공간으로 보통 비어있습니다.(자세한 내용은 Day2에서 진행 될 예정입니다.) 반    면 NTFS는 BR영역 뒤에 내용이 비어있지 않습니다. 이 점을 가지고도 쉽게 찾는게 가능합니    다.(하지만 직접 찾아보는 습관을 들이는게 좋습니다.)


그리고 사뿐히 재부팅을 한번 해주시면 [그림 11]과 같이 여러분이 그토록 찾아야 했던 첫번쨰 파티션에 들어갈 수 있게 됩니다.

[그림 11. 복구한 첫번쨰 파티션]

그럼 첫번째 파티션을 풀었으니, 2번 문제도 답이 나왔습니다. FAT32 파티션은 존재하는가? 정답은 '존재한다' 입니다.


그럼 두번째 파티션도 복구 해 보도록 하겠습니다. [그림 5]에서 두번쨰 파티션의 Start LBA Addr은 4D 12 A0 입니다. 이를 Little Endian 표기법으로 계산하면 0xA0124D = 10490445 가 됩니다.


[그림 12. 2st 파티션의 Start LBA Addr 에 위치하는 BR 영역]

이번 두번쨰 파티션의 BR영역은 자신이 FAT32 영역이라고 소개하고 있습니다. 위에서 부터 잘 따라오신 분들이라면 이 BR영역은 FAT32 가 아니라고 이미 판단하고 계실겁니다. FAT32 의 경우 BR 영역 바로 뒤가 비어있다고 말씀드렸는데 지금은 비어있지 않기 때문입니다. 그럼 실제로 확인하러 가 보도록 하겠습니다.


[그림 13. 2번째 파티션의 BR영역으로 부터 Offset 6만큼 뒤의 Sector의 내용]

만약 2번쨰 파티션의 타입이 FAT32 라면 6 Sector 뒤의 값이 BR 영역과 같아야 합니다. 그러나 [그림 12]와 [그림 13]은 확연히 다른 모습을 하고 있습니다. 이는 이 파티션은 FAT32 가 아니라 NTFS 타입의 파티션이라는 것을 확인 할 수 있습니다. 자, 그럼 정말 NTFS 파티션인지 확인하러 가 보도록 하겠습니다.

NTFS의 Backup Area는 NFTS BR + Total Sector(offset T.S)라고 설명드렸습니다. [그림 5]로 다시가서 2번쨰 파티션의 BR영역의 값은 4D 12 A0 이며 Size of Sector 는 8C D3 9F 입니다. 이를 10진수로 바꿔서 계산해보면 0xA0124D(10490445) + 0x9FD38C(10474380) = 20964825 이 됩니다. 여기서 첫번째 BR영역이 1부터가 아닌 0부터 시작이라고 생각하면 1을 더 빼줘야 하기 때문에 20964824 Sector가 2번쨰 파티션의 Backup Area가 됩니다.


[그림 14. 2번쨰 파티션의 NTFS Backup Area]

계산을 토대로 두번째 파티션의 가장 끝에서 NTFS Backup Area를 확인 할 수 있었습니다. 그럼 [그림 14]의 내용을 복사해서 [그림 12] 부분에 붙여넣어 준 뒤 MBR로 돌아가서 두번쨰 파티션의 타입을 0x07로 바꿔주면 되겠습니다. 그리고 첫번째 파티션을 복구했을 떄와 마찬가지로 Window를 재부팅 한 뒤 내 컴퓨터에서 새로운 파티션이 추가되었는지 확인 합니다.


[그림 15. 모든 파티션을 복구 한 후 내 컴퓨터 화면]

두번쨰 파티션까지의 복구가 끝났다면 문제 3번인 NTFS 파티션은 존재하는가? 라는 문제의 답도 확인이 가능합니다. 정답은 '존재한다' 입니다. 추가적으로 바로 그 다음 문제인 각 파티션별 용량은 얼마인가 역시 확인이 가능합니다. 정답은 '각각 5GB' 입니다.


다음 문제는 첫번째 파티션에 있는 파일의 이름 및 확장자명을 찾아내는 문제입니다. 첫번쨰 파티션으로 들어가면 아래 [그림 16]과 같이 확장자명 없이 존재하는 파일 하나를 확인 할 수 있습니다.


[그림 16. 첫번쨰 파티션 안에 있는 파일]

5번의 문제는 첫번째 파티션 안에있는 파일의 이름과 확장자 명을 적으라는 문제입니다. [그림 16]에서 볼 수 있듯이 실제 존재하는 파일은 파일명만 있을 뿐 확장자 명은 존재하지 않습니다. 그럼 어떻게 확장자명을 확인할 수 있을까요? HxD로 저 파일을 열어 보도록 하겠습니다.


[그림 17. KEEEEEEEEEEEEEY 파일의 HxD 화면]

[그림 17]에서 우리눈에 가장 익숙하게 먼저 보이는 단어가 하나 있습니다. 바로 PNG 입니다. PNG는 그림파일 확장자 중 하나입니다. 물론 여러가지로 확인을 해 봐야 합니다. 아래 사이트에서 PNG의 시그니처 값을 확인 해 보도록 하겠습니다.

http://www.garykessler.net/library/file_sigs.html

[그림 18. PNG 파일의 Signature]

[그림 18]에서 볼 수 있는 것처럼 PNG 파일은 89 50 4E 47 0D 0A 1A 0A로 시작해서 49 45 4E 44 AE 42 60 82로 끝납니다. 실제로 파일의 맨 끝으로 가보면 동일하게 끝나는 것을 볼 수 있습니다.


[그림 19. KEEEEEEEEEEEEEY 파일의 Tail 부분]

한번 분석하시면서 PNG 파일의 구조를 한번 찾아보시면 HxD에 나오는 구조와 비슷하게 나오는 것을 확인 하실 수 있습니다. 그럼 이 파일이 PNG 파일임을 확인을 했으니 .png로 저장을 해 보도록 하겠습니다.


[그림 20. KEEEEEEEEEEEEEY.png 파일 실행화면]

음?? Fake 라네요.. 심지어 저보고 멍청한 놈이라고 놀리고 있습니다. 그럼 다른부분으로 분석해 볼까요.. 네.. 그렇게 30분이 흐르고 1시간이 흘러도 발견되는건 아무것도 없습니다. 이 파일은 흔히 CTF 문제에서 출제되는 시간끌기용 파일입니다. 저렇게 Fake라고 쓰여져있지만 실제로는 저 그대로가 답입니다. 저기에 휘말리게 되면 스스로 2중 훼이크에 걸리게 됩니다.

 * PPT를 받아보신 분들 중 답을 이미 확인하신 분들은 확장자가 png가 아닌 dib로 되어있는    것을 보신분들도 있을겁니다. Signature 상으로는 png가 맞습니다만, 실제로 dib나 bmp      파일로 변경해도 정상적으로 작동됩니다.

그럼 5번 문제의 답도 나왔네요. 정답은 'KEEEEEEEEEEEEEY.png' 입니다.


이제 6번 문제로 넘어가보도록 하겠습니다. 6번은 2번 파티션 안에 있는 파일의 이름과 확장자명을 구하라는 문제입니다.

[그림 21. 2번째 파티션에 존재하는 Tail 파일]

두번째 파티션에 존재하는 Tail 파일역시 확장자가 따로 존재하지 않습니다. 첫번째 파티션에 있던 파일과 동일하게 HxD에서 열어보도록 하겠습니다.


[그림 22. Tail 파일의 HxD 화면]

Tail 파일은 길이가 월등히 짧네요. 보통 모든 파일은 맨 앞에 그 파일 확장자에 맞는 Signature값이 들어옵니다. 그런데 이 파일은 맨 앞줄이 비어있습니다. 그리고 아무런 힌트도 없습니다. 그럼 머리를 굴려서 생각을 해봐야합니다. 

보통 CTF 문제의 경우 문제에 힌트가 주어지는 경우도 있고, 파일명 자체에 힌트가 주어지는 경우도 있습니다. 이번 문제의 경우 파일명에 힌트가 주어진 경우입니다. Tail, 즉 꼬리라는 힌트가 주어진 것입니다.

[그림 22]에서 맨 마지막 줄로 가보면 PK로 시작하는 문장이 있습니다. 이미 어느정도 공부를 해 보신분들은 아시는 내용이겠지만, 보통 ZIP 파일의 확장자명이 50 4B 03 04로 시작합니다.


[그림 23. ZIP 확장자 파일의 Signature]

한편으로 생각하면 어느정도는 센스가 필요한 문제입니다. 제목과 파일시그니처를 이용헤 연관시키는 능력이 필요한 부분이죠. 자, 다시 [그림 22]로 돌아가서 맨 마지막 줄을 맨위로 올려준 뒤 확장자를 zip으로 바꿔 저장해줍니다.

[그림 24. Tail.zip 파일 복구 후 HxD 내용]

복구한 Tail.zip을 압축 풀기를 시도하면, 암호를 입력하라고 [그림 25]와 같이 암호를 입력하라고 나옵니다.

다시 살포시 X표를 눌러 꺼준 뒤 Tail.zip 파일을 더블클릭해 열면 안에 KEY.rtf 파일이 하나 존재합니다. 그 파일을 열면 [그림 26]과 같이 의미를 알수 없는 문장이 나타납니다.

[그림 26. KEY.rtf 파일의 내용]

KEY란 이름을 가진 파일안에서 알수없는 의미의 암호가 나타났습니다. 그럼 저 내용을 암호란에 대입해 볼까요? 아.. 물론 맞지 않습니다. 도대체 저 정체불명의 문장은 어떤 것일까요.아, 물론 우리가 할 일은 KEY를 찾는거죠..

사실 저 내용은 어떠한 문장이 인코딩 된 내용입니다. 그럼 어떤식으로 인코딩 되었는냐가 관건인데요. 인코딩 방식에는 여러가지가 있습니다. Base64, MD5, SHA-1, SHA-2 등등.. 그러나 SHA 인코딩는 [그림 26]같은 방식을 보이지 않기 때문에 예측범위 내에서 제외시켰습니다. 그럼 먼저 Base64 를 이용해서 Decode 해보도록 하겠습니다.

Decode 사이트는 상당히 많습니다. Google에서 Base64 Decoder라고 치면 굉장히 많은 사이트가 나오게 됩니다. 제가 시험해본 사이트는 아래의 URL에 존재합니다.

https://www.base64decode.org/

그리고 분석 결과는 [그림 27]과 같습니다.

[그림 27. KEY.rft 파일 안의 내용을 Decoding 한 결과 값]

자, 이것으로 모든 문제를 풀 수 있게 되었습니다. 아래에 위에 써져있는 문제의 답을 한번에 정리 해 보도록 하겠습니다.

1) 총 파티션 수 : 2개

2) FAT32 파티션은 존재하는가? : 존재한다.

3) NTFS 파티션은 존재하는가? : 존재한다.

4) 각 파티션의 용량은? : 5GB, 5GB

5) 첫 번째 파티션에 있는 파일 이름은?(확장자 포함) : KEEEEEEEEEEEEEY.png

6) 두 번째 파티션에 있는 파일 이름은?(확장자 포함) : Tail.zip

7) BR 영역에서 올바르지 않은 점은? : BR영역이 서로 뒤바뀌어 있었다.(FAT32인데 NTFS로, NTFS인데 FAT32로)

8)KEY 값은 무엇인가?(Key is 로 시작함) : Key is :)_Start_Forensic


한번에 다 쓰다보니 내용이 좀 길어졌네요. 제가 혼자 정리할 떈 이렇게 길지 않았던거 같은데... 중간중간 설명이 들어가면서 좀 길어진 것 같습니다.

다음번에는 아마 Day1 의 다른 문제인 Training_Disk 문제로 찾아올 예정입니다.

이 내용을 보고 도움이 되시길 바라며, 열심히 공부하시길 바랍니다.

감사합니다.


'보안 > Forensics_In_DMA' 카테고리의 다른 글

Day1_Hard_Training(Lv.2)  (2) 2016.03.26
Day1 Hard_Training(Lv.1)  (0) 2016.03.16
Day1 Training 풀이  (0) 2016.03.07
스터디 1일차(Day1)  (0) 2016.03.02
본 디렉토리에 대하여..  (0) 2016.03.02
Posted by Latte_
,

안녕하세요. Latte 입니다.

이번엔 DMA 첫 스터디 관련 내용입니다.

다만 스터디관련 내용은 이미 Eniac님의 블로그에 잘 정리가 되어있기 때문에 그쪽 링크만 첨부해 드리니 확인해 보시기 바랍니다.


Day1 요약

1. MBR(Master Boot Record) 구조체와 역할에 대한 이해

2. MBR Partiton Table 상세분석

3. 각 File System 설계 목적과 탄생 이유에 대한 이해

4. FAT32 / NTFS 의 차이점에 대한 이해

5. BR(Boot Record) 구조체에 대한 이해

6. Backup의 중요성에 의한 File System BR Backup 영역에 대한 이해


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


'보안 > Forensics_In_DMA' 카테고리의 다른 글

Day1_Hard_Training(Lv.2)  (2) 2016.03.26
Day1 Hard_Training(Lv.1)  (0) 2016.03.16
Day1 Training 풀이  (0) 2016.03.07
Day1 Warming_Up 풀이  (0) 2016.03.06
본 디렉토리에 대하여..  (0) 2016.03.02
Posted by Latte_
,

안녕하세요. Latte 입니다.

사실 필명을.. 뭘 쓸까 고민을 하다가.. 최근 제가 게임에서 라떼 라는 아이디를 부케로 많이 이용하고 있다보니.. Latte 라는 용어를 하게 되었습니다.

잡소리는 여기까지만하고.. 이제 슬슬 이야기를 진행 해 보도록 하죠.


DMA(Digital Media Analysis)라는 팀을 아시는 소수의 분들은 최근 우리가 Forensic 스터디를 하는것을 알고 계실 겁니다.

간단히 소개를 하고가면.. DMA는 Digital Media Analysis의 약자로 Forensic을 좋아하고 그 길로 가는 사람들을 모아서 만든 디지털포렌식 전문 팀 입니다. 물론 전문이 되기위함이 목표이긴 합니다만.. 그 길을 가기위해 스터디를 진행하고 있습니다.


본 블로그는 현재 DMA 에서 FAT 및 NTFS 강의(?)를 담당하고 있는 Eniac님의 블로그와 연계하여 DMA 수업의 전반적인 과정을 함께 나눌 계획입니다.


여기에 수업에 대한 설명부분을 넣을지는.. 좀 더 상의를 해 봐야 할거 같지만, 아마 본 블로그에는 수업 내용에 대한 부분은 링크로만 남겨질 예정입니다.


그럼 다음 포스팅에는 Warming_Up 문제로 찾아뵙겠습니다.

'보안 > Forensics_In_DMA' 카테고리의 다른 글

Day1_Hard_Training(Lv.2)  (2) 2016.03.26
Day1 Hard_Training(Lv.1)  (0) 2016.03.16
Day1 Training 풀이  (0) 2016.03.07
Day1 Warming_Up 풀이  (0) 2016.03.06
스터디 1일차(Day1)  (0) 2016.03.02
Posted by Latte_
,

지난번에 말씀드린 대로 오늘은 범용 레지스터(General Purpose Register)에 대해 포스팅 할 예정입니다.

범용 레지스터는 말 그대로 범용적으로 사용되는 '막 쓰는 레지스터' 라고 생각하시면 편합니다. IA-32에서 범용 레지스터의 크기는 32비트(4바이트)로 보통 상수/주소 등을 저장할 때 사용되기도 하고 특정 어셈블리 명령어에서는 특정 레지스터를 조작하는데 사용되기도 합니다.

아래 그림을 보면 범용 레지스터들을 표현한 것을 볼 수 있습니다.


그림 1.1 범용 레지스터

31

16

15

8

7

0

16-bit

32-bit

 

AH

AL

AX

EAX

 

BH

BL

BX

EBX

 

CH

CL

CX

ECX

 

DH

DL

DX

EDX

 

BP

 

EBP

 

SI

 

ESI

 

DI

 

EDI

 

SP

 

ESP

그림 1.1에서 볼 수 있듯이 각 레지스터들은 16비트 하위호환을 위해 몇개의 구역으롤 나뉘어 있습니다. 32bit EAX를 기준으로 간단히 설명하겠습니다.

EAX : (0~31) 32bit

AX : (0~15) EAX이 하위 16bit

AH: (8~15) AX의 상위 8bit

AL: (0~7) AX의 하위 8bit

위에서 볼 수 있는 것처럼 하나의 32비트 레지스터는 상황에 맞게 8비트, 16비트, 32비트로 알뜰살뜰 사용 할 수 있으니 구획 개념을 확실히 잡고가면 앞으로 디버깅 할 어셈블리 코드를 보다 쉽게 볼 수 있습니다.


각 레지스터의 이름은 아래와 같습니다.

EAX(Extended Accumulator Register) : Accumulator for operands and results data (연산과 결과 Data를 위한 누산기)

EBX(Extended Base Register) : Pointer to data in the DS segment (DS 세그먼트의 데이터 주소)

ECX(Extended Counter Register) : Counter for string and loop operations (문자열과 반복 명령을 카운트하기 위한 레지스터)

EDX(Extended Data Register) : I/O pointer (보통은 EAX와 함께 쓰이며 부호 확장 명령등에 사용)


보통 위의 4개의 레지스터는 산술 연산(ADD, SUB, XOR, OR등)명령어에서 상수/변수 값의 저장 용도로 많이 사용된다. 특정 명령어는 특정 레지스터를 직접 조작하기도 하니, 알아두면 좋다.(여기서는 언급하지 않도록 하겠다.)

그리고 ECX와 EAX는 조금 특수한 용도로도 사용되는데, ECX는 반복 명령어(LOOP)가 나오면 반복 카운트로 사용된다.(한번 반복될 때 마다 ECX 값이 1 감소한다.) 

EAX는 함수 리턴 값에 사용되는데 모든 Win32 API 함수는 리턴값을 EAX에 저장한 후 리턴 한다.


나머지 범용 레지스터들은 아래와 같다.

EBP(Extended Basse Pointer) : Pointer to data on the stack(in the SS segment) (스텍 프레임의 시작 지점 주소 - 스택의 처음을 가르킴)

ESI(Extended Source Index) : Source pointer for string operations (문자열 명령어 조작을 위한 Source Data의 주소가 저장)

EDI(Extended Destination Index) : Destination pointer for string operation (문자열 명령어 조작을 위한 목적지 주소가 저장)

ESP(Extended Stack Pointer) : Stack pointer(in the SS segment) (스텍 프레임의 끝 주소가 저장)


앞에서 설명한 4개의 범용 레지스터가 주로 산술연산에 사용 된다면, 방금 언급한 4개의 범용 레지스터는 주로 메모리 주소를 저장하는 포인터로 사용된다.

먼저 ESP는 스텍 메모리 주소를 가리키는데 특정 명령어들(PUSH, POP, CALL, RET)은 ESP를 직접 조작하기도 한다. 한가지 주의할 점이 있다. 스택 메모리 관리는 프로그램에서 굉장히 중요한 역할을 하기 때문에 ESP를 다른 용도로 사용해서는 안될 것이다.

EBP는 함수가 호출될 때 그 순간의 ESP를 저장하고 있다가 함수가 리턴하기 직전에 다시 ESP값을 돌려줌으로써 스택이 깨지지 않도록 돕는 역할을 합니다. 이를 스텍프레임(Stack Frame)이라고 합니다.

ESI와 EDI는 특정 명령어들과 함께 메모리 복사에 사용되므로, 해당 명령어들과 함께 공부하면 도움이 될 것입니다.


범용 레지스터는 '막 사용하는' 레지스터 라고 말씀드리긴 했습니다만.. 그렇다고 무턱대고 '막' 쓰면... 안되는거 아시지요 ? ㅎㅎㅎ 특정 레지스터는 그 레지스터만의 역할이 따로 있기에.. 잘 확인 하고 사용해 주셔야 합니다.


다음 포스팅에는 세그먼트 레지스터(Segment Register)에 대해서 알아보도록 하겠습니다.

Posted by Latte_
,

레지스터에 대해서는 두 세번정도로 나누어 포스팅을 할 예정입니다.

레지스터 자체가 굉장히 기본이 되는 부분이기도 하고, 스택등과 더불어 툴을 쓸 때 가장 많이 볼 부분이 그 부분이기 때문입니다.

이번 포스팅에서는 레지스터가 무엇인지 알아보는 시간을 갖도록 하겠습니다.


레지스터(Register)란?

 레지스터는 CPU에 존재하는 다목적 저장 공간 입니다. 우리가 흔히 메모리라고 이야기하는 RAM(Random Access Memory,이하 램)와는 조금 다른 성격을 가집니다.

레지스터와 램은 데이터와 명령어를 저장하는 점에서는 동일한 성격을 지닙니다. 다만 램은 CPU와 한몸이 아니라 하나 또는 그 이상의 마이크로 칩으로 이루어져 있으며, CPU와 물리적으로 가까운곳에 위치합니다.

그래서 램에 있는 데이터에 접근(Access)하기 위해서는 물리적으로 먼 길을 돌아가기 때문에 시간이 오래 걸리게 되는데 반해 레지스터는 CPU와 함께 붙어있기 때문에 고속으로 데이터를 처리 할 수 있습니다.


레지스터는 왜 알아야 하는가?

 지금 이 글을 포스팅하는 저를 포함한 많은 리버스 엔지니어링을 공부하는 사람들은 초급단계로 디스어셈블을 통한 어셈블리 명령어를 해석하게 됩니다.

그런데 이 어셈블리 명령어라는 녀석들은.. 대부분 레지스터를 조작하고, 내용을 검사하는 일을 합니다. 즉, 레지스터에 대해 알지 못하면 리버싱을 할 수 없다는 소리가 됩니다. 물론 볼 때 마다 하나하나 찾아가며 하는 방법도 있겠습니다만.. 효율적인 면이나 능률적인 면에서 보면 공부해서 아는 것이 육체적으로나 정신적으로나 큰 도움이 될거라고 생각 됩니다.


IA-32(Intel Architecture 32bit)는 수많은 기능을 제공하며, 또 그만큼 많은 수의 레지스터를 보유하고 있습니다. 앞으로 이어질 세개의 포스팅에서는 오늘 간단하게 언급하고 넘어갈 레지스터인 Basic program execution register에 대해 이야기 할 예정입니다.

물론 이외에도 Memory Management Register, Machine specific register, Control register 등이 존재하지만.. 이는 향후에 좀더 깊게 설명할 때 다시 언급하기로 한다.


다음 포스팅에 설명할 Basic program execution register의 4개 그룹을 간단하게 언급하고 다음 포스팅에서 뵙도록 하겠습니다.

 - General Purpose Registers(범용 레지스터)

 - Segment Register(세그먼트 레지스터)

 - Program Status and Control Register(프로그램 상태 및 컨트롤 레지스터)

 - Instruction Pointer(명령어의 주소)


다음 포스팅에서는 범용 레지스터에 대해서 포스팅 할 계획입니다.

Posted by Latte_
,

바이트 오더링(Byte Ordering)은 컴퓨터에서 메모레이 데이터를 저장하는 방식을 의미한다.

바이트 오더링은 크게 두종류로 나뉘는데 리틀 엔디언(Little Endian), 빅 엔디언(Big Endian)으로 구분 할 수 있다.


간단하게 쉽게 설명부터 하자면, 빅 엔디언 방식은 데이터를 입력한 순서대로 저장합니다. 주로 대형 UNIX 서버에서 사용되는 RISC(*1)(Reduced Instruction Set Computer) CPU 또는 네트워크 프로토콜에 사용 합니다.

빅 엔디언의 장점은 데이터를 순서대로 저장하기 때문에 직관적이라는 점입니다. 뒤에서 다시 설명하겠지만 빅 엔디언과 리틀 엔디언의 가장 큰 차이점은 일부 자료형에 따른 저장방식이 다르다는 점입니다.

빅 엔디언의 경우 전 자료형에 대해 입력한 순서대로 저장하지만, 리틀 엔디언의 경우는 WORD형과 DWORD 자료형에 대해서는 입력한 순서와 반대로 저장합니다.

아래의 예를 들어 빅 엔디언을 설명하겠습니다.

- 코드(1.1)

BYTE b = 0x12;

WORD w  = 0x1234;

DWORD dw = 0x12345678;

char str[] = "abcde"; 

- 빅 엔디언 표기(표 1.1)

 Type

Name

Size 

빅 엔디언 표기

BYTE

b

1

 [12]

WORD

w

2

[12][34] 

DWORD

dw

4

[12][34][56][78]

char[]

str

6

[61][62][63][64][65][00]

표 1.1에서 보는것과 같이 빅 엔디언은 값을 입력한 대로 저장한다. 마지막 char형의 경우 마지막에는 NULL값이 들어가기 때문에 [00]이 포함된다. 

그럼 동일한 값을 리틀 엔디언 표기법으로 저장하면 어떻게 될까?


-리틀 엔디언 표기(표 1.2)

 Type

Name

Size 

리틀 엔디언 표기 

BYTE

[12]

WORD

[34][12] 

DWORD 

dw 

[78][56][34][12]

char[] 

str 

[61][62][63][64][65][00] 

표 1.2에서 보는것과 같이 리틀 엔디언은 WORD형과 DWORD형에서는 입력된 순서와 반대로 값을 저장한다.


리틀 엔디언 방식의 경우 바이트 자체는 입력한 순서대로 저장이 되지만, WORD나 DWORD처럼 멀티 바이트(Multi-BYTE)의 경우에는 각 바이트가 역순으로 저장이 된다. 빅 엔디언이 직관적인 면에서 더 우월하기 때문에 소프트웨어 디버그가 편한 반면, 리틀 엔디언 방식은 산술 연산 및 데이터 타입의 확장/축소 시 더 편한 장점을 가지고 있다.

표 1.2를 보면, 문자열은 빅 엔디언과 동일한 방식으로 저장이 됨을 볼 수 있는데 이는 문자열은 결국 char 배열이기 때문에 각 바이트를 하나씩 연속해서 저장하기 때문에, 리틀 엔디언도 문자열 자체는 빅 엔디언과 동일하게 저장한다고 보면 된다.


*1) RISC : Reduced Instruction Set Computer의 약자로 말 그대로 풀어쓰면 '명령어 세트 컴퓨터' 라고 한다. 기존 CICS(*2)에 존재하는 수많은 명령어와 주소모드 중 실제 사용되는 명령어는 몇개 되지 않는다는 사실을 바탕으로 적은 수의 명령어만으로 명령어 집합을 구성한 방식이다. 

*2) CICS : Complex Instruction Set Computer의 약자로 복잡한 명령어 집합을 갖는 CPU 아키텍처. 주로 메인프레임이나 X86 호환 프로세에서 이 방식을 사용하고 있다.

Posted by Latte_
,