KR20180052466A - 메모리 포렌식을 이용한 인메모리 데이터 추출 방법 - Google Patents

메모리 포렌식을 이용한 인메모리 데이터 추출 방법 Download PDF

Info

Publication number
KR20180052466A
KR20180052466A KR1020160149803A KR20160149803A KR20180052466A KR 20180052466 A KR20180052466 A KR 20180052466A KR 1020160149803 A KR1020160149803 A KR 1020160149803A KR 20160149803 A KR20160149803 A KR 20160149803A KR 20180052466 A KR20180052466 A KR 20180052466A
Authority
KR
South Korea
Prior art keywords
heap
memory
data
imdb
segment
Prior art date
Application number
KR1020160149803A
Other languages
English (en)
Inventor
한규식
박성순
김경훈
Original Assignee
(주) 글루시스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by (주) 글루시스 filed Critical (주) 글루시스
Priority to KR1020160149803A priority Critical patent/KR20180052466A/ko
Priority to PCT/KR2016/013076 priority patent/WO2018088596A1/ko
Publication of KR20180052466A publication Critical patent/KR20180052466A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Abstract

본 발명은 디지털 포렌식을 이용한 인메모리 데이터 추출 방법에 관한 것이다.
본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 방법은 메모리 분석 도구인 Volatility의 플러그인으로 구현할 수 있다.

Description

메모리 포렌식을 이용한 인메모리 데이터 추출 방법{IMDB EXTRACTING METHOD BY USING MEMORY FORENSIC}
본 발명은 메모리 포렌식을 이용한 인메모리 데이터 추출 방법에 관한 것이다.
최근 컴퓨팅 성능의 발전에도 불구하고 데이터 저장 장치인 디스크는 타 장치들에 비해 발전 폭이 현저히 떨어진다. 이에 따라 디스크 입출력 속도 때문에 전체 컴퓨팅 속도가 지연되는 것을 막기 위한 기술이 연구되고 있다. 특히 메모리 가격의 하락과 기업의 자사 제품이 지원하는 메모리 용량이 커지고, 64bit 컴퓨팅이 보편화됨에 따라 데이터를 메모리에 적재할 수 있는 크기가 커지면서 이를 활용하는 인메모리 컴퓨팅 기술이 주목받고 있다. 이러한 기술을 통해 기존 데이터베이스가 디스크에 데이터를 저장하여 발생하는 성능 제약을 해결할 수 있는 방안으로 IMDB(In-Memory Database)가 등장하였다(H. Garcia-Molina and K.Salem, Memory Database Systems: An Overview,IEEE Transactions on Knowledge and Data Engineering, Vol. 4, No. 6, pp.509-516, Dec. 1992.).
하루에 발생하는 수많은 데이터를 통해 의미 있는 정보를 추출하여 활용하고자 하는 빅데이터 시장의 발달에 따라 고성능, 실시간 및 대규모 트랜잭션 처리에 대한 요구가 필요하게 되면서 기존 디스크 기반 데이터베이스의 한계를 해결하는 IMDB의 필요성이 증가하게 되었다(H. Zhang et al., Big Data Management and Processing: A Survey,IEEE Transactions on Knowledge and Data Engineering, Vol. 27, No. 7, pp.1920-1948, Apr. 2015.). 도1에 도시된 바와 같이, IMDB는 데이터베이스를 메모리에 상주시켜 운영하는 DBMS(Database Management System)로써 데이터를 디스크가 아닌 메모리에 보관하고 실시간으로 분석할 수 있게 한 기술을 이용한다. 이는 디스크에 대한 접근없이 메모리 접근만을 통해 데이터를 관리하므로 고성능 데이터 처리를 가능하게 하여 디스크에 비해 상당히 빠른 속도를 가진다는 특징이 있다. 이러한 장점으로 많은 기업들 및 오픈 소스 진영에서는 연구를 통해 IMDB를 출시하고 있으며 현재 상용화된 대표적인 제품으로는 SAP HANA, Oracle 12c, Redis 등이 있다.
디지털 장치가 발전함에 따라 범죄에 활용되면서 이를 디지털 증거로써 수집 및 분석하는 디지털 포렌식이 발전하게 되었다. 디지털 포렌식의 다양한 분야 중에서도 DBMS 시장의 성장과 함께 개인정보 유출과 같은 침해사고 발생 시 이를 조사하기 위한 데이터베이스 포렌식의 필요성이 증가하게 되면서 MySQL, MSSQL, Oracle 등 디스크 기반 관계형 데이터베이스 뿐만 아니라 NoSQL을 대상으로 한 연구들이 꾸준히 진행되고 있다. 그 결과 디스크 기반 저장소를 활용하는 관계형 데이터베이스를 조사하는 많은 기술이 발전하고 있다(J. Wagner, A. Rasin and J. Grier, Forensic Analysis Through Internal Structure Carving,Digital Investigation, Vol. 14, pp.S106-S115, Aug. 2015.). 최근에는 인메모리 컴퓨팅 기술의 발전으로 메모리를 조사 대상으로 하는 디지털 포렌식 기법이 요구되고 있다.
인메모리 컴퓨팅의 발전에 따라 메모리 조사가 필요해졌고, 이를 위해 디지털 포렌식 기법인 메모리 포렌식이 연구되고 있다. 메모리에는 컴퓨터 시스템 구조 상 CPU 연산이 이루어지는데 필요한 데이터와 코드가 적재된다. 이러한 특성으로 디스크와는 다르게 소프트웨어 등이 실행되는 과정이나 실행되었던 정보가 존재하지만 휘발성이라는 특성 때문에 시스템이 재시작 될 경우 데이터를 잃을 수 있어 조사가 필요한 경우 실시간으로 조사하거나 메모리 덤프를 이용하여 조사한다[8][9]. 현재 메모리 포렌식의 주요 조사 대상은 커널 메모리 공간의 구조와 데이터이며 이를 해석하여 정보를 얻는데 목표를 두고 있다. 그러나 운영체제에서 쓰이는 데이터 위주의 정보만을 획득할 수 있기 때문에 특정 응용 프로그램에서 사용한 데이터를 얻는데 한계가 있다. 이러한 이유로 응용 프로그램에서 개별적으로 사용되는 데이터를 추출하기 위해서는 유저 메모리 공간을 조사할 필요가 있다.
현재 데이터베이스 포렌식은 디스크에 저장된 데이터베이스 파일을 분석하여 데이터를 추출한다. 이는 데이터를 메모리에 저장하는 IMDB와는 분석 대상이 다르기 때문에 메모리 내 데이터를 조사하기 위한 새로운 접근 방법이 필요하다.
본 발명은 상기와 같은 문제점을 해결하기 위해 안출된 것으로, 본 발명의 목적은 기존의 디스크 기반 데이터베이스와는 다른 특성을 갖는 IMDB를 조사하기 위해 메모리 포렌식을 이용하여 유저 메모리 공간을 조사하고, 데이터를 추출하기 위한 메모리 포렌식을 이용한 인메모리 데이터 추출 방법을 제공하는 것이다.
본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 방법은 메모리 분석 도구인 Volatility의 플러그인으로 구현할 수 있다.
본 발명에 따르는 메모리 포렌식 기법을 이용한 인메모리 데이터 추출 방법은 메모장 프로그램의 데이터 추출 방법의 문제점을 해결하였을 뿐만 아니라 IMDB에서도 성공적으로 데이터를 추출할 수 있다.
본 발명에 따르는 메모리 포렌식 기법을 이용한 인메모리 데이터 추출 방법은 데이터가 실제 저장되는 힙과 관련한 메모리 영역만을 조사하는 것이 가능하여 조사 범위를 줄일 수 있으며, 메모리 포렌식을 이용하여 IMDB의 데이터를 추출할 수 있고, 기존의 데이터 추출 방법에서 이용하는 조사 범위에 비해 줄어든 조사 범위를 이용함에 따라 효율적인 조사가 가능하다.
도1은 메모리 및 디스크 기반 데이터베이스 구조를 나타내는 블록도이다.
도2는 VAD 트리 플러그인의 구성을 개략적으로 나타내는 블록도이다.
도3은 userspace 플러그인의 구성을 개략적으로 나타내는 블록도이다.
도4는 윈도우 환경에서 실행되는 notepad 플러그임의 구성을 개략적으로 나타내는 블록도이다.
도5는 힙 메모리 할당 구조를 나타내는 도면이다.
도6은 힙 할당 구조에서 힙 관리자의 할당 요청 처리 방법을 나타내는 흐름도이다.
도7은 힙과 관련한 메모리 영역을 나타내는 도면이다.
도8은 모든 힙의 주소를 얻기 위해 ProcessHeaps 멤버를 조사하는 과정을 나타내는 흐름도이다.
도9는 _HEAP 구조체를 나타낸다.
도10은 가상 할당 영역이 연결되는 구조를 나타낸다.
도11은 _HEAP_SEGMENT 구조체를 나타낸다.
도12는 가상 할당 영역 구조체를 나타낸다.
도13은 _HEAP_ENTRY 구조체를 나타낸다.
도14는 힙과 관련된 메모리 영역의 전체적인 구조를 나타낸다.
도15는 디지털 포렌식을 이용한 인메모리 데이터 추출 실험 환경을 나타내는 도면이다.
도16은 메모장 데이터 추출 방법을 적용하기 위한 예시적인 실험 데이터를 나타낸다.
도17은 기존 플러그인을 이용한 실험 1의 수행 결과를 나타내는 그래프이다.
도18은 기존 플러그인을 이용한 실험 2의 수행 결과를 나타내는 그래프이다.
도19는 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험 1의 마지막 단계에서의 데이터를 나타내는 도면이다.
도20은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험 2의 8번째 단계(데이터 입력 회수 160회)에서의 힙 세그먼트가 할당된 상태를 나타내는 도면이다.
도21은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험 2의 11번째 단계(데이터 입력 회수 220회)에서의 가상 할당 영역이 할당된 상태를 나타내는 도면이다.
도22는 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험 2의 마지막 단계에서의 세그먼트를 나타내는 도면이다.
도23은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험 2의 마지막 단계에서의 각각의 힙 세그먼트를 나타내는 도면이다.
도24은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험의 힙 세그먼트 0x550000 내 힙 블록을 나타내는 도면이다.
도25은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험의 힙 세그먼트 0x1360000 내 힙 블록을 나타내는 도면이다.
도26은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험의 힙 세그먼트 0x1560000 내 힙 블록을 나타내는 도면이다.
도27은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험의 힙 세그먼트 0x1960000 내 힙 블록을 나타내는 도면이다.
도28은 본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 실험의 힙 세그먼트 0x2270000 내 힙 블록을 나타내는 도면이다.
도29는 본 발명에 따르는 Redis String 타입 문자열 관리 구조를 도면이다.
도30은 본 발명에 따르는 메모리 내에서의 Redis String 타입 문자열 관리 구조를 도면이다.
도31은 기존 플러그인과 본 발명에 따르는 플러그인의 힙 조사 범위를 나타내는 그래프이다.
이하, 첨부된 도면들을 참조로, 본 발명에 따른 실시예를 상세히 설명한다.
메모리 포렌식을 이용하여 유저 메모리 공간에서의 데이터 추출과 관련하여 다음과 같은 관련 연구가 있다.
1. 유저 메모리 공간 정보
운영체제는 프로세스마다 각각의 고유한 메모리 공간을 제공한다. 이러한 메모리 공간을 가상 주소 공간이라고 하며 유저(user) 메모리 공간, 커널 메모리 공간으로 나누어진다. 유저 메모리 공간은 응용 프로그램이 실행되면서 사용되는 코드 및 데이터가 저장되며 커널 메모리 공간에는 프로세스의 전체적인 정보가 저장된다.
B.Dolan- Gavitt 은 프로세스가 사용하는 유저 메모리 공간 내 할당된 메모리 영역을 검색하기 위한 기법을 제안하였다( VAD tree: A Process-eye View of Physical Memory, Digital Investigation , Vol. 4, pp.62-64, Sep . 2007.). 커널 메모리 공간에 존재하는 커널 구조체인 _ EPROCESS 의 VadRoot 멤버를 참조하여 전체 유저 메모리 공간에 할당된 메모리 영역과 속성을 조사하였고 조사 결과로써 할당된 메모리 영역의 시작과 끝 주소, 할당 목적과 같은 유용한 정보를 트리 형식으로 보여주며 메모리 분석 도구인 Volatility의 플러그인으로 구현하였고, VAD tree라는 이름으로 정의하였다. 도2에 도시된 바와 같이, VAD tree는 각각의 메모리 영역 주소를 단순하게 나열할 수 있을 뿐만 아니라 Graphviz 프로그램을 통해 그래프로 출력할 수 있도록 지원하여 각각의 메모리 영역을 쓰임새에 따라 색깔로 쉽게 구분할 수 있게 한다. 이와 같은 정보를 통해 유저 메모리 공간에 할당된 전체 메모리 영역의 정보를 간략하게 파악할 수 있다.
A.White는 유저 메모리 공간에 할당된 메모리 영역의 할당 용도를 보여주기 위한 기법을 제안하였다(the User Space Through User Allocations, Digital Investigation , Vol. 9, pp. S3 - S12 , Aug . 2012). VAD tree에서 제공하는 정보와 더불어 VAD tree 각각의 메모리 영역을 나타내는 VAD node 구조 및 프로세스의 _EPROCESS에 존재하는 메모리 할당 관련 멤버를 분석하였고 해당 메모리 영역의 할당 용도에 대한 상세한 내용을 보여주며 메모리 분석 도구인 Volatility의 플러그인으로 구현하였고, userspace 라는 이름으로 정의하였다. 도3에 도시된 바와 같이, userspace 는 VAD node가 갖는 기본 정보 외에 할당 속성을 조사하며 private과 mapped 둘 중 하나의 속성을 갖는다. private 속성은 오직 해당 프로세스 내에서만 존재하는 할당 영역이고, mapped 속성은 다른 프로세스에서도 존재할 수 있는 할당 영역이다. 이와 같은 정보를 통해 유저 메모리 공간의 상세한 할당 정보를 파악할 수 있다.
2. 데이터 추출
메모리 포렌식을 이용하여 커널 메모리 공간을 조사함에 따라 유저 메모리 공간 내 할당된 메모리 영역을 조사할 수 있다. 이를 바탕으로 응용 프로그램에서 사용되는 데이터를 추출하여 커널 메모리 공간에서 추출할 수 있는 데이터만으로는 부족했던 정보를 보완하고자 하는 연구가 진행되고 있다.
T. XIAO 는 도4에 도시된 바와 같이, 윈도우 환경에서 실행되는 메모장에 입력된 내용을 추출하기 위한 기법을 제안하였다(Text Documents Opened by Notepad from Windows7 RAM Image, Journal of Computational Information Systems , Vol. 10, No. 16, pp.7117-7124, Aug . 2014.). T. XIAO 는 메모장의 경우 작성된 내용이 저장되는 영역은 VAD node 중 가장 큰 할당 크기를 갖는 영역이라 주장한다. 이에 따라 데이터 추출을 위해 먼저 _ EPROCESS 의 VadRoot 멤버를 참조하여 메모장에서 사용하는 유저 메모리 공간에 할당된 메모리 영역을 조사한다. 이렇게 조사한 VAD node에서 할당된 크기가 가장 큰 영역을 찾아 메모장에 입력된 내용을 찾는다.
Volatility는 Volatility Foundation에서 제공하는 오픈 소스 메모리 포렌식 도구이다. Volatility는 메모리 분석을 위해 다양한 플러그인을 제공하고 있으며 필요에 따라 사용자가 직접 플러그인을 작성하여 활용할 수도 있다. 이 분석 도구에는 데이터 추출과 관련하여 메모장의 작성 내용을 추출하기 위한 notepad 플러그인이 존재한다. 이 플러그인은 동적 할당에 사용되는 힙을 조사하여 메모장에서 작성된 내용을 찾는다.
이하 본 발명에 따르는 디지털 포렌식을 이용한 인메모리 데이터 추출 방법을 설명한다.
인메모리 데이터베이스의 데이터 추출 방법
메모리 포렌식을 이용한 데이터 추출 방법으로 유저 메모리 공간 정보를 나타내는 플러그인 및 메모리 분석 도구인 Volatility의 notepad 플러그인을 사용하는 방법이 있다. 그러나 유저 메모리 공간의 정보는 할당된 메모리 영역의 위치와 크기를 알려줄 뿐 실제 데이터의 추출을 위한 분석은 하지 않기 때문에 조사를 진행하는 사람이 각각의 할당된 메모리 영역에서 직접 데이터를 추출해야만 한다. 또한 notepad 플러그인은 메모장 프로그램에 한정하여 입력된 내용을 추출하는데 쓰이기 때문에 분석 대상이 제한되고 정확한 분석이 이뤄지지 않고 있어 데이터 추출 정확도가 높지 않다. 따라서 본 발명에서는 힙 구조의 조사를 기반으로 한 메모리 포렌식 기법을 이용하여 IMDB의 데이터를 추출하는 방안을 제안한다.
1. 힙 할당 구조
힙(HEAP)은 동적으로 할당된 메모리 영역을 의미한다. 도5에 도시된 바와 같이, 응용 프로그램에서 동적 메모리 할당을 요청하면 관련된 라이브러리는 힙 안에서 사용 가능한 영역을 찾고, 해당 메모리 영역에 접근 가능하도록 힙의 핸들 또는 포인터를 반환하여 사용 가능하게 한다. 모든 응용 프로그램은 실행 시 1MB 크기의 자동으로 늘어나는 디폴트 힙(Default heap)이 할당되고, 필요에 따라 동적 힙 또는 전용 힙이라 불리는 힙이 할당된다. global/local 메모리 API, C run-time 라이브러리의 메모리 함수는 디폴트 힙을 사용하고, 핸들을 통해 구체적인 힙을 지정하는 힙 메모리 API는 동적 힙을 사용한다. 이처럼 동적 할당 요청을 위해 다양한 함수 및 라이브러리가 존재하며 이를 총괄해서 힙 메모리 할당이라고 한다.
윈도우 환경에서는 메모리를 관리하기 위해 윈도우 힙 관리자를 사용한다. 힙 관리자는 응용 프로그램의 메모리 요청 및 해제를 제공하기 위해 존재하며 프론트엔드 관리자(Front-End Allocator)와 백엔드 관리자(Back-End Allocator)로 이루어져 있다[16]. 프론트엔드 관리자는 힙의 성능을 최적화하기 위해 존재하며 이를 위해 Windows Vista 이전 버전에서는 LAL(Look Aside List), 이후 버전부터는 LF(Low Fragmentation)을 사용한다. LAL과 LF는 실제로 데이터가 저장되는 메모리 영역인 힙 블록(Heap Block) 중 비어있는 힙 블록을 관리하기 위한 리스트이다. 이 리스트를 통해 힙 관리자는 응용 프로그램의 메모리 할당 요청에 따라 비어있는 메모리 영역을 할당한다. LAL은 메타데이터 8Bytes를 포함한 1,024Bytes 크기의 프리 힙 블록까지 관리할 수 있고, LF는 16,384Bytes 크기의 프리 힙 블록까지 관리할 수 있다. 이를 넘어서는 크기는 백엔드 관리자에서 관리한다. 백엔드 관리자는 프리 리스트(Free list)를 통해 프리 힙 블록을 관리한다. 프리 리스트는 524,280Bytes 크기의 프리 힙 블록까지 관리할 수 있다. 만약 프리 리스트가 524,280Bytes 크기를 넘어서는 할당 요청을 받게 되면 이를 가상 메모리 관리자에게로 요청을 전달하고, 가상 할당 리스트로 관리하게 된다. 힙 블록은 힙이 관리하는 특정 범위의 메모리 영역인 힙 세그먼트(Heap Segment) 내에 존재한다. 만약 특정 힙 세그먼트의 힙 블록을 모두 할당한 경우 가상 메모리 관리자에게 새로운 메모리 영역을 요청한다. 이를 통해 새로운 힙 세그먼트가 할당된다. 하나의 힙이 가질 수 있는 힙 세그먼트의 개수는 64개이고, 모든 세그먼트는 추적 가능한 리스트가 존재한다. 도6은 힙 할당 구조에서 힙 관리자의 할당 요청 처리 방법을 나타내는 흐름도이고, 도7은 힙과 관련한 메모리 영역을 나타내는 도면이다.
2. 힙 조사 방법
프로세스에 할당된 모든 힙은 _ EPROCESS 의 Peb 멤버 내에 ProcessHeaps 멤버의 값을 참조하여 시작 주소를 가져올 수 있다. 모든 힙의 주소를 얻기 위해 ProcessHeaps 멤버를 조사하는 과정을 도8로 나타내었다.
ProcessHeaps 멤버를 통해 찾은 힙은 _HEAP 구조체로 이루어져 있으며 힙 정보 및 힙 세그먼트를 조사하기 위한 멤버를 갖는다. Signature 멤버는 힙 임을 나타내는 값으로써 0 xEEFFEEFF 를 갖는다. VirtualAllocdBlocks 멤버는 양방향 링크의 주소를 갖는 _LIST_ENTRY 구조체 타입이며, 해당 멤버가 존재하는 위치에 힙 블록의 최대 크기를 초과하는 할당 영역의 주소가 저장되어 있다. 만약 가상 할당 영역이 존재하지 않는 경우 해당 멤버의 주소가 저장된다. Segments 멤버는 해당 멤버가 존재하는 위치에 힙 세그먼트들의 주소가 저장되어 있다. 도9는 _HEAP 구조체를 나타내고, 도10은 가상 할당 영역이 유지되는 구조를 나타낸다.
Segments 멤버를 통해 찾은 힙 세그먼트는 도11에 도시된 바와 같이, _HEAP_SEGMENT 구조체로 이루어져 있으며, 힙 세그먼트 정보 및 힙 블록을 조사하기 위한 멤버를 가지고 있다 . Signature 멤버는 힙 세그먼트임을 나타내는 값으로써 0 xFFEEFFEE 를 갖는다. Heap, BaseAddress 멤버에는 힙 세그먼트가 속한 힙의 주소가 저장되어 있다. FirstEntry 멤버에는 현재 힙 세그먼트의 첫 번째 힙 블록의 위치가 저장되어 있다.
VirtualAllocdBlocks 멤버를 통해 찾은 가상 할당 영역은 힙 블록의 최대 크기를 초과하는 할당 요청을 위한 영역이며, 도12에 도시된 바와 같이 _HEAP_VIRTUAL_ALLOC_ENTRY 구조체로 이루어져 있고 해당 영역의 정보를 가지고 있다. Entry 멤버는 양방향 링크의 주소를 갖는 _LIST_ENTRY 구조체 타입이며 그림 11과 같이 가상 할당 영역들을 찾는데 필요한 위치가 저장되어 있다. 힙 내에 유일한 가상 할당 영역이면 힙 구조체의 VirtualAllocdBlocks 멤버 주소가 저장된다. CommitSize 멤버는 실제 커밋된 크기가 저장되어 있으며 대부분의 경우 ReserveSize 멤버와 동일하다.
힙 세그먼트의 FirstEntry 멤버를 통해 찾은 힙 블록은 도13에 도시된 바와 같이, _HEAP_ENTRY 구조체로 이루어져 있으며 힙 블록의 정보를 가지고 있다. Size 멤버는 힙 블록의 크기를 할당 단위인 8Bytes로 나눈 값이 저장되어 있다. 이 멤버를 통해 다음 힙 블록의 시작 위치를 찾을 수 있다. PreviousSize 멤버는 이전 힙 블록의 크기를 힙 할당 단위로 나눈 값이 저장되어 있다. Flags 멤버는 힙 블록의 상태가 저장되어 있다. UnusedBytes 멤버는 힙 블록의 헤더 크기와 힙 블록 할당 범위에서 사용하지 않는 크기를 더한 값이 저장되어 있다. SegmentIndex 멤버는 힙에 속한 힙 세그먼트의 순서가 저장되어 있다.
도14는 이상 설명한 힙과 관련된 메모리 영역의 전체적인 조사 대상을 나타낸다.
실 험
1. 실험 환경
실험 환경은 메모리 수집 프로그램에 의한 메모리 내용의 변화를 예방하고, 빠르게 수집 가능하도록 가상 환경을 이용한다. 가상 환경의 일시 정지 기능을 사용하면 해당 시점의 가상 머신의 메모리 내용이 메모리 덤프 파일처럼 vmem 파일로 저장되기 때문에 별도의 메모리 수집 프로그램을 사용할 필요가 없다. 실험에 사용된 환경과 소프트웨어는 표1과 같다.
가상 환경 도구 VMware workstation player 12
분석 대상 환경 OS Windows XP SP3
RAM 512MB
HDD 20GB
IMDB Redis 2.4.5
메모리 수집 도구 -
메모리 분석 도구 Volatility 2.1, 2.5
도15에 도시된 바와 같이, IMDB 인 Redis 는 가상 머신에서 서버를 운영하고, 호스트PC에서 클라이언트 프로그램을 실행하여 서버로 데이터를 전송한다. 이후 데이터 추출을 위해 가상 머신을 일시 정지하여 vmem 파일을 수집하고 Volatility로 분석한다.
2. 실험 내용
데이터베이스 포렌식으로 메모리 내 캐쉬를 조사하여 일부 데이터를 추출하기도 하지만, 레코드 등과 같은 데이터의 추출은 디스크에 저장된 데이터베이스 파일을 조사하여 이루어진다. 실험에 사용한 Redis는 데이터를 모두 메모리에 저장하고, 설정에 따라 특정 시점에 데이터를 디스크에 파일로 백업한다. 하지만 백업된 파일의 조사는 최신의 데이터를 반영하지 못하는 경우가 존재하기 때문에 메모리 조사를 통해 실시간으로 저장된 데이터를 추출한다.
실험 순서는 다음과 같다.
먼저 메모장 프로그램을 대상으로 기존의 데이터 추출 기법을 적용한 실행 결과와 본 발명에서 제안하는 기법으로 구현한 플러그인의 실행 결과를 비교하여 구현한 플러그인의 개선점을 검증한다.
다음으로 Redis 를 대상으로 구현한 플러그인의 실행 결과를 분석하여 메모리 포렌식을 이용한 데이터 추출의 실현 가능성을 알아보고 데이터 추출의 정확도 및 이점을 증명한다.
1) 메모장 데이터 추출
메모장을 대상으로 한 실험 데이터는 도16에 도시된 바와 같이, 연합뉴스의 기사 내용[18]을 발췌하여 첫 문장의 앞에 단어를 넣어 생성하였다.
실험은 데이터 증가량에 따라 두 가지로 나눠 진행한다. 첫 번째 실험에서는 적은 양의 데이터를 점차적으로 늘려가는 실험으로써 총 20번의 단계를 진행하며 매 단계마다 그림 17의 데이터만큼을 추가하여 데이터양을 늘린다. 두 번째 실험에서는 많은 양의 데이터를 점차적으로 늘려가는 실험으로써 12번의 단계를 진행하며 매 단계마다 도16의 데이터를 20개씩 추가하여 데이터 양을 늘린다. 그리고 각 단계마다 vmem 파일을 수집 및 분석한다. 단, 데이터의 마지막에 반복 횟수를 알려주는 숫자 및 줄 바꿈 문자를 기입하여 데이터 증가량이 정확한지 표시한다. 이에 따라 반복 횟수 숫자 및 줄 바꿈 문자만큼 데이터 크기가 약간 증가하게 된다.
실험 1, 2의 각 단계마다 데이터를 입력 후 기존 플러그인으로 얼마나 정확하게 분석할 수 있는지 알아보기 위해 수집한 vmem 파일을 기존 플러그인으로 분석한 결과를 표 2, 도17 및 도18로 나타내었다.
실험 데이터
입력 횟수		 실험 데이터
크기(Bytes)		 기존 플러그인을
이용한 추출 크기(Bytes)		 추출 정확도
1 1 1,205 1,205 100%
2 2,414 2,204 91.3%
3 3,623 2,204 60.8%
4 4,832 2,204 45.6%
5 6,041 2,204 36.4%
6 7,250 2,260 31.1%
7 8,459 3,152 37.2%
8 9,668 3,152 32.6%
9 10,877 3,152 28.9%
10 12,087 2,204 18.2%
11 13,297 2,204 16.5%
12 14,057 2,204 15.6%
13 15,717 2,204 14.0%
14 16,927 2,204 13.0%
15 18,137 2,204 12.1%
16 19,347 2,204 11.3%
17 20,557 2,204 10.7%
18 21,767 2,204 10.1%
19 22,977 2,204 9.5%
20 24,187 2,204 9.1%
2 20 24,187 2,668 11.0%
40 48,387 0 0%
60 72,587 0 0%
80 96,787 0 0%
100 120,988 0 0%
120 145,208 0 0%
140 169,428 0 0%
160 193,648 0 0%
180 217,868 0 0%
200 242,088 0 0%
220 266,308 0 0%
240 290,528 0 0%
표 2를 통해 실험 1의 스무 번째 단계와 실험 2의 첫 번째 단계의 실험 데이터는 크기가 같은 시점임에도 데이터 추출 크기가 다른 것을 확인할 수 있었다. 또한 실험 1에서는 1,205Bytes에서 3,152Bytes만큼의 데이터를 추출할 수 있었으며 단계를 진행하면서 처음 100%였던 추출 정확도가 큰 폭으로 떨어지는 것을 확인할 수 있다. 실험 2에서는 첫 번째 단계에서 2,668Bytes를 추출할 수 있었으며 이어지는 단계에서는 데이터 추출이 불가능하였다. 기존의 notepad 플러그인은 이처럼 데이터 추출을 정확하게 수행하지 못하는 문제점을 보였다.
기존 플러그인의 문제를 알아보았고, 이를 해결하기 위하여 새로운 분석 방법을 이용해 플러그인으로 구현하였다. 구현한 플러그인으로 vmem 파일을 분석하여 각 실험의 단계마다 실험 데이터가 저장된 위치를 조사하는 것이 가능했고, 데이터를 100% 추출할 수 있었다. 첫 번째 실험을 진행하는 동안 구현한 플러그인을 통해 데이터가 저장되는 메모리 할당 영역을 조사한 결과를 표3으로 나타내었다.
실험 단계 데이터 입력 횟수 힙 주소 힙 세그먼트 주소 힙 블록 주소 힙 블록 크기
(Bytes)		 가상 할당 영역 주소
1 1 0xa0000 0xa0640 0xb35f0 2,504 -
2 2 0xb5e90 4,920
3 3 7,336
4 4 9,752
5 5 12,176
6 6 0xb8e20 14,592
7 7 0xbc720 17,008
8 8 19,424
9 9 21,848
10 10 0xb5e90 24,264
11 11 26,680
12 12 29,104
13 13 31,520
14 14 33,944
15 15 36,360
16 16 38,784
17 17 41,200
18 18 43,624
19 19 46,040
20 20 48,464
실험 데이터는 0xa0000에서 시작하는 힙의 첫 번째 힙 세그먼트 내에서만 존재하였으며 추가적인 힙 세그먼트 그리고 가상 할당 영역은 사용되지 않았다. 이때 힙 세그먼트 내에 존재하는 힙 블록의 최대 크기는 20번째 단계를 수행한 시점인 48,464Bytes였으며 실험 데이터를 저장하는데 하나의 힙 블록만을 사용했음을 알 수 있다. 마지막 단계를 진행한 후 힙 구조체를 실제로 조사하여 표3의 결과를 확인해보았고 도19로 나타내었다.
두 번째 실험을 진행하는 동안, 본 발명에 따르는 디지털 포렌식을 이용한 플러그인을 통해 데이터가 저장되는 메모리 할당 영역을 조사한 결과를 표4로 나타내었다.
실험 단계 데이터 입력 횟수 힙 주소 힙 세그먼트 주소 힙 블록 주소 힙 블록 크기(Bytes) 가상 할당 영역 주소 가상 할당 영역 크기(Bytes)
1 20 0xa0000 0xa0640 0xc1b10 48,424 - -
2 40 0xd9538 96,808
3 60 0xf0f60 145,208
4 80 0x114698 193,608
5 100 0xcd498 242,008
6 120 0x1503e0 290,440
7 140 0xcd498 338,880
8 160 0xbe0000 0xbe0040 387,320
9 180 0xa0640 0xcd498 435,760
10 200 484,200
11 220 - - - 0xce0000 536,576
12 240 0xd70000 581,632
실험 데이터를 160번 입력하는 단계 8에서 0xbe0000 주소로 시작하는 추가적인 힙 세그먼트가 할당되어 해당 영역으로 실험 데이터가 옮겨졌으며 다음 단계에서 실험 데이터가 기존에 사용되던 힙 세그먼트로 다시 옮겨졌다. 실험 데이터를 220번 입력하는 단계 11부터 가상 할당 영역이 할당되어 해당 영역으로 실험 데이터가 옮겨졌음을 알 수 있다. 힙 세그먼트 및 가상 할당 영역이 할당된 단계에서의 힙 구조체를 실제로 조사하여 이를 확인해보았고 도20, 및 도21로 나타내었다.
본 발명에 따르는 메모리 포렌식을 이용한 인메모리 데이터 추출 플러그인으로 분석하는 과정에서 데이터가 저장된 위치를 알 수 있었으며, 본 발명에 따르는 플러그인을 이용한 메모장 데이터 추출 결과는 표5로 나타내었다.
실험 데이터 입력 횟수 실험 데이터 크기
(Bytes)		 구현한 플러그인을 이용한 데이터 추출 크기(Bytes) 추출 정확도
1 1 1,205 1,205 100%
2 2,414 2,414
3 3,623 3,623
4 4,832 4,832
5 6,041 6,041
6 7,250 7,250
7 8,459 8,459
8 9,668 9,668
9 10,877 10,877
10 12,087 12,087
11 13,297 13,297
12 14,057 14,057
13 15,717 15,717
14 16,927 16,927
15 18,137 18,137
16 19,347 19,347
17 20,557 20,557
18 21,767 21,767
19 22,977 22,977
20 24,187 24,187
2 20 24,187 24,187
40 48,387 48,387
60 72,587 72,587
80 96,787 96,787
100 120,988 120,988
120 145,208 145,208
140 169,428 169,428
160 193,648 193,648
180 217,868 217,868
200 242,088 242,088
220 266,308 266,308
240 290,528 290,528
표5를 통해 실험 1, 실험 2에서 입력 데이터만큼의 데이터를 추출할 수 있음을 확인할 수 있고 100%의 복원율을 보였다.
힙에서의 메모리 할당과 관련한 분석으로 데이터 추출에 필요한 메모리 할당 영역 및 해당 메모리 영역의 변화를 알아보았다. 기존의 플러그인은 유동적인 메모리 할당 방식을 제대로 조사하지 못하여 데이터 추출의 정확도가 상당히 낮았으나, 본 발명에 따르는 플러그인을 통해 높은 정확도의 조사 결과를 가져올 수 있었다.
2) Redis 데이터 추출
다음으로, Redis 데이터 추출 실험에서 덤프 파일 내 Redis 프로세스를 대상으로 구현한 플러그인을 수행하여 메모리 포렌식 기법으로 IMDB의 데이터 추출이 가능한지 알아본다.
Redis는 Key-Value Store로써 저장 데이터를 위해 다섯 가지의 데이터 타입이 존재한다. 본 실험에서는 <키, 값> 쌍을 이루는 가장 단순한 String 데이터 타입을 사용하며 실험 데이터는 표6과 같다.
실험 단계 데이터 개수 데이터
1 10 <key_test1, value_test1> ~ <key_test10, value_test10>
2 2,500 <key_test1, value_test1> ~ <key_test2500, value_test2500>
3 5,000 <key_test1, value_test1> ~ <key_test5000, value_test5000>
4 7,500 <key_test1, value_test1> ~ <key_test7500, value_test7500>
5 10,000 <key_test1, value_test1> ~ <key_test10000, value_test10000>
6 12,500 <key_test1, value_test1> ~ <key_test12500, value_test12500>
7 15,000 <key_test1, value_test1> ~ <key_test15000, value_test15000>
8 17,500 <key_test1, value_test1> ~ <key_test17500, value_test17500>
9 20,000 <key_test1, value_test1> ~ <key_test20000, value_test20000>
10 50,000 <key_test1, value_test1> ~ <key_test50000, value_test50000>
11 100,000 <key_test1, value_test1> ~ <key_test100000, value_test100000>
12 200,000 <key_test1, value_test1> ~ <key_test200000, value_test200000>
총 12번의 단계를 진행하며 각 단계마다 Redis 서버가 표6의 실험 순서에 따른 데이터 개수를 갖도록 Redis 클라이언트에서 데이터를 송신한다. 그리고 단계를 진행하는 동안 vmem 파일을 수집 및 분석한다. 본 발명에 따르는 플러그인을 통해 각 단계마다 데이터가 저장되는 메모리 할당 영역을 조사한 결과를 표7로 나타내었다.
실험 단계 데이터 개수 힙 주소 힙 세그먼트 주소 힙 블록
처음 힙 블록 주소 마지막 힙 블록 주소
1 10 0x3e0000 0x550000 0x5fed68 0x5ff1e8
2 2,500 0x550000 0x5fed68 0x64f340
3 5,000 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x13b1600
4 7,500 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x13ff800
5 10,000 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x1455a00
6 12,500 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x14a3c88
7 15,000 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x14f2000
8 17,500 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x1540200
9 20,000 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x155ffd0
0x1560000 0x1560040 0x158e5e8
10 50,000 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x155ffd0
0x1560000 0x1560040 0x19380d0
11 100,000 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x155ffd0
0x1560000 0x1560040 0x195ffd0
0x1960000 0x1960040 0x1f42ac0
12 200,000 0x550000 0x5fed68 0x64ffd8
0x1360000 0x1360040 0x155ffd0
0x1560000 0x1560040 0x195ffd0
0x1960000 0x1960040 0x215ffd8
0x2270000 0x2270040 0x2c87e50
표 7을 통해 데이터가 증가함에 따라 추가적인 힙 세그먼트를 할당 후 힙 블록만을 사용할 뿐 가상 할당 영역은 사용하지 않는 것을 확인할 수 있었다. 또한 메모장 프로그램과는 다르게 디폴트 힙이 아닌 동적 힙을 사용하는 것으로 파악되었다. 실험 데이터를 5,000개 저장한 시점에서 0x1360000 주소로 시작하는 추가적인 힙 세그먼트가 할당되었다. 실험 데이터를 17,500개 저장할 때까지 힙 세그먼트는 두 개가 이용되었고, 20,000~50,000개 저장한 시점에서 0x1560000 주소로 시작하는 추가적인 힙 세그먼트가 할당되었다. 이후 단계가 진행됨에 따라 0x1960000 주소와 0x2270000 주소로 시작하는 추가적인 힙 세그먼트가 할당되었으며 마지막 단계에서 총 다섯 개의 힙 세그먼트에 실험 데이터가 분산되어 저장되었음을 확인하였다. 마지막 단계를 진행한 후 힙 구조체를 실제로 조사하여 이를 도22로 나타내었다.
도22를 통해 힙에서 사용되는 모든 힙 세그먼트를 조사할 수 있었으며 각각의 힙 세그먼트 정보를 도23으로 나타내었다.
도23을 통해 각각의 힙 세그먼트 정보를 확인할 수 있었고, 0x550000 주소로 시작하는 힙 세그먼트의 경우 해당 영역에 이미 다른 데이터들을 위해 할당된 힙 블록들이 존재하였다. 이러한 이유로 <키, 값> 쌍 데이터가 저장된 힙 블록이 0x5fed68부터 시작되고 있으며 이를 도24로 나타내었다. 그 외의 <키, 값> 쌍 데이터들은 힙 세그먼트의 처음 힙 블록부터 저장되고 있으며 이를 도25 내지 도28로 로 나타내었다.
Redis는 데이터의 관리를 쉽게 하기 위해 String 타입으로 저장된 문자열 데이터를 SDS(Simple Dynamic Strings) 구조로 관리하고, SDS 구조를 관리하기 위해 redisObject를 사용하며 redisObject는 dictEntry 구조를 통해 관리된다[19]. 이러한 구조가 <키, 값>이 저장된 힙 블록과 인접한 영역에 존재하는 것을 확인하였고, 분석을 통해 <키, 값> 쌍의 존재 여부를 검증할 수 있었다. Redis에서 다루는 각각의 구조를 도29로 나타내었으며 실제 메모리의 조사 결과를 도30으로 나타내었다.
구현한 플러그인으로 Redis 실험 단계마다 수집한 vmem 파일을 분석하는 과정에서 데이터가 저장된 위치를 알 수 있었으며 이를 통해 데이터를 추출한 결과를 표8로 나타내었다.
실험 단계 데이터 개수 구현한 플러그인을 이용한 데이터 추출 개수 추출 정확도
1 10 10 100%
2 2,500 2,500
3 5,000 5,000
4 7,500 7,500
5 10,000 10,000
6 12,500 12,500
7 15,000 15,000
8 17,500 17,500
9 20,000 20,000
10 50,000 50,000
11 100,000 100,000
12 200,000 200,000
표8을 통해 Redis에 저장된 모든 <키, 값>쌍의 저장 위치를 확인할 수 있었고, 표 8을 통해 모든 데이터의 복원이 가능했음을 확인할 수 있다.
현재까지의 실험은 실험 데이터를 이미 알고 있었기 때문에 구현한 플러그인으로 추출한 데이터들 내에서 문자열 검색 방법을 통해 데이터가 저장된 위치를 바로 찾을 수 있었다. 그러나 찾고자하는 데이터를 모르는 경우 조사 범위를 직접 확인하면서 데이터를 추출해내야만 한다. 이러한 경우는 기존의 데이터 추출 및 제안하는 데이터 추출 방식 모두에 해당할 수 있으며 조사에 상당한 시간과 노력이 필요하다. 구현한 플러그인을 이용하면 힙이 관리하는 각각의 메모리 영역의 구조를 분석하여 데이터를 추출하므로 기존의 데이터 추출을 위해 사용되는 플러그인을 이용하는 것보다 조사해야 할 메모리 조사 범위를 감소시킬 수 있어서 보다 효율적으로 조사가 가능해진다. 이러한 차이를 알아보기 위해 기존의 플러그인과 구현한 플러그인을 각각 수행하여 조사해야 할 힙의 조사 범위를 표 9, 도31로 나타내었다.
실험 단계 조사 범위
기존 플러그인(MBytes) 구현한 플러그인(MBytes)
1 2.25 0.93
2 2.25 1.24
3 4.25 1.56
4 4.25 1.87
5 4.25 2.20
6 4.25 2.51
7 4.25 2.82
8 4.25 3.12
9 8.25 3.43
10 8.25 7.09
11 16.25 13.13
12 32.25 25.33
기존의 플러그인으로 조사할 경우 전체 힙, 힙 외부에 할당된 힙 세그먼트, 가상 할당 영역의 크기가 조사 범위로 설정되지만, 본 발명에 따르는 플러그인으로 조사할 경우 기존의 플러그인과 동일한 범위 내에서 내부 구조 분석에 의해 특정한 메모리 영역만이 조사 범위에 속하게 되므로 실제 조사 범위가 줄어들었음을 확인할 수 있다. 표 9를 통해 본 발명에 따르는 플러그인의 조사 범위 감소 비율을 계산한 결과는 다음과 같다. 단계 3에서 기존 플러그인 대비 약 63%의 최고 감소 비율을 보였으며 단계 10에서 14%의 최저 감소 비율을 보였다. 이에 따라 데이터 추출에 걸리는 시간 또한 조사 범위 감소 비율에 비례하여 단축될 것이다.
본 발명에 따르는 메모리 포렌식 기법을 이용한 IMDB의 데이터 추출을 위한 플러그인은 기존의 플러그인에서 조사 대상이 특정 응용 프로그램으로 제한되었던 부분을 개선하고, 힙 분석의 필요성을 검증하여 메모리 포렌식을 이용한 IMDB의 데이터 추출을 위해 새롭게 플러그인을 구현하였다. 이를 통한 Redis 분석 실험으로 데이터가 존재하는 메모리 할당 영역 및 해당 메모리 영역의 변화를 알아보았으며 존재하는 데이터를 모두 추출할 수 있었다.
이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로, 본 발명이 속하는 기술분야에서 통상의 지식을 갖는 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 게시된 실시예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이런 실시예에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호범위는 아래의 청구범위에 의하여 해석되어야하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (7)

  1. 메모리 포렌식을 이용한 인메모리 데이터베이스(IMDB)의 데이터 추출 방법으로서,
    인메모리 데이터베이스(IMDB)의 커널 메모리 공간을 조사함에 따라, 프로세스 도중에 유저 메모리 공간에 동적으로 할당되는 메모리 영역인 힙(HEAP)을 조사하는 단계; 및
    데이터가 저장된 위치를 확인하여 데이터를 추출하는 단계를 포함하는
    메모리 포렌식을 이용한 IMDB의 데이터 추출 방법.
  2. 제1항에 있어서,
    조사되는 상기 힙은
    Peb 멤버를 갖는 _EPROCESS 구조체,
    ProcessHeaps 멤버를 갖는 _PEB 구조체,
    힙 정보 및 힙 세그먼트를 조사하기 위한 Signature 멤버, VirtualAllocdBlocks 멤버, Segments 멤버를 갖는 _HEAP 구조체,
    힙 세그먼트 정보 및 힙 블록을 조사하기 위한 Signature 멤버, Heap 멤버, BaseAddress 멤버, FirstEntry 멤버를 갖는 _HEAP_SEGMENT 구조체,
    Entry 멤버, CommitSize 멤버, ReverseSize 멤버를 갖는 _HEAP_VIRTUAL_ALLOC_ENTRY 구조체,
    Size 멤버, PreviousSize 멤버, Flags 멤버, UnusedBytes 멤버, SegmentIndex 멤버를 갖는 _HEAP_ENTRY 구조체를 포함하는
    메모리 포렌식을 이용한 IMDB의 데이터 추출 방법.
  3. 제2항에 있어서,
    상기 _HEAP 구조체의 VirtualAllocdBlocks 멤버가 존재하는 위치에는 힙 블록의 최대 크기를 초과하는 할당 영역의 주소가 저장되고,
    상기 _HEAP 구조체의 Segments 멤버가 존재하는 위치에는 힙 세그먼트들의 주소가 저장되는 것을 특징으로 하는
    메모리 포렌식을 이용한 IMDB의 데이터 추출 방법.
  4. 제2항에 있어서,
    _HEAP_SEGMENT 구조체의 Heap 멤버, BaseAddress 멤버에는 힙 세그먼트가 속한 힙의 주소가 저장되고,
    _HEAP_SEGMENT 구조체의 FirstEntry 멤버에는 현재 힙 세그먼트의 첫 번째 블록의 위치가 저장되는 것을 특징으로 하는
    메모리 포렌식을 이용한 IMDB의 데이터 추출 방법.
  5. 제2항에 있어서,
    HEAP_VIRTUAL_ALLOC_ENTRY 구조체의 Entry 멤버에는 가상 할당 영역을 찾기 위한 주소가 저장되고,
    HEAP_VIRTUAL_ALLOC_ENTRY 구조체의 CommitSize 멤버에는 실제 커밋된 크기가 저장되는 것을 특징으로 하는
    메모리 포렌식을 이용한 IMDB의 데이터 추출 방법.
  6. 제2항에 있어서,
    _HEAP_ENTRY 구조체의 Size 멤버에는 힙 블록의 크기를 힙 할당 단위 8byte로 나눈 값이 저장되어 다음 힙 블록의 시작 위치를 찾을 수 있고,
    _HEAP_ENTRY 구조체의 PreviousSize 멤버에는 이전의 힙 블록 크기를 힙 할당 단위 8byte로 나눈 값이 저장되고,
    _HEAP_ENTRY 구조체의 Flags 멤버에는 힙 블록의 상태가 저장되고,
    _HEAP_ENTRY 구조체의 UnusedBytes 멤버에는 힙 블록의 헤더 크기와 힙 블록 범위에서 사용되지 않는 크기를 더한 값이 저장되고,
    _HEAP_ENTRY 구조체의 SegmentIndex 멤버에는 힙에 속한 힙 세그먼트의 순서가 저장되는 것을 특징으로 하는
    메모리 포렌식을 이용한 IMDB의 데이터 추출 방법.
  7. 제1항에 있어서,
    상기 힙을 조사하는 단계는
    _EPROCESS 구조체의 Peb 멤버를 통해 _PEB 구조체를 조사하는 단계;
    _PEB 구조체의 ProcessHeaps 멤버를 통해 _HEAP 구조체를 조사하는 단계;
    _HEAP 구조체의 Segments 멤버를 통해 _HEAP_SEGMENT 구조체를 조사하는 단계;
    _HEAP 구조체의 VirtualAllocdBlocks 멤버를 통해 _HEAP_VIRTUAL_ALLOC_ENTRY 구조체를 조사하는 단계;
    _HEAP_SEGMENT 구조체의 FirstEntry 멤버를 통해 _HEAP_ENTRY 구조체를 조사하는 단계를 포함하는 것을 특징으로 하는
    메모리 포렌식을 이용한 IMDB의 데이터 추출 방법.
KR1020160149803A 2016-11-10 2016-11-10 메모리 포렌식을 이용한 인메모리 데이터 추출 방법 KR20180052466A (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020160149803A KR20180052466A (ko) 2016-11-10 2016-11-10 메모리 포렌식을 이용한 인메모리 데이터 추출 방법
PCT/KR2016/013076 WO2018088596A1 (ko) 2016-11-10 2016-11-14 메모리 포렌식을 이용한 인메모리 데이터 추출 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020160149803A KR20180052466A (ko) 2016-11-10 2016-11-10 메모리 포렌식을 이용한 인메모리 데이터 추출 방법

Publications (1)

Publication Number Publication Date
KR20180052466A true KR20180052466A (ko) 2018-05-18

Family

ID=62109924

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020160149803A KR20180052466A (ko) 2016-11-10 2016-11-10 메모리 포렌식을 이용한 인메모리 데이터 추출 방법

Country Status (2)

Country Link
KR (1) KR20180052466A (ko)
WO (1) WO2018088596A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10873605B2 (en) 2018-11-05 2020-12-22 Somansa Co., Ltd. System and method for tracking information leakage at endpoint

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2136154C (en) * 1994-11-18 1999-08-24 Jay William Benayon User control of multiple memory heaps
US6499094B1 (en) * 2001-09-14 2002-12-24 Unisys Corporation Management of memory heap space for data files accessible to programs operating in different addressing modes
KR20060033606A (ko) * 2004-10-15 2006-04-19 주식회사 팬택앤큐리텔 힙 메모리 관리장치 및 그 방법
KR100961179B1 (ko) * 2008-06-02 2010-06-09 한국전자통신연구원 디지털 포렌식 방법 및 장치
US8504878B2 (en) * 2010-05-04 2013-08-06 Oracle International Corporation Statistical analysis of heap dynamics for memory leak investigations

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10873605B2 (en) 2018-11-05 2020-12-22 Somansa Co., Ltd. System and method for tracking information leakage at endpoint

Also Published As

Publication number Publication date
WO2018088596A1 (ko) 2018-05-17

Similar Documents

Publication Publication Date Title
US8615500B1 (en) Partial block allocation for file system block compression using virtual block metadata
US7480643B2 (en) System and method for migrating databases
US9665498B2 (en) Memory management using transparent page transformation
EP2778972B1 (en) Shared cache used to provide zero copy memory mapped database
US9875183B2 (en) Method and apparatus for content derived data placement in memory
US9348514B2 (en) Efficiency sets in a distributed system
US10572508B2 (en) Consistent query execution in hybrid DBMS
JP2020502626A (ja) データベース・システムにおけるテスト・データの形成及び動作
US8868576B1 (en) Storing files in a parallel computing system based on user-specified parser function
US10248693B2 (en) Multi-layered row mapping data structure in a database system
US9430503B1 (en) Coalescing transactional same-block writes for virtual block maps
Lee et al. ActiveSort: Efficient external sorting using active SSDs in the MapReduce framework
US10810174B2 (en) Database management system, database server, and database management method
Richard III et al. In lieu of swap: Analyzing compressed RAM in Mac OS X and Linux
CN109783457B (zh) Cgi接口管理方法、装置、计算机设备和存储介质
Amur et al. Design of a write-optimized data store
Cruz et al. A scalable file based data store for forensic analysis
KR20210123236A (ko) 키-값 장치들을 위한 키-값 저장소 아키텍처
Wagner et al. Database image content explorer: Carving data that does not officially exist
US8738669B1 (en) Method and apparatus for providing access to data objects within another data object
Yu et al. Pdfs: Partially dedupped file system for primary workloads
Wust et al. Efficient logging for enterprise workloads on column-oriented in-memory databases
Shen et al. An efficient LSM-tree-based SQLite-like database engine for mobile devices
KR20180052466A (ko) 메모리 포렌식을 이용한 인메모리 데이터 추출 방법
Schuhknecht et al. AnyOLAP: analytical processing of arbitrary data-intensive applications without ETL

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application