Digital Forensic Challenge 2019 AF200 문제풀이

  

 

AF200 문제로 저번 AF100 문제를 너무 재미잇게 풀어서 이번 문제도 기대가 됩니다!

 

 

문제를 이제 확인해 보겠습니다.

 

what-is-Pooh-doing 이라는 파일의 확장자를 알아 보겠습니다.

 

7z 파일인 것을 알 수 있고, 압축 해제를 해보겠습니다.

 

하이브 파일(hve)과 하이브 로그 파일(hve.LOG1)이 있습니다.

하이브 파일은 레지스트리 뷰어로 확인 해 볼수 있기 때문에 Registry Explorer 툴을 이용해서 확인해 보겠습니다.

 

 

0xAF200 하위에 3개의 폴더가 존재 합니다.

- Let's warm up.

- One part was stored here.

- Two parts were buried here.

 

먼저 0xAF200에 데이터가 있는지 보겠습니다.

 

아무런 데이터가 들어있지 않습니다.

Let's warm up. 을 확인해 보겠습니다.

 

 

2개의 데이터가 있습니다.

1 - Trust me. This key and its subkeys do not have any parts of hidden data.

2 - However, you might be able to get a valuable hint for interpreting hidden data, if you can find some alphabets of nameless values.

 

1 - 이키의 서브키에는 hidden data가 없다.

2 - nameless value의 값을 찾을 수 있다.

 

AAAAAAAAA... 의 값을 확인해보면 아래와 같습니다.

 

(Default)의 값으로 A가 있습니다.

우리가 찾아야 하는 값은 nameless value 값인데 (Default)는 고의적으로 만든 이름 입니다.

 

원래 nameless value는 (기본값)이라는 곳에 데이터가 들어가 있는데 , Registry Explorer 에서는 nameless  value는 (default)에 들어가 있습니다.

Registry Explorer 이 아닌 기본 레지스트리 편집기를 이용하면 아래와 같이 출력됩니다.

 

그렇다면 BBBBBBBBBB... 를 확인해 보겠습니다.

 

우리가 찾던 nameless value 입니다!

(default) 에 B라는 값이 들어있습니다.

 

A ~ Z 까지 (default)에 들어있는 값만 출력해 보겠습니다.

 

 

Let's warm up 에서 나온 nameless value 값을 모아 보면 B,M,P입니다.

 

나머지 One part was stored here 과 Two parts were buried here 의 하위키도 확인해 보겠습니다.

 

여러 문자열 들이 들어있었지만 우리가 찾아야 하는것은 you can find some alphabets of nameless values // 알파벳 값이기 때문에 관련이 없어 보입니다.

 

모든 하위키를 전부 조사해본 결과 찾을 수 있는 nameless value 값은 B,M,P 입니다.

hidden data 는 bmp 이미지 파일이라는 것을 알수 있습니다.

 

그렇다면 One part was stored here 과 Two parts were buried here 하위 키에 들어있던 문자열 부터 조사를 해보겠습니다.

 

One part was stored here. 이라는 키에 2개의 데이터가 들어있는데 각각 무슨 데이터가 들어있는지 확인 해 보겠습니다.

[ ※ 엄청나게 많은 공백이 들어있지만 문자열만 추출해 보겠습니다. ]

 

One part was stored here

- (default) : One of three parts

- (Default) : The subkey had a treasure. | Remember: focus on the Windows registry file format specification.

 

(default)를 보면 bmp 파일이 3개로 나눠져 있을 것으로 예상이 됩니다.

(Default)를 보면 서브키는 보물을 가지고 있고, 특별한 윈도우 레지스트리 파일 형식를 유심히 보는것을 잊지 말아라 라는 문자열이 들어 있습니다.

 

 

서브키에 보물이 있다고 해서 3개의 파트중 1개의 부분이 들어 있을 것이라 생각을 했는데... 데이터가 아무것도 없습니다.

아마 값이 삭제되어서 아무 것도 존재 하지 않는것 같습니다. 복구 해내야 하는 부분.

 

 

Two parts were buried here.

- (default) : Two of three parts

 

bmp 파일의 2번째 부분이 들어있는 곳 같습니다.

서브키를 조사해 보겠습니다.

 

Open this door! , One more! 에는 값이 없습니다.

 

 

Last one!

- (default) : Open the $$$Golden-Chamber$$$ | The chamber had two treasures. | Remember: focus on the Windows registry file format specification.

 

$$$Golden-Chamber$$$를 열어라 , chamber 에는 2개의 보물이 들어 있다. , 특별한 윈도우 레지스트리 파일 형식를 유심히 보는것을 잊지 말아라 라는 문자열이 들어 있습니다. chamber 에는 bmp 파일의 2개 부분이 들어있는 것으로 추측이 됩니다.

 

 

아까 Yes, you are almost there! 이라는 키에서 처럼 아무런 데이터가 없는 것으로 보아 복구를 해야하는 대상 인것 으로 확인이 됩니다.

 

Exit 키 값에도 아무런 값이 존재 하지 않습니다.

 

이제 hive file format을 공부한 뒤 필요한 부분을 복구를 진행해 보겠습니다.

파일 구조를 공부 하실때는 HxD를 사용했었지만 010 editor를 사용한 이후엔 010 editor만을 사용합니다.

 

Pooh.hve 파일의 구조를 보기전 hve 파일의 구조를 먼저 공부해 보겠습니다.

Registry hive layout을 확인해 보면 아래와 같습니다.

 

 

 

하이브 파일은 블록단위로 구성되어 있으며 하나의 블록은 0x1000의 크기를 가지고 있습니다.

 

하이브 파일의 첫 블록을 Base Block이라고 불리는데 우리가 이야기 하는 파일의 헤더 부분이 이 Base Block 영역에 해당된다.

Bin 영역은 Base Block 영역을 제외한 나머지 블록을 하나 이상의 묶음을 지칭하는 단위로 Hive Bin이라는 논리적 단위로 구분합니다.

마지막으로 Cells 는 Bin 영역의 일부를 차지하는데 hbin이라고 불리는 header bin 과 cells 로 이루어져 있으며, cell은 레지스트리 키, 값, 인덱스와 같은 실제 레지스트리의 정보를 담고 있습니다.

 

Block : 클러스터와 비슷한 개념으로 , 하나의 블록은 0x1000(4096byte)의 크기를 가진다.

Bin : 레지스트리 데이터를 담고 있는 작은 유닛으로 Cell의 집합이다.

1개 이상의 Block영역을 가지고 있다.

Cell : 논리 적인 데이터 유닛으로 레지스트리의 정보를 담고있다.

hbin : bin의 헤더 정보이다.

 

 

문제 파일인 Pooh.hve 파일의 Base Block 은 0x1000의 크기를 가지고 있고 그 뒤로 Bin의 크기도 0x1000의 배수 인것을 확인 할 수 있다.

 

Cell에는 여러가지의 타입이 존재 합니다.

- Key Cell : 키에 관한 데이터가 들어 있다.

- Value Cell : 값의 이름과 값에 대한 포인터를 담고 있다.

- Value-list Cell : 값 데이터들에 대한 포인터 리스트를 담고 있다.

 

아래의 표는 Cell data는 4바이트의 크기인 크기영역과 데이터 영역으로 나누어져 있는데 데이터 영역에 들어가는 데이터의 종류를 정리한 표입니다. 

 

이 중 중요한 데이터는 Index root, Index leaf , Key node , Key value 가 있다.

 

위의 표와 함께 아래의 사진을 보면 이해가 쉽다.

 

 

Base Block은 root cell을 가리키고 root cell 은 Key node를 포함하고 있습니다.

key node 는 자신의 부모 key node와 자신의 subkey list , 자신의 Key value list , 자신의 Key security item을 가르킨다.

subkey list 는 Index root 구조에 의해서 나누어 질 수 있다.

key value는 데이터를 가리키고, 데이터는 크기가 4바이트 이하일 경우에 key value구조의 Dataoffset 필드에 그대로 저장이 되고, 아닐 경우에는 별개의 셀이나 여러 개의 셀에 걸쳐서 저장 될 수 있다.

 

위의 hve file format를 바탕으로 위에서 Registry Exploler 로 찾았던 데이터를 파일 구조를 보며 간략하게 찾아 보겠습니다.

 

 

nk값 내부의 데이터가 vk로 되어 있는 것을 알 수있습니다. (nk : key node , vk : key value)

 

key value name이 (default)와 (Default)여서 기본값 데이터와 혼동이 올수도 있다.

하지만 이름 설정을 하지않은 기본값 데이터는 name length의 값이 0으로 출력될 것이다. 또한 Value name string 필드도 비어 있을 것이다.

 

데이터를 보면 (dafault)가 9글자 여서 vk[5]는 9라고 나와있지만 이름이 설정 되어있지 않은 vk[6]은 0으로 출력이 되고 있다.

vk[6]의 hex 값을 봐보면 아래와 같습니다.

 

 

size가 24 이기 때문에1B28 ~ 1B3F 까지를 의미한다.

 

Data offset 을 보면 77 라는 값이 들어있고 이는 M를 의미 합니다.

앞에서 찾은 B,M,P중 M을 의미 합니다.

 

이제 하위에 없던 데이터를 복구 하는 작업을 해보겠습니다.

 

이렇게 2가지 키가 아무런 데이터가 없었습니다.

 

먼저 Yes, you are almost there! 을 확인 해 보겠습니다.

 

nk[3] 에 Yes, you are almost there! 이라는 문자열이 담긴 key node 가 있는데 하위에 앞에서는 보이지 않았던 key value값이 보입니다.

vk[2] : 3,PIXELS

 

 

유심히 보아야 할 데이터는 DataLength 와 DataOffset 입니다.

먼저 DataOffset이 데이터의 시작 주소일 것이고 그 뒤로 5712 만큼이 데이터 일 것 입니다.

 

8768 = 0x2240 + 0x1000(Base Block) = 시작 주소는 0x3240 입니다. 또한 데이터의 크기는 5712byte = 0x1650 입니다.

 

빨간 박스는 Cell의 크기를 의미 하기 때문에 0x3244 부터 시작입니다.

0x3244으로 부터 0x1650 더 떨어진 0x4893이 데이터 끝입니다.

 

3번째 부분으로 예상이 됩니다.

 

 

아까 보지 못했던 1.BITMAPFILEHEADER 이라는 문자열이 있는 것으로 보아 파일 헤더가 있는 것 같습니다.

 

23184 = 0x5A90 + 0x1000(Base Block) = 0x6A90 에서 데이터 시작 

데이터 크기 14 = 0xE

 

 

빨간 박스는 Cell 크기 이므로 0x6A94 ~ 0x6AA1 까지 HEADER 입니다.

 

위의 사진 아래쪽을 보면 2.BITMAPINFOHEADER+PALETTE 라고 되어 있습니다.

 

FILEHEADER 뒤에 오는 INFO 가 들어있는것 같습니다.

 

빨간 박스는 Cell 의 크기입니다. 그리고 녹색 박스 첫번째꺼는 데이터의 크기(DataLength) , 두번째 꺼는 데이터의 오프셋(Data Offset)을 의미 합니다.

 

데이터의 시작값은 0x5AE8 + 0x1000(Base Block) = 0x6AE8

 

빨간 박스는 Cell의 크기 이므로 6AEC 부터 시작입니다.

 

총 3개의 데이터를 다 수집했기 때문에 아래에 사진에 기반해서 하나로 합쳐 보겠습니다.

 

 

추출.bmp로 만들어 보겠습니다.

 

사진을 찾았으나 Pooh는 여기에 없다고 하면서 또다른 힌트를 제시 합니다.

힌트 : 트랜잭션 로그를 주목해서 보아라 !

 

Pooh.hve.LOG1 파일을 열어보겠습니다.

.LOG1 파일이기 때문에 문자열 검색으로 찾아보면 아래와 같습니다.

 

1.BITMAPFILEHEADER 과 2.BITMAPINFOHEADER+PALETTE 는 일반적인 Pooh.hve 파일과 똑같은 것으로 보아 

PIXELS 파일이 좀 다를 것 이라고 생각이 됩니다.

 

앞서 확인했던 0x3240 에 가보면 아래와 같은 모습을 볼 수 있습니다.

 

시작 부분이 여기가 아닌것 같다.

그래서 hbin을 먼저 찾아 보기로 했다.

 

 

0x230에 hbin이 있었다.

그래서 데이터 오프셋을 아래와 같은 연산으로 찾아야 합니다.

 

0x3240 - (0x1000 - 0x230) = 0x2470

 

빨간박스는 Cell의 크기 입니다.

 

데이터 값은 0x2474부터 5712byte(0x1650)까지인 0x3AC3 까지가 PIXELS를 의미 합니다.

다시 파일을 만들면 아래와 같은 사진을 얻을 수 있습니다.

 

 

result.bmp 라고 이름을 지어 보겠습니다.

라는 사진을 찾을 수 있습니다.

 

드디어 Pooh를 찾았네요.

은닉된 파일은 생각하는 푸 사진이였습니다.