Kasım 2026'nın ilk haftasında karşıma çıkan bir güvenlik haberi, evde kullandığım bir Android TV kutusunu beklemediğim bir araştırmanın merkezine koydu. Google Threat Intelligence Group, Çinli Videostrong Technology'nin ürettiği cihazlara XCPE adlı bir arka kapı yerleştirildiğini ve bu cihazların kullanıcılarının haberi olmadan bir botnet'e dönüştürüldüğünü açıklamıştı. Haberde MECOOL adı da geçiyordu. Benim de ocak ayında aldığım bir MECOOL vardı. Önce “benimkine denk gelmiş midir?” diye merak ettim; birkaç saat sonra ise cihazın firmware'indeki APK'leri tek tek çıkarıp SHA-256 hesaplıyordum.
Bu yazı bir haber çevirisi değil; kendi cihazım üzerinde ADB ile yaptığım incelemenin kronolojik kaydı. Komutları, gerçek bulguları, yanlış varsayımlarımızı ve henüz cevaplayamadığımız soruları birlikte vereceğim. Sonuç baştan belli: MECOOL HP4414 cihazımda XCPE arka kapısını, firmware'de kalıcı olmasını sağlayan bileşenleriyle birlikte doğruladım. Bunun, ev ağımdaki bütün bilgisayarların ele geçirildiği veya bütün hesaplarımın çalındığı anlamına gelmediğini de baştan belirteyim.
Haber neydi, neden önemliydi?
Google'ın 2 Kasım 2026'da yayımladığı teknik rapora göre XCPE, Android TV kutuları başta olmak üzere çok sayıda cihazın firmware'ine önceden yerleştirilmiş bir arka kapıydı. Google, Videostrong'un bu altyapıyı bilerek geliştirdiği ve üçüncü taraflara erişim satarak gelir elde ettiği değerlendirmesini yüksek güvenle açıkladı. Operasyonda 1,3 milyondan fazla cihazın botnet'e katıldığı belirtiliyordu. Amaç yalnızca reklam tıklatmak değildi: cihazlar ev internetlerini başkalarına kiralayan residential proxy çıkışlarına dönüştürülebiliyor, uzaktan komut ve ekran görüntüsü alınabiliyor, yeni APK'ler kullanıcıya sorulmadan kurulabiliyordu.
Bir başka kritik ayrıntı, arka kapının sıradan bir kullanıcı uygulaması olmamasıydı. Bazı sürümlerde x.cpe, bazılarında com.oemservice adını kullanan küçük bir başlatıcı firmware'in sistem bölümündeydi. Tam paket /oem/ altında duruyor, açılışta /data/app/ içine kuruluyordu. Uygulamayı silmek bile çözüm değildi; sonraki açılışta tekrar kurulabiliyordu. Google kontrol altyapısını kapattığını ve Videostrong ile ilişkisini kestiğini açıkladı. Bu, mevcut cihazın firmware'indeki zararlı kodun ortadan kalktığı anlamına gelmiyor.
İlk adım: Windows'tan ADB bağlantısı
ADB'nin bilgisayarımda kurulu olup olmadığından bile emin değildim. Windows'ta C:\platform-tools klasörünü hazırladıktan sonra MECOOL'un Android 14 kablosuz hata ayıklama ekranındaki eşleştirme kodunu kullandım. Android'in yeni kablosuz ADB sisteminde eşleştirme portuyla bağlantı portu farklı; ilk bağlantı denemesinin başarısız olmasının nedeni de buydu. Eşleştirme başarılı olunca cihazın kimliği göründü:
adb pair TV_IP:PAIR_PORT
adb connect TV_IP:ADB_PORT
adb devices -lproduct:HP4414-MECOOL
model:4K_Android_TV_Box
device:YYCBurada ve devamındaki ağ örneklerinde gerçek yerel IP, MAC adresi, eşleştirme kodu ve hesap e-posta adreslerini yayımlamıyorum. İncelemeye ait asıl çıktılar ayrıca saklı.
Birinci bulgu: com.oemservice
Google'ın yayımladığı gösterge listesindeki paket adlarını PowerShell üzerinden aradım. Linux'taki grep -E yerine Select-String kullandım. İlk taramada tek satır döndü ve olayın yönü değişti:
.\adb.exe -s TV_IP:ADB_PORT shell pm list packages -u |
Select-String 'x\.cpe|com\.oemservice|com\.abc\.nexus|com\.android\.system\.ntp|com\.android\.sso\.auth\.handler'
package:com.oemserviceYalnızca bir paket adını bulmak, tek başına kötü amaçlı kodun kanıtı olmazdı. Bu yüzden uygulamanın yolunu, UID'sini, izinlerini ve firmware'deki diğer bileşenleri sorguladım:
adb shell pm path com.oemservice
adb shell dumpsys package com.oemserviceSonuçlar oldukça belirleyiciydi: çalışan uygulama /data/app/ altındaydı, sürümü 6.8.3 görünüyordu, android.uid.system/1000 ortak sistem kimliğini kullanıyordu. INTERNET, READ_LOGS ve paket yükleme ile ilgili izinleri vardı. Aynı paket adına ilişkin firmware kaydı ise /system/priv-app/app_xcpe_preset yolunu ve 1.2.1 sürümünü gösteriyordu.
İlginç bir karşı bulgu da vardı: settings get global package_verifier_user_consent komutu 1 döndürüyordu. Google'ın raporunda XCPE'nin bu ayarı -1 yaparak uygulama doğrulamasını devre dışı bırakabildiği yazıyor. Dolayısıyla o anda ayarın 1 olması, zararlı kodun bulunmadığını göstermiyordu; yalnızca o anki ayarın değeri buydu.
Firmware'in içinde: /system ve /oem
/oem/ dizinini listeleyince birbirine yakın boyutlarda iki büyük dosya buldum:
/oem/app_xcpe_ext_sign 8,304,788 bytes
/oem/BoxFactoryTest_sign 8,197,829 bytesXCPE başlatıcısının yolu da ortaya çıktı:
/system/priv-app/app_xcpe_preset/app_xcpe_preset.apkapp_xcpe_ext_sign dosyasının ilk baytlarını okuduğumda 50 4B 03 04, yani ZIP/APK imzası çıktı. Adının uzantısız olması dosyanın biçimini değiştirmiyordu. 21 KB'lık sistem başlatıcısı ile yaklaşık 8,3 MB'lık tam paketin bir arada bulunması, Google'ın tarif ettiği yeniden kurulum mimarisiyle örtüşüyordu.
adb shell ls -la /system/priv-app/app_xcpe_preset/
adb shell sha256sum /oem/app_xcpe_ext_sign
adb shell 'od -An -tx1 -N16 /oem/app_xcpe_ext_sign'Burada bir küçük takılma yaşadım: adb pull /oem/app_xcpe_ext_sign, Permission denied verdiği hâlde aynı dosyanın SHA-256 değeri cihaz üzerinde hesaplanabiliyordu. Dosyayı doğrudan çekmek yerine standart çıktıyı ikili olarak alıp Windows'ta dosyaya yönlendirdim. PowerShell 7 kullandığım için bu yöntemle aldığım kopyanın hash'i orijinaliyle birebir eşleşti:
.\adb.exe -s TV_IP:ADB_PORT exec-out cat /oem/app_xcpe_ext_sign > C:\XCPE-Analysis\app_xcpe_ext_signÜç dosyanın SHA-256 değerleri
| Dosya | SHA-256 |
|---|---|
app_xcpe_preset.apk | 88e1b6ec984534def6e05421d973e7bf45fe602d929bd3edbb5aaa7e0a3edb7f |
app_xcpe_ext_sign | aa6269b993a6ca4f4286ed20cd6b3d7ae7ac4edc329d10ed525c602b60c4fbe5 |
com.oemservice.apk | 630431d001b8ef25bd998fc8e71b39c397a29d0635ac95a2f9778c05d18ca4a3 |
Bu hash'ler cihaz üzerindeki dosyalarla bilgisayara çektiğim kopyaların aynı olduğunu doğruluyor. Kamuya açık aramalarda bu tam hash'lere rastlamamış olmam, dosyaların temiz olduğu anlamına gelmez. Farklı derlemeler aynı zararlı aileye ait olabilir.
APK'lerin içine bakınca
Dosyaları çalıştırmadan ZIP içeriğini, DEX dizelerini ve imza sertifikalarını inceledim. Çalışan com.oemservice.apk içinde extstb.anyevonline.com, /router/config/mqtt, /router/config/acs, disablePackageVerify, package_verifier_user_consent, x.cpe.util.RunCmds ve com.oem.share.provider gibi göstergeler bulundu. Bunlar Google'ın XCPE teknik raporundaki ağ protokolü ve işlevlerle doğrudan örtüşüyor. Burada artık yalnızca benzer isimli bir sistem uygulamasından değil, kod düzeyinde eşleşen XCPE bileşenlerinden söz edebiliyoruz.
Üç APK de skydigital@skyworth.com adresini taşıyan, kuruluş adı SKYWORTH olan aynı sertifikayla imzalanmış. Sertifikanın 2022'de oluşturulmuş olması ve cihazın üretici özelliğinde SkyworthDigital görünmesi dikkat çekici. Fakat imzanın kimin elinde kullanıldığı ve tedarik zincirinin hangi noktasında zararlının eklendiği yalnızca sertifikadan çıkarılamaz. Videostrong'un rolüne ilişkin genel atıf Google'ın araştırmasına dayanıyor; benim incelediğim dosyalar bu ticari ilişkinin tüm ayrıntılarını ispatlamıyor.
21 KB'lık preset APK'nin DEX dizelerinde x.cpe.receiver.BootReceiver, x.cpe.UpgradeService, OEM_FOLDER, copyInstallFile ve execInstallCommand adlarını görmek, açılışta OEM bölümünden kurulum mekanizmasını ayrıca destekledi.
İkinci uygulama: BoxFactoryTest ve com.oem.qa
XCPE'yi ararken başka bir paket daha dikkatimi çekti: com.oem.qa. Bunun da çalışan sürümü /data/app/ altındaydı, UID 1000 kullanıyordu ve /system/priv-app/BoxFactoryTest_preset ile /oem/BoxFactoryTest_sign bileşenleri vardı. com.oemservice ile com.oem.qa için görülen son güncelleme zamanları 13 Şubat 2025'te yalnızca üç saniye arayla kaydedilmişti. 1970 ve 2009 gibi diğer dosya zaman damgaları ise gerçek yükleme tarihi sayılabilecek güvenilir kayıtlar değildi.
Bu paralellik üzerine BoxFactoryTest dosyalarını da aldım. Fakat önemli bir sınır var: com.oem.qa'nın zararlı olduğu henüz kanıtlanmadı. Gerçek bir fabrika kalite kontrol uygulaması da aynı dağıtım mekanizmasını kullanıyor olabilir. Şimdilik onu şüpheli değil, daha fazla analiz gerektiren ayrı bir bileşen olarak ele alıyorum.
| BoxFactoryTest dosyası | SHA-256 |
|---|---|
BoxFactoryTest_preset.apk | 932cb88c47df119f651df1be54146161004926d4810f03725379a4100547ea5e |
BoxFactoryTest_sign | 6e95ce13846189b2f637f66e1829c0d5d7f73817d356fa2d3e6a2774667b3ced |
com.oem.qa.apk | d1f5e005d75afb6f6eab3e0e4207342deaa5b3d5e6ac5ca10d077374093b1ca7 |
Çalışan süreçler ve ek modüller
ps -A ile yaptığım kontrolde XCPE'nin gerçekten çalıştığını gördüm:
com.oemservice
com.oemservice:NetworkService
com.oemservice:WorkServiceİlk anda com.abc.nexus, Linkfog, Moyu veya AppSalt isimli başka bir paket ve süreç çıkmadı. Bu, ek modül bulunmadığını kanıtlamıyor: native ikili dosyalar farklı isimlerle çalışabilir veya modüller daha önce kaldırılmış olabilir. com.android.proxyhandler gibi adında “proxy” geçen normal Android bileşenlerini de doğrudan zararlı saymamak gerekiyor.
Ağ bağlantısını kesmek sandığım kadar kolay olmadı
Cihazım ZTE H3600 V9 yönlendiriciye bağlıydı. Modemin Türk Telekom firmware'inde WAN → Güvenlik → Ebeveyn Denetimleri bölümünden yalnızca bu cihazın MAC adresi için Genel Ağ Erişimini Yasakla kuralı oluşturdum. Böylece yerel ADB erişimini korurken interneti kesmeyi amaçladım. IPv4 tarafında 1.1.1.1 adresine üç ping denemesinin tamamı başarısızdı; TCP/443 için toybox nc de zaman aşımına uğradı.
adb shell ping -c 3 -W 2 1.1.1.1
adb shell 'echo test | toybox nc -w 5 1.1.1.1 443'
adb shell cat /proc/net/tcp
adb shell cat /proc/net/tcp6Ancak IPv6 TCP tablosunda dış adreslerle ilişkili bağlantı kayıtları vardı; hatta bir tanesi ESTABLISHED durumundaydı. Bu, engelleme kuralı sonrasında gerçekten yeni veri aktarıldığının kesin kanıtı değil; önceden kurulmuş soketlerin kalıntıları da olabilir. Yine de IPv6'nın tam olarak engellendiğini doğrulayamadım. Bu yüzden inceleme dışında cihazın gücünü kesmek veya tamamen internetsiz bir test ağı kullanmak daha güvenli.
Hesaplar ve kurulu uygulamalar
dumpsys account ile cihazda kayıtlı tek bir Google hesabı olduğunu gördüm; e-posta adresini burada yayımlamıyorum. Netflix, Prime Video, Disney+, HBO Max, Spotify, tabii, YouTube ve VLC gibi uygulamalar kurulu. Ayrıca Proton VPN ve ExpressVPN de vardı. İkisini ne zaman kurduğumu hatırlamayınca kurulum kayıtlarına baktım: her ikisi de 24 Ocak 2026'da yaklaşık bir dakika arayla kurulmuş ve yükleyici olarak Google Play görünüyordu. Bu kayıtlar, uygulamaları zararlının kurduğunu göstermiyor; benzer şekilde yükleyici bilgisinin Play Store olması da kimin başlattığını kesinleştirmiyor.
Bütün ev ağının ele geçirildiğine ilişkin bir bulgu elde etmedim. Buna rağmen güvenilir başka bir bilgisayardan Google cihaz oturumlarını, iki aşamalı doğrulamayı ve streaming servislerinin aktif oturumlarını kontrol etmek yerinde. Her hesapta farklı parola kullanmak olası zararı sınırlandıran önemli bir avantaj. Elimizdeki kanıtlar, bütün parolaları gelişigüzel değiştirmeyi veya diğer cihazları topluca sıfırlamayı gerektirmiyor.
Peki neden fabrika ayarlarına dönmüyorum?
Çünkü burada tek bir kullanıcı APK'sı yok. Firmware'in korunan sistem ve OEM bölümlerinde yeniden kurucu bileşenler var. Yalnızca pm uninstall kullanmak, yeniden başlatma sonrasında arka kapının geri gelmesini engellemeyebilir. Kalıcı çözüm, bu modele uygun ve gerçekten temiz olduğu doğrulanmış firmware'in güvenli biçimde yüklenmesi olabilir. Ama rastgele bir imajla bootloader veya sistem bölümleri üzerinde işlem yapmak cihazı açılmaz hâle getirebilir; DRM ve sertifikasyon sorunları da doğurabilir. Bu yazı hazırlanırken HP4414/YYC için güvenilirliği doğrulanmış temiz kurtarma imajı henüz bulunmuş değildi.
Google'ın Videostrong'u yeni sertifikalı cihaz üretiminden men etmesi, benim kutumdaki YouTube veya Netflix'in otomatik kapanacağı anlamına da gelmiyor. Bunu denemek için cihazın internet engelini kaldırmak gereksiz risk olurdu. Bu nedenle “servisler hâlâ çalışıyor mu?” testini yapmadım.
Satın alma ve iade meselesi
Cihazı 23 Ocak 2026'da Hepsiburada üzerinden Techstorm satıcısından 2.966 TL'ye almışım. Kasımda aynı sınıftaki ürünlerin fiyatı yaklaşık 4.000 TL düzeyine çıkmıştı. Bu yüzden yalnızca eski bedeli geri almak aynı ürünü yeniden almayı karşılamıyor. Satıcıya ayıplı mal gerekçesiyle güvenli bir muadil veya bedel iadesi talebi yöneltmeyi değerlendiriyorum. 6502 sayılı Kanun'da ayıplı mala ilişkin seçimlik haklar var; hangi çözümün uygulanacağı somut koşullara bağlı. Henüz satıcıdan kabul veya ret gelmiş değil. Techstorm'un kataloğundaki Homatics Box R 4K Plus gibi alternatifler ise ciddi fiyat farkı gerektiriyor.
Bugünkü durum ve açık sorular
Sonuç olarak XCPE'nin cihazda bulunup bulunmadığı sorusunun cevabı artık evet. Paket adı, sistem UID'si, firmware başlatıcısı, OEM paketi, çalışan süreçler, APK içindeki komuta-kontrol dizeleri ve SHA-256 ile doğrulanan kopyalar birbirini destekliyor. Fakat başka nelerin yüklendiği, geçmişte ne kadar veri aktarıldığı, BoxFactoryTest'in rolü ve temiz firmware ile kurtarma imkânı hâlâ açık sorular. Bunları kanıtlamadan kesin hüküm vermek istemiyorum.
İronik olan şu: kutuyu aldığımda Google sertifikası benim için bir güven işaretiydi. Oysa burada asıl güven sınırı, uygulama mağazası değil cihazın üretim ve firmware tedarik zinciriymiş. Birkaç ADB komutuyla başlayan merak, evdeki küçük TV kutusunun içinden doğrudan sistem yetkili bir arka kapının çıkmasıyla sonuçlandı. Araştırma ilerledikçe bu yazıyı güncelleyeceğim; şimdilik cihazı normal kullanım için güvenli kabul etmiyorum.
Kaynaklar:
Google Threat Intelligence Group — Shutting the Door on the XCPE Botnet (2 Kasım 2026)
Synthient — The Internals of a Badbox Operation
T.C. Ticaret Bakanlığı — Ayıplı mal ve hizmetler hakkında bilgilendirme
Etiketler: MECOOL, XCPE, Videostrong, Android TV, Android 14, ADB, firmware, backdoor, botnet, malware, reverse engineering, Skyworth, siber güvenlik
