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 이 무엇인지 간단히 알아보겠습니다.