Android Applications Basics
Last updated
Last updated
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)
Kuna tabaka mbili:
OS, ambayo inashikilia programu zilizowekwa kuwa mbali na kila mmoja.
programu yenyewe, ambayo inaruhusu waendelezaji kufichua kazi fulani na kuunda uwezo wa programu.
Kila programu inapewa Kitambulisho Maalum cha Mtumiaji. Hii inafanyika wakati wa usakinishaji wa programu ili programu iweze kuingiliana tu na faili zinazomilikiwa na Kitambulisho chake cha Mtumiaji au faili zilizoshirikiwa. Hivyo, ni programu yenyewe tu, sehemu fulani za OS na mtumiaji wa root wanaweza kufikia data za programu.
Programu mbili zinaweza kuwekewa mipangilio kutumia UID sawa. Hii inaweza kuwa na manufaa kushiriki taarifa, lakini ikiwa moja yao itashambuliwa, data za programu zote mbili zitakuwa hatarini. Hii ndiyo sababu tabia hii inashauriwa kuepukwa.
Ili kushiriki UID sawa, programu lazima zifanye maelezo sawa ya android:sharedUserId katika hati zao.
Android Application Sandbox inaruhusu kuendesha kila programu kama mchakato tofauti chini ya Kitambulisho tofauti cha mtumiaji. Kila mchakato una mashine yake ya virtual, hivyo msimbo wa programu unafanya kazi kwa kujitenga na programu nyingine. Kuanzia Android 5.0(L) SELinux inatekelezwa. Kimsingi, SELinux ilikataa mwingiliano wote wa mchakato na kisha kuunda sera za kuruhusu tu mwingiliano unaotarajiwa kati yao.
Wakati unaposakinisha programu na inahitaji ruhusa, programu inahitaji ruhusa zilizowekwa katika uses-permission vipengele katika AndroidManifest.xml faili. Kipengele cha uses-permission kinaonyesha jina la ruhusa inayohitajika ndani ya attribute name. Pia ina maxSdkVersion attribute ambayo inakomesha kuomba ruhusa kwenye toleo lililo juu ya lile lililotajwa.
Kumbuka kwamba programu za android hazihitaji kuomba ruhusa zote mwanzoni, zinaweza pia kuomba ruhusa kwa njia ya kidinamik lakini ruhusa zote lazima zitangazwe katika manifest.
Wakati programu inafichua kazi inaweza kupunguza ufikiaji kwa programu tu ambazo zina ruhusa maalum. Kipengele cha ruhusa kina attributes tatu:
jina la ruhusa
permission-group attribute, ambayo inaruhusu kuunganisha ruhusa zinazohusiana.
protection-level ambayo inaonyesha jinsi ruhusa zinavyotolewa. Kuna aina nne:
Normal: Inatumika wakati hakuna hatari zinazojulikana kwa programu. Mtumiaji huhitajika kuidhinisha.
Dangerous: Inaonyesha ruhusa inatoa programu inayohitaji ufikiaji wa juu. Watumiaji wanahitajika kuidhinisha.
Signature: Ni programu tu zilizotiwa saini na cheti sawa na ile inayosambaza kipengele zinaweza kupewa ruhusa. Hii ndiyo aina yenye nguvu zaidi ya ulinzi.
SignatureOrSystem: Ni programu tu zilizotiwa saini na cheti sawa na ile inayosambaza kipengele au programu zinazofanya kazi na ufikiaji wa kiwango cha mfumo zinaweza kupewa ruhusa.
Programu hizi kwa ujumla hupatikana katika /system/app au /system/priv-app directories na baadhi yao zime boreshwa (huenda usipate hata faili ya classes.dex). Programu hizi zinastahili kuangaliwa kwa sababu wakati mwingine zinakuwa zinatumika na ruhusa nyingi sana (kama root).
Zile zinazokuja na AOSP (Android OpenSource Project) ROM
Zilizoongezwa na mtengenezaji wa kifaa
Zilizoongezwa na mtoa huduma wa simu (ikiwa imenunuliwa kutoka kwao)
Ili kupata ufikiaji wa root kwenye kifaa halisi cha android kwa ujumla unahitaji kufanya exploit 1 au 2 vulnerabilities ambazo huwa maalum kwa kifaa na toleo.
Mara exploit inapofanya kazi, kwa kawaida faili ya su ya Linux inakopishwa kwenye eneo lililotajwa katika mabadiliko ya PATH ya mtumiaji kama /system/xbin.
Mara faili ya su inapokuwa imewekwa, programu nyingine ya Android inatumika kuwasiliana na faili ya su na kusindika maombi ya ufikiaji wa root kama Superuser na SuperSU (inapatikana kwenye duka la Google Play).
Kumbuka kwamba mchakato wa rooting ni hatari sana na unaweza kuharibu kifaa vibaya
Inawezekana kuchukua nafasi ya OS kwa kusakinisha firmware maalum. Kufanya hivi inawezekana kuongeza matumizi ya kifaa cha zamani, kupita vizuizi vya programu au kupata ufikiaji wa msimbo wa hivi karibuni wa Android. OmniROM na LineageOS ni mbili ya firmware maarufu zaidi za kutumia.
Kumbuka kwamba sio kila wakati ni lazima ku-root kifaa ili kusakinisha firmware maalum. Wazalishaji wengine wanaruhusu kufungua bootloaders zao kwa njia iliyoandikwa vizuri na salama.
Mara kifaa kinapokuwa kime-rooted, programu yoyote inaweza kuomba ufikiaji kama root. Ikiwa programu mbaya itapata hiyo, itakuwa na ufikiaji wa karibu kila kitu na itakuwa na uwezo wa kuharibu simu.
Muundo wa programu za Android unajulikana kama APK file format. Kimsingi ni ZIP file (kwa kubadilisha kiambatisho cha faili kuwa .zip, maudhui yanaweza kutolewa na kuangaliwa).
Maudhui ya APK (Siyo ya kina)
AndroidManifest.xml
resources.arsc/strings.xml
resources.arsc: ina rasilimali zilizotayarishwa mapema, kama XML ya binary.
res/xml/files_paths.xml
META-INF/
Hapa ndipo Cheti kinapatikana!
classes.dex
Inashikilia bytecode ya Dalvik, inawakilisha msimbo wa Java (au Kotlin) uliotayarishwa ambao programu inatekeleza kwa default.
lib/
Inashikilia maktaba asilia, iliyogawanywa kwa usanifu wa CPU katika subdirectories.
armeabi: msimbo wa processors za msingi wa ARM
armeabi-v7a: msimbo wa processors za ARMv7 na za juu
x86: msimbo wa processors za X86
mips: msimbo wa processors za MIPS pekee
assets/
Inahifadhi faili mbalimbali zinazohitajika na programu, huenda ikajumuisha maktaba za asilia au faili za DEX, wakati mwingine hutumiwa na waandishi wa malware kuficha msimbo wa ziada.
res/
Inashikilia rasilimali ambazo hazijakusanywa katika resources.arsc
Katika maendeleo ya Android, Java au Kotlin inatumika kwa kuunda programu. Badala ya kutumia JVM kama katika programu za desktop, Android inakusanya msimbo huu kuwa Dalvik Executable (DEX) bytecode. Awali, mashine ya virtual ya Dalvik ilishughulikia bytecode hii, lakini sasa, Android Runtime (ART) inachukua jukumu katika toleo jipya la Android.
Kwa ajili ya uhandisi wa nyuma, Smali inakuwa muhimu. Ni toleo linaloweza kusomeka na binadamu la bytecode ya DEX, likifanya kazi kama lugha ya assembly kwa kutafsiri msimbo wa chanzo kuwa maagizo ya bytecode. Smali na baksmali zinarejelea zana za assembly na disassembly katika muktadha huu.
Intents ni njia kuu ambayo programu za Android zinawasiliana kati ya vipengele vyake au na programu nyingine. Hizi ni vitu vya ujumbe vinaweza pia kubeba data kati ya programu au vipengele, sawa na jinsi maombi ya GET/POST yanavyotumika katika mawasiliano ya HTTP.
Hivyo, Intent kimsingi ni ujumbe unaopita kati ya vipengele. Intents zinaweza kuelekezwa kwa vipengele maalum au programu, au zinaweza kutumwa bila mpokeaji maalum. Ili kuwa rahisi, Intent inaweza kutumika:
Kuanzisha Activity, kwa kawaida kufungua kiolesura cha mtumiaji kwa programu
Kama matangazo ya kuarifu mfumo na programu kuhusu mabadiliko
Kuanzisha, kusitisha, na kuwasiliana na huduma ya nyuma
Kupata data kupitia ContentProviders
Kama callbacks kushughulikia matukio
Ikiwa ni hatari, Intents zinaweza kutumika kufanya mashambulizi mbalimbali.
Kichujio cha Intents kinaelezea jinsi shughuli, huduma, au Mpokeaji wa Matangazo unaweza kuingiliana na aina tofauti za Intents. Kimsingi, zinaelezea uwezo wa vipengele hivi, kama vile ni hatua gani wanaweza kuchukua au aina gani za matangazo wanaweza kushughulikia. Mahali kuu pa kutangaza vichujio hivi ni ndani ya faili ya AndroidManifest.xml, ingawa kwa Mpokeaji wa Matangazo, kuandika ni chaguo pia.
Vichujio vya Intents vinajumuisha makundi, hatua, na vichujio vya data, huku kukiwa na uwezekano wa kujumuisha metadata ya ziada. Mpango huu unaruhusu vipengele kushughulikia Intents maalum zinazolingana na vigezo vilivyotangazwa.
Sehemu muhimu ya vipengele vya Android (shughuli/huduma/watoa maudhui/mpokeaji wa matangazo) ni mwonekano wao au hadhi ya umma. Kipengele kinachukuliwa kuwa cha umma na kinaweza kuingiliana na programu nyingine ikiwa kime exported na thamani ya true au ikiwa kichujio cha Intent kimewekwa kwa ajili yake katika hati. Hata hivyo, kuna njia kwa waendelezaji kuweka vipengele hivi kuwa binafsi, kuhakikisha havihusiani na programu nyingine bila kukusudia. Hii inafanywa kwa kuweka exported attribute kuwa false katika maelezo yao ya hati.
Zaidi ya hayo, waendelezaji wana chaguo la kuimarisha ufikiaji wa vipengele hivi zaidi kwa kuhitaji ruhusa maalum. permission attribute inaweza kuwekwa ili kuhakikisha kwamba ni programu tu zenye ruhusa iliyotolewa zinaweza kufikia kipengele, kuongeza safu ya ziada ya usalama na udhibiti juu ya nani anaweza kuingiliana nayo.
Intents huundwa kimaandishi kwa kutumia mjenzi wa Intent:
The Action ya nia iliyotangazwa hapo awali ni ACTION_SEND na Extra ni mailto Uri (Extra ni taarifa ya ziada ambayo nia inatarajia).
Nia hii inapaswa kutangazwa ndani ya manifest kama katika mfano ufuatao:
An intent-filter inahitaji kuendana na action, data na category ili kupokea ujumbe.
Mchakato wa "Intent resolution" unamua ni programu ipi inapaswa kupokea kila ujumbe. Mchakato huu unazingatia priority attribute, ambayo inaweza kuwekwa katika intent-filter declaration, na ile yenye kipaumbele cha juu itachaguliwa. Kipaumbele hiki kinaweza kuwekwa kati ya -1000 na 1000 na programu zinaweza kutumia thamani ya SYSTEM_HIGH_PRIORITY. Ikiwa conflict itatokea, Dirisha la "choser" linaonekana ili mtumiaji aweze kuamua.
Explicit intent inabainisha jina la darasa ambalo linawalenga:
Katika programu nyingine ili kufikia nia iliyotangazwa hapo awali unaweza kutumia:
Hizi zinawaruhusu programu nyingine kuchukua hatua kwa niaba ya programu yako, wakitumia utambulisho na ruhusa za programu yako. Kujenga Pending Intent inapaswa kuelezwa intent na hatua ya kutekeleza. Ikiwa intent iliyotangazwa si ya Moja kwa Moja (haijatangaza ni intent ipi inayoweza kuitwa) programu mbaya inaweza kutekeleza hatua iliyotangazwa kwa niaba ya programu ya mwathirika. Zaidi ya hayo, ikiwa hatua haijatangazwa, programu mbaya itakuwa na uwezo wa kufanya hatua yoyote kwa niaba ya mwathirika.
Tofauti na intents za awali, ambazo zinapokelewa na programu moja tu, broadcast intents zinaweza kupokelewa na programu nyingi. Hata hivyo, kuanzia toleo la API 14, ni mpossible kuweka programu ambayo inapaswa kupokea ujumbe kwa kutumia Intent.setPackage.
Vinginevyo, pia inawezekana kueleza ruhusa wakati wa kutuma broadcast. Programu inayopokea itahitaji kuwa na ruhusa hiyo.
Kuna aina mbili za Broadcasts: Kawaida (asynchronous) na Iliyopangwa (synchronous). Agizo linategemea kipaumbele kilichowekwa ndani ya kipengele cha mpokeaji. Kila programu inaweza kushughulikia, kupeleka au kuacha Broadcast.
Inawezekana kutuma broadcast kwa kutumia kazi sendBroadcast(intent, receiverPermission) kutoka kwa darasa la Context.
Unaweza pia kutumia kazi sendBroadcast kutoka kwa LocalBroadCastManager inahakikisha ujumbe hauondoki kwenye programu. Kwa kutumia hii hutahitaji hata kusafirisha kipengele cha mpokeaji.
Aina hii ya Broadcasts inaweza kufikiwa muda mrefu baada ya kutumwa. Hizi zilitolewa katika kiwango cha API 21 na inashauriwa usizitumie. Zinawaruhusu programu yoyote kunusa data, lakini pia kuibadilisha.
Ikiwa unapata kazi zinazojumuisha neno "sticky" kama sendStickyBroadcast au sendStickyBroadcastAsUser, angalia athari na jaribu kuondoa hizo.
Katika programu za Android, deep links zinatumika kuanzisha hatua (Intent) moja kwa moja kupitia URL. Hii inafanywa kwa kutangaza URL scheme maalum ndani ya shughuli. Wakati kifaa cha Android kinajaribu kufikia URL yenye scheme hii, shughuli iliyotangazwa ndani ya programu inazinduliwa.
Scheme lazima itangazwe katika AndroidManifest.xml faili:
Mpango kutoka kwa mfano uliopita ni examplescheme:// (zingatia pia category BROWSABLE)
Kisha, katika uwanja wa data, unaweza kubainisha host na path:
Ili kuweza kufikia kutoka kwenye wavuti, inawezekana kuweka kiungo kama:
Ili kupata msimbo utakaotekelezwa katika App, nenda kwenye shughuli inayoitwa na deeplink na tafuta kazi onNewIntent.
Jifunze jinsi ya kuita deep links bila kutumia kurasa za HTML.
Android Interface Definition Language (AIDL) imeundwa ili kuwezesha mawasiliano kati ya mteja na huduma katika programu za Android kupitia mawasiliano ya kati ya michakato (IPC). Kwa kuwa upatikanaji wa kumbukumbu ya mchakato mwingine moja kwa moja haukubaliki kwenye Android, AIDL inarahisisha mchakato kwa kuhamasisha vitu katika muundo unaoeleweka na mfumo wa uendeshaji, hivyo kurahisisha mawasiliano kati ya michakato tofauti.
Huduma Zilizofungwa: Huduma hizi hutumia AIDL kwa IPC, zikiwezesha shughuli au vipengele kuungana na huduma, kufanya maombi, na kupokea majibu. Njia ya onBind katika darasa la huduma ni muhimu kwa kuanzisha mwingiliano, ikifanya kuwa eneo muhimu kwa ukaguzi wa usalama kutafuta udhaifu.
Messenger: Ikifanya kazi kama huduma iliyofungwa, Messenger inarahisisha IPC kwa kuzingatia usindikaji wa data kupitia njia ya onBind. Ni muhimu kukagua njia hii kwa karibu kwa usimamizi usio salama wa data au utekelezaji wa kazi nyeti.
Binder: Ingawa matumizi ya moja kwa moja ya darasa la Binder si ya kawaida sana kutokana na ufafanuzi wa AIDL, ni muhimu kuelewa kwamba Binder inafanya kazi kama dereva wa kiwango cha kernel unawezesha uhamasishaji wa data kati ya maeneo ya kumbukumbu ya michakato tofauti. Kwa ufahamu zaidi, rasilimali inapatikana kwenye https://www.youtube.com/watch?v=O-UHvFjxwZ8.
Hizi ni pamoja na: Shughuli, Huduma, Vastika za Matangazo na Watoa Huduma.
Katika programu za Android, shughuli ni kama skrini, zikionyesha sehemu tofauti za kiolesura cha mtumiaji wa programu. Programu inaweza kuwa na shughuli nyingi, kila moja ikionyesha skrini ya kipekee kwa mtumiaji.
shughuli ya kuanza ni lango kuu la programu, inayozinduliwa unapobofya ikoni ya programu. Imefafanuliwa katika faili ya manifest ya programu kwa nia maalum za MAIN na LAUNCHER:
Sio programu zote zinahitaji shughuli ya kuzindua, hasa zile zisizo na kiolesura cha mtumiaji, kama huduma za nyuma.
Shughuli zinaweza kupatikana kwa programu nyingine au michakato kwa kuashiria kama "exported" katika hati. Mpangilio huu unaruhusu programu nyingine kuanzisha shughuli hii:
Hata hivyo, kufikia shughuli kutoka programu nyingine si hatari ya usalama kila wakati. Wasiwasi unatokea ikiwa data nyeti inashirikiwa vibaya, ambayo inaweza kusababisha uvujaji wa taarifa.
Mzunguko wa maisha wa shughuli uanza na njia ya onCreate, kuandaa UI na kuandaa shughuli kwa mwingiliano na mtumiaji.
Katika maendeleo ya Android, programu ina chaguo la kuunda aina ya Application darasa, ingawa si lazima. Wakati aina kama hiyo imefafanuliwa, inakuwa darasa la kwanza kuanzishwa ndani ya programu. Njia ya attachBaseContext, ikiwa imeanzishwa katika aina hii, inatekelezwa kabla ya njia ya onCreate. Mpangilio huu unaruhusu kuanzishwa mapema kabla ya sehemu nyingine za programu kuanza.
Services ni operatives za nyuma zinazoweza kutekeleza kazi bila kiolesura cha mtumiaji. Kazi hizi zinaweza kuendelea kukimbia hata wakati watumiaji wanapobadilisha programu, na kufanya huduma kuwa muhimu kwa operesheni za muda mrefu.
Huduma ni za kubadilika; zinaweza kuanzishwa kwa njia mbalimbali, ambapo Intents ndiyo njia kuu ya kuzizindua kama kiingilio cha programu. Mara huduma inapozinduliwa kwa kutumia njia ya startService, njia yake ya onStart inaanza kufanya kazi na inaendelea kukimbia hadi njia ya stopService itakapoitwa wazi. Vinginevyo, ikiwa jukumu la huduma linategemea muunganisho wa mteja hai, njia ya bindService inatumika kuunganisha mteja na huduma, ikihusisha njia ya onBind kwa ajili ya kupitisha data.
Matumizi ya kuvutia ya huduma ni pamoja na upigaji muziki wa nyuma au upataji wa data ya mtandao bila kuingilia mwingiliano wa mtumiaji na programu. Aidha, huduma zinaweza kufanywa kupatikana kwa michakato mingine kwenye kifaa hicho hicho kupitia exporting. Hii si tabia ya kawaida na inahitaji usanidi wazi katika faili ya Android Manifest:
Broadcast receivers hufanya kazi kama wasikilizaji katika mfumo wa ujumbe, ikiruhusu programu nyingi kujibu ujumbe sawa kutoka kwa mfumo. Programu inaweza kujiandikisha mpokeaji kwa njia mbili kuu: kupitia Manifest ya programu au kwa njia ya kidinamik ndani ya msimbo wa programu kupitia registerReceiver API. Katika Manifest, matangazo yanachujwa kwa ruhusa, wakati wapokeaji waliojiandikisha kwa njia ya kidinamik wanaweza pia kubainisha ruhusa wakati wa kujiandikisha.
Intent filters ni muhimu katika mbinu zote za kujiandikisha, zikiamua ni matangazo gani yanayochochea mpokeaji. Mara matangazo yanayolingana yanapotumwa, njia ya onReceive ya mpokeaji inaitwa, ikiruhusu programu kujibu ipasavyo, kama kubadilisha tabia kwa kujibu onyo la betri ya chini.
Matangazo yanaweza kuwa asynchronous, yakifika kwa wapokeaji wote bila mpangilio, au synchronous, ambapo wapokeaji wanapata matangazo kulingana na vipaumbele vilivyowekwa. Hata hivyo, ni muhimu kutambua hatari ya usalama, kwani programu yoyote inaweza kujipa kipaumbele ili kukamata tangazo.
Ili kuelewa kazi ya mpokeaji, angalia njia ya onReceive ndani ya darasa lake. Msimbo wa njia hii unaweza kubadilisha Intent iliyopokelewa, ikionyesha umuhimu wa uthibitisho wa data na wapokeaji, hasa katika Ordered Broadcasts, ambazo zinaweza kubadilisha au kuacha Intent.
Content Providers ni muhimu kwa kushiriki data iliyopangwa kati ya programu, ikisisitiza umuhimu wa kutekeleza ruhusa ili kuhakikisha usalama wa data. Wanaruhusu programu kufikia data kutoka vyanzo mbalimbali, ikiwa ni pamoja na hifadhidata, mifumo ya faili, au mtandao. Ruhusa maalum, kama readPermission na writePermission, ni muhimu kwa kudhibiti ufikiaji. Zaidi ya hayo, ufikiaji wa muda unaweza kutolewa kupitia mipangilio ya grantUriPermission katika manifest ya programu, ikitumia sifa kama path, pathPrefix, na pathPattern kwa udhibiti wa ufikiaji wa kina.
Uthibitisho wa ingizo ni muhimu ili kuzuia udhaifu, kama vile SQL injection. Content Providers zinasaidia operesheni za msingi: insert(), update(), delete(), na query(), zikifanikisha usimamizi wa data na kushiriki kati ya programu.
FileProvider, Content Provider maalum, inazingatia kushiriki faili kwa usalama. Inafafanuliwa katika manifest ya programu kwa sifa maalum za kudhibiti ufikiaji wa folda, zinazoonyeshwa na android:exported na android:resource zikielekeza kwenye mipangilio ya folda. Tahadhari inashauriwa wakati wa kushiriki saraka ili kuepuka kufichua data nyeti bila kukusudia.
Mfano wa tangazo la manifest kwa FileProvider:
Na mfano wa kufafanua folda zinazoshirikiwa katika filepaths.xml:
For further information check:
WebViews ni kama vivinjari vidogo vya wavuti ndani ya programu za Android, vinavyovuta maudhui ama kutoka kwenye wavuti au kutoka kwenye faili za ndani. Vinakabiliwa na hatari sawa na vivinjari vya kawaida, lakini kuna njia za kupunguza hatari hizi kupitia mipangilio maalum.
Android inatoa aina mbili kuu za WebView:
WebViewClient ni nzuri kwa HTML ya msingi lakini haisaidii kazi ya arifa ya JavaScript, ikihusisha jinsi mashambulizi ya XSS yanavyoweza kupimwa.
WebChromeClient inafanya kazi zaidi kama uzoefu kamili wa kivinjari cha Chrome.
Jambo muhimu ni kwamba vivinjari vya WebView havishiriki vidakuzi na kivinjari kikuu cha kifaa.
Kwa ajili ya kupakia maudhui, mbinu kama loadUrl, loadData, na loadDataWithBaseURL zinapatikana. Ni muhimu kuhakikisha kwamba URLs hizi au faili ni salama kutumia. Mipangilio ya usalama inaweza kudhibitiwa kupitia darasa la WebSettings. Kwa mfano, kuzima JavaScript kwa setJavaScriptEnabled(false) kunaweza kuzuia mashambulizi ya XSS.
JavaScript "Bridge" inaruhusu vitu vya Java kuingiliana na JavaScript, ikihitaji mbinu kuwekewa alama na @JavascriptInterface kwa usalama kuanzia Android 4.2.
Kuruhusu ufikiaji wa maudhui (setAllowContentAccess(true)) kunaruhusu WebViews kufikia Watoa Maudhui, ambayo inaweza kuwa hatari isipokuwa URLs za maudhui zihakikishwe kuwa salama.
Ili kudhibiti ufikiaji wa faili:
Kuzima ufikiaji wa faili (setAllowFileAccess(false)) kunapunguza ufikiaji wa mfumo wa faili, huku kukiwa na visamaha kwa mali fulani, kuhakikisha zinatumika tu kwa maudhui yasiyo nyeti.
Saini ya kidijitali ni lazima kwa programu za Android, kuhakikisha kwamba zimeandikwa kwa uhalisia kabla ya usakinishaji. Mchakato huu unatumia cheti kwa ajili ya utambulisho wa programu na lazima uhakikishwe na meneja wa pakiti wa kifaa wakati wa usakinishaji. Programu zinaweza kuwa zimejitia saini au kuthibitishwa na CA ya nje, kulinda dhidi ya ufikiaji usioidhinishwa na kuhakikisha programu inabaki bila kubadilishwa wakati wa usafirishaji wake kwa kifaa.
Kuanzia Android 4.2, kipengele kinachoitwa Verify Apps kinawaruhusu watumiaji kuangalia programu kwa usalama kabla ya usakinishaji. Mchakato huu wa uthibitishaji unaweza kuwatahadharisha watumiaji dhidi ya programu zenye hatari, au hata kuzuia usakinishaji wa zile zenye uharibifu mkubwa, kuimarisha usalama wa mtumiaji.
MDM solutions zinatoa uangalizi na usalama kwa vifaa vya simu kupitia Device Administration API. Zinahitaji usakinishaji wa programu ya Android ili kudhibiti na kulinda vifaa vya simu kwa ufanisi. Kazi kuu ni pamoja na kulazimisha sera za nywila, kulazimisha usimbaji wa hifadhi, na kuruhusu kufuta data kwa mbali, kuhakikisha udhibiti na usalama wa kina juu ya vifaa vya simu.
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)
