안드로이드 스마트폰 램덤프로 데이터 확인(카카오톡 대화)

안드로이드(삼성 갤럭시 스마트폰)에서 램덤프를 얻은 후 사용자 데이터가 있는지 확인해보겠습니다.  테스트는 모두 일반적으로 인터넷 검색을 통해 얻을 수 있는 것과 루팅되지 않은 스마트폰의 기본적인 기능을 통해서 진행했습니다.  추가 고급스킬이나 접근하기 어려운 소스&권한이 필요하지 않으며 스마트폰을 비정상상태로 만들지 않습니다.

카카오톡은 하나의 예이고 램 상에 남아있는 데이터면 무엇이든 되며 램덤프를 얻는 방법, 램덤프에 남아있는 데이터의 유효성 등에 따라 보안적으로 취약한 부분일 수 있고 아닐 수 있습니다.

 

램덤프 얻기

전화 - 키패드에서 - *#9900# 입력 - SysDump 라는 메뉴가 뜹니다.

여기서 'Debug Level Disabled/Low' 메뉴가 보이실 텐데 이걸 클릭해서 MID로 바꿔줍니다.

언제든지 되돌릴 수 있습니다.

Debug level 변경

 

MID를 클릭하면 자동으로 재부팅이 됩니다.  재부팅이 되면 이제부터 '볼륨다운 누르고있기 + 파워버튼 2번'으로 램덤프를 얻을 수 있는 업로드 모드로 들어가게 됩니다.

 

업로드모드에 들어가면 아래와같은 화면이 뜹니다.

Upload mode

 

다시 정상부팅을 하고싶으면 표시된 대로 '볼륨다운 + 파워키'를 약 3초정도 동시에 누르고 있으면 됩니다.

 

이제 이 상태에서 램덤프를 PC로 옮겨야 합니다.  RDX라는 툴을 이용해 할 수 있으며 구글링을 통해 6.1.4버전을 얻어 진행했습니다.

 

RDX는 대략 아래와 같은 이미지의 툴입니다.  

RDX

업로드모드에 들어간 스마트폰을 usb로 연결하고 RDX 툴을 실행시키면 자동으로 잡아서 가져올 수 있는 데이터들을 표시해줍니다.  ap_XXX로 되어있는 것들이 램덤프이며 덤프시점에 kernel, platform(android) log 등 도 확인할 수 있습니다.

당연한 얘기지만 램덤프 크기는 해당 스마트폰의 램크기와 동일합니다.  PC에 그만큼의 여유공간이 있어야 램덤프 파일을 다루기 수월합니다.

 

램덤프에서 데이터 확인

이제 카카오톡에 데이터를 남겨봅니다.

카카오톡 대화창에 'Hellosummer' 라고 작성했습니다.

카카오톡 - 대화 - 'Hellosummer' 

 

카카오톡에 메시지를 남기고 다시 스마트폰을 업로드 모드로 진입시키고 램덤프를 얻습니다.  램덤프 혹은 바이너리 파일을 분석하는 툴은 여러가지 있지만 저는 binwalk를 즐겨씁니다.

아래는 binwalk를 이용해 얻은 램덤프에서 'Hellosummer'라는 문자열을 검색한 결과입니다.

Dump에서 데이터 검색

 

해당 데이터가 여러 ap_XXX의 어느 파일에 있는지는 직접 찾아봐야 합니다.  

 

저는 위 ap_XXX파일에서 검색했고 여러 위치에서 'Hellosummer' 데이터가 검색되네요.  이는 해당 데이터가 실제 램상의 여러 위치에 있다는 것을 의미합니다.  제가 다른 app에서 Hellosummer라는 문자열을 사용하진 않았습니다.  혹시 Hellosummer를 사용하는 다른 app이 있었을까요?  하나 이상의 데이터가 검색되는 이유는 os, 혹은 app에서 그 데이터를 어떻게 처리했는지에 따라 달렸습니다.  os상에서 app의 특정 데이터를 여러군데에 복사해두었을 가능성은 적습니다만 os에 따라 memory swap, migration과정 중 남을 수도 있고 app에서 사용자 입력 데이터를 다른 layer로 넘기는 과정에서 복사가 빈번하게 일어날 수도 있습니다.  특히 memroy의 데이터에 직접 memset(, 0x00, )같은 zeroing을 할 수 없는 java의 경우 더욱 추적하기 어렵겠죠.

확실한건 제가 'Hellosummer'라는 데이터를 카카오톡에 쓰기 전에는 램덤프에 검색되는것은 하나도 없었습니다.

 

다시 binwalk로 돌아와서 검색 결과 열 중 HEXDECIMAL이라고 되어있는 부분이 해당 램덤프 파일에서의 상대적 위치입니다.  제가 사용한 ap_0x8c000...의 경우 0x8c000...부터의 메모리 영역이고 여기서 첫번 째 검색 결과인 0x67A38EF은 결과적으로 0x8c000... + 0x67A38EF의 실제 램 상 위치가됩니다.

 

아래는 binwalk를 통해 램덤프 파일을 바이너리 형태로 본 결과입니다.

0x15B21247 address 영역

 

위 결과는 같은 파일의 검색 결과 중 0x15B21247 offset의 위치를 봤을 때 입니다.

Hellosummer라는 데이터가 오른쪽 열에 보입니다.  그리고 기타 정보도 확인 할 수 있는데 msgId는 해당 메시지의 id, noSeen=false라고 되어있는건 카카오톡에서 해당 메시지를 본 상태인지, 읽지않아 1이 남아있는 상태인지를 나타내는 것이 아닐까 추측해볼 수 있습니다.

 

자바 데이터 타입의 경우 H . e . l . l . 과 같은 형식으로 문자열을 다루는 경우도 있습니다.  이 경우는 binwalk 검색 시 -R=Hellosummer로 옵션을 주면 검색결과에 잡히지 않습니다.  이는 자바에서 byte[], Byte[]와 같이 prmitive type, reference type의 변수형 메모리 관리와 관련이 있습니다.

byte[]는 데이터를 그대로 연속적인 array로 관리하는 반면 Byte[]는 하나하나씩 관리, 즉 실제 데이터 바이트 값이 연속적이지 않습니다.

 

시작할 때도 언급했지만 이렇게 램덤프에서 확인되는 결과가 반드시 보안적으로 취약하다는 것은 아닙니다.  공격 대상의 램덤프를 얻는 방법부터 해당 데이터가 보안적으로 민감한 데이터인지, 유효한지, 램상에 남아있는 이 데이터를 덤프 외의 방법으로 얻을 수 있는지를 따져봐야합니다.

 

대화창의 데이터를 모두 암호화하여 관리한다고 해도 사용자가 입력하는 순간의 memory를 확실히 지우지 않으면 원본데이터는 남게됩니다.  사용자가 읽을 수 있어야하기 때문에 보여주는 순간 복호화한 memory도 마찬가지입니다.

이는 흔히 사용하는 카카오톡을 대상으로 했을 때 얘기지만 다른 사용자 데이터를 다루는 app들도 비슷합니다.  모든 사용자 데이터를 이용할 때마다 암/복호화를 거치도록하면 너무 느려질겁니다.  법과 각 서비스 보안 정책을 기반으로 성능과 보안을 알맞게 trade off해야합니다.