Security – JWMSG

jwmsg

CVE-2021-22205 긴급 패치하기

2021년 11월 8일2021년 11월 8일git, Security, uncategorizedLeave a Comment

그렇습니다. 저도 갑작스럽게 이 RCE 가 터져서 문제가 좀 생겼습니다.

아마 이 게시물에 들어오신분들은 저와 같은 상황에 처해있거나 GITLAB CE/EE 운영하다가 문제가 생기신 분들일 가능성이 있습니다 ~~저도 중 많이 받았어요.~~

특히 저처럼 AWS Lightsail 사용하시는분들도 꼭 확인하셔야 하는 이유가 있습니다. 저도 처음엔 당황스러웠는데요.

AWS 에서 메일이 날아왔습니다….

그래서 일단 부지런하게 원인이 뭔지 좀 밝혀내야 하지 않을까하고 페북에다가도 수소문을 해서 조금 검색해보니 최근 (2021년 11월 1일쯤?) 문제가 좀 있었던것 같습니다.

일단 무슨 문제일까?

깃랩의 설명에 따르면 이미지 올리거나 할때 EXIF 영역을 제거하는 부분이 있는듯합니다. 그래서 그부분을 ExifTool 이라는 녀석이 받아서 처리하는데, 이 ExifTool 이라는 녀석에게 RCE 취약점이 발견된것 같습니다. (EXIF에 대한 내용은 여기로)

일반적으로 gitlab.com 은 문제가 되지 않구요, 별도로 자체 Gitlab을 서버에 올려서 사용하시는 CE 또는 EE 유저들은 필히 이 문제를 꼭 확인하시기 바랍니다.

문제가 발생하는 서버 버전

다음 버전의 서버에서 발생하는데 보통 다들 깃랩 같은서버는 한번 올려놓고 딱히 업데이트 안하는것 같아서 이번에 대부분의 서버들은 패치되어야 할것 같습니다.

11.9.x – 13.8.7
13.9.0 – 13.9.5
13.10.0 – 13.10.2

일단 내 서버가 당했을까?

일단 깃랩에서 친절하게 잘 설명하고 있습니다.

그런데 일단 한글로도 정리를 해야할것 같아서 여기다가 정리를 해보려 합니다.

일단 스냅샷 부터 꼭 찍으시고 작업 하시기 바랍니다.

/var/log/gitlab/gitlab-workhouse 아래에 current 라는 로그파일이 있습니다. 해당 파일에서 grep 을 이용하여 “exiftool command failed” 를 검색하면 되는데요.

느낌이 쎄하다,,, stderr 을 보아하니 뭔가 다운을 받은것 같다,,,,

대충 뭔갈 다운받은듯한데, 뭔가 수상쩍은 stderr 혹은 stdout 부분이 발견되신다면 일단 내 서버가 털렸을 것에 집중을 하셔야 합니다.

해당 시간에 맞는 nginx 의 로그를 확인해 보셔도 좋습니다.

일단 빼박,, 저는 뭔가 느낌이 좋지 않습니다..

공격 당한것 같은데 어찌 해야 합니까?

지금 저도 공격 벡터 찾아서 분석중인데, 시간이 좀 걸릴것 같습니다.

확실한건 이번주 주말(11월 13일) 까지 상세하게 찾아보고 글을 써서 공유해볼 예정입니다.

패치는 어찌하면 좋습니까….

일단 가장 좋은 방법은 최신버전의 Gitlab CE로 업그레이드 하는겁니다만,,,

아시다시피,, 코드 저장소를 함부로 업그레이드를 갑자기 진행하기엔 좀 곤란한 부분이 있습니다.

하나의 솔루션으로는 ExifTool 부분의 소스코드만 별도로 패치하는것입니다만.

sudo su cd ~  
curl -JLO https://gitlab.com/gitlab-org/build/CNG/-/raw/master/gitlab-ruby/patches/allow-only-tiff-jpeg-exif-strip.patch  
cd /opt/gitlab/embedded/lib/exiftool-perl  
patch -p2 < ~/allow-only-tiff-jpeg-exif-strip.patch

일단 제가 해봤는데요, 왜인지 모르겠으나 저는 안되더라구요 (되시는 분들은 여기서 멈추시면 됩니다.)

이상하게 저는 FAILED 가 뜹니다. 그래서 저는 그냥 ExifTool이 돌지 못하게 막도록 하기로 했습니다. (그렇게 되면 자동으로 EXIF 를 처리하는 로직이 사라지니 혹시 필요하신 분은 좀 다른 방법을 찾으셔야 할듯 합니다)

/opt/gitlab/embedded/bin/exiftool 를 에디터 (VIM,등)으로 여시고,

#!/bin/bash

cat -

위 처럼 파일을 덮어 버리시기 바랍니다.

(저는 exiftool.bak 이라고 별도로 백업파일 만들어 두고 진행했습니다.)

패치가 잘 되었는지?

역시 직접 공격 넣어보시면 됩니다. 해당 CVE 코드를 기반으로 Git 에 돌아다니는 python 소스코드를 이용하여 테스트 해보실 수 있습니다.

일단, 저는 혹시나,,,, 하는 마음에 이 블로그에는 공유하지 않겠습니다. 별도로 잘 찾아보시기 바랍니다.

마무리글…

이제, AWS 에 보고메일을 보내야 할듯합니다.

일단 워낙 긴급한 사안같아서 난리난듯 한데,

암튼 제 글솜씨가 좋지않아 두서없이 적은점은 죄송합니다 ㅠㅜㅠㅜ

다들 해결은 잘 하셨으면 좋겠습니다.

jwmsg

OSINT 특집[2] – 이미지에서 정보를?

2020년 9월 4일2020년 9월 4일OSINT, SecurityLeave a Comment

바로 이어서 이미지/영상 소스에서 정보를 추출하는 방법과, 이를 통해 찾아낼 수 있는 정보들에 대하여 알아볼까 합니다.

눈에 보이는 영역에서 정보를 찾아보자!

제일 먼저, 우리가 쉽게 찾을 수 있는것에서부터 찾아내보는겁니다.

제가 과거 제 2회 NEWSECU 정보보안해킹대회 때 출제했던 문제 입니다.

위 사진을 찍은 위치의 주소는?
위 사진에서 지나가고 있는 버스의 번호는?
위 사진을 찍은 시기(몇년/몇월)는?

사진에서 찾을 수 있는 정보는 다음과 같습니다.

건물에 적힌 간판들의 상호명들
앞에 지나가고 있는 버스의 정류소 (나머지는 일부러 지웠음)
영화 대개봉을 알리는 포스터들

그럼,,
건물에 적힌 상호명들을 조합하여, 건물의 명칭과 주소를 알아낼 수 있고,
지나가는 정류소를 나열하여 검색하면 버스 번호를 조회해 볼 수 있습니다!
그리고, 보통 1~2주전쯤 홍보하는 영화포스터를 통해,
사진을 찍을 수 있는 시기를 알 수 있습니다!
[직접 찾으실 수 있게 정답은 공개하지 않겠습니다]

자, 그럼, 친구와 집근처에서 셀카를 찍고 SNS에 올렸다고 가정해 봅시다.

뒷 배경과 조그마한 정보들을 토대로 사진을 찍은 위치와 시간대를 유추당할 수 있는 여지를 줄 수 있는것이겠죠?

물론, “나 여기 왔어요~~” 자랑하기 위해서 올리는 사진에서는 문제가 되지 않겠지만, 단순히 셀카만 찍어 올리는것을 목적으로 올린경우, 그리고 그 찍은 위치가 공개되면 좋지 않은 경우엔, 당연히 배경을 주의하여 촬영을 하는게 좋을 수 있다고 의견을 남깁니다.

눈에 보이지는 않지만, 남아있는 정보!

혹시, EXIF 라는 정보를 들어보신 적이 있으신가요?

EXIF 는 EXchangable Image File format 의 약자로, 우리가 흔히 사용하는 “JPG/JPEG” 형태의 사진에서 주로 사용하는 이미지의 “메타데이터” 를 저장하는 하나의 “포멧(형태)” 입니다.

메타데이터가 뭔데?

메타데이터는 “데이터에 대한 데이터” 라고 하는데, 즉 어느 데이터를 설명하기 위한 또다른 데이터 라고 생각하면 됩니다. 예를들어 사진이 있다고 가정할때, 사진을 설명하는 정보 (사진이름, 사진찍은시간, 사진찍은사람, 사진찍은 기기의 정보 등) 가 이에 해당합니다.

그거가지고 뭐하는데?

제가 아래 사진을 하나 준비해 왔습니다! 이 아래 사진을 토대로 분석해 봅시다!

이 사진을 오른쪽 마우스 눌러서 다운로드 하시면 아래 방법으로 실습 하실 수 있습니다.

먼저 파일의 오른쪽 마우스를 눌러 속성을 봅시다.

카메라 제조업체, 카메라 모델, 촛점과 카메라 셋팅까지 모두 확인이 가능

여기서 중요한건, 당연히 위도 경도 고도 겠죠? 위/경도를 이용해 위치를 찾고, 고도를 이용해 층수를 계산하면? (실제로 저게 학교기숙사) 만약 집안에서의 위/경/고도를 알게 된다면, 집주소 찾는건 그냥 하겠죠?

위, 경도는 세미콜론(;) 을 단위로 3개의 영역(도,분,초) 으로 나뉩니다. 이 3개의 영역을 계산하면 실제 위경도 좌표가 나오는데 방법은 아래와 같습니다.

위 사진에서 위도가, 37도 37분 17.2999 초 이므로, 60분법을 이용하여 계산하면,

위도는
37+(37/60)+(17.2999/3600) = 37 + 0.61666 + 0.004805527777 =
37.621472194444… 가 나옵니다.

경도는
127+(3/60)+(23.159999 / 3600) = 127 + 0.05 + 0.00643333305555 =
127.05643333305555… 가 나옵니다.

위경도를 구글에 검색하면!
역시 구글신은 무엇이든 알고 계신다!!!!

제가 살았던 광운대학교 기숙사 위치를 찍어 볼 수 있습니다.
~~(소름돋는건, 실제로 저 위치가 내방 있는 위치였다는거,)~~

여기에 고도를 더하면?

그럼 카메라에서 측정된 47미터였으니까, 약 6미터, 2미터당 1층이라 치면 (3층높이) => 본인은 5층이었음 [오차 존재]

오차가 존재하더라도, 어느정도 들어맞출 수 있는 정도 입니다. 만약 이게 집에서 찍은 사진을 온라인에 잘못 올렸을 경우, 집주소와 위치를 노출 당할 우려가 있겠죠? ~~(무섭네,,)~~

안전하게 이미지 올리는 방법은?

사실, 아무리 안전하게 한다 한들 찾을 사람들은 다 찾습니다. (팩트)

하지만, 최대한 우리가 신경을 쓴다면 가장 먼저 EXIF 영역을 지운 상태로 이미지를 업로드 하는게 좋겠죠?

사진을 찍을때 부터 위치정보를 지우고 찍는다

당연히 처음부터 찍을때 위치정보를 지우고 찍는걸 추천합니다.
안드로이드 같은 경우 카메라 앱 설정에서 위치정보를 기록하지 않는 방법이 있습니다.
아이폰의 경우에는 설정->개인정보보호->위치서비스->카메라->안함 설정을 해주시면 됩니다.

이미 찍은 사진을 올릴때에는 exif 제거하는 도구 를 이용하여 제거한다.

PC 로 업로드 할 때는 EXIF Eraser 라는 툴을 이용하여 꼭 EXIF 영역을 지우고 올립시다. 혹은 페북이나, 인스타, 트위터 등에 업로드 할때, “자동으로 위치 수집, 태그” 기능을 꼭 끄고 업로드 합니다.

모바일에서는 사실 EXIF영역을 지워주는 앱들이 많이 출시 되었습니다만,, 사실 개인적으로는 신뢰하기 어려워서 추천해 드리지는 않습니다 (과거에 사진이랑 위치를 수집해가는 앱들이 있었기에ㅡ,,ㅡ) 되도록이면 처음부터 위치정보나 기본정보를 지우고 찍는걸 추천해 드리며, 업로드 시에도 주의해서 업로드 하시길 바랍니다.

그리하야, 드디어 이미지속 나의 정보를 지키는 방법에 대하여 알아보았습니다.

다음글에서는 “SNS 글에서 추출가능한 정보들” 에 대하여 알아보겠습니다.

jwmsg

OSINT 특집[1] – 오신트가 머임?

2020년 9월 3일OSINT, SecurityLeave a Comment

안녕하세요, 저어어엉말로 오랜만에 글을 써보는 맛소금 해커 입니다.
요즘들어 인스타그램이나, 페이스북 등 개인 SNS 를 애용하는 사람들이 늘어나고 있습니다. 자신의 일상을 공유하고, 셀카를 올리는 등, 다양한 목적으로 SNS 를 이용하면서 세상과 소통하곤 합니다.

하지만, 우리가 잊고 있던 몇가지들이 있습니다. 사소한 정보, 사소한 사진, 사소한 내용의 글 이더라도 그 속에서 다양한 개인정보 혹은 민감한 정보들을 찾아낼 수 있습니다. 그래서 이제는 SNS 를 이용하는데에도 더더욱 주의해야 합니다.

오늘부터 특집으로 OSINT 관련된 내용으로 글을 써볼까 합니다. ~~(과연 제가 성실히 글을 잘 작성할지는 모르겠지만)~~ 앞으로 잘 부탁드립니다.

OSINT 가 뭐임?

Open Source INTelligence 의 약어로, “공개 정보(원천)” 를 이용한 “인텔리전스” 입니다. 여기서 Open Source(공개정보) 라고 함은 말 그대로, 온라인/오프라인 상에 공개되어, 얻을 수 있는 모든 정보들을 칭하는 말로, SNS/Github/영상매체/블로그/홈페이지 댓글 등 다양한 곳에서 추출해 낼 수 있는 정보들을 말합니다.

OSINT 의 종류로는 IMINT(영상/이미지 정보), HUMINT(인간 정보), SIGINT(신호정보) 등이 존재하며, 수집하는 방법도 다양합니다.

사실 이걸 글로만 쓰면 이해하기 싫고 노잼일게 분명합니다. 그러니, 다음 글부터는 직접 추출해보면서 자세하게 각각을 알아보도록 하겠습니다.

다음 글에서는 IMINT 정보를 수집/추출하는 방법을 알아보고, 이를 대비하는 방법에 대하여 알아보도록 하겠습니다.

jwmsg

FAT32 파일 추출 삽질기 – 해캠에서 실패했던 시연 설명

2019년 2월 17일2019년 2월 17일FileSystem, Free, uncategorizedLeave a Comment

하,,,,, 제가 멍청했습니다. 하위 클러스터 바이트가 0076 이면, 데이터영역 시작이 2번 클러스터 이니까. 데이터 영역 기준으로 74클러스터 만큼 이동해야 하는데, 76클러스터만큼 이동해서 시그니처를 찾지 못했군요,,,

그래서, 아래에 FAT32 파일 추출을 한번 설명해볼까 합니다. 이미지파일은 해캠에서만 배포하였고, 해당이미지는 트레이닝을 위한 어느 한 포렌식 트레이닝 사이트에서 받은 이미지 내부에 FAT32 영역 500메가만 불러왔어요. 저작권이나 뭐나 그럴 수 있으니, 따로 공유하지는 않겠습니다.

순서는 다음과 같습니다

VBR 영역에서 1섹터당 몇바이트인지 알아오기 (off = 0x0B , 2Byte)
VBR 영역에서 1클러스터당 몇 섹터인지 알아오기 (off = 0x0D , 1Byte)
VBR 영역 에서 예약된 섹터 수가 몇개인지 알아오기 (off = 0x0E , 2Byte)
VBR 영역에서 FAT 영역이 몇개인지 알아오기 (off = 0x10, 1Byte)
VBR 영역에서 하나의 FAT 영역의 크기는 몇 섹터인지 알아오기 (off = 0x24, 4byte)
VBR 영역에서 루트디렉터리(루트 클러스터) 번호 알아오기(off = 0x2C, 4byte).
Dir Entry 영역 에서 파일명(off = 0x00, 11Byte)
Dir Entry 영역에서 상위 클러스터 2바이트(off=0x20, 2Byte)
Dir Entry 영역에서 하위 클러스터 2바이트(off=0x30, 2Byte)

** 각 영역에서부터 오프셋이 시작되니 착오 없으시길 바랍니다.

여기서 알 수 있는것은

FAT 시작 오프셋 = (예약된 섹터 수 * 1섹터당 바이트 수)

DATA영역 시작 오프셋 =
(FAT 시작 오프셋 + FAT영역갯수 * FAT 1개 영역 크기 * FAT 영역 갯수)

파일의 시작 오프셋 =
(DATA영역 시작 오프셋 + ( (시작 클러스터 번호 4바이트 – 루트클러스터번호) * 1클러스터 당 섹터수 * 1섹터당 바이트 수) )

파일의 끝 오프셋 =
일단, FAT시작 오프셋으로 갑니다.
그 위치는 0번 클러스터를 가르치는 부분입니다.
그렇다면, 76번 클러스터니까, 4byte * 76 하면 76클러스터의 할당정보가 나오죠.
해당 클러스터 할당정보에 적힌 다음 클러스터번호로 넘어갑니다.
당연히 해당위치는 FAT시작 오프셋에서 4Byte * 해당 다음 클러스터 번호가 되겠죠
쭉 가다보면 FFFFFF0F 가 보일것입니다. EOF 입니다.
드디어 해당 위치의 오프셋에서 FAT 시작 오프셋을 빼고 4로 나누면,
몇번째 클러스터 인지 알 수 있습니다.
해당 클러스터가 마지막 클러스터 입니다.
그 마지막클러스터 오프셋은
(DATA영역 시작 오프셋 + ( (마지막 클러스터 번호 4바이트 – 루트클러스터번호) * 1클러스터 당 섹터수 * 1섹터당 바이트 수) ) 이며,
해당 위치에서 (1클러스터 당 섹터수 * 1섹터당 바이트 수) 만큼만 더 가면
그 위치가 파일의 끝 오프셋이 됩니다.

발표에서 실패했던 이유가 DATA 영역 시작 위치는 2번 클러스터니까, 76번 클러스터로 가려면, 당연히 74번 클러스터를 뛰어 넘어가야 하는데, 제가 멍청하게 76번 뛰어넘어가면서 78번 클러스터를 보여드렸습니다.

위 방식을 추후 눈으로 볼 수 있는 이미지 파일로 정리를 하여 공개하도록 하겠습니당 ㅠㅜ

추가로 그 FAT툴 시연 영상입니다

jwmsg

FAT32 분석기 – 1

2018년 9월 21일FileSystem, SecurityLeave a Comment

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

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

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

위 그림은 기본적인 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

2018년 9월 11일2018년 9월 21일Security, WindowsLeave a Comment

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

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

FirstLogRecordNum 과는 별 차이를 알 수 없으나
아마 첫번째 레코드를 의미하는것으로 알고 있습니다.

이 또한 마찬가지로 LastLogRecordNum 과는 별 차이를 알 수 없으나
아마 첫번째 레코드를 의미하는것으로 알고 있습니다.

String table Offset 이라고 되어 있으나
제 추측상 File header 와 마찬가지로, Header 영역에 제일 상단영역의 크기 같습니다.
보통 0x80 입니다.

마지막 레코드의 Offset 입니다.
주의! 상대적인 위치입니다, Chunk 의 첫 offset 을 기준으로 합니다.

만약 새로 레코드가 추가될경우,
세로운 레코드가 시작할 offset 의 위치 입니다.

Chunk 내에 존재하는 레코드들의 CRC 입니다.
레코드들의 무결성을 확인 할 수 있습니다.

사용되지 않는 알수 없는 영역인데,
예약된 영역, 혹은 Padding 영역이라고 생각이 듭니다.

String 테이블로 어떤 값들이 저장되어 있긴 한데,,, 뭔지 아직 잘 모르겠습니다.
추후 알아보고 업데이트 하겠습니다,
(추측이지만,, 뭔가 바이너리 XML 과 연관 되어있지않을까요?)

템플릿 테이블로 어떤 값들이 저장되어 있긴 한데,,, 뭔지 아직 잘 모르겠습니다.
추후 알아보고 업데이트 하겠습니다,
(추측이지만,, 뭔가 바이너리 XML 과 연관 되어있지않을까요?)

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

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

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

jwmsg

evtx 파일 구조분석 – 2

2018년 9월 8일2018년 9월 11일Security, WindowsLeave a Comment

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

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

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

해더에 part1 영역(지금 우리가 삽질중인 영역)의 크키
기본적으로 0x80

여기까지가 파일 헤더의 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 에서 레코드를 찾는 방법까지 알아보도록 하겠습니다. 글을 익어주셔서 진심으로 감사합니다!

jwmsg

evtx 파일 구조분석 – 1

2018년 8월 4일2018년 9월 11일Security, WindowsLeave a Comment

안녕하세요!

이 홈페이지를 개설하고나서 처음으로 글을 써 봅니다.

(사실 지금 매우 많은 블로그를 갖고 있으면서 글을 안쓰고 있죠;;)

앞으로 페북에 커밋하지 않고 이 블로그에 커밋하길 저 또한 희망합니다(제발 ㅠㅜㅠㅜ)

오늘부터 여러 편으로 나눠 evtx 파일에 대하여 알아볼까 합니다.

EVTX 파일?

Windows 의 이벤트로그를 저장하는 파일입니다. 과거 Windows XP 시절에는 EVT 파일이었으나 현재 Vista 이상버전부터는 확장명이 EVTX 로 바뀌며 구조 또한 조금 바뀌었다고 합니다. 이 파일은 c:/Windows/System32/winevt/Logs 에 다양한 종류로 존재하면서 대부분의 이벤트들을 기록하고 있습니다. 이 파일만 있다면, 컴퓨터에서 어떤일이 일어났는지 확인을 할 수도 있습니다.

다양한 EVTX 파일

Windows 에는 아래와 같은 종류의 이벤트로그가 존재합니다.

Application
Security
Setup
System
Forwarded Events

이 외에도 다양한 이벤트로그가 존재합니다. (너무 많아서 이하 설명을 생략합니다;;)

EVTX 파일의 기본구조

기본적으로는 Header 와 여러개의 Chunk 들로 이뤄져 있고 Chunk 속에는 Record 들이 있습니다. Record 가 계속 추가 되다가 Chunk 의 최대크기 (0x10000) 을 넘게 되면 새로 Chunk 가 추가되고 그 위에 Record 를 추가합니다.

그럼 이제 EVTX 의 기본 구조를 알아보았으니, 다음편에서는 EVTX의 Header 구조와 Chunk 를 알아보겠습니다.