Assessing the Forensic Viability of Android Memory Analysis Across Production Builds: A Cross-Version Study of Security Hardening and Structure Preservation

당신의 스마트폰이 북적이고 보안이 철저한 도시라고 상상해 보세요. 이 도시 안에서 앱들은 바쁜 상점들과 같고, RAM(메모리)은 모든 현재 거래가 일어나는 임시 작업 공간입니다. 당신이 비밀 메시지를 보내거나 계정에 로그인할 때, 데이터는 삭제되거나 하드 드라이브로 이동하기 전 잠시 동안 이 작업 공간에 존재합니다. 디지털 포렌식은 이 데이터가 사라지기 전에 이 작업 공간에 몰래 들어가 증거를 확보하는 기술입니다. 하지만 문제는, 도시의 설계자들(구글)이 더 높은 벽을 쌓고 거리 표지판을 제거하고 있다는 점입니다. 과거에는 조사관들이 지도(디버그 심볼)를 들고 들어가서 "비밀 메시지" 상점이 정확히 어디에 위치해 있는지 알 수 있었습니다. 이제 이 도시는 해커들이 침입하기 어렵게 만들기 위해 표지판들을 모두 제거했으며, 이로 인해 조사관들은 빈 벽을 바라보며 상점들이 여전히 그 자리에 있기는 한 것인지 의아해하고 있습니다.

이 논문은 그 표지판이 사라졌더라도 상점들이 여전히 서 있는지를 다루는 탐정 이야기입니다. 연구진은 다음과 같은 질문을 던졌습니다. "구글은 우리가 실제로 구매하는 휴대폰에서 지도를 제거했지만, 건물 자체도 옮겼는가?" 그들은 개발자들이 사용하며 전체 지도를 가지고 있는 안드로이드 시스템의 "설계도" 버전과, 모든 표지판이 제거된 일반 사용자들이 사용하는 "프로덕션" 버전을 비교했습니다. 그 결과, 거리 표지판은 확실히 사라졌지만 건물 자체는 움직이지 않았다는 것을 발견했습니다. 메모리의 레이아웃은 동일하게 유지되었으며, 단지 이름표가 없을 뿐이었습니다. 이는 약간의 추가적인 탐정 업무—즉, 일치하는 버전의 도시로부터 얻은 설계도를 사용하는 것—를 통해, 가장 현대적이고 강화된 휴대폰에서도 여다면 증거를 찾아낼 수 있음을 의미합니다.

거대한 지도 탈취 사건

수년간 디지털 포렌식 전문가들은 안드로이드 휴대폰의 혼란스러운 메모리를 탐색하기 위해 libart.so라는 라이브러리 파일을 의존해 왔습니다. 이 파일을 거대한 도서관의 마스터 디렉토리라고 생각하면 됩니다. 이 파일 내부에는 모든 책, 모든 선반, 그리고 각 문단의 정확한 위치가 담긴 완전한 목록이 있었습니다. 이 목록들을 "심볼(symbols)"이라고 불렀습니다. 만약 조사관이 암호화된 채팅 메시지와 같은 특정 증거를 찾고 싶다면, 디렉토리에서 "chat" 심볼을 검색하기만 하면 되었고, 그러면 도구는 메모리의 정확한 위치를 즉시 찾아냈습니다.

하지만 구글은 휴대폰을 해커로부터 더 안전하게 만들기 위해 "강화(hardening)" 캠в페인을 시작했습니다. 그들은 만약 해커가 전체 디렉토리를 갖게 된다면 시스템의 취약점을 쉽게 찾아낼 수 있다는 점을 깨달았습니다. 그래서 그들은 실제로 매장에 출고되는 휴대폰에서 이러한 디렉토리들을 제거하기 시작했습니다. 그들은 정적 심볼(주 목록), 소스 파일 참조(저자의 주석), 그리고 대부분의 동적 심볼을 제거했습니다 사서들이 문을 열 수는 있도록 최소한의 필수 라벨은 남겨두었지만, 그 외의 모든 것은 숨겨버린 것과 같습니다.

중요한 질문은 이것이었습니다. 단순히 라벨만 제거한 것인가, 아니면 선반까지 재배치한 것인가? 만약 선반이 움직였다면, 조사관이 예전 버전의 도서관에서 가져온 설계도를 가지고 있더라도 도움이 되지 않을 것입니다.

탐정 작업

이를 해결하기 위해 연구진은 시간 여행을 하는 사서처럼 행동했습니다. 그들은 두 가지 버전의 안드로이드 시스템을 확보했습니다:

1. "개발자(Developer)" 빌드: 전체 지도가 포함된 미제거(unstripped) 버전 (설계도).
2. "프로덕션(Production)" 빌드: 실제 구글 픽셀 7 휴대폰에서 실행 중인 버전 (내용이 제거된 현실).

그들은 먼저 숫자부터 확인했습니다. 예전 안드로이드 8 버전의 경우 라이브러리에 20,495개의 정적 심볼이 있었습니다. 새로운 안드로이드 15 버전에서는 그 숫자가 0으로 떨어졌습니다. 함수가 어떤 코드 파일에서 왔는지를 알려주는 소스 파일 참조 또한 완전히 사라졌습니다. 휴대폰 작동을 위해 반드시 남아 있어야 하는 몇 안 되는 라벨인 동적 심볼은 6,577개에서 2,614개로 약 60% 감소했습니다.

이는 포렌식에 있어 재앙처럼 보였습니다. 하지만 그들은 더 깊이 파고들었습니다. 그들은 실제 메모리 구조, 즉 "선반"과 "책" 자체를 확인했습니다. 그들은 안드로이드 8 휴대폰과 안드로이드 15 휴대폰의 메모리 맵을 비교했습니다. 그들은 "힙(heap, 앱이 데이터를 저장하는 곳)"과 "가비지 컬렉터(garbage collector, 오래된 데이터를 정리하는 것)"와 같은 핵심 구조들이 여전히 존재한다는 것을 발견했습니다. 단지 이름이 약간 바뀌었을 뿐이었습니다. 예를 들어, 안드로이드 8의 dalvik-allocspace main rosalloc이라는 메모리 공간은 안드로이드 15에서 dalvik-allocspace non moving이 되었습니다. 건물은 바뀌었지만, 주소는 변하지 않았습니다.

"마법의 설계도" 기술

이 논문에서 가장 흥 excitement(흥미로운) 부분은 그들이 부린 "마법"입니다. 휴대폰 자체에는 지도가 없기 때문에, 연구진은 일치하는 버전의 지도를 빌려오기로 결정했습니다.

그들은 안드로이드 15의 "개발자" 빌드(여전히 전체 지도를 보유한 버전)를 가져와 특정 구조로 가는 정확한 오프셋(바이트 단위의 거리)을 찾았습니다. 그런 다음, 지도가 없는 실제 픽셀 7 "프로덕션" 휴대폰으로 가서 그 동일한 거리들을 적용했습니다.

결과는 다음과 같았습니다:

1. 그들은 휴대폰 작동을 위해 반드시 남아 있어야 하는 단 하나의 심볼을 사용하여 "런타임(Runtime)" 객체(휴대폰 메모리의 주요 관리자)를 찾았습니다.
2. "개발자" 지도를 사용하여 해당 런타임 객체 내부에서 "힙(Heap, 데이터 저장소)"이 어디에 위치하는지 찾았습니다.
3. 그 거리를 "프로덕션" 휴대폰에 적용했습니다.
4. 결과: 완벽하게 작동했습니다. 계산된 포인터는 실제 휴대폰의 정확한 유효 메모리 주소로 이어졌습니다.

그들은 이 과정을 "스레드 리스트(Thread List)"와 "범프 포인터 스페이스(Bump Pointer Space)"에 대해서도 반복했으며, 매번 개발자 버전의 설계도가 제거된 프로덕션 휴대폰의 올바른 위치로 그들을 안내했습니다.

이것이 미래에 의미하는 바

이 논문은 포렌식의 "이지 모드(easy mode)"는 끝났지만, 게임이 끝난 것은 아니라고 시사합니다. 보안 강화는 메모리 아키텍처를 파괴한 것이 아니라, 단지 라벨을 숨긴 것뿐입니다.

• 좋은 소식: 메모리의 내부 레이아웃은 보존됩니다. 만약 당신이 조사 중인 휴대폰과 정확히 일치하는 버전의 "개발자" 빌드를 가지고 있다면, 그 지도를 사용하여 제거된 휴대폰을 탐색할 수 있습니다.
• 나쁜 소식: 오래된 지도를 그냥 사용할 수는 없습니다. 논문은 구조적 오프셋이 안드로이드 버전(예: 14 대 15) 간에 변경된다고 언급합니다. 따라서 안드로이드 8 지도로 안드로이드 15 케이스를 해결할 수는 없습니다. 반드시 버전이 일치하는 설계도가 필요합니다.
• 주의 사항: 이 과정은 이제 훨씬 더 수동적입니다. 조사관들은 단순히 "증거 찾기"라고 말하는 도구를 실행할 수 없습니다. 그들은 휴대폰의 정확한 버전을 찾아내고, 일치하는 개발자 빌드를 가져와서, 특정 거리(offset)를 추출한 다음, 이를 수동으로 적용해야 합니다.

연구진은 또한 자신들이 구글 픽셀 기기에서만 테스트했다는 점을 언급했습니다. 다른 휴대폰 제조사(삼성이나 샤오미 등)도 똑같이 했는지, 혹은 그들이 선반을 완전히 재배치했는지는 확실하지 않습니다. 하지만 테스트한 기기들에 대해서는 결론이 명확합니다: 도시는 여전히 존재하며 건물은 움직이지 않았지만, 길을 찾으려면 자신만의 지도를 가져와야 할 것입니다.