- Google’ın resmi duyurusu değil; devam eden bir IssueTracker özellik isteğinde, ADB’nin çekirdek bakım sorumlusu kötüye kullanımı önlemek için yerel bağlantıları kısıtlamayı ve yalnızca
wlan0arayüzüne bağlanmayı gündeme getirdi - Yalnızca
wlan0a izin verilirse, loopback adresi127.0.0.1kullanan cihaz içi ADBnin yanı sıra VPN/Ethernet tabanlı ADB ve çeşitli geliştirme ortamları da çalışmayabilir - Tartışma, Wireless ADB kimlik doğrulamasını tamamen atlatan CVE-2026-0073 ile başladı; asıl istek ise ADBD’nin dinleyeceği arayüzün seçilebilmesi ve tüm ağlara açık olmamasıydı
- Sıradan kötü amaçlı uygulamalar ADBD’yi doğrudan başlatamaz veya Wireless ADB eşleştirmesini/TCP/IP onayını tek başına tamamlayamaz; bu nedenle kullanıcının elle işlem yapması olmadan ADB yetkisi elde etmeleri zordur
- Loopback bağlantılarını kalıcı olarak engellemek Shizuku ve libadb-android tabanlı araçları etkileyeceğinden, varsayılan engellemenin yeniden başlatma sonrasında da kaldırılabilmesini sağlayan kullanıcı seçimine dayalı bir ayar gerekir
Resmi duyuru değil, erken aşama bir tartışma
- Bu konu Google’ın kesinleşmiş bir politikası veya resmi duyurusu değil; devam eden bir IssueTracker özellik isteğine ve ADB’nin çekirdek bakım sorumlusunun yorumuna dayanıyor
- Sorumlu kişi, bir uygulamanın ADBD’nin yerel soketini kullanarak yetki yükselttiği örneğe değinerek ADBD’nin yalnızca Wi‑Fi arayüzü olan
wlan0a bağlanması seçeneğini gündeme getirdi - Açık tartışmada basit itirazlardan, hakaretlerden veya aynı kullanım senaryosunun tekrarlanmasından kaçınılmalı
- Benzersiz bir kullanım senaryonuz varsa iş akışını, ilgili bağlantıları ve teknik ödünleri içerecek şekilde somut geri bildirim bırakabilirsiniz
- Aynı senaryo zaten kaydedilmişse yorumları tekrarlamak yerine +1 ve bildirim özelliğini kullanmak önerilir
- Düşük kaliteli yorumlar yığılırsa konu kilitlenebilir veya faydalı geri bildirimler ve herkese açık güncellemeler azalabilir
ADB’nin üç bağlantı yöntemi
- ADB, Android cihazları test eden ve yöneten geliştiricilere ve ileri düzey kullanıcılara yüksek yetkili komut erişimi sağlayan bir protokoldür
- Başlıca bağlantı yöntemleri üçe ayrılır
- USB: Ayrı bir bilgisayardan USB kablosuyla cihaza doğrudan bağlanılan özgün yöntemdir
- ADB TCP/IP: Genellikle
5555portunu kullanır; trafik düz metin olarak iletilir ve YES/NO onay penceresiyle kimlik doğrulaması yapılır. Etkinleştirmek için mevcut bir ADB bağlantısı gerekir - Wireless Debugging: Android 11’de kullanıma sunuldu; bilgisayarı kod veya QR kod ile eşleştirdikten sonra kimliği doğrulanmış ve şifreli bir bağlantı kurar. Etkinleştirmek için mevcut bir ADB bağlantısı gerekmez
Cihaz içi ADB’nin oluşturduğu ekosistem
- Tipik ADB kullanımı, Android cihazın ADBD’si ile ayrı bir geliştirme bilgisayarındaki ADB istemcisini bağlar; ancak bilgisayar olmadan doğrudan Android cihaz üzerinde çalışan geliştiriciler de vardır
- Cihaz içi ADB (On-Device ADB) resmi bir terim değildir; Termux gibi terminal emülatörlerinde ADB istemcisini çalıştırıp aynı cihazdaki ADBD’ye bağlanma yöntemini ifade eder
- ADB TCP/IP veya Wireless Debugging kullanır
- İstemci ve sunucu aynı cihazda olduğundan loopback adresi
127.0.0.1üzerinden çalışır
- Bu yöntem libadb-android, Shizuku gibi geliştiricilere ve ileri düzey kullanıcılara yönelik açık kaynak projelerin temelini oluşturur
- ShizuCallRecorder, engellilik nedeniyle yaşanan günlük zorlukları azaltmak için yapılmış Shizuku tabanlı bir uygulamadır
- Bir kullanıcı bu uygulamayı, vefat eden bir aile üyesinin sesli mesajlarını saklamak için kullandı
- Android’de arama kaydı kullanıcılar tarafından çok talep edilmiş, Android 11’de resmi bir özellik olarak geliştirilip sonra iptal edilmişti; bugün kapalı kaynaklı veya gizlilik ihlali riski taşıyan geçici çözüm uygulamaları da mevcut
- Bazı OEM’ler, yasal olarak gerekli olmayan bölgelerde bile arama kaydı uyarı sesini zorunlu kılıyor
Arayüz seçimi isteği ve wlan0 kısıtlaması
- Yeni özellik isteğinin asıl amacı, ADBD’nin dinleyeceği ağ arayüzünü geliştiricinin seçebilmesini sağlamak
- Arka planda, Wireless ADB kimlik doğrulama sürecinin tamamen atlatılmasına izin veren CVE-2026-0073 bulunuyor
- Şu anda ADBD, telefonun bağlı olduğu tüm ağlardan erişilebilir durumda; bu yüzden arayüz seçimi özelliği kendi başına maruz kalma alanını azaltabilir
- Ancak yalnızca
wlan0a izin verilirse şu yapılandırmalar bozulabilir- Loopback kullanan cihaz içi ADB
- VPN üzerinden ADB
- Ethernet üzerinden ADB
- Diğer özel geliştirme ortamları
- Android geliştiricilerinin de bilgisayara erişemediklerinde cihaz içi ADB kullandığı örnekler var
Kötü amaçlı uygulamaların aşması gereken kısıtlar
- Cihaz içi ADB yetki yükseltme için kullanılabilse de, sıradan kötü amaçlı uygulamalar kendi başlarına bağlantı kuramaz
-
Sıradan Android kullanıcıları
- ADB devre dışıysa ADBD çalışmaz
- Kötü amaçlı uygulamalarda ADB üzerinden elle verilmesi gereken
WRITE_SECURE_SETTINGSizni de bulunmadığından ADB saldırısı denemeleri zordur
-
Android 11 ve üzeri sürümlerde Wireless ADB kullanan geliştiriciler
- ADBD’nin ağ arayüzlerinde dinlemesi için kullanıcının USB hata ayıklamayı ve Wireless ADB’yi doğrudan etkinleştirmesi gerekir
- Uygulamanın bağlanabilmesi için kullanıcının ayarlar ekranından tek kullanımlık eşleştirme kodunu alıp sağlaması gerekir; bu yüzden uygulama tek başına bağlantı kuramaz
-
ADB TCP/IP kullanan geliştiriciler
- Kullanıcının USB hata ayıklamayı açması, USB ADB ile TCP/IP’yi etkinleştirmesi ve ardından kabloyu çıkarması gerekir
- Uygulama bağlantı başlattığında ekranda onay penceresi görünür; kullanıcı No seçerse reddedilir
- Normal kimlik doğrulama durumunda uygulama kullanıcıdan habersiz bağlanıp saldırı gerçekleştiremez
Güvenlik açığı riski ve engellemenin kapsamı
- Normal koşullarda kötü amaçlı bir uygulama ADBD’yi doğrudan başlatamaz; bağlantı olasılığı yalnızca geliştirici cihazda ADB kullanıyorken ortaya çıkar
- CVE-2026-0073 gibi kimlik doğrulamayı atlatan bir güvenlik açığı varsa Wireless ADB ve TCP/IP ortamlarında kötüye kullanılabilir
- Yine de kullanıcının önce USB hata ayıklamayı elle etkinleştirmesi gerekir
- TCP/IP yönteminde kullanıcının ADB TCP/IP’yi de doğrudan açması gerekir
- Loopback bağlantılarını varsayılan olarak engelleyen önlem ile kullanıcının kaldıramayacağı kalıcı engelleme birbirinden ayrılmalı
- Cihaz yöneticisi atama veya erişilebilirlik izni de kullanıcı işlemiyle kötü amaçlı uygulamalara verilebilir; ancak yalnızca bu olasılık nedeniyle özelliklerin kendisi kaldırılmıyor
Kullanıcı seçeneğini koruyan bir uzlaşma
- Loopback engeli, kullanıcının açıkça kaldırabileceği kalıcı bir ayar olmalı
- Shizuku gibi araçların pratikte kullanılabilmesi için yeniden başlatmadan sonra da korunmalı
- Mümkünse üçüncü taraf uygulamalar ayar durumunu okuyamamalı; böylece banka uygulamaları veya oyunların tespitinden kaçınmak için ayarı tekrar tekrar değiştirmek gerekmez
- Bir uygulamaya
WRITE_SECURE_SETTINGSelle verilirse bazı kısıtlar aşılabilir
- Kullanıcının güvenlik özelliğini kapatıp cihaz içi hata ayıklamaya izin verirken gelecekteki güvenlik açıklarına maruz kalma riskini de üstlendiği bir yapı uygun olur
- Cihaz içi ADB kalıcı olarak engellenirse aşağıdaki niş açık kaynak ekosistemi etkilenir
2 yorum
Iyy...
Hacker News yorumları
Genel olarak güvenlik iyileştirmelerini destekliyorum ama burada pratik fayda neredeyse yok gibi görünüyor. Bu saldırının gerçekleşmesi için kullanıcının hem geliştirici ayarlarını hem de uzak ADB'yi açması gerekiyor; bu da kullanıcıların %99,9'u için gerçekçi bir saldırı yolu değil, kalan %0,1 ise genelde ne yaptığını biliyor
Erişimi belirli bir arayüz veya IP ile sınırlayan değişiklikler iyi olurdu ama geliştiricilerin bunu localhost ile sınırlayabilmesi yeterli olurdu. Shizuku ve Canta gibilerini tali hasarmış gibi gösterip engellemeye çalışma hissi daha baskın
disable sandboxyazsanız bile mobilde çalışmıyorFirefox'ta imzasız eklentiler hiç kurulamıyor, bunun için Developer Edition gerekiyor; siteler passkey dayatıyor ve tek bir S3 bucket üzerinde bile onlarca katman erişim kontrolü, servis kimliği, IAM ve OAuth birikiyor. Headless cihazlarda çalışmayan OAuth, TOTP yerine özel uygulama isteyen bankalar, VPN engelleme, çocuk koruma bahanesiyle gerçek isimli gözetim ve veriler Çin'e gidiyor diye açık ağırlıklı modelleri yasaklama girişimleri de sürüyor
Güvenlik, kolaylık, kullanılabilirlik, gizlilik, özelleştirilebilirlik ve açıklığın her zaman önüne geçen mutlak bir değere dönüştü ve BT güvenlik sektörü bundan utanmalı
Bu değişiklik kullanıcı güvenliği için değil, şirket çıkarlarını korumak için yapılmış gibi görünüyor
Başta uygulama mağazası olmadan sadece Safari kullanın deniyordu ve bence kökeninde, kanser tedavisi görürken bile tasarımı güzel olmayan tıbbi cihazların bedenine temas etmesini istemeyen Steve Jobs'a özgü bir takıntı vardı. “Mükemmel” cihaza “kirli” şeylerin değmesini istemeyen tavır sonradan güvenlik diliyle meşrulaştırıldı
O zamanlar kötü amaçlı yazılımla dolu Windows 98 benzeri bir durumdan kaçınmak gerektiği söyleniyordu ama modern işletim sistemleri zaten o dönemin Windows'unun zayıf güvenlik seviyesini çoktan aştı
Shizuku tabanlı root gerektirmeyen gizlilik araçlarını engellemenin amacı cihaz sahibinin değil, devletin güvenliğini sağlamaktır. AB Dijital Kimlik Cüzdanı gibi güvenilir yürütme ortamı uygulamaları ve ileride çocuk koruma bahanesiyle istenecek özellikler, kullanıcının cihazı kurcalayamayacağı veya onaysız yazılım kuramayacağı varsayımına büyük ölçüde dayanıyor. Intel SGX'in nasıl sonuçlandığını hepimiz biliyoruz
ADB kısıtlaması beklenen bir sonraki adım. Bu öneri aynen geçmese bile Google, sıradan kişisel bilişim işlerini bile cihaz içindeki ya da USB/kablosuz geliştirici arayüzlerine bağımlı hale getirdi
Bir gün kimliğinizi verip yıllık ücret ödemek ya da Android'i anlamlı biçimde kullanırken ciddi kısıtlamalarla karşılaşmak çok olası. Google, kontrol edilen dağıtım kanallarının dışında Android uygulaması geliştirilmesini istemiyor ve normal, yasal sideloading'i yasaklayan değişikliklerden geri adım atmadığında savaş zaten kaybedilmiş olacak
Arama kaydı uyarıları da Google'ın suçu. Üreticiler daha iyi olan kendi çeviricileri yerine Google Dialer'ı benimsedikçe bu, yasal zorunluluk olmayan bölgelere bile topluca uygulanıyor. Özellikle kararlı üçüncü taraf uygulamalar üzerinden kayıt almayı donanım düzeyinde desteklemeyen MediaTek SoC'lerde daha da can sıkıcı
Sonuçta bu, “benim” cihazıma sahip olmadığımın kanıtı ve birkaç yıl sonra belki de Gemini onaylı gözetim kanalı üzerinden aramalarımı dinleyip özetleyecek
Meşru kullanım alanları için alternatif yolların da sunulup sunulmadığını merak ediyorum. Bir işlevi kaldırıp yerine seçenek vermezseniz geliştiricileri daha kırılgan, hatta bazen kuralları ihlal eden dolambaçlı çözümlere itersiniz
Bu tepki, yanlış anlamadan doğmuş büyük bir aşırı tepki gibi görünüyor. Uzak ADB ile geliştirdiğim Android projesinin yeni derlemesini kuruyor ve logları alıyorum; şu anda da Tailscale VPN üzerinden bağlanıyorum
Ama mevcut yöntem, bağlandığı tüm ortak Wi-Fi ağlarında kimlik doğrulama öncesi açıkları bile ortaya çıkarabiliyor. Yalnızca Tailscale arayüzüyle sınırlanabilse bu aslında iyileştirme olurdu
Önerinin özü, uzak ADB ayarlanırken tüm arayüzler yerine bağlanılacak arayüzün seçilmesi. localhost'un reddedileceğine dair bir şey yok; yalnızca
wlan0'a bağlanmayı öneren kısa teklif VPN'den daha az güvenilir olduğu için açıkça hatalıydı ve gerçek uygulama yönü de muhtemelen bu olmayacakKonuyu spam'leyip Google geliştiricilerinin başlığı kilitlemesine ve geri bildirimi görmezden gelmesine yol açsanız bile mevcut durumdan daha kötü olmayacak. Eleştirinin kendisi rahatsız ediyorsa değerli geri bildirimler de kilitlenebilir, o yüzden rahatça destek belirtebilirsiniz
Google uygulama geliştiricilerinden bazen geri bildirim alıyor ama böyle hileli yöntemlere dayanan açık kaynak geliştiricilerinden çok kendi iç ekiplerinin yargısına önem vermesi doğal. ADB daemon'unun, uygulamaların loopback adresi üzerinden ADB oturumu açıp arama kaydı yapabilmesi için tasarlandığı açıkça söylenemez. https://xkcd.com/1172/ yine akla geliyor
Geliştiricilerin bu değişikliği sevmemesinin yanlış olduğu anlamına gelmiyor. Google da çeviricisine arama kaydı eklediği için o özelliği ben de destekliyorum, ama bu ADB ekibinin güvenliği artırmaması gerektiği anlamına da gelmiyor
Google, sideloading kısıtlamasını ilk açıkladığında “en azından ADB var” denmişti ve buna itiraz edenler sert biçimde eleştirilmişti
Artık ADB’yi etkinleştiren dolambaçlı yöntemi bile beklemek gerekiyor; ayrıca Android uzun zamandır iOS’tan daha açık değildi. Bu gidişat sürecek
Bu, Google’ın düşünce yapısına dair teknik olmayan bir sorun olduğu için teknik çözümlerle giderilemez
Kendi yazılımınızı kurabilseniz bile cihaz “kurcalanmış” sayılıyor. Doğrulamadan kalırsanız güvenilmez kabul edilip iletişim, bankacılık, yayın, oyun ve dijital toplumun neredeyse her alanından dışlanan ikinci sınıf bir vatandaş oluyorsunuz
Android’in geleceği bu; bazı şirketler mucizevi biçimde GrapheneOS’un doğrulama anahtarlarına güvenmeye başladığı için GrapheneOS son umut. O umut da kaybolursa gidip iPhone almak daha iyi
Bu zaten beklenen bir şeydi. Sırada 24 saatlik sideloading kısıtlamasının süresize dönmesi var; insanlar olsa olsa buna şaşırır
Tüm pazarı ele geçirmesi gerekmiyor; Google’ı tereddüde düşürecek ya da bunu hukuken uygulamasını zorlaştıracak kadar güçlü olması yeterli. Chrome karşısında Firefox’un ideal rolüne benzer
Android’in bu kadar kilitlenmesi ciddi bir uyarı işareti. Android’i iyi yapan unsurlar yavaş yavaş tek tek kaldırılıyor
Yakında aynı şeyin web sitelerine de olacağından endişe ediyorum. Apple cihazlarında site açtırmak için Apple’a, Android cihazlarında ise Google’a aylık ücret ödemek gerekebilir
https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
Henüz ücret yok ama Google’ın hatırı sayılır sayıda web sitesi için hangi cihazların erişimine izin verileceğine karar verebilmesini sağlıyor
Eski web’in içeriği de yapay zeka şirketleri tarafından topluca kazınıp sonra yeni web üzerinden halka yeniden sunulabilir
Akıllı telefonlar için Linux gerekli. Bankacılık işleri tarayıcıdan yapılabiliyorsa uygulamaya gerek yok, ama kablosuz iletişim özellikleriyle Sonos ve Spotify gibi temel uygulamalar çalışmalı
Bankacılık ve kamu hizmetleri gibi temel servisler için düzgün çalışan bir web deneyimini zorunlu kılan yasalar gerekli. Aksi halde mevcut ikili yapı daha da pekişecek
Ben de web hizmeti sunan şirketleri seçip onları daha aktif desteklemeliyim
postmarketOS vikisinden uyumlu cihazlara bakıp elinizdeki cihazın desteklenip desteklenmediğini kontrol edin; mümkünse desteği iyileştirmeye katkı sağlayın. Değilse eBay’de destek durumu iyi olan ikinci el cihazlar bulunabilir
Librem 5 ve PinePhone iyi destekleniyor, ama OnePlus 6T gibi eski Android cihazlar fiyat/performans açısından daha iyi olabilir. Satın almadan önce temel işlevlerin çalışıp çalışmadığını kontrol etmek gerekir
Popüler Android uygulamaları Waydroid ile çalıştırılabilir
Alternatif olan SMS doğrulaması da güvenli olmadığı için ortadan kalkıyor; güvenlik açısından bu doğru yönde bir adım ama kullanılabilir başka yöntemler yeterince yok