[Digital Forensic] Registry 분석

2020. 5. 8. 02:46

[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

저작자표시

'Digital Forensics > Forensic Theory' 카테고리의 다른 글

[Digital Forensic] 안티 포렌식 (0)	2020.05.09
[Digital Forensic] PE(Portable Executable) 구조 (0)	2020.05.09
[Digital Forensic] EXT 파일 시스템 (3) (0)	2020.04.02
[Digital Forensic] EXT 파일 시스템 (2) (0)	2020.04.02
[Digital Forensic] EXT 파일 시스템 (1) (0)	2020.04.01

Yum_Yum