Yum_Yum

[DataBase] 데이터베이스 구조

(1) 데이터베이스 구조

• 데이터베이스를 물리적 공간을 이해하기 쉽게 논리적으로 구체화

• Table Space, Segment, Extent, Block 단위로 나뉨

테이블 스페이스(Table Space) 안에는 데이터 파일이 존재하며, 데이터 파일은 세그먼트(Segment)로 구성된다.

각각의 세그먼트는 익스텐트(Extent)로 구성되고, 익스텐트는 블록(Block)으로 구성된다.

상위 개념과 크기 순서로 나열하면 다음과 같다.

• 1. 테이블 스페이스 (Table Space)

• 2. 데이터 파일 (Data File)

• 3. 세그먼트 (Segment)

• 4. 익스텐트 (Extent)

• 5. 블록 (Block)

1-1. Data Block (Block 또는 Page)

• 데이터베이스에서 데이터를 저장하는 가장 작은 단위 데이터 블록

• 물리적 디스크 공간 크기에 따라 데이터 블록 크기도 결정됨

• 위 그림을 예로 들자면, 데이터 블록의 크기는 2KB

• 데이터 블록은 담고 있는 데이터를 추적하고 비어있는 공간을 수월하게 찾기 위해 일정한 형식을 가짐

사용자가 입력한 데이터는 테이블에 저장되고 테이블은 물리적 파일 안에 데이터 블록 단위로 분할되어 저장된다.

데이터 블록은 헤더와 Row 디렉토리로 구성되며, 헤더는 각 블록에 대한 기본 정보를 담고 있고, Row 디렉토리는 각각의 Row를 가리키는 오프셋 목록을 가지고 있다.

Row 디렉토리 안에는 Flag(플래그) 값도 포함되어 있는데, 플래그 값은 해당 Row의 삭제 여부를 알려준다.

데이터 블록의 구조는 다음 그림과 같다.

가) Block Header

• 물리 디스크 주소나 데이터 블록에 대한 일반적인 정보를 담음

• 블록을 업데이트한 모든 트랜잭션에 대해서는 트랜잭션 엔트리가 필요하며, 그것에 대한 정보 또한 Block Header가 담음

• 대부분 운영체제에서 트랜잭션 엔트리는 약 23Byte 정도가 필요

나) Table Directory

• 데이터 블록 안에 레코드 데이터가 저장된 테이블에 대한 메타데이터를 담고 있는 영역

• 하나의 데이터 블록은 여러 테이블의 레코드를 저장하고 있을 수 있음

다) Row Directory

• 데이터 블록 특정 위치에 저장된 레코드 데이터 위치 정보를 담고 있는 영역

• 해당 영역은 한 번 레코드 삭제 이후에도 재할당 받을 수 없음

• 새로운 레코드가 데이터 블록에 추가되었을 때만 해당 공간을 다시 사용 가능

• 각각의 Row는 Row Directory에 있는 슬롯을 가짐

• 슬롯은 Row 데이터의 시작을 가리킴

Block Header, Table Directory, Row Directory를 총칭하여 블록 오버헤드(Block Overhead)라고 한다.

일부는 고정된 크기를 갖지만, 총 사이즈는 가변적이다.

대부분 블록 오버헤드의 총 사이즈는 84에서 107Byte 정도이다.

라) Row Data

• 테이블 레코드나 인덱스 키 엔트리 등과 같은 실제 데이터를 담고 있는 곳

• 모든 데이터 블록이 내부 구조로 되어 있듯이 모든 레코드들도 데이터베이스가 원하는 데이터를 수월하게 찾기 위한 형식 존재

• 하나의 Row는 여러 개의 Row 조각들로 구성

• 각각의 Row 조각은 Row 헤더와 Column 데이터로 구성 

마) Row Header

• 데이터베이스에 저장된 Row Piece들을 관리하는 데 필요한 영역

• Row Piece에 있는 Column들과 데이터 블록 안에 저장된 다른 Row Piece에 대한 정보, 클러스터 키 정보를 가지고 있음

• 블록 하나를 온전히 차지하는 Row는 최소 3Byte의 Row 헤더를 가짐

일반적으로 Row는 하나의 데이터 블록에 담아지는 크기라 보통 하나의 Row Piece로 저장하지만, 하나의 데이터 블록에 담기에는 Row의 크기가 너무 크거나 업데이트로 인해 기존 Row 크기가 블록 크기를 넘어갈 경우, 여러 개의 Row Piece에 데이터를 저장한다.

RowID는 데이터베이스가 각 Row를 고유하게 식별하기 위한 것이다.

데이터베이스가 Row에 접근하기 위한 정보를 담고 있으며, 각 Row의 물리 주소를 Base64로 인코딩한 형식을 사용하며 확장형 RowID는 데이터 오브젝트 넘버를 포함한다.

ROWID 값으로 AAAR59AABAAALohAAA가 나왔다고 가정하자.

ROWID는 4부분으로 나뉘며, 다음 그림과 같이 나눌 수 있다.

[표 1] ROWID 구분과 설명

바) Column Data

• Row의 실제 데이터를 담는 공간

• Column 데이터는 CREATE TABLE로 명시한 Column 이름 순서대로 넣어짐

1-2. Extent

• 데이터 블록이 연속적으로 할당된 것

• 24KB의 익스텐트는 12개의 2KB 데이터 블록을 연속적으로 할당 받은 것이 됨

• 72KB의 익스텐트라면 데이터 블록 36개가 연속적으로 할당된 것

• 특정 타입의 정보를 저장하기 위한 단위

1-3. Segment

• 데이터베이스 테이블의 특정 오브젝트를 담기 위해 할당되는 단위 (한 개 이상의 익스텐트 모음)

• 해당 테이블 안의 데이터는 데이터 세그먼트에 저장

• 테이블의 인덱스 정보는 인덱스 세그먼트에 저장

• 모든 데이터베이스 오브젝트는 각각의 세그먼트에 저장

1-4. Table Space

• 실제 데이터를 물리적으로 저장하는 공간

• 데이터베이스의 레코드와 테이블 스키마 정보가 이곳에 들어 있음

# Reference

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

Multimedia Forensic #67 (어딘가에 숨겨진 메시지가 있을 것이다.)

문제 파일로 png 파일이 주어진다.

파일명만 보면 마치 스테가노그래피와 관련된 문제인 것 같다.

우선 파일을 실행해서 그림을 확인해보자.

png 파일을 실행해보면 이쁜 우주 그림을 볼 수 있다.

이번 문제를 풀기 위해 어떠한 방법을 사용해봐도 문제가 절대 풀리지 않았다.

그래서 관련된 내용을 책을 통해 확인해보면, 책에는 본 문제에 대한 힌트가 나오지만 본 문제에는 힌트와 관련된 내용은 전혀 나오지 않았다...

그렇기 때문에 문제를 매우 어렵게 접근하게 되어 Solve 수도 매우 적은 것 같았다.

책에서 나온 힌트는 다음과 같다.

Hint : bpp. 그건 믿을 수 없다.. 2bpp. 2X3 매트릭스 임베딩. Jessica Fridrich는 이 문제를 쉽게 해결할 것

문제에 대한 힌트를 해석해보면 다음과 같다.

먼저 bpp는 bit per pixel로 일정한 범위의 가짓수만큼 색을 표현하기 위해 사용되는 비트 개수를 부르는 단위이다.

그리고 2bpp는 2비트를 사용해서 픽셀 당 2비트를 사용한다는 의미이다.

힌트의 2x3 매트릭스 임베딩은 스테가노그래피에 사용되는 코딩 기법인데 힌트에서 언급된 Jessica Fridrich라는 교수가 2006년 Matrix embedding for large payloads라는 논문을 발표했었다.

모든 것을 종합해서 정리해보면 본 문제는 LSB 스테가노그래피와 매우 관련 깊은 문제이다.

LSB는 픽셀을 구성하는 비트 중 가장 오른쪽에 있는 1비트를 칭하지만 힌트로 2bpp가 주어졌기 때문에 픽셀 당 2비트의 데이터를 숨겼을 것으로 추측할 수 있다.

따라서 LSB에 대한 Python 코드를 작성하여 본 문제 해결이 가능하다.

코드를 작성한 후에 다음과 같은 명령을 입력하여 문제 파일의 결과에 대한 파일을 출력해보자.

코드의 이름을 lsb-stego로 해주고, 문제 파일 그리고 결과 파일 이름을 result로 지정해준 명령이다.

코드 실행이 종료되면 결과에 대한 result 파일을 file 명령어를 통해 파일 유형을 확인할 수 있다.

확인해보면 저장된 파일은 png 확장자를 갖는 그림 파일이다.

파일이 저장된 위치로 가서 결과를 확인해보면 다음과 같다.

파일을 실행해보면 문제에 대한 플래그를 확인할 수 있다.

위 방법을 통해 본 문제 해결이 가능하다.

# Reference

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

Multimedia Forensic #72 (저는 애니메이션을 좋아하는...)

지문이 200점 문제치고는 의외로 까다롭다...

우선 문제 파일인 jpg 파일을 열어 확인해보면 다음과 같은 그림이 나온다.

확인해보면 손상된 이미지이며, 지문에서 나온 Hint 2를 통해 손상된 이미지 복구가 아닌 해당 파일에 대한 원본 파일이 필요하다는 것을 추측해볼 수 있다.

문제 파일의 원본 파일은 다음과 같다.

원본 파일 : https://pp.userapi.com/c625217/v625217819/1eec5/5WzbbhtpMkQ.jpg

원본 파일을 확인한 후, 리눅스 환경에서 ls -l 명령어를 통해 원본 파일과 문제 파일을 비교해보자.

두 파일의 크기는 같지만, 정확한 데이터 값 분석을 위해 HexCmp2 프로그램을 통해 상세 분석을 진행해보자.

HexCmp2 : 각 파일의 Hex값을 비교하고, 다른 부분을 표시해주는 도구

설치 사이트 : https://softfamous.com/hexcmp/ 

[그림 3]에서 보이는 붉은 부분이 두 파일을 비교하였을 때, 서로 틀린 데이터 값을 표시하는 부분이다.

선명하게 보여주기 때문에 매우 유용한 도구이다.

다시 [그림 3]을 보면 원본 파일은 [7C 44 9E]로 시작하지만, 문제 파일은 [7C 45 9F]로 시작한다.

그리고 계속 분석해보면, 원본 파일의 특정 오프셋 Hex값에 1을 더해주면 문제 파일에 수정한 부분의 값들과 같음을 알 수 있다.

예를 들어 원본 파일의 [7C 44 9E]가 문제 파일에서는 [7C 45 9F]로 수정되었음을 알 수 있다.

이것으로 표시한 부분의 Hex값 차이를 구해 정리하면, 0과 1로 이루어진 이진 문자열을 얻을 수 있을 것이다.

이진 문자열 확인을 위해 Python 코드를 작성해보자.

이제 해당 코드를 이용하여 명령을 수행해보자.

diff라는 이름으로 Python 코드를 저장한 후, 2개의 파일을 입력하여 이진 문자열을 얻게하는 방식이다.

이진 문자열을 다음과 같이 출력하는 것을 볼 수 있다. (위 화면은 중간 내용으로, 나머지 내용은 너무 길어 생략)

이진 문자열을 확인한 후에 정리해보면, 해당 내용과 관련하여 아스키코드를 변환하는 방식이 있다.

아스키코드 변환 방식은 데이터를 은닉할 때 흔히 사용되는 방식으로 쓰인다.

따라서 위 [그림 5]에서 확인한 이진 문자열을 다음과 같은 명령을 통해 아스키코드로 변환할 수 있다.

echo와 perl 옵션을 통해 [그림 6]처럼 아스키코드로 변환이 가능하다.

명령을 수행하게 되면 하단에 문자열이 출력되며, 해당 문자열이 플래그라는 것을 확인할 수 있다.

위 과정을 통해 본 문제를 해결할 수 있다.

문제 해결~~

# Reference

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

Multimedia Forensic #68 (stream)

문제 파일로 pcap 패킷 파일이 주어진다.

패킷 분석을 위해 Wireshark 도구를 사용해보자.

Wireshark : 오픈 소스 패킷 분석 프로그램으로 pcap을 이용하여 패킷을 잡아내는 것이 주요 기능

다운로드 사이트 : https://www.wireshark.org/download.html

Wireshark 도구로 문제 파일을 오픈한 후에 [Conversations] 기능으로 패킷을 확인해보면 TCP 프로토콜로 하나의 Stream이 존재한다.

해당 패킷 내용을 확인하기 위해 [Follow TCP Stream] 기능을 통해 내용을 확인해보자.

위 [그림 2]와 같이 TCP Stream 0번을 확인해보면 User-Agent 항목 값이 브라우저가 아닌 NSPlayer로 되어 있다.

그리고 Content-Type 항목 값을 통해 mms 프로토콜로 파일을 응답 받았다는 것을 확인할 수 있다.

따라서 해당 패킷을 통해 호스트에서 동영상 재생 프로그램으로 서버의 어떤 파일을 mms 프로토콜로 시청했다고 할 수 있다.

자세한 정보를 확인하기 위해 HTTP Object를 확인해보자.

Wireshark 도구에서 [File] - [Export Objects] - [HTTP] 기능을 통해 확인할 수 있으며, 살펴보면 한 개의 오브젝트가 존재한다.

위 [그림 3]에서 보이는 Content Type이 위에서 확인했던 TCP Stream의 Content Type과 동일하고 TCP Stream이 패킷에서 오직 1개만 존재하기 때문에 해당 파일이 시청된 동영상 파일이라는 것을 추측할 수 있다.

이제 해당 동영상 확인을 위해 리눅스 환경에서 환경을 구축해보자.

우선 리눅스에서 php로 서버를 실행한다.

php 설치 명령어 : sudo apt-get install php

[그림 4]와 같은 화면이 나오면 하단에 표시되는 Document root 경로에 문제 파일을 넣는다.

그리고 VLC Media Player을 실행한다.

VLC Media Player : DVD, 오디오 CD, VCD와 다양한 스트리밍 프로토콜뿐만 아니라 대부분의 멀티미디어 파일을 재생할 수 있는 무료 오픈 소스 크로스 플랫폼 멀티미디어 재생기

설치 명령어 : sudo snap install vlc

참조 사이트 : https://www.videolan.org/index.ko.html

리눅스 환경에서는 vlc-wrapper을 터미널에 입력해주면 실행할 수 있다.

VLC Media Player가 실행되면 다음과 같은 화면이 나타난다.

위 [그림 5]에서 표시가 되어 있는 것처럼 [미디어] - [네트워크 스트림 열기] 기능을 선택한다.

그리고 Network URL 입력 칸에 mms 프로토콜을 이용하여 저장했던 파일의 URL을 입력하자.

필자는 php를 통해 127.0.0.1:7777 서버를 열었고, 문제 파일 이름을 123456으로 저장한 상태를 기준으로 하였다.

모든 입력이 끝났으면 우측 하단에 [재생] 버튼을 클릭한다.

[재생] 버튼을 클릭하면 동영상이 실행되면서 플래그를 확인할 수 있다.

이렇게 해서 위와 같은 방법을 통해 문제 해결이 가능하다.

문제 해결~~

# Reference

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

Disk Forensic #31 (도와주십시오, 누군가 깃발을 나누고 있습니다!)

문제 파일로 토렌트 파일이 주어진다.

토렌트는 하나의 파일을 piece라는 단위 조각으로 공유한다.

이런 piece 조각의 정보를 문제에서 주어진 토렌트 파일에서 확인 가능하다.

HxD로 해당 토렌트 파일을 확인해보면 공유 파일 크기는 28Byte이고, piece 조각 크기는 2Byte라는 것을 확인 가능하다.

여기서 28을 2로 나누면 14이며, piece가 총 14조각이라는 것을 알 수 있다.

그리고 위 정보에서 pieces280은 파라미터 뒤의 데이터는 암호화가 되어 전송된 piece가 280Byte임을 의미한다.

여기서 280을 14로 나누면 20이 계산되는데, 암호화가 된 1개의 piece조각이 20Byte임을 알 수 있다.

위 [그림 2]에서 표시한 280Byte 영역의 Hex 데이터를 암호화가 된 1개의 piece조각인 20Byte씩 순서대로 정리하면 다음과 같다.

Hex 데이터로 정리해보면 40글자의 문자열이 14줄 생성된다.

그리고 SHA-1 Hash 알고리즘은 40글자의 Hash 값을 생성하는데, 여기서 정리한 Hex 데이터가 SHA-1 알고리즘과 연관있다는 것을 추측해볼 수 있으며, 해당 데이터를 SHA-1 복호화를 통해 진행해보자.

SHA-1 복호화 사이트 : https://md5decrypt.net/en/Sha1/#answer 

14줄로 나눠 놓은 20Byte의 문자열을 소문자로 변경한 뒤에 한 줄씩 Decrypt를 진행하면 SHA-1 알고리즘으로 복호화 된 단어를 확인할 수 있다.

20Byte씩 14줄이므로 14번 진행해보면 문제에 대한 플래그를 얻을 수 있으며, 해당 값을 플래그로 입력해주면 문제 해결이 가능하다.

따라서 위 방법대로 본 문제를 해결할 수 있다.

# Reference

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

Disk Forensic #20 (경찰청은 최근 아동 성폭력...)

지문이 굉장히 긴 문제이다...

먼저 문제에서 제공한 이미지 파일을 FTK Imager에서 열어 확인해보자.

FTK Imager : 포렌식의 가장 기본 도구로, 디스크 이미징 작업에 많이 활용

다운로드 사이트 : https://accessdata.com/product-download/ftk-imager-version-4-2-1

파티션 1에서 Forensic[NTFS]의 폴더를 살펴보면 root/Users에서 사용자 계정을 확인할 수 있다.

우선 제일 의심스러운 CodeGate_Forensic 사용자 계정에서는 다운로드와 관련된 정보를 얻을 수 없다.

그러므로 추가 분석을 진행해보자.

분석 진행 도중에 Administrator 계정에서 토렌트와 관련된 uTorrent라는 이름으로 된 폴더를 확인할 수 있다.

따라서 uTorrent를 이용하여 다운로드를 했음을 추측해볼 수 있다.

파일의 경로는 root\Users\Administrator\AppData\Local\uTorrent이다.

이제 uTorrent에서 다운받은 파일의 경로와 설정 정보를 분석하기 위해서는 root\Users\Administrator\AppData\Roaming\uTorrent 폴더의 settings.dat 파일을 분석해야 한다.

settings.dat 파일을 [마우스 우클릭] - [Export Files...] 기능을 통해 해당 파일을 추출하여 지정 위치에 저장한다.

저장이 완료되면 토렌트 데이터 파일을 확인하기 위한 도구인 BEncode Editor 도구를 사용해보자.

BEncode Editor : 토렌트 데이터 파일을 편집, 확인할 수 있는 도구

다운로드 사이트 : https://sites.google.com/site/ultimasites/bencode-editor

settings.dat 파일을 열면 Administrator 계정과 관련된 경로를 확인할 수 있다.

경로는 C:\Users\CodeGate_Forensic\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup이다.

이제 위에서 settings.dat 파일의 내용에 대해 BEncode Editor 도구를 사용하여 확인한 경로를 FTK Imager로 이동해보자.

이동하면 위와 같은 파일이 확인되고, 똑같이 추출하여 MAC 타임을 확인해보면 다음과 같은 시간이 확인된다.

MAC 타임에서 C는 Created(생성 시간)을 뜻한다.

따라서 해당 파일은 2012년 12월 24일 월요일 오후 1시 45분 43초에 생성된 파일이라는 것을 확인할 수 있다.

그리고 해당 파일의 데이터를 확인해보면 TorrentRG.com의 문자열을 확인할 수 있고, 따라서 이 파일은 다운로더의 음란물 다운로드 흔적은 토렌트를 이용한 해당 파일의 다운로드임을 확인할 수 있다.

이제 지금까지의 내용을 정리하여 문제에서 요구하는 플래그 형태로 정리해보자.

문제에서 요구하는 형태는 SHA1("md5(Evidence File)_Download Time") 형태이다.

정리해보면 SHA1("md5(052b585f1808716e1d12eb55aa646fc4984bc862)_2012/12/24_13:45:43")이다.

이제 SHA1과 MD5 Hash값을 구하기 위해 Hashcalc라는 도구를 이용해보자.

HashCalc : 다양한 해시값 추출 프로그램으로, 파일 무결성 검사 도구

설치 사이트 : https://www.slavasoft.com/hashcalc/

위 화면은 HashCalc 도구를 이용해 해당 파일에 대한 MD5 값을 나타낸 화면이다.

이제 마지막으로 문제에서 제시한 파일의 MD5 Hash값과 다운로드 시간을 조합해보자.

449529C93EF6477533BE01459C7EE2B4_2012/12/24_13:45:43 (MD5 Hash 값_다운로드 시간)

SHA1 Hash값을 HashCalc 도구를 이용하여 구하면 최종 플래그를 확인할 수 있다.

따라서 위 과정을 통해 본 문제 해결이 가능합니다.

추가적으로 토렌트 다운로드 경로와 관련 있음을 파악하기 위해 NTFS 파일 시스템의 메타데이터 트랜잭션 정보를 저장하고 있는 $LogFile과 MFT 엔트리 정보가 저장된 $MFT를 NTFS Log Tracker 도구를 통해 분석하는 방법도 있으며, 파일에 대한 정확한 MAC 타임 정보를 확인할 수 있습니다.

그리고 HashCalc 도구를 통해 나온 결과 값인 MD5 Hash 값은 소문자에서 대문자로 변환해주어야 최종 플래그 값이 정상적으로 출력됩니다.

# Reference

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