Day1 Warming_Up 풀이

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

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

감사합니다.