Android Applications Basics
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
İki katman vardır:
OS, kurulu uygulamaları birbirinden izole tutar.
uygulamanın kendisi, geliştiricilerin belirli işlevleri açmasına izin verir ve uygulama yeteneklerini yapılandırır.
Her uygulamaya belirli bir Kullanıcı Kimliği atanır. Bu, uygulamanın yüklenmesi sırasında yapılır, böylece uygulama yalnızca kendi Kullanıcı Kimliğine ait dosyalarla veya paylaşılan dosyalarla etkileşimde bulunabilir. Bu nedenle, yalnızca uygulamanın kendisi, OS'nin belirli bileşenleri ve root kullanıcısı uygulama verilerine erişebilir.
İki uygulama aynı UID'yi kullanacak şekilde yapılandırılabilir. Bu, bilgi paylaşmak için yararlı olabilir, ancak bunlardan biri tehlikeye girerse, her iki uygulamanın verileri de tehlikeye girecektir. Bu nedenle bu davranış tavsiye edilmez.
Aynı UID'yi paylaşmak için, uygulamalar manifestolarında aynı android:sharedUserId değerini tanımlamalıdır.
Android Uygulama Sandbox'ı, her uygulamanın ayrı bir kullanıcı kimliği altında ayrı bir işlem olarak çalışmasına izin verir. Her işlem kendi sanal makinesine sahiptir, bu nedenle bir uygulamanın kodu diğer uygulamalardan izole bir şekilde çalışır. Android 5.0(L) itibarıyla SELinux uygulanmaktadır. Temelde, SELinux tüm işlem etkileşimlerini reddetti ve ardından aralarındaki beklenen etkileşimlere yalnızca izin vermek için politikalar oluşturdu.
Bir uygulama yüklediğinizde ve izinler istediğinde, uygulama AndroidManifest.xml dosyasındaki uses-permission öğelerinde yapılandırılan izinleri istemektedir. uses-permission öğesi, istenen iznin adını name özniteliği içinde belirtir. Ayrıca, belirtilen sürümden daha yüksek sürümlerde izin istemeyi durduran maxSdkVersion özniteliğine de sahiptir.
Android uygulamalarının başlangıçta tüm izinleri istemesi gerekmediğini, dinamik olarak da izin isteyebileceğini unutmayın, ancak tüm izinler manifestoda belirtilmelidir.
Bir uygulama işlevsellik sunduğunda, yalnızca belirli bir izne sahip uygulamalara erişimi sınırlayabilir. Bir izin öğesinin üç özniteliği vardır:
İznin adı
İzin grubu özniteliği, ilgili izinleri gruplamak için kullanılır.
İzinlerin nasıl verildiğini belirten koruma seviyesi. Dört tür vardır:
Normal: Uygulama için bilinen bir tehdit yoksa kullanılır. Kullanıcının onaylaması gerekmez.
Tehlikeli: İznin, istek yapan uygulamaya bazı yükseltilmiş erişim sağladığını belirtir. Kullanıcılardan onay istenir.
İmza: Yalnızca bileşeni dışa aktaranla aynı sertifika ile imzalanmış uygulamalara izin verilir. Bu, en güçlü koruma türüdür.
İmza veya Sistem: Yalnızca bileşeni dışa aktaranla aynı sertifika ile imzalanmış uygulamalara veya sistem düzeyinde erişimle çalışan uygulamalara izin verilir.
Bu uygulamalar genellikle /system/app veya /system/priv-app dizinlerinde bulunur ve bazıları optimize edilmiştir (belki de classes.dex dosyasını bile bulamazsınız). Bu uygulamalar, bazen çok fazla izinle çalıştıkları için kontrol edilmeye değerdir (root olarak).
AOSP (Android Açık Kaynak Projesi) ROM ile birlikte gelenler
Cihaz üreticisi tarafından eklenenler
Hücresel telefon sağlayıcısı tarafından eklenenler (eğer onlardan satın alındıysa)
Bir fiziksel android cihazda root erişimi elde etmek için genellikle 1 veya 2 güvenlik açığını istismar etmeniz gerekir; bu genellikle cihaz ve sürüm için özgüdüsel olur.
İstismar çalıştığında, genellikle Linux su ikili dosyası, kullanıcının PATH ortam değişkeninde belirtilen bir konuma, örneğin /system/xbin'e kopyalanır.
Su ikili dosyası yapılandırıldıktan sonra, su ikili dosyası ile etkileşimde bulunmak ve root erişim taleplerini işlemek için başka bir Android uygulaması kullanılır; bu uygulamalar Superuser ve SuperSU'dur (Google Play mağazasında mevcuttur).
Rootlama işleminin çok tehlikeli olduğunu ve cihazı ciddi şekilde zarar verebileceğini unutmayın.
Özel bir yazılım yükleyerek işletim sistemini değiştirmek mümkündür. Bunu yaparak, eski bir cihazın kullanımını uzatmak, yazılım kısıtlamalarını aşmak veya en son Android koduna erişmek mümkündür. OmniROM ve LineageOS, kullanılacak en popüler yazılımlardan ikisidir.
Cihazı rootlamak her zaman gerekli değildir; bazı üreticiler, bootloader'larını iyi belgelenmiş ve güvenli bir şekilde kilidini açmaya izin verir.
Bir cihaz rootlandığında, herhangi bir uygulama root olarak erişim talep edebilir. Kötü niyetli bir uygulama bunu elde ederse, neredeyse her şeye erişimi olacaktır ve telefonu zarar verebilir.
Android uygulamalarının formatı APK dosya formatı olarak adlandırılır. Temelde bir ZIP dosyasıdır (dosya uzantısını .zip olarak değiştirerek, içerikler çıkarılabilir ve görüntülenebilir).
APK İçerikleri (kapsamlı değil)
AndroidManifest.xml
resources.arsc/strings.xml
resources.arsc: ikili XML gibi önceden derlenmiş kaynakları içerir.
res/xml/files_paths.xml
META-INF/
Sertifikanın bulunduğu yer burasıdır!
classes.dex
Uygulamanın varsayılan olarak çalıştırdığı derlenmiş Java (veya Kotlin) kodunu temsil eden Dalvik bytecode içerir.
lib/
CPU mimarisine göre alt dizinlerde ayrılmış yerel kütüphaneleri barındırır.
armeabi: ARM tabanlı işlemciler için kod
armeabi-v7a: ARMv7 ve daha yüksek tabanlı işlemciler için kod
x86: X86 işlemciler için kod
mips: yalnızca MIPS işlemcileri için kod
assets/
Uygulamanın ihtiyaç duyduğu çeşitli dosyaları depolar; bunlar bazen kötü amaçlı yazılım yazarları tarafından ek kodu gizlemek için kullanılan ek yerel kütüphaneler veya DEX dosyaları içerebilir.
res/
resources.arsc içine derlenmemiş kaynakları içerir.
Android geliştirmede, Java veya Kotlin uygulama oluşturmak için kullanılır. Masaüstü uygulamalarındaki gibi JVM kullanmak yerine, Android bu kodu Dalvik Executable (DEX) bytecode'a derler. Daha önce, Dalvik sanal makinesi bu bytecode'u yönetiyordu, ancak şimdi, daha yeni Android sürümlerinde Android Runtime (ART) devralmıştır.
Tersine mühendislik için, Smali kritik hale gelir. DEX bytecode'un insan tarafından okunabilir versiyonudur ve kaynak kodunu bytecode talimatlarına çevirerek montaj dili gibi çalışır. Smali ve baksmali, bu bağlamda montaj ve ayrıştırma araçlarını ifade eder.
Niyetler, Android uygulamalarının bileşenleri arasında veya diğer uygulamalarla iletişim kurmanın birincil yoludur. Bu mesaj nesneleri, uygulamalar veya bileşenler arasında veri taşıyabilir; bu, HTTP iletişimlerinde GET/POST isteklerinin nasıl kullanıldığına benzer.
Yani bir Niyet, temelde bileşenler arasında iletilen bir mesajdır. Niyetler belirli bileşenlere veya uygulamalara yönlendirilebilir veya belirli bir alıcı olmadan gönderilebilir. Basit olmak gerekirse, Niyet şu amaçlarla kullanılabilir:
Bir Aktivite başlatmak, genellikle bir uygulama için bir kullanıcı arayüzü açmak
Sistemi ve uygulamaları değişiklikler hakkında bilgilendirmek için yayınlar olarak
Arka planda bir hizmeti başlatmak, durdurmak ve onunla iletişim kurmak
ContentProviders aracılığıyla verilere erişmek
Olayları işlemek için geri çağırmalar olarak
Eğer savunmasızsa, Niyetler çeşitli saldırılar gerçekleştirmek için kullanılabilir.
Niyet Filtreleri, bir aktivite, hizmet veya Yayın Alıcısının farklı türdeki Niyetlerle nasıl etkileşimde bulunabileceğini tanımlar. Temelde, bu bileşenlerin hangi eylemleri gerçekleştirebileceği veya hangi tür yayınları işleyebileceği gibi yeteneklerini tanımlar. Bu filtreleri tanımlamanın birincil yeri AndroidManifest.xml dosyasıdır, ancak Yayın Alıcıları için kodlama da bir seçenektir.
Niyet Filtreleri, kategoriler, eylemler ve veri filtrelerinden oluşur ve ek meta verilerin dahil edilmesi mümkündür. Bu yapı, bileşenlerin belirtilen kriterlere uyan belirli Niyetleri işleyebilmesini sağlar.
Android bileşenlerinin (aktivite/hizmet/içerik sağlayıcıları/yayın alıcıları) kritik bir yönü, görünürlükleri veya kamusal durumlarıdır. Bir bileşen, exported değeri true olarak ayarlandığında kamuya açık kabul edilir ve diğer uygulamalarla etkileşimde bulunabilir. Ancak, geliştiricilerin bu bileşenleri özel tutarak, diğer uygulamalarla istemeden etkileşimde bulunmamalarını sağlamak için bir yolu vardır. Bu, exported özniteliğini manifest tanımlarında false olarak ayarlayarak gerçekleştirilir.
Ayrıca, geliştiricilerin bu bileşenlere erişimi daha da güvence altına almak için belirli izinler talep etme seçeneği vardır. permission özniteliği, yalnızca belirlenen izne sahip uygulamaların bileşene erişebilmesini sağlamak için ayarlanabilir ve bu, kimlerin etkileşimde bulunabileceği üzerinde ek bir güvenlik ve kontrol katmanı ekler.
Niyetler, bir Niyet yapıcısı kullanılarak programatik olarak oluşturulur:
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).
Bu intent, aşağıdaki örnekte olduğu gibi manifest içinde tanımlanmalıdır:
Bir intent-filter'ın bir mesajı alabilmesi için action, data ve category ile eşleşmesi gerekir.
"Intent çözümleme" süreci, her mesajı hangi uygulamanın alması gerektiğini belirler. Bu süreç, intent-filter bildirimi içinde ayarlanabilen öncelik niteliğini dikkate alır ve daha yüksek önceliğe sahip olan seçilecektir. Bu öncelik -1000 ile 1000 arasında ayarlanabilir ve uygulamalar SYSTEM_HIGH_PRIORITY değerini kullanabilir. Eğer bir çelişki oluşursa, kullanıcının karar verebileceği bir "seçici" Penceresi görünür.
Açık bir intent, hedef aldığı sınıf adını belirtir:
Diğer uygulamalarda daha önce tanımlanmış bir intent'e erişmek için şunu kullanabilirsiniz:
Bunlar diğer uygulamaların uygulamanız adına eylemler gerçekleştirmesine olanak tanır, uygulamanızın kimliği ve izinlerini kullanarak. Bir Pending Intent oluştururken bir intent ve gerçekleştirilecek eylem belirtilmelidir. Eğer belirtilen intent Açık değilse (hangi intent'in bunu çağırabileceğini belirtmiyorsa) kötü niyetli bir uygulama, belirtilen eylemi mağdur uygulama adına gerçekleştirebilir. Dahası, bir eylem belirtilmemişse, kötü niyetli uygulama mağdur adına herhangi bir eylem gerçekleştirebilir.
Önceki intent'lerin aksine, yalnızca bir uygulama tarafından alınan, broadcast intent'ler birden fazla uygulama tarafından alınabilir. Ancak, API sürüm 14'ten itibaren, mesajı alması gereken uygulamayı belirtmek mümkündür Intent.setPackage kullanarak.
Alternatif olarak, yayın gönderirken bir izin belirtmek de mümkündür. Alıcı uygulamanın bu izne sahip olması gerekecektir.
İki tür Yayın vardır: Normal (asenkron) ve Sıralı (senkron). Sıralama, alıcı öğesindeki yapılandırılmış önceliğe dayanır. Her uygulama Yayını işleyebilir, iletebilir veya düşürebilir.
Context sınıfından sendBroadcast(intent, receiverPermission) fonksiyonunu kullanarak bir yayın göndermek mümkündür.
Ayrıca, LocalBroadCastManager'dan sendBroadcast fonksiyonunu kullanarak mesajın uygulamadan çıkmamasını sağlayabilirsiniz. Bunu kullanarak bir alıcı bileşenini dışa aktarmanıza bile gerek kalmaz.
Bu tür Yayınlar gönderildikten uzun süre sonra erişilebilir. Bunlar API seviyesi 21'de kullanımdan kaldırıldı ve kullanılmamaları önerilir. Herhangi bir uygulamanın verileri dinlemesine, ayrıca bunları değiştirmesine olanak tanır.
"sticky" kelimesini içeren fonksiyonlar bulursanız, örneğin sendStickyBroadcast veya sendStickyBroadcastAsUser, etkisini kontrol edin ve kaldırmaya çalışın.
Android uygulamalarında, deep links bir eylemi (Intent) doğrudan bir URL aracılığıyla başlatmak için kullanılır. Bu, bir aktivite içinde belirli bir URL şeması tanımlanarak yapılır. Bir Android cihazı bu şemaya sahip bir URL'ye erişmeye çalıştığında, uygulama içindeki belirtilen aktivite başlatılır.
Şema, AndroidManifest.xml dosyasında belirtilmelidir:
Önceki örnekteki şema examplescheme:// (aynı zamanda category BROWSABLE'ı da not edin)
Ardından, veri alanında host ve path belirtebilirsiniz:
Web'den erişmek için şu şekilde bir bağlantı ayarlamak mümkündür:
Uygulamada çalıştırılacak kodu bulmak için, deeplink ile çağrılan aktiviteye gidin ve onNewIntent fonksiyonunu arayın.
HTML sayfaları kullanmadan derin bağlantıları nasıl çağıracağınızı öğrenin.
Android Arayüz Tanım Dili (AIDL), Android uygulamalarında işlem arası iletişim (IPC) yoluyla istemci ve hizmet arasında iletişimi kolaylaştırmak için tasarlanmıştır. Android'de başka bir işlemin belleğine doğrudan erişim izni verilmediğinden, AIDL, nesneleri işletim sistemi tarafından anlaşılan bir formata marşallayarak süreci basitleştirir ve farklı işlemler arasında iletişimi kolaylaştırır.
Bağlı Hizmetler: Bu hizmetler, IPC için AIDL kullanarak, aktivitelerin veya bileşenlerin bir hizmete bağlanmasını, isteklerde bulunmasını ve yanıt almasını sağlar. Hizmetin sınıfındaki onBind metodu, etkileşimi başlatmak için kritik öneme sahiptir ve güvenlik incelemesi için zafiyet arayışında önemli bir alan olarak işaretlenmelidir.
Messenger: Bağlı bir hizmet olarak çalışan Messenger, onBind metodu aracılığıyla veri işleme odaklı IPC'yi kolaylaştırır. Bu metodun, güvensiz veri işleme veya hassas fonksiyonların yürütülmesi açısından dikkatlice incelenmesi önemlidir.
Binder: AIDL'nin soyutlaması nedeniyle Binder sınıfının doğrudan kullanımı daha az yaygındır, ancak Binder'ın farklı işlemlerin bellek alanları arasında veri transferini kolaylaştıran bir çekirdek düzeyinde sürücü olduğunu anlamak faydalıdır. Daha fazla bilgi için https://www.youtube.com/watch?v=O-UHvFjxwZ8 adresine başvurabilirsiniz.
Bunlar: Aktiviteler, Hizmetler, Yayın Alıcıları ve Sağlayıcılar.
Android uygulamalarında, aktiviteler ekranlar gibidir ve uygulamanın kullanıcı arayüzünün farklı bölümlerini gösterir. Bir uygulama birçok aktiviteye sahip olabilir, her biri kullanıcıya benzersiz bir ekran sunar.
Başlatıcı aktivite, bir uygulamanın simgesine dokunduğunuzda başlatılan ana geçittir. Uygulamanın manifest dosyasında belirli MAIN ve LAUNCHER intentleri ile tanımlanmıştır:
Tüm uygulamaların bir başlatıcı etkinliğe ihtiyacı yoktur, özellikle de arka plan hizmetleri gibi kullanıcı arayüzü olmayanlar.
Etkinlikler, manifestoda "exported" olarak işaretlenerek diğer uygulamalara veya süreçlere sunulabilir. Bu ayar, diğer uygulamaların bu etkinliği başlatmasına izin verir:
Ancak, başka bir uygulamadan bir aktiviteye erişmek her zaman bir güvenlik riski değildir. Hassas verilerin yanlış bir şekilde paylaşılması durumunda endişe ortaya çıkar, bu da bilgi sızıntılarına yol açabilir.
Bir aktivitenin yaşam döngüsü onCreate yöntemi ile başlar, UI'yı kurar ve aktiviteyi kullanıcı ile etkileşim için hazırlar.
Android geliştirmede, bir uygulama Application sınıfının bir alt sınıfını oluşturma seçeneğine sahiptir, ancak bu zorunlu değildir. Böyle bir alt sınıf tanımlandığında, uygulama içinde oluşturulan ilk sınıf olur. Bu alt sınıfta uygulanmışsa, attachBaseContext yöntemi onCreate yönteminden önce çalıştırılır. Bu kurulum, uygulamanın geri kalan kısmı başlamadan önce erken başlatma sağlar.
Services arka plan operatifleri olarak, kullanıcı arayüzü olmadan görevleri yerine getirebilen yapılardır. Bu görevler, kullanıcılar farklı uygulamalara geçse bile çalışmaya devam edebilir, bu da servisleri uzun süreli işlemler için kritik hale getirir.
Servisler çok yönlüdür; çeşitli şekillerde başlatılabilirler, Intents bunları bir uygulamanın giriş noktası olarak başlatmanın birincil yöntemidir. Bir servis startService yöntemi kullanılarak başlatıldığında, onStart yöntemi devreye girer ve stopService yöntemi açıkça çağrılana kadar çalışmaya devam eder. Alternatif olarak, bir servisin rolü aktif bir istemci bağlantısına bağlıysa, istemciyi servise bağlamak için bindService yöntemi kullanılır ve veri geçişi için onBind yöntemi devreye girer.
Servislerin ilginç bir uygulaması, arka planda müzik çalma veya kullanıcıların bir uygulama ile etkileşimini engellemeden ağ verisi alma gibi işlemlerdir. Ayrıca, servisler dışa aktarma yoluyla aynı cihazdaki diğer süreçlere erişilebilir hale getirilebilir. Bu, varsayılan bir davranış değildir ve Android Manifest dosyasında açık bir yapılandırma gerektirir:
Broadcast receivers mesajlaşma sisteminde dinleyici olarak işlev görür ve birden fazla uygulamanın sistemden gelen aynı mesajlara yanıt vermesine olanak tanır. Bir uygulama iki ana yolla bir alıcı kaydedebilir: uygulamanın Manifest dosyası aracılığıyla veya uygulamanın kodu içinde dinamik olarak registerReceiver API'si ile. Manifest'te, yayınlar izinlerle filtrelenirken, dinamik olarak kaydedilen alıcılar kaydedilme sırasında izinleri de belirtebilir.
Intent filtreleri, her iki kayıt yönteminde de kritik öneme sahiptir ve hangi yayınların alıcıyı tetikleyeceğini belirler. Eşleşen bir yayın gönderildiğinde, alıcının onReceive metodu çağrılır ve uygulamanın buna göre tepki vermesini sağlar; örneğin, düşük pil uyarısına yanıt olarak davranışı ayarlamak gibi.
Yayınlar asenkron olabilir, tüm alıcılara sırasız ulaşır veya senkron olabilir; burada alıcılar, belirlenen önceliklere göre yayını alır. Ancak, herhangi bir uygulamanın kendisini önceliklendirebileceği ve bir yayını kesebileceği potansiyel güvenlik riskini not etmek önemlidir.
Bir alıcının işlevselliğini anlamak için, sınıfı içinde onReceive metodunu arayın. Bu metodun kodu, alınan Intent'i manipüle edebilir ve alıcıların veri doğrulama ihtiyacını vurgular; özellikle Sıralı Yayınlar'da, Intent'i değiştirebilir veya atlayabilir.
Content Providers, uygulamalar arasında yapılandırılmış verilerin paylaşımı için gereklidir ve veri güvenliğini sağlamak için izinlerin uygulanmasının önemini vurgular. Uygulamalara, veritabanları, dosya sistemleri veya web gibi çeşitli kaynaklardan veri erişimi sağlar. readPermission ve writePermission gibi belirli izinler, erişimi kontrol etmek için kritik öneme sahiptir. Ayrıca, uygulamanın manifestinde grantUriPermission ayarları aracılığıyla geçici erişim sağlanabilir; path, pathPrefix ve pathPattern gibi nitelikler detaylı erişim kontrolü için kullanılır.
Girdi doğrulaması, SQL enjeksiyonu gibi güvenlik açıklarını önlemek için son derece önemlidir. Content Providers, veri manipülasyonu ve uygulamalar arasında paylaşımı kolaylaştıran temel işlemleri destekler: insert(), update(), delete(), ve query().
FileProvider, dosyaları güvenli bir şekilde paylaşmaya odaklanan özel bir Content Provider'dır. Erişimi kontrol etmek için belirli niteliklerle uygulamanın manifestinde tanımlanır; bu nitelikler, klasör yapılandırmalarını gösteren android:exported ve android:resource ile belirtilir. Duyarlı verilerin yanlışlıkla ifşa edilmesini önlemek için dizinleri paylaşırken dikkatli olunmalıdır.
FileProvider için örnek manifest bildirimi:
Ve filepaths.xml dosyasında paylaşılan klasörleri belirtmenin bir örneği:
For further information check:
WebViews, Android uygulamaları içinde mini web tarayıcıları gibidir, içerikleri ya webden ya da yerel dosyalardan çeker. Normal tarayıcılarla benzer risklerle karşılaşırlar, ancak belirli ayarlar ile bu riskleri azaltmanın yolları vardır.
Android, iki ana WebView türü sunar:
WebViewClient, temel HTML için harikadır ancak JavaScript uyarı fonksiyonunu desteklemez, bu da XSS saldırılarının nasıl test edileceğini etkiler.
WebChromeClient, tam Chrome tarayıcı deneyimine daha çok benzer.
Önemli bir nokta, WebView tarayıcılarının cihazın ana tarayıcısıyla çerez paylaşmamasıdır.
İçerik yüklemek için loadUrl, loadData, ve loadDataWithBaseURL gibi yöntemler mevcuttur. Bu URL'lerin veya dosyaların kullanım için güvenli olduğundan emin olmak kritik öneme sahiptir. Güvenlik ayarları, WebSettings sınıfı aracılığıyla yönetilebilir. Örneğin, JavaScript'i setJavaScriptEnabled(false) ile devre dışı bırakmak, XSS saldırılarını önleyebilir.
JavaScript "Bridge", Java nesnelerinin JavaScript ile etkileşimde bulunmasına olanak tanır ve Android 4.2'den itibaren güvenlik için yöntemlerin @JavascriptInterface ile işaretlenmesi gerekmektedir.
İçerik erişimine izin vermek (setAllowContentAccess(true)), WebView'lerin İçerik Sağlayıcılarına ulaşmasına olanak tanır, bu da içerik URL'leri güvenli olarak doğrulanmadıkça bir risk oluşturabilir.
Dosya erişimini kontrol etmek için:
Dosya erişimini devre dışı bırakmak (setAllowFileAccess(false)), dosya sistemine erişimi sınırlar, belirli varlıklar için istisnalarla, yalnızca hassas olmayan içerikler için kullanılmasını sağlar.
Dijital imzalama, Android uygulamaları için zorunludur, uygulamaların yüklemeden önce gerçekten yazıldığı garantisini sağlar. Bu süreç, uygulama kimliği için bir sertifika kullanır ve yükleme sırasında cihazın paket yöneticisi tarafından doğrulanmalıdır. Uygulamalar kendinden imzalı veya harici bir CA tarafından sertifikalandırılmış olabilir, yetkisiz erişime karşı koruma sağlar ve uygulamanın cihazına teslimatı sırasında değiştirilmediğini garanti eder.
Android 4.2'den itibaren, Uygulamaları Doğrula adı verilen bir özellik, kullanıcıların yüklemeden önce uygulamaların güvenliğini kontrol etmelerine olanak tanır. Bu doğrulama süreci, kullanıcıları potansiyel olarak zararlı uygulamalar hakkında uyarabilir veya özellikle kötü niyetli olanların yüklenmesini engelleyebilir, kullanıcı güvenliğini artırır.
MDM çözümleri, Cihaz Yönetimi API'si aracılığıyla mobil cihazlar için denetim ve güvenlik sağlar. Mobil cihazları etkili bir şekilde yönetmek ve güvence altına almak için bir Android uygulamasının yüklenmesini gerektirir. Ana işlevler arasında şifre politikalarının uygulanması, depolama şifrelemesinin zorunlu kılınması ve uzaktan veri silme izni verme bulunur, bu da mobil cihazlar üzerinde kapsamlı kontrol ve güvenlik sağlar.
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
