[Tech Report] 안드로이드 OS, 숨겨진 속살을 파고들다

안드로이드 포렌식

스마트폰 분석의 첫걸음, 안드로이드 운영체제의 모든 것

모바일 시장에서 스마트폰의 점유율이 높아지면서 디지털 포렌식 조사에 있어서도 스마트폰 포렌식의 중요성이 갈수록 커지고 있다. 특히 스마트폰의 운영체제(OS) 중 안드로이드 OS는 전체의 70%를 차지할 정도로 비중이 커지고 있는 실정이다.

이에 이번 글에서는 스마트폰 시장에서 가장 높은 점유율을 기록하고 있는 안드로이드 OS에 대한 디지털 포렌식 분석 방법을 자세히 다루고자 한다. 이를 통해 디지털 포렌식에 있어 모바일의 중요성을 재확인하는 한편, 고도화되고 있는 안드로이드 포렌식 영역에 대해서도 제고하는 계기를 마련하려 한다.

 

시장조사기관 IDC가 지난 2월 19일 발표한 바에 따르면 스마트폰 안드로이드 OS는 지난 2012년 ‘세계 톱5 스마트폰 운영체제 출하량 및 점유율’ 조사에서 68.8%로 나타나, 가장 높은 점유율을 기록한 스마트폰 OS로 집계됐다. 이는 전년인 2011년 안드로이드가 49.2%에 달했던 것에 비하면 20% 가량 늘어난 것으로 안드로이드의 비중이 날로 커지고 있음을 방증한다.

주지하다시피, 스마트폰에는 연락처와 통화 기록, 메시지 정보뿐만 아니라 일정, 메일, 인터넷 방문 히스토리 등이 고스란히 기록돼 있다. 이 때문에 디지털 포렌식에서 더없이 중요한 영역으로 대두되고 있다. 스마트폰 OS에 있어 가장 높은 점유율을 차지하고 있는 안드로이드의 포렌식 기법에 대한 관심이 최근 증폭되고 있는 이유가 바로 여기에 있다.

 

안드로이드란 무엇인가

안드로이드는 오픈 핸드셋 얼라이언스(Open Handset Alliance)에서 개발한 모바일 기기용 OS다. 오픈 핸드셋 얼라이언스는 구글을 비롯해 HTC, 인텔, LG 등 48개의 하드웨어와 소프트웨어, 통신회사가 모바일 기기 공개표준개발을 목표로 결성한 단체다. 이들은 안드로이드의 모든 소스코드를 오픈 소스 라이선스인 ‘아파치 라이선스(Apache License)’로 배포한다.

안드로이드는 모바일 기기를 위한 운영체제와 미들웨어, 핵심 애플리케이션들을 포함한 소프트웨어 스택(Stack)으로 정리할 수 있다. 현재까지 최신 버전인 Android 4.2 ‘Jelly Bean’이 나온 상태다. 국내에서도 갤럭시(Galaxy)S 시리즈, Optimus 시리즈, Vega 시리즈, NexusOne, NexusS, Galaxy Nexus 등 다양한 안드로이드 기반 스마트폰이 출시돼 있다.

 

 

안드로이드 커널과 애플리케이션으로 구성

안드로이드는 크게 C 및 C++ 기반의 커널 영역과 Java 기반의 애플리케이션 영역 등 두 가지로 나뉜다. 커널 영역은 Linux 2.6 커널 기반으로 작성돼 있으며, 애플리케이션 영역은 SDK(Software Development Kit) 형태로써 개발용 도구와 API를 무상 제공하고 있다. [그림 1]은 안드로이드의 구조를 도식화한 것이다.

 

[그림 1] 안드로이드 시스템 구조도

초창기(버전 2.3 이전)엔 파일 시스템으로 YAFFS2(Yet Another Flash File System2)를 사용했다. YAFFS2는 NAND 플래시(Flash) 전용 파일 시스템으로, 마운트 속도와 NAND 유형의 플래시 메모리에서 입출력의 속도가 우수하다. 그러나 마운트 시 플래시 메모리 전체를 스캔해야 하기 때문에 플래시 메모리가 클수록 마운팅 시간이 오래 걸리는 단점이 있다. 이후 버전인 2.3부터는 YAFFS2 대신 Ext4(Extended file system 4)를 기본 시스템으로 택하고 있다.

 

실행 파일 수행, 달빅 가상머신 이용

안드로이드는 실행 파일 수행에 있어 달빅 가상머신(Dalvik VM)을 사용한다. 달빅 가상머신 상에서 수행되는 애플리케이션들은 각각 분리된 프로세스와 ID를 갖고 있으며 분리된 VM 영역에서 실행된다. 또한 데이터 저장은 경량 관계형 데이터베이스 엔진인 SQLite를 사용해 애플리케이션의 데이터를 저장한다.

Windows 환경 하에서의 실행 파일인 PE(Portable Executable)파일이 있듯이, 안드로이드 환경 하에서도 실행 파일인 DEX(Dalvik Excutable) 파일이 있다. 안드로이드는 이 DEX 파일을 달빅 가상머신에서 구동시킨다.

달빅 가상머신은 모바일 기기에서 용량이 적은 메모리를 사용해 실행 파일을 구동할 수 있게 최적화한 가상머신이다. 동시에 여러 가상머신을 실행할 수 있도록 설계돼 있다. 다시 말해 안드로이드 OS는 실행되는 애플리케이션마다 가상머신을 생성해 구동시티는 것이다.

 

DEX 파일과 APK 파일이란

앞서 언급한 DEX 파일은 Java 코드로 작성돼 컴파일된 클래스 파일을 DX(Android dx tool) 도구를 사용해 변환한 파일이다. 이 과정에 Java 바이트 코드는 달빅 바이트 코드로 변환되며 여러 클래스 파일에 들어있는 중복된 코드들을 재사용하기 때문에 JAR(Java archive) 파일에 비해 필요한 공간이 절반 정도로 크게 줄어든다.

APK(Android Package File)는 안드로이드 애플리케이션의 설치 파일이다. JAR 포맷의 변형된 형태로, 표준 ZIP 압축 포맷으로 돼 있다. 이 때문에 7-Zip, Alzip 등 압축 프로그램으로 내용을 확인할 수 있다. [그림 2]는 APK의 기본 구조다.

 
[그림 2] APK 기본 구조

AndroidManifest.xml 파일은 APK 내 최상위 폴더에 위치해 있으며 애플리케이션에 필요한 퍼미션(Permossion) 설정 정보를 담고 있다. 주요 컴포넌트(Component) 즉 Activity, Service, Broadcast Receiver, Content Provider에 대한 동작 설정 정보도 포함하고 있다.

 
[그림 3] AndroidManifest.xml 파일 구조

Classes.dex 파일은 앞서 언급한 DEX 파일로, 애플리케이션 안의 모든 코드를 내포하고 있다.

 

커스터마이징이 가능한 안드로이드

안드로이드의 표준 파티션은 [표 1]과 같이 7개로 구성된다. 하지만 제조사에 따라 파티션 구성이 조금씩 다를 수 있다. 안드로이드는 기본적으로 오픈 소스여서, 제조사가 원하는 대로 커스터마이징(Customizing) 작업이 가능하기 때문이다. 삼성과 LG 등 국내 제조사들은 커스터마이징 작업을 많이 하기 때문에, 포렌식 분석 과정에서 특히 유의해야 한다. 해외 제조사들은 비교적 표준을 따르고 있다.

 

 

이름 파일 시스템 마운트 포인트 설명

 

[표 1] 안드로이드 파티션 구성

 

디지털 포렌식 분석가 입장에서 중요한 파티션은 Userdata와 Sdcard다. 먼저 Userdata 파티션은 애플리케이션들이 생성하는 모든 데이터가 저장되는 파티션이다. 연락처와 통화 기록, 문자메시지 정보뿐만 아니라, 일정, 메일, 인터넷 출입 기록, 다운로드 정보 등 다양한 정보가 파티션에 남는다. Sdcard 파티션은 외장 파티션으로 사진이나 음악 등 멀티미디어 데이터들이 저장되는 파티션이다.

 

데이터 저장, 대부분 SQLite 사용

일반적으로 안드로이드 애플리케이션은 ‘/data/data/패키지명’ 경로 아래에 자신의 데이터를 저장한다. 저장 방식은 SQLite와 Preference, Local File 등 크게 세 가지로 나뉘며 대부분 SQLite 데이터베이스를 사용한다.

SQLite는 소형 데이터베이스 엔진으로써, 일반적인 질의어 언어인 SQL을 사용해 테이블 정의와 데이터 접근을 수행한다. 클라이언트 서버형이 아닌, 애플리케이션이 직접 데이터베이스의 파일로 접근하는 방식을 택하기 때문에 데이터베이스로 접근하기 위한 관리자 아이디나 패스워드를 설정하지 않아도 되는 편의성이 있다. 보통 ‘/data/data/패키지명’databases’ 아래에 저장된다.

 

[그림 4] 일반적인 SQLite 저장 위치

 

다음으로 프리퍼렌스(Preference) 저장 방식은 키와 값의 조합으로 데이터를 저장하는 구조다. 하나의 키에 하나의 값을 저장할 수 있다. 값으로 사용하는 유형에는 Boolean, Float, Int, Long, String 등이 있다. 프리퍼렌스엔 이름을 붙일 수도 있다. 게다가 한 개의 애플리케이션은 여러 개의 프리퍼렌스를 가질 수 있다. 프리퍼렌스는 일반적으로 ‘shared_pref’ 폴더 아래에 XML 포맷으로 저장된다.

 

[그림 5] 일반적인 Preference 저장 위치

 

Local File은 임의의 포맷에 문자열이나 이미지를 저장하는 방식이다. SQLite, Preference 이외의 모든 데이터 저장 방식이 여기에 속한다. Cache나 files 폴더에 저장된다.

 

응용프로그램, 서로 샌드박스 침범 불가

안드로이드에 설치된 애플리케이션들은 자신이 생성한 데이터를 앞서 언급한 세 가지 방식을 통해 저장한다. 이 과정에 데이터들은 샌드박스(Sandbox) 영역에서 관리된다. 샌드박스는 애플리케이션이 설치되는 시점에 고유의 UID(User Indentifer), GID(Group Identifer)를 부여받아 각각의 권한으로 실행되는 영역을 뜻한다. 따라서 응용프로그램(애플리케이션)들은 서로 샌드박스 영역을 침범할 수 없다. [그림 6]은 안드로이드 애플리케이션의 데이터베이스 폴더에 대한 접근 권한 정보를 도식화한 것이다.
 

 

[그림 6] 안드로이드 샌드박스 개념도 

실제 데이터가 저장되는 영역의 권한 정보를 살펴보면 [그림 7]과 같이 다른 사용자에게는 어떠한 접근 권한도 부여되지 않는다. 다시 말해, 데이터베이스 영역에는 해당 응용프로그램과 그 응용프로그램에 대한 관리자만이 접근할 수 있는 것이다.

 

 

[그림 7] 권한 설정 상태

 

 

최고 권리자 권한 획득, 루팅

그렇다면 안드로이드 환경 하에서 최고 관리자 권한을 획득하는 것은 무엇이라고 할까. 이를 루팅(Rooting)이라고 말한다. 안드로이드 OS는 리눅스를 기반으로 만들어져 있기 때문에 권한 체계도 리눅스를 따른다. 이 때문에 ‘최고 관리자 권한을 획득한다’는 것은 리눅스의 루트 권한을 획득하는 것과 동일한 의미를 지니는 것이다.

루팅은 개인 유저는 물론, 디지털 포렌식 분석가 모두에게 효과적이다. 우선 일반 유저 관점에서는 외장 메모리에 애플리케이션을 설치할 수 있고 멀티 터치 제한을 해제할 수 있으며 오버클럭킹(Overclocking, 사용자가 의도적으로 CPU의 동작속도인 클럭을 기준치 이상으로 높여 성능을 향상시키는 방법)을 통한 기능 향상 등을 꾀할 수 있다. 디지털 포렌식 관점에서는 루팅을 통해서 접근할 수 없는 주요 시스템 폴더에 접근할 수 있다. 이를 통해 파일 추출이 가능하고 파일 시스템의 이미징 생성이 가능하다.
 

 

[그림 8] 안드로이드 루팅

 

 

개발 위한 SDK, 관리 위한 ADB

안드로이드 SDK(Software Development Kit)는 구글에서 무료로 제공하는 안드로이드 애플리케이션 개발자들을 위한 Java 기반의 개발 도구다. SDK는 사이트(http://developer.android.com/sdk/index.html)에서 손쉽게 다운로드할 수 있다.

C++ 기반의 NDK(Native Development Kit)도 있다. SDK로 처리하지 못하는 신호나 비할당 메모리 처리 등에 유용하다. 하지만 일반적인 안드로이드 애플리케이션을 개발하고자 할 때는 SDK만으로 충분하다.

 

 

[그림 9] 안드로이드 SDK

ADB(Android Debug Bridge)는 안드로이드 기기와 에뮬레이터(Emulator)를 관리하기 위한 프로그램이다. 안드로이드 SDK에 기본으로 포함돼 있다. 주요 기능은 기기 연결 확인, 셸(Shell) 접속, 데이터 추출/삽입(루팅된 기기일 경우), 애플리케이션 설치/실행 및 삭제다.

ADB를 사용하기 위해선 해당 기기의 ‘설정’에서 [그림 10]과 같이 ‘USB debugging 모드’를 활성화해야 한다. 그 뒤 기기를 USB 케이블을 이용해 PC에 연결하면 ADB 사용이 가능하다.

 

 

[그림 10] USB debugging 모드 활성화

ADB의 기본 기능에 대해 자세히 설명하면 다음과 같다.

 

 

1) 에뮬레이터/기기 인식 확인 ADB를 사용하면 PC에서 기기나 에뮬레이터로 연결할 수 있다. 연결을 위해선 ADB에서 해당 개체를 인식해야 한다. 그런 후, [그림 11]과 같이 ‘adb devices’ 명령으로 인식된 기기나 에뮬레이터 목록을 확인할 수 있다.     [그림 11] 에뮬레이터 연결 확인 한 가지 주의해야 할 점은 기기를 연결할 경우, 해당 제조사에서 제공해주는 USB 드라이버를 PC에 설치해야만 인식이 가능하다는 점이다. 2) 셸 연결 기기나 에뮬레이터를 인식한 것으로 확인이 되면 해당 개체를 셸로 연결할 수 있다. 인식된 개체가 하나라면 ‘adb shell’ 명령으로 바로 셸 연결이 가능([그림 12])하지만 인식된 개체가 [그림 13]과 같이 여러 개일 경우 ‘-s’ 옵션 뒤에 연결하고픈 개체명을 입력해주어야 한다.     [그림 12] 셸 연결   [그림 13] 개체 선택 특히 셸 명령어 뒤에 리눅스 명령어를 추가하면 셸 프롬프트를 띄우지 않아도 바로 실행이 가능하다. 대신 이 경우엔 명령어 실행 후 바로 셸에서 빠져 나오게 된다.     [그림 14] 셸 옵션을 통한 리눅스 명령어 실행   여기서 주의해야 할 점 역시 기기를 연결할 때 해당 제조사에서 제공해주는 USB 드라이버를 PC에 설치해야만 인식이 가능하다는 점이다.   3) 데이터 입력 기기나 에뮬레이터가 인식됐다면 해당 개체에 데이터를 입력할 수 있다. [그림 15]와 같이 ‘adb push local remote' 형식으로 입력하면 된다. local과 remote는 미묘한 차이가 있다. 예컨대 local이 입력하고 싶은 데이터의 경로를 뜻한다면, remote는 입력한 데이터가 저장되는 개체의 경로를 말한다. local이 파일이 아닌 폴더일 경우, 폴더 아래 모든 파일과 폴더들이 remote 경로에 복사된다. 여기서도 한 가지 주의할 것이 있다. remote의 경로 중, 접근을 위해 권한이 필요한 경우가 있다. 이럴 땐 먼저 루팅을 통해 관리자 권한을 득해야 한다.     [그림 15] 파일 입력   [그림 16] 폴더 입력 4)데이터 추출 ADB를 이용해 기기나 에뮬레이터에서 데이터를 추출하는 것도 가능하다. ‘adb pull remote local’ 형식으로 입력하면 remote 경로에 해당하는 파일과 폴더를 추출한다. 데이터 입력 때와 마찬가지로 remote를 폴더에 저장하면 해당 폴더 아래 모든 파일과 폴더를 local에 저장한다.   [그림 17] 데이터 추출 5) 애플리케이션 설치/삭제/실행 만약 사용자가 APK 파일을 갖고 있다면 ADB를 통해 기기나 에뮬레이터 설치를 할 수 있다. 우선 애플리케이션의 설치는 ‘adb install APK파일명’ 형식으로 입력한다. 추가로 ‘-r’ 옵션을 주면 현재 설치돼 있는 애플리케이션의 데이터는 삭제하지 않으면서 애플리케이션만 재설치할 수 있다. ‘-s’ 옵션은 애플리케이션을 외장 SD카드에 설치한다.   [그림 18] 애플리케이션 설치 애플리케이션 삭제는 ‘adb uninstall <패키지명>’ 형식으로 입력한다. 패키지명은 APK 파일 내의 AndroidManifest.xml 파일에서 확인할 수 있다. 참고로 ‘-k’ 옵션을 사용하면 대상 애플리케이션의 데이터를 지우지 않는다.   [그림 19] 애플리케이션 삭제 설치된 애플리케이션을 실행하고자 한다면 ‘adb shell am start –n 패키지명/.Activity Class명’ 형식으로 입력하면 된다. Activity Class명은 AndroidManifest.xml 파일에서 확인 가능하다.     [그림 20] 애플리케이션 실행   이 역시 해당 제조사에서 제공해 주는 USB 드라이버를 PC에 설치해야만 인식이 가능하다.   6) 기타 기능 이밖에 기기나 에뮬레이터 리부팅이 기능도 있다. ‘adb reboot’를 입력하면 현재 연결된 개체를 리부팅한다. ‘adb kill-server’와 ‘adb start-server’는 각각 ADB 서버를 끄거나 작동시키는 명령어다. ADB는 PC에 연결된 ADB 서버와 기기나 에뮬레이터에 있는 ADB 클라이언트와의 통신을 통해 작동한다. 하지만 연결이 원활하지 않을 경우 ADB 서버를 끄고 다시 활성화하는 방법을 사용하면 손쉽게 문제를 해결할 수 있다.

애플리케이션 간 데이터 공유, 콘텐트 프로바이더

앞서 언급했듯이, 안드로이드 환경하에서 동작하는 애플리케이션들은 저마다 샌드박스를 갖고 있어 서로의 데이터 영역에 접근이 불가능하다. 그러나 간혹 애플리케이션 간의 데이터 교환이 필요한 때가 있다. 이럴 경우엔 콘텐트 프로바이더(Content Provider)를 사용하면 된다. 안드로이드 OS는 콘텐트 프로바이더라는 인터페이스를 제공하고 있어 애플리케이션 간의 데이터 공유를 해결한다.

콘텐트 프로바이더는 애플리케이션 간의 데이터 공유는 물론이고 다른 애플리케이션 데이터를 저장하거나 가져오는 작업을 수행할 수 있다. 자신의 콘텐트 프로바이더를 작성해 외부에 공개할 수도 있다. 안드로이드가 기본으로 설치해놓고 있는 애플리케이션들이 공개하고 있는 콘텐트 프로바이더를 네이티브 콘텐트 프로바이더(Native Content Provider)라고 한다. 여기에는 알람 정보, 통화 기록, 연락처, 브라우저 정보, 문자 정보, 미디어 스토어 등이 있다.
 

 

[그림 21] 콘텐트 프로바이더 구성도

 

콘텐트 프로바이더 접근 및 사용법

안드로이드 환경 하에서 특정 애플리케이션이 공개한 콘텐트 프로바이더에 접근하기 위해선 URI(Uniform Resource Identifier)를 통해야 한다. URI는 콘텐트 프로바이더를 통해 제공되고 있는 데이터를 뜻한다. 안드로이드 OS에 기본으로 설치된 애플리케이션들은 자신들의 데이터에 접근이 가능하도록 URI를 공개하고 있다.

URI를 사용하는 방법은 크게 두 가지가 있다. 먼저 콘텐트 프로바이더 클래스의 Static Field를 사용하는 방식이다. Static Field에 정의돼 있는 URI는, 콘텐트 프로바이더가 만든 일종의 가상 테이블이다. URI의 대다수는 테이블을 그대로 반환하지 않고 여러 테이블을 조인한 결과를 반환하는데, 이를 문서로 공개한다. 다음의 [표 2]는 네이티브 콘텐트 프로바이더 클래스의 Static Field에 정의돼 있는 URI의 한 예다.

 

[표 2] 네이티브 콘텐트 프로바이더 클래스의 Static Field URI

 

두 번째 방식은 일반적인 URI 사용이다. URI는 일반적으로 스키마나 네임스페이스, 혹은 인스턴스 ID로 구성돼 있다. 또 각 구성요소들은 슬래시(/)로 구분한다. 콘텐트 프로바이더와 스키마는 ‘Content://’로 고정돼 있다. 네임스페이스는 ‘contacts’와 같이 저장된 상수를 사용하는 방법과 ‘com.android.providers.contacts’와 같이 Java 패키지 이름을 그대로 사용하는 방법이 있다. 스키마와 네임스페이스로 이뤄진URI를 기본 URI라고 부르며 콘텐트 프로바이더가 제공하는 전체 데이터 집합을 의미하기도 한다.

실제 본 분석가가 두 번째 방식을 사용해본 결과, 데이터베이스에 있는 테이블의 전체 내용을 가져오는 것을 확인할 수 있었다. 또 이 방식은 네임스페이스 뒤 인스턴스 ID를 추가해 테이블의 ID 값에 해당하는 데이터에 접근할 수도 있다.

 

콘텐트 프로바이더 접근 시 퍼미션 필요

콘텐트 프로바이더에 URI를 통해 접근하기 위해선 퍼미션이 필요하다. 퍼미션은 안드로이드 시스템에서 제공하는 기능이나 데이터에 접근할 수 있는 권한을 말한다. 퍼미션이 설정돼 있지 않으면 코드 상 아무런 문제가 없더라도 해당 기능을 사용할 수 없으며 원하는 데이터에 접근할 수도 없다. 퍼미션은 해당 애플리케이션의 AndroidManifest.xml 파일에서 설정해야 한다. 현재 안드로이드 SDK 공식 문서에는 110여 개의 퍼미션이 정의돼 있다.

 

 

[표 3] 주요 퍼미션과 내용

 

데이터 공유 기반의 논리적 증거 수집

이제까지 설명한 내용을 간략히 다시 정리하면 안드로이드 OS는 애플리케이션 간의 데이터 공유를 지원하기 위해 콘텐트 프로바이더라는 인터페이스를 제공하고 있으나, 이를 이용해 특정 애플리케이션의 데이터에 접근하려면 해당 애플리케이션의 URI를 먼저 알아야 한다.

하지만 안드로이드에 기본으로 설치된 애플리케이션들은 이미 자신들의 URI를 공개하고 있다. 이 때문에 디지털 포렌식 관점에서 중요한 연락처나 문자, 통화 기록, 일정 등의 데이터는 콘텐트 프로바이더를 활용하면 비교적 쉽게 수집이 이뤄질 수 있다. 이런 방식의 데이터 수집은 직접 데이터가 저장돼 있는 파일에 접근하지 않고 OS를 통해 접근 및 수집이 가능하다는 점에서 ‘논리적 증거 수집’ 방식에 속한다.

이는 결국 콘텐트 프로바이더를 통해 증거를 수집하려면 이를 위한 애플리케이션을 개발해야 한다는 이야기이기도 하다. 안드로이드 애플리케이션 개발에 필요한 요소는 JDK(Java SE Development Kit)와 Eclipse IDE, 안드로이드 SDK가 있다. 각각의 구성요소들은 아래의 [표 4]에 나와있는 URL에서 다운로드받을 수 있다. 실제 개발에 필요한 상세한 내용은 인터넷 검색 등을 활용할 수 있기에 이번에는 생략한다.

 

[표 4] 안드로이드 애플리케이션 개발 환경

 

다음의 [그림 22]는 콘텐트 프로바이더를 통해 통화 목록을 가져오는 소스의 일부를 보여주고 있다. 사용된 URI는 ‘content://call_log/calls’이며, ‘getContentResolver()’ API를 통해 통화기록이 저장된 DB에 접근해 데이터를 가져오는 방식으로 수집이 이뤄진다.

 

 

 

[그림 22] 콘텐트 프로바이더 사용의 예

 

위 [그림 22]는 또 콘텐트 프로바이더를 이용한 수집 도구의 데이터 흐름을 뜻하고 있기도 하다. 수집 도구는 콘텐트 프로바이더에 기본 애플리케이션 URI를 입력하고 데이터를 받아온 뒤, SD카드에 CSV(Comma-separated values)파일 형태로 저장한다. 이를 통해 분석가는 SD카드를 PC에 마운트해 추출한 데이터를 확인할 수 있다.

 
[그림 23] 논리적 수집 애플리케이션

 

아래 [그림 24]는 콘텐트 프로바이더 구현의 예다.

 

 

 

[그림 24] 콘텐트 프로바이더 도구 구현의 예

 

[표 5]는 콘텐트 프로바이더를 통해 수집할 수 있는 데이터 종류와 사용 URI, 필요한 퍼미션을 정리한 내용이다. URI의 경우 현재 공식화된 문서가 없으며 OS 버전이 업데이트될 때마다 변경이 될 수 있어 유의할 필요가 있다. 데이터를 수집할 때 수집 도구의 AndroidManifest.xml 파일에 해당 퍼미션을 입력해야 하는 점도 주의해야 한다.

 

[표 5] 데이터별 사용 URI 및 필요한 퍼미션 내용

 

무료로 공개되어 있는 논리적 수집 도구는 ViaForensics의 AFLogical 오픈소스 버전이 있다. 이 도구는 https://viaforensics.com/resources/tools/android-forensics-tool/에서 다운로드가 가능하다.

 

[그림 25] ViaForensics의 AFLogical 오픈 소스 버전

 

지금까지 안드로이드 OS의 전반적인 지식과 더불어 콘텐트 프로바이더를 통한 데이터의 논리적 수집 방법에 대해 자세히 살펴보았다. 이번에 소개한 논리적 수집 방법은 SQL DB에 쿼리를 던져 데이터를 받아오는 방식과 유사하다. 이 때문에 삭제된 데이터의 복구는 사실상 불가능하다.

결국 확실한 분석을 위해선 루팅을 통해 데이터가 저장된 파일에 접근한 뒤 이미지를 생성해 삭제된 파일을 복구해야 할 것으로 보인다. 하지만 루팅이 모든 경우에 가능한 것은 아니어서 논리적 수집 방법도 전혀 무용한 것은 아니다.

다음 호에서는 앞서 좀 더 확실한 분석 방법으로 제시한 안드로이드 기기를 루팅하는 방법을 구체적으로 살펴보고자 한다. 루팅을 통해 권리자 권한을 득한 뒤, 데이터 파일에 직접 접근해보고 물리적으로 데이터를 수집하는 방법에 대해서도 다뤄보도록 하겠다.@