Apple TV'de Protobuf şifresini çözerek ve değiştirerek YouTube reklamlarını engellemek

• Apple TV ve iPhone’da YouTube reklamlarını ağ katmanında engellemek için pfSense, DNS engelleme, VPN yönlendirme, Squid, MITMProxy ve en sonunda Protobuf yanıtlarını değiştirme dahil çeşitli yöntemler denendi
• YouTube reklamları normal videolarla aynı alan adlarından sunulduğu için Pi-hole ve pfBlockerNG gibi DNS tabanlı engelleme yöntemleriyle içerik ile reklamı güvenilir biçimde ayırmak zordu
• TLS trafiği MITMProxy ile çözüldükten sonra web YouTube’da JSON reklam alanları kaldırıldı; iOS uygulamasında ise application/x-protobuf yanıtlarının içindeki reklam yapıları doğrudan bulunup değiştirildi
• Python tabanlı tam Protobuf çözümlemesi pfSense yönlendiricisinde yaklaşık 23 saniye sürse de, /pagead/ çevresinde doğrusal tarama yapan bir yöntemle 1.8MiB payload bile gerçek zamanlı işlenebilir hale geldi
• Bu yöntem, güvenilir bir CA kurulumu ve yeterli CPU performansı gerektiriyor; ağa bağlı Apple cihazlarında reklam engelleme mümkün olsa da, sonunda YouTube Premium ödemesi de düşünülmeye başlandı

---

pfSense yönlendirici ve ağ ayrımı

• Amaç, FreeBSD·pfSense tabanlı bir yönlendirici kurarak Apple TV ve iPhone’daki YouTube pre-roll, mid-roll ve end-roll reklamlarını tüm ağ genelinde engellemekti
• Kullanılan donanım, AES-NI komut setine sahip bir J4125 mini PC, DDR4 RAM, mSATA SSD ve pfSense kurulumu için bir USB sürücüydü
  • Örnek yapılandırma 32GiB RAM ve 128GB mSATA SSD içeriyordu
  • 128GB depolama alanının loglar, SSD aşınmasını azaltma, paket yakalama ve edge cache alanı için yararlı olduğu düşünülüyordu
• pfSense kurulduktan sonra LAN 1, mevcut DHCP aralığı dışında kalan statik IP 192.168.1.3 olarak ayarlandı ve yönetim web portalına admin/pfsense hesabıyla erişildi
• pfSense kontrol panelindeki AES-NI CPU Crypto: Yes (inactive) göstergesi doğrulandıktan sonra System › Advanced › Miscellaneous bölümünden AES-NI elle etkinleştirildi
• 32GiB RAM’den yararlanmak için /var ve /tmp altında RAM disk’e bol alan ayrıldı ve RAM-disk yedeklerinin her saat yapılması sağlandı

DNS engelleme ve fiziksel ağ ayrımı

• Mevcut Pi-hole yerine pfSense paketi olan pfBlockerNG-devel kurularak reklam/kötü amaçlı içerik engelleme ve coğrafi engelleme yapılandırıldı
  • Kurulumla yaklaşık 20MiB ek alan kullanıldı
  • pfb_dnsbl servisi başlamazsa veya [ Missing CRON task ] görünürse /var/run/booting içindeki boş dosyanın silinmesi öneriliyordu
• pfSense yönlendiricideki 3 Gigabit port, VLAN yerine fiziksel LAN ayrımı için kullanıldı
  • Alexa ve Apple TV gibi sürekli dışarıyla konuşan cihazlar ayrı bir donanımsal LAN’a alındı
  • Kritik LAN ile akıllı cihazlar/Wi-Fi cihazları ayrılarak bankacılık, hisse işlemleri ve crypto wallet kullanılan cihazların korunması amaçlandı
• Akıllı cihaz ağı 172.31.1.0/24 olarak ayrıldı; daha güvenilir görülen LAN ise 192.168/16 üzerinde bırakıldı
  • Ağlar arasında rota yoksa hatalı yapılandırılmış iptables kurallarının etkisinin de bir ölçüde azalacağı düşünülüyordu
  • Yeni ağ cihazlarının adres alabilmesi için fiziksel NIC üzerinde DHCP resolver etkinleştirilmeliydi
• AC1200 Archer C5; AP mode eksikliği, uzaktan erişim sorunları, eski stock firmware ve Broadcom chipset için yetersiz OpenWRT/DD-WRT/Tomato desteği nedeniyle kullanımdan çıkarıldı
• Sonrasında Nighthawk R7000, Apple/Amazon/TV için bir AP ve Trusted Wireless Network için başka bir AP olarak kullanıldı
  • Trusted Wireless Network’te 2.4GHz kapatılıp yalnızca 5GHz kullanılması planlandı
  • 5GHz’in duvar ve betondan daha kolay etkilenmesi nedeniyle orta mesafe snooping’e karşı avantaj sağlayacağı düşünülüyordu

Tüm DNS trafiğini pfSense’e zorlama

• pfSense arkasındaki tüm istemcilerin yerel Unbound DNS sunucusunu kullanması için NAT kuralları eklendi
  • Amaç, uygulamaların ve ev otomasyonu bileşenlerinin kendi DNS sunucularını ya da sabit kodlanmış DNS adreslerini kullanarak bunu aşamamasını sağlamaktı
  • pfBlockerNG’nin DNS isteklerine müdahale edebilmesi için DNS over TLS’in engellenmesi gerekiyordu
• NAT kuralları önce WAN dışındaki her arayüz için oluşturulurken, daha sonra Non_WAN firewall alias ile sadeleştirildi
  • Hem IPv4 hem IPv6 için 53 numaralı porta giden yerel DNS sorguları localhost’a yönlendirildi
  • NAT reflection devre dışı bırakılmalıydı; aksi halde dış internetten yerel DNS sunucusuna erişim mümkün olabilirdi
• Services › DNS Resolver › Display Custom Options bölümüne server: log-queries: yes eklenerek yakalanan DNS isteklerinin loglanması sağlandı
• DNS loglarında Windows’un Google Tag Manager’a erişmeye çalıştığı görüldü; ilgili istek var olmayan 10.10.10.1 IP’sine blackhole edilerek düşürüldü

VPN ile YouTube reklam hedeflemesini aşma denemesi

• YouTube reklamları normal videolarla aynı alan adlarından geldiği için pfBlockerNG ya da Pi-hole gibi alan adı engelleyicilerle yalnızca reklamları ayıklamak zordu
  • googleadservices.com engellemesinin ancak reklam videosu izlenip reklama tıklandıktan sonra anlamlı olacağı düşünülüyordu
  • Tarayıcıda uBlock Origin JavaScript’e müdahale edebilse de, iPhone YouTube uygulamasında jailbreak olmadan reklamları sınırlamanın zor olduğu değerlendiriliyordu
• Reklamları doğrudan engellemek yerine, YouTube reklam algoritmasının kullanıcıyı daha az cazip bir hedef olarak görmesini sağlamaya yönelik deneyler yapıldı
  • Fikir, Apple TV trafiğini VPN üzerinden geçirmek ve YouTube izleyicisinin az olduğu bir bölgedeki VPN çıkış noktasını kullanmaktı
  • Hedef, kullanıcıyı İtalya’da yaşayan 70 yaşında bir erkek gibi göstermekti
• pfSense üzerinde WireGuard yapılandırıldı ve NordLynx/WireGuard private key Linux VM’den alınıp ayarlara eklendi
  • Tünel adresi girilirken 1.0.0.0 ve subnet mask 0 yazıldığında, arayüz sonucu 0.0.0.0/0 olarak gösteriyordu
• Apple TV’nin tüm trafiği VPN’e yönlendirildiğinde YouTube İtalyanca görünmeye başladı ve reklam sayısı azaldı; ancak Netflix ve Amazon Prime’da sorunlar çıktı
  • CSS ya da font dosyaları engelleniyormuş gibi görünüyor, thumbnail’ler yüklenmiyordu
  • Netflix ve Prime’ın VPN sağlayıcılarına karşı geofencing konusunda başarılı olduğu uyarısı yapıldı
• Daha sonra yalnızca YouTube ile ilgili FQDN’leri VPN üzerinden yönlendirmek için www.youtube.com, youtube.com, googlevideo.com, accounts.google.com, googleapis.com, gstatic.com gibi adresler aday olarak belirlendi
  • Yapılandırmadan sonra YouTube kullanıcıyı Milano’da, Netflix ve Prime Video ise Kanada’da görüyordu
  • Reklamlar seyrekleşti ve görünen reklamlar da İtalyanca oldu

DNS race condition ve wildcard alan adı sorunu

• Bir gün sonra pfSense hostname alias ile istemci DNS önbelleğinin farklı YouTube IP kümeleri gördüğü bir DNS race condition keşfedildi
  • pfSense hostname alias için varsayılan çözümleme aralığı 300 saniyedir
  • YouTube DNS TTL değeri 1.440 saniye olarak gözlemlendi
• Alias Daemon'ın FQDN'yi çözümlediğinde aldığı IP ile Apple TV'nin daha sonra aldığı IP eşleşmezse trafik VPN tüneline girmeyebilir
  • Hafifletme yöntemi, pfSense'in hedef TTL'yi yok sayıp alias girdisini daha uzun süre önbellekte tutmasını sağlamaktır
• googlevideo.com üzerindeki türetilmiş alt alan adları wildcard yönlendirme gerektiriyordu, ancak NAT ve firewall kuralları IP tabanlı çalıştığı için wildcard hostname'leri doğrudan işleyemiyordu
• DNS yanıt IP'lerini yakalayıp bunları dinamik olarak VPN_wildcards alias'ına eklemek için Unbound Python modülü ve pfSense REST API kullanan bir PoC yazıldı
  • VPN_wildcards TTL değeri 1 saat, kapasitesi ise 500 olarak ayarlandı
  • A kayıtları ipaddress.IPv4Address, AAAA kayıtları ise ipaddress.IPv6Address ile ayrıştırıldı
• Sabah yapılan kontrolde Unbound DNS Resolver'ın segfault durumunda olduğu görüldü ve her IP eklemesinde pfSense kural yeniden yüklemesi gerektiğinden pfSense çok yavaşladı

Squid ve MITMProxy ile HTTPS şifresini çözme

• Yeni hedef, Squid benzeri bir proxy kurup sahte ama güvenilen bir CA sertifikasını cihaza ekleyerek TLS trafiğinin şifresini çözmekti
• Squid, pfSense paketi olarak kuruldu ve SSL Filtering smoke test'i de başarılı oldu, ancak sonrasında vazgeçildi
  • Performansı çok yavaştı
  • ACL yapılandırması zahmetliydi
  • https://http/* ile ilgili bir sorun vardı
  • SquidGuard URL filtre listesi güncellemesi çok uzun sürüyordu
  • Squid arayüzünün yetersiz olduğu düşünüldü
• Sonrasında MITMProxy seçildi
  • Python scripting ve bir arayüz sunduğu, ayrıca YouTube reklam engelleme için genişletilebileceği düşünüldü
  • mitmproxy 7.0.4 Linux tarball'u FreeBSD'de ELF interpreter /lib64/ld-linux-x86-64.so.2 not found ve eksik kütüphaneler nedeniyle çalışmadı
• pfSense'in FreeBSD jail ortamına pkg install mitmproxy ile kuruldu
  • Kurulan paket sayısı 50, ek alan ihtiyacı 206MiB, indirme boyutu ise 33MiB idi
  • jail içinde mitmproxy çalıştırıldığında arayüz açıldı
• MITMProxy deneyi için pfSense üzerinde 127.0.1.1 sanal IP'si localhost'a bağlandı ve NAT kuralıyla [Private IPs]:8080, 127.0.1.1:8080 adresine yönlendirildi
  • Kurban olarak kullanılan dizüstü bilgisayarda proxy 192.168.20.1:8080 olarak ayarlanınca tarayıcı istekleri MITMProxy arayüz günlüğünde görünmeye başladı
• MITMProxy CA PEM dosyası ~/.mitmproxy/mitmproxy-ca-cert.pem konumundadır
  • Python 3 web sunucusuyla cert.pem sunuldu
  • MITMProxy aynı CA sertifikasını mitm.it üzerinden de sağlıyor
  • Temiz bir dizüstü bilgisayara ve iPhone'a sertifika eklendi

MITMProxy işletimi ve certificate pinning ile başa çıkma

• Yönlendiricide mitmproxy, boşta olsa bile yüksek CPU kullanıyordu; bunun nedeninin her istekte TLS sertifikasını anında üretmesi ve arayüzün aşırı günlükleme yapması olduğu düşünüldü
• mitmdump, arayüzü ve aşırı günlüklemeyi atladığı için CPU yükünün daha düşük olduğu değerlendirildi
  • Çalıştırırken --anticomp, --mode regular, --listen-port 8080, --listen-host 127.0.1.1 gibi seçenekler kullanıldı
• Certificate Pinning, sunucunun veya istemcinin beklenen sertifika fingerprint'ini önceden bildiği için MITMProxy'nin sertifika sahteciliğinin işe yaramadığı bir tekniktir
  • Geçici çözüm olarak --ignore-hosts kullanılarak apple.com:443, icloud.com:443 gibi host'ların proxy'yi atlaması sağlandı
• Transparent Proxy Mode'da --allowed-hosts seçeneğinin SNI temelinde daha iyi çalışması için MITMProxy 7.0.4'ün next_layer.py dosyası yamalandı
  • Daha önce birçok durumda eşleştirme için yalnızca sunucu IP'sinin kullanıldığı düşünüldü
  • Yama, hostname adayı olarak yalnızca server.address[0] değil server.sni değerini de ekliyordu
• Yamadan sonra bazı host'lar güvenilir şekilde yakalanabilirken geri kalanların geçmesine izin verilebildiği belirtildi

Web YouTube'da JSON reklamlarını kaldırma

• MITMProxy smoke test'lerinde YouTube reklam ve takip URL'leri küçük bir betikle engellendi
  • youtube.com üzerinde /pagead/, /log_event?, /stats/ads, /stats/qoe?, /ptracking?, /generate_204, el=adunit, adformat=, /activeview? gibi yollar engellendi
  • google.com ve google.ca için /pagead/ engellendi
• İlk testlerde engellenen isteklerin DevTools Network panelinde de gerçekten engellendiği görüldü
  • (failed) girdileri betikten kaynaklandı
  • 502 hatalarının, pfBlockerNG'nin isteği black-hole işlemine tabi tutmasının sonucu olduğu düşünüldü
  • Aynı kanal üzerindeki sonraki isteklerin geçmemesi için HTTP/2 devre dışı bırakıldı
• Yalnızca basit URL engelleme reklamları tamamen ortadan kaldırmadı; bu nedenle YouTube HTML·JavaScript'i ve uBlock Origin filtreleri incelenerek reklam bilgilerinin JSON yanıt gövdesinde olabileceği izlendi
• MITMProxy'nin yakaladığı JSON yanıtlarda playerAds ve playbackTracking yapılarında reklam ve takip bilgileri doğrulandı
  • playerAds içinde playerLegacyDesktopWatchAdsRenderer, playerAdParams, gutParams.tag, showCompanion, showInstream, useGut yer alıyordu
  • playbackTracking içinde videostatsPlaybackUrl, ptrackingUrl, qoeUrl, atrUrl yer alıyordu
  • youtubeRemarketingUrl, www.youtube.com/pagead/viewthroughconversion/... biçimindeydi
• Web YouTube'da, JSON payload içinden reklam bilgilerinin kaldırılmasıyla yönlendirici üzerinden web reklamları ortadan kaldırılabildi

iOS YouTube ve Protobuf analizi

• iOS YouTube uygulaması, web sürümüne benzer API çağrılarında JSON yerine Protocol Buffer (Protobuf) biçiminde veri kullanıyor
  • Protobuf'ta anahtarlar sayısaldır ve değişebilir; bu yüzden JSONPath yaklaşımıyla reklam bölümünü bulmak zordur
  • payload içinde “Telus”, “Samsung TV”, “Boxing Week”, “Buy now” gibi reklam metinleri görüldü
• iOS YouTube ağ trafiği, web trafiğinden farklıydı
  • Web sürümünde video chunk'larının range ya da clen parametrelerinden reklam adayları bir ölçüde tahmin edilebiliyor
  • iOS protokolü range sorgu parametresi veya Range header'ı kullanmıyor; bunun yerine &nr=2, &nr=3 gibi sayaçlar kullanıyor
• Protobuf yanıtı decode edilip çevrimdışı analiz edilirken has_unlimited_entitlement: False, has_premium_lite_entitlement: False gibi alanlar bulundu
  • Bu değerleri değiştirmenin “hile” gibi hissettirdiği için yeniden sezgisel yaklaşıma dönüldü
• Reklam URL'lerini engelleme denemeleri, iOS uygulamasında sonsuz döngüye, UI hatalarına ve çökmelere yol açtı
  • Boş body ile 200, 404, 503, kesilmiş response body ve reklam videosunun bir kısmını null yapma gibi yöntemler uygulamayı yavaşlattı ya da bozuk durumda çökmesine neden oldu
  • /error_204/ error-reporting endpoint'i “dev assertion failed” durumunu gösterdiği için engellendi
• Reklamların, belirli bir video içindeki slot'lara kaydedildiği anlaşıldı
  • Slot türleri arasında pre-roll, mid-roll, end-roll, full-page ve ad pod var
  • Yalnızca reklam URL'sini engellemek, “var olmayan bir reklam slot ayırttı” benzeri hatalara yol açıyor ve UI'ı panic durumuna sokuyordu

Protobuf performans sorunları ve blackboxprotobuf

• Yalnızca Python kullanarak yaklaşık 500KiB ham Protobuf verisini insanın okuyabileceği metne decode etmek çok yavaştı
  • i7-6700 CPU'lu masaüstünde yaklaşık 2.06~2.11 saniye sürdü
  • pfSense router'da yaklaşık 22.8~24.2 saniye sürdü
• C++ protoc --decode_raw çok daha hızlıydı
  • i7-6700 CPU'lu masaüstünde yaklaşık 0.017~0.022 saniye sürdü
  • pfSense router'da yaklaşık 0.12~0.14 saniye seviyesindeydi
• Python'da ham decoding desteklenmediği için C++ protoc binary'siyle subprocess.Popen üzerinden doğrudan iletişim kurma yöntemi seçildi
• Burp Suite için blackboxprotobuf, ham Protobuf wire message'ını decode edip değer enjekte ettikten sonra yeniden encode edebiliyor
  • PyPI fork'u değil, özgün Burp Suite sürümünün kullanılması öneriliyor
  • Bazı fork'lar derin recursion nedeniyle stack overflow'a yol açabiliyor
  • os.environ["PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION"] = "cpp" satırı, protobuf import edilmeden önce ayarlanırsa mümkün olduğunda C++ libprotobuf.so implementasyonunu kullanıyor
• blackboxprotobuf içindeki protobuf_to_json(data), tahmine dayalı bir .proto schema üretebiliyor; ancak sonuç çok büyük, derin iç içe geçmiş ve kusursuz değil
  • Python schema dump'ı yaklaşık 250.000 karakterden fazlaydı
  • Buna rağmen reklam ayrıntılarını çıkarmak için yeterli olduğu düşünüldü

1 baytlık değişiklikle reklam bölümünü etkisiz hale getirmek

• Protobuf Wire Format'ta, özgün schema olmadan decode/edit/re-encode yapıldığında encoding değişebiliyor
  • Bunun nedenleri arasında ZigZag encoding kullanılıp kullanılmadığının anlaşılamaması, sayı türünün belirlenememesi ve object field sırasının deterministik olmaması sayılıyor
• Çözüm, Protobuf'un backward compatibility özelliğini kullanarak reklam bölümünü bilinmeyen bir field gibi göstermektir
  • Eski yazılımın yeni field'ları okurken bilinmeyen field'ları yok sayması davranışından yararlanılıyor
  • Kritik noktadaki 1 baytı değiştirip derin iç içe geçmiş bölümü gelecekteki bir schema sürümüne aitmiş gibi göstermek, Protobuf'un bunu yok saymasını sağlıyor
• Hedef field key 49399797, basit bir string aramasıyla değil, varint tag scanning ile bulunmak zorundaydı
  • Wire type 2; bu da length-delimited nested string/message anlamına geliyor
  • Hedef tag AA FF B8 BC 01 olarak hesaplandı
  • Wire type'ın 3 bit'i kaydırılarak field key 49399797 yeniden elde edildi
• Gerçek arama, ham Protobuf byte'larında önce /pagead/ gibi reklam URL imzasını bulup sonra yakın çevresinde geriye giderek hedef field tag ve field key'i arama yöntemiyle yapıldı
  • Örnek intercept hedefi POST youtubei.googleapis.com:443/youtubei/v1/browse?key=... idi
  • Yanıt 200, application/x-protobuf, 1.87m idi
  • Örnek log'da 49399797 konum 4465'te, 50195462 ise konum 4477'de bulundu
• O(n) smoke test'te 1.8MiB Protobuf veri, ek bellek kullanılmadan tek taramada tarandı ve reklam kaldırmanın çalıştığı görüldü
  • Hedef 30.593. baytta bulundu
  • Bozulacak field key'i bulmak için yaklaşık 600 bayt geriye izleme yapıldı
  • Artık *.googleadservices.com ya da /pagead/ içeren URL'leri engellemek gerekmiyor; ilgili istekler en baştan oluşturulmuyor

MITMProxy eklentisinin yapısı

• PoC betiği youtube.py olarak kaydediliyor ve mitmdump --listen-port 8080 --listen-host 127.0.0.1 -s "youtube.py" ile çalıştırılıyor
  • FreeBSD önkoşulu olarak pkg install protobuf, pkg install py38-pip, pip install jsonpath-ng sunuluyor
• Betik Logger, trunc, KilledError, JSONPathReplacement, ProtobufDebugParser, YouTubeAdBlocker sınıflarından oluşuyor
• YouTubeAdBlocker için intercept hedefi host regex'i \.youtube\.com|google\.(com|ca)|googleapis\.com|googleadservices\.com|googlevideo\.com
  • Protobuf reklam URL arama dizgesi b"/pagead/"
  • arama sınırı 80_000
  • hedef alan etiketi 50195462
• İstek engelleme kuralı, host'a göre partial URL dizgelerini kontrol edip flow'u kill ediyor
  • youtube.com hedefinde pagead/, log_event?, stats/ads, stats/qoe?, ptracking?, generate_204, error_204, adformat=, activeview?, _ad_, ai?, sw.js vb. bulunuyor
  • sw.js için service worker'ların reddedildiğine dair bir yorum var
• JSON yanıtlarında çeşitli JSONPath replacement'ları uygulanıyor
  • $.responseContext.serviceTrackingParams[*].params[?(@.key == 'yt_ad')].value "0" olarak değiştiriliyor
  • $..adPlacements [] olarak değiştiriliyor
  • $..adPlacementRenderer, $..adPlacementConfig, $..playerAdParams, $..gutParams {} olarak değiştiriliyor
  • $..adVideoId boş dizgeye çevriliyor
  • $..showCompanion, $..showInstream, $..useGut False olarak değiştiriliyor
• Protobuf yanıtlarında, content type içinde protobuf geçtiğinde body bytearray'e dönüştürülüyor ve /pagead/ ilk 80.000 bayt içinde aranıyor
  • TagBytes(self.target_field_tag, WIRETYPE_LENGTH_DELIMITED) ile hedef etiket baytları oluşturuluyor, ardından target_field_tag - 1 için yeni baytlar oluşturuluyor
  • /pagead/ konumunun hemen öncesine kadar geriye doğru arama yapılıp hedef etiket baytları bulunuyor
  • Bulunursa ilgili baytların üstüne yeni baytlar yazılıyor ve flow.response.set_content(bytes(body)) ile yanıt gövdesi değiştiriliyor
• Yorumlara göre bu PoC reklamların %90'ını engelliyor
  • Diğer section'larda da başka field key'leri var ve bozularak değiştirilmesi gereken birden fazla reklam section'ı olabilir

Uygulama kapsamı ve sınırlamalar

• Bu teknik, Apple cihazlarındaki YouTube reklamlarını veya Instagram, WhatsApp, Facebook gibi tracker trafiğini engellemek için oldukça özelleşmiş bir teknik olarak özetleniyor
• HTTPS trafiğini decrypt/re-encrypt etmenin CPU gereksiniminin, Raspberry Pi'nin kaldırabileceği seviyenin çok üstünde olduğu düşünülüyor
• Apple TV jailbreak edildikten sonra pfSense root certificate eklenirse, pfSense gateway'nin Apple TV trafiğini çözerek request header içindeki reklam hostname'lerini inceleyip engelleyebileceği öne sürülüyor
  • Ancak bunun hâlâ iPhone reklamlarına uygulanamayacağı, iPhone jailbreak'in daha zor olduğu ve banking app'lerin bunu tespit edip çalışmayabileceği belirtiliyor
  • jailbreak'in kendisinin de fazla uç bir yöntem olduğu değerlendiriliyor
• Sahte ama güvenilen bir CA mümkünse TLS packet'ları düz metin olarak çözülebilir ve URL engelleme uygulanabilir
  • Örnek engelleme URL'leri olarak YouTube'un /pagead/viewthroughconversion/... ve /pagead/conversion/... yolları veriliyor
• Sonuç olarak donanım router baştan yapılandırılıyor, LAN güvenilir ve güvenilmeyen bölgelere ayrılıyor, DNS reklam engelleme ve şeffaf MITM proxy ekleniyor; ardından ağa bağlı Apple cihazlarında YouTube reklamları yüksek performansla engelleniyor

YouTube Premium ve içerik üreticilerini destekleme

• Birkaç ay boyunca YouTube reklamlarını engelledikten sonra, içerik üreticilerini desteklemek istediği için YouTube Premium ödemeye başladığını söylüyor
  • “Yapabiliyor olmak, yapılması gerektiği anlamına gelmez” notunu ekliyor
• YouTube Premium fiyatı CAD $9.99/mo'dan $11.99/mo'a, vergi dâhil yaklaşık $13.43/mo olarak anılıyor
• Reklam izleme deneyinde temiz bir dizüstü bilgisayar ve gizli tarama ile bir gün boyunca YouTube'u aralıklı olarak izlemiş
  • Kayıtlara göre izlenen video sayısı 10'du
  • 8 reklama maruz kalındı ve bunların yalnızca 2'si atlanabiliyordu
• CPV'nin USD $0.15 olduğu varsayılırsa günlük reklam maliyeti $1.20, aylık dışa vurum yaklaşık USD $36/mo oluyor
• Statista verileriyle yapılan başka bir hesapta, 2019'da ABD'li reklamverenlerin YouTube'a $15.1 billion harcadığı ve ABD'de yaşayan kullanıcıların 916 billion video izlediği, buna göre görüntüleme başına ortalama USD $0.0165 çıktığı belirtiliyor
  • Bu hesap uygulanınca günlük maliyet yaklaşık USD $0.13, aylık dışa vurum ise yaklaşık USD $3.96 oluyor
  • Bunun Premium'un USD $10 seviyesine yakın olmadığı yorumu yapılıyor
• DMCA claim gelirse reklam gelirinin içerik üreticisine değil, Sony veya Viacom gibi claim'i yapan tarafa gidebileceği belirtiliyor
  • Bu yüzden sevilen kanallara farkında olmadan hiçbir katkı sağlanmamış olabilir
  • Birçok içerik üreticisinin Patreon'a yönelmesinin şaşırtıcı olmadığı değerlendiriliyor

[xguru]

Orijinal yazı aşırı uzun. Süreç ilgi çekici ama asıl nokta, yazının yazarının da sonunda YouTube Premium’a ödeme yapıp kullanıyor olması.

[GN⁺]

Hacker News yorumları

• Genel olarak havalı bir hack, ancak Protobuf hakkındaki bazı ifadeler tuhaf geliyor
  Protobuf’ta bir alanın etiketini kasten bozmuş; tanınmayan etiket numaralarını yok saymak bir “kusur” değil, genişletilebilirlik için temel tasarımın parçası
  1,87 MiB de o kadar büyük bir boyut değil ve bu tür mesajlar sürekli akış halinde geliyor olmasa gerek; bu yüzden bunu bir performans bariyeri olarak açıklamak da pek ikna edici değil
  Protobuf kodlaması, çözme maliyetini pahalı yapmak için değil, tam tersine verimli biçimde çözülebilecek şekilde tasarlandı; özgün .proto şeması olmasa bile UnknownFieldSet ile doğrudan çözülebilir
  Daha iyi yöntem, kaldırılmak istenen tek alanı içeren sahte bir .proto şeması kullanmak olurdu. Dize tarama yaklaşımı, aynı bayt dizisi tesadüfen başka verilerde de görünebileceği için hataya daha açık
  Alan sırası değişirse yeniden kodlanan sonucun baytları farklı olabilir, ancak alıcı bunu aynı mesaj olarak işlemeli; YouTube uygulamasının alan sırası değişikliğini algılama ihtimali düşük görünüyor
  Daha önce Protobuf üzerinde çalışmış biri olarak, yazar bu kısmı yanlış anlamış gibi görünüyor

  • İyi bir analiz, ama 1,87 MB’ın küçük olduğu görüşüne pek katılamıyorum
    Hayatımın çoğunu kırsal bölgelerde geçirdim; kendi Wi‑Fi’ım değilse bu kadarı bile pratikte büyük bir indirme. Mobilde bazı dolanma yolları olabilir, ama kırsal Wi‑Fi hâlâ Web 2.0 yapısıyla zorlanıyor ve genellikle 2–4G hızlarında kullanılıyor
    Kentsel bölgelerde, altyapıyı destekleyecek nüfusun olduğu yerlerde 1,87 MB genel olarak küçük bir dosya haline gelmiş olabilir; ancak kablo hattına bağlı herkesin yayın izlediği akşam 6 civarı bunun istisnası olabilir
  • without the C++ source proto files konusunda küçük bir tanıtım yapayım: ikiliden kaynak .proto dosyaları üreten protodump adlı bir proje yaptım
    Mesaj ve alan tanımlarını, özgün adları da dahil olmak üzere yeniden oluşturuyor; Apple TV kutusundan yalnızca ikiliyi çıkarmanız yeterli
    https://github.com/arkadiyt/protodump
  • “Daha önce Protobuf üzerinde çalıştım” demek inanılmaz ölçüde mütevazı bir ifade. Bilmeyenler için söyleyeyim, Kenton Protobuf’u bugünkü haline getiren kişi
    Protobuf, IDL ile ilk tanışmamı sağlayan teknolojiydi ve o zamanlar sihirli bir fikir gibi görünüyordu. Kendi kötü IDL’imi yaptıktan sonra Protobuf’u keşfedince daha da şaşırmıştım
  • Bu yazıyı okurken ben de benzer şekilde kafam karıştı. Protobuf tasarım ilkeleri gizli değil; hepsi açıkça belgelenmiş durumda
  • Protobuf’u şemasız çözerken en zor kısım, gömülü mesajların ve dizelerin aynı etiket tipini kullanması; yine de oldukça kolay işlenebiliyor
    Tüm protoc bağımlılığını içeri çekmek istemiyorsanız birkaç yüz satırlık basit bir Protobuf çözücüyü kendiniz yazabilirsiniz: https://github.com/kubernetes/test-infra/blob/master/guberna... https://github.com/kubernetes/test-infra/blob/master/guberna...

• 20 yılı aşkın süre önce The Proxomitron’u keşfettiğimden beri, reklamları kaldırmak ve sayfaları kullanıcı CSS’i gibi şeylerle yeniden yazmak için trafiği araya giren bir proxy üzerinden işliyorum
  CloudFlare gibi yerler beni “bot” olarak sınıflandırma eğiliminde, ama bunun da kolay olmasa bile etrafından dolaşmanın yolları var. Bu tür örnekler, uzaktan doğrulamanın kullanıcı özgürlüğü için neden tehlikeli olduğunu da gösteriyor

  • The Proxomitron’a bakınca geliştirmesi 2004’te bitmiş gibi görünüyor; mevcut durumu iyi bilen bir özet olsa ilginç olurdu
    Birkaç “devam” projesi var gibi ve yalnızca Windows’a mı özel olduğunu da merak ediyorum. Uzak içeriğe yerel bağlantılar ekleyebilen basit bir proxy’yi hafifçe araştırıyordum
  • Privoxy ya da pi-hole gibi ağ düzeyinde reklam engellemenin, satır içi reklamları işleyememek gibi çok fazla dezavantajı var
    Şu anda Pi 4’te çalıştırdığım pi-hole’u da sökmüş durumdayım. Birden çok servisle düzgün çalıştırmak için saatler harcadım ama sonunda vazgeçtim; ev ağı için ayırmaya değecek bir zaman değildi
    Gerçekten işe yarayanlar tarayıcı tabanlı reklam engelleyiciler ve ReVanced gibi uygulama patch’leyicileri. Birikimim arttıkça, YouTube Premium, Hulu, Netflix, Max gibi bu ikisiyle çözülemeyen durumlarda reklamsız servis ücretini ödemeye daha çok yöneliyorum
  • Cloudflare çalışanlarının burada gizlice okuduğu bilindiğine göre merak ediyorum: bu şekilde bot olarak sınıflandırılmak yanlış pozitif mi sayılır, yoksa amaçlandığı gibi mi çalışıyor?
  • Proxomitron’u neredeyse 20 yıldır aklıma bile getirmemiştim; hâlâ kullanılıyor mu merak ediyorum
    Burada söylenen amaçla hiç kullanmadım, ama şirket güvenlik duvarının arkasında proxy olarak kullanmak için harikaydı. Eskiden güvenlik duvarı dış bağlantılar için oturum açma bilgisi istediğinden birçok program internete bağlanamıyordu
  • Muhtemelen cihaza yeni bir CA sertifikası yüklenmesini gerektiren bir yöntemdir; doğru mu?

• Docker ile paketlenmiş Privaxy akla geliyor. UBlock Origin engelleme listeleriyle uyumlu bir ortadaki adam proxy’si.
  Akıllı ürünlerde, özellikle de TV’lerde reklam ve izleme betiklerinin ne kadar çok olduğunu görmek şaşırtıcı. Şimdiye kadar test ettiğim kadarıyla gereksiz trafik %40’ı aştı; akıllı TV uygulamalarından reklamları söküp atma deneyi de epey eğlenceliydi.
  https://github.com/deetungsten/webui-privaxy, https://github.com/Barre/privaxy projesinin Docker’laştırılmış bir fork’u.

  • TV’nin kendinden imzalı sertifikaya güvenmesini nasıl sağlamak gerekir?
  • Bunu burada da görmek sevindirici. Filtre listesi ping sorununu gündeme getirmen iyi olmuş.
    Docker container’ını gerçekten izole edebilmek için fork’u, frontend’de hardcode edilmiş 0.0.0.0 adresini kullanmayacak şekilde değiştirmeye çalışıyordum ama hayat araya girdi. Apple TV’de denedin mi?
  • Adguard da benzer bir şey üzerinde çalışıyor.
    https://github.com/AdguardTeam/urlfilter
  • Docker’laştırılmış fork denince bunun GUI’nin web GUI’ye dönüştüğü anlamına geldiğini anlamam fazla uzun sürdü.

• Bu yazı, sık sık gelen “hacker olmak için nasıl öğrenmeliyim?” sorusuna harika bir cevap niteliğinde.
  Herhangi bir exploit’in içine giren düşünce sürecini ve inatçı çalışmayı çok iyi gösteriyor.

• “WireGuard kullanalım — Intel AES-NI şifreleme komut seti var” diye bir bölüm var; bildiğim kadarıyla WireGuard AES kullanmıyor.
  Genel olarak yazar, TLS şifrelemesinin CPU gereksinimlerini biraz abartıyor ya da modern tek kart bilgisayarların performansını küçümsüyor gibi.
  Raspberry Pi’de HTTPS trafiğini çözüp yeniden şifrelemek için gereken CPU gereksinimlerinin çok aşıldığı açıklaması da bana tuhaf geldi. RPi 4’te TLS için ortadaki adam işlemi gerçekten mümkün değilse epey şaşırırım; tamamen yazılımsal RSA kullanılsa bile.
  Hâlâ kullanılan Android telefonlar arasında RPi 4’ten daha zayıf CPU’ya sahip cihazlar var ve onlar da TLS kullanıyor.

  • CPU gereksinimlerini hafife alıyor gibisin.
    Zayıf bir Android telefonun TLS trafiğini yalnızca 50Mb/s işleyebilmesi bile gerçek kullanımda büyük sorun olmayabilir. Çünkü yavaş telefonlar genelde yavaş ağlara bağlı olur.
    Buna karşılık evde gigabit internet varken, tüm bilgisayarlarla internetin arasına konmuş zayıf bir cihaz yüzünden 50Mb/s’te darboğaz oluşması büyük sorun olur.
    TLS’in CPU gereksinimleri hedef bant genişliğine çok ciddi biçimde bağlıdır. Daha yüksek bant genişliklerinde hızlandırıcılara offload etmek fiilen zorunlu hale bile gelebilir. El sıkışma maliyeti de göz ardı edilemez ve saniye başına bağlantı sayısını sınırlayabilir. Tek bir cihazda nadiren sorun olur ama tüm cihaz ağında daha büyük bir meseleye dönüşebilir.

• Harika yazı. Özel CA yüklemeye izin vermeyen cihazlarda ortadaki adam işlemi yapmanın yolunu bekliyordum.
  Yerel API sunmayıp verileri yalnızca bulut üzerinden gösteren bir IoT cihazım var; cihaz ile bulut arasındaki trafiği yakalamak istiyorum.
  Sonunda flash belleği dump edip CA’yı değiştirerek tekrar yüklemekten başka yol yok mu acaba?

  • Sertifikayı “hardcode” ettilerse buna sertifika sabitleme denir. Öyleyse trafiği çözebilmek için sertifikayı değiştirmeniz ya da kaldırmanız ve aynı sertifikayı ortadaki adam proxy’sine taşımanız gerekir.
    Donanım veya firmware işi yapmadan IoT cihazlarını araya almayı denemek için iyi bir yazı var:
    https://robertheaton.com/2019/11/21/how-to-man-in-the-middle...
  • Özel CA yüklemeye izin vermeyen cihazlarda ortadaki adam işlemi yapmanın yolunu aramak, sonuçta TLS’in amacına ters düşmek demek.
    Mümkünse, bir uygulama hatasına dayanıyorsunuz demektir.
    Açıkçası bugün kendi güvenilen sertifikanızı yükleyebildiğiniz bazı cihazların bile gelecekte bunu desteklemeye çok uzun süre devam etmeyeceğini düşünüyorum.

• YouTube’da ya da herhangi bir platformda reklamları engellemenin yeni yolları hep çıkıyor ama birkaç ay sonra değişip işe yaramaz hale geliyor.
  Bunun yerine reklamverenlere saldırmak nasıl olur? YouTube/Google yalnızca “tıklamaları” izliyormuş gibi görünüyor; gerçek satın alımları da izliyor mu?
  Teorik olarak yeterince çok sahte bot ve gerçek kullanıcı reklamlara tıklayıp hiçbir şey satın almazsa reklam bütçesini yakabilir. Zamanla pazarlama departmanı belirli bir platformda tıklama sayısının rekor düzeyde olduğunu ama dönüşüm oranının tıklama ya da gösterimlere kıyasla çok düşük kaldığını görür ve sonunda o platformdan çekilebilir.

  • Nauseum’un Chrome Store’da engellendiğine bakılırsa epey etkili gibi.

• Şaşırtıcı bir yazı. mitm yaması adımını görür görmez bunun özel bir yazı olacağını düşündüm; gerçekten de öyleydi.

• İçindekilerdeki “Yeni hedef: YouTube’u, İtalya’da yaşayan 70 yaşında bir erkek olduğuma inandıralım” kısmı etkileyiciydi.
  Eskiden bir şekilde reklam hedeflemesi, sevgilim için 500 dolarlık yıkanabilir ipek pijama almak isteyen biri olduğuma inanmıştı.
  Reklamların kendisi harikaydı ama gösterim başına ne kadar ödüyorlardı acaba merak ediyorum.
  Apple TV’ye geçtikten sonra çoğunlukla bölgesel hedeflemesi yanlış yerel reklamlar çıkıyor. Ortalama olarak bu daha iyi gibi de geliyor.

• Bu, Protobuf’un bir “kusuru” değil. Baytları değiştirdiğinizde başka bir konumdaki alan olarak decode edilmesi tasarlandığı gibi çalışmasıdır.
  Protobuf zaten alan numarası ve uzunluk öneki tabanlı bir protokoldür; aktarım sırasında baytların değişmeyeceği yönünde makul bir varsayım yapar ve bütünlüğü okuyan tarafa bırakır.
  Kusur olsa bile bu Protobuf’un değil, iOS için YouTube uygulamasının kusuru olurdu; gerçekte kusur da olmadığı için buna “exploit” demek de zor. Belki YouTube iOS uygulamasının Protobuf alışverişinde dönen payload hash’ini kontrol etmemesinden söz ediliyorsa ayrı.
  Bu yazıdan sonra muhtemelen kontrol etmeye başlayacaklardır.

  • Yazarın ifadesi biraz tuhaf. “Kusur” yalnızca başlıkta geçiyor; metin ise sadece formatın nasıl çalıştığını açıklıyor.
    Kusur değil, tasarım gereği böyle çalışıyor.
    “Google’ın, C++ kaynak proto dosyası olmadan decode etme, değiştirme ve yeniden encode etmeyi hesaplama açısından pahalı hale getirdiği” kısmı da tuhaf. Optimize edilmemiş Python koduyla yapılırsa pahalı olabilir; ama C veya başka bir derlenen dille yazılırsa, proto kaynak dosyası olsun olmasın 1,8 MB’lık bir Protobuf’u taramak önemsiz bir iştir.
    Protobuf dosyalarını kaynak olmadan decode etmeyi zorlaştırmanın bir tasarım hedefi olduğunu sanmıyorum. Hedef buysa da oldukça kötü başarmışlar.
  • Protobuf’ta zorunlu alanların nasıl çalıştığını bilmiyorum, ancak saldırıyı hafifletmek için Google’ın YouTube istemcisi ilgili alanı zorunlu alan olarak ele alabilir ve alan yoksa ya da varsayılan değerdeyse hizmeti reddedecek şekilde yapabilir.
  • Yazının tarihi Ocak 2022. Blog yazısından sonra protokolü güçlendirmek isteselerdi, büyük olasılıkla bunu zaten yapmışlardır.