APK 분석기

Android 패키지인 .apk 파일을 놓으면, 휴대폰에 가까이 가기도 전에 그 파일이 스스로 선언하는 내용을 읽을 수 있습니다: 패키지 이름과 버전, 대상으로 하는 SDK 수준, 요청하는 모든 권한, 디버깅과 백업을 허용하는지, 다른 앱이 닿을 수 있는 컴포넌트는 무엇인지, 그리고 어떤 인증서로 서명되었는지. 파일은 절대 기기를 떠나지 않습니다: 업로드되지 않고 이 페이지 안에서 열리고 분석됩니다. 의심스러운 APK야말로 낯선 사람의 서버에 건네서는 안 되는 파일이기 때문입니다.

파일을 이 상자 안 어디에든 놓아도 됩니다. 아래의 모든 내용은 이 기기에서 패키지 자체로부터 읽습니다 — 매니페스트, 컴파일된 리소스, 서명 블록입니다.

APK가 코드 한 줄도 실행하기 전에 선언하는 것

APK는 주관이 있는 ZIP 아카이브입니다. Android가 그 코드를 실행하기 전에, 시스템은 안에 들어 있는 바이너리 AndroidManifest.xml을 먼저 읽습니다. 그 파일 하나가 놀랍도록 완전한 의도 선언입니다. 업데이트가 대조되는 정체성인 패키지와 그 버전을 명시합니다. 앱이 지원한다고 주장하는 가장 오래된 Android 릴리스와, 그 동작 규칙에 맞춰 빌드된 릴리스를 밝힙니다. 대상 SDK가 중요한 이유가 바로 이것입니다: 대상이 낮으면 더 오래되고 더 느슨한 권한 동작이 조용히 살아남습니다. 앱이 앞으로 사용할 수 있는 모든 권한을 나열합니다. 선언되지 않은 권한은 나중에 부여할 수 없기 때문입니다. 빌드가 디버깅 가능한지 — 릴리스에 절대 살아남아서는 안 되는 플래그 — 와 그 데이터가 기기 백업에 포함될 수 있는지도 말해 줍니다. 그리고 앱의 컴포넌트(액티비티, 서비스, 리시버, 프로바이더)를 목록화하며, 각각에 기기의 다른 앱이 호출할 수 있는지를 결정하는 내보내기 상태를 붙입니다. 권한 검사 없이 내보내진 컴포넌트는 고전적인 Android 공격 표면이며, 아무것도 설치하지 않고 여기, 매니페스트에서 볼 수 있습니다.

이야기의 나머지 절반은 서명입니다. Android는 기존 앱과 업데이트가 모두 같은 키로 서명된 경우에만 업데이트를 위에 설치합니다. 그래서 서명자 인증서의 지문은 그 앱 정체성의 연속성입니다: 패키지 이름이 같아도 다른 키로 서명되었다면 친숙한 라벨을 쓴 다른 앱입니다. 이 페이지는 두 세대의 서명을 모두 읽습니다 — META-INF의 Jar 스타일 인증서와 APK Signature Scheme v2/v3 블록 — 그리고 각 서명자의 주체, 발급자, 유효 기간, SHA-256 지문을 보여 주며, 인증서 및 키 매처에서 보유한 키나 CSR과 비교할 수 있습니다. 동반 가이드인 설치하기 전에 APK 안에 무엇이 있는지는 전체 검사를 체크리스트로 안내합니다. 정직한 제한 두 가지: 이 페이지는 동작이 아니라 선언을 읽습니다 — 코드를 디컴파일하지 않고, 앱을 실행하지 않으며, 악성인지 판단하지 않습니다. 그리고 매니페스트 자체가 모호한 경우(intent-filter가 있는 컴포넌트에서 exported 플래그가 생략된 경우, 컴파일된 리소스에서 확인할 수 없는 라벨)에는 추측으로 빈틈을 채우지 않고 그 사실을 말합니다. 앱이 실행된 뒤 네트워크에서 무엇을 하는지는 PCAP 분석기가 캡처를 읽어 알려 줍니다.

자주 묻는 질문

내 APK 파일은 어디로 가나요?

어디로도 가지 않습니다. 파일은 이 페이지에서, 사용자의 기기에서 열리고 분석되며, 아무것도 업로드, 전송, 저장되지 않습니다 — 파일을 분석할 때 네트워크 요청이 발생하지 않습니다. 이 도구에서는 그 점이 대부분의 도구보다 더 중요합니다: 가장 검사하고 싶은 APK는 이미 의심하고 있는 것들 — 포럼에서 받은 파일, 직접 다운로드한 파일, 이상해 보이는 스토어 항목 — 이며, 의심스러운 바이너리를 원격 검사 서비스에 보내는 것 자체가 노출이기 때문입니다. 페이지가 로드된 뒤에는 오프라인에서도 동작합니다.

APK를 설치하기 전에 무엇을 확인해야 하나요?

위에 모두 보이는 네 가지입니다. 패키지 이름: 게시자의 실제 네임스페이스인가, 아니면 한 글자만 바꾼 모조품인가? 권한: 손전등 앱이 정말로 연락처, 통화 기록, 정확한 위치가 필요한가 — 그리고 서명 수준이나 특수 수준의 요청이 일상적인 요청 사이에 숨어 있지 않은가? 내보내진 컴포넌트: 다른 앱이 닿을 수 있는 모든 액티비티, 서비스, 리시버, 프로바이더는 당신이 받아들이는 공격 표면입니다. 그리고 서명자: 업데이트는 설치된 앱과 같은 서명 인증서를 가져야 하므로, 어디선가 받은 "새 버전"을 사이드로딩하기 전에 SHA-256 지문을 신뢰하는 사본과 비교하세요.

이것으로 앱이 악성인지 알 수 있나요?

아니요. 매니페스트만으로 그것을 약속하는 도구는 과장하고 있는 것입니다. 이 페이지는 패키지가 선언하는 것 — 정체성, 권한, 컴포넌트, 플래그, 서명 — 을 읽으며, 이는 부주의한 개발자와 사칭자를 잡기에는 충분합니다: 서명자가 틀린 복제품, SMS 접근을 요구하는 손전등, 디버깅 가능한 상태로 남은 릴리스 빌드. 코드가 실제로 무엇을 하는지 판단하려면 디컴파일, 동적 분석, 또는 신뢰할 수 있는 스캐너가 바이너리 자체에 내리는 판정이 필요합니다. 여기서 깨끗한 결과는 "선언된 것 중 이상해 보이는 것이 없다"로 받아들이세요. 안전 인증서가 아닙니다.

일부 권한에 "참조 표에 없음"이라고 나오는 이유는 무엇인가요?

그럴듯한 추측보다 정직함이 낫기 때문입니다. 표시되는 보호 수준 — 일반, 위험, 서명, 특수 — 은 잘 알려진 android.* 권한과 프레임워크가 각각에 부여하는 수준을 정리한 선별 표에서 옵니다. 공급업체는 자체 권한을 추가하고, 제조사는 더 추가하며, 새 Android 릴리스는 새 이름을 도입합니다. 그중 어느 것도 표에 없으므로 페이지는 그 사실을 명시합니다. 알 수 없는 수준은 그 권한이 무해하거나 위험하다는 뜻이 아닙니다 — 이 참조가 다루지 않는다는 뜻이며, 권한 자체의 이름과 네임스페이스가 확인을 시작할 자리입니다.

"내보내기: 지정되지 않음"은 무슨 뜻인가요?

매니페스트가 정말로 말하지 않는다는 뜻입니다. 컴포넌트가 intent-filter를 선언하면서 android:exported를 생략하면, 실제 답은 역사적으로 앱의 대상 SDK와 Android 버전에 따라 달라졌습니다 — 옛 규칙은 그런 컴포넌트를 기본으로 내보냈고, 새 규칙은 개발자가 결정할 때까지 앱 설치 자체를 거부합니다. 자신 있게 예 또는 아니요를 출력하는 리더는 파일에 없는 사실을 지어내는 셈이므로, 이 페이지는 생략 자체를 보고합니다. 본인의 빌드에서 이 줄이 보인다면 명시적으로 고칠 가치가 있는 항목입니다.