În procesul de analiză a unei aplicații mobile, identificarea permisiunilor solicitate și a API-urilor utilizate este o etapă esențială. Aceste elemente oferă indicii clare despre ce accesuri își rezervă aplicația asupra sistemului și ce comportamente potențial riscante pot fi declanșate. Deși permisiunile sunt vizibile într-un fișier dedicat – AndroidManifest.xml – adevărata putere de înțelegere vine din corelarea acestora cu apelurile efective către clase și metode API, descoperite în codul aplicației.
De ce sunt permisiunile importante?
Permisiunile definesc ceea ce poate și nu poate face o aplicație într-un dispozitiv Android. Unele sunt considerate „normale” și sunt acordate automat (ex: acces la internet), în timp ce altele sunt „periculoase” și trebuie aprobate de utilizator (ex: acces la cameră, microfon, contacte, SMS). O aplicație care solicită multiple permisiuni de nivel înalt, fără un motiv clar, devine suspectă. Din perspectiva securității, permisiunile sunt adesea poarta de intrare către comportamente abuzive sau colectări de date nedocumentate.
Manifestul aplicației oferă lista permisiunilor declarate. Dar analiza trebuie să meargă mai departe: să identifice dacă acele permisiuni sunt și folosite, unde sunt folosite și în ce condiții. Este posibil, de exemplu, ca o aplicație să declare acces la locație dar să nu o folosească nicăieri – sau dimpotrivă, să o folosească intens în fundal, fără notificare.
Exemple de permisiuni considerate riscante:
🔹 READ_SMS, RECEIVE_SMS – oferă acces complet la mesajele text, pot fi folosite pentru interceptarea codurilor 2FA
🔹 RECORD_AUDIO, CAMERA – permit activarea microfonului sau camerei fără consimțământ explicit (dacă utilizatorul a aprobat la început)
🔹 ACCESS_FINE_LOCATION – poziționare GPS precisă, sensibilă în combinație cu alte date
🔹 READ_CONTACTS, READ_CALL_LOG – oferă acces la rețeaua personală a utilizatorului
🔹 SYSTEM_ALERT_WINDOW – permite desenarea de elemente peste alte aplicații (folosit frecvent de malware)
🔹 REQUEST_INSTALL_PACKAGES – poate instala aplicații suplimentare fără a trece prin Play Store
Un comportament uzual în aplicațiile suspecte este să grupeze mai multe astfel de permisiuni, fără justificare clară în funcționalitate.
API-uri și clase suspecte
Dincolo de permisiuni, un element mai subtil și tehnic este prezența unor apeluri către API-uri Android sau biblioteci externe care pot semnala comportamente ascunse. Acestea nu sunt vizibile pentru utilizator, dar pot fi descoperite în timpul analizei statice cu instrumente precum JADX sau MobSF.
Printre cele mai comune API-uri de interes în analiza de securitate se numără:
🔹 LocationManager.getLastKnownLocation() – obține poziția recentă
🔹 SmsManager.sendTextMessage() – trimite SMS-uri direct, fără aplicația default
🔹 TelephonyManager.getDeviceId() – obține IMEI-ul (interzis începând cu Android 10 fără permisiune specială)
🔹 MediaRecorder.start() – poate porni înregistrarea audio/video
🔹 Runtime.getRuntime().exec() – permite executarea de comenzi în shell
🔹 WebView.loadUrl() – poate injecta conținut într-o interfață web controlată de aplicație
🔹 HttpURLConnection sau OkHttpClient – vizibile în orice aplicație care face trafic de rețea, dar pot indica și exfiltrare de date
Unele aplicații încorporează și SDK-uri comerciale opace, care folosesc propriile metode obscure pentru colectarea de date, analytics sau tracking. Acestea pot include funcționalități greu de detectat la o simplă analiză vizuală, dar pot fi identificate prin inspecția bibliotecilor și a traficului rețelei (vom discuta în lecția despre analiza dinamică).
Strategii de analiză: ce verifici și cum interpretezi
Analiza corectă implică atât citirea manifestului, cât și parcurgerea claselor pentru a verifica dacă și cum sunt apelate metodele relevante. Astfel, poți separa permisiunile „de formă” (nerelevante în cod) de cele folosite activ, și poți verifica dacă aplicația aplică vreo formă de control sau filtrare (ex: verifică dacă permisiunea e acordată, sau o folosește oricum).
Recomandări de analiză:
🔹 Caută metode care accesează date personale (ex: getContacts, getAccounts)
🔹 Verifică dacă aplicația apelează checkSelfPermission sau requestPermissions
🔹 Explorează dacă aceste permisiuni sunt legate de funcționalitatea principală sau sunt ascunse în activități secundare
🔹 Notează apariția unor clase neobișnuite, cu nume ofuscate sau generice (ex: a.a.a()), și urmărește ce fac
Un caz clasic este o aplicație de lanternă care cere acces la locație, contactele și apeluri. Funcționalitatea declarată nu justifică astfel de accesuri. Un alt exemplu: o aplicație de rețea socială care trimite periodic SMS-uri automate fără intervenția utilizatorului.
Limitări și context
Este important să înțelegi că o permisiune riscantă nu implică automat o intenție malițioasă. Unele aplicații au funcționalități legitime care justifică aceste accesuri (ex: aplicații de ride-sharing care accesează GPS-ul și microfonul pentru apeluri).
De aceea, analiza trebuie pusă în context: cine e dezvoltatorul?, ce reputație are aplicația?, ce trafic de rețea generează?, unde sunt trimise datele?. Doar corelând aceste aspecte poți ajunge la o concluzie solidă privind riscurile reale.