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

안녕하세요. 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 문제로 찾아뵙겠습니다.

안녕하세요. 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 문제로 찾아올 예정입니다.

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

감사합니다.