Latte의 보안이야기

* 들어가기에 앞서 본 스터디에 사용 된 OS 종류 및 VMware 종류에 대해 기술하고 시작하고자 한다. 다른 버전이어도 상관은 없으나, 사용 상 불편한 부분까지 본 블로그에서 일일히 다루어 주지는 않는다. 물론, 질문을 남겨줄 경우, 따로 확인해서 답변을 드리긴 하겠다.

  - 필자 E-Mail : wotmd9408@naver.com

  - 가상머신 : VMWare WorkStation 12

  - OS : Window7 Enterprise K 64bit

  - RAM : 1GB

  - 나머지 사항은 기본적인 세팅으로 설정하였다.

  - 추가 필요 Tool : Hxd(https://mh-nexus.de/en/downloads.php?product=HxD)

파일시스템은 현대 모든 운영체제의 기본 구성 요소로 '컴퓨터에서 파일 또는 자료를 쉽게 발견 및 접근할 수 있도록 보관하는 조직 또는 체계'를 의미한다.

파일시스템은 크게 디스크, 네트워크 그리고 특수용도의 파일 시스템으로 나눌 수 있으며, 이번에 다루기 시작해 한동안 다룰 파일 시스템은 FAT32(Window에서 사용되는 파일 시스템. 기존 XP까지 주력 파일시스템으로 사용되었으며 Window7 이후 NTFS를 주력으로 사용 중)이다.

파일시스템 파트는 일단 MicroSoft사 OS인 Window 파일시스템부터 시작할 예정이며 가장 먼저 FAT32로 진행 할 예정이다.

FAT32에 대해 이야기하기 전에, 간단이 짚고 넘어가야 할 부분이 있다. 바로 MBR이다.

Master Boot Record(이하 MBR)은 간단히 말하면 디스크의 정보를 담고 있는 영역을 말한다. 모든 디스크의 시작 지점(0번 Sector)부터 512Byte의 크기를 가지고 있으며, 그 안에는 Master Boot Code와 Partition Table Area, 그리고 Signature를 포함하고 있습니다.

  * 아래 그림에 대한 실제 실습 과정은 다음 FAT32 파트에서 다루도록 한다.

<그림 1. MBR 구조>

위와 같이 크게 세 부분으로 구분되어있는 MBR은 전체 512 Byte 중 대부분을 부트코드로 채우고 있다. 또한 파티션 테이블(그림 1의 Partition Area)를 가지고 있는데, 이는 MBR의 가장 최종목표가 바로 부팅임을 알려주고 있다. 

MBR에서 가장 많은 영역을 차지하는 부분은 부트코드인데 440Byte 크기를 차지하고 있다. 부트코드는 부팅을 위해 파티션 내의 BR을 호출하는 과정이 프로그래밍 되어있으며 이를 위한 파티션 테이블 확인, 그리고 각 파티션의 부팅가능 여부를 확인하는 루틴이 들어있다. 또한 디스크의 정상여부를 판단해 예외처리를 진행하며 최종적으로 Start LBA(Logical Block Addressing, 논리 블록 어드레스)를 계산하여 해당 파티션의 Boot Record를 호출함으로서 그 임무를 다하게 된다.

어떻게 보면 전체 섹터에서 그렇게 큰 부분을 차지하지는 않는 부트코드지만 이 부분이 문제가 있을경우 PC가 정상적으로 부팅이 되지 않기 때문에 가장 중요한 부분이라고 보면 되겠다.

그다음으로 중요하게 봐야 할 부분은 파티션 테이블 영역이다. 총 64 Byte의 크기를 가지고 있는 파티션 테이블은 개당 16 Byte씩 총 4개의 파티션  테이블을 차례로 갖는다. 각 파티션에 대한 자세한 내용은 아래서 더 다루어 보기로 한다.

<표 1. 파티션 영역 세부 분석>

[표 1]을 보다보면 CHS 부분은 현재는 거의 사용하지 않으며, 0으로 채워도 부팅에는 지장이 없다고 설명해 놓았다. 필자가 분석가는 아니지만, 많은 분들이 실제로 딱히 저부분은 크게 알 필요가 없다고 말하기도 하고, 어느경우는 무시하고 바로 LBA만 보라고 하는 경우도 있다. (필자도 여태까지 공부하면서 CHS 부분을 봐본적은 사실 없다.) 

물론 위에 말한 내용이 '요새 설정에 있어서'는 맞는 말이기는 하다. 여러분이 사용하는 OS의 파일 시스템 대부분이 LBA 모드를 사용하고 있기 때문이다. 그러나 잊지 말았으면 하는점이 있다. IT에 있어서, 아니 세상에 있어서 '절대' 라는 것은 단 하나밖에 존재하지 않는다. 바로 '생명은 태어나면 반드시 언젠간 죽음을 맞이한다는 것' 이다. 즉, 그 이외의 모든것들은 언제나 항상 맞는것은 아니라는 점이다. 

여러분이 분석을 진행하다 보면 대부분의 확률로 LBA 모드의 파일 시스템을 보게 될 것이다. 그러나 CHS 모드나 LBA 모드를 결정하는 것은 전적으로 어플리케이션이다. 함부로 단정짓지 않길 바란다. 여기에 기술하지는 않겠지만 인터넷을 찾아보면 각각의 파티션 타입을 설명해 놓은 글이 존재한다. 그리고 그것들은 단순히 파티션의 종류만 설명해 놓은 것이 아닌 CHS 모드인지 LBA 모드인지 역시 함께 서술해 놓고 있으니 참고하며 공부하길 권한다.

위 내용을 토대로 각각의 파티션별 디스크 최대 인식 용량을 구해보도록 하자.

위의 [그림 1]을 다시 한번 보면 MBR 내 파티션 테이블 영역은 0x1BE부터 0x1FD까지 총 64 byte를 차지하고 있다. 그리고 그 안에서 각각의 파티션은 16 Byte씩 최대 4개의 파티션을 가질 수 있다. 또한 각 파티션의 Size는 [표 1]의 Size in Sector 부분을 참고하면 찾을 수 있다. 

총 4 Byte의 크기를 가지고 있는 이 영역의 Max 값을 쉽게 표현해 보자. 16진수는 2의 4승만큼의 값을 가진다. 그런데 4 Byte의 값을 가지는 Size in Sector는 총 8개의 16 진수 값을 가질 수 있다. 즉, 최대의 개수는 2의 4승이 8개가 있다는 의미이기 때문에 2의 32승만큼의 섹터 값을 가진다. 

일반적인 파일시스템의 경우 섹터당 512 Byte의 값을 가진다. 그러면 Size in Sector 값과 512를 곱해줄 경우 해당 파티션의 용량이 구해지는데 최대 용량의 경우 가장 높은 값은 2의 32승 * 512(2,199,023,255,552 Byte)가 된다. 이것을 이제 1024로 지속적으로 나누게 되면 Byte -> KByte -> MByte -> GByte -> TByte 순이 된다. 

이렇게 계산할 경우 계산되는 MBR 구조에서 각각의 파티션 별 디스크 최대 인식 용량은 2TB가 된다. 이는 MBR 구조의 큰 단점 중 하나인데, 과거에는 파일별 용량이 크지 않았으나 상관이 없었으나, IT가 발전되면서 프로그램의 용량이 늘어남에 따라 곧 한계가 올 것으로 보인다. 

이를 해결하기 위해 나온 구조가 GPT구조이다. 나중에 기회가 되면 따로 설명하겠지만, GTP구조는 MBR의 구조적 문제를 해결하기 위해 만들어진 구조로 2TB 이상의 파티션도 인식 가능하다는 장점이 있다.

이상으로 파일시스템 중 FAT32에 들어가기에 앞서 기본 베이스가 될 수 있는 MBR구조에 대해 알아보았다. 다음 포스팅부터는 FAT32에 대해 자세히 알아보도록 한다.

* 참고 : 임베디드 개발자를 위한 파일시스템의 원리와 실습(정준석, 정원용 공저), 한빛미디어

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

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

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

"그러시죠."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

안녕하세요. 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)를 통해 찾아뵙겠습니다.