Yum_Yum

[Digital Forensic] Chain of Custody

 

---

(1) CoC

• 현재의 증거가 최초로 수집된 상태에서 지금까지 어떠한 변경도 되지 않았다는 것을 보증하기 위한 절차적 방법

• 미국의 경우 Chain of Custody가 지켜지지 않으면 해당 증거물은 법적 증거 효력을 갖지 못하게 되며 해당 증거물에서 나오는 모든 증거물은 법적 증거효력을 갖지 못함

• Chain of Custody는 수사 기관 등에서 의도적 증거 조작으로부터 피의자를 보호하려는 성격을 지님

 

1-1. Chain of Custody 부정

• Chain of Custody 부정 방법 중 대표적인 것은 일시적 증거 무관리 상태를 증명하는 것

• 일시적 증거 무관리 상태란, 증거 보관자와 증거가 물리적으로 떨어진 상태를 말함

• 무관리 상태는 증거 보관자가 증거와 떨어져 있는 사이 증거가 변경될 수 있다는 가정을 의미하기 때문에 부정 방법으로 쓰임

 

1-2. Chain of Custody 수행

• Chain of Custody를 수행하기 위해 작성하는 문서가 있는데 이 문서의 포맷은 어떠한 표준이 있는 것은 아님

• 각 기관(회사)마다 조금씩 양식의 차이가 있음

• 그러나 기입하는 내용은 대부분 동일

 

 

Chain of Custody는 '연계 보관성'으로 번역되기도 한다.

 

CoC의 가장 중요한 점은 어떠한 물건이 이동하는 과정의 기록이라 할 수 있다.

 

디지털 포렌식 입장에서는 증거물의 이동 과정에서 그 대상의 무결성이 보존되었다는 증거로도 활용되며 그 과정에서 발생되는 사건에 대해서 기록되어야 한다는 것이다.

 

디지털 포렌식에 있어서 무결성이란 그 무엇보다 중요시 하기도 하며 그 무결성에 의해 큰 제약을 받기도 한다.

---

# Reference

 

http://www.yes24.com/Product/Goods/8511539

[Incident Response]  침해사고 대응(Incident Response)

 

---

(1) Incident(사고) vs Event(사건)

1-1. Event(사건)

• 시스템이나 네트워크에서 관찰 가능한 모든 행위들

• 악의적 Event , 정상적 Event, 의심스러운 Event 등 매우 다양

• 예시)

  • 공유 폴더(Shared Folder)에 연결하는 사용자

  • 웹 페이지 요청을 수신하는 서버

  • 이메일을 보내는 사용자

 

1-2. Incident(사고)

• 사내 컴퓨터 보안 정책 위반

• 시스템 권한 불법적 사용

• 민감한 데이터 무단 접근

• 악성코드 실행 등과 같은 부정적 결과를 초래하는 유해한 모든 이벤트

• 예시)

  • 봇넷에서 웹 서버에 많은 양의 연결 요청을 보내 서비스 거부를 유발하도록 명령

  • 사내 이메일을 통해 수신된 악성 첨부파일 실행

  • 조직의 민감한 데이터를 입수한 공격자가 금액을 지불하지 않으면 공개하겠다며 협박

  • 내부자가 P2P 파일 공유 서비스를 통해 민감 정보를 제 3자에게 제공 / 노출 

---

(2) Asset(자산), Threat(위협), Vulnerability(취약성), Risk(위험)의 개념

2-1) Asset(자산)

• 조직 내의 보호가 필요한 유형 / 무형의 모든 객체들

• '자산'을 지키는 것을 '정보보안'으로 표현 가능

• 예시)

  • 유형 : 조직원, 외주 직원, 고객, 서버, 기타 유형의 것들

  • 무형 : 회사 평판, 주요한(민감한) 사내 데이터, 소스 코드, 기타 무형의 것들

 

2-2) Threat(위협)

• 취약점(vulnerability)을 악용하여 자산(asset)에 접근 / 손상 / 파괴하려는 모든 시도들

• 예시)

  • 하루 평균 10000건 정도의 웹 서버에 대한 SQL Injection 공격 시도

  • 사내 이메일을 통해 수신되는 모든 악성 메일

  • 권한 없는 조직원이 사내 민감 정보에 접근하려는 시도들

  • 인터넷에 공개된 제로-데이, 원-데이 취약점을 이용한 공격 시도

 

2-3. Vulnerability(취약성)

• 위협(threat)에 의해 권한 없이 무단으로 사용될 가능성이 있는 자산(asset)이 갖고 있는 기술적 / 정책적 / 관리적 약점(weakness)

• 예시)

  • 회사 홍보 목적으로 사용하는 사내 웹 서버에 SQL 취약점 존재

  • 조직원들의 보안 인식 부재로 사내 메일로 수신되는 악성 첨부파일 실행 가능성

  • 사내 특정한 자산들에 해당되는 제로-데이 취약점 공개

 

2-4. Risk(위험)

• 사내 자산(asset)에 존재하는 취약성(vulnerability)에 대한 악용 위협(threat)으로 인한 자산 손실, 손상 또는 파괴 가능성

• 위험 관리 방법으로는 웹 방화벽 설정, 웹 서버에 대한 SQL Injection 제거 등이 있음

• 예시)

  • SQL Injection 취약점이 존재하는 웹 서버에 대한 공격 시도로 사내 정보 유출 및 위변조

  • 보안 인식이 부족한 조직원이 사내 메일을 통해 수신된 악성 첨부파일 실행

  • 권한 관리가 되어 있지 않은 주요 서버에 권한 없는 조직원이 접근하여 정보 열람

---

(3) A-V-T-R Model

3-1. A-V-T-R 모델?

• 자산(asset) 내에 존재하는 취약성(vulnerability)을 위협(threat)으로 발생하는 실질적 손해와 그 가능성을 위험(risk)이라고 함

• 즉, 자산(asset) + 취약점(vulnerability) + 위협(threat) = 위험(risk)

---

(4) Purpose : IR

4-1. 침해사고 대응 목적

• 침해 사고에 효율적 / 효과적으로 대응하기 위한 조직 실정에 맞는 실질적 대응 지침 수립

• 조직의 자산(asset)에 존재하는 취약성(vulnerability)에 대한 공격 위협(threat)으로 부터 컴퓨터 침해사고(incident) 발생 시 초래되는 위험(risk)을 완화(mitigation)하도록 지원

• '침해사고를 막는다(block)'는 개념보다 '완화(mitigation)'하는 개념

 

4-2. 완화의 개념

• 식별(identification)

• 격리(containment)

• 제거(Eradication)

• 복구(Recovery)

• 사후-활동(Post-Incident Activity)

---

(5) 침해사고 대응 절차

 

---

5-1. 예방 단계

1) 준비(Preparation)

• 원활한 침해사고 대응을 위한 정책 / 계획 / 절차 / 지침 수립

• 원활한 침해사고 대응을 위한 탐지 센서 구축 / 설치

 

2) 탐지(Detection)

• 준비 단계에서 구축 / 설치한 탐지 센서들로부터 위협(threat) 모니터링

• 실제 공격 시도인지? (정탐 / 오탐 구분)

• 정탐이면 '분석 단계'로 진행하고, 오탐이면 '탐지 단계'로 리턴 

---

5-2. 심사 단계

3) 분석(Analysis)

• 내부 자산(asset)에 대한 위협(threat)이 실제로 취약성(vulnerability)에 위험(risk)을 발생시켰는가?

• 실제 공격이 성공한 호스트에서는 어떠한 일이 발생했는가? (영향도 분석)

• 공격이 실제로 성공하지 않았으면 '탐지 단계'로 리턴하고, 공격이 실제로 성공했으면 '식별 단계'로 진행

• 얼마나 심각한 공격이 성공했는가? (심각도 분석)

• 너무 많이 '분석 단계'에서 머물러 있지 않되, 다음 단계들을 진행하면서 같이 병행하며 추가적 정보를 지속적으로 획득하는 것이 중요

 

4) 식별(Identification)

• 공격자가 내부 시스템에 얼마나 많은 발판(foothold)을 설치했는지 식별하는 단계

• 공격이 성공적으로 실행된 경우, 내부 전파(측면 이동)가 공격자의 일반적인 첫 단계이므로 사고 범위를 빠르게 결정하는 것이 매우 중요

• 해당 시스템만 영향을 받는가? (사고 범위 분석)

 

---

5-3. 완화 단계

5) 격리(Containment)

• 다른 시스템이 추가 점령 / 감염 / 전파되는 것을 막기 위한 단계

• 식별 단계를 통해 파악된 사고의 범위를 통해 격리 범위 판단 가능

• 현실적으로 완벽히 / 신속히 수행되기 매우 어려운 단계

예시 1) 사고 범위가 해당 서버 1대인 경우

• 확인된 공격자의 C2 서버 IP 차단

• 서버 랜선 절췌

• 서버 셧다운

예시 2) 사고 범위가 특정 네트워크 대역대인 경우

• 확인된 공격자의 C2 서버 IP 차단

• 방화벽을 통한 해당 네트워크 대역대 인 / 아웃바운드 접근 제어

• 이후 점진적인 서버 랜선 절췌 / 셧다운

 

6) 제거(Eradication)

• 공격자가 내부 시스템에 설치한 발판(foothold)들을 제거하는 단계

• 일부 케이스에서는 '제거 / 복구 단계'를 병행하여 같이 수행

• 예시)

  • 안티 바이러스 솔루션을 통한 치료

  • 악성 파일 및 프로세스 삭제 / 종료

  • 침해된 사용자 계정 비활성화 / 삭제

  • 악용된 취약점 / 서비스 제거

 

7) 복구(Recovery)

• 공격자에 의해 영향 받은 시스템에 대해 이전과 같은 정상 상태로 복구하기 위한 단계

• 예시)

  • 백업 서버를 통한 서버 재설치 / 교체

  • 손상되거나 위변조된 내부 데이터베이스 복원

  • 재감염 여부 모니터링 수행

 

8. 사후 활동(Post-Incident Activity)

• 사고 원인을 다시 추적 / 분석하며, 이전 단계에서 놓친 부분이 없는지 재확인하고 보고하는 단계

8-1. 조사(Investigation) - optional

• 이번 침해사고에 대한 전체적인 타임라이닝(timelining) 및 추가적 세부사항 작성

• 이번 침해사고에 대한 가시성 확보, 원인을 파악함으로써 내부 보안성 강화 기회 제공

• 많은 시간 소모, 높은 수준의 기술력 요구

• 조사가 필요한 수준의 사고였는지 판단 필요

8-2. 강화(Hardening)

• 이전 단계들을 수행하며 보안성을 향상할 필요가 있었던 부분에 대한 강화 진행

예시)

• 이메일이 벡터인 경우 > 이메일 필터링 강화 / APT 솔루션 도입 혹은 내부 직원에 대한 스피어피싱 교육 실시

• 웹 서버가 벡터인 경우 > 웹 서버 보안 점검 프로세스 혹은 시큐어 코딩 의무화 실시

---

# Reference

 

https://attack.mitre.org/

[Digital Forensic] 안티 포렌식(Anti Forensics)

 

 

흔히 어떠한 기술의 반대적 성향을 가진 기술 명칭에는 Anti 라는 단어가 붙어 명명되곤 한다.

 

또 'Anti'라는 단어가 붙은 기술을 보면 대부분 좋지 않은(보안 기술과 반대적인 크래킹 등) 기술들이어서 일반적인 인식 자체가 좋지 않은 기술로 사람들 머리 속에 자리잡게 되곤 한다.

 

하지만 안티 포렌식은 그렇지 않다.

---

(1) 안티 포렌식이란? 

• 어떠한 사건을 해결하기 위한 포렌식 기술 수행을 방해하기 위한 것이 목적이므로 좋은 기술이 될 수 없음

• 현재 포렌식이 각광을 받고 있고 또 그 시장 규모가 예전에 비해 많이 팽창함에 따라 포렌식 연구가 활발히 진행

• 반면에 안티 포렌식에 대비하는 연구는 아직 미비

• 대부분의 문서에서는 안티 포렌식의 예로 루트킷을 거론하곤 함

루트킷을 거론하는 이유는 안티 포렌식 기술의 대부분을 루트킷이 수행하기 때문이다.

 

그렇기에 안티 포렌식의 모음이라고 할 수 있는 루트킷을 거론하는 것이다.

 

안티 포렌식에는 여러 종류의 기술들이 존재한다. 그 기술을 수행하는데 있어 방법은 여러 가지이다.

 

그러므로 이 섹션에서는 기술의 종류만 정의할 것이다. (기술의 명칭이 명명되지 않은 이유도 있다)

 

 

1-1. Data Destruction

• 포렌식을 어렵게 하는 근본적 이유는 데이터 부족

• 수집된 데이터가 부족하다면 분석할 수 있는 범위가 그만큼 한정되기 때문

• Data Destruction은 수집될 수 있는 데이터들을 수집되지 못하도록 완전히 삭제 하는 것을 의미

 

데이터 완전 삭제는 일반적으로 Wiping이라고 불린다.

 

그런데 대부분의 문서를 보면 Wiping의 수행 횟수를 제시한다.

 

왜 1번이 아니라 여러 번을 시도하라고 권장하고, 기존 데이터를 다른 데이터로 덮어씌우는 Wiping은 1번만 해도 그 데이터가 완전 삭제되는 것이 아니던가?

 

이유는 바로 요즘 출시되는 하드 디스크의 특성 때문이다.

 

요즘 하드 디스크의 플래터에는 강한 자성을 이용해 데이터를 저장하려고 플래터 표면에 코발트, 크롬, 산화 알루미늄과 같은 자성 물질을 코딩시켜 두는데 이 자성 물질에 데이터가 저장되게 되면 데이터가 저장된 자성 물질 부분에 데이터가 저장되지 않은 자성 물질과 높낮이 차이가 생기게 된다.

 

 

[그림 1] 상태에서 데이터를 삭제하기 위해 Wiping을 수행하게 되면 자성 높이가 조금은 낮아지게 된다.

 

하지만 기존 자성 물질들과의 높낮이 차이는 아직 있기에 몇 번의 Wiping을 수행해 그 높낮이 차이를 해소하고 자성 물질의 높낮이 차이를 이용해 데이터를 복구할 수 있다는 이론이 존재하기 때문에 혹시라도 모르는 상황을 대비해 여러 문서에서는 최소 3번 이상의 Wiping을 권고하고 있다.

 

 

 

1-2. Data Hiding

• 데이터를 숨기는 행위

• 데이터가 발견되지 못하게 하거나 발견하기까지 시간이 오래 걸리도록 하기 위한 목적의 기술

• 대부분 파일 시스템의 비할당 영역이나 예약 영역, 슬랙 영역 등에 데이터를 숨기고는 함

• 요즘은 포렌식 분석 도구들이 이런 부분도 모두 체크하여 분석해주기 때문에 현재의 포렌식 기술에는 크게 영향을 미치지 못함 

 

1-3. Data Transformation

• 데이터의 형태를 변환하는 기술

• 대표적으로 암호화를 들 수 있음

• 분석가가 데이터의 원본과 의미를 알기까지의 시간을 벌거나 데이터의 본래 의미를 숨길 때 사용하는 기술

 

1-4. Data Contraception

• 데이터를 분석이 불가능한 위치에 저장해 데이터를 아예 찾지 못하게 하는 기술

• 해당 기술은 포렌식 데이터의 수집량을 줄이기 위한 것이 가장 큰 목적

 

1-5. Data Fabriacation

• 데이터 분석의 결과를 잘못된 방향으로 흐르게 하는 기술 및 방법

• 분석가가 분석하는 데이터를 임의로 조작하여 도출되는 결과를 잘못된 결과로 만드는 기술

• 데이터 조작에 있어 정교함이 필요한 기술

 

1-6. Preventing Data Creation

• 포렌식 분석에 필요한 데이터 생성을 하지 않도록 시스템 설정을 변경하는 기술

• 대표적으로 타임라인 분석에 있어 필요한 타임 스탬프 값의 업데이트를 방지하는 기술

• Windows 시스템의 경우 레지스트리 값을 조작하여 타임스탬프의 업데이트를 하지 않도록 할 수 있음

 

1-7. Overwriting Metadata

• 대부분의 파일 시스템에서 데이터가 삭제될 경우 해당 데이터의 메타데이터와 데이터가 저장된 파일 시스템 영역의 링크가 끊어져 사용자에게는 파일이 삭제된 것처럼 보임

• 파일 시스템에는 사용자가 삭제 명령을 내린 데이터가 고스란히 남아 있음

• 포렌식 도구들은 이러한 원리를 이용해 메타데이터를 분석하고 해당 메타데이터에 대한 데이터를 찾아 복원시켜줌

• 해당 기술도 이런 원리를 이용해 메타데이터를 임의의 값으로 덮어 씌워 포렌식 도구나 분석가가 메타데이터를 이용해 데이터를 찾지 못하도록 함

 

1-8. Degaussing

• 앞에서 언급한 기술들이 모두 소프트웨어적 기술이면 디가우징은 하드웨어적 기술

• 하드 디스크는 일반적으로 자기성분을 이용해 데이터를 디스크에 쓰는데, 이 자기성분보다 더 강한 자기성분을 디스크에 씌우면 디스크는 자기성분을 이기지 못하고 모든 데이터를 휘발시켜 버림

• 예전의 일반적인 디가우저(디가우징 장비)는 대상 하드 디스크의 데이터를 모두 삭제 시키고 해당 하드 디스크를 사용하지 못하게 했음

• 요즘 디가우저는 DDOS라는 기술을 사용해 디가우징이 이루어지고 난 후에도 해당 디스크를 재활용할 수 있게 함

• 원래 디가우징 기술은 안티 포렌식이 아닌 관공서나 군부대 등에서 비밀을 유지하고 정보 유출 방지를 위해 사용되었지만 요즘은 안티 포렌식에도 가끔 사용

 

안티 포렌식의 기술 종류는 위처럼 매우 다양하다.

 

위 종류들의 안티 포렌식 기술들이 모두 적용되거나 하나의 기술만이라도 완전히 적용 된다면 포렌식 수행 과정은 정말 힘들고 험난할 것이다.

 

하지만, 안티 포렌식 기술의 완전한 성공은 현재로서는 어렵다.

 

포렌식은 사실 컴퓨터를 구성하고 있는 각 부품들과 소프트웨어를 개발하는 업체들에 의해 이루어지고 있다고 해도 과언이 아닐만큼 컴퓨터 부품이나 소프트웨어에서 지원하는 기능과 데이터에 많이 의존한다.

 

안티 포렌식은 포렌식과 달리 받쳐주는 받침대 역할의 부품이나 소프트웨어가 턱없이 부족하기 때문에 안티 포렌식을 완전히 수행할 수는 없다.

 

 

EXFORENSIS 블로그의 블로거는 다음과 같은 이유로 안티 포렌식이 실제 침해사고에서 완전히 성공할 수 없다고 언급하였다.

 

• 대부분의 파일 삭제 도구들은 파일 삭제 흔적(로그 등)을 남긴다.

• 대부분의 도구에는 도구가 파일 삭제를 수행할 시 원하는 행위를 하도록 하는 옵션이 존재하지만 이 옵션을 설정한다고 하더라도 도구가 설정된 옵션에 따라 파일을 완전히 삭제하지 못할 수도 있다.

• 비할당 영역의 데이터를 삭제하는 일은 생각만큼 빨리 끝나지 않는다.

• 포렌식적으로 의미가 있는 데이터를 오나전히 지우는 도구는 존재하지 않는다.

• 대부분의 사람들은 비밀번호로 컴퓨터를 보호하기 때문에 데이터의 대한 보안을 생각해 데이터를 주기적으로 완전히 삭제하는 일은 하지 않는다.

 

첫 번째에서 언급한 파일 삭제 도구의 흔적은 우리가 일반적으로 알고 있는 완전 삭제 프로그램인 BCWipe에서도 찾아볼 수 있다.

 

 

위 [그림 3]은 BCWipe 프로그램을 이용해 결정적인 증거물을 지우려는 장면이다.

 

BCWipe의 로그는 사실 설정이 필요한 부분이지만, 로그 기능을 지원한다는 점을 중요하게 생각해야 한다.

 

개인이 사용할 때에는 로그 기능을 사용하지 않겠지만, 공공기관이나 기업체에서 사용할 때에는 기록이 중요하기 때문에 로그 기능을 활성화해 두는 일이 많다.

 

 

위 설정을 통해 파일 삭제 도구도 기록을 남기고 어떤 파일이 지워졌는지 알아낼 수 있다.

 

물론 원본 파일을 복구하지는 못하겠지만 말이다.

 

안티 포렌식의 기술은 현재로선 완벽하지 못한 기술들이 대부분이다.

 

하지만 포렌식은 피의자 입장에서 생각해봐야 하는 분야이다.

 

그러므로 피의자 입장에서 포렌식을 무력화할 방법은 어떤 것이 있는지, 또 그 방법을 어떻게 찾아내고 대응해야 할 것인지에 대한 연구나 고민을 지속적으로 해야할 것이다.

 

지구 어디에선가 안티 포렌식 기술을 연구해 한 순간에 악성코드나 불법적인 행위를 통해 공개할 수 있다.

 

이렇게 될 경우 해당 안티 포렌식 기술에 대응하기 위해 연구하는 동안 또 다른 추가 피해가 생기고 정상적 침해에 대한 대응을 못할 수도 있다.

 

포렌식 연구가 활발히 진행되는 만큼 안티 포렌식과 관련된 연구도 진행되어야 할 것이다.

---

# Reference

 

http://www.yes24.com/Product/Goods/8511539

[Digital Forensic] PE 구조 분석

 

 

포렌식에서 메모리 분석을 통해 파일을 카빙한다거나 하드디스크 이미지에서 파일을 카빙하여 해당 파일이 무엇인지 분석하려고 할 때 꼭 필요한 지식이기에 PE 구조를 상세하게 공부해 볼 것이다.

 

일반적으로 포렌식에서 파일을 분석할 경우는 악성코드로 의심되는 파일을 분석하는 경우로 정적 분석과 동적 분석을 하게 된다.

 

리버스 엔지니어링 같은 경우에는 정적 분석에 속하며, 정적 분석을 할 경우 어셈블리어와 메모리 구조 등에 대한 지식도 있어야 하지만, PE 구조에 대한 지식도 있어야 하기에 이렇게 상세히 PE 구조를 알아보려고 한다.

 

PE(Portable Executable) 파일 포맷은 윈도우에 해당하는 파일 포맷으로 .exe, .dll, .cpl, .sys, .scr, .drv, .vxd, .ocx 확장자를 가진 파일들에게서 볼 수 있다.

 

PE 구조를 보다 보면 IMAGE로 시작하는 구조체들을 많이 보게 되며, 이는 윈도우에서 실행 파일을 IMAGE라는 명칭으로 대신하기 때문에 구조체 이름도 그렇게 지은 것이다.

---

PE 구조는 다음 그림과 같다.

 

---

(1) DOS 영역

• 윈도우 실행 파일을 DOS 모드에서 실행하려고 할 때, 사용자에게 에러 메시지를 보여주기 위해 존재

• 실제로 이 영역은 윈도우 실행 파일이 윈도우에서 실행할 때에는 아무런 영향을 주지 않는 부분이어서 볼만한 내용이 많지 않음

• DOS MZ Header와 DOS Stub Program 영역으로 이루어짐

 

 

1-1. DOS MZ Header

• WinNT.h 헤더 파일에 정의되어 있음

• 눈 여겨 볼 구조체 멤버는 e_magic과 e_lfanew 구조체 멤버

• 다른 구조체 멤버들은 사용하지 않거나 PE 파일 포맷 내에서는 사실상 의미가 없음

 

e_magic

• 이 구조체 멤버는 DOS MZ Header의 맨 앞(PE 파일 맨 앞)을 나타내며 16진수는 '4D 5A' 값을 가짐

• 아스키코드로 변환하면 MZ라는 값을 가짐

• MZ는 도스를 최초로 설계한 사람 중 한 명인 Mark Zbikowksi의 이니셜

• 모든 윈도우의 실행 파일은 MZ로 시작하기 때문에 이 값을 검색해 실행 파일을 찾을 수도 있음

 

e_lfanew

• 이 구조체 멤버는 PE 파일의 머리 격인 IMAGE_NT_HEADER를 가리키는 오프셋 값을 가짐

 

DOS MZ Header의 구조체 구조는 다음과 같다.

 

 

 

다음 그림은 notepad.exe의 DOS MZ Header 영역을 보여준다.

 

 

• 4D 5A : e_magic

• F0 00 00 00 : e_lfanew (E0 00 00 00)

이 두 값이 올바르면 프로그램은 실행하는데 문제가 없다.

 

 

1-2) Dos Stub Program

• 사용자가 DOS 모드에서 윈도우용 실행 파일을 실행하였을 때 문구를 출력해주기 위한 코드가 있는 부분

 

출력하는 문구는 다음과 같다.

 

'This Program cannot be run is DOS mode'

 

 

이 부분은 오프셋 0x40 ~ 0x7F까지이다.

 

---

(2) PE Header 영역

• PE 파일의 시작 부분

• PE File Signature, PE File Header, PE File Optional Header 영역이 있음

• IMAGE_NT_HEADERS 구조체로 이루어짐

 

위쪽에 정의된 구조체는 32bit 구조체이며 아래는 64bit 구조체이다.

 

어느 정도 직관적인 구조체 멤버 이름을 통해서 왜 PE 헤더 영역이 3가지로 나누여졌는지 알 수 있다.

 

 

2-1. PE File Signature

• DOS의 e_magic 구조체 멤버처럼 PE 영역의 시작을 알리는 값을 가지고 있는 영역

• 모든 파일에서 그 값은 항상 동일

• 그 값은 'PE/0/0(0x50)/0x45/0x00/0x00)'

• 메모리나 파일 시스템 분석에서 삭제된 실행 파일을 찾는 데에 중요한 단서가 됨

 

PE File Signature 값은 다음 그림과 같다.

 

 

여기서 중요한 것은 DOS MZ Header 설명 부분에서 설명한 것과 같이 DOS MZ Header 영역의 e_lfanew 구조체 멤버는 IMAGE_NT_HEADER의 주소를 가지고 있다고 설명하였으며, 여기서 그 사실 확인이 가능하다.

 

 

2-2. PE File Header

• 실행 파일 자체의 메타데이터를 가지고 있음

• 길이는 20바이트

• 구조체는 IMAGE_FILE_HEADER 구조체 사용

 

구조체 정보는 다음 그림과 같다.

 

 

 

1) Machine

• 실행 파일이 사용하는 CPU를 나타내는 번호를 가지고 있음 

 

Machine 종류는 다음 표와 같다.

 

 

[표 1] Machine 목록

CPU 종류	값	설명
IMAGE_FILE_MACHINE_UNKNOWN	0x00	어떤 머신에도 적용이 가능한 종류
IMAGE_FILE_MACHINE_AM33	0x01D3	마쯔시다 AM33
IMAGE_FILE_MACHINE_AMD_64	0x8664	64bit CPU(Intel 포함)
IMAGE_FILE_MACHINE_ARM	0x01C0	ARM(Little Endian)
IMAGE_FILE_MACHINE_EBC	0x0EBC	EFI Byte Code
IMAGE_FILE_MACHINE_I386	0x014C	Intel 386 또는 그 이후 Processor
IMAGE_FILE_MACHINE_IA64	0x0200	Intel Itanium Processor
IMAGE_FILE_MACHINE_M32R	0x9041	미쯔비시 M32(Little Endian)
IMAGE_FILE_MACHINE_MIPS16	0x0266	MIPS16
IMAGE_FILE_MACHINE_MIPSFPU	0x0366	MIPS(FPU 지원)
IMAGE_FILE_MACHINE_MIPSFPU16	0x0466	MIPS16(FPU 지원)
IMAGE_FILE_MACHINE_POWERPC	0x01F0	Power PC(Little Endian)
IMAGE_FILE_MACHINE_POWERCFP	0x01F1	Power PC(부동소수점 지원)
IMAGE_FILE_MACHINE_R4000	0x0166	MIPS(Little Endian)
IMAGE_FILE_MACHINE_SH3	0x01A2	Hitachi SH3
IMAGE_FILE_MACHINE_SH3PSP	0x01A3	Hitachi SH3 DSP
IMAGE_FILE_MACHINE_SH4	0x01A6	Hitachi SH4
IMAGE_FILE_MACHINE_SH5	0x01C2	Thumb
IMAGE_FILE_MACHINE_WCEMIPSV2	0x0169	MIPS(Little Endian WCE V2)

 

 

2) NumberOfSections(NoS)

• 실행 파일이 가지고 있는 섹션의 개수를 의미

• 만약 섹션을 삭제, 추가하면 이 구조체 멤버의 값 또한 변경 필요

 

3) TimeDataStamp

• 실행 파일이 컴파일된 시간으로 이 시간은 컴파일 한 컴퓨터의 시스템 시간을 의미

• 32비트 유닉스 포맷으로 GMT를 기준으로 함

• 만약 '0x4A5BC60F' 값이 저장되어 있다면, 이 값을 10진수로 변환하였을 경우 '1247528463'라는 숫자를 의미

 

우리가 알아볼 수 있는 날짜로 변환하게 되면 다음과 같다.

 

 

4) PointerToSymbolTable(PTST)

• COFF 심볼 파일의 오프셋을 값으로 가짐

• 컴파일러에 의해 생성된 OBJ 파일이나 디버그 모드로 만들어져 COFF 디버그를 가진 PE 파일에서만 사용됨

• COFF 심볼 테이블은 이제 더 이상 사용하지 않아 이 값은 반드시 0으로 설정되어야 함

 

5) NumberOfSymbols(NoS)

• 심볼 테이블에 있는 엔트리 개수를 나타냄

• COFF 심볼 테이블은 더 이상 사용되지 않으므로 반드시 0으로 설정되어야 함

 

6) SizeOfOptionalHeader(SOOH)

• Optional Header의 크기를 값으로 가짐

• 실행 파일에서만 필요하며, 일반적으로 32bit 시스템은 E0의 값을 가짐

 

7) Characteristics(Char)

• 파일의 속성을 결정하는 값을 가짐

 

Characteristics의 값들은 다음 표와 같다.

 

 

[표 2] Characteristics

속성 이름	값	설명
IMAGE_FILE_RELOCS_STRIPPED	0x0001	실행 파일 전용, 이 파일은 재배치되지 않으므로 반드시 지정된 베이스 주소에 로그 필요, 지정된 베이스 주소가 사용 불가능하면 에러 발생
IMAGE_FILE_EXECUTABLE_IMAGE	0x0002	실행 파일 전용, 실행 파일은 검증되었으며 실행 가능, 이 값이 설정되어 있지 않으면 그것은 링크 에러 의미
IMAGE_FILE_LINK_NUMB_STRIPED	0x0004	COFF 라인 번호는 더 이상 사용하지 않으므로 이 값은 반드시 0이어야 함
IMAGE_FILE_LOCAL_SYMS_STRIPED	0x0008	로컬 심볼에 대한 COFF 심볼 테이블은 더 이상 사용하지 않으므로 이 값은 반드시 0이어야 함
IMAGE_FILE_AGGRESIVE_ES_TRIM	0x0010	해당 값은 윈도우 2000과 그 이후 버전에서는 더 이상 사용되지 않으므로 반드시 0이어야 함
IMAGE_FILE_LARGE_ADDRESS_AWARE	0x0020	애플리케이션은 2GB보다 큰 주소를 다룰 수 있음
?????	0x0040	예약 영역
IMAGE_FILE_BYTES_REVERSED_LO	0x0080	Little Endian, 해당 필드는 더 이상 사용하지 않으므로 반드시 0이어야 함
IMAGE_FILE_32BIT_MACHINE	0x0100	머신이 32bit Processor를 사용
IMAGE_FILE_DEBUG_STRIPED	0x0200	해당 실행 파일에는 디버깅 정보가 없음
IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP	0x0400	해당 실행 파일이 이동형 저장 장치에 있다면 실행 파일 전체를 페이지 파일로 복사함
IMAGE_FILE_NET_RUN_FROM_SWAP	0x0800	해당 실행 파일이 네트워크로 연결된 저장 장치에 있다면 실행 파일 전체를 페이지 파일로 복사
IMAGE_FILE_SYSTEM	0x1000	이 실행 파일은 시스템 파일
IMAGE_FILE_DLL	0x2000	해당 실행 파일은 DLL 파일, 사실상 실행 파일로 취급
IMAGE_FILE_SYSTEM_ONLY	0x4000	해당 파일은 오직 Single Processor가 있는 머신에서만 실행되어야 함
IMAGE_FILE_BYTES_REVERSED_HI	0x8000	Big Endian, 해당 필드는 더 이상 사용되지 않으므로 0값을 가져야 함

 

PE Header 영역의 세 번째 영역인 PE File Optional Header 영역을 알아보기 전에 알아두어야 할 개념은 바로 RVA이다.

 

PE File Optional Header 영역에서 자주 언급되기 때문에 미리 알아두고 이해하는 것이 훨씬 효과적이다.

 

 

2-3. RVA (Relative Virtual Address)

• 실행 파일이 프로세스를 만들고 실행 파일의 코드와 데이터가 가상 메모리에 맵핑이 되면 메모리에 맵핑되는 지점의 시작 주소가 베이스 주소가 됨

• RVA는 가상 메모리 상의 베이스 주소를 기준으로 로드된 실행 파일의 상대적 위치를 의미

 

가상 메모리에서의 가상 주소는 아래와 같은 형식으로 구할 수 있다.

 

 

가상 주소 = 베이스 주소(Base Address) + RVA

 

 

RVA는 가상 메모리에 맵핑된 이후의 오프셋 값이므로 PE 파일상의 오프셋과 같다고 생각하면 안된다.

 

물론 PE 파일은 가상 메모리에 그대로 맵핑이 되어 순서가 맵핑 되기 전과 같지만, 가상 메모리에 맵핑이 되면 섹션 사이에 패딩이 생겨 오프셋 값이 달라진다.

 

 

2-4. PE File Optional Header

• 실행 파일의 실행 정보가 담긴 부분

• 필수적인 부분이므로, PE File Header보다 더 중요

• Option이라는 이름이 붙은 이유는 오브젝트가 이 영역을 선택적으로 가질 수 있기 때문

• 정작 오브젝트에서는 별다른 기능을 발휘하지 않음

 

PE File Optional Header 부분은 IMAGE_OPTIONAL_HEADER 구조체로 되어 있다.

 

크기가 유동적이고 앞서 보았던 IMAGE_NT_HEADER의 SizeOfOptionalHeader 구조체 멤버에 의해 크기가 결정되고, PE File Header 바로 뒤에 위치 한다.

 

IMAGE_OPTIONAL_HEADER 구조체는 Standard Fields, NT additional Fields, IMAGE_DATA_DIRECTORY로 구분이 된다.

 

 

Standard Fields

• 파일을 로드하고 실행하는 것에 대한 정보가 들어있음

 

 

1) Magic

• 실행 파일의 상태를 나타내는 부호 없는 정수 값을 가짐

• 이 값이 '0x010B' 라면 일반적인 실행 파일을 뜻하며, '0x0107' 이라면 ROM 이미지, '0x020B'라면 64bit Executable 타입이라는 것을 의미

 

2) MajorLinkerVersion(V1)

• 링커의 상위 버전 넘버를 저장하는 멤버

 

3) MinorLinkerVersion(V2)

• 링커의 하위 버전 넘버를 저장하는 멤버

 

4) SizeOfCode

• 코드 섹션(.text)의 크기 정보를 가지고 있음

• 코드 섹션이 여러 개라면 그것들의 합에 대한 값을 가짐

 

5) SizeOfInitialized Data

• 초기화된 데이터 섹션의 크기를 값으로 가짐

• SizeOfCode 멤버와 마찬가지로 자신이 담당하고 있는 섹션의 수가 여러 개라면 그들의 합에 대한 값을 가짐

 

6) SizeOfUninitialized Data

• 초기화되지 않은 데이터 섹션의 크기를 값으로 가짐

• 섹션이 여러 개일 경우 SizeOfInitialized Data 구조체 멤버와 동일한 성격을 가짐

 

7) AddressOfEntry Point

• 메모리에 맵핑된 상태에서의 실행 코드 주소를 가짐

• 이 주소는 절대적 주소가 아닌 상대적 주소(RVA)

• 보통 .text 섹션 내의 특정 주소를 가리킴

• 실행 파일에서의 이 주소는 실행 코드의 시작 주소

• 디바이스 드라이버에서는 초기화 함수의 주소가 됨

• 반면 DLL 파일은 이 값이 선택적이며, 이 값이 없다면 반드시 0으로 되어야 함

 

8) BaseOfCode

• 실행 파일이 메모리에 맵핑된 상태에서의 코드 섹션(.text) 주소를 가짐

• 이 값은 상대적 주소인 RVA 값

 

9) BaseOfData

• 실행 파일이 메모리에 맵핑된 상태에서의 데이터 섹션(.data) 주소를 가짐

• 이 값은 상대적 주소인 RVA 값

 

 

NT Additional Fields

• 해당 영역은 Standard Fields 바로 다음부터 시작되며, 많은 구조체 멤버로 이루어짐

• 이 영역에서 제공되는 정보는 윈도우 링커와 로더가 사용하는 정보

 

다음 그림은 해당 영역의 오프셋 구조이다.

 

 

 

1) ImageBase

• 가상 메모리에 로드된 실행 파일의 주소를 가짐

• 이 값은 반드시 64KB이어야 함

• ImageBase 구조체 멤버 값과 Standard Fields의 BaseOfCode 값을 더하면 .text 섹션의 가상 메모리 주소

 

2) SectionAlignment

• 가상 주소에 맵핑될 때 섹션이 할당 받을 가상 주소의 기준 값을 가짐

• 섹션은 메모리에 맵핑될 때 섹션별로 맵핑되기 때문

• 섹션의 시작 주소는 항상 메모리 페이지의 배수여야 하므로 이 값은 FileAlignment와 같거나 커야 함

• 기본 값은 페이지의 크기와 같음

 

3) FileAlignment

• PE 파일 내에서 섹션들이 시작하는 주소의 기준 값

• 따라서 PE 파일 내에서의 섹션이 시작하는 주소는 항상 이 값의 배수가 됨

• 이 값은 2에서 512 사이에 있는 2의 제곱이거나 64KB가 되지만 기본 값은 512

• SectionAlignment의 값이 메모리 페이지 크기보다 작다면 FileAlignment의 값과 동일해야 함

 

4) MajorOperatingSystemVersion(mOS1)

• 실행 파일을 실행하는데 필요한 OS의 최소 상위 버전 값을 가짐

 

5) MinorOperationSystemVersion(mOS2)

• 실행 파일을 실행하는데 필요한 OS의 최소 하위 버전 값을 가짐

 

6) MajorImageVersion(mIV1)

• 실행 파일의 상위 버전의 값을 가짐

 

7) MinorImageVersion(mIV2)

• 실행 파일의 하위 버전의 값을 가짐

 

8) MajorSubsystem(mSV1)

• 실행 파일을 실행하는데 필요한 서브 시스템의 상위 버전의 값을 가짐

 

9) MinorSubsystem(mSV2)

• 실행 파일을 실행하는데 필요한 서브 시스템의 하위 버전의 값을 가짐

 

10) Win32Version

• 이 멤버는 VC++6.0 SDK까지는 예약 영역이었음

• 7.0부터 지금의 이름으로 바뀌었으며, 하지만 여전히 사용하지 않아 보통 0으로 되어 있음

 

11) SizeOfImage

• 메모리에 로드 되었을 때 실행 파일의 크기 값을 가짐

• 이 값은 헤더를 포함했을 때의 크기이며, 반드시 SectionAlignment의 배수여야 함

• 이 값을 기준으로 해서 가상 메모리에서 실행 파일을 맵핑할 공간을 예약

 

12) SizeOfHeader

• DOS Stub, PE 헤더, 섹션 헤더의 합 값을 가짐

• 이 값은 무조건 FileAlignment의 배수여야 함

 

13) Checksum

• 실행 파일의 체크섬 값을 가짐

• 체크섬 알고리즘은 IMAGEHELP, DLL 파일에 있으며 이 값은 모든 드라이버와 부팅 시 로드 된 DLL 파일, 중요한 윈도우 프로세스가 로드한 DLL 파일을 검증할 때 사용

 

14) Subsystem

• 실행 파일을 실행하는데 필요한 서브 시스템의 값을 가짐

 

다음 표는 Subsystem 값 목록표이다.

 

 

[표 3] Subsystem 값 목록표

상수	값	목록표
IMAGE_SUBSYSTEM_UNKNOWN	0	알 수 없는 SubSystem
IMAGE_SUBSYSTEM_NATIVE	1	디바이스 드라이버와 Native Windows Process
IMAGE_SUBSYSTEM_WINDOWS_GUI	2	Windows GUI SubSystem
IMAGE_SUBSYSTEM_WINDOWS_GUI	3	Windows CUI SubSystem
IMAGE_SUBSYSTEM_POSIX_CUI	7	Posix CUI Subsystem
IMAGE_SUBSYSTEM_WINDOWS_CE_GUI	9	Windows CE
IMAGE_SUBSYSTEM_EFI_APPLICATION	10	EFI (Extensible Firmware Interface) Application
IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER	11	Boot Service가 있는 EFI 드라이버
IMAGE_SUBSYSTEM_RUNTIME_DRIVER	12	Runtime Service가 있는 EFI 드라이버
IMAGE_SUBSYSTEM_EFI_ROM	13	EFI ROM Image
IMAGE_SUBSYSTEM_XBOX	14	XBOX

 

15) DLLchr(DllCharacteristics)

• PE 파일이 DLL 파일인 경우 파일의 속성정보를 의미

 

16) SizeOfStackReserve

• 예약할 스택의 크기 값을 가짐

 

17) SizeOfStackCommit

• 커밋할 스택의 크기 값을 가짐

 

18) SizeOfHeapReserve

• 예약할 힙의 크기 값을 가짐

19) SizeOfHeapCommit

• 커밋할 힙의 크기 값을 가짐

 

20) LoaderFlags

• 예약된 영역으로 0으로 채워져 있음

 

21) NumberOfRvaAndSize

• Optional Header의 나머지 부분에 있는 데이터 디렉토리 엔트리의 숫자 값을 가짐

 

 

IMAGE_DATA_DIRECTORY

• WinNT.h를 보면 IMAGE_OPTIONAL_HEADER 안에 있지만, 사실은 NT Additional Fields 하부 구조체

 

구조체 선언은 다음 그림과 같다.

 

 

WinNT.h에 명시되어 있는 것을 보면 IMAGE_DATA_DIRECTORY의 엔트리 개수는 16개로 정의되어 있다.

 

 

 

엔트리는 [그림 16]과 같이 정의되고, 마지막은 0으로 예약되어 있기 때문에 16개가 되는 것이다.

 

 

각 부분은 주소와 크기로만 나누어진다.

---

(3) Section

3-1) Section Header

• 섹션 헤더 영역에는 각 세션의 헤더들이 있으며, 섹션들은 이 헤더에 메타 데이터와 메모리에 로드될 때 필요한 정보를 저장

 

섹션 헤더의 구조체 형태는 다음 그림과 같다.

 

 

위 [그림 18]에는 보이지 않지만 IMAGE_SIZEOF_SHORT_NAME은 8바이트로 정의되어 있으며, 이름 길이가 8바이트를 넘어가게 되면 8바이트 이후는 잘리며, 8바이트 보다 짧을 경우 남는 공간은 NULL로 채워진다.

 

 

다음 그림은 .text 섹션의 헤더 영역 오프셋 구조이다.

 

 

1) Name

• 섹션의 이름 부분

• 8바이트 내에서 사용자가 임의로 수정 가능 

 

2) VirtualSize

• 메모리에 로드되는 섹션의 전체 크기

• 이 필드는 실행 파일에서만 존재하고 오브젝트 파일에서는 0으로 설정되어 있음

• SizeOfRawData보다 크다면 섹션의 나머지 부분은 0으로 채워짐

 

3) VirtalAddress

• 메모리에 로드 되었을 때의 RVA 값을 가짐

• 오브젝트 파일의 경우 0으로 설정 됨

 

4) SizeOfRawData

• 실행 파일의 경우 디스크 상에서 초기화된 데이터의 크기를 말함

• Optional Header의 FileAlignment 값의 배수이어야 함

• VirtualSize보다 작다면 섹션 나머지 부분은 0으로 채워짐

• 오브젝트 파일의 경우 0으로 설정 됨

 

5) PointerToRawData(PotToRawData)

• PE 파일 내에서의 섹션 위치의 오프셋을 값으로 가짐

• 실행 파일의 경우 이 값은 무조건 FileAlignment의 배수여야 함

 

6) PointerToRelocations(PotToRelocations)

• 섹션 재배치에 대한 시작 지점 오프셋을 값으로 가짐

• 이 값은 보통 오브젝트 파일에 사용

• 실행 파일의 경우 0으로 설정 됨

 

7) PointerToLineNumbers(PotToLineNumbers)

• 해당 섹션에 대한 Line-Number 엔트리의 시작 지점 주소 값을 가짐

• Line-Number 엔트리는 COFF 포맷으로 지금은 사용하지 않기 때문에 0으로 설정 되어 있음

 

8) NumberOfRelocations(Nolo)

• 해당 섹션의 재배치 엔트리 숫자를 값으로 가짐

• 실행 파일의 경우 항상 0으로 설정되어 있음

 

9) NumberOfLineNumber(Nolo)

• 해당 섹션에 대한 Line-Number 엔트리의 숫자를 가짐

 

10) Characteristics

• 해당 섹션의 속성 정보를 표시하는 값을 가짐

 

 

Characteristics에 대한 속성 목록은 다음 표와 같다.

 

[표 4] 속성 목록표

종류	값	설명
IMAGE_SCN_CNT_CODE	0x00000020	실행 코드를 가지고 있음
IMAGE_SCN_CNT_INITIALIZED_DATA	0x00000040	초기화된 데이터를 가지고 있음
IMAGE_SCN_CNT_UNINITIALIZED_DATA	0x00000080	초기화되지 않은 데이터를 가지고 있음
IMAGE_SCN_MEM_NOT_CACHED	0x04000000	캐시될 수 없음
IMAGE_SCN_MEM_NOT_PAGED	0x08000000	페이징되지 않음
IMAGE_SCN_MEM_SHARED	0x10000000	메모리에서 공유될 수 없음
IMAGE_SCN_MEM_EXECUTE	0x20000000	코드로서 실행될 수 없음
IMAGE_SCN_MEM_READ	0x40000000	읽기가 가능
IMAGE_SCN_MEM_WRITE	0x80000000	쓰기가 가능

 

더 많은 속성들이 있지만 중요한 것만 목록화 한 내용이다.

 

더 많은 속성들은 WinNT.h 파일을 참고하면 확인 가능하다.

 

만약 섹션 이름이 임의로 바뀌어 어떠한 섹션인지 파악이 되지 않는다면 섹션 속성 정보를 보는 것도 하나의 방법이다.

 

섹션 속성 정보들은 각 섹션마다 기본적으로 정의되어 있어 섹션 속성 정보만 봐도 어떠한 섹션인지 파악 가능하다.

 

 

앞에서 알아본 PE 구조들은 실행 파일들의 정보나 메모리에 로드될 때의 정보 등이었다.

 

이제 알아볼 섹션은 실행 파일의 동작에 관한 정보들이다.

 

섹션에는 여러 가지 섹션이 있는데, 대부분 .text, .data, .rdata, .rsrc, .edata, .idata, .reloc 섹션이 많이 사용된다.

 

 

분석하고자 하는 파일의 섹션 정보는 PE File Header를 보면 NumberOfSections에 색션 개수가 나타나 있으며, 각 섹션의 위치 정보 등은 Section Header 영역을 보면 확인할 수 있다.

 

 

 

 

3-2. .text 섹션

• 실행 파일의 소스코드가 들어있는 섹션

• 초기화되거나 초기화되지 않은 변수, import와 export 테이블 정보를 제외한 나머지 소스코드들이 저장됨

 

해당 섹션의 기본 속성 정보는 다음과 같다.

• IMAGE_SCN_CNT_CODE

• IMAGE_SCN_MEM_EXCUTE

• IMAGE_SCN_MEM_READ

 

섹션의 위치와 크기는 섹션 헤더(PointerToRawData, SizeOfRawData)를 참고하면 알 수 있으며 .text 섹션 헤더에서의 PE 파일 내에서의 .text 섹션 위치와 크기를 확인할 수 있다.

 

 

위 [그림 22]의 빨간색 박스를 보면 PE 파일 내에서의 주소를 확인할 수 있다.

 

.text 섹션의 마지막 오프셋은 주소와 크기를 더하게 되면 결과 값이 나오게 된다.

 

.text 섹션의 마지막 오프셋으로 이동한 다음, 섹션의 모습을 보면 어느 정도 데이터가 있다가 나머지는 0으로 채워져 있는 것을 확인할 수 있다.

 

이러한 이유는 SizeOfRawData의 경우 FileAlignment(IMAGE_OPTIONAL_HEADER)의 배수가 되어야 하므로 실제 데이터의 크기를 가지고 있는 VirtualSize 값을 FileAlignment의 값의 배수로 올림하여 크기가 늘어나 채울 데이터가 없어 0으로 채운 것이다.

 

실제 메모리에 .text 섹션이 올라갈 때는 0을 제외하고 올라가게 된다.

 

 

이러한 방법으로 모든 섹션의 영역을 찾을 수 있다.

 

이 방법을 계속 섹션마다 사용하여 영역을 찾는 것을 보여줄 수는 없기 때문에 이후에 나오는 섹션들은 특징과 속성 정보 등만 소개한다.

 

 

3-3. .data 섹션

• 읽기/쓰기가 가능한 일반적인 데이터를 위한 섹션

• 정적 변수와 전역 변수가 저장

 

해당 섹션의 기본 속성 정보는 다음과 같다.

• IMAGE_SCN_CNT_INITIALIZED_DATA

• IMAGE_SCN_MEM_READ

• IMAGE_SCN_MEM_WRITE

 

 

3-4. .rdata 섹션

• 읽기 전용 섹션으로 상수와 배열로 직접 정의된 문자열과 런타임 라이브러리에서 사용하는 에러 메시지 등이 저장

 

해당 섹션의 기본 속성 정보는 다음과 같다.

• IMAGE_SCN_CNT_INITIALIZED_DATA

• IMAGE_SCN_MEM_READ

 

 

3-5. .idata, .edata 섹션

• .idata 섹션은 import table이 들어 있으며, .edata 섹션은 export table이 의미

• 이 섹션들은 실행하는데 꼭 필요한 섹션은 아님

 

.idata 섹션의 기본 속성 정보는 다음과 같다.

• IMAGE_SCN_CNT_INITIALIZED_DATA

• IMAGE_SCN_MEM_READ

• IMAGE_SCN_MEM_WRITE

 

.edata 섹션의 기본 속성 정보는 다음과 같다.

• IMAGE_SCN_CNT_INITIALIZED_DATA

• IMAGE_MEM_READ

 

 

3-6. .reloc 섹션

• PE 파일이 메모리 상에 로드될 때 재배치에 관해 참조하는 정보가 들어있는 섹션

• 실행 파일의 경우 이 섹션은 필요하지 않을 수 있지만, DLL 파일의 경우 메모리에 로드될 때 재배치를 염두하고 있기 때문에 이 섹션이 없으면 실행되지 않을 수도 있음

 

.reloc 섹션의 기본 속성 정보는 다음과 같다.

• IMAGE_SCN_MEM_READ

• IMAGE_SCN_CNT_INITIALIZED_DATA

• IMAGE_SCN_TYPE_NOLOAD

 

이렇게 해서 PE 포맷을 모두 알아보았다.

 

조금만 더 깊숙이 들어가면 그 구조는 매우 복잡하며, 알아야 할 것들이 너무 많기 때문에 포렌식 업무를 수행함에 있어 알아두어야 할 것들만 소개하였다.

 

앞서 말했듯이 PE 포맷은 파일 카빙, 파일 시그니처 탐지에 유용하게 사용될 수 있어 이렇게 소개하였다.

 

포렌식 관점에서 PE 구조를 보면 파일 생성 시간 값을 저장하는 PE File Header 영역에 TimeDataStamp 구조체 멤버가 중요하고 또 파일의 종류를 결정하는 PE File Header 영역에 Characteristics 구조체 멤버가 중요하다.

---

# Reference

 

http://www.yes24.com/Product/Goods/8511539

[Digital Forensic] Registry 분석

 

---

(1) 레지스트리란?

• 윈도우 포렌식에서 메모리 분석과 함께 제일 중요하게 여겨지고 있는 분석

• 윈도우에서의 모든 정보가 저장되어 있는 데이터베이스

• 윈도우 3.1부터 시작되었으며, 시작은 .ini 파일처럼 단순 구조로 시작

• 모든 정보가 저장되어 있는 만큼 포렌식 과정에서 얻고자 하는 정보도 들어 있음

• 오늘 날의 레지스트리는 복잡하고 양이 매우 방대

 

1-1. 레지스트리 용어

 

 

• 루트키 : 레지스트리 최상위 키

• 서브키 : 루트키 하위에 있는 키, 메모리에만 존재

• 키 : 레지스트리에서 폴더처럼 데이터를 가지고 있는 것

 

 

• value : 폴더에 속한 파일처럼 키에 속한 값의 이름

• data : value가 가지고 있는 값

• Hive : 서브키 아래의 트리 구조를 의미하며 서브키와 달리 하드디스크 상에 파일로 존재

 

많이 쓰이는 루트키의 용어는 다음과 같다.

 

• 1) HKCR : HKEY_CLASSES_ROOT의 약자

• 2) HKCU : HKEY_CURRENT_USER의 약자

• 3) HKLM : HKEY_LOCAL_MACHINE의 약자

• 4) HKU : HKEY_USERS의 약자

• 5) HKCC : HKEY_CURRENT_CONFIG의 약자

---

1-2. 루트키

• 총 5개의 루트키로 이루어짐

• 루트키들 중 파일로 존재하는 HKLM, HKU는 Master key이며 나머지 루트키들은 Derived key

• Master key는 Derived key의 원본을 말하며, Windows의 Configuration Manager가 각 하이브 파일을 읽어 구성하는 값들

• Derived key는 Master key의 심볼릭 링크 값들을 말하며, 해당 값들은 파일로 존재하지 않으며 메모리에만 존재하기 때문에 시스템 전원(On/Off) 상태에 따라 유지나 재구성 됨

 

 

• HKEY_CLASSES_ROOT : 파일 확장자와 확장자가 사용할 프로그램의 맵핑 정보가 정의

• HKEY_CURRENT_USER : 현재 시스템에 로그온하고 있는 사용자가 설정한 시스템 환경 정보(네트워크, 응용 프로그램 등의 정보)가 정의

• HKEY_LOCAL_MACHINE : 시스템의 하드웨어 구성에 필요한 초기화 파일과 소프트웨어 정보, 드라이버 정보 등이 정의

• HKEY_USER : 시스템에 있는 모든 계정과 그룹에 대한 시스템 환경 정보가 정의

• HKEY_CURRENT_CONFIG : 시스템이 부팅 시 사용하는 하드웨어 프로파일 정보(글꼴, 프린터 정보 등의 부가적 정보)가 정의

 

HKLM과 HKU는 독자적인 정보를 가지고 있는 반면에 HKCU, HKCR, HKCC는 독자적 정보가 아닌 HKLM과 HKU의 심볼릭 링크 정보로 이루어져 있다.

 

즉 HKLM, HKU 루트키는 Master Key에 해당하며, 나머지 HKCU, HKCR, HKCC는 Derived Key에 해당

 

 

1) HKEY_CLASSES_ROOT

• 해당 루트키는 하위 서브키로 HKLM\SOFTWARE\Classes와 HKU\<SID>\Classes의 심볼릭 링크 정보를 가짐 (.btapp)

• .btapp 서브키는 HKCR에는 존재하지만, HKLM의 서브키에는 존재하지 않음

• HKCR은 자신만의 서브키가 없고 HKLM과 HKU의 Classes 서브키 심볼릭 정보를 가져와 자신의 서브키로 만듦

• HKCR은 많은 양의 하위 키들을 가지고 있으며, 대부분의 서브키들은 HKLM의 심볼릭 링크 서브키를 뜻함

• 나머지 서브키들은 HKU에서 가져옴

 

HKCR은 파일과 프로그램간의 맵핑 정보를 담당한다고 하였다.

 

HKCR 서브키들 중 .mp3라는 서브키의 데이터를 보면 다음 그림과 같다.

 

 

각 value와 data를 .mp3를 실행하는 프로그램의 정보가 들어 있는데 (기본값) 은 value가 정해지지 않았을 때 default로 정해지는 value이며, 키당 하나만 생성이 가능하다.

 

(기본값)에서 가리키고 있는 곳으로 따라가면 프로그램의 전체 경로와 명령어 옵션을 알 수 있다.

 

 

기본값이 가리키는 키의 하위 키인 Shell키의 Open\Command 키로 가면 [그림 5]와 같이 프로그램을 실행시키는 명령 행과 옵션을 볼 수 있다.

 

 

2) HKEY_CURRENT_USER

• 현재 로그온한 사용자의 정보를 서브키로 가짐

• 이 서브키들은 HKU 루트키에서 가져온 것들 

 

[그림 6]을 보면 HKU 서브키들 중 S1002 계정의 서브키들이 HKCU의 서브키와 동일한 것을 볼 수 있다.

 

즉 현재 S1002 계정이 로컬에 로그온되어 있다는 뜻이 된다.

 

각 서브키들이 어떠한 의미를 뜻하는지는 다음과 같다.

 

 

3) HKCU 서브키

• AppEvent : 이벤트 정보

• Console : 명령 프롬프트의 비쥬얼 설정 정보

• Control Panel : 화면 보호기, 키보드/마우스 등의 환경설정 정보

• Environment : 환경 변수 정보

• EUDC : 최종 사용자가 정의한 문자 정보

• Identifies : 윈도우 메일 계정 정보

• Keyboard Layout : 키보드 레이아웃 설정 정보

• Network : 네트워크 드라이브 맵핑 정보

• Printers : 프린터 연결 정보

• Sessions information : 현 세션의 정보

• Software : 현재 로그온한 사용자의 소프트웨어 목록

• UNICODE Program groups(Win XP) : 현재 로그온한 사용자가 지정한 '시작' 메뉴 환경 설정 정보

• system(Win 7) : HKLM/SYSTEM 서브키의 일부

• Volatile Environments : 휘발성 환경 변수 정보

 

 

4) HKEY_USERS

• 시스템의 모든 계정 정보를 담고 있는 루트키

• 루트키와 각 서브키의 계정 프로파일이 있다는 것만 제외하면 HKU의 서브키들은 HKCU 서브키와 동일

• 계정 프로파일은 각 키들의 (기본값)에 링크되어 있음

 

다음은 HKU를 구성하는 하이브들의 목록과 하이브들의 저장 경로이다.

 

HKU\<로컬 사용자의 계정 SID>

• Win XP : Documents and Settings\LocalService\NTUSER.DAT

• Win Vista/7 : %System Root% \ServiceProfiles\LocalService\NTUSER.DAT

HKU\<네트워크 사용자 계정 SID>

• Win XP : Documents and Settings\NetworkService\NTUSER.DAT

• Win Vista/7 : %System Root% \ServiceProfiles\NetworkService\NTUSER.DAT

HKU\<사용자 SID>

• Win XP : Documents and Settings\<user name>\NTUSER.DAT

• Win Vista/7 : Users\%UserName%\NTUSER.DAT

HKU\<사용자 SID>_Classes

• Win XP : Documents and Settings\<user name>\LocalSettings\ApplicationData\Microsoft\Windows\UsrClass.dat

• Win Vista/7 : Users\%UserName%\AppData\Local\Microsoft\Windows\UsrClass.dat

HKU\.DEFAULT

• %System Root% \System32\Config\Default

 

%System Root%는 Windows의 루트 위치를 말하며 Windows 운영체제가 설치된 드라이브의 Windows 폴더를 의미한다.

 

 

5) HKEY_CURRENT_CONFIG

• 시스템이 시작할 때 사용되는 하드웨어 프로파일을 저장

• 별도의 하이브를 갖고 있지 않음

• 프로그램이 현재 활성화된 하드웨어를 알아보기 위해 이 루트키 참조

 

 

6) HKEY_LOCAL_MACHINE

• 자체 하이브를 갖고 있으며, 시스템의 하드웨어, 소프트웨어 드라이버의 환경설정 정보를 가짐

• HKLM 하이브 중 일부는 관리자 계정으로도 접근하지 못하는 하이브가 있으며, 시스템 계정으로 접근 가능

 

HKLM 하위 하이브 목록과 위치는 다음과 같다.

 

• HKLM\BCD00000000(Win Vista/7) : <Boot Partition> \Boot\BCD

• HKLM\COMPONENTS(Win Vista/7) : %SystemRoot%\System32\Config\COMPONENTS

• HKLM\HARDWARE : 메모리

• HKLM\SAM : %SystemRoot% \System32\Config\SAM

• HKLM\SECURITY : %SystemRoot% \System32\Config\SECURITY

• HKLM\SOFTWARE : %SystemRoot% \System32\Config\SOFTWARE

• HKLM\SYSTEM : %SystemRoot% \System32\Config\SYSTEM

• HKLM\SYSTEM\Clone : 메모리

 

위에서 알 수 있듯이 하이브는 모두 확장자가 없으며, HARDWARE와 Clone 하이브는 메모리에 존재한다.

 

그러므로 Live Response 과정에 이러한 휘발성 하이브에 대한 덤프 수집 부분도 추가하는 것이 좋다.

 

 

이제부터는 각 하이브에 대해 알아보도록 하자.

 

1) HKLM\HARDWARE

• 해당 하이브는 휘발성 정보로 메모리에 존재

• 모니터 포트 등 부팅 시 관련된 하드웨어 장치와 드라이버 맵핑 정보들을 저장

• 중요한 것은, 하이브 파일이 존재하지는 않지만 Derived Key가 아님

 

2) HKLM\SAM

• 해당 하이브는 사용자의 로컬 계정 정보(사용자 패스워드, 사용자 프로필 등)와 그룹 정보를 갖고 있음 (리눅스 /etc/passwd와 비슷)

• 만약 조사하고자 하는 시스템이 도메인 컨트롤러라면 AD(Active Directory)에 도메인 계정과 그룹 정보를 가짐

• 이 하이브는 일반 관리자 계정으로도 접근이 불가능하며, 시스템 계정으로만 접근 가능

 

시스템 계정 권한을 얻는 방법에는 여러 가지가 있으며 대체로 조사 과정에서는 통합 포렌식 도구들을 통해 얻는다.

 

대표적인 도구로는 psExec를 이용하여 일시적으로 얻는 방법이 있다.

 

 

3) HKLM\SECURITY

• 이 하이브는 시스템 범위의 보안 정책과 사용자 권한 할당 정보, 현재 시스템의 패스워드 또는 마지막 로그온 사용자의 패스워드 등의 정보를 가짐

• 이 하이브 또한 시스템 계정으로만 접근이 가능하며 위 SAM 접근했던 방식과 동일하게 접근 가능

• 시스템 계정이 아닌 경우에 해당 하이브의 하위에는 아무것도 없는 것처럼 보이지만, 시스템 계정 권한으로 접근하면 많은 서브키들을 볼 수 있음

 

4) HKLM\SYSTEM

• 해당 하이브는 시스템이 부팅될 때의 환경 설정 정보를 가짐

• 이런 정보들은 시스템이 정상적 부팅되었을 때 복사되며, 시스템이 비정상적으로 종료되었을 때 복사해 둔 정보를 바탕으로 부팅할 수 있는 옵션을 사용자에게 제공

• 이런 복사본은 일반적으로 '마지막으로 성공한 구성'이라고 부름

• 해당 하이브에서 중요한 것은 바로 CurrentControlSet 키

 

CurrentControlSer 키는 ControlSet001이나 또는 ControlSet002 둘 중 어느 하나의 대한 링크이다.

 

ControlSet은 시스템 환경 설정 정보를 담고 있는 키로 보통 2개 이상의 키가 존재한다.

 

CurrentControlSet은 부팅에서 사용된 ControlSet 키의 링크이고, 같은 레벨에 있는 Select 키에서 확인 가능하다.

 

예를 들어, Current value의 값이 1로 되어 있으면, 이것의 의미는 ControlSet001로 부팅되었다는 의미이다.

---

1-3. HKCU 서브키 타입

 

 

레지스트리를 보면 [그림 7]과 같은 데이터 타입들이 존재한다.

 

레지스트리에는 여러 가지 데이터 타입들이 존재하는데 데이터 타입들은 다음 표와 같다.

 

 

[표 1] 데이터 타입 목록

종류	값	설명
REG_NONE	0x00	타입 없음
REG_SZ	0x01	고정 길이의 유니코드 문자열
REG_EXPAND_SZ	0x02	Embeded 환경 변수들이 가질 수 있는 가변 길이 유니코드 문자열
REG_BINARY	0x03	Binary Data
REG_DWORD	0x04	32bit Integer
REG_DWORD_LITTLE_ENDIAN	0x04	32bit Integer, Little Endian 방식
REG_DWORD_BIG_ENDIAN	0x05	32bit Integer, Big Endian 방식
REG_LINK	0x06	Unicode Symbolic Link
REG_MULTI_SZ	0x07	Unicode 문자열의 배열, Null 문자가 문자열의 끝을 의미
REG_RESOURCE_LIST	0x08	Hardware Resource 설명
REG_FULL_RESOURCE_DESCRIPTOR	0x09	Hardware Resource 설명
REG_RESOURCE_REQUIPMENTS_LIST	0x0A	필요한 Resource 목록
REG_QWORD	0x0B	64bit Integer
REG_QWORD_LITTLE_ENDIAN	0x0C	64bit Integer, Little Endian 방식

---

1-4. ROT 방식의 서브키

• HKCU\software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist 아래에 있는 서브키들은 value를 ROT-13 방식으로 저장

• 레지스트리에서 해당 키의 서브키들만 이러한 방식 사용

 

 

ROT-13은 현대 암호들과 비교해보면 암호라고 할 수 없지만 이러한 방법이 있다는 것을 모른다면 UserAssist 서브키들의 값을 보았을 때 이 값이 무엇을 파악하는데 어느 정도의 시간이 소요될 것이다.

---

1-5. 하이브 구조

• 하이브의 구조를 파악함으로써 비할당 영역이나, 메모리 등에서 하이브를 추출(카빙)할 수 있는 방법을 구상할 수 있음

• 해당 하이브가 어떠한 이름을 갖고 있는지, 어떠한 데이터를 갖고 있는지 파악 가능

 

하이브의 파일 구조 베이스 블록, 하이브 빈, 셀로 이루어져 있으며, 다음 그림과 같다.

 

 

블록

• 하이브는 파일 시스템이 클러스터라 불리는 논리적 저장 단위를 사용하는 블록이라는 논리적 단위 사용하는데 그 단위를 의미

• 블록 크기는 4KB이며, NTFS에서의 일반적인 클러스터 크기와 같음

• 파일 시스템의 경우 클러스터가 4KB일 경우 모든 파일의 물리적 크기가 4KB씩 증가하고, 클러스터가 1비트면 파일의 물리적 크기가 1비트씩 증가

• 하지만, 하이브는 파일의 크기 증가 기준이 논리적 바이트이기 때문에 언제나 4바이트씩 증가

 

베이스 블록 (Hive Header)

• 하이브의 첫 번째 블록이며, 하이브의 여러 정보들이 들어 있음

• 하이브의 시작이 되는 부분이기 때문에 하이브 헤더 역할을 함

• 아직까지 완벽히 연구된 영역이 아니기 때문에 각 오프셋이 뭘 의미하는지 알 수 없음

 

• Signature : 베이스 블록의 시그니처는 'regf"

• Seqn Number 1 : 하이브에 문제가 없다면 다음에 나올 Seqn Number2와 동일하여야 함

• Seqn Number 2 : 하이브에 문제가 없다면 앞에 나온 Seqn Number1과 동일하여야 함

• TimeStamp : Windows 64bit 형식의 시간 값

• Major Version : 상위 버전의 번호

• Minor Version : 하위 버전의 번호

• Root Cell : 첫 번째 key cell의 포인터 값으로서 Offset 단위

• Last Hive Bin : 마지막 하이브 빈의 포인터 값으로 Offset 단위

• Only Value 1 : 무조건 값이 1인 Offset

• CheckSum : 무결성 검증을 위한 CheckSum 값

 

하이브 빈

• 레지스트리는 4KB를 기준으로 증가하는 동시에 내부에서 4KB 크기의 하이브 빈이라는 논리적 단위 생성

• 블록과 하이브 빈의 크기는 4KB로 동일하기 때문에 블록 하나가 하이브 빈 하나를 구성할 수도 있고 여러 블록이 하이브 빈 하나를 구성할 수도 있음

• 하이브의 크기를 결정짓는 블록과 다르게 하이브의 논리적 구조를 결정짓는 요소로 작용

 

베이스 블록은 시그니처가 달라 하이브 빈이라고 부르지 않는다.

 

각각의 하이브 빈은 다음 하이브 빈까지의 상대적 거리를 저장하며, 윈도우는 레지스트리를 읽어 들일 때 하이브 빈을 기본 단위로 삼는다.

 

셀이라는 논리적 단위를 사용하게 되면 잦은 호출로 인해 시스템 속도 저하를 일으킬 수 있고 단편화가 발생할 수 있다.

 

이런 이유로 윈도우에서는 빈 하이브 빈이 생기면 인접 하이브 빈과 결합시키고, 마지막 하이브 빈이 비게 되면 하이브를 축소시킨다.

 

• Signature : 하이브 빈의 시그니처는 hbin

• Offset : 첫 번째 하이브로부터의 상대적 거리를 나타내는 값으로 Offset 단위

• Size : 하이브 빈의 크기로 4096 배수

• TimeStamp : Windows 64bit 형식의 시간 값

 

하이브 빈 헤더 이후로는 각 셀들이 위치하게 된다.

 

 

셀

• 하이브 빈보다 더 작은 논리적 저장 단위

• 실제 레지스트리 데이터를 저장할 때 사용되는 단위

• 셀 헤더에는 셀의 전체 길이가 저장되며, 이 값은 무조건 8바이트의 배수

 

셀이 하이브 빈에 위치하고 있는 모습은 다음과 같다.

 

 

셀은 처음 그 구조가 시작될 때 셀의 크기를 나타내는 Cell Length 필드 (0x0~3)부터 시작된다.

 

셀의 크기는 Cell Length 필드까지 포함하여 그 크기를 나타낸다.

 

Cell Length 필드 이후에는 각 셀들의 고유 구조(0x4~)가 시작된다.

 

 

1) Key Cell

• 레지스트리의 키를 가지고 있는 셀

• '키 노드(Key node)'라고도 불림

• 가장 최근에 키를 수정한 시간이 기록되며, 이 셀이 바로 Root cell

• 파일 시스템과 비교하면 해당 셀은 디렉토리 역할을 하는 셀

 

• Hive Bin Header : Hive Bin Header 필드

• Cell Length : 해당 셀의 길이를 나타내며, 해당 필드도 포함

• Signature : 시그니처(nk)를 나타내는 필드

• Flag : 셀의 상태 플래그를 나타냄

• TimeStamp : Windows 64bit 형식의 시간 값을 가짐

• Parent key : 부모 키의 오프셋을 값으로 가짐

• Subkey Count : 서브키의 개수를 나타내며, Subkey Count 1 필드는 비휘발성 성격을 가지며 Subkey Count 2 필드는 휘발성 성격을 가짐

• Subkey-list : Subkey-list의 오프셋을 값으로 가지며, Subkey-list 1 필드는 비휘발성 성격을 가지며 Subkey-list 2 필드는 휘발성 성격을 가짐

• Value-list :  Value-list의 오프셋을 값으로 가짐

• Security key Cell : Security key의 오프셋을 값으로 가짐

• Name Length : 키 이름의 길이를 나타냄

• Class Name Length : 클래스 이름의 길이를 나타냄

• Key name : 키 이름을 나타내며 해당 필드의 길이는 가변적

 

위에서 말한 상태 플래그 목록은 다음과 같다.

• 0x0001 : 휘발성 키

• 0x0002 : 다른 하이브의 마운트 포인트

• 0x0004 : 루트 키

• 0x0008 : 삭제 불가능한 키

• 0x0010 : 링크되어 있는 키

• 0x0020 : 키의 이름을 ASCII 형태로 저장

• 0x0040 : 미리 정의되어 있는 키

• 0x0080 : 알 수 없음

• 0x1000 : 알 수 없음

• 0x4000 : 알 수 없음

 

 

2) Subkey-list cells

• Subkey-list cell은 레지스트리 키의 인덱스 목록을 구성하는 셀

• 다음에 설명할 두 종류의 엘리먼트 셀과의 결합으로 키들의 인덱스를 구성

• Signature : 시그니처를 나타내는 필드이며 'lf(Fast Leaf), lh(Hash Leaf), ri(Index Root), li(Index Leaf)' 중 어느 하나가 시그니처로 저장될 수 있음

• Count : Subkey-list에 있는 엘리먼트들의 개수를 나타냄

• Subkey-list Element : 다수의 Subkey-list 엘리먼트들을 나타내는데 크기는 4Byte 또는 8Byte가 될 수 있음

 

만약 subkey-list cell의 시그니처가 FL(lf), HL(lh)이라면 subkey-list cell 기본 구조에서 Subkey-list Element 필드 부분에 다음과 같은 구조가 위치하게 된다.

 

• KN Cell : key cell의 오프셋을 값으로 가짐

• Hash : 해쉬 값을 가짐

 

또 만약에 Subkey-list ell의 시그니처가 IR(ri), IL(li)이라면 subkey-list cell 기본 구조에서 Subkey-list Element 필드 부분에 다음과 같은 구조가 위치하게 된다.

 

• Offset : 타입이 IR인 경우 해당 필드는 또 다른 Subkey-list Cell의 오프셋 값을 가짐

• 그렇지 않은 경우 Subkey의 Offset 값을 가짐

 

 

3) Value-list Cell

• Value-list cell은 Value cell들의 인덱스 목록을 가짐

 

• Offset : Value Cell 오프셋을 값으로 가지고 있으며, Subkey-list cell의 Subkey-list Element 필드처럼 반복 되어 위치

 

 

4) value cell

• 해당 셀은 value와 data, data의 타입이 들어 있는 셀

• key cell이 파일 시스템에 디렉토리라면 해당 셀은 파일과 비교할 수 있는 셀 (시그니처는 vk)

 

• Cell Length : 해당 셀의 길이를 나타내며, 해당 필드도 길이에 포함

• Signature : 시그니처(vk)를 나타내는 필드

• Value Length : Value의 길이

• Data Length : Data의 길이

• Data : Data 위치의 오프셋을 값으로 가짐

• Value Type : Value의 타입을 결정짓는 필드

• Flag : 해당 필드가 0일 경우 Value는 아스키 코드로 저장되고, 아닐 경우 UTF-16LE 방식으로 저장

• Value : Value가 저장되어 있는 필드이며, 길이는 가변적

 

 

5) Data cell

• Data cell은 레지스트리의 data를 저장하고 있는 cell

• data 크기에 따라 총 3가지의 셀로 구분

• Big Data cell, Big Data Indirect cell, Data cell로 구분

• Big Data cell은 크기가 큰 데이터를 직접 저장하지 않고 해당 데이터가 어디에 있는지 알려주는 Big Data Indirect cell의 위치 값을 가짐

• Big Data Indirect cell은 실제 데이터가 저장되어 있는 Data cell의 위치를 저장

• Data cell은 실제 데이터를 저장하고 있는 cell

 

• Signature : 해당 셀의 시그니처가 저장되는 필드로 시그니처는 db

• Indirect cell : Big Data Indirect cell의 위치를 저장하고 있는 필드, 오프셋 단위로 저장

 

• Data cell : Data cell의 위치를 저장하고 있는 필드

 

• Data : 실제 데이터가 저장되는 필드로, 그 크기는 가변적

 

 

6) Security-descriptor cell

• key cell의 Security-descriptor 정보를 가지며 시그니처는 sk

• 이 셀을 공유하고 있는 모든 키 노드의 개수도 같이 기록

 

• Cell Length : 해당 셀의 길이를 나타내며 해당 필드도 포함

• Signature : 시그니처를 나타내는 필드

• Previous SK cell : 이전 SK 셀의 오프셋을 값으로 가짐

• Next SK Cell : 다음 SK 셀의 오프셋을 값으로 가짐

• Key node Count : 해당 셀을 공유하고 있는 키 노드들의 개수를 값으로 가지고 있는 레퍼런스 카운터

• Size : Security descriptor의 크기를 나타냄

 

Security descriptor의 크기 다음부터는 SID, SID Group 등이 위치하는데 그 길이가 가변적이다.

 

일반적으로 레지스트리의 어떤 키와 value, data를 찾아가는데에 지금까지 설명했던 구조들이 참고된다.

 

앞서 설명한 각 셀들의 구조만 이해하고 있따면 자신이 직접 레지스트리 뷰어 제작이 가능할 수도 있다.

 

 

다음 그림은 각 구조들이 어떻게 레지스트리를 구성하게 되는지 간략하게 그림으로 표현한 것이다.

 

 

간단하게 설명하면, 처음 Hive header에서 Root cell 필드를 참조해 Root cell이 어디에 위치하고 있는지 파악한 후 Root cell로 이동한다.

 

그 후, Root cell, 즉 Root Key cell에서 Subkey-list cell의 위치를 나타내는 필드의 값을 참조해 Subkey-list cell이 위치하고 있는 곳으로 이동한다.

 

Subkey-list cell 위치에서 시그니처를 참조한다.

 

시그니처가 lf(Fast Leaf)라면 엘리먼트 구조는 Key cell의 위치를 가지고 있는 필드와 해시 값을 저장하고 있는 해시 필드로 구성된다.

 

 

Key cell의 위치를 저장하고 있는 필드를 참조해 key cell이 어디 있는지 파악하고 그곳으로 이동한다.

 

레지스트리 키에는 하나의 value와 data만 존재하는 것이 아니기 때문에 바로 Value cell로 이동하는 것이 아니라 Key cell에서 Value-list cell로 이동해야 한다.

 

Key cell 구조를 보면 여러 가지 cell들의 위치를 저장하는 필드가 존재하는데 그 중 Value-list cell 위치를 저장하는 필드가 존재한다.

 

해당 필드를 참조해 Value cell이 위치하고 있는 곳으로 이동하고, Value cell에서 data의 위치를 저장하고 있는 필드를 참조해 data가 있는 위치로 이동해 데이터를 읽는다.

 

만약 데이터가 위치하고 있는 곳에 Big data 종류의 cell이 있다면 또 한 번 이동해야 한다.

 

 

이와 같은 기본 원리로 레지스트리의 데이터를 읽을 수 있으며, 레지스트리의 서브키, 즉 하위키가 많아질수록 하이브의 구조는 더 커지고 복잡해진다.

---

# Reference

 

http://www.yes24.com/Product/Goods/8511539

[DataBase] 데이터베이스 포렌식 개요

 

---

(1) 데이터베이스 포렌식 개요

• 데이터베이스 포렌식은 디지털 포렌식의 한 분야

• 데이터베이스의 구조 및 저장된 데이터, 메타데이터를 수집하여 법적 증거 자료로써의 요구 조건을 충족시키기 위해 분석하는 행위

• 주로 감사 로그를 수집하여 분석 

현재 활용 가능한 데이터베이스 포렌식 툴은 로그 분석기 수준으로 전문적인 도구는 아직까지 존재하지 않는다.

 

또한, 각 DBMS 벤더사별로 데이터베이스 구조가 판이하고, 데이터베이스의 트랜잭션 로그 구조 자체가 기업 보안 정보로 분류되어 구체적인 문서나 매뉴얼을 얻을 수 없다.

 

그리고 방대해지고 있는 어플리케이션 규모도 데이터베이스 포렌식에 있어 걸림돌이 될 수 있다.

 

 

데이터베이스에 저장된 사용자의 개인 정보 유출이 자주 발생하고, 또한 저장된 데이터를 조작하는 사고가 빈번히 발생한다.

 

대부분의 사고는 내부 관계자의 소행이 주를 이르고 있는 만큼 데이터베이스 포렌식의 중요성이 점점 커지고 있다.

 

 

1-1. 데이터베이스 포렌식 이해

• 데이버테이브 정보 침해 사건은 대부분 기업이나 기관 내부의 데이터베이스 관리자나 일반 사용자로 인해 일어남

• 이들은 관리자 권한을 악용해 감사 로그 기록을 우회하여 데이터베이스를 조작, 데이터 조작을 숨기기 위해 로그 기록을 중지함

• 따라서 로그파일 분석을 통해 언제, 어디서, 어떤 사용자에 의해 데이터가 조작되었는지 알아내는 것이 매우 중요

 

가) 왜 데이터베이스 침해사고가 일어나는가?

• 예산 부족으로 인한 관리 인력 및 보안 전문 인력 감축

• 정보 보안에 대한 이해 부족

• 부서 간의 협조 부족

• 데이터베이스 사전 보안 테스트 부족

• 너무 많은 'root' 권한 계정

• 데이터베이스 보안 관리에 대한 기술력 부족

 

나) 다양한 실무 환경에서 사용되는 데이터베이스

• 데이터베이스는 전자결제, 이메일, 기업 정보, 회계 압수 등에서 정보의 메타데이터 역할을 함 

 

 

데이터베이스 포렌식을 이용하여 데이터 선별이 가능한 주요 데이터들을 살펴보면 다음 그림과 같다.

 

---

1-2. 데이터베이스 조사 절차

• 1) DB 조사 기획

• 2) IT / BT 조사

• 3) IT / BT 실사

• 4) DB 증거 수집

• 5) 이송 및 보관

 

가) DB 조사 기획

• 정보 시스템 관련 정보 수집 및 공유

• 영장에 명시할 기업 정보 시스템 소재지 확인

• 데이터베이스 압수 수색 시 소요되는 인력과 시간 판단

• 데이터베이스 압수 방법 구체화

 

나) IT / BT 조사

• IT / BT는 정보 기술과 업무 기술을 뜻함

• 보유 시스템애 대한 조사 진행

• 하드웨어 정보, 네트워크 정보, 운영 중인 소프트웨어 등에 대해 조사 진행

• 운영 중인 데이터베이스에 대한 종류 및 버전과 용량 확인

• 업무 프로세스를 확인하여 동일 시스템이나 유사한 시스템이 있는지를 확인

• 외부 용역 시스템 개발자와 퇴사한 시스템 개발자 및 운영자에 대한 정보 수집

 

다) IT / BT 실사

• 데이터베이스 서버에 대한 메인프레임, 데스크탑 자원 정보 및 잉여 자원 보유 여부 확인

• 데이터베이스에 대한 DBA 계정, 암호 확인, 사용 권한 미 보유자의 데이터베이스 접근 가능 여부 확인

• 데이터베이스와 관련된 트랜잭션 로그 파일의 저장 위치 파악

• 데이터베이스에 대한 조작, 변조, 삭제, 은닉 및 이중 시스템 유무 파악

• 업무담당자의 PC 네트워크 정보와 프로세스 상태를 통해 이중 시스템 및 은닉 데이터베이스 찾기 가능

 

라) DB 증거 수집

• 현장을 통제하여 관련 없는 사람을 현장으로부터 격리하여 현장 보존과 관계자 및 입회인 참관 시킴

• 수사관이나 분석관이 바로 작업하지 않고 데이터베이스 관리자를 대동해 작업 지시를 하여 작업에 사용된 쿼리문 기록

• 원활한 협조가 이뤄지지 않을 경우 직접 쿼리문을 사용하여 조사 가능 (이때도 사용한 쿼리문을 꼭 기록해야 함)

• 특정 로그 및 설정 제어 파일은 DBMS마다 다르므로 사전에 각 DBMS 별 저장 경로 확인 및 수집

 

[표 1] RDBMS 별 증거 수집 파일 목록

Oracle	DBF	데이터베이스의 실제 데이터가 들어있는 파일
	CTL	데이터베이스 마운트 / 오픈 시에 사용하는 파일
	LOG	데이터베이스 사용, 오류 등을 기록하는 파일
MySQL	MYD	MySQL 저장 엔진이 MyISAM일 경우 데이터베이스의 실제 데이터가 들어있는 파일
	MYI	MySQL 저장 엔진이 MYISAM일 경우 데이터베이스의 데이터 인덱스 정보를 담는 파일
	FRM	테이블 구조에 대한 정보를 담는 파일 (어떤 저장 엔진이든 테이블이 생성되면 자동 생성)
	ibdata	MySQL 저장 엔진이 InnoDB일 경우 데이터베이스 데이터와 인덱스 정보를 담는 파일
	ibd	MySQL 저장 엔진이 InnoDB이고 다수의 Table Space 사용이 허용된 경우 데이터베이스 데이터와 인덱스 정보를 담는 파일
	binlog	데이터베이스 조직 / 조회에 사용된 쿼리문을 기록하는 로그 파일
Microsoft SQL Server	MDF	SQL Server의 데이터베이스 주 데이터 파일
	NDF	SQL Server의 데이터베이스 보조 데이터 파일
	LDF	데이터베이스 사용, 오류 등을 기록하는 로그 파일
	BAK	데이터베이스를 백업하는 파일

 

그리고 압수 대상 데이터베이스가 원격지에 있다면, 원격지 데이터베이스의 IP 및 패스워드 등의 정보를 확인하고, 네트워크 위치와 시스템 정보를 수집한다.

 

원격이 아닌 데이터베이스 서버를 압수할 경우, shutdown 명령 후 운영제제를 종료한다.

 

 

과거 시점의 데이터 압수 시에는 백업 데이터를 활용하여 수집하며, 증거 수집에서 목적에 맞는 자료만 추출할 경우, 데이터베이스 또는 운영체제 CMD 상에서 명령어를 입력하여 자료 추출 및 복사한다.

 

추출된 결과를 엑셀과 같은 파일로 가공하면 분석 및 조사가 수월해진다.

 

대부분의 기업은 데이터베이스를 주기적으로 백업을 실시하기 때문에 삭제된 데이터 또한 백업 데이터를 통해 복원이 가능하다.

 

마) 이송 및 보관 단계

• 추출된 데이터베이스 복사본 또는 증거 파일의 해시 값을 계산하고 기록 및 확인 후에 보관

• 해시 값은 증거물이 압수 및 분석 과정에서 부당하게 훼손되거나 변경되지 않았음을 검증하는 수단

• 생성 후에는 증거 데이터 추출 시 작성된 문서 값과 비교 확인을 해야 함

• 적은 용량의 증거물일 경우, CD 또는 DVD로 제작하여 레이블에 피압수자의 서명을 받음

• 대용량 증거 파일은 분할하여 해시 값을 생성

• 또한 증거물 이송 중에 손상 방지를 위한 대책 강구 필요 (충격방지 케이스, 정전기 방지용 랩 등 활용)

 

데이터 추출 시 고려 사항

• 대형 범죄가 아닌 이상 규모가 큰 사이트에서 데이터베이스 전체를 복제하는 경우는 거의 없음

• 저장 용량이 크고 복제 시간도 많이 소요되는데다가 개인 정보나 기밀 정보 유출 등의 위험이 있기 때문

• 따라서 주로 미리 받은 ERD나 스키마로 데이터베이스 구조를 분석

• 그 이후 쿼리문을 입력하여 필요한 부분만 덤프 진행

• 덤프는 담당자가 직접 하거나 담당자 입회하에 수사관이 직접 수행

 

데이터 추출 과정에 앞서 데이터베이스 서버를 정지시킬 수 없는 경우에는 데이터베이스 덤프를 바로 시행하지 않고 해시 값을 먼저 생성하여 담당자나 소유자 확인과 서명을 받는다.

 

그리고 서버의 로그, 데이터베이스 테이블 space를 함께 복사하여 해당 데이터베이스 테이블을 재구성하는 데에 많은 시간이 소요되는 것을 방지한다.

 

레이드로 구성되어 있는 서버의 경우, 디스크를 분리하면 재구성이 어려워진다. (특히 레이드 10이나 01)

 

따라서 레이드가 구성되어 있는 상태에서 Encase 또는 dd로 이미징하거나 파일을 복사한다.

 

증거 자료를 확보한 후에는 역시 해시 값을 생성하여 관리자나 소유자에게 확인과 서명을 받아야 한다.

 

수집해야 할 기본 정보 리스트

• 운영체제 시스템과 관련된 정보 (시스템 시간 / 날짜, 로그인 기록, 사용자 및 그룹, 네트워크 정보)

• 실행중인 전체 프로세스 정보 (프로세스 간의 부모 자식 관계, 연결된 DLL 정보 등 확인)

• 메모리 덤프 (메모리 내에 저장된 데이터 분석을 위해 필요 시에 메모리 덤프 수행)

• 레지스트리 정보 (Windows Server를 사용하는 경우)

• 데이터베이스 서버 내 모든 로그 파일 (이벤트 로그, 메시지 로그,  etc)

 

은닉 데이터베이스 실행 확인

• 은닉 데이터베이스 실행 여부 확인을 우힌 방법으로 2가지 존재

• 첫 번째는 프로세스 정보를 확인하는 방법

• 두 번째는 네트워크 통신 상태를 확인하는 방법

윈도우 시스템의 경우 명령 프롬프트를 통해 [tasklist] 명령어를 통해 동작 중인 서비스를 확인할 수 있으며, 네트워크 정보는 [netstat -anob]를 통해 확인 가능하다.

 

그리고 리눅스의 경우 [ps -ef] 명령어로 프로세스 정보를, 네트워크 정보는 [netstat -anop]를 통해 확인 가능하다.

 

 

수집해야 할 데이터베이스 정보 리스트

• 데이터베이스 종류

• 데이터베이스 인스턴스 버전 정보

• 휘발성 정보

• 사용자 목록

• 가장 최근에 실행된 SQL 파일 사본

• 테이블 정보

• 데이터베이스 전체 덤프 혹은 데이터베이스 내부 특정 파일들

• 로그 파일 (Error, General, binary, Redo, Listener 로그 등)

• 데이터베이스 백업 파일 

 

주요 증거 데이터

• 휘발성 데이터베이스 Connection & Session 정보

• 데이터베이스 전체 또는 특정 데이터베이스

• 테이블 전체 또는 특정 테이블 또는 특정 레코드

• 데이터베이스의 메타데이터 또는 테이블의 메타데이터

• 데이터베이스 자체적으로 기록하는 로그 파일

• 시스템 로그 파일

• 애플리케이션 로그 파일

 

자료 수집 우선 순위

• 1순위 : 데이터베이스 서버 Connection & Sessions 정보

• 2순위 : 트랜잭션 로그

• 3순위 : 데이터베이스 서버 로그

• 4순위 : 데이터베이스 서버 파일

• 5순위 : 시스템 이벤트 로그

 

데이터베이스 연결 정보와 트랜잭션 로그

• 데이터베이스 연결 정보(접속 정보)와 트랜잭션 로그는 데이터베이스 포렌식에 있어 가장 중요도가 높음

• 이는 어떤 사용자가 데이터베이스에 접속하여 어떤 쿼리를 사용하였는지에 대한 로그를 가지고 있기 때문에 향후 사건 추적에 매우 중요한 단서가 됨

• 비 인가자가 중요 데이터를 지웠다고 가정할 경우, 연결 정보와 트랜잭션 로그를 추적하여 실마리 잡기 가능

• 단, 대규모 시스템일수록 시간이 매우 오래 소요될 수 있음 

---

1-3. 증거 자료 분석 절차

• 1) 추출한 데이터베이스 복사본  또는 증거 파일들의 해시 값과 문서에 기재된 해시 값을 비교

• 2) 휘발성 정보를 획득했을 경우에는 메모리, 프로세스, 파일 등의 자원 사용 분석

• 3) 데이터베이스 증거에 맞는 운영체제 및 프로그램을 구축하여 증거 파일 복제

• 4) 데이터베이스 접속 프로그램과 로그 분석 프로그램을 사용하여 자료구조, 자료 관계, 접근한 사용자 목록, 사용 기록 등의 데이터를 획득하고, 목적에 따라 자료 복구를 수행

• 5) 데이터베이스의 분석자, 분석 과정, 분석 결과 등 세부 사항 기록

---

1-4. 데이터 추출 관련 참고 자료

 

가) SAP를 활용한 데이터 추출

• 많은 대기업들이 회계, 판매, 생산, 인사, 재정 등 중요 데이터를 통합적으로 관리 및 처리하기 위하여 ERP(Enterprise Resource Planning)라는 시스템 사용

• 데이터베이스 포렌식에서는 ERP 데이터 추출을 위해, ERP 관련 제품 시장에서 가장 큰 점유율을 차지하는 SAP 사 S/W 사용

 

SAP 기능

• GUI 기반으로 SE16, SE11 등 T-CODE라는 SAP 상에서 미리 정의된 추출 기능 사용

• T-CODE 또는 트랜잭션 코드로 SAP 메뉴의 커맨드 필드에 명령을 입력하여 원하는 작업을 보다 빨리 수행

• 시스템 작업을 경로를 찾아 들어가 수행하지 않아도 되는 바로가기와 비슷한 기능이라고 보면 됨

• 약 200,000가지의 T-CODE가 존재하여 거의 모든 트랜잭션 기능 제공

• 사용자가 T-CODE를 커스터마이징할 수 있지만 영문자, 숫자 조합 20자까지 가능

• SE11 / 16은 관련 T-code 실행 권한이 필요하며, 데이터 용량이 큰 경우 런타임 오류가 발생할 가능성 있음 

 

SE16은 일반 테이블을 조회하는 SAP T-CODE를 의미하며, SE11은 ABAP Dictionary를 조회하는 SAP T-CODE를 의미한다.

 

ABAP (Advanced Business Application Programming)

• SAP에서 개발한 SAP만을 위한 프로그래밍 언어로 데이터를 추출하는 데 사용

• 서버 사이드 프로그래밍 언어로 개발을 위한 환경인 SAP Application Server에 접속하기 위한 SAP GUI 필요

• SAP의 3가지 테이블 유형 모두의 데이터 추출 가능

SAP의 3가지 테이블 유형으로는 Transparent, Pool 그리고 Cluster라는 3가지 테이블 유형이 있다.

 

Transparent는 오직 하나의 테이블이 존재하며 데이터베이스와 1대1 관계를 형성한다.

 

주로 중요한 정보를 담은 마스터 데이터를 저장할 때 사용한다.

 

Pool은 커스터마이징 데이터나 자잘한 시스템 데이터와 같이 테이블 자체는 작지만 수가 많을 경우 사용하며, 데이터베이스와 다대일 관계를 형성한다.

 

Cluster는 큰 시스템 데이터와 같이 테이블이 크고 수가 적은 경우에 사용하며, 데이터베이스와 다대일 관계를 형성한다.

 

SQL Query

• RDBMS에 직접 접근해 SQL 명령어를 입력하는 것으로 데이터 추출

• 데이터베이스 구조(인덱스, 키 ,테이블, 데이터 관계 등)에 대한 이해 필요

• SAP 테이블 중 Cluster 테이블과 Pool 테이블에 대한 데이터 추출은 편리하지 않음

 

ACL과 SAP Direct Link / ODBC (Open Database Connectivity)

• ACL 사에서 개발한 Direct Link 소프트웨어로 모든 데이터에 접근하여 추출하는 방법

• 반복적 업무를 batch 파일로 만들어 수행하는 것이 가능

• 별도의 IFD(Input File Definition)가 없어 편의성이 높음

• 하지만, 수사관의 PC 및 데이터 압수 대상 회사의 컴퓨터에 해당 S/W가 설치되어 있어야만 함

• ODBC는 ACL에서 기본적으로 제공하는 프로그램

• SAP 테이블 중 Cluster 테이블과 Pooled 테이블에 대한 데이터 추출이 편리하지 않음

 

 

나) Oracle ERP 데이터베이스 압수 체계

 

데이터 추출 방법

• Standard Report 기능 이용 : Oracle Web Browser를 통해 압수 대상 데이터와 관련한 Standard Report를 다운로드하며, Data sources and relationship에 대한 지식이 필요하고 다운로드할 수 있는 레코드 길이에 제한 있음

• SQL Query 이용 : RDBMS에 직접 접근하여 정의된 명령어를 사용하여 데이터를 추출하는 방법이며, 데이터베이스 구조(index, keys, tables, data relations)에 대한 이해 필요

 

 

다) Oracle의 전표, 기본 데이터 테이블 및 압수 방법

 

[표 2] Oracle의 전표, 기본 데이터 테이블

구분	테이블	테이블명	압수 방법
전표 데이터	GL_JE_HEADERS	전표 헤더	SQL Query
	GL_JE_LINES	전표 라인
	GL_CODE_COMBINATIONS	계정 배분 코드
	GL_JE_BALANCE	계정별 잔액 테이블
기본 데이터	FND_FLEX_VALUE_SETS	원장 ID 별 계정 SET 정의 테이블
	FND_FLEX_VALUE_VL	계정 SET 별 계정 과목 코드 / 과목명 테이블
	FND_USER	ERP 사용자 테이블
	GL_PERIODS	회계 기간 테이블
	GL_SETS_OF_BOOKS	원장 ID 테이블 (재무회계, 사업부회계 등)
	GL_JE_SOURCES_TL	전표소스 (출처) 코드 테이블

---

# Reference

 

http://www.yes24.com/Product/Goods/87579830