이벤트 로그는 윈도우에만 있는 기능으로 컴퓨터에서 일어나는 일련의 모든 작업이 기록된다. 이러한 로그는 컴퓨터 관련 범죄가 일어나게 되면 중요한 단서가 된다. 침입자가 들어와 해킹한 흔적을 알아내거나 그가 여기서 무엇을 했는지조차 나오므로 법적 전자증거로도 사용할 수 있다. 관리자 역시 이벤트로그를 관리하여 누가 컴퓨터에 침입했는지 혹은 자신의 시스템의 취약한 부분이 있는지 확인할 수 있다. 또한, 시스템상 장애가 발생할 시에 복구에 필요한 정보로도 사용되기도 한다. 이렇듯 이벤트로그는 다양하게 활용할 수 있으며 해킹 사고를 미리 막을 수 있는 용도로 사용되거나 사고가 일어난 후 그 과정을 담아내는 역할을 담당하고 있다. 하지만 간혹 침입자들은 시스템에 침입하여 정보를 탈취한 후 자신의 흔적을 지우면서 이벤트로그를 삭제하고 나간다. 그래서 나온 것이 이벤트 로그 파일을 복구하는 카빙이다.

이벤트 로그란 정확히 윈도우 상에서 발생한 시스템 사용과 관련한 정보를 기록하는 흔적으로서 즉, 시스템 내에서 어떠한 작업을 할 시에 그 작업이 발생한 시간과 날짜, 이벤트가 일어난 프로세스, 이벤트 유형을 식별하는 Event ID 등과 같은 정보가 담겨있는 흔적을 모아 둔 것을 말한다. 이벤트 로그 파일인 EVT 파일은 2008년부터 EVTX 파일로 변경되어 EVT 파일보다 더 많은 Event ID를 포함하고 있다..

사용자은 ‘제어판 → 관리도구 → 이벤트 뷰어’에서 이벤트로그를 확인할 수 있다. 혹은 윈도우 검색창에 ‘이벤트 뷰어’라고 검색하면 나온다. 이벤트는 오류, 경고, 정보, 성공검사로 표현되며 로그의 종류로는 응용 프로그램과 관련된 Application 로그, 유효하지 않은 로그인 시도나 파일을 생성 및 열람, 삭제 등과 괸련된 Security 로그가 있다. 또한, 시스템의 구성요소를 기록하는 System 로그가 있다. 외에도 윈도우즈 업데이트 로그를 나타내는 Setup 로그나 Cisco, Microsoft 로그가 있다.

이렇게 이벤트 로그에는 시스템에서 일어나는 거의 모든 정보를 담기 때문에 침입자는 이벤트 로그를 삭제하고 나가기도 한다. 이렇게 침입자가 이벤트 로그를 삭제하고 나갔을 경우, 분석가는 침입자를 추적하기 위해 파일 시스템 내에서 이벤트 로그의 흔적을 찾는다. 파일 시스템에 있는 이벤트 로그는 이벤트 로그의 고유 시그니처를 통해 찾을 수 있다. 파일 시스템에서 각각의 파일을 보면 그 파일 형식만의 고유한 시그니처가 있다. 이러한 시그니처를 통해 파일 시스템에 있는 이벤트 로그 파일을 찾을 수 있다. 더불어, 이벤트 로그는 각 구조를 나타내는 시그니처가 존재하여 이러한 일부분의 구조를 모아 하나의 이벤트 로그를 만들어낼 수 있다.

이벤트 로그는 크게 헤더와 데이터로 나뉘어 있으며 여러 청크들로 구성되어 있다. 다시 하나의 청크 안에는 청크 헤더와 여러 레코드로 이루어져 있으며 레코드 안에는 레코드 헤더와 진짜 이벤트 데이터가 존재한다. 이런 것들이 모여 이벤트 로그는 수많은 청크와 수많은 레코드로 이루어져 있다고 해도 과언은 아니다. 이러한 구조로 나눠어져 각각의 공간에 존재하는 헤더의 시그니처를 찾는다. 이벤트 로그의 파일 헤더 ‘ElfFile’를 파일 시스템에서 찾는 것은 어려운 일이 아니다.

수많은 청크와 레코드는 각각의 청크와 레코드를 구별할 수 있는 번호가 붙어 각각을 구별할 수 있다. 먼저 청크 헤더의 시그니처인 ‘ElfChnk’를 파일 시스템 내에서 찾아 이벤트 로그가 가지고 있는 레코드의 수와 마지막 레코드의 번호가 무엇인지 확인한다. 그런 후, 나와있는 레코드의 갯수대로 레코드를 수집하여 하나의 청크를 구성하거나 레코드의 ID, 번호를 통해 특정 레코드에 접근할 수 있다. 레코드의 구분은 레코드의 시그니처 다음으로 나오는 'size'를 나타내는 값이 처음과 끝에 포함되어 있어 이를 통해 하나의 레코드를 구분한다.

이벤트로그는 XML 바이너리 구조로 구성되어 있다. 이 말은, 기존에 만들어져 있는 정형화된 구조에 데이터만 가져와 추가하여 이벤트 로그를 표현한다. 이러한 XML 바이너리 구조는 처음부터 만들어져 있는 것이 아니라 처음에는 이벤트를 표현할 가장 기본적인 데이터 형식만 가지고 있다. 그런 후에 이벤트가 발생하면 이벤트가 표현해야하는 내용에 따라서 구조에 형식이 추가된다. 즉, 이벤트를 표현할 때 새로운 표현 방식의 데이터가 추가되면 XML 바이너리에 형식이 추가되고 들어오는 데이터가 앞에 들어왔던 데이터와 비슷하면 형식을 가져다 쓴다. 이렇게 구조를 나타내는 XML 바이너리를 토큰이라고 하며 토큰은 데이터의 구조를 표현하는 것에 따라 시스템 토큰과 데이터를 표현하는 애플리케이션 토큰으로 나눠져 있다. 이러한 XML을 통해 이벤트 로그를 표현하는 이유는 데이터의 크기를 줄일 수 있고 이벤트를 표현하기에도 효율적이다.

어떤 파일이 삭제되었을 때 이를 다시 되살리는 것을 복구 및 카빙이라고 한다. 정확히 말하면 어떤 파일이 삭제되었을 때 파일은 완전히 사라지는 것이 아니라 단지 컴퓨터 내에 있는 파일로 찾아갈 수 있는 링크가 사라지고 파일은 파일시스템 내에 온전하게 존재한다. 따라서 사용자가 파일을 완전 삭제하더라도 사실은 파일을 복구할 수가 있다. 문제는 파일이 저장되어 있는 형태에 따라서 달라진다. 사용자가 파일을 생성하게 되면 파일에 대한 데이터는 메모리에 저장된다. 이 때 보통은 시스템 효율상 데이터는 메모리에 순차적으로 저장되지만 메모리에 공간이 넉넉치 않을 경우, 빈 공간 곳곳에 나뉘어 저장된다. 앞서 말한 전자의 경우를 순차적 할당이라 하며 후자의 경우를 비순차적 할당이라 한다. 이런 경우 곳곳에 흩어진 데이터들로 인해 복구의 어려움이 있다.

또 다른 문제점으로 삭제가 되면 링크는 사라지고 파일의 데이터는 남아있지만 사실상 그 데이터는 존재하지 않는 데이터다. 따라서 사용자가 다른 새 파일을 저장할 때 기존에 삭제된 파일의 데이터 위로 저장될 수가 있다. 이럴 경우, 특히나 중요한 일부분이라도 덮어 씌워지게 되면 온전한 파일이라 인식되지 않아 파일의 복구가 어렵다.

현재 이벤트 로그의 카빙 프로그램에서는 이러한 문제에 대해 어떻게 해결할 것인지가 가장 핵심적인 포인트다. 최대한 유실된 데이터도 없어야 하며 구조를 찾지 못하고 남겨진 고아 데이터도 살려줄 수 있어야 한다. 이 카빙의 가장 완벽한 목표는 완벽한 파일을 하나 드랍하는 것이다. 하지만 이 같은 문제점들이 남아 있어 사실상 고민을 많이 해봐야 하는 문제다. 이 글을 보고 누군가는 번뜩이는 아이디어가 생각날 수 있지 않을까 한번 글로 적어본다.