Serbian - Ht
HackTricks Training Twitter Linkedin Sponsor

Android Applications Basics

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Try Hard Security Group

Android Sigurnosni Model

Postoje dva sloja:

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

  • Sama aplikacija, koja omogućava developerima da izlože određene funkcionalnosti i konfigurišu sposobnosti aplikacije.

UID Separacija

Svaka aplikacija je dodeljena specifičan User ID. Ovo se radi prilikom instalacije aplikacije tako da aplikacija može da interaguje samo sa fajlovima koje poseduje njen User ID ili deljenim fajlovima. Zbog toga, samo aplikacija, određeni delovi OS-a i root korisnik mogu pristupiti podacima aplikacija.

Deljenje UID-a

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 vrednost android:sharedUserId u njihovim manifestima.

Izolacija

Android aplikacioni pesak omogućava pokretanje svake aplikacije kao zaseban proces pod zasebnim User ID-om. Svaki proces ima svoju virtuelnu mašinu, tako da kod aplikacije radi izolovano od drugih aplikacija. Od Android 5.0(L) SELinux je primenjen. U osnovi, SELinux odbija sve interakcije procesa i zatim kreira 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 fajlu. Uses-permission element označava ime tražene dozvole unutar name atributa. Takođe ima maxSdkVersion atribut koji zaustavlja traženje dozvola na verzijama višim od navedene. Imajte na umu 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

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

  • Nivo zaštite koji označava kako su dozvole dodeljene. Postoje četiri tipa:

  • Normalno: Koristi se kada nema poznatih pretnji aplikaciji. Korisniku nije potrebno da je odobri.

  • Opasno: Označava da dozvola daje traženoj aplikaciji neki povišen pristup. Korisnici su zamoljeni da ih odobre.

  • Potpis: Samo aplikacije potpisane istim sertifikatom kao i ona koja izvozi komponentu mogu dobiti dozvolu. Ovo je najjači tip zaštite.

  • PotpisIliSistem: Samo aplikacije potpisane istim sertifikatom kao i ona koja izvozi komponentu ili aplikacije koje se izvršavaju sa sistemskim nivoom pristupa mogu dobiti dozvole

Preinstalirane Aplikacije

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

  • One isporučene sa AOSP (Android OpenSource Project) ROM-om

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

  • Dodate od strane provajdera mobilnog telefona (ako je kupljen od njih)

Rootovanje

Da biste dobili root pristup fizičkom Android uređaju obično morate iskoristiti 1 ili 2 ranjivosti koje obično budu specifične za uređaj i verziju. Kada eksploatacija uspe, obično se Linux su binarni fajl kopira na lokaciju navedenu u korisnikovoj PATH env promenljivoj kao što je /system/xbin.

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

Imajte na umu da je proces rootovanja veoma opasan i može ozbiljno oštetiti uređaj

ROM-ovi

Moguće je zameniti OS instaliranjem prilagođenog firmware-a. To omogućava proširenje upotrebljivosti starog uređaja, zaobilazak softverskih ograničenja ili pristup najnovijem Android kodu. OmniROM i LineageOS su dva od najpopularnija firmware-a za korišćenje.

Imajte na umu da nije uvek potrebno rootovati uređaj da biste instalirali prilagođeni firmware. Neki proizvođači dozvoljavaju otključavanje njihovih bootloader-a na dobro dokumentovan i siguran način.

Posledice

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

Osnove Android Aplikacija

  • Format Android aplikacija se naziva APK format fajla. U osnovi je to ZIP fajl (preimenovanjem ekstenzije fajla u .zip, sadržaj može biti izvađen i pregledan).

  • 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, predstavlja kompilirani Java (ili Kotlin) kod koji aplikacija izvršava po podrazumevanim postavkama.

  • lib/

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

  • armeabi: kod za procesore na bazi ARM-a

  • armeabi-v7a: kod za ARMv7 i novije procesore

  • x86: kod za X86 procesore

  • mips: kod samo za MIPS procesore

  • assets/

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

  • res/

  • Sadrži resurse koji nisu kompilovani 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) bytecode. Ranije je Dalvik virtuelna mašina obrađivala ovaj bytecode, ali sada, Android Runtime (ART) preuzima kontrolu u novijim verzijama Androida.

Za obrnuti inženjering, Smali postaje ključan. To je ljudima čitljiva verzija DEX bytecode-a, delujući kao jezik asemblaža prevodeći izvorni kod u bytecode instrukcije. Smali i baksmali se odnose na alate za asembliranje i disasembliranje u ovom kontekstu.

Intents

Intents su osnovno sredstvo komunikacije između komponenti Android aplikacija ili sa drugim aplikacijama. Ovi objekti poruka takođe mogu prenositi podatke između aplikacija ili komponenti, slično kao što se GET/POST zahtevi koriste u HTTP komunikacijama.

Dakle, Intent je u osnovi poruka koja se prenosi između komponenti. Intents mogu biti usmereni ka određenim komponentama ili aplikacijama, ili mogu biti poslati bez određenog primaoca. Da bude jednostavno, Intent se može koristiti:

  • Za pokretanje Activity-ja, obično otvaranje korisničkog interfejsa za aplikaciju

  • Kao emitovanja za obaveštavanje sistema i aplikacija o promenama

  • Za pokretanje, zaustavljanje i komunikaciju sa pozadinskom uslugom

  • Za pristup podacima putem ContentProvidera

  • Kao povratni poziv za rukovanje događajima

Ako su ranjivi, Intents mogu biti korišćeni za izvođenje različitih napada.

Intent-Filter

Intent Filteri definišu kako aktivnost, usluga ili Broadcast Receiver mogu interagovati sa različitim tipovima Intents-a. U osnovi, opisuju sposobnosti ovih komponenti, kao što su koje akcije mogu izvršiti ili vrste emitovanja koje mogu obraditi. Glavno mesto za deklarisanje ovih filtera je unutar AndroidManifest.xml datoteke, iako je kodiranje za Broadcast Receivere 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 Intents-e koji se podudaraju sa deklarisanim kriterijumima.

Ključni aspekt Android komponenti (aktivnosti/usluga/content providera/broadcast receivera) je njihova vidljivost ili javni status. 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 razvojnike da eksplicitno zadrže ove komponente privatnim, osiguravajući da ne interaguju sa drugim aplikacijama nenamerno. To se postiže postavljanjem atributa exported na false u njihovim definicijama manifesta.

Osim toga, razvojnici imaju opciju da dodatno obezbede pristup ovim komponentama zahtevanjem određenih dozvola. permission atribut može biti postavljen da bi se naložilo da samo aplikacije sa određenom dozvolom mogu pristupiti komponenti, dodajući dodatni sloj sigurnosti i kontrole nad tim ko može interagovati sa njom.

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

Implicitni Intenti

Intenti se programski kreiraju korišćenjem konstruktora Intent:

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

Akcija prethodno deklarisane namere je ACTION_SEND i Dodatno je mailto Uri (Dodatno je dodatna informacija koju namera očekuje).

Ova namera treba da bude deklarisana unutar manifesta 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>

Intent-filter treba da se podudara sa akcijom, podacima i kategorijom da bi primio poruku.

Proces "Rešavanja namere" određuje koja aplikacija treba da primi svaku poruku. Ovaj proces uzima u obzir atribut prioriteta, koji se može postaviti u deklaraciji intent-filtera, i onaj sa većim prioritetom će biti izabran. Ovaj prioritet može biti postavljen između -1000 i 1000, a aplikacije mogu koristiti vrednost SYSTEM_HIGH_PRIORITY. Ako dođe do sukoba, pojavljuje se prozor "izbora" kako bi korisnik odlučio.

Eksplicitne namere

Eksplicitna namera navodi ime klase koju cilja:

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

U drugim aplikacijama, kako biste pristupili prethodno deklarisanoj nameri, možete koristiti:

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

Pending Intents

Ovi dozvoljavaju drugim aplikacijama da preduzmu radnje u ime vaše aplikacije, koristeći identitet i dozvole vaše aplikacije. Konstruisanje Pending Intenta treba specificirati nameru i radnju koju treba izvršiti. Ako deklarisana namera nije eksplicitna (ne deklariše koja namera može da je pozove), zlonamerna aplikacija može izvršiti deklarisane radnje u ime aplikacije žrtve. Štaviše, ako radnja nije specificirana, zlonamerna aplikacija će moći da izvrši bilo koju radnju u ime žrtve.

Broadcast Intents

Za razliku od prethodnih namera, koje prima samo jedna aplikacija, broadcast namerama mogu pristupiti više aplikacija. Međutim, od API verzije 14, moguće je specificirati aplikaciju koja treba da primi poruku korišćenjem Intent.setPackage.

Alternativno, takođe je moguće specificirati dozvolu prilikom slanja broadcasta. Aplikacija primaoc će morati da ima tu dozvolu.

Postoje dva tipa Broadcasta: Normalni (asinhroni) i Poređani (sinhroni). Redosled se zasniva na konfigurisanoj prioritetu unutar primaoca elementa. Svaka aplikacija može obraditi, proslediti 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 koji osigurava da poruka nikada ne napusti aplikaciju. Korišćenjem ovoga čak nećete morati ni da izvezete komponentu primaoca.

Ljepljivi Broadcasti

Ovaj tip Broadcasta može biti pristupan dugo nakon što su poslati. Ovi su zastareli od API nivoa 21 i preporučuje se da se ne koriste. Dozvoljavaju bilo kojoj aplikaciji da prisluškuje podatke, ali i da ih modifikuje.

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

Duboke veze / URL šeme

U Android aplikacijama, duboke veze se koriste za pokretanje radnje (Intent) direktno putem URL-a. To se postiže deklarisanjem specifične URL šeme unutar aktivnosti. Kada Android uređaj pokuša da pristupi URL-u sa ovom šemom, pokreće se određena aktivnost unutar aplikacije.

Šema se mora deklarisati u datoteci 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>
[...]

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

Zatim, u polju podataka, možete specificirati host i putanju:

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

Da biste pristupili sa 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 kôd koji će se izvršiti u aplikaciji, idite na aktivnost pozvanu pomoću dubinskog linka i potražite funkciju onNewIntent.

Saznajte kako pozvati dubinske linkove bez korišćenja HTML stranica.

AIDL - Android Interface Definition Language

Android Interface Definition Language (AIDL) dizajniran je za olakšavanje komunikacije između klijenta i servisa u Android aplikacijama putem međuprocesne komunikacije (IPC). Budući da direktno pristupanje memoriji drugog procesa nije dozvoljeno na Androidu, AIDL pojednostavljuje proces marshalling objekata u format koji razume operativni sistem, olakšavajući komunikaciju između različitih procesa.

Ključni koncepti

  • Povezani servisi: Ovi servisi 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 pokretanje interakcije, označavajući je kao važno područje za pregled sigurnosti u potrazi za ranjivostima.

  • Messenger: Funkcionišući kao povezani servis, Messenger olakšava IPC sa fokusom na obradi podataka putem metode onBind. Važno je pažljivo pregledati ovu metodu radi bilo kakvog nebezbednog rukovanja podacima ili izvršavanja osetljivih funkcija.

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

Komponente

Ove uključuju: Aktivnosti, Servise, Prijemnike emitovanja i Provajdere.

Aktivnost pokretača i druge aktivnosti

U Android aplikacijama, aktivnosti su poput ekrana koji prikazuju različite delove korisničkog interfejsa aplikacije. Aplikacija može imati mnogo aktivnosti, prikazujući svaka jedan jedinstveni ekran korisniku.

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

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

Nisu sve aplikacije potrebne aktivnosti pokretača, posebno one bez korisničkog interfejsa, poput pozadinskih usluga.

Aktivnosti mogu biti dostupne drugim aplikacijama ili procesima označavanjem kao "izložene" u manifestu. Ovo podešavanje omogućava drugim aplikacijama da pokrenu ovu aktivnost:

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

Međutim, pristupanje aktivnosti iz druge aplikacije nije uvek sigurnosni 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, postavljanjem korisničkog interfejsa i pripremom aktivnosti za interakciju sa korisnikom.

Podklasa aplikacije

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

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

Servisi

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

Servisi su veoma fleksibilni; mogu biti pokrenuti na različite načine, pri čemu su Intents primarni metod za njihovo pokretanje kao ulazna tačka aplikacije. Kada se servis pokrene korišćenjem metode startService, njegova metoda onStart se aktivira i nastavlja sa radom sve dok se eksplicitno ne pozove metoda stopService. Alternativno, ako je uloga servisa uslovljena aktivnom klijentskom konekcijom, koristi se metoda bindService za povezivanje klijenta sa servisom, angažujući metodu onBind za prenos podataka.

Interesantna primena servisa uključuje reprodukciju pozadinske muzike ili preuzimanje mrežnih podataka bez ometanja interakcije korisnika sa aplikacijom. Osim toga, servisi mogu biti dostupni drugim procesima na istom uređaju putem izvoza. Ovo nije podrazumevano ponašanje i zahteva eksplicitnu konfiguraciju u Android Manifest fajlu:

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

Broadcast Receivers

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

Filteri namere su ključni u oba metoda registracije, određujući koje emitovanja pokreću prijemnik. Kada se pošalje odgovarajuće emitovanje, poziva se metoda onReceive prijemnika, omogućavajući aplikaciji da reaguje u skladu, kao što je prilagođavanje ponašanja u odgovoru na upozorenje o niskom nivou baterije.

Emitovanja mogu biti ili asinhrona, dostižući sve prijemnike bez redosleda, ili sinhrona, gde prijemnici dobijaju emitovanje na osnovu postavljenih prioriteta. Međutim, važno je napomenuti potencijalni sigurnosni rizik, jer bilo koja aplikacija može sebe prioritetizovati da presretne emitovanje.

Da biste razumeli funkcionalnost prijemnika, potražite metodu onReceive unutar njegove klase. Kod ove metode može manipulisati primljenom namerom, ističući potrebu za validacijom podataka od strane prijemnika, posebno u Poređanim Emitovanjima, koja mogu modifikovati ili odbaciti nameru.

Provajder Sadržaja

Provajderi sadržaja su ključni za deljenje strukturiranih podataka između aplikacija, naglašavajući važnost implementiranja dozvola kako bi se osigurala sigurnost podataka. Oni omogućavaju aplikacijama pristup podacima iz različitih izvora, uključujući baze podataka, fajl sisteme ili veb. Specifične dozvole, poput readPermission i writePermission, su ključne za kontrolu pristupa. Dodatno, privremeni pristup može biti odobren putem podešavanja grantUriPermission u manifestu aplikacije, koristeći atribute poput path, pathPrefix i pathPattern za detaljnu kontrolu pristupa.

Validacija unosa je od suštinskog značaja kako bi se sprečile ranjivosti, poput SQL ubacivanja. Provajderi sadržaja podržavaju osnovne operacije: insert(), update(), delete() i query(), olakšavajući manipulaciju podacima i deljenje među aplikacijama.

FileProvider, specijalizovani Provajder Sadržaja, fokusira se na sigurno deljenje fajlova. Definisan je u manifestu aplikacije sa specifičnim atributima za kontrolu pristupa fasciklama, označenim sa android:exported i android:resource koji pokazuju konfiguracije fascikli. Preporučuje se oprez prilikom deljenja direktorijuma kako bi se izbeglo slučajno 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 za specificiranje deljenih fascikli u filepaths.xml datoteci:

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

Za dodatne informacije pogledajte:

WebViews

WebViews su kao mini web pregledači unutar Android aplikacija, koji prikazuju sadržaj ili sa weba ili iz lokalnih datoteka. Oni se suočavaju sa sličnim rizicima kao i obični pregledači, ali postoji način da se smanje ovi rizici kroz specifična podešavanja.

Android nudi dva glavna tipa WebView-a:

  • 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 se ponaša više kao potpuno iskustvo pregledača Chrome.

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

Za učitavanje sadržaja, dostupne su metode poput loadUrl, loadData, i loadDataWithBaseURL. Važno je osigurati da su ovi URL-ovi ili datoteke sigurne za korišćenje. Sigurnosna podešavanja mogu se upravljati putem klase WebSettings. Na primer, onemogućavanje JavaScript-a sa setJavaScriptEnabled(false) može sprečiti XSS napade.

JavaScript "Bridge" omogućava Java objektima da interaguju sa JavaScript-om, zahtevajući da se metode obeleže sa @JavascriptInterface radi sigurnosti od Android verzije 4.2 nadalje.

Dozvoljavanje pristupa sadržaju (setAllowContentAccess(true)) omogućava WebViews da pristupe Content Providers-u, što može biti rizično osim ako se URL-ovi sadržaja ne provere kao sigurni.

Za kontrolu pristupa datotekama:

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

Ostale komponente aplikacije i upravljanje mobilnim uređajima

Digitalno potpisivanje aplikacija

  • Digitalno potpisivanje je obavezno za Android aplikacije, osiguravajući da su autentično autorizovane pre instalacije. Ovaj proces koristi sertifikat za identifikaciju aplikacije i mora biti verifikovan od strane upravljača paketa uređaja prilikom instalacije. Aplikacije mogu biti samopotpisane ili sertifikovane od strane spoljnog CA, štiteći od neovlašćenog pristupa i osiguravajući da aplikacija ostane nepromenjena tokom isporuke na uređaj.

Provera aplikacija za unapređenu sigurnost

  • Počevši od Android 4.2, funkcija nazvana Provera aplikacija omogućava korisnicima da provere sigurnost aplikacija pre instalacije. Ovaj proces provere može upozoriti korisnike na potencijalno štetne aplikacije, ili čak sprečiti instalaciju posebno zlonamernih, unapređujući sigurnost korisnika.

Upravljanje mobilnim uređajima (MDM)

  • MDM rešenja pružaju nadzor i sigurnost za mobilne uređaje putem Device Administration API-ja. Zahtevaju instalaciju Android aplikacije radi efikasnog upravljanja i osiguranja mobilnih uređaja. Ključne funkcije uključuju nametanje pravila za lozinke, obaveznu enkripciju skladišta, i dozvolu za daljinsko brisanje podataka, osiguravajući sveobuhvatnu kontrolu i sigurnost 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);
}

Try Hard Security Group

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

PreviousAndroid Applications PentestingNextAndroid Task Hijacking

Last updated