jwmsg

FAT32 분석기 – 1

요즘에는 잘 사용하는지는 모르겠으나, 몇년전까지만 해도 대부분의 USB와 SDCard 같은 경우 FAT32를 쓰곤 했습니다.  파일시스템을 공부하면서 FAT 이미지 에서 데이터를 카빙하거나, 디렉터리 목록을 긁어오는등을 하며 조금 감각을 익혀가긴 했었는데,, 과도한 입시 공부를 하느라(거짓말) 파일시스템이 기억도 안나고 감각이 무뎌져 다시 공부를 시작했습니다.

일단, 그냥 글로만 보면 이해가 잘 안되서, C++로 코드를 작성하고 Sample 이미지를 기반으로 공부를 해 나가보겠습니다. 일단 이번 글에서는 FAT32의 기본적인 부부분만 짚고 넘어가 봅시다!

일단, FAT는 File Allocation Table 의 약자 입니다. 이는 매우 단순한 파일시스템 입니다. 과거 XP이전 시대때 주로 사용되었고, 현재는 작은 용량의 저장소 (흔히 2~16기가 미만)의 파일시스템 입니다.

기본적인 FAT 구조

위 그림은 기본적인 FAT 구조 입니다. 일단 먼저 예약된 영역에는 이 파일시스템을 정의(?)하는 영역입니다. 주로 첫 섹터에 부트섹터가 존재합니다. 부트섹터에서는 아래와 같은 정보를 알 수 있습니다.

BootSector 구조체
(표로 만들기 힘들어서,,, ㅠㅜㅠㅜ 조만간 표로 만들어서 업데이트 할께요,,)

여기서 가장 중요한것들만 모아 봤습니다. 이 아래에 있는 목록들만 있어도 충분히 FAT32의 디렉터리, 데이터 들을 분석할 수 있고, 카빙도 가능합니다.

  • (Dec)11~12 번째 offset의 섹터당 바이트수
  • (Dec)13 번째 offset 에 있는 클러스터당 섹터수,
  • (Dec)14~15번째 offset의 예약된 영역의 섹터크기
  • (Dec)16번째 offset의 FAT영역의 개수
  • (Dec)36~39번째 offset의 FAT 영역의 섹터 수
  • (Dec)44~47번째 offset의 루트디랙터리의 클러스터 번호 (주로 2 입니다.)

일단 여기까지 글의 시작을 알리며  다음 내용 (FAT32의 디렉터리 정보를 불러오기)를 통해 계속 이어나가겠습니다. 아 참, 그리고 EVTX 도 이어서 올리도록 하겠습니다!

jwmsg

evtx 파일 구조분석 – 3

지난 글에서는 File Header 를 분석하여 chunk의 위치를 찾는 방법을 알아보았습니다. 이번 글에서는 Chunk 내에 있는 Header 를 분석하여 Recoard 의 위치를 찾아가고, Recoard 를 읽어가는 방법에 대하여 알아보도록 하겠습니다.

Chunk 내에 존재한 Header로 0x200 의 길이이다.

이번 역시 위 구조로는 눈에 안들어오니 HXD와 함께 삽질을 시작해 봅시다.

Magic 시그니처로 ElfChnk 입니다.
이 Chunk 에서 첫번째의 레코드의 번호를 명시 합니다.
이 chunk 에서 가장 마지막의 레코드의 번호를 명시합니다.
FirstLogRecordNum 과는 별 차이를 알 수 없으나
아마 첫번째 레코드를 의미하는것으로 알고 있습니다.
이 또한 마찬가지로 LastLogRecordNum 과는 별 차이를 알 수 없으나
아마 첫번째 레코드를 의미하는것으로 알고 있습니다.
String table Offset 이라고 되어 있으나
제 추측상 File header 와 마찬가지로, Header 영역에 제일 상단영역의 크기 같습니다.
보통 0x80 입니다.
마지막 레코드의 Offset 입니다.
주의! 상대적인 위치입니다, Chunk 의 첫 offset 을 기준으로 합니다.
만약 새로 레코드가 추가될경우, 
세로운 레코드가 시작할  offset 의 위치 입니다.
Chunk 내에 존재하는 레코드들의 CRC 입니다.
레코드들의 무결성을 확인 할 수 있습니다.
사용되지 않는 알수 없는 영역인데,
예약된 영역, 혹은 Padding 영역이라고 생각이 듭니다.
플레그 영역 입니다.
상위 해더의 CRC 입니다.
String 테이블로 어떤 값들이 저장되어 있긴 한데,,, 뭔지 아직 잘 모르겠습니다.
추후 알아보고 업데이트 하겠습니다,
(추측이지만,, 뭔가 바이너리 XML 과 연관 되어있지않을까요?)
템플릿 테이블로 어떤 값들이 저장되어 있긴 한데,,, 뭔지 아직 잘 모르겠습니다.
추후 알아보고 업데이트 하겠습니다,
(추측이지만,, 뭔가 바이너리 XML 과 연관 되어있지않을까요?)

그럼 이제 레코드 위치를 찾아보도록 하겠습니다.
먼저 Chunk 의 해더는 0x200 이었습니다.
그렇다면 chunk의 offset + 0x200 하면 첫번째 레코드의 offset이 나오겠네요!
그리고 다음 레코드로 넘어가려면 현재 레코드 길이만큼 뛰어넘으면 될것 같네요!

이번글은 여기서 마치도록 하겠습니다. 이번글은 약간 chunk 의 구조만 집중적으로 알아보고 다른 내용이 없네요 ㅠㅜ

이제 다음장에서는 레코드 영역을 제대로 분석하여보고, BinaryXML 이 무엇인지 간단히 알아보겠습니다.

jwmsg

evtx 파일 구조분석 – 2

안녕하세요!  드디어 evtx 파일의 구조분석 두번째 글을 올리게 되었습니다.
저번글에서는 이벤트 로그파일이 무엇이고, 이벤트로그파일의 간단한 구조들을 알아보았는데요. 이번글 부터는 HEX 뷰어를 통해 하나하나 삽질을 시작해볼까 합니다.

이번글 에서는 evtx 파일의 파일 해더 부분을 구체적으로 알아보고, Chunk 를 찾아가는 방법을 공부해볼까 합니다.

위 사진은 Header 의 구조를 한눈에 볼 수 있는 표 입니다.  이제 HXD 를 이용하여 삽질을 해보도록 합시다!

magic Signature
가장 오래된 chunk

현재 작성중인 chunk
작성 예정의 레코드 번호
해더에 part1 영역(지금 우리가 삽질중인 영역)의 크키
기본적으로 0x80
버전(좌:minor , 우: major)
해더영역 전체 길이
기본적으로 0x1000
chunk 의 개수
padding 으로 추측되는 알 수 없는 영역
플레그 영역
CRC 체크

여기까지가 파일 헤더의 part1 영역이며, 이 아래 전체 영역은 대부분 0x00으로 채워져 있습니다. offset 0x00 부터 0x1000만큼 움직이면 첫번째 chunk 가 나오게 됩니다.

chunk 부분은 다음 글에서 다루겠지만, chunk 를 찾아가는 방법을 소개하고 이번 글을 마치겠습니다!

먼저 Header 가 끝나면 바로 chunk 가 시작된다고 했습니다. 그리고 저번글에서는 Chunk의 크기는 0x10000 이 기본이라고 했구요. 그럼 첫번째 Chunk 의 위치는 당연히 0x1000 이 될껍니다. 그리고 두번째 Chunk는 첫번째 Chunk 시작위치에서 0x10000만큼 이동한 0x11000이 되겠죠!

그럼 N번째(N은 0이상의 정수) Chunk 의 offset 을 찾을 수 있게 됩니다!

Chunk N’s offset == 0x1000 + (N * 0x10000)

위 식을 이용하면 해당하는 chunk 의 위치로 갈 수 있습니다.

다음글에서는 Chunk 의 구조와, Chunk 에서 레코드를 찾는 방법까지 알아보도록 하겠습니다. 글을 익어주셔서 진심으로 감사합니다!