KR102028412B1 - SQLite 데이터의 은닉 탐지 시스템 및 방법 - Google Patents

SQLite 데이터의 은닉 탐지 시스템 및 방법 Download PDF

Info

Publication number
KR102028412B1
KR102028412B1 KR1020170141390A KR20170141390A KR102028412B1 KR 102028412 B1 KR102028412 B1 KR 102028412B1 KR 1020170141390 A KR1020170141390 A KR 1020170141390A KR 20170141390 A KR20170141390 A KR 20170141390A KR 102028412 B1 KR102028412 B1 KR 102028412B1
Authority
KR
South Korea
Prior art keywords
page
sqlite
data
concealment
information
Prior art date
Application number
KR1020170141390A
Other languages
English (en)
Other versions
KR20190047467A (ko
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 KR1020170141390A priority Critical patent/KR102028412B1/ko
Publication of KR20190047467A publication Critical patent/KR20190047467A/ko
Application granted granted Critical
Publication of KR102028412B1 publication Critical patent/KR102028412B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/565—Static detection by checking file integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

본 발명은 SQLite 데이터베이스 파일의 은닉이 가능한 파일 헤더, 페이지 및 레코드 영역을 탐색하고, 데이터의 은닉 여부를 판단할 수 있는 SQLite 데이터의 은닉 탐지 시스템 및 방법에 관한 기술로서, SQLite 데이터베이스 파일을 입력받는 입력부와, SQLite 데이터베이스 파일을 파싱하는 파싱부와, 파싱된 SQLite 데이터베이스 파일의 헤더, 페이지 및 레코드의 은닉을 검사하는 변조검사부를 포함하는 것을 특징으로 한다.

Description

SQLite 데이터의 은닉 탐지 시스템 및 방법 {Detection System and Method on SQLite Data Concealing}
본 발명은 SQLite 데이터의 은닉 탐지 시스템 및 방법에 관한 것으로서, 보다 상세하게는 SQLite 데이터베이스 파일의 은닉이 가능한 파일 헤더, 페이지 및 레코드 영역을 탐색하고, 데이터의 은닉 여부를 판단할 수 있는 SQLite 데이터의 은닉 탐지 시스템 및 방법에 관한 기술이다.
데이터베이스란 여러 사람에 의해 공유되어 사용될 목적으로 관리되는 데이터의 집합을 의미한다. 초기 모델은 데이터베이스를 응용프로그램이 조작하는 것이 아닌 데이터베이스를 관리해주는 소프트웨어인 DBMS(database management system)형태로 제공되었다가 키(key)와 값(value)들의 간단한 관계를 테이블화 시킨 RDBMS(relational database management system)형태로 발전하였다. 이후 Oracle, MySQL 등 다양한 데이터베이스를 기반으로 하여 입지를 높였으며, 전 세계적으로 정보화 사회에 없어서는 안 될 중요한 요소 중 하나가 되었다. Oracle과 MySQL 같은 서버 형태의 데이터베이스가 데이터베이스 시장의 주를 이루고 있지만 사물인터넷(IoT, internet of things) 시대가 도래 하면서 임베디드 환경에 적합하며 속도도 준수한 SQLite 데이터베이스가 각광을 받기 시작했다.
현재 SQLite는 스마트폰에 주로 사용된다. 스마트폰 데이터가 급증하게 되면서 데이터를 효율적으로 저장하고 관리해주는 매개체로 데이터베이스가 요구되었는데 이에 적합한 SQLite가 선정되어 이용되고 있다. 그러나 SQLite의 중요도가 높아지는 만큼 이를 이용하는 범죄 행위들이 발생할 가능성이 있는데, SQLite에 대한 은닉이 그 중 하나이다. 예를 들어, 기업에서의 기밀이 유출된 사건에서 범죄자들은 서로 스마트폰을 사용하여 데이터를 주고받았다고 가정해본다면, 범죄자가 PC를 통해 SQLite 데이터베이스 파일 내부에 존재하는 범죄의 단서가 될 수 있는 데이터를 고의적으로 은닉했을 때 은닉된 데이터를 찾을 수 없다.
기존 연구로 이근기 외 2명은 2008 한국방송공학회 학술발표대회 논문 '은닉 데이터베이스 시스템 탐지 방안'에 기존의 데이터베이스가 은닉되어 클라이언트 측에서 데이터를 확인할 수 없을 경우 해당 은닉 시스템을 탐지하는 방안을 제시하였다. 해당 논문에서는 데이터베이스와 관련된 실제 수사 현장에서 수사관과 조직의 협조 여부에 따라 시나리오를 각각 구분하여 제시한다. 먼저, 수사관과 조직의 협조가 양호한 경우, 형식적으로만 협조하고 정확히 알려주지 않는 경우, 예고치 않은 수사를 실시하여 비협조 하는 경우, 고의적으로 비협조 하는 경우로 나누어 대응 상황을 고려해볼 수 있다. 수사에 비협조적인 두 가지 경우에서는 데이터베이스의 은닉을 의심해볼 수 있는데, 한 사례로 은닉의 경우에 데이터베이스 시스템에는 접근이 불가능하게 되지만 웹 서버와 같은 기타 서버 시스템에는 문제없이 접근할 수 있는 경우도 있다. 또 다른 사례로는 특정 클라이언트만 접근을 허용하여 해당 데이터베이스를 은닉하는 시스템이 존재할 수 있다. 만약 해당 데이터베이스에 대한 접근 자체를 막게 된다면 무언가 중요한 데이터가 존재할 가능성이 조명될 수 있기 때문에, 접근 자체를 막기 보다는 소수 클라이언트에게만 접근을 허용하는 기법을 선호한다.
데이터베이스를 은닉하는 시스템을 탐지하는 방안으로는 데이터베이스 사용 흔적 수집 기법과 ADO(ActiveX Data Object)를 이용한 데이터베이스 서버 탐지 기법을 제안하였다. 데이터베이스 사용에 대한 흔적은 데이터베이스 파일, 레지스트리, 로그분석을 통하여 정보를 수집할 수 있으며, 각각의 방법에 대하여 사용되는 몇 가지 툴을 제안하여 효율적인 모니터링 기법을 제안하였다. Microsoft에서는 다양한 데이터베이스에 대해 공통적으로 데이터베이스와 연결될 수 있는 객체 지향 인터페이스인 ADO를 개발하여 배포하였다. ADO 기술을 이용하게 될 경우 데이터베이스의 종류에 구애 받지 않고 데이터에 접근하는 프로그램을 구현하는 것이 가능하다.
기존 데이터베이스 데이터 은닉과 관련된 연구는 데이터베이스 시스템을 대상으로 하는 데이터 은닉과 이에 대한 대응을 다루고 있다. 그러나 기존 연구의 결과로는 데이터베이스 파일 자체에 은닉되어 있는 데이터에 대해서 탐지가 불가능하다.
한편, SQLite는 모바일 기기에서 대부분의 애플리케이션 데이터 저장을 위하여 사용된다. 규모가 큰 시스템에서 사용되는 MySQL이나 Oracle과 같은 데이터베이스에 비해 작업량이 적으며, 데이터 저장 시 단일 파일만을 사용하기 때문에 데이터베이스 파일의 구조가 상대적으로 단조롭다.
SQLite 데이터베이스 파일의 구조는 도 1과 같은 형태로 나타낼 수 있다. SQLite 데이터베이스 파일은 페이지라는 저장단위로 구성되어 있으며, 각 페이지는 일정한 크기를 가지고 있다. 가장 처음 위치하는 페이지는 헤더 페이지이고, 이후 페이지들은 B-트리 구조로 구성된다. 헤더 페이지는 SQLite 전용 데이터베이스 파일임을 구분할 수 있는 시그니처와 페이지 크기, 데이터베이스 파일 크기 등 SQLite 데이터베이스 파일에 관련된 메타데이터가 존재하는 영역이다. 헤더 페이지 내부의 하위 부분에는 데이터베이스의 스키마에 대한 정보를 포함하고 있는 스키마 테이블이 존재한다. 스키마 테이블에는 테이블 이름, 필드의 타입, 이름, 개수, 변수 타입에 대한 정보가 들어있으며 각 테이블과 연관된 데이터 정보가 존재하기 때문에 GUI 뷰어에서 보여주는 테이블의 데이터와 매칭되는지 파악하는 중요한 지표가 된다. 특히 변형된 B-트리 구조에서 노드들의 시작이 되는 루트 페이지 번호를 SQL 쿼리문 바로 앞에 포함하고 있다.
오프셋 사이즈 내용(Description)
0x0 16 Header Signature
0x10 2 Page Size
0x12 1 Write Ver
0x13 1 Read Ver
0x14 1 0
0x15 1 64
0x16 1 32
0x17 1 32
0x18 4 File Change Counter
0x1c 4 Size of database file in pages
0x20 4 Page number of first freelist page
0x24 4 Total number of freelist pages
0x28 4 Schema Cookie
0x2c 4 Schema foramt number (1, 2, 3, 4)
0x30 4 Default page cache size
0x34 4 The largest root b-tree page number when in auto-vacuum or incremental-vacuum modes
0x38 4 Database text encoding
0x3c 4 User Version
0x40 4 True for incremental-vacuum mode
0x44 4 Application ID
0x48 20 Reserved for expansion (0)
0x5c 4 Version-valid-for number
0x60 4 SQLite version number
표 1은 SQLite 데이터베이스 파일 내부 헤더 영역을 나타낸 표이다. 총 100바이트로 구성되어 있으며 오프셋 0x00에서 시그니처를 시작으로 주요 메타데이터 정보를 포함하고 있다.
SQLite 파일의 경우에는 정해져 있는 확장자가 없기 때문에 SQLite 전용 데이터베이스 파일인지의 여부를 알기 위해서는 헤더부분의 시그니처인 'SQLite format 3' 문구를 확인하는 작업이 필요하다. SQLite는 고정된 크기를 사용하는 페이지 구조이기 때문에 분석하는데 간편하다는 장점이 있고 페이지의 크기는 오프셋 0x10에 2바이트 크기의 빅 엔디안 형식으로 나타나 있다. 오프셋 0x1C에는 데이터베이스 파일의 크기가 4KB 단위로 명시되어 있다. SQLite의 구조가 페이지 단위로 구성되어 있기 때문에 데이터베이스 파일의 값은 페이지 용량의 배수로 표현이 가능하다. 오프셋 0x20과 0x24에는 첫 번째 프리리스트(freelist) 페이지의 페이지 번호와 전체 프리리스트(freelist) 페이지의 개수를 각각 4바이트씩 나타내고 있다. 프리리스트(freelist) 페이지는 사용되지 않는 페이지가 프리리스트(freelist)에 저장이 되었다가 추후 데이터를 위한 부가적인 페이지가 필요해질 경우 재사용되는 페이지이다. 그 이외에도 스키마 쿠키(Schema cookie), 페이지 캐쉬(page cache) 크기. 데이터베이스 문자 인코딩(Database text encoding) 버전 등 데이터베이스 파일을 구성하는데 필요한 데이터가 수록되어 있다.
Offset Size Description
0x0 1 Page type
0x1 2 First free block offset
0x3 2 Number of cells
0x5 2 Cell content area offset
0x7 1 Fragment byte number
0x8 Cellnum * 2 Cell pointer
SQLite를 구성하고 있는 페이지는 각 내부에 데이터를 포함하고 있다. 표 2는 페이지 헤더의 정보를 나타내고 있다. 페이지에서는 셀이라는 작은 저장단위에 데이터를 저장하고 있으며 맨 처음 위치하는 영역은 해당 페이지의 헤더 부분으로써 페이지에 대한 메타데이터를 포함하고 있다. 페이지의 첫 바이트에는 타입 값이 위치한다.
Type Value
interior index b-tree page 0x02
interior table b-tree page 0x05
leaf index b-tree page 0x0a
leaf table b-tree page 0x0d
표 3을 참조하면, 파일 타입은 1바이트 값이며 인테리어 인덱스/테이블(interior index/table) 페이지, 리프 인덱스/테이블(leaf index/table) 페이지를 구분하는 기준이 된다. 인덱스(index) 페이지란 페이지 내부에 실제 데이터가 아닌 데이터와 연관된 키(key) 값들을 저장해 놓는 페이지이며, 테이블(table) 페이지는 실제 데이터를 포함하는 페이지이다. 오프셋 0x01에는 첫 번째 프리블록(free block)에 대한 오프셋이 포함되어 있어서 데이터에 연관되지 않은 영역이 시작되는 부분을 알 수 있다. 오프셋 0x03에서는 해당 페이지의 셀의 개수를 나타내고 있으며 오프셋 0x05에 처음으로 셀 데이터가 시작되는 위치를 2바이트 빅 엔디안 형태로 나타낸다. 도 2는 첫 번째 프리블록(free block)과 처음 시작되는 셀 데이터의 위치를 나타난 그림이다. 오프셋 0x08부터 각 셀의 위치를 가리키는 포인터가 각각 2바이트 씩 연속적으로 저장되어 있다. 이 영역은 셀의 개수에 따라 길이가 유동적으로 변할 수 있는 영역이기 때문에 (셀의 개수 * 2) 가변적인 크기를 갖는 영역이다. 페이지의 데이터 영역에 위치하는 레코드는 가장 처음 들어온 레코드가 페이지 맨 밑의 영역부터 쌓이게 되는 구조로 이루어져 있으며, 셀 포인터와 셀 데이터 사이는 빈 공간으로 이루어져 있다.
도 3은 변형된 B-트리 구조를 가진 SQLite 데이터베이스 파일의 데이터 참조 과정을 나타낸 그림이다. 헤더 페이지의 스키마 테이블 영역에 존재하는 루트 노드를 기점으로 하위 노드를 참조하여 데이터를 찾아가는 일반적인 트리구조 형태를 지니고 있다. 가장 하위에 위치하는 노드는 리프(leaf) 노드이며, 리프(leaf) 노드에는 실제 데이터가 저장이 된다. 루트 노드와 리프(leaf) 노드 사이에 존재하는 페이지들을 인테리어(interior) 페이지라고 하며 내부에는 하위 노드를 가리키는 4바이트 빅 엔디안 형태의 포인터와 2바이트 빅 엔디안 형태의 키 값이 인접하여 저장된다.
테이블 내에 쿼리를 통해 삽입된 여러 레코드들의 데이터양이 단일 페이지의 용량을 넘지 않는다면 레코드 데이터는 리프(leaf) 페이지 하나에 저장이 되지만, 만약 레코드 데이터가 단일 페이지의 용량을 초과할 경우 다수의 연속된 리프(leaf) 페이지로 나누어 데이터를 저장한 뒤, 인테리어(interior) 페이지 내부에 포인터를 저장하고 나누어진 리프(leaf) 페이지들을 참조하는 방식으로 구성된다. 각 페이지들은 고정된 크기로 존재하기 때문에 시작 오프셋이 페이지의 크기 단위로 나타난다. 따라서 포인터를 참조하여 하위노드에 접근할 때는 포인터가 가리키는 번호에 해당하는 오프셋으로 접근해야 한다.
한국등록특허공보 10-1681054 : SQL 변조 공격을 감지하기 위한 자동 학습 방법 및 시스템
이에 본 발명은 상기와 같은 종래의 제반 문제점을 해소하기 위해 제안된 것으로, 본 발명의 목적은 SQLite 데이터베이스 파일의 은닉이 가능한 파일 헤더, 페이지 및 레코드 영역을 탐색하고, 데이터의 은닉 여부를 판단할 수 있는 SQLite 데이터의 은닉 탐지 시스템 및 방법을 제공하기 위한 것이다.
상기와 같은 목적을 달성하기 위하여 본 발명의 기술적 사상에 의한 SQLite 데이터의 은닉 탐지 시스템은, SQLite 데이터베이스 파일을 입력받는 입력부와, 상기 SQLite 데이터베이스 파일을 파싱하는 파싱부와, 파싱된 상기 SQLite 데이터베이스 파일의 헤더, 페이지 및 레코드의 은닉을 검사하는 변조검사부를 포함하는 것을 특징으로 한다.
또한, 상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 은닉되어도 SQLite 구동 시 오류가 발생되지 않는 영역을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 메타데이터 영역의 은닉을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 변조검사부는 상기 SQLite 데이터베이스 파일의 헤더 영역 중 파일변경횟수 정보, 버전 정보, 스키마 정보, 프리리스트 정보, 페이지캐쉬크기 정보, b트리페이지번호 정보, 증분베큠모드 정보, 응용프로그램아이디 정보, 확장예약영역 중 적어도 어느 하나를 대상으로 은닉을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 파싱부는 SQL 쿼리문의 루트 노드 관련 인덱스 및 페이지 번호를 파싱하고, 상기 변조검사부는 상기 루트 노드 관련 인덱스와 상기 페이지 번호를 대비하는 것으로 페이지의 은닉을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 파싱부는 리프(leaf) 페이지, 포인터 페이지 및 상기 포인터 페이지에 대응되는 상기 페이지 번호를 파싱하는 것을 특징으로 할 수 있다.
또한, 상기 파싱부는 페이지의 헤더에서 셀(cell)의 개수 데이터 및 셀 지시 포인터의 개수를 파싱하고, 상기 변조검사부는 상기 셀의 개수 데이터와 상기 셀 지시 포인터의 개수를 대비하는 것으로 은닉을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 파싱부는 페이지의 레코드를 파싱하고, 상기 변조검사부는 상기 레코드의 수와 상기 셀의 개수 데이터를 대비하는 것으로 은닉을 검사하는 것을 특징으로 할 수 있다.
한편, 상기와 같은 목적을 달성하기 위하여 본 발명의 기술적 사상에 의한 SQLite 데이터의 은닉 탐지 방법은, (A)입력부가 SQLite 데이터베이스 파일을 입력받는 단계, (B)파싱부가 상기 SQLite 데이터베이스 파일을 파싱하는 단계, (C)변조검사부가 파싱된 상기 SQLite 데이터베이스 파일의 헤더, 페이지 및 레코드의 은닉을 검사하는 단계를 포함하는 것을 특징으로 한다.
또한, 상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 은닉되어도 SQLite 구동 시 오류가 발생되지 않는 영역을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 메타데이터 영역의 은닉을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 변조검사부는 상기 SQLite 데이터베이스 파일의 헤더 영역 중 파일변경횟수 정보, 버전 정보, 스키마 정보, 프리리스트 정보, 페이지캐쉬크기 정보, b트리페이지번호 정보, 증분베큠모드 정보, 응용프로그램아이디 정보, 확장예약영역 중 적어도 어느 하나를 대상으로 은닉을 검사하는 것을 특징으로 할 수 있다.
또한, 상기 (B)단계는 상기 파싱부가 SQL 쿼리문의 루트 노드 관련 인덱스 및 페이지 번호를 파싱하는 단계를 포함하고, 상기 (C)단계는 상기 변조검사부가 상기 루트 노드 관련 인덱스와 상기 페이지 번호를 대비하는 것으로 페이지의 은닉을 검사하는 단계를 포함하는 것을 특징으로 할 수 있다.
또한, 상기 파싱부가 SQL 쿼리문의 루트 노드 관련 인덱스 및 페이지 번호를 파싱하는 단계의 상기 파싱부는 리프(leaf) 페이지, 포인터 페이지 및 상기 포인터 페이지에 대응되는 상기 페이지 번호를 파싱하는 것을 특징으로 할 수 있다.
또한, 상기 (B)단계는 상기 파싱부가 페이지의 헤더에서 셀(cell)의 개수 데이터 및 셀 지시 포인터의 개수를 파싱하는 단계를 포함하고, 상기 (C)단계는 상기 변조검사부가 상기 셀의 개수 데이터와 상기 셀 지시 포인터의 개수를 대비하는 것으로 은닉을 검사하는 단계를 포함하는 것을 특징으로 할 수 있다.
또한, 상기 (B)단계는 상기 파싱부가 페이지의 헤더에서 셀(cell)의 개수 데이터 및 상기 페이지의 레코드를 파싱하는 단계를 포함하고, 상기 (C)단계는 상기 변조검사부가 상기 레코드의 수와 상기 셀의 개수 데이터를 대비하는 것으로 은닉을 검사하는 단계를 포함하는 것을 특징으로 할 수 있다.
본 발명에 의한 SQLite 데이터의 은닉 탐지 시스템 및 방법에 따르면 아래와 같은 효과가 있다.
첫째, 종래에는 수사현장에서 압수 수색 영장을 받고 데이터베이스를 압수하여 분석할 때 데이터가 뷰어에서는 보이지 않게 은닉이 되었다면, 은닉의 진위를 판단하는 것이 쉽지 않았으나, 본 발명은 데이터베이스 자체에서 은닉의 여부를 판단할 수 없을 때 직접 내부 데이터를 이미징 하여 파일에 대한 데이터를 일일이 분석이 가능하게 하여 데이터의 은닉을 탐지할 수 있게 한다.
둘째, 현재까지 SQLite 데이터베이스 파일에 대한 은닉 탐지에 관한 연구가 되어있지 않기 때문에 본 발명을 SQLite와 관련된 사건에 활용할 수 있게 된다.
셋째, 본 발명은 데이터베이스 파일이 법정에서 효력을 발휘하기 위한 증거로써 활용되기 위해 은닉의 여부를 나타내는 기능과 은닉이 탐지된 부분의 영역을 표시해주는 기능, 그리고 해당 데이터베이스의 메타데이터 영역을 파싱하여 데이터베이스에 대한 정보도 같이 보여주는 것이 가능하기 때문에 SQLite 관련 포렌식에 도움이 된다.
도 1은 SQLite 데이터베이스 파일의 구조를 개략적으로 나타낸 도면.
도 2는 첫 번째 프리블록 및 셀 내용 영역을 나타낸 도면.
도 3은 SQLite 데이터베이스 파일의 B-트리 구조를 나타낸 도면.
도 4는 인위적인 페이지가 첨가된 데이터를 예시적으로 나타낸 도면.
도 5는 SQLite 데이터베이스 파일에서 레코드의 정상 조회 결과(상단)와 셀의 개수 데이터를 변조하여 레코드가 은닉된 결과(하단)을 나타낸 도면.
도 6은 본 발명의 일 실시예에 따른 SQLite 데이터의 은닉 탐지 시스템의 구성도.
도 7은 루트 노드 페이지 인덱스를 나타낸 도면.
도 8은 본 발명의 일 실시예에 따른 SQLite 데이터의 은닉 탐지 방법의 순서도.
첨부한 도면을 참조하여 본 발명의 실시예들에 의한 SQLite 데이터의 은닉 탐지 시스템 및 방법에 대하여 상세히 설명한다. 본 발명은 다양한 변경을 가할 수 있고 여러 가지 형태를 가질 수 있는바, 특정 실시예들을 도면에 예시하고 본문에 상세하게 설명하고자 한다. 그러나 이는 본 발명을 특정한 개시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.
또한, 다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
또한, 은닉이란 본래의 원본 데이터를 수정, 삭제 및 추가함으로써, 원본 데이터가 정상적으로 조회되지 않게 감추는 행위에 더하여, 임의로 추가된 데이터가 함께 로드되게 하는 행위를 포괄한다.
먼저, 데이터 은닉을 위해 특정 메타데이터 영역(바이너리)에 변화를 주었을 때 발생하는 데이터베이스 파일 내부 데이터의 변화를 검토한다. 내부 데이터를 은닉하기 위해서는 관리자 등급의 권한이 필요하지만 이 실시예는 전제조건이 모두 갖추어져 있다고 가정한다. 이 실시예는 데이터베이스 파일 내부 레코드를 가시적으로 볼 수 있는 GUI 기반의 도구로 SQLite Expert Personal 3, SysTools SQLite Database Recovery, DB Browser for SQLite를 사용하였고, 바이너리 데이터 은닉을 위한 도구로 010 Editor를 이용하였으며, 실험대상파일은 SQLite가 탑재된 안드로이드 모바일 기기에 저장되어있는 데이터베이스 파일을 사용하였다.
SQLite 데이터베이스 파일의 메타데이터로는 헤더 페이지의 상위 100바이트 존재하는 데이터베이스 파일 헤더 영역, 테이블의 루트 노드가 존재하는 스키마 테이블 영역, 각 페이지마다 맨 처음 위치하고 있는 영역인 페이지 헤더 영역이 존재한다. SQLite 메타데이터는 SQLite의 전체 구성 정보를 담고 있는 데이터이며, 실제 데이터를 소유하고 있는 레코드의 저장 메커니즘이 존재한다. 따라서 메타데이터 영역에서 구성정보에 변화를 가한다면 내부 레코드를 은닉할 수 있는 가능성이 있다.
SQLite의 구조를 바탕으로 모든 메타데이터 영역의 바이너리 데이터에 변화를 준 결과, 특정 영역을 변경할 경우 애플리케이션에서 데이터베이스 파일로 인식하지 못하게 되는 경우가 발생하게 됨을 발견하였다. 이 때 경고 메시지가 팝업, 즉 오류가 발생된다.
실제 수사에서 데이터베이스 파일을 열었을 때 정상적인 파일로 인식되지 않는다면, 범죄자 입장에서는 파일 자체에 임의의 변화를 가했다는 사실이 쉽게 노출될 수 있기 때문에 오류가 발생되는 영역을 은닉할 영역으로 타겟팅하지 않을 것이다. 따라서 데이터베이스 파일 메타데이터의 각 영역을 인위적으로 변경하였을 때 올바른 데이터베이스 파일로 인식이 되는지에 대한 여부는 추후 은닉 여부를 의미하는 지표가 될 수 있다. 또한 이러한 사실을 바탕으로 애플리케이션 탐지를 우회하는 영역에 대해서는 고의적인 데이터의 저장 공간으로 사용이 가능하다는 것을 알 수 있다.
오프셋 내용(Description) 은닉가능여부
0x0 ~ f Header Signature -
0x10 ~ 11 Page Size -
0x12 Write Ver O
0x13 Read Ver O
0x14 0 -
0x15 64 -
0x16 32 -
0x17 32 -
0x18 ~ 1b File Change Counter O
0x1c ~ 1f Size of database file in pages -
0x20 ~ 23 Page number of first freelist page O
0x24 ~ 27 Total number of freelist pages O
0x28 ~ 2b Schema Cookie O
0x2c ~ 2f Schema foramt number (1, 2, 3, 4) O
0x30 ~ 33 Default page cache size O
0x34 ~ 37 The largest root b-tree page number when in auto-vacuum or incremental-vacuum modes O
0x38 ~ 3b Database text encoding -
0x3c ~ 3f User Version O
0x40 ~ 43 True for incremental-vacuum mode O
0x44 ~ 47 Application ID O
0x48 ~ 5b Reserved for expansion (0) O
0x5c ~ 5f Version-valid-for number O
0x60 ~ 63 SQLite version number O
표 4는 데이터베이스 파일 헤더의 메타데이터 영역에 접근하여 인위적인 데이터를 숨겼을 때 영역별로 은닉이 가능한지에 대한 여부를 나타낸 것이다. 시그니처, 페이지 크기, 데이터베이스 파일 크기 등 'O' 표시된 부분에 데이터를 수정, 추가, 삭제 등의 변조를 할 경우, 기존 애플리케이션에서 탐지되지 않고 데이터를 은닉하는 것이 가능하다. 인위적인 데이터를 받아들이지 못하고 애플리케이션에 의해 파일이 인식되지 않는, 즉 오류가 발생되는 영역은 '-'로 표시하였다. 표 4에서 애플리케이션 탐지를 우회할 수 있는 부분을 모두 합한 파일 헤드 영역의 크기는 총 70바이트이므로 범죄자는 70바이트만큼 데이터를 숨길 공간을 획득하게 된다. 해당 공간에 고의적으로 URL이나 스마트폰 번호, 짧은 메시지 등을 담아서 전송에 사용한다면 70바이트 내에서 통신 교환이 가능하기 때문에 해당 공간은 얼마든지 악의적인 용도로 공유되는 공간이 될 수 있다.
한편, 스키마 테이블의 SQL 쿼리문 바로 앞에는 루트 페이지 번호를 나타내는 인덱스 값이 존재한다. 해당 값을 변경하여 다른 페이지를 참조하게 하면, 변경된 값과 상응하는 페이지와 매칭되는 테이블 정보가 나타난다. 이러한 방식으로 범죄자는 인위적인 페이지를 추가한 뒤 인덱스를 변경하여 기존의 페이지를 은닉하는 행위를 시도할 가능성이 있다. 인위적으로 페이지를 생성할 경우, 생성된 페이지의 크기만큼 데이터베이스 파일의 크기가 증가되므로 헤더영역의 데이터베이스 크기 영역을 추가한 페이지의 용량만큼 더해주면 뷰어에 정상적으로 인식 된다. 도 4는 인위적인 페이지를 첨가하고 참조하였을 때 기존의 페이지가 은닉되어 인위적인 페이지의 데이터가 나타나는 현상을 캡처한 예시이다. 해당 그림에서 'last_message' 필드의 값을 인위적으로 생성한 페이지를 참조 했을 때 정상적인 데이터로 인식되어 기존 페이지가 은닉되는 현상이 나타났다.
또한, 페이지마다 실제 레코드를 담고 있는 셀의 개수, 셀의 위치를 가리키는 포인터, 처음 레코드가 위치하는 영역의 오프셋 주소 등이 존재하는 페이지 헤더영역이 존재한다. 오프셋 0x03에 위치하고 있는 셀의 개수는 해당 페이지 내부에 들어있는 셀의 개수를 의미한다. 해당 값을 변경하였을 경우, 실제 데이터는 그대로 존재하지만 조회되는 레코드의 개수가 변경된다. 도 5의 상단의 그림은 페이지의 헤더 부분에서 셀의 개수 영역을 변경시키기 전 조회되는 정상 레코드이고, 하단은 변경하고 난 후 조회되는 비정상 레코드이다. 레코드의 개수가 4개였던 기존의 테이블에서 셀의 개수를 3개로 변경하였을 때 가장 나중에 삽입된 레코드부터 조회되지 않는 현상이 발생했다. 또한, 셀 포인터 영역에서 각각의 포인터의 순서를 변경했을 때 레코드의 순서 또한 변경이 가능했고, 특정 레코드의 포인터를 삭제했을 때 해당 레코드를 은닉하는 행위도 가능했다.
수사현장에서 획득한 데이터베이스 파일에 은닉이 감행되면 이에 대응하기 위한 탐지 방안이 필요하다. 본 발명의 일 실시예는 표 4의 은닉가능여부가 'O'인 영역이 아닌 부분에 범죄자가 은닉을 시도하였다면, 애플리케이션에서 은닉행위가 탐지되어 고의적으로 변조하였다는 것이 쉽게 발각되기 때문에 애플리케이션의 탐지를 우회하는 파일에 대해서만 탐지하는 것을 특징으로 한다.
SQLite에서 은닉된 데이터를 탐지할 때는 우선 데이터베이스 파일의 헤더 부분에서 페이지의 크기를 알아내는 것이 중요하다. 그 후, 페이지의 단위 크기만큼 데이터를 읽어 들이고 탐색 하면서 내부 데이터에 대한 은닉 여부 조사를 실시한다.
도 6을 참조하면, 본 발명의 일 실시예에 따른 SQLite 데이터의 은닉 탐지 시스템(100)은 SQLite 데이터베이스 파일을 입력받는 입력부(120)와, SQLite 데이터베이스 파일을 파싱하는 파싱부(140)와, 파싱된 상기 SQLite 데이터베이스 파일의 헤더, 페이지 및 레코드의 은닉을 검사하는 변조검사부(160)를 포함한다.
앞서, 데이터베이스 헤더영역에 70바이트만큼의 데이터를 은닉할 수 있는 것으로 확인되었다. 상기 70바이트 영역에서는 데이터가 은닉되어도 애플리케이션에 의한 SQLite 구동 시 오류가 발생되지 않기 때문에 파싱부(140)는 파일 헤더 영역(100바이트)을 파싱하고, 변조검사부(160)는 상기 70바이트 영역 내에서 은닉을 검사한다.
특히, 변조검사부(160)는 SQLite 데이터베이스 파일의 헤더 영역 중 파일변경횟수 정보, 버전 정보, 스키마 정보, 프리리스트 정보, 페이지캐쉬크기 정보, b트리페이지번호 정보, 증분베큠모드 정보, 응용프로그램아이디 정보, 확장예약영역 중 적어도 어느 하나를 대상으로 은닉을 검사할 수 있다. 표 4를 참조하면, 파일의 헤더 영역 중 파일변경횟수 정보에 대응되는 오프셋은 0x18 내지 0x1b이다. 버전 정보에 대응되는 오프셋은 0x12, 0x13, 0x3c 내지 0x3f, 0x5c 내지 0x5f, 0x60 내지 0x63이다. 스키마 정보에 대응되는 오프셋은 0x28 내지 0x2b, 0x2c 내지 0x2f이다. 프리리스트 정보에 대응되는 오프셋은 0x20 내지 0x23, 0x24 내지 0x27이다. 페이지캐쉬크기 정보에 대응되는 오프셋은 0x30 내지 0x33이다. b트리페이지번호 정보에 대응되는 오프셋은 0x34 내지 0x37이다. 증분베큠모드 정보에 대응되는 오프셋은 0x40 내지 0x43이다. 응용프로그램아이디 정보에 대응되는 오프셋은 0x44 내지 0x47이다. 확장예약영역에 대응되는 오프셋은 0x48 내지 0x5b이다.
한편, 본 발명의 일 실시예에 따른 SQLite 데이터의 은닉 탐지 시스템(100)의 파싱부(140)는 SQL 쿼리문의 루트 노드 관련 인덱스 및 페이지 번호를 파싱하고, 변조검사부(160)는 루트 노드 관련 인덱스와 페이지 번호를 대비하는 것으로 페이지의 은닉을 검사한다.
도 7은 SQL 쿼리문 영역 앞의 루트 노드와 그에 대응되는 테이블을 나타낸 그림이다. 해당 테이블의 고유 인덱스를 은닉하여 다른 테이블을 참조하게 하는 것만으로도 데이터를 은닉하는 작업이 가능하다. 만약 같은 필드를 지닌 테이블이 참조 되면 기존 테이블 데이터의 은닉 여부를 판별하기 쉽지 않지만, 이미 존재하고 있는 다른 테이블을 참조하면 페이지 인덱스가 중복될 가능성이 있기 때문에 변조검사부(160)는 같은 인덱스가 반복이 되고 있는지 확인한다.
반복되는 페이지가 없다면 페이지를 인위적으로 생성하여 데이터 은닉을 시도하는 경우를 고려할 수 있다. 이 경우 파싱부(140)는 모든 데이터를 페이지 크기의 단위로 읽어 들이고, 변조검사부(160)는 페이지와 인덱스를 각각 매칭시키면서 일대일 대응이 되는지 확인한다.
한편, 레코드 은닉의 탐지를 위해, 인덱스를 참조하여 테이블의 내부 데이터 영역에 접근한 후 셀 데이터의 은닉 여부를 판단한다. 먼저 파싱부(140)는 리프(leaf) 페이지, 포인터 페이지 및 포인터 페이지에 대응되는 페이지 번호를 파싱한다. 즉, 페이지 타입의 파싱으로 변조검사부(160)는 0x0D의 값을 가지는 페이지인 리프(leaf) 페이지와 0x05의 경우인 인테리어(interior) 페이지를 타깃으로 하여 실제 데이터의 은닉 여부를 확인한다. 인테리어(interior) 페이지의 경우에는 페이지 내부에 존재하는 포인터를 참조하여 리프(leaf) 페이지로 접근한 뒤 셀 데이터의 은닉 탐지를 시작한다.
또한, 파싱부(140)는 페이지의 헤더에서 셀(cell)의 개수 데이터 및 셀 지시 포인터의 개수를 파싱하고, 변조검사부(160)는 셀의 개수 데이터와 셀 지시 포인터의 개수를 대비하는 것으로 은닉을 검사한다.
리프(leaf) 페이지에서 은닉의 대상이 되는 영역 중 하나는 각 페이지의 오프셋 0x03에 해당하는 셀의 개수이다. 오프셋 0x08에서는 셀 지시 포인터가 연속적으로 존재하고 있는데 셀의 개수와 셀 지시 포인터의 개수가 서로 상이하면 고의적으로 은닉이 시도된 것으로 판단할 수 있다.
다만, 셀의 개수와 셀 포인터의 개수가 같다고 할지라도 두 부분에 대한 은닉을 동시에 시도했을 가능성도 배제할 수 없다. 따라서 내부 셀 데이터가 셀의 개수만큼 존재하는지 확인하는 작업이 필요하고, 각 레코드를 구분 짓는 구분자를 조사하여 레코드 개수를 파악해야한다. 이러한 파악을 위해, 파싱부(140)는 페이지의 레코드를 파싱하고, 변조검사부(160)는 레코드의 수와 셀의 개수 데이터를 대비하는 것으로 은닉을 검사한다.
또한, 테이블 마다 레코드를 구분 짓는 구분자가 각각 상이하기 때문에 페이지마다 구분자를 확인하는 작업도 실시할 수 있다.
상기 탐지과정이 모두 진행되었을 때 아무런 은닉의 흔적이 발견되지 않았다면 원본 파일이라고 판단한 후 탐지를 종료한다.
이어서, 본 발명의 일 실시예에 따른 SQLite 데이터의 은닉 탐지 방법을 설명한다.
도 8을 참조하면, 본 발명의 일 실시예에 따른 SQLite 데이터의 은닉 탐지 방법은 입력부(120)가 SQLite 데이터베이스 파일을 입력받는 단계(S100)와, 파싱부(140)가 SQLite 데이터베이스 파일을 파싱하는 단계와, 변조검사부(160)가 파싱된 SQLite 데이터베이스 파일의 헤더, 페이지 및 레코드의 은닉을 검사하는 단계를 포함한다.
이 실시예의 변조검사부(160)는 SQLite 데이터베이스 파일 중 은닉되어도 SQLite 구동 시 오류가 발생되지 않는 영역을 검사하는 것을 특징으로 한다.
또한, 변조검사부(160)는 SQLite 데이터베이스 파일 중 메타데이터 영역의 은닉을 검사하는 것을 특징으로 한다.
파싱부(140)가 SQLite 데이터베이스 파일을 파싱하는 단계와, 변조검사부(160)가 파싱된 SQLite 데이터베이스 파일의 은닉을 검사하는 단계는 파일의 헤더, 페이지, 레코드의 은닉을 검사하는 과정에서 반복될 수 있다.
먼저, 파일의 헤더 검사를 위해, 파싱부(140)가 SQLite 데이터베이스 파일을 파싱하는 단계는 파싱부(140)가 SQLite 데이터베이스 파일의 헤더를 파싱하는 단계(S220)를 포함하고, 변조검사부(160)가 파싱된 SQLite 데이터베이스 파일의 은닉을 검사하는 단계는 변조검사부(160)가 SQLite 데이터베이스 파일의 헤더 영역 중 파일변경횟수 정보, 버전 정보, 스키마 정보, 프리리스트 정보, 페이지캐쉬크기 정보, b트리페이지번호 정보, 증분베큠모드 정보, 응용프로그램아이디 정보, 확장예약영역 중 적어도 어느 하나를 대상으로 은닉을 검사하는 단계(S240)를 포함한다. S240 단계에서 검사되는 파일 헤더의 정보는 일반적으로 일정하게 정해진 값을 가지는 정보가 대다수이므로 해당 정보를 조회하는 것만으로도 용이하게 은닉을 식별할 수 있다. 변조검사부(160)는 상기 정보 중 정상적이지 않은 값을 가진 정보가 발견되면 파일의 헤더에 은닉 데이터가 포함된 것으로 판단한다(S280).
또한, 페이지의 검사를 위해, 파싱부(140)가 SQLite 데이터베이스 파일을 파싱하는 단계는 파싱부(140)가 SQL 쿼리문의 루트 노드 관련 인덱스(S320) 및 페이지 번호를 파싱(S330)하는 단계를 포함한다. 파싱부(140)는 리프(leaf) 페이지, 포인터 페이지 및 상기 포인터 페이지에 대응되는 상기 페이지 번호를 파싱한다. 변조검사부(160)가 파싱된 SQLite 데이터베이스 파일의 은닉을 검사하는 단계는 변조검사부(160)가 루트 노드 관련 인덱스와 페이지 번호를 대비하는 것으로 페이지의 은닉을 검사하는 단계(S340)를 포함한다. 변조검사부(160)는 인덱스와 페이지 번호가 매칭되지 않으면 페이지에 은닉이 있는 것으로 판단한다(S380)
또한, 레코드의 검사를 위해, 파싱부(140)가 SQLite 데이터베이스 파일을 파싱하는 단계는 파싱부(140)가 페이지의 헤더에서 셀(cell)의 개수 데이터 및 셀 지시 포인터의 개수를 파싱하는 단계(S420)를 포함한다. 변조검사부(160)가 파싱된 SQLite 데이터베이스 파일의 은닉을 검사하는 단계는 변조검사부(160)가 셀의 개수 데이터와 셀 지시 포인터의 개수를 대비하는 것으로 은닉을 검사하는 단계(S430)를 포함한다. 만약, 셀 개수 데이터 및 셀 포인터의 개수가 서로 상이하면 변조검사부(160)는 레코드에 은닉이 있는 것으로 판단한다(S480).
또한, 레코드의 검사를 위해, 파싱부(140)가 SQLite 데이터베이스 파일을 파싱하는 단계는 파싱부(140)가 페이지의 헤더에서 셀(cell)의 개수 데이터 및 상기 페이지의 레코드를 파싱하는 단계(S450)를 포함한다. 만약 S450단계가 S420단계 후에 실행된다면, 셀의 개수 데이터는 S420단계에서 파싱된 것을 이용한다. 변조검사부(160)가 파싱된 SQLite 데이터베이스 파일의 은닉을 검사하는 단계는 변조검사부(160)가 레코드의 수와 셀의 개수 데이터를 대비하는 것으로 은닉을 검사하는 단계(S470)를 포함한다. 레코드의 수와 셀의 개수가 서로 상이하면 변조검사부(160)는 레코드에 은닉이 있는 것으로 판단한다(S490).
상기 탐지과정이 모두 진행되었을 때 아무런 은닉의 흔적이 발견되지 않았다면 원본 파일이라고 판단한 후 탐지를 종료한다.
도 8의 순서도는 일 실시예로서, 파일 헤더의 검사 과정(S220, S240, S280), 페이지의 검사 과정(S320, S330, S340, S380), 레코드의 검사 과정(S420, S430, S450, S470, S480, S490)의 순서는 변경되어도 무방하다. 또한, 파싱부(140)의 파싱 단계들(S220, S320, S330, S420, S450)이 먼저 실행된 후 변조검사부(160)가 은닉을 검사하는 단계들(S240, S340, S430, S470)이 실행되는 것으로도 실시될 수 있다.
이상에서 본 발명의 바람직한 실시예를 설명하였으나, 본 발명은 다양한 변화와 변경 및 균등물을 사용할 수 있다. 본 발명은 상기 실시예를 적절히 변형하여 동일하게 응용할 수 있음이 명확하다. 따라서 상기 기재 내용은 하기 특허청구범위의 한계에 의해 정해지는 본 발명의 범위를 한정하는 것이 아니다.
100 : 은닉 탐지 시스템 120 : 입력부
140 : 파싱부 160 : 변조검사부

Claims (16)

  1. SQLite 데이터베이스 파일을 입력받는 입력부와;
    상기 SQLite 데이터베이스 파일을 파싱하는 파싱부와;
    파싱된 상기 SQLite 데이터베이스 파일의 헤더, 페이지 및 레코드의 은닉을 검사하는 변조검사부를 포함하되,
    상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 은닉되어도 SQLite 구동 시 오류가 발생되지 않는 영역을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 시스템.
  2. 삭제
  3. 제1항에 있어서,
    상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 메타데이터 영역의 은닉을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 시스템.
  4. 제3항에 있어서,
    상기 변조검사부는 상기 SQLite 데이터베이스 파일의 헤더 영역 중 파일변경횟수 정보, 버전 정보, 스키마 정보, 프리리스트 정보, 페이지캐쉬크기 정보, b트리페이지번호 정보, 증분베큠모드 정보, 응용프로그램아이디 정보, 확장예약영역 중 적어도 어느 하나를 대상으로 은닉을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 시스템.
  5. 제1항에 있어서,
    상기 파싱부는 SQL 쿼리문의 루트 노드 관련 인덱스 및 페이지 번호를 파싱하고,
    상기 변조검사부는 상기 루트 노드 관련 인덱스와 상기 페이지 번호를 대비하는 것으로 페이지의 은닉을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 시스템.
  6. 제5항에 있어서,
    상기 파싱부는 리프(leaf) 페이지, 포인터 페이지 및 상기 포인터 페이지에 대응되는 상기 페이지 번호를 파싱하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 시스템.
  7. 제5항에 있어서,
    상기 파싱부는 페이지의 헤더에서 셀(cell)의 개수 데이터 및 셀 지시 포인터의 개수를 파싱하고,
    상기 변조검사부는 상기 셀의 개수 데이터와 상기 셀 지시 포인터의 개수를 대비하는 것으로 은닉을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 시스템.
  8. 제7항에 있어서,
    상기 파싱부는 페이지의 레코드를 파싱하고,
    상기 변조검사부는 상기 레코드의 수와 상기 셀의 개수 데이터를 대비하는 것으로 은닉을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 시스템.
  9. (A) 입력부가 SQLite 데이터베이스 파일을 입력받는 단계;
    (B) 파싱부가 상기 SQLite 데이터베이스 파일을 파싱하는 단계;
    (C) 변조검사부가 파싱된 상기 SQLite 데이터베이스 파일의 헤더, 페이지 및 레코드의 은닉을 검사하는 단계를 포함하되,
    상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 메타데이터 영역의 은닉을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 방법.
  10. 제9항에 있어서,
    상기 변조검사부는 상기 SQLite 데이터베이스 파일 중 은닉되어도 SQLite 구동 시 오류가 발생되지 않는 영역을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 방법.
  11. 삭제
  12. 제9항에 있어서,
    상기 변조검사부는 상기 SQLite 데이터베이스 파일의 헤더 영역 중 파일변경횟수 정보, 버전 정보, 스키마 정보, 프리리스트 정보, 페이지캐쉬크기 정보, b트리페이지번호 정보, 증분베큠모드 정보, 응용프로그램아이디 정보, 확장예약영역 중 적어도 어느 하나를 대상으로 은닉을 검사하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 방법.
  13. 제9항에 있어서,
    상기 (B)단계는 상기 파싱부가 SQL 쿼리문의 루트 노드 관련 인덱스 및 페이지 번호를 파싱하는 단계를 포함하고,
    상기 (C)단계는 상기 변조검사부가 상기 루트 노드 관련 인덱스와 상기 페이지 번호를 대비하는 것으로 페이지의 은닉을 검사하는 단계를 포함하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 방법.
  14. 제13항에 있어서,
    상기 파싱부가 SQL 쿼리문의 루트 노드 관련 인덱스 및 페이지 번호를 파싱하는 단계의 상기 파싱부는 리프(leaf) 페이지, 포인터 페이지 및 상기 포인터 페이지에 대응되는 상기 페이지 번호를 파싱하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 방법.
  15. 제9항에 있어서,
    상기 (B)단계는 상기 파싱부가 페이지의 헤더에서 셀(cell)의 개수 데이터 및 셀 지시 포인터의 개수를 파싱하는 단계를 포함하고,
    상기 (C)단계는 상기 변조검사부가 상기 셀의 개수 데이터와 상기 셀 지시 포인터의 개수를 대비하는 것으로 은닉을 검사하는 단계를 포함하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 방법.
  16. 제9항에 있어서,
    상기 (B)단계는 상기 파싱부가 페이지의 헤더에서 셀(cell)의 개수 데이터 및 상기 페이지의 레코드를 파싱하는 단계를 포함하고,
    상기 (C)단계는 상기 변조검사부가 상기 레코드의 수와 상기 셀의 개수 데이터를 대비하는 것으로 은닉을 검사하는 단계를 포함하는 것을 특징으로 하는 SQLite 데이터의 은닉 탐지 방법.
KR1020170141390A 2017-10-27 2017-10-27 SQLite 데이터의 은닉 탐지 시스템 및 방법 KR102028412B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020170141390A KR102028412B1 (ko) 2017-10-27 2017-10-27 SQLite 데이터의 은닉 탐지 시스템 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020170141390A KR102028412B1 (ko) 2017-10-27 2017-10-27 SQLite 데이터의 은닉 탐지 시스템 및 방법

Publications (2)

Publication Number Publication Date
KR20190047467A KR20190047467A (ko) 2019-05-08
KR102028412B1 true KR102028412B1 (ko) 2019-10-04

Family

ID=66580347

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170141390A KR102028412B1 (ko) 2017-10-27 2017-10-27 SQLite 데이터의 은닉 탐지 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR102028412B1 (ko)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100951945B1 (ko) 2009-04-29 2010-04-09 광주과학기술원 스테가노그래피를 이용한 데이터 전송 방법과 장치 및 이를 구현하는 프로그램이 기록되는 기록 매체
KR101575246B1 (ko) 2014-12-10 2015-12-21 고려대학교 산학협력단 SQLite 데이터베이스 파일 내 손상된 레코드의 복원 방법

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101456757B1 (ko) * 2012-12-26 2014-10-31 고려대학교 산학협력단 ＳＱＬｉｔｅ 데이터베이스에서 삭제된 데이터의 복원 방법 및 장치
KR101681054B1 (ko) 2014-10-27 2016-11-30 주식회사 웨어밸리 Sql 변조 공격을 감지하기 위한 자동 학습 방법 및 시스템
KR101812328B1 (ko) * 2016-03-29 2018-01-25 대한민국 모바일 기기에서 데이터 무결성을 보장하는 부분 데이터 획득 장치 및 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100951945B1 (ko) 2009-04-29 2010-04-09 광주과학기술원 스테가노그래피를 이용한 데이터 전송 방법과 장치 및 이를 구현하는 프로그램이 기록되는 기록 매체
KR101575246B1 (ko) 2014-12-10 2015-12-21 고려대학교 산학협력단 SQLite 데이터베이스 파일 내 손상된 레코드의 복원 방법

Also Published As

Publication number Publication date
KR20190047467A (ko) 2019-05-08

Similar Documents

Publication Publication Date Title
Raghavan Digital forensic research: current state of the art
CN102171702B (zh) 机密信息的检测
CN101751535B (zh) 通过应用程序数据访问分类进行的数据损失保护
CN108667855B (zh) 网络流量异常监测方法、装置、电子设备及存储介质
EP2608107A2 (en) System and method for fingerprinting video
CN109413017B (zh) 一种管理异构防火墙的方法及系统
KR20120044002A (ko) 인터넷을 통해 수집한 데이터의 분석과 증거화 방법 및 이를 이용한 데이터 분석과 증거화 시스템
CN109783457B (zh) Cgi接口管理方法、装置、计算机设备和存储介质
Choi et al. Forensic recovery of SQL server database: Practical approach
CN103166966A (zh) 识别对网站的非法访问请求的方法及装置
CN113132311A (zh) 异常访问检测方法、装置和设备
CN103118035A (zh) 分析网站访问请求参数合法范围的方法及装置
CN112347501A (zh) 数据处理方法、装置、设备及存储介质
CN104392171A (zh) 一种基于数据关联的自动内存证据分析方法
CN104252447A (zh) 文件行为分析方法及装置
CN114866344B (zh) 信息系统数据安全防护方法、系统及云平台
CN110008462B (zh) 一种命令序列检测方法及命令序列处理方法
CN116383189A (zh) 业务数据的处理方法、装置、计算机设备、存储介质
CN115033569A (zh) 一种自定义遥感影像元数据入库方法
CN108733543A (zh) 一种日志分析的方法、装置、电子设备和可读存储介质
Raghavan A framework for identifying associations in digital evidence using metadata
CN106528805A (zh) 基于用户的移动互联网恶意程序url智能分析挖掘方法
CN111966339B (zh) 埋点参数的录入方法、装置、计算机设备和存储介质
KR102028412B1 (ko) SQLite 데이터의 은닉 탐지 시스템 및 방법
CN104933105A (zh) 数据库访问请求的分析方法和装置

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right