Android Applications Basics

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Podrška HackTricks

• Proverite planove pretplate!

• Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.

• Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.

Android Bezbednosni Model

Postoje dva sloja:

• OS, koji drži instalirane aplikacije izolovane jedna od druge.

• sama aplikacija, koja omogućava programerima da izlože određene funkcionalnosti i konfigurišu mogućnosti aplikacije.

UID Razdvajanje

Svakoj aplikaciji se dodeljuje specifični User ID. Ovo se dešava tokom instalacije aplikacije tako da aplikacija može da komunicira samo sa datotekama koje pripadaju njenom User ID-u ili deljenim datotekama. Stoga, samo sama aplikacija, određeni delovi OS-a i root korisnik mogu pristupiti podacima aplikacije.

UID Deljenje

Dve aplikacije mogu biti konfigurisane da koriste isti UID. Ovo može biti korisno za deljenje informacija, ali ako je jedna od njih kompromitovana, podaci obe aplikacije će biti kompromitovani. Zato se ovo ponašanje ne preporučuje. Da bi delile isti UID, aplikacije moraju definisati istu android:sharedUserId vrednost u svojim manifestima.

Sandboxing

Android Application Sandbox omogućava da se svaka aplikacija pokreće kao poseban proces pod posebnim korisničkim ID-om. Svaki proces ima svoju virtuelnu mašinu, tako da se kod aplikacije izvršava u izolaciji od drugih aplikacija. Od Android 5.0(L) SELinux se primenjuje. U suštini, SELinux je odbio sve interakcije procesa i zatim stvorio politike da dozvoli samo očekivane interakcije između njih.

Dozvole

Kada instalirate aplikaciju i ona traži dozvole, aplikacija traži dozvole konfigurisane u uses-permission elementima u AndroidManifest.xml datoteci. uses-permission element označava naziv tražene dozvole unutar name atributa. Takođe ima maxSdkVersion atribut koji prestaje da traži dozvole na verzijama višim od one koja je navedena. Napomena da android aplikacije ne moraju tražiti sve dozvole na početku, mogu takođe tražiti dozvole dinamički, ali sve dozvole moraju biti deklarisane u manifestu.

Kada aplikacija izlaže funkcionalnost, može ograničiti pristup samo aplikacijama koje imaju određenu dozvolu. Element dozvole ima tri atributa:

• ime dozvole

• permission-group atribut, koji omogućava grupisanje povezanih dozvola.

• protection-level koji označava kako se dozvole dodeljuju. Postoje četiri vrste:

• Normal: Koristi se kada nema poznatih pretnji za aplikaciju. Korisnik nije obavezan da je odobri.

• Dangerous: Ukazuje da dozvola dodeljuje tražećoj aplikaciji neku povišenu pristupnost. Korisnici se traže da ih odobre.

• Signature: Samo aplikacije potpisane istim sertifikatom kao onaj koji izvozi komponentu mogu dobiti dozvolu. Ovo je najjači tip zaštite.

• SignatureOrSystem: Samo aplikacije potpisane istim sertifikatom kao onaj koji izvozi komponentu ili aplikacije koje rade sa pristupom na sistemskom nivou mogu dobiti dozvole.

Preinstalirane Aplikacije

Ove aplikacije se obično nalaze u /system/app ili /system/priv-app direktorijumima i neke od njih su optimizovane (možda čak nećete pronaći classes.dex datoteku). Ove aplikacije vredi proveriti jer ponekad rade sa previše dozvola (kao root).

• One koje dolaze sa AOSP (Android OpenSource Project) ROM-om

• Dodate od strane proizvođača uređaja

• Dodate od strane provajdera mobilnih telefona (ako su kupljene od njih)

Rootovanje

Da biste dobili root pristup na fizičkom android uređaju, obično morate iskoristiti 1 ili 2 ranjivosti koje su obično specifične za uređaj i verziju. Kada je eksploatacija uspela, obično se Linux su binarni fajl kopira na lokaciju koja je navedena u korisničkoj PATH env varijabli kao što je /system/xbin.

Kada je su binarni fajl konfiguran, koristi se druga Android aplikacija za interakciju sa su binarnim fajlom i obrađivanje zahteva za root pristup kao što su Superuser i SuperSU (dostupni u Google Play prodavnici).

Napomena da je proces rootovanja veoma opasan i može ozbiljno oštetiti uređaj.

ROM-ovi

Moguće je zameniti OS instaliranjem prilagođenog firmvera. Na ovaj način je moguće produžiti korisnost starog uređaja, zaobići softverska ograničenja ili dobiti pristup najnovijem Android kodu. OmniROM i LineageOS su dva od najpopularnijih firmvera za korišćenje.

Napomena da nije uvek potrebno rootovati uređaj da bi se instalirao prilagođeni firmver. Neki proizvođači dozvoljavaju otključavanje svojih bootloader-a na dobro dokumentovan i siguran način.

Implkacije

Kada je uređaj rootovan, svaka aplikacija može zatražiti pristup kao root. Ako zlonamerna aplikacija dobije taj pristup, može imati pristup gotovo svemu i moći će da ošteti telefon.

Osnovni principi Android Aplikacija

• Format Android aplikacija se naziva APK format datoteke. U suštini, to je ZIP datoteka (preimenovanjem ekstenzije datoteke u .zip, sadržaj se može ekstrahovati i pregledati).

• Sadržaj APK-a (nije iscrpan)

• AndroidManifest.xml

• resources.arsc/strings.xml

• resources.arsc: sadrži prekompilirane resurse, poput binarnog XML-a.

• res/xml/files_paths.xml

• META-INF/

• Ovde se nalazi sertifikat!

• classes.dex

• Sadrži Dalvik bajtkod, koji predstavlja kompajlirani Java (ili Kotlin) kod koji aplikacija izvršava po defaultu.

• lib/

• Sadrži nativne biblioteke, razdvojene po CPU arhitekturi u poddirektorijumima.

• armeabi: kod za ARM procesore

• armeabi-v7a: kod za ARMv7 i više procesore

• x86: kod za X86 procesore

• mips: kod samo za MIPS procesore

• assets/

• Čuva razne datoteke potrebne aplikaciji, potencijalno uključujući dodatne nativne biblioteke ili DEX datoteke, ponekad korišćene od strane autora malvera za prikrivanje dodatnog koda.

• res/

• Sadrži resurse koji nisu kompajlirani u resources.arsc

Dalvik & Smali

U Android razvoju, Java ili Kotlin se koriste za kreiranje aplikacija. Umesto korišćenja JVM-a kao u desktop aplikacijama, Android kompajlira ovaj kod u Dalvik Executable (DEX) bajtkod. Ranije je Dalvik virtuelna mašina upravljala ovim bajtkodom, ali sada, Android Runtime (ART) preuzima u novijim verzijama Androida.

Za obrnuto inženjerstvo, Smali postaje ključan. To je ljudski čitljiva verzija DEX bajtkoda, koja deluje kao asembler prevodeći izvorni kod u bajtkod instrukcije. Smali i baksmali se odnose na alate za asembler i disassembler u ovom kontekstu.

Intenti

Intenti su primarni način na koji Android aplikacije komuniciraju između svojih komponenti ili sa drugim aplikacijama. Ovi objekti poruka takođe mogu nositi podatke između aplikacija ili komponenti, slično kako se koriste GET/POST zahtevi u HTTP komunikaciji.

Dakle, Intent je u suštini poruka koja se prenosi između komponenti. Intenti mogu biti usmereni ka specifičnim komponentama ili aplikacijama, ili se mogu slati bez specifičnog primaoca. Jednostavno rečeno, Intent se može koristiti:

• Da pokrene Aktivnost, obično otvarajući korisnički interfejs za aplikaciju

• Kao emitovanja da obavesti sistem i aplikacije o promenama

• Da pokrene, zaustavi i komunicira sa pozadinskom uslugom

• Da pristupi podacima putem ContentProviders

• Kao povratni pozivi za obradu događaja

Ako su ranjivi, Intenti se mogu koristiti za izvođenje raznih napada.

Intent-Filter

Intent Filteri definišu kako aktivnost, usluga ili Broadcast Receiver mogu interagovati sa različitim tipovima Intent-a. U suštini, oni opisuju mogućnosti ovih komponenti, kao što su koje akcije mogu izvršiti ili koje vrste emitovanja mogu obraditi. Primarno mesto za deklarisanje ovih filtera je unutar AndroidManifest.xml datoteke, iako je za Broadcast Receivere kodiranje takođe opcija.

Intent Filteri se sastoje od kategorija, akcija i filtera podataka, sa mogućnošću uključivanja dodatnih metapodataka. Ova postavka omogućava komponentama da obrade specifične Intente koji se poklapaju sa deklarisanim kriterijumima.

Kritičan aspekt Android komponenti (aktivnosti/usluge/provideri sadržaja/broadcast receiveri) je njihova vidljivost ili javnost. Komponenta se smatra javnom i može interagovati sa drugim aplikacijama ako je exported sa vrednošću true ili ako je za nju deklarisan Intent Filter u manifestu. Međutim, postoji način za programere da eksplicitno zadrže ove komponente privatnim, osiguravajući da ne interaguju sa drugim aplikacijama nenamerno. Ovo se postiže postavljanjem exported atributa na false u njihovim manifest definicijama.

Pored toga, programeri imaju opciju da dodatno osiguraju pristup ovim komponentama zahtevajući specifične dozvole. permission atribut može biti postavljen da osigura da samo aplikacije sa dodeljenom dozvolom mogu pristupiti komponenti, dodajući dodatni sloj sigurnosti i kontrole nad tim ko može da interaguje sa njom.

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

Implicit Intents

Intenti se programatski kreiraju koristeći Intent konstruktor:

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

The Action of the previously declared intent is ACTION_SEND and the Extra is a mailto Uri (the Extra if the extra information the intent is expecting).

Ova namera treba da bude deklarisana unutar manifest-a kao u sledećem primeru:

<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 treba da odgovara akciji, podacima i kategoriji da bi primio poruku.

Proces "rezolucije intencija" određuje koja aplikacija treba da primi svaku poruku. Ovaj proces uzima u obzir atribut prioriteta, koji može biti postavljen u deklaraciji intent-filter-a, i ona sa višim prioritetom će biti odabrana. Ovaj prioritet može biti postavljen između -1000 i 1000, a aplikacije mogu koristiti SYSTEM_HIGH_PRIORITY vrednost. Ako dođe do konflikta, pojavljuje se "chooser" prozor kako bi korisnik mogao da odluči.

Eksplicitne Intencije

Eksplicitna intencija specificira naziv klase koju cilja:

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

U drugim aplikacijama, da biste pristupili prethodno deklarisanom nameru, možete koristiti:

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

Pending Intents

Ovi omogućavaju drugim aplikacijama da preduzimaju akcije u ime vaše aplikacije, koristeći identitet i dozvole vaše aplikacije. Prilikom konstruisanja Pending Intent-a, treba navesti intent i akciju koja se izvršava. Ako deklarisani intent nije Eksplicitan (ne navodi koji intent može da ga pozove), maliciozna aplikacija bi mogla da izvrši deklarisanu akciju u ime žrtvinske aplikacije. Štaviše, ako akcija nije navedena, maliciozna aplikacija će moći da izvrši bilo koju akciju u ime žrtve.

Broadcast Intents

Za razliku od prethodnih intent-a, koji se primaju samo od jedne aplikacije, broadcast intent-i mogu biti primljeni od više aplikacija. Međutim, od API verzije 14, moguće je odrediti aplikaciju koja treba da primi poruku koristeći Intent.setPackage.

Alternativno, takođe je moguće navesti dozvolu prilikom slanja broadcast-a. Aplikacija primaoc će morati da ima tu dozvolu.

Postoje dva tipa Broadcast-a: Normalni (asinkroni) i Poručeni (sinhroni). Redosled se zasniva na konfigurisanoj prioritetu unutar elementa primaoca. Svaka aplikacija može obraditi, preneti ili odbaciti Broadcast.

Moguće je poslati broadcast koristeći funkciju sendBroadcast(intent, receiverPermission) iz klase Context. Takođe možete koristiti funkciju sendBroadcast iz LocalBroadCastManager koja osigurava da poruka nikada ne napusti aplikaciju. Koristeći ovo, nećete ni morati da izvozite komponentu primaoca.

Sticky Broadcasts

Ova vrsta Broadcast-a može se pristupiti dugo nakon što su poslati. Oni su obeleženi kao zastareli u API nivou 21 i preporučuje se da se ne koriste. Oni omogućavaju bilo kojoj aplikaciji da prisluškuje podatke, ali i da ih modifikuje.

Ako pronađete funkcije koje sadrže reč "sticky" kao što su sendStickyBroadcast ili sendStickyBroadcastAsUser, proverite uticaj i pokušajte da ih uklonite.

Deep links / URL schemes

U Android aplikacijama, deep links se koriste za pokretanje akcije (Intent) direktno putem URL-a. To se postiže deklarisanjem specifičnog URL shema unutar aktivnosti. Kada Android uređaj pokuša da pristupi URL-u sa ovom shemom, određena aktivnost unutar aplikacije se pokreće.

Shema mora biti deklarisana u AndroidManifest.xml datoteci:

[...]
<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>
[...]

Šema iz prethodnog primera je exampleapp:// (obratite pažnju i na category BROWSABLE)

Zatim, u polju podataka, možete navesti host i path:

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

Da biste mu pristupili putem veba, moguće je postaviti link kao:

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

Da biste pronašli kod koji će biti izvršen u aplikaciji, idite na aktivnost koju poziva deeplink i potražite funkciju onNewIntent.

Saznajte kako da pozovete deep linkove bez korišćenja HTML stranica.

AIDL - Android Interfejs Definicija Jezika

Android Interfejs Definicija Jezika (AIDL) je dizajniran za olakšavanje komunikacije između klijenta i servisa u Android aplikacijama putem interprocesne komunikacije (IPC). Pošto direktan pristup memoriji drugog procesa nije dozvoljen na Androidu, AIDL pojednostavljuje proces maršalizovanjem objekata u format koji operativni sistem razume, čime olakšava komunikaciju između različitih procesa.

Ključni Koncepti

• Povezani Servisi: Ove usluge koriste AIDL za IPC, omogućavajući aktivnostima ili komponentama da se povežu sa servisom, šalju zahteve i primaju odgovore. Metoda onBind u klasi servisa je ključna za započinjanje interakcije, označavajući je kao vitalno područje za bezbednosnu reviziju u potrazi za ranjivostima.

• Messenger: Kao povezani servis, Messenger olakšava IPC sa fokusom na obradu podataka putem metode onBind. Bitno je pažljivo pregledati ovu metodu zbog bilo kakvog nesigurnog rukovanja podacima ili izvršavanja osetljivih funkcija.

• Binder: Iako je direktna upotreba klase Binder manje uobičajena zbog AIDL-ove apstrakcije, korisno je razumeti da Binder deluje kao drajver na nivou jezgra koji olakšava prenos podataka između memorijskih prostora različitih procesa. Za dalju pomoć, resurs je dostupan na https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Komponente

Ove uključuju: Aktivnosti, Servise, Broadcast Receiver-e i Provajdere.

Aktivnost Pokretača i druge aktivnosti

U Android aplikacijama, aktivnosti su poput ekrana, prikazujući različite delove korisničkog interfejsa aplikacije. Aplikacija može imati mnogo aktivnosti, od kojih svaka predstavlja jedinstveni ekran za korisnika.

Aktivnost pokretača je glavni ulaz u aplikaciju, pokreće se kada dodirnete ikonu aplikacije. Definisana je u manifest fajlu aplikacije sa specifičnim MAIN i LAUNCHER intencijama:

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

Неће све апликације требати ланчер активност, посебно оне без корисничког интерфејса, као што су позадинске услуге.

Активности могу бити доступне другим апликацијама или процесима означавањем као "извозне" у манифесту. Ова подешавања омогућавају другим апликацијама да покрену ову активност:

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

Međutim, pristupanje aktivnosti iz druge aplikacije nije uvek bezbednosni rizik. Briga se javlja ako se osetljivi podaci dele nepravilno, što može dovesti do curenja informacija.

Životni ciklus aktivnosti počinje sa onCreate metodom, postavljajući UI i pripremajući aktivnost za interakciju sa korisnikom.

Podklasa Aplikacije

U Android razvoju, aplikacija ima opciju da kreira podklasu Application klase, iako to nije obavezno. Kada je takva podklasa definisana, ona postaje prva klasa koja se instancira unutar aplikacije. attachBaseContext metoda, ako je implementirana u ovoj podklasi, izvršava se pre onCreate metode. Ova postavka omogućava ranu inicijalizaciju pre nego što ostatak aplikacije počne.

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

Services

Services su pozadinski operativci sposobni za izvršavanje zadataka bez korisničkog interfejsa. Ovi zadaci mogu nastaviti da se izvršavaju čak i kada korisnici pređu na različite aplikacije, što čini servise ključnim za dugotrajne operacije.

Servisi su svestrani; mogu se pokrenuti na različite načine, pri čemu su Intents primarna metoda za njihovo pokretanje kao ulaznu tačku aplikacije. Kada se servis pokrene koristeći metodu startService, njegova metoda onStart počinje da se izvršava i nastavlja da radi dok se eksplicitno ne pozove metoda stopService. Alternativno, ako je uloga servisa zavisna od aktivne klijentske veze, koristi se metoda bindService za povezivanje klijenta sa servisom, angažujući metodu onBind za prenos podataka.

Zanimljiva primena servisa uključuje reprodukciju muzike u pozadini ili preuzimanje mrežnih podataka bez ometanja interakcije korisnika sa aplikacijom. Štaviše, servisi se mogu učiniti dostupnim drugim procesima na istom uređaju putem izvoza. Ovo nije podrazumevano ponašanje i zahteva eksplicitnu konfiguraciju u Android Manifest datoteci:

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

Broadcast Receivers

Broadcast receivers deluju kao slušatelji u sistemu poruka, omogućavajući više aplikacija da reaguju na iste poruke iz sistema. Aplikacija može registrovati prijemnik na dva osnovna načina: kroz Manifest aplikacije ili dinamički unutar koda aplikacije putem registerReceiver API-ja. U Manifestu, emitovanja se filtriraju sa dozvolama, dok dinamički registrovani prijemnici takođe mogu specificirati dozvole prilikom registracije.

Intent filteri su ključni u obe metode registracije, određujući koja emitovanja aktiviraju prijemnik. Kada se pošalje odgovarajuće emitovanje, poziva se onReceive metoda prijemnika, omogućavajući aplikaciji da reaguje u skladu sa tim, kao što je prilagođavanje ponašanja u odgovoru na upozorenje o niskoj bateriji.

Emitovanja mogu biti asinhrona, dostižući sve prijemnike bez reda, ili sinhrona, gde prijemnici dobijaju emitovanje na osnovu postavljenih prioriteta. Međutim, važno je napomenuti potencijalni bezbednosni rizik, jer svaka aplikacija može dati prioritet sebi da presretne emitovanje.

Da biste razumeli funkcionalnost prijemnika, potražite onReceive metodu unutar njegove klase. Kod ove metode može manipulisati primljenim Intentom, naglašavajući potrebu za validacijom podataka od strane prijemnika, posebno u Ordered Broadcasts, koji mogu modifikovati ili odbaciti Intent.

Content Provider

Content Providers su ključni za deljenje strukturiranih podataka između aplikacija, naglašavajući važnost implementacije dozvola za obezbeđivanje bezbednosti podataka. Oni omogućavaju aplikacijama da pristupaju podacima iz različitih izvora, uključujući baze podataka, datotečne sisteme ili web. Specifične dozvole, kao što su readPermission i writePermission, su ključne za kontrolu pristupa. Pored toga, privremeni pristup može biti odobren putem grantUriPermission podešavanja u manifestu aplikacije, koristeći atribute kao što su path, pathPrefix i pathPattern za detaljnu kontrolu pristupa.

Validacija unosa je od suštinskog značaja za sprečavanje ranjivosti, kao što je SQL injekcija. Content Providers podržavaju osnovne operacije: insert(), update(), delete(), i query(), olakšavajući manipulaciju i deljenje podataka među aplikacijama.

FileProvider, specijalizovani Content Provider, fokusira se na sigurno deljenje datoteka. Definisan je u manifestu aplikacije sa specifičnim atributima za kontrolu pristupa folderima, označenim sa android:exported i android:resource koji ukazuju na konfiguracije foldera. Preporučuje se oprez prilikom deljenja direktorijuma kako bi se izbeglo nenamerno izlaganje osetljivih podataka.

Primer deklaracije manifesta za 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>

I primer specifikovanja deljenih foldera u filepaths.xml:

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

For further information check:

• Android Developers: Content Providers

• Android Developers: FileProvider

WebViews

WebViews su kao mini web pregledači unutar Android aplikacija, koji preuzimaju sadržaj ili sa interneta ili iz lokalnih datoteka. Suočen su sa sličnim rizicima kao obični pregledači, ali postoje načini da se smanje ovi rizici kroz specifične postavke.

Android nudi dva glavna tipa WebView:

• WebViewClient je odličan za osnovni HTML, ali ne podržava JavaScript alert funkciju, što utiče na to kako se XSS napadi mogu testirati.

• WebChromeClient deluje više kao potpuno iskustvo Chrome pregledača.

Ključna tačka je da WebView pregledači ne dele kolačiće sa glavnim pregledačem uređaja.

Za učitavanje sadržaja, dostupne su metode kao što su loadUrl, loadData, i loadDataWithBaseURL. Ključno je osigurati da su ovi URL-ovi ili datoteke sigurni za korišćenje. Bezbednosne postavke mogu se upravljati putem WebSettings klase. Na primer, onemogućavanje JavaScripta sa setJavaScriptEnabled(false) može sprečiti XSS napade.

JavaScript "Bridge" omogućava Java objektima da komuniciraju sa JavaScript-om, zahtevajući da metode budu označene sa @JavascriptInterface radi bezbednosti od Android 4.2 nadalje.

Dozvoljavanje pristupa sadržaju (setAllowContentAccess(true)) omogućava WebViews pristup Content Providers, što može predstavljati rizik osim ako su URL-ovi sadržaja verifikovani kao sigurni.

Da biste kontrolisali pristup datotekama:

• Onemogućavanje pristupa datotekama (setAllowFileAccess(false)) ograničava pristup datotečnom sistemu, sa izuzecima za određene resurse, osiguravajući da se koriste samo za nesenzitivni sadržaj.

Other App Components and Mobile Device Management

Digital Signing of Applications

• Digitalno potpisivanje je obavezno za Android aplikacije, osiguravajući da su autentično napisane pre instalacije. Ovaj proces koristi sertifikat za identifikaciju aplikacije i mora biti verifikovan od strane menadžera paketa uređaja prilikom instalacije. Aplikacije mogu biti samo-potpisane ili sertifikovane od strane eksternog CA, štiteći od neovlašćenog pristupa i osiguravajući da aplikacija ostane neizmenjena tokom isporuke na uređaj.

App Verification for Enhanced Security

• Počevši od Android 4.2, funkcija pod nazivom Verifikacija aplikacija omogućava korisnicima da provere aplikacije za bezbednost pre instalacije. Ovaj proces verifikacije može upozoriti korisnike na potencijalno štetne aplikacije, ili čak sprečiti instalaciju posebno zlonamernih, poboljšavajući bezbednost korisnika.

Mobile Device Management (MDM)

• MDM rešenja pružaju nadzor i bezbednost za mobilne uređaje putem Device Administration API. Oni zahtevaju instalaciju Android aplikacije za efikasno upravljanje i obezbeđivanje mobilnih uređaja. Ključne funkcije uključuju sprovođenje politika lozinki, obavezno šifrovanje skladišta, i dozvoljavanje daljinskog brisanja podataka, osiguravajući sveobuhvatan nadzor i bezbednost nad mobilnim uređajima.

// 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);
}

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Podržite HackTricks

• Proverite planove pretplate!

• Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.

• Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.