APK 보안을 분석하고 감사를 자동화하는 방법

1. 채팅

모바일 보안에 관해서는 최근 몇 년 동안 이 분야에 대한 연구가 대중화되었기 때문에 생소할 수 있습니다. 그렇다면 모바일 보안이란 무엇인가? 우선, 우리는 모바일 보안이 플랫폼 시스템 자체의 일부 문제와 애플리케이션 수준의 문제를 포함하여 iOS 플랫폼과 Android 플랫폼의 일부 보안 문제에 지나지 않는다는 것을 알고 있습니다. 물론 클라이언트와 서버가 상호 작용할 때 주로 http 및 https 프로토콜과 websocket 등과 같은 일부 다른 프로토콜과 같은 일부 통신 프로토콜이 관련되어야 합니다. 우리가 주의해야 할 것은 전송 중에 데이터 패킷이 필요할 때 암호화되는지 여부, 서버가 사용자의 운영 권한 및 서버의 일부 서비스를 제어하는지 여부입니다. 논리적 처리에 결함이 있는지 등 이런 측면의 아이디어는 기본적으로 웹 침투와 유사하지만 몇 가지 차이점이 있습니다.

2. 트로이 목마 공격

모바일 보안에 있어서는 당연히 바이러스와 트로이 목마 공격이 필수입니다. 일반적인 원격 제어 트로이 목마에는 droidjack, SpyNote 등이 포함되며, 얼마 전에 등장한 휴대폰 잠금 소프트웨어도 있습니다. .

그림 1 Droidjack

그림 2 잠금 소프트웨어

공격자는 Droidjack과 같은 소프트웨어를 사용하여 트로이 목마를 생성할 수 있습니다. 이러한 종류의 악성 트로이 목마는 일반적으로 일부 3류 APK 시장에 존재합니다. 일반적으로 공격자는 아무개 뷰티 동영상 무료 보기, 아무개 동영상을 위한 광고 없는 클라이언트, 아무개 멋진 사진 브라우저 등과 같은 몇 가지 유혹적인 정보를 이러한 APK에 넣습니다. 공격자는 유혹적인 정보가 포함된 APK를 인터넷에 게시한 후 원격 서버에서 서버 프로그램을 시작합니다. 사용자가 이 악성 프로그램을 설치하고 실행하면 해커는 원격 서버에서 사용자의 휴대폰을 제어할 수 있습니다. 다양한 행위를 저지르고 사용자의 개인정보를 도용합니다.

최종 분석에서 이러한 트로이 목마 바이러스 수준의 공격은 주로 사용자의 보안 인식 부족에 기인하므로 Android 애플리케이션의 보안에 대해 주로 논의하지 않을 것입니다.

3. 앱 서버 측 취약점 마이닝

그렇다면 앱 취약점을 어떻게 마이닝할까요? 우선 웹 보안에서 모바일 취약점 마이닝으로 전환한 보안 종사자들의 경우 자신의 분야와 유사한 취약점을 발굴하고 싶은 것은 당연하다. 앱의 서버 측도 기본적으로는 동일하다. 웹 보안 분야는 클라이언트가 브라우저에 가깝다는 점을 제외하면 모바일 애플리케이션에는 일반적으로 모바일 장치에 설치할 수 있는 앱 프로그램이 있습니다. 따라서 앱 서버 취약점 마이닝의 경우 과거 웹 경험을 활용하여 xss, ssrf, sql 주입, 임의 파일 읽기 등과 같은 일부 취약점을 마이닝할 수 있습니다.

웹 애플리케이션의 취약점을 파헤칠 때 브라우저에서 프록시를 구성하여 패킷을 캡처하고 웹 애플리케이션을 분석할 수 있습니다. 그렇다면 모바일 애플리케이션에서 패킷 분석을 어떻게 수행해야 할까요?

사실 안드로이드 애플리케이션의 패킷 분석도 프록시를 기반으로 하지만 프록시 구성이 상대적으로 복잡합니다. burptsuit 또는 fiddler에서 해당 에이전트를 구성한 후 이를 사용하여 데이터 패킷을 가로채고 재생할 수 있습니다. 여기서는 구체적인 단계를 자세히 설명하지 않습니다. 온라인 튜토리얼이 있으니 직접 확인해 보세요.

여기에서는 xss 및 sql 주입과 같은 일부 고전적인 취약점에 대해 자세히 설명하지 않겠습니다. 여기서는 주로 모바일 애플리케이션의 승인되지 않은 취약점에 대해 이야기하겠습니다. 웹 보안에서 무단 접근 취약점은 일반적으로 서버가 사용자 요청에 대한 권한 확인을 수행하지 않고 사용자 ID만을 기반으로 사용자 요청을 실행함으로써 발생하는 것으로 알려져 있습니다. 그렇다면 올바른 인증 프로세스는 무엇입니까? 텍스트로 간략하게 설명하면 다음과 같습니다. 사용자가 성공적으로 로그인하고 인증되면 서버는 사용자의 권한을 쿠키에 기록한 다음 브라우저에 반환합니다. 이 쿠키는 사용자가 가져옵니다. 후속 요청 패킷에서 서버는 데이터 패킷의 쿠키를 확인하여 사용자 권한을 식별하고 해당 권한으로 작업을 수행합니다.

그림 3 쿠키 인증 과정

물론 세션 인증이라는 또 다른 인증 방법이 있습니다. 세션 인증과 쿠키 인증 모두 사용자의 신원을 인증할 수 있습니다. 그렇다면 세션 인증과 쿠키 인증의 차이점은 무엇입니까? ​

간단히 말하면 쿠키는 클라이언트 측에 저장되고 세션은 서버 측에 저장됩니다. 보안 관점에서 볼 때 쿠키는 상대적으로 안전하지 않은 반면, 세션은 상대적으로 안전합니다. 왜냐하면 쿠키는 클라이언트 측에 저장되고 공격자는 사용자의 신원을 식별하는 데 사용되는 필드가 암호화되지 않은 경우 클라이언트 측에서 쿠키를 얻을 수 있기 때문입니다. 열거하기 쉬우면 공격자가 쿠키를 위조하고 승인되지 않은 작업을 수행할 수 있습니다. 세션 인증이 활성화된 경우 클라이언트는 로그인 성공 후에만 해당 세션 ID를 얻습니다. 이 ID는 암호화된 문자열이므로 탐색할 수 없습니다.

그렇다면 인증 절차는 어떻게 되나요? 우선, 세션 인증도 쿠키에 의존한다는 점을 알아야 합니다. 사용자가 성공적으로 로그인하면 서버는 사용자의 해당 세션을 서버의 데이터베이스에 기록합니다. 세션에는 사용자의 신원 정보와 기타 정보가 포함됩니다. 그런 다음 서버는 이 세션에 해당하는 ID를 클라이언트로 전송하므로 클라이언트의 쿠키 내용은 일반적으로 sessionid=xxxxxx 문자열뿐입니다. 사용자는 후속 요청에서 이 세션 ID를 가져와야 합니다. 서버는 세션 ID를 식별한 다음 데이터베이스를 쿼리하여 해당 사용자 권한 정보를 얻은 다음 사용자에게 응답 작업을 수행할 권한이 있는지 확인합니다.

분명히 세션 메커니즘은 상대적으로 안전하지만 보안의 다른 측면도 쿠키에 비해 더 많은 서버 성능을 소모합니다.

그림 4 세션 인증 프로세스

단, 모바일 측에서 사용자 신원 인증은 쿠키를 사용하지 않고 토큰 식별을 기반으로 합니다. 그럼 어떤 인증방식인가요? 간단히 말해서 인증 프로세스는 일반적으로 다음과 같습니다. 클라이언트 로그인 확인이 성공한 후 서버는 토큰 문자열을 반환합니다. 이 문자열은 사용자가 서버와 상호 작용합니다. 사용자의 신원을 식별할 수 있도록 이 토큰을 가져와야 합니다.

그림 5 토큰 인증 프로세스

데이터 패킷을 분석할 때 토큰이 없는 요청을 발견하면 이 데이터 패킷에 무단 액세스 취약점이 있을 가능성이 높습니다. 물론 특정 시나리오와 결합되어야 합니다. .비즈니스 로직에 영향을 미치는지 분석하고 결정합니다. 이것이 모바일 단말기의 무단 취약점을 발굴하기 위한 우리의 일반적인 자세입니다. 하지만 이 자세는 정신적으로 너무 지체되어 있어서 기본적으로 누구든지 접할 수 있는 문턱이 없습니다.

무단 접근 취약점을 파헤치는 또 다른 방법이 있는데, 다소 이상해 보이는 이 무단 접근 취약점의 근본 원인은 인증 전략 자체의 오류입니다. 오래 전 생방송 소프트웨어에 대한 프로토콜 분석을 수행한 결과 인증 논리가 다음과 같다는 것을 발견했습니다. 사용자 로그인 확인이 성공한 후 서버가 사용자 ID를 반환한 다음 로컬에서 사용자 토큰을 생성합니다. 후속 요청에서는 이 토큰을 사용자 신원 증명으로 가져오세요. 이는 사용자 ID를 통과할 수 있고 토큰 생성 알고리즘이 로컬이므로 공격자가 다른 사용자의 ID를 획득하고 로컬 토큰 생성 알고리즘을 추출하는 한 스스로 토큰을 계산할 수 있기 때문에 분명히 버그가 있습니다. 그런 다음 가짜 사용자가 로그인했습니다.

물론, 이러한 무단 취약점을 발견하는 것은 여전히 ​​상대적으로 어렵습니다. 이를 위해서는 취약점 발굴자에게 상대적으로 심층적인 역분석 능력과 코딩 능력이 필요합니다. 그러나 개발자로서 이러한 어려움 때문에 애플리케이션 보안 강화를 느슨하게 해서는 안 됩니다. 특히 매우 중요한 기능 모듈인 사용자 인증에 대해서는 보안을 잘 유지해야 합니다.

4. APK 클라이언트 취약점 마이닝

1. 일반적으로 사용되는 도구 소개

클라이언트 취약점의 경우 주요 방법은 디컴파일 도구를 통해 앱 클라이언트를 디컴파일하여 소스 코드를 얻은 다음 일부 경험과 보안 지식을 결합하는 것입니다. 정적 소스 코드 감사. 일반적인 디컴파일 도구에는 apkide, jeb, apktools 등이 포함됩니다. 이해를 돕기 위해 스크린샷을 찍어 보겠습니다.

그림 6 변화의 원리

그림 7 Jeb

물론 제가 가장 좋아하는 것은 매우 실용적인 안드로이드 역방향 보조 장치입니다.

그림 8 안드로이드 역방향 도우미

jeb과 함께 사용하면 기본적으로 일상적인 역분석을 충족할 수 있습니다.

안드로이드 애플리케이션 플랫폼은 크게 네이티브 레이어와 자바 레이어로 구분됩니다. Java 계층의 경우 위의 도구를 사용하여 분석할 수 있으며, 기본 계층의 경우 ida를 사용하여 분석해야 합니다. Ida는 매우 사용하기 쉬운 분해 도구입니다. ida를 통해 apk의 so 파일을 분해한 다음 f5 함수를 사용하여 arm 조립 코드를 C++ 의사 코드로 변환하고 논리 알고리즘을 분석할 수 있습니다. 또한 동적 디버깅을 지원하고 apk 애플리케이션을 원격으로 디버깅할 수 있습니다. ida 동적 디버깅을 사용하여 2차 패키징 검증과 같은 so 계층의 일부 검증을 우회하거나 동적 디버깅 및 셸링을 수행할 수 있습니다.

2. 애플리케이션 쉘링 소개

애플리케이션 쉘링이라고 하면 이는 APK 분석 과정에서 매우 필요합니다. 언패킹(Unpacking)에 대해 이야기하기 전에 먼저 패킹(Packing)이 무엇인지부터 알아보겠습니다. 패킹은 응용 프로그램이 실행되기 전에 먼저 프로그램 제어권을 얻은 다음 프로그램 제어권을 원본 프로그램으로 전달하는 것을 의미합니다. Android 플랫폼의 패킹 구현은 원본 dex 파일을 암호화하고 숨긴 다음 쉘 프로그램을 통해 원본 dex 파일을 얻은 다음 다시 복원하는 것입니다. 또 다른 방법은 함수 명령을 추출하고 실행할 때 후크를 사용하여 응답하는 것입니다. 클래스 로딩 함수는 명령을 다시 채웁니다.

패킹된 애플리케이션의 경우 기본적으로 원본 프로그램의 로직을 인식할 수 없으며, 패키징된 프로그램을 통해서는 보안 분석을 수행할 수 없습니다. 그러므로 우리는 애플리케이션의 압축을 풀어야 합니다. 일반적인 자동 압축 풀기 도구에는 drizzledump 및 dexhunter가 포함됩니다. Dexhunter는 사용하기 쉽지만 플래싱이 필요하고 많은 암호화 공급업체에서 이를 확인했기 때문에 직접 사용하면 작동하지 않으며 일부 감지를 우회해야 합니다. 자세한 사용법은 온라인에서 튜토리얼을 찾을 수 있으므로 여기서는 자세히 다루지 않겠습니다. 도구가 작동하지 않으면 결국 ida로 가야 합니다.

3. 정적 소스 코드 감사

소스 코드 수준에서 보안 탐지 시 주의해야 할 사항을 자세히 살펴보겠습니다.

구성 요소 보안

첫 번째는 구성 요소의 보안 문제입니다. Android 애플리케이션에는 활동, 서비스, 콘텐츠 제공자 및 방송 수신기라는 네 가지 주요 구성 요소가 있습니다. 이러한 구성요소가 그다지 필요하지 않은 경우 해당 내보내기 속성(exported)을 false로 설정해야 합니다. 즉, 내보내기가 금지됩니다. true로 설정하면 외부 애플리케이션에서 호출되어 정보 유출, 권한 우회 등의 취약점이 발생할 수 있습니다. 또한 데이터를 얻거나 처리하기 위해 Intent.getXXXExtra()를 사용할 때 예외 처리에 try...catch를 사용하지 않으면 서비스 거부 취약점이 발생할 수 있습니다. 이러한 예외에는 null 포인터 예외, 유형 변환 예외, 배열 범위를 벗어난 액세스 예외, 정의되지 않은 클래스 예외, 직렬화 및 역직렬화 예외.

위에서 언급한 컴포넌트 보안과 마찬가지로 우리는 보통 안드로이드의 androidManifest.xml 파일을 분석하여 판단합니다. AndroidManifest.xml은 Android 애플리케이션의 항목 파일로, 패키지에 노출된 구성 요소(활동, 서비스 등)와 해당 구현 클래스, 처리할 수 있는 다양한 데이터 및 시작 위치를 설명합니다. 프로그램에서 활동, ContentProvider, 서비스 및 인텐트 수신기를 선언하는 것 외에도 권한 및 계측(보안 제어 및 테스트)도 지정할 수 있습니다. 이 매니페스트.xml 파일을 분석하면 애플리케이션 데이터 백업, 애플리케이션 조정 가능성 등의 취약점도 발견할 수 있습니다. 물론 이러한 취약점은 일반적으로 상대적으로 위험도가 낮은 취약점입니다. 즉, 프로그램의 비즈니스 로직에 큰 영향을 미치지 않습니다. 또한 애플리케이션 디버깅 가능성의 취약성으로 인해 공격자가 애플리케이션을 디버깅하는 것을 금지하도록 디버그 가능을 설정하더라도 개발자는 애플리케이션 자체의 디버깅만 제어할 수 있고 사용자 시스템을 제어할 수 없기 때문에 공격자의 애플리케이션 디버깅을 막지는 못합니다. . 공격자는 응용 프로그램이 디버깅되도록 설정되어 있는지 여부에 관계없이 메모리에 속성을 설정하여 시스템의 모든 응용 프로그램을 디버깅할 수 있습니다. 그러나 모든 역분석가가 이 설정을 우회할 수 있다는 것을 아는 것은 아니기 때문에 여기서 디버깅을 비활성화하려면 이 설정을 지정하는 것이 여전히 필요합니다.

Webview 보안 문제

Android 클라이언트 애플리케이션의 더 심각한 취약점에 대해 이야기하려면 Webview 취약점이어야 합니다. 이제 아래와 같이 많은 전자상거래 플랫폼, Taobao, JD.com, Juhuasuan 등과 같은 많은 앱에 웹 페이지가 내장되어 있습니다.

그림 9 webview 디스플레이

사실 이것들은 모두 안드로이드의 컴포넌트는 webview로 구현됩니다. WebView는 웹페이지를 표시하는 웹킷 엔진 기반의 컨트롤입니다. 웹페이지를 표시하고 렌더링하는 기능은 레이아웃에 HTML 파일을 직접 사용하고 자바스크립트로 대화형으로 호출하는 것입니다. Webview는 단독으로 사용하거나 다른 하위 클래스와 함께 사용할 수 있습니다. Webview의 가장 일반적으로 사용되는 하위 클래스는 WebSettings 클래스, WebViewClient 클래스 및 WebChromeClient 클래스입니다. 여기서는 자세한 내용을 소개하지 않겠습니다. Android 프로그래밍에 관심이 있다면 Baidu에서 더 많은 정보를 찾을 수 있습니다.

Webview 구성 요소는 양면의 검이라고 할 수 있습니다. 그 외관은 클라이언트 개발 부담을 줄이고 프로그램의 주요 논리를 서버에 올려 구현하기만 하면 됩니다. webview를 이용하여 해당 웹페이지를 로딩하는데, 잘못 구성할 경우 원격 명령 실행 취약점이 존재할 수 있습니다. 관련 CVE에는 CVE-2012-6636, CVE-2014-1939 및 CVE-2014-7224가 포함됩니다.

cve-2012-6636 이 취약점은 프로그램이 WebView.addJavascriptInterface 메서드의 사용을 올바르게 제한하지 않기 때문에 발생합니다. 원격 공격자는 이 취약점을 악용하여 Java Reflection API를 사용하여 임의의 Java 개체 메서드를 실행할 수 있습니다.

cve-2014-1939 이 취약점은 addJavascriptInterface API를 사용하고 SearchBoxImpl 클래스의 개체를 생성하는 java/android/webkit/BrowserFrame.java로 인해 발생합니다. 공격자는 이 취약점을 악용하여 searchBoxJavaBridge_ 인터페이스에 액세스하여 임의의 Java 코드를 실행할 수 있습니다. .

cve-2014-7224 공격자는 원격 공격 코드를 실행하기 위해 주로 접근성과 접근성 Traversal이라는 두 개의 Java Bridge를 사용합니다.

Webview 원격 명령 실행 생성도 Java의 반사 메커니즘에 의존합니다. Webview의 addJavascriptInterface 메소드는 Java 객체를 WebView에 주입할 수 있으며, 이 Java 객체의 메소드는 Javascript를 통해 액세스할 수 있습니다. addJavascriptInterface를 제공하는 이유는 WebView의 Javascript가 로컬 App과 통신할 수 있도록 하기 위함입니다. 이는 실제로 매우 강력한 기능입니다. 로컬 앱 로직이 변경되지 않은 경우 앱을 업그레이드하지 않고도 프로그램을 업데이트하고 해당 웹 페이지를 수정할 수 있다는 장점이 있습니다. 그러나 Android 초기 버전에서는 접근 가능한 메소드에 대한 제한이 없었습니다. Java의 리플렉션 메커니즘을 사용하면 모든 객체의 모든 메소드를 호출할 수 있습니다. 이것이 WebView 취약점의 근본적인 원인입니다.

apk 업데이트 패키지 공격(중간자 공격)

위에서 언급한 취약점은 안드로이드 애플리케이션에서 비교적 흔하고 영향이 상대적으로 큰 취약점도 있지만, 적절하게 사용하면 해로울 수 있습니다. 예를 들어, 중간자 공격에서는 공격자와 피해자가 동일한 LAN에 있어야 하며 피해자의 트래픽은 공격자가 제어합니다. 중간자 공격은 무엇을 할 수 있나요? xss를 플레이하시겠습니까? 사용자 쿠키를 받으시겠습니까? 물론 여기서 사용자 쿠키를 얻는 것은 분명히 쓸모가 없으며 토큰 정보여야 합니다. 모바일 공격에서 적절하게 악용된 중간자 공격은 원격 명령 실행으로 이어질 수도 있습니다. 예를 들어, 애플리케이션이 업데이트될 때 다운로드된 업데이트 패키지를 제어하여 악성 공격 데이터 패킷으로 대체하는 경우 애플리케이션은 업데이트 패키지에 대해 필요한 서명 검증을 수행하지 않고 공격자가 수정한 반환 패키지에 포함된 업데이트 프로그램을 실행하는 경우가 있습니다. 악성 프로그램을 실행하게 만듭니다.

5. Apk 취약점 정적 검사 도구 구현

1. 프로젝트 소개

현재 클라이언트 측 취약점 탐지를 위한 적합한 검사 엔진이 없습니다. 얼마 전 모 디지털 기업, 모 뱅, 모 암호화된 APK 보안 스캐닝 툴을 조사한 결과는 평균 수준이었고 기본적으로는 모두 디컴파일된 소스코드를 기반으로 한 단순 취약점 검증을 바탕으로 한 결과였습니다. 그렇다면 자동화된 탐지 도구를 직접 작성할 수도 있을까요? 나는 또한 이전에 apk 자동 누락 검사 도구를 작성했습니다.

아래에서 구현 아이디어에 대해 이야기하겠습니다. 먼저 주요 분석 개체가 AndroidManifest.xml 및 dex 파일이라는 것을 알고 있지만 이 두 파일은 컴파일된 바이너리 파일이므로 디컴파일해야 합니다. AndroidManifest.xml을 디컴파일하는 데 필요한 도구는 AXMLPrinter.jar이고, dex 파일을 디컴파일하는 데 필요한 파일은 baksmali.jar입니다. 실제로 이 두 jar 패키지는 일부 리버스 엔지니어링 도구에서도 일반적으로 사용됩니다. Android Reverse Assistant 디컴파일 도구의 프로그램 디렉터리를 살펴보겠습니다.

그림 10 Android 역방향 보조 프로그램 디렉터리

Android Reverse Assistant라는 이 역방향 도구는 주로 이 두 도구를 사용하여 AndroidManifest를 구현합니다. dex 파일로 디컴파일됨 .

자동 누출 검색 도구에 해당 로직을 작성하고 이 두 도구를 호출하여 AndroidManifest 및 dex 파일을 디컴파일하는 한 일부 취약점 특성을 일치시켜 취약점을 감지할 수 있습니다.

다음은 프로젝트 디렉터리 구조에 대한 간략한 소개입니다.

그림 11 Apk 취약점 스캔 프로젝트 디렉터리 및 소개

먼저 애플리케이션의 패키지 이름이 필요하고 백업 허용 여부, 조정 가능 여부 등과 같은 애플리케이션의 일부 설정을 감지한 다음 활동, 서비스, 콘텐츠 네 가지 구성 요소에 대한 일부 구성 정보를 얻습니다. 공급자, 방송 수신기 및 내보낼 수 있는지 여부를 결정한 다음 애플리케이션에서 적용한 권한을 획득하여 너무 민감한지 여부를 결정합니다.

다음으로 디컴파일된 smali 파일에 대해 취약점 기능 탐지를 수행합니다. 이는 주로 우리가 사전에 수집한 취약점 특성에 의존합니다. 여기서는 취약점 특성을 xml 파일에 작성하고, 취약점 검사를 시작할 때 이를 프로그램이 호출할 수 있도록 메모리에 로드합니다. 우리 프로그램이 더 많은 취약점을 검사할 수 있도록 이러한 취약점 특성을 맞춤화할 수 있습니다. 현재 취약점 특성 정의는 문자열 및 정규 형식을 지원합니다. 이 프로젝트는 아직 유지 관리 중이지만 기본 기능은 구현되었으며 일상적인 검색 및 탐지를 충족할 수 있습니다. 검색 결과에 대해 몇 가지 문제를 해결하면 됩니다.

2. 현재 소프트웨어에서 지원하는 취약점 감지 유형

1. 임의 파일 읽기 및 쓰기 취약점

2. 강제 유형 변환 로컬 서비스 거부 취약점

4. 로컬 서비스 거부 취약점

5, 인텐트 스키마 URL 취약점

6, 콘텐츠 공급자 구성 요소 로컬 SQL 주입 취약점

7, 코드 동적 로딩 보안 탐지

8, 인증서 약한 검증

9, 호스트 이름 약한 검증

10, HTTPS 민감한 데이터 하이재킹 취약성

11, 해시 알고리즘은 안전하지 않습니다

12, AES 약한 암호화

13, Locat은 개인 정보를 유출합니다

14, 로그 유출 위험

15, PendingIntent 오용 위험

16, 의도 암시적

17. 데이터베이스 파일의 임의 읽기 및 쓰기

18. WebView 구성 요소 원격 코드 실행 취약점 감지

20. WebView는 SSL 인증서 오류 감지를 무시합니다. 저장 비밀번호

22. SharedPreferences

23. 임의의 파일 읽기 및 쓰기

24. 구성 요소 권한 확인

26.

27. 애플리케이션 권한 확인

28 , 애플리케이션 사용자 정의 권한 확인

30, 애플리케이션 백업 취약점 확인

3. 검사해야 하는 apk 파일을 작업 공간/apk 디렉터리에 넣습니다.

2. AndroidCodeCheck.exe를 클릭하거나 Python을 실행합니다. AndroidCodeCheck.py를 사용하여 취약점 검사를 수행할 수 있습니다

4. 보고서 출력

보고서 출력 경로는 보고서

1)txt 형식

일 수 있습니다. 프로그램의 실행 로그로 간주되며, 검사 결과에 대한 참고 자료로도 사용될 수 있습니다.

2) HTML 형식

html 형식의 보고서에는 디렉터리가 있습니다. 디렉터리에서 취약점 이름을 클릭하면 해당 취약점 유형 설명으로 이동합니다. 유형 설명에서 디렉토리로 돌아가기를 클릭하면 취약성 디렉토리 목록으로 돌아가서 취약성 검토를 용이하게 할 수 있습니다.

마지막으로 취약점 스캔 보고서 스크린샷을 보여드리겠습니다. 다소 조잡한 내용이며 추후 점차 개선될 예정입니다.首 그림 12 보고서 디렉터리 홈페이지

그림 13 취약점 5, 프로젝트 주소

APK 정적 소스 코드 데모 및 검색 도구 프로젝트 주소:

https://github.com/zsdlove/ApkVulCheck

위 내용은 APK 보안을 분석하고 감사를 자동화하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!