Android Applications Basics

htARTE (HackTricks AWS Red Team 전문가)로부터 AWS 해킹을 처음부터 전문가까지 배우세요!

HackTricks를 지원하는 다른 방법:

회사가 HackTricks에 광고되길 원하거나 HackTricks를 PDF로 다운로드하려면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 얻으세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 Discord 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
해킹 요령을 공유하려면 PR을 HackTricks 및 HackTricks Cloud github 저장소에 제출하세요.

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

안드로이드 보안 모델

두 가지 레이어가 있습니다:

OS: 설치된 애플리케이션을 서로 격리시킵니다.
애플리케이션 자체: 개발자가 특정 기능을 노출하고 애플리케이션 기능을 구성할 수 있습니다.

UID 분리

각 애플리케이션에는 특정 사용자 ID가 할당됩니다. 이는 앱 설치 중에 수행되어 앱은 해당 사용자 ID 또는 공유 파일에 소유권이 있는 파일과만 상호 작용할 수 있습니다. 따라서 앱 자체, OS의 특정 구성 요소 및 루트 사용자만 앱 데이터에 액세스할 수 있습니다.

UID 공유

두 애플리케이션은 동일한 UID를 사용하도록 구성할 수 있습니다. 이는 정보를 공유하는 데 유용할 수 있지만 그 중 하나가 손상되면 두 애플리케이션의 데이터가 손상됩니다. 이것이 이러한 동작이 권장되지 않는 이유입니다. 동일한 UID를 공유하려면 애플리케이션은 매니페스트에서 동일한 android:sharedUserId 값을 정의해야 합니다.

샌드박싱

Android 애플리케이션 샌드박스는 각 애플리케이션을 별도의 사용자 ID로 별도의 프로세스로 실행할 수 있도록 합니다. 각 프로세스에는 자체 가상 머신이 있으므로 앱의 코드는 다른 앱과 격리된 상태에서 실행됩니다. Android 5.0(L)부터 SELinux가 강제됩니다. 기본적으로 SELinux는 모든 프로세스 상호 작용을 거부한 다음 예상된 상호 작용만 허용하는 정책을 생성합니다.

권한

앱을 설치하고 권한을 요청할 때, 앱은 AndroidManifest.xml 파일의 uses-permission 요소에 구성된 권한을 요청합니다. uses-permission 요소는 요청된 권한의 이름을 name 속성 내에 나타냅니다. 또한 maxSdkVersion 속성이 있어 지정된 버전보다 높은 버전에서 권한을 요청하지 않도록 합니다. Android 애플리케이션은 처음에 모든 권한을 요청할 필요가 없으며 동적으로 권한을 요청할 수도 있지만 모든 권한은 매니페스트에 선언되어야 합니다.

앱이 기능을 노출할 때 특정 권한이 있는 앱에만 액세스를 제한할 수 있습니다. 권한 요소에는 세 가지 속성이 있습니다:

권한의 이름
permission-group 속성: 관련 권한을 그룹화하는 데 사용됩니다.
권한이 부여되는 방식을 나타내는 protection-level이 있습니다. 네 가지 유형이 있습니다:
Normal: 앱에 알려진 위협이 없을 때 사용됩니다. 사용자가 승인할 필요가 없습니다.
Dangerous: 권한이 요청된 애플리케이션에 일부 상승된 액세스를 부여함을 나타냅니다. 사용자가 승인을 요청받습니다.
Signature: 구성 요소를 내보내는 것과 동일한 인증서로 서명된 앱만 권한을 부여받을 수 있습니다. 이것은 가장 강력한 보호 유형입니다.
SignatureOrSystem: 구성 요소를 내보내는 것과 동일한 인증서로 서명된 앱 또는 시스템 수준 액세스로 실행되는 앱만 권한을 부여받을 수 있습니다.

사전 설치된 애플리케이션

이러한 앱은 일반적으로 /system/app 또는 /system/priv-app 디렉토리에 있으며 일부는 최적화되어 있습니다(classes.dex 파일을 찾을 수 없을 수도 있음). 이러한 애플리케이션은 때로는 루트로 실행되는 권한이 너무 많은 경우가 있으므로 확인할 가치가 있습니다.

AOSP(Android 오픈소스 프로젝트) ROM에 포함된 앱
장치 제조업체가 추가한 앱
휴대전화 제공업체가 추가한 앱(제공업체에서 구매한 경우)

루팅

물리적 안드로이드 장치에서 루트 액세스를 얻으려면 일반적으로 장치 및 버전에 특정한 취약점을 이용해야 합니다. 일단 취약점이 작동하면 일반적으로 Linux su 이진 파일이 사용자의 PATH 환경 변수에 지정된 위치(예: /system/xbin)로 복사됩니다.

su 이진 파일이 구성된 후 다른 Android 앱이 su 이진 파일과 루트 액세스 요청을 처리하는 데 사용됩니다. 이러한 앱에는 Superuser 및 SuperSU가 포함됩니다(구글 플레이 스토어에서 사용 가능).

루팅 프로세스는 매우 위험하며 장치를 심각하게 손상시킬 수 있음을 유의하세요

ROM

커스텀 펌웨어를 설치하여 OS를 대체할 수 있습니다. 이렇게 하면 오래된 장치의 유용성을 확장하거나 소프트웨어 제한을 우회하거나 최신 Android 코드에 액세스할 수 있습니다. OmniROM 및 LineageOS는 가장 인기 있는 펌웨어 중 두 가지입니다.

장치를 루팅할 필요가 항상 있는 것은 아님을 유의하세요. 일부 제조업체는 부트로더의 잠금 해제를 잘 문서화되고 안전한 방식으로 허용합니다.

영향

장치가 루팅되면 모든 앱이 루트 액세스를 요청할 수 있습니다. 악성 애플리케이션이 액세스를 요청하면 거의 모든 것에 액세스할 수 있으며 전화를 손상시킬 수 있습니다.

안드로이드 애플리케이션 기초 사항

안드로이드 애플리케이션의 형식은 _APK 파일 형식_으로 참조됩니다. 이는 기본적으로 ZIP 파일입니다(파일 확장자를 .zip로 변경하면 내용을 추출하고 볼 수 있음).
APK 내용(완전하지 않음)
AndroidManifest.xml
resources.arsc/strings.xml
resources.arsc: 바이너리 XML과 같은 사전 컴파일된 리소스를 포함합니다.
res/xml/files_paths.xml
META-INF/
여기에 인증서가 위치합니다!
classes.dex
기본적으로 애플리케이션이 실행하는 컴파일된 Java(또는 Kotlin) 코드를 나타내는 Dalvik 바이트 코드를 포함합니다.
lib/
CPU 아키텍처별로 하위 디렉터리에 분리된 네이티브 라이브러리를 보관합니다.
armeabi: ARM 기반 프로세서용 코드
armeabi-v7a: ARMv7 및 그 이상 기반 프로세서용 코드
x86: X86 프로세서용 코드
mips: MIPS 프로세서 전용 코드
assets/
앱에서 필요한 기타 파일을 저장하며 때로는 악성 소프트웨어 작성자가 추가 코드를 숨기기 위해 추가 네이티브 라이브러리 또는 DEX 파일을 포함할 수 있습니다.
res/
resouces.arsc에 컴파일되지 않은 리소스를 포함합니다.

Dalvik & Smali

안드로이드 개발에서는 Java 또는 Kotlin이 앱을 만드는 데 사용됩니다. 데스크톱 앱과 달리 Android는 이 코드를 Dalvik Executable (DEX) bytecode로 컴파일합니다. 이전에는 Dalvik 가상 머신이 이 bytecode를 처리했지만 최신 Android 버전에서는 Android Runtime (ART)가 이를 처리합니다.

역공학을 위해 Smali가 중요해집니다. 이는 DEX bytecode의 사람이 읽을 수 있는 버전으로, 소스 코드를 bytecode 명령어로 번역하여 어셈블리 언어처럼 작동합니다. 여기서 Smali와 baksmali는 어셈블리 및 해체 도구를 가리킵니다.

Intents

Intents는 Android 앱이 구성 요소 간이나 다른 앱과 통신하는 주요 수단입니다. 이러한 메시지 객체는 앱이나 구성 요소 간에 데이터를 전달할 수도 있으며, 이는 HTTP 통신에서 GET/POST 요청이 사용되는 방식과 유사합니다.

따라서 Intent는 기본적으로 구성 요소 간에 전달되는 메시지입니다. Intents는 특정 구성 요소 또는 앱으로 직접 전송될 수 있으며, 특정 수신자 없이 전송될 수도 있습니다. 간단히 말해 Intent는 다음과 같이 사용할 수 있습니다:

주로 앱의 사용자 인터페이스를 열어 활동을 시작하는 데 사용
변경 사항을 시스템 및 앱에 알리기 위한 브로드캐스트로 사용
백그라운드 서비스를 시작, 중지 및 통신하는 데 사용
ContentProviders를 통해 데이터에 액세스하는 데 사용
이벤트를 처리하기 위한 콜백으로 사용

취약하다면 Intents는 다양한 공격을 수행하는 데 사용될 수 있습니다.

Intent-Filter

Intent Filters는 활동, 서비스 또는 Broadcast Receiver가 다양한 유형의 Intents와 상호 작용하는 방식을 정의합니다. 기본적으로 이러한 구성 요소의 기능을 설명하며, 수행할 수 있는 작업이나 처리할 수 있는 브로드캐스트 유형과 같은 내용을 설명합니다. 이러한 필터를 선언하는 주요 위치는 AndroidManifest.xml 파일이지만 Broadcast Receiver의 경우 코드를 통해 선언할 수도 있습니다.

Intent Filters는 카테고리, 작업 및 데이터 필터로 구성되어 있으며 추가 메타데이터를 포함할 수 있습니다. 이러한 설정을 통해 선언된 기준과 일치하는 특정 Intents를 처리할 수 있습니다.

Android 구성 요소(활동/서비스/콘텐츠 제공자/브로드캐스트 수신기)의 중요한 측면은 가시성 또는 공개 상태입니다. 구성 요소가 true 값을 가진 **exported**로 내보내어지거나 매니페스트에 대한 Intent Filter가 선언된 경우, 해당 구성 요소는 다른 앱과 상호 작용할 수 있습니다. 그러나 개발자는 이러한 구성 요소를 명시적으로 비공개로 유지하여 의도치 않게 다른 앱과 상호 작용하지 않도록 할 수 있습니다. 이는 매니페스트 정의에서 exported 속성을 **false**로 설정하여 달성할 수 있습니다.

또한 개발자는 특정 권한이 필요하도록 구성 요소에 대한 액세스를 더욱 안전하게 할 수 있습니다. permission 속성을 설정하여 지정된 권한을 가진 앱만 해당 구성 요소에 액세스할 수 있도록 강제할 수 있으며, 이를 통해 누가 상호 작용할 수 있는지에 대한 추가적인 보안 및 제어 수단을 추가할 수 있습니다.

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

암시적 인텐트

인텐트는 Intent 생성자를 사용하여 프로그래밍적으로 생성됩니다:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

Action으로 이전에 선언된 intent는 ACTION_SEND이고 Extra는 mailto Uri입니다 (Extra는 intent가 기대하는 추가 정보입니다).

이 intent는 다음 예제와 같이 manifest 안에 선언되어야 합니다:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

인텐트 필터는 메시지를 수신하기 위해 액션, 데이터 및 카테고리와 일치해야 합니다.

"인텐트 해결" 프로세스는 각 메시지를 수신해야 하는 앱을 결정합니다. 이 프로세스는 우선순위 속성을 고려합니다. 이 속성은 인텐트 필터 선언에서 설정할 수 있으며, 더 높은 우선순위를 가진 것이 선택됩니다. 이 우선순위는 -1000에서 1000 사이로 설정할 수 있으며 애플리케이션은 SYSTEM_HIGH_PRIORITY 값을 사용할 수 있습니다. 충돌이 발생하면 "선택기" 창이 나타나서 사용자가 결정할 수 있습니다.

명시적 인텐트

명시적 인텐트는 대상 클래스 이름을 지정합니다:

Intent downloadIntent = new (this, DownloadService.class):

다른 애플리케이션에서 이전에 선언된 intent에 액세스하려면 다음을 사용할 수 있습니다:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

보류 중인 인텐트

이를 통해 다른 애플리케이션이 귀하의 애플리케이션 대신 작업을 수행할 수 있습니다. 보류 중인 인텐트를 구성할 때는 인텐트와 수행할 작업을 지정해야 합니다. 선언된 인텐트가 명시적이지 않은 경우 (어떤 인텐트가 호출할 수 있는지 선언하지 않은 경우) 악성 애플리케이션이 피해 앱 대신 선언된 작업을 수행할 수 있습니다. 또한, 작업이 지정되지 않은 경우, 악성 앱은 피해자를 대신하여 모든 작업을 수행할 수 있습니다.

브로드캐스트 인텐트

이전 인텐트와 달리 브로드캐스트 인텐트는 여러 앱에서 수신할 수 있습니다. 그러나 API 버전 14부터는 Intent.setPackage를 사용하여 메시지를 수신해야 하는 앱을 지정할 수 있습니다.

또한 브로드캐스트를 보낼 때 권한을 지정할 수도 있습니다. 수신 앱은 해당 권한이 있어야 합니다.

브로드캐스트에는 두 가지 유형이 있습니다: 일반 (비동기) 및 순서가 지정된 (동기). 순서는 수신기 내에서 구성된 우선순위에 따라 결정됩니다. 각 앱은 브로드캐스트를 처리, 중계 또는 삭제할 수 있습니다.

Context 클래스에서 sendBroadcast(intent, receiverPermission) 함수를 사용하여 브로드캐스트를 보낼 수 있습니다. 또한 **LocalBroadCastManager**에서 sendBroadcast 함수를 사용하여 메시지가 앱을 벗어나지 않도록 할 수 있습니다. 이를 사용하면 수신기 구성요소를 내보낼 필요가 없습니다.

스티키 브로드캐스트

이 유형의 브로드캐스트는 보낸 후 오랫동안 액세스할 수 있습니다. 이러한 것들은 API 레벨 21에서 사용 중단되었으며 사용하지 않는 것이 권장됩니다. 어떤 애플리케이션이 데이터를 엿볼 수 있지만 수정할 수도 있습니다.

sendStickyBroadcast 또는 **sendStickyBroadcastAsUser**와 같이 "sticky"를 포함하는 함수를 찾으면 영향을 확인하고 제거하려고 시도해야 합니다.

딥 링크 / URL 스키마

Android 애플리케이션에서 딥 링크는 URL을 통해 직접 작업 (인텐트)을 시작하는 데 사용됩니다. 이는 활동 내에서 특정 URL 스키마를 선언함으로써 수행됩니다. Android 기기가 이 스키마를 사용하여 URL에 액세스하려고 시도할 때, 애플리케이션 내의 지정된 활동이 시작됩니다.

스키마는 AndroidManifest.xml 파일에 선언되어야 합니다:

[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]

이전 예제의 scheme은 exampleapp://입니다 (또한 **category BROWSABLE**도 참고하세요)

그런 다음, 데이터 필드에서 host와 path를 지정할 수 있습니다:

<data android:scheme="examplescheme"
android:host="example"
/>

웹에서 액세스하려면 다음과 같이 링크를 설정할 수 있습니다:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

앱에서 실행될 코드를 찾으려면 deeplink에 의해 호출된 activity로 이동하여 onNewIntent 함수를 검색하십시오.

HTML 페이지를 사용하지 않고 deep link를 호출하는 방법을 배우세요.

AIDL - Android Interface Definition Language

**Android Interface Definition Language (AIDL)**은 Android 애플리케이션에서 프로세스 간 통신 (IPC)을 통해 클라이언트와 서비스 간 통신을 용이하게 하는 데 사용됩니다. Android에서 다른 프로세스의 메모리에 직접 액세스하는 것은 허용되지 않기 때문에 AIDL은 객체를 운영 체제가 이해하는 형식으로 marshalling하여 서로 다른 프로세스 간의 통신을 용이하게 합니다.

주요 개념

Bound Services: 이러한 서비스는 IPC를 위해 AIDL을 활용하여 활동이나 구성 요소가 서비스에 바인딩되어 요청을 수행하고 응답을 받을 수 있게 합니다. 서비스 클래스의 onBind 메서드는 상호 작용을 시작하는 데 중요하며 취약점을 찾기 위한 보안 검토의 중요한 영역으로 표시됩니다.
Messenger: 바운드 서비스로 작동하는 Messenger는 onBind 메서드를 통해 데이터 처리에 중점을 둔 IPC를 용이하게 합니다. 이 메서드를 안전하지 않은 데이터 처리나 민감한 기능 실행을 위해 면밀히 검토하는 것이 중요합니다.
Binder: AIDL의 추상화로 인해 Binder 클래스의 직접적인 사용은 덜 흔하지만, Binder가 서로 다른 프로세스의 메모리 공간 간 데이터 전송을 용이하게 하는 커널 수준 드라이버로 작동한다는 점을 이해하는 것이 유익합니다. 자세한 내용은 https://www.youtube.com/watch?v=O-UHvFjxwZ8에서 확인할 수 있습니다.

구성 요소

이는 Activities, Services, Broadcast Receivers 및 Providers를 포함합니다.

런처 액티비티 및 기타 활동

Android 앱에서 activities는 화면처럼 작동하여 앱의 사용자 인터페이스의 다른 부분을 표시합니다. 앱에는 여러 개의 activities가 있을 수 있으며 각각은 사용자에게 고유한 화면을 제공합니다.

런처 액티비티는 앱으로의 주요 게이트웨이로, 앱 아이콘을 탭할 때 시작됩니다. 앱의 매니페스트 파일에 특정 MAIN 및 LAUNCHER 인텐트로 정의됩니다:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

앱 중에는 백그라운드 서비스와 같이 사용자 인터페이스가 없는 앱들도 런처 액티비티가 필요하지 않을 수 있습니다.

액티비티는 매니페스트에서 "exported"로 표시하여 다른 앱이나 프로세스에서 사용할 수 있도록 만들 수 있습니다. 이 설정은 다른 앱이 이 액티비티를 시작할 수 있게 합니다:

<service android:name=".ExampleExportedService" android:exported="true"/>

그러나 다른 앱에서 활동에 액세스하는 것이 항상 보안 위험은 아닙니다. 민감한 데이터가 부적절하게 공유되는 경우에는 정보 누출로 이어질 수 있습니다.

활동의 수명주기는 onCreate 메서드로 시작되며 UI를 설정하고 사용자와 상호 작용할 수 있도록 활동을 준비합니다.

애플리케이션 서브클래스

Android 개발에서 앱은 Application 클래스의 서브클래스를 만들 수 있지만 필수는 아닙니다. 이러한 서브클래스가 정의된 경우 해당 클래스는 앱 내에서 가장 먼저 인스턴스화됩니다. 이 서브클래스에 구현된 attachBaseContext 메서드는 onCreate 메서드보다 먼저 실행됩니다. 이 설정을 통해 애플리케이션이 시작되기 전에 초기화를 빠르게 수행할 수 있습니다.

public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}

서비스

서비스는 사용자 인터페이스 없이 작업을 실행할 수 있는 백그라운드 작업자입니다. 이러한 작업은 사용자가 다른 애플리케이션으로 전환해도 계속 실행될 수 있어서 장기 실행 작업에 중요합니다.

서비스는 다양한 방법으로 시작될 수 있으며, 인텐트가 애플리케이션의 진입점으로 사용되어 서비스를 시작하는 주요 방법입니다. startService 메서드를 사용하여 서비스를 시작하면 onStart 메서드가 실행되어 stopService 메서드가 명시적으로 호출될 때까지 계속 실행됩니다. 또한, 서비스의 역할이 활성 클라이언트 연결에 의존하는 경우, 클라이언트를 서비스에 바인딩하기 위해 bindService 메서드가 사용되며 데이터 전달을 위해 onBind 메서드가 활성화됩니다.

서비스의 흥미로운 응용 사례로는 사용자가 앱과 상호 작용하는 것을 방해하지 않고 백그라운드에서 음악 재생이나 네트워크 데이터 가져오기가 있습니다. 또한, 서비스는 내보내기를 통해 동일한 장치의 다른 프로세스에서 접근할 수 있습니다. 이는 기본 동작이 아니며 Android Manifest 파일에서 명시적으로 구성해야 합니다:

<service android:name=".ExampleExportedService" android:exported="true"/>

브로드캐스트 수신기

브로드캐스트 수신기는 메시징 시스템에서 청취자 역할을 하며, 여러 애플리케이션이 시스템에서의 동일한 메시지에 응답할 수 있게 합니다. 앱은 두 가지 주요 방법으로 수신기를 등록할 수 있습니다: 앱의 Manifest를 통해 또는 앱의 코드 내에서 registerReceiver API를 통해 동적으로 등록할 수 있습니다. Manifest에서는 브로드캐스트가 권한으로 필터링되며, 동적으로 등록된 수신기는 등록 시 권한을 지정할 수도 있습니다.

인텐트 필터는 등록 방법 모두에서 중요하며, 수신기를 트리거하는 브로드캐스트를 결정합니다. 일치하는 브로드캐스트가 전송되면 수신기의 onReceive 메서드가 호출되어 앱이 해당하는 대로 반응할 수 있게 되며, 예를 들어 배터리 부족 경고에 대한 동작을 조정할 수 있습니다.

브로드캐스트는 비동기적일 수도 있고 순서 없이 모든 수신기에 도달할 수도 있으며, 동기적일 수도 있어 수신기가 우선순위에 따라 브로드캐스트를 받을 수 있습니다. 그러나 잠재적인 보안 위험을 인지해야 합니다. 모든 앱이 자신을 우선시하여 브로드캐스트를 가로챌 수 있습니다.

수신기의 기능을 이해하려면 해당 클래스 내의 onReceive 메서드를 찾아보세요. 이 메서드의 코드는 수신된 인텐트를 조작할 수 있으며, 특히 **순서가 지정된 브로드

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

그리고 filepaths.xml에서 공유 폴더를 지정하는 예시:

<paths>
<files-path path="images/" name="myimages" />
</paths>

WebViews

WebViews are like mini web browsers inside Android apps, pulling content either from the web or from local files. They face similar risks as regular browsers, yet there are ways to reduce these risks through specific settings.

Android offers two main WebView types:

WebViewClient is great for basic HTML but doesn't support the JavaScript alert function, affecting how XSS attacks can be tested.
WebChromeClient acts more like the full Chrome browser experience.

A key point is that WebView browsers do not share cookies with the device's main browser.

For loading content, methods such as loadUrl, loadData, and loadDataWithBaseURL are available. It's crucial to ensure these URLs or files are safe to use. Security settings can be managed via the WebSettings class. For instance, disabling JavaScript with setJavaScriptEnabled(false) can prevent XSS attacks.

The JavaScript "Bridge" lets Java objects interact with JavaScript, requiring methods to be marked with @JavascriptInterface for security from Android 4.2 onwards.

Allowing content access (setAllowContentAccess(true)) lets WebViews reach Content Providers, which could be a risk unless the content URLs are verified as secure.

To control file access:

Disabling file access (setAllowFileAccess(false)) limits access to the filesystem, with exceptions for certain assets, ensuring they're only used for non-sensitive content.

Other App Components and Mobile Device Management

Digital Signing of Applications

Digital signing is a must for Android apps, ensuring they're authentically authored before installation. This process uses a certificate for app identification and must be verified by the device's package manager upon installation. Apps can be self-signed or certified by an external CA, safeguarding against unauthorized access and ensuring the app remains untampered during its delivery to the device.

App Verification for Enhanced Security

Starting from Android 4.2, a feature called Verify Apps allows users to have apps checked for safety before installation. This verification process can warn users against potentially harmful apps, or even prevent the installation of particularly malicious ones, enhancing user security.

Mobile Device Management (MDM)

MDM solutions provide oversight and security for mobile devices through Device Administration API. They necessitate the installation of an Android app to manage and secure mobile devices effectively. Key functions include enforcing password policies, mandating storage encryption, and permitting remote data wipe, ensuring comprehensive control and security over mobile devices.

// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

htARTE (HackTricks AWS Red Team Expert)를 통해 제로부터 히어로까지 AWS 해킹을 배우세요!

다른 HackTricks 지원 방법:

회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 구입하세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm을 팔로우하세요.
HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

PreviousAndroid Applications Pentesting NextAndroid Task Hijacking

Last updated 1 month ago