Rootlu cihaz testi, yeniden paketlenmiş Android uygulamalarının Google Play Integrity'den geçebildiğini gösteriyor

Ne oldu

dev.to'da yayımlanan teknik bir yazı, rootlu bir Android cihazda Google Play Integrity'nin atlatılmasının pratik bir yolunu gösteriyor: uygulamanın diskteki gerçek kod dosyasının üzerine yazılır, orijinal kurulum kaydı yerinde bırakılırsa servis uygulamayı yine de genuine (orijinal) olarak raporluyor.

Yazara göre test, Android 16 ve Google Play Services 26.34.67 çalıştıran rootlu bir telefonda yapıldı. Yeniden paketlenmiş bir build takıldıktan sonra bir Play Integrity isteği, o anda çalışan kod yazarın farklı bir anahtarla imzalanmış değiştirilmiş sürümü olmasına rağmen PLAY_RECOGNIZED, LICENSED ve NO_ISSUES sonucunu veren bir Play Protect yanıtı döndürdü.\n

Doğrulama nasıl veriliyor

Yazıda açıklandığı gibi repackaging (yeniden paketleme), bir APK'yı cihazdan çekmek, ne yaptığını değiştirmek (reklam veya ödeme duvarlarını kaldırmak, know-your-client kontrollerini sahtelemek, root belirtilerini gizlemek) ve sonucu dağıtmak anlamına geliyor. Bu önemli, çünkü birçok backend hangi trafiğin meşru olduğuna karar verirken istemcinin bildirdiği cihaz sinyallerine güveniyor ve değiştirilmiş bir istemci basitçe yalan söyleyebilir. Yazar, fintech, kripto, web3 ve kumar uygulamalarını en açık hedefler olarak sayıyor ve yeniden paketlemenin, kurcalanmış bir uygulama daha az teknik kullanıcıların kullanımına birçok cihazda sunulabildiği için egzotik runtime açıklarından daha ölçeklenebilir olduğunu savunuyor.

Google'ın yanıtı Play Integrity API'si ve PLAY_RECOGNIZED doğrulaması. Yazar, kontrolü canlı bir cihazda izleyerek akışı şöyle anlatıyor: uygulama API'yi çağırır, Google'ın IntegrityService'i DroidGuard'a devreder; DroidGuard paket adını, sürüm kodunu, kurulum kaynağını, cihaz tanımlayıcılarını, SIM verilerini ve bir request nonce'ını, Google sunucularının değerlendirip imzaladığı bir attestation içinde birleştirir. Yazıda alıntılanan Google dokümantasyonu, doğrulamayı uygulama ve sertifikasının Google Play'in dağıttığı sürümlerle eşleşmesi olarak tanımlıyor.

Yazara göre Google, PLAY_RECOGNIZED için iki şeyi karşılaştırıyor: paket adını ve o kurulum için elinde tuttuğu imza sertifikasını. Bu kayıt uygulama kurulduğunda sabitleniyor; doğrulama, fiilen çalışan kodu hiçbir zaman yeniden incelemiyor.

Dosya değişimi

Yazar, bir test uygulamasının yeniden paketlenmiş bir sürümünü kendi anahtarıyla yeniden imzaladı. Android, imzalar farklı olduğu için normal bir yükseltmeyi INSTALL_FAILED_UPDATE_INCOMPATIBLE ile engelledi ve yazar, bu imza kontrolünün fiilen Play Integrity korumasının bittiği yer olduğunu savunuyor.

Root erişimiyle yazar bunun yerine kurulu base.apk dosyasının doğrudan üzerine yazdı; sistemin kurulum kaydına ve önbelleğe alınmış genuine sertifikasına dokunmadı. Bir sonraki doğrulama, yeniden paketlenmiş sürümün anahtarı yerine genuine sertifika özetine atıf yaparak PLAY_RECOGNIZ ED döndürdü; LICENSED ve NO_ISSUES da yanındaydı.

Bayat derlenmiş kod ihtimalini elemek için yazar, telefonun uygulamanın önceden derlenmiş kopyasını sildi (böylece Android değiştirilmiş dosyayı yüklemek zorunda kaldı) ve genuine doğrulamayı alan sürecin kendisinden loglayan bir işaretleyici yerleştirdi.

Bu atlatmanın sınırları var: değişimin yapıldığı cihazda root gerektiriyor ve yeni kurulum olarak kurulan yeniden imzalanmış bir uygulama yine de UNRECOGNIZED_VERSION alıyor. Püf noktası, özellikle çalışan kod ile kurulum kaydının birbirinden ayrılması.

Daha geniş boşluklar

Yazı ilgili diğer zayıflıkları da listeliyor. Önbelleğe alınmış sertifika hiç değişmediği için, runtime'da hook'lanan gerçekten imzalı bir uygulama da farklı davranırken temiz bir doğrulama almayı sürdürüyor. De-Googled cihazlarda (custom ROM'lar ve Çin pazarındaki birçok telefon gibi) Play Integrity hiç çalışamıyor; bu da savunmacıları ya tüm bu trafiği engellemeye ya tamamına izin vermeye zorluyor. API kotaları ve gecikme geliştiricileri yalnızca hassas işlemlerde doğrulama yapmaya itiyor ve aradaki pencereler açıyor. Yazar ayrıca, test ettiği tüm cihaz içi anti-repackaging düzenlerini atlatan 2022 tarihli bir araştırmaya atıf yapıyor ve salt cihaz içi savunmaların hiçbir zaman tek başına duramadığını savunuyor.

Önerilen önlem

Yazının önerdiği ve çerçevesi dikkate alındığında açıkça tanıttığı çözüm, Intakto adlı bir araç; ücretsiz katmanı, kurulu APK dosyalarının runtime'da güncel bir hash'ini hesaplayıp sonucu Android'in kurulum sırasında kaydettiği imza sertifikasıyla karşılaştırıyor. Yazarın Android 12 çalıştıran bir Pixel 3a'daki testinde araç, değiştirilmiş dosyayı işaretledi. Yeni kurulum olarak kurulan yeniden imzalanmış bir kopyayı yakalamıyor; onu zaten UNRECOGNIZED_VERSION kapsıyor. Yazara göre imzalayıcı iki kez okunuyor, bir kez native bir çağrıyla bir kez de standart Android API'si üzerinden, dolayısıyla bir yola yalan söyleyen hook diğer yola yakalanıyor.

Neden önemli

Play Integrity doğrulamaları yük taşıyan bir sinyal: backendler hangi istemcilerin ödeme, kimlik kontrolü ve lisanslı içerikle ilgilenebileceğine karar vermek için bunları kullanıyor. Rootlu bir cihaz, doğrulama hâlâ genuine derken saldırgan kodu çalıştırabiliyorsa, bu garanti birçok entegratörün varsaydığından zayıf demektir. Yüksek değerli uygulamaların geliştiricileri muhtemelen derinlemesine savunmaya ihtiyaç duyuyor: runtime kendi kendini doğrulama ile sunucu tarafı anomali tespitini birleştirmek, PLAY_RECOGNIZED'ı çalışan kodun Google'ınkileri olduğunun kanıtı saymamak gerekir. Bu gösterim ayrıca yeniden paketlemenin neden ilgiyi hak ettiğinin altını çiziyor: sofistike runtime saldırılarına kıyasla teknik olarak kaba, ama tek seferlik açıkların yapamadığı bir biçimde sıradan kullanıcılara ölçekleniyor.