Day1 Hard_Training(Lv.1)

안녕하세요. 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을 통과하셨습니다.(저 혼자 풀었으니.. 제가 축하를 받아야 하는 부분일까요?)