Memblokir iklan YouTube di Apple TV dengan dekripsi dan modifikasi Protobuf

 (ericdraken.com)
2 poin oleh GN⁺ 2023-08-28 | 2 komentar | Bagikan ke WhatsApp
  • Untuk memblokir iklan YouTube di Apple TV dan iPhone pada level jaringan, dilakukan berbagai eksperimen mulai dari pfSense, pemblokiran DNS, routing VPN, Squid, MITMProxy, hingga modifikasi respons Protobuf
  • Karena iklan YouTube dikirim dari domain yang sama dengan video biasa, pemblokiran DNS saja seperti dengan Pi-hole atau pfBlockerNG sulit memisahkan konten dan iklan secara stabil
  • Setelah trafik TLS didekripsi dengan MITMProxy, field iklan JSON pada YouTube web dihapus, sementara pada aplikasi iOS struktur iklan di dalam respons application/x-protobuf dicari lalu dimodifikasi secara langsung
  • Decoding Protobuf penuh berbasis Python memerlukan sekitar 23 detik pada router pfSense, tetapi dengan metode pemindaian linear di sekitar /pagead/, payload 1.8MiB pun bisa diproses secara real time
  • Metode ini memerlukan instalasi CA tepercaya dan CPU yang cukup bertenaga; pemblokiran iklan pada perangkat Apple yang terhubung ke jaringan berhasil dilakukan, tetapi pada akhirnya opsi berlangganan YouTube Premium pun mulai dipertimbangkan

Router pfSense dan pemisahan jaringan

  • Tujuannya adalah membuat router berbasis FreeBSD·pfSense untuk memblokir iklan YouTube pre-roll, mid-roll, end-roll di Apple TV dan iPhone pada seluruh jaringan
  • Perangkat keras yang digunakan adalah mini PC J4125 dengan set instruksi AES-NI, RAM DDR4, SSD mSATA, dan USB drive untuk instalasi pfSense
    • Contoh konfigurasinya menggunakan RAM 32GiB dan SSD mSATA 128GB
    • Ruang penyimpanan 128GB dianggap berguna untuk log, mengurangi keausan SSD, packet capture, dan ruang edge cache
  • Setelah pfSense diinstal, LAN 1 diatur ke IP statis 192.168.1.3 di luar rentang DHCP yang ada, lalu portal web admin diakses dengan akun admin/pfsense
  • Setelah memeriksa indikator AES-NI CPU Crypto: Yes (inactive) di dashboard pfSense, AES-NI diaktifkan secara manual dari System › Advanced › Miscellaneous
  • Dengan memanfaatkan RAM 32GiB, RAM disk berukuran besar dialokasikan ke /var dan /tmp, serta backup RAM-disk diatur berjalan setiap jam

Pemblokiran DNS dan pemisahan jaringan fisik

  • Alih-alih memakai Pi-hole yang lama, dipasang paket pfSense pfBlockerNG-devel untuk memblokir iklan, konten berbahaya, dan melakukan pemblokiran geografis
    • Ukuran instalasinya menambah sekitar 20MiB
    • Jika layanan pfb_dnsbl tidak berjalan atau muncul [ Missing CRON task ], disarankan mencoba menghapus file kosong /var/run/booting
  • Tiga port Gigabit pada router pfSense digunakan untuk pemisahan LAN fisik, bukan VLAN
    • Perangkat yang sering phoning-home seperti Alexa dan Apple TV ditempatkan di LAN perangkat keras terpisah
    • LAN penting dipisahkan dari perangkat pintar dan perangkat Wi‑Fi untuk melindungi perangkat yang digunakan untuk perbankan, trading saham, dan crypto wallet
  • Jaringan untuk perangkat pintar dipisahkan ke 172.31.1.0/24, sedangkan LAN yang lebih tepercaya tetap berada di 192.168/16
    • Jika tidak ada route antarjaringan, dampak dari aturan iptables yang salah konfigurasi juga dianggap bisa sedikit berkurang
    • DHCP resolver pada NIC fisik harus diaktifkan agar perangkat jaringan baru bisa memperoleh alamat
  • AC1200 Archer C5 dibuang karena tidak memiliki mode AP, bermasalah untuk akses jarak jauh, masih memakai stock firmware lama, dan chipset Broadcom-nya kurang didukung oleh OpenWRT/DD-WRT/Tomato
  • Setelah itu, Nighthawk R7000 digunakan sebagai AP untuk Apple/Amazon/TV dan AP untuk Trusted Wireless Network
    • Pada Trusted Wireless Network, diputuskan untuk mematikan 2.4GHz dan hanya memakai 5GHz
    • 5GHz dianggap lebih mudah terhalang dinding dan beton, sehingga lebih baik untuk menghindari snooping dari jarak menengah

Memaksa semua DNS melalui pfSense

  • Ditambahkan aturan NAT agar semua klien di belakang pfSense menggunakan server Unbound DNS lokal
    • Tujuannya agar aplikasi dan home assistant tidak bisa menghindar lewat server DNS sendiri atau DNS yang di-hardcode
    • Agar pfBlockerNG bisa ikut campur dalam permintaan DNS, DNS over TLS perlu diblokir
  • Aturan NAT awalnya dibuat pada tiap antarmuka selain WAN, lalu disederhanakan dengan alias firewall Non_WAN
    • Pada IPv4 dan IPv6, kueri DNS lokal di port 53 diarahkan ulang ke localhost
    • NAT reflection harus dinonaktifkan agar server DNS lokal tidak bisa diakses dari internet eksternal
  • Pada Services › DNS Resolver › Display Custom Options ditambahkan server: log-queries: yes untuk mencatat permintaan DNS yang dicegat
  • Dari log DNS terlihat Windows mencoba mengakses Google Tag Manager, dan permintaan tersebut diblackhole ke IP yang tidak ada, 10.10.10.1

Mencoba menghindari penargetan iklan YouTube dengan VPN

  • Karena iklan YouTube datang dari domain yang sama dengan video biasa, pemblokir domain seperti pfBlockerNG atau Pi-hole sulit memilih hanya iklannya
    • Memblokir googleadservices.com dianggap baru bermakna setelah video iklan diputar dan iklan itu diklik
    • Di browser, uBlock Origin bisa ikut campur pada JavaScript, tetapi pada aplikasi YouTube iPhone pembatasan iklan dianggap sulit tanpa jailbreak
  • Alih-alih memblokir iklan secara langsung, dilakukan eksperimen agar algoritme iklan YouTube menilai pengguna sebagai target iklan yang kurang menarik
    • Idenya adalah mengirim trafik Apple TV melalui VPN dan memakai endpoint VPN di wilayah dengan sedikit penonton YouTube
    • Tujuannya adalah membuat pengguna terlihat seperti pria 70 tahun yang tinggal di Italia
  • WireGuard dikonfigurasi di pfSense, dengan private key NordLynx/WireGuard diambil dari Linux VM lalu diterapkan
    • Saat memasukkan alamat tunnel, jika diisi 1.0.0.0 dan subnet mask 0, hasil di UI akan tampil sebagai 0.0.0.0/0
  • Ketika seluruh trafik Apple TV dilewatkan melalui VPN, YouTube tampil dalam bahasa Italia dan jumlah iklan berkurang, tetapi Netflix dan Amazon Prime mengalami masalah
    • Tampak seperti file CSS atau font diblokir dan thumbnail gagal dimuat
    • Diperingatkan bahwa Netflix dan Prime cukup ketat dalam geofencing terhadap penyedia VPN
  • Setelah itu, dicoba merutekan hanya FQDN terkait YouTube melalui VPN, dengan kandidat seperti www.youtube.com, youtube.com, googlevideo.com, accounts.google.com, googleapis.com, gstatic.com
    • Setelah konfigurasi ini, YouTube menganggap pengguna berada di Milan, sementara Netflix dan Prime Video menganggapnya berada di Kanada
    • Iklan menjadi jarang muncul, dan iklan yang tetap muncul pun berbahasa Italia

Masalah DNS race condition dan domain wildcard

  • Sehari kemudian ditemukan DNS race condition di mana hostname alias pfSense dan cache DNS klien melihat kumpulan IP YouTube yang berbeda
    • Interval resolve default hostname alias pfSense adalah 300 detik
    • TTL DNS YouTube teramati sebesar 1.440 detik
  • Jika IP yang di-resolve Alias Daemon untuk FQDN tidak cocok dengan IP yang diterima Apple TV kemudian, lalu lintas bisa melewatkan tunnel VPN
    • Mitigasinya adalah membuat pfSense mengabaikan TTL target dan menyimpan cache entri alias lebih lama
  • Subdomain varian googlevideo.com memerlukan routing wildcard, tetapi aturan NAT dan firewall bekerja berbasis IP dan tidak bisa langsung menangani hostname wildcard
  • Sebuah PoC ditulis menggunakan modul Python Unbound dan pfSense REST API untuk menangkap IP respons DNS dan menambahkannya secara dinamis ke alias VPN_wildcards
    • TTL VPN_wildcards diatur 1 jam, kapasitasnya 500
    • Record A diparse sebagai ipaddress.IPv4Address, record AAAA sebagai ipaddress.IPv6Address
  • Saat diperiksa pada pagi hari, Unbound DNS Resolver berada dalam kondisi segfault, dan karena setiap penambahan IP memerlukan reload rule pfSense, pfSense menjadi sangat lambat

Mendekripsi HTTPS dengan Squid dan MITMProxy

  • Tujuan baru adalah memasang proxy mirip Squid dan menambahkan sertifikat CA palsu tetapi tepercaya ke perangkat untuk melakukan dekripsi trafik TLS
  • Squid dipasang sebagai paket pfSense dan bahkan lulus smoke test SSL Filtering, tetapi kemudian ditinggalkan
    • Performanya sangat lambat
    • Pengaturan ACL merepotkan
    • Ada masalah terkait https://http/*
    • Pembaruan daftar filter URL SquidGuard memakan waktu sangat lama
    • UI Squid dianggap kurang memadai
  • Setelah itu dipilih MITMProxy
    • Ada scripting Python dan UI, serta dianggap bisa diperluas agar cocok untuk pemblokiran iklan YouTube
    • Tarball Linux mitmproxy 7.0.4 tidak bisa dijalankan di FreeBSD karena ELF interpreter /lib64/ld-linux-x86-64.so.2 not found dan library yang hilang
  • MITMProxy dipasang di lingkungan FreeBSD jail milik pfSense dengan pkg install mitmproxy
    • Paket yang dipasang berjumlah 50, ruang tambahan 206MiB, ukuran unduhan 33MiB
    • Saat mitmproxy dijalankan di dalam jail, UI terbuka
  • Untuk eksperimen MITMProxy, virtual IP 127.0.1.1 ditempelkan ke localhost di pfSense, lalu aturan NAT meneruskan [Private IPs]:8080 ke 127.0.1.1:8080
    • Ketika proxy laptop korban diatur ke 192.168.20.1:8080, permintaan browser muncul di log UI MITMProxy
  • File PEM CA MITMProxy adalah ~/.mitmproxy/mitmproxy-ca-cert.pem
    • cert.pem disajikan lewat server web Python 3
    • MITMProxy juga menyediakan sertifikat CA yang sama di mitm.it
    • Sertifikat ditambahkan ke laptop bersih dan iPhone

Pengoperasian MITMProxy dan penanganan certificate pinning

  • Di router, mitmproxy menggunakan banyak CPU bahkan saat idle, dan diduga penyebabnya adalah pembuatan sertifikat TLS secara langsung untuk setiap permintaan serta logging UI yang berlebihan
  • mitmdump dianggap menurunkan beban CPU karena menghilangkan UI dan logging ekstrem
    • Saat dijalankan, digunakan --anticomp, --mode regular, --listen-port 8080, --listen-host 127.0.1.1, dan lain-lain
  • Certificate Pinning adalah teknik di mana server atau klien sudah mengetahui fingerprint sertifikat yang diharapkan, sehingga pemalsuan sertifikat oleh MITMProxy tidak akan berhasil
    • Sebagai solusi, --ignore-hosts digunakan agar host seperti apple.com:443 dan icloud.com:443 melewati proxy
  • Dalam Transparent Proxy Mode, --allowed-hosts dibuat bekerja lebih baik berdasarkan SNI dengan mem-patch next_layer.py milik MITMProxy 7.0.4
    • Sebelumnya, dalam banyak kasus hanya IP server yang dianggap digunakan untuk pencocokan
    • Patch tersebut menambahkan server.sni sebagai kandidat hostname selain server.address[0]
  • Setelah patch, sebagian host dapat dicegat secara stabil dan sisanya bisa dibiarkan lewat

Menghapus iklan JSON di YouTube web

  • Dalam smoke test MITMProxy, URL iklan dan pelacakan YouTube diblokir dengan skrip kecil
    • Di youtube.com, yang diblokir meliputi /pagead/, /log_event?, /stats/ads, /stats/qoe?, /ptracking?, /generate_204, el=adunit, adformat=, /activeview?, dan lainnya
    • Di google.com dan google.ca, /pagead/ diblokir
  • Pada pengujian awal, permintaan yang menjadi target pemblokiran memang benar-benar terblokir juga di panel Network DevTools
    • Entri (failed) berasal dari skrip
    • Kegagalan 502 diduga merupakan hasil pfBlockerNG yang menangani permintaan dengan black-hole
    • HTTP/2 dinonaktifkan agar permintaan lanjutan pada kanal yang sama tidak ikut lewat
  • Pemblokiran URL sederhana saja tidak sepenuhnya menghilangkan iklan, sehingga sambil melihat HTML·JavaScript YouTube dan filter uBlock Origin, ditelusuri kemungkinan bahwa informasi iklan berada di body respons JSON
  • Dalam respons JSON yang ditangkap MITMProxy, informasi iklan dan pelacakan terkonfirmasi ada di struktur playerAds dan playbackTracking
    • playerAds mencakup playerLegacyDesktopWatchAdsRenderer, playerAdParams, gutParams.tag, showCompanion, showInstream, useGut, dan lain-lain
    • playbackTracking mencakup videostatsPlaybackUrl, ptrackingUrl, qoeUrl, atrUrl, dan lain-lain
    • youtubeRemarketingUrl berbentuk www.youtube.com/pagead/viewthroughconversion/...
  • Di YouTube web, menghapus informasi iklan dari payload JSON memungkinkan iklan web dihilangkan melalui router

YouTube iOS dan analisis Protobuf

  • Aplikasi YouTube iOS menggunakan data dalam bentuk Protocol Buffer (Protobuf) alih-alih JSON pada panggilan API yang mirip dengan versi web
    • Dalam Protobuf, key berupa angka dan dapat berubah, sehingga sulit menemukan bagian iklan dengan pendekatan bergaya JSONPath
    • Di payload terlihat string iklan seperti “Telus”, “Samsung TV”, “Boxing Week”, “Buy now”
  • Trafik jaringan YouTube iOS berbeda dari trafik web
    • Pada versi web, kandidat iklan sampai batas tertentu dapat diperkirakan dari parameter range atau clen pada chunk video
    • Protokol iOS tidak menggunakan parameter query range atau header Range, melainkan counter seperti &nr=2, &nr=3
  • Saat mendekode respons Protobuf untuk analisis offline, ditemukan item seperti has_unlimited_entitlement: False, has_premium_lite_entitlement: False
    • Mengubah nilai ini terasa seperti “cheating”, sehingga pendekatan kembali ke heuristic
  • Eksperimen pemblokiran URL iklan menyebabkan infinite loop, error UI, dan crash pada aplikasi iOS
    • 200 dengan body kosong, 404, 503, response body yang terpotong, dan perlakuan sebagian video iklan sebagai null membuat aplikasi melambat atau crash dalam keadaan rusak
    • Endpoint pelaporan error /error_204/ menunjukkan “dev assertion failed” dan ikut diblokir
  • Iklan tampaknya didaftarkan ke slot di dalam video tertentu
    • Jenis slot mencakup pre-roll, mid-roll, end-roll, full-page, dan ad pod
    • Jika hanya URL iklan yang diblokir, akan muncul error semacam “iklan yang tidak ada memesan slot”, lalu UI masuk ke kondisi panic

Masalah performa Protobuf dan blackboxprotobuf

  • Mendekode raw Protobuf sekitar 500KiB menjadi teks yang dapat dibaca manusia hanya dengan Python sangat lambat
    • Pada desktop CPU i7-6700, waktunya sekitar 2,06~2,11 detik
    • Pada router pfSense, waktunya sekitar 22,8~24,2 detik
  • C++ protoc --decode_raw jauh lebih cepat
    • Pada desktop CPU i7-6700, waktunya sekitar 0,017~0,022 detik
    • Pada router pfSense, sekitar 0,12~0,14 detik
  • Karena Python tidak mendukung raw decoding, dipilih cara berkomunikasi langsung dengan binary C++ protoc melalui subprocess.Popen
  • blackboxprotobuf untuk Burp Suite dapat mendekode raw Protobuf wire message, menyuntikkan nilai, lalu melakukan re-encode
    • Disarankan memakai versi asli Burp Suite, bukan fork PyPI
    • Beberapa fork dapat menyebabkan stack overflow karena deep recursion
    • Jika os.environ["PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION"] = "cpp" disetel sebelum import protobuf, maka implementasi C++ libprotobuf.so akan digunakan bila tersedia
  • protobuf_to_json(data) milik blackboxprotobuf dapat membuat schema .proto best-guess, tetapi hasilnya sangat besar, sangat dalam nested-nya, dan tidak sempurna
    • Dump schema Python panjangnya lebih dari sekitar 250.000 karakter
    • Ini dinilai cukup untuk mengekstrak detail iklan

Menonaktifkan bagian iklan dengan perubahan 1 byte

  • Protobuf Wire Format dapat berubah encoding-nya saat di-decode/edit/re-encode tanpa schema asli
    • Penyebabnya disebut mencakup penggunaan ZigZag encoding, ketidakmampuan menentukan tipe numerik, dan sifat non-deterministik urutan field object
  • Solusinya adalah memanfaatkan backward compatibility Protobuf untuk membuat bagian iklan terlihat seperti field yang tidak dikenal
    • Ini memanfaatkan perilaku software lama yang mengabaikan field tak dikenal saat membaca field baru
    • Dengan mengubah 1 byte di titik kritis agar section yang deeply nested tampak seperti milik versi schema masa depan, Protobuf akan mengabaikannya
  • Target field key 49399797 harus ditemukan dengan varint tag scanning, bukan pencarian string biasa
    • Wire type-nya 2, yang berarti nested string/message length-delimited
    • Target tag dihitung sebagai AA FF B8 BC 01
    • Setelah 3 bit wire type di-shift out, field key 49399797 dipulihkan
  • Penelusuran aktual dilakukan dengan lebih dulu mencari signature URL iklan seperti /pagead/ di raw byte Protobuf, lalu bergerak mundur di sekitarnya untuk menemukan target field tag dan field key
    • Target intercept contoh adalah POST youtubei.googleapis.com:443/youtubei/v1/browse?key=...
    • Responsnya adalah 200, application/x-protobuf, 1.87m
    • Pada log contoh, 49399797 ditemukan di posisi 4465, dan 50195462 di posisi 4477
  • Dalam smoke test O(n), penghapusan iklan pada data Protobuf 1,8MiB bekerja dengan satu kali scan tanpa memori tambahan
    • Target ditemukan pada byte ke-30.593
    • Backtracking sekitar 600 byte dilakukan untuk menemukan field key yang akan diubah
    • Tidak perlu lagi memblokir URL yang memuat *.googleadservices.com atau /pagead/, karena request tersebut sejak awal tidak dibuat

Struktur add-on MITMProxy

  • Skrip PoC disimpan sebagai youtube.py dan dijalankan dengan mitmdump --listen-port 8080 --listen-host 127.0.0.1 -s "youtube.py"
    • Prasyarat FreeBSD yang disebutkan adalah pkg install protobuf, pkg install py38-pip, pip install jsonpath-ng
  • Skrip terdiri dari kelas Logger, trunc, KilledError, JSONPathReplacement, ProtobufDebugParser, dan YouTubeAdBlocker
  • Regex host target intersepsi YouTubeAdBlocker adalah \.youtube\.com|google\.(com|ca)|googleapis\.com|googleadservices\.com|googlevideo\.com
    • String pencarian URL iklan Protobuf adalah b"/pagead/"
    • Batas pencarian adalah 80_000
    • Tag field target adalah 50195462
  • Rule pemblokiran permintaan memeriksa string URL parsial per host lalu mematikan flow
    • Untuk target youtube.com, ini mencakup pagead/, log_event?, stats/ads, stats/qoe?, ptracking?, generate_204, error_204, adformat=, activeview?, _ad_, ai?, sw.js, dan lainnya
    • Pada sw.js ada komentar yang menyatakan service workers ditolak
  • Pada respons JSON, beberapa replacement JSONPath diterapkan
    • $.responseContext.serviceTrackingParams[*].params[?(@.key == 'yt_ad')].value diubah menjadi "0"
    • $..adPlacements diubah menjadi []
    • $..adPlacementRenderer, $..adPlacementConfig, $..playerAdParams, $..gutParams diubah menjadi {}
    • $..adVideoId diubah menjadi string kosong
    • $..showCompanion, $..showInstream, $..useGut diubah menjadi False
  • Pada respons Protobuf, saat content type berisi protobuf, body dijadikan bytearray dan /pagead/ dicari dalam 80.000 byte pertama
    • TagBytes(self.target_field_tag, WIRETYPE_LENGTH_DELIMITED) digunakan untuk membuat byte tag target, lalu dibuat byte baru dari target_field_tag - 1
    • Pencarian mundur dilakukan hingga tepat sebelum posisi /pagead/ untuk menemukan byte tag target
    • Jika ditemukan, byte tersebut ditimpa dengan byte baru dan body respons diganti dengan flow.response.set_content(bytes(body))
  • Dalam komentar, PoC ini disebut memblokir 90% iklan
    • Di section lain juga ada field key lain, dan bisa jadi ada beberapa section iklan yang perlu dirusak

Cakupan penerapan dan keterbatasan

  • Teknik ini dirangkum sebagai teknik yang sangat terspesialisasi untuk memblokir iklan YouTube di perangkat Apple atau traffic tracker seperti Instagram, WhatsApp, dan Facebook
  • Kebutuhan CPU untuk mendekripsi/mengenkripsi ulang traffic HTTPS dinilai jauh melampaui kemampuan Raspberry Pi
  • Setelah Apple TV di-jailbreak lalu ditambahkan root certificate pfSense, gateway pfSense dinilai dapat mendekripsi traffic Apple TV dan memblokirnya dengan memeriksa hostname iklan di header request
    • Namun ini tetap tidak berlaku untuk iklan di iPhone, jailbreak iPhone lebih sulit, dan aplikasi perbankan bisa mendeteksinya lalu tidak berfungsi
    • Jailbreak itu sendiri dianggap terlalu ekstrem
  • Jika fake trusted CA memungkinkan, paket TLS dapat didekripsi menjadi plaintext dan pemblokiran URL bisa diterapkan
    • Contoh URL yang diblokir adalah path YouTube /pagead/viewthroughconversion/... dan /pagead/conversion/...
  • Pada akhirnya, penulis menyiapkan router hardware dari nol, membagi LAN menjadi zona tepercaya dan tidak tepercaya, menambahkan pemblokiran iklan DNS dan proxy MITM transparan, lalu memblokir iklan YouTube dengan performa baik pada perangkat Apple yang terhubung ke jaringan

YouTube Premium dan dukungan untuk kreator

  • Setelah memblokir iklan YouTube selama beberapa bulan, penulis mulai membayar YouTube Premium karena ingin mendukung kreator konten
    • Ditambahkan catatan, “bisa dilakukan bukan berarti harus dilakukan”
  • Harga YouTube Premium disebut naik dari CAD $9.99/mo menjadi $11.99/mo, sekitar $13.43/mo termasuk pajak
  • Dalam eksperimen menonton iklan, penulis menonton YouTube sesekali selama sehari dengan laptop bersih dan mode penjelajahan privat
    • Berdasarkan catatan, video yang ditonton ada 10
    • Terpapar 8 iklan, dan hanya 2 di antaranya yang bisa dilewati
  • Jika CPV diasumsikan USD $0.15, biaya iklan per hari menjadi $1.20, dan ekstrapolasi per bulan sekitar USD $36/mo
  • Dalam perhitungan lain yang memakai angka Statista, pengiklan AS pada 2019 menghabiskan $15.1 billion di YouTube dan penduduk AS menonton 916 billion video, sehingga rata-rata per tayangan adalah USD $0.0165
    • Jika perhitungan ini diterapkan, biaya per hari sekitar USD $0.13, dan ekstrapolasi per bulan sekitar USD $3.96
    • Nilai ini dinilai tidak mendekati Premium di kisaran USD $10
  • Jika ada klaim DMCA, pendapatan iklan bisa masuk ke pengaju klaim seperti Sony atau Viacom, bukan ke kreator
    • Karena itu, tanpa disadari penonton mungkin sama sekali tidak memberi apa pun ke channel favoritnya
    • Penulis menilai tidak mengherankan jika banyak kreator berpindah ke Patreon

Bacaan terkait

2 komentar

 
xguru 2023-08-29

Tulisan aslinya sangat panjang. Prosesnya memang menarik, tetapi poin utamanya adalah bahkan penulisnya sendiri pada akhirnya tetap berlangganan YouTube Premium untuk digunakan.
 
GN⁺ 2023-08-28
Komentar Hacker News

  • Secara keseluruhan ini hack yang keren, tetapi beberapa ungkapan tentang Protobuf terasa agak aneh
    Yang dilakukan adalah sengaja merusak tag suatu field di Protobuf, dan mengabaikan nomor tag yang tidak dikenali bukanlah “cacat”, melainkan desain inti untuk ekstensibilitas
    1,87MiB juga bukan ukuran yang terlalu besar, dan sepertinya pesan seperti ini tidak terus-menerus di-streaming, jadi penjelasan bahwa ini menjadi hambatan performa juga kurang meyakinkan
    Encoding Protobuf tidak dirancang untuk membuat biaya decoding mahal, justru dirancang agar dapat di-decode secara efisien, dan bahkan tanpa skema .proto asli pun bisa di-decode langsung dengan UnknownFieldSet
    Cara yang lebih baik tampaknya adalah memakai skema .proto palsu yang hanya berisi satu field yang ingin dihapus. Metode memindai string lebih rentan salah karena urutan byte yang sama bisa saja muncul secara kebetulan di data lain
    Jika urutan field berubah, hasil byte setelah re-encoding memang bisa berbeda, tetapi penerima harus memperlakukannya sebagai pesan yang sama, dan kecil kemungkinan aplikasi YouTube mendeteksi perubahan urutan field
    Dari sudut pandang saya yang pernah mengerjakan Protobuf dulu, sepertinya penulis salah memahami bagian ini

    • Analisis yang bagus, tetapi saya agak sulit setuju dengan pernyataan bahwa 1,87MB itu kecil
      Saya menghabiskan sebagian besar hidup di daerah pedesaan, dan kalau bukan Wi-Fi saya sendiri, ukuran sebesar ini pun dalam praktiknya adalah unduhan besar. Di mobile mungkin ada cara mengakalinya, tetapi Wi-Fi pedesaan masih kewalahan dengan struktur Web 2.0 dan biasanya dipakai pada kecepatan 2–4G
      Di wilayah perkotaan yang punya populasi untuk menopang infrastrukturnya, 1,87MB umumnya sudah menjadi file kecil, tetapi sekitar pukul 6 sore ketika semua orang yang memakai koneksi kabel sedang streaming bisa menjadi pengecualian
    • Sedikit promosi terkait without the C++ source proto files: saya membuat proyek bernama protodump yang menghasilkan file sumber .proto dari binary
      Proyek ini meregenerasi definisi pesan dan field, termasuk nama aslinya, dan Anda hanya perlu mengambil binary dari kotak Apple TV
      https://github.com/arkadiyt/protodump
    • “Pernah mengerjakan Protobuf dulu” adalah ungkapan yang sangat merendah. Untuk yang belum tahu, Kenton adalah orang yang membentuk Protobuf menjadi seperti sekarang
      Protobuf adalah teknologi yang pertama kali memperkenalkan saya pada IDL, dan saat itu terasa seperti ide ajaib. Saya makin terkejut karena menemukan Protobuf setelah sebelumnya membuat IDL sendiri yang asal-asalan
    • Saat membaca tulisan ini, saya juga merasa bingung dengan cara yang mirip. Prinsip desain Protobuf bukan rahasia, dan semuanya didokumentasikan dengan jelas
    • Bagian paling rumit saat men-decode Protobuf tanpa skema adalah bahwa pesan tertanam dan string memakai tipe tag yang sama, tetapi tetap cukup mudah ditangani
      Jika tidak ingin menarik seluruh dependensi protoc, Anda bisa menulis decoder Protobuf sederhana beberapa ratus baris sendiri: https://github.com/kubernetes/test-infra/blob/master/guberna... https://github.com/kubernetes/test-infra/blob/master/guberna...

  • Sejak menemukan The Proxomitron lebih dari 20 tahun lalu, saya sudah memproses trafik lewat proxy man-in-the-middle untuk menghapus iklan dan menulis ulang halaman dengan hal-hal seperti CSS pengguna
    Layanan seperti CloudFlare cenderung mengklasifikasikan saya sebagai “bot”, tetapi itu pun ada cara untuk mengakalinya meski tidak sederhana. Kasus seperti ini juga menunjukkan mengapa remote attestation berbahaya bagi kebebasan pengguna

    • Saya mencari The Proxomitron dan sepertinya pengembangannya berakhir pada 2004; akan menarik kalau ada ringkasan yang memahami lanskap saat ini
      Tampaknya ada beberapa proyek “penerus”, dan saya juga penasaran apakah ini khusus Windows. Saya sempat mencari secara ringan proxy sederhana yang bisa menyisipkan tautan lokal ke konten jarak jauh
    • Pemblokiran iklan tingkat jaringan seperti Privoxy atau pi-hole punya terlalu banyak kekurangan, misalnya tidak bisa menangani iklan inline
      Saat ini pi-hole yang dulu berjalan di Pi 4 saya pun sudah saya cabut. Saya menghabiskan berjam-jam agar bisa bekerja dengan baik bersama berbagai layanan, tetapi akhirnya menyerah, dan itu tidak sepadan dengan waktu untuk jaringan rumah
      Yang benar-benar bekerja dengan baik adalah pemblokir iklan berbasis browser dan patcher aplikasi seperti ReVanced. Seiring tabungan bertambah, untuk kasus yang tidak bisa diselesaikan oleh keduanya seperti YouTube Premium, Hulu, Netflix, dan Max, saya makin condong membayar layanan bebas iklan saja
    • Karena karyawan Cloudflare diketahui diam-diam membaca di sini, saya penasaran. Klasifikasi sebagai bot seperti ini dianggap false positive, atau dianggap berjalan sesuai niat?
    • Saya hampir 20 tahun tidak memikirkan Proxomitron, jadi penasaran apakah masih ada yang memakainya
      Saya tidak pernah memakainya untuk tujuan yang disebutkan di sini, tetapi dulu sangat bagus sebagai proxy di balik firewall perusahaan. Waktu itu firewall menuntut informasi login untuk koneksi keluar, sehingga banyak program tidak bisa mengakses internet
    • Mungkin caranya harus memasang sertifikat CA baru di perangkat, benar begitu?

  • Privaxy yang dipaketkan dengan Docker jadi teringat. Ini adalah proxy man-in-the-middle yang kompatibel dengan daftar blokir UBlock Origin.
    Mengejutkan melihat betapa banyaknya iklan dan skrip pelacakan di produk pintar, terutama TV. Dari pengujian sejauh ini, trafik yang tidak perlu melebihi 40%, dan eksperimen mengupas iklan dari aplikasi smart TV cukup menarik.
    https://github.com/deetungsten/webui-privaxy adalah fork https://github.com/Barre/privaxy yang dibuat versi Docker-nya.

    • Bagaimana cara membuat TV mempercayai sertifikat yang ditandatangani sendiri?
    • Senang melihatnya disebut di sini juga. Bagus karena mengangkat masalah ping daftar filter.
      Saya sempat ingin mengubah fork itu agar frontend tidak memakai alamat 0.0.0.0 yang di-hardcode, supaya container Docker benar-benar bisa diisolasi, tapi hidup keburu menyela. Sudah mencobanya di Apple TV?
    • Adguard juga sedang mengerjakan hal serupa.
      https://github.com/AdguardTeam/urlfilter
    • Butuh waktu terlalu lama bagi saya untuk memahami bahwa yang dimaksud fork versi Docker adalah GUI-nya diganti menjadi GUI web.

  • Tulisan ini menjadi jawaban yang sangat bagus untuk pertanyaan yang sering muncul, “bagaimana cara belajar menjadi hacker?”
    Eksploit apa pun selalu menunjukkan dengan baik proses berpikir dan kerja tekun yang ada di dalamnya.

  • Ada bagian “pakai WireGuard — ada set instruksi enkripsi Intel AES-NI”, tetapi setahu saya WireGuard tidak memakai AES.
    Secara umum, penulis tampaknya agak melebih-lebihkan kebutuhan CPU untuk enkripsi TLS, atau meremehkan performa komputer single-board modern.
    Penjelasan bahwa kebutuhan CPU untuk mendekripsi dan mengenkripsi ulang trafik HTTPS di Raspberry Pi akan jauh terlampaui juga terasa janggal. Kalau pemrosesan TLS man-in-the-middle benar-benar tidak memungkinkan di RPi 4, saya akan cukup terkejut, bahkan jika memakai RSA murni di software sekalipun.
    Di antara ponsel Android yang masih dipakai, ada juga yang CPU-nya lebih lemah daripada RPi 4, dan perangkat-perangkat itu tetap memakai TLS.

    • Sepertinya Anda meremehkan kebutuhan CPU.
      Jika ponsel Android yang lemah hanya bisa memproses trafik TLS 50Mb/s, itu mungkin bukan masalah besar dalam penggunaan nyata. Ponsel lambat biasanya terhubung ke jaringan yang lambat juga.
      Sebaliknya, jika Anda punya internet gigabit di rumah, lalu ada perangkat lemah di antara semua komputer dan internet yang menjadi bottleneck di 50Mb/s, itu menjadi masalah besar.
      Kebutuhan CPU TLS sangat bergantung pada target bandwidth. Pada bandwidth yang lebih tinggi, offloading ke akselerator bahkan praktis menjadi keharusan. Biaya handshake juga sulit diabaikan dan bisa membatasi jumlah koneksi per detik. Pada satu perangkat ini jarang menjadi masalah, tetapi pada jaringan perangkat secara keseluruhan bisa menjadi lebih besar.

  • Tulisan yang keren. Saya berharap ada cara melakukan man-in-the-middle pada perangkat yang tidak mengizinkan pemasangan CA kustom.
    Saya punya perangkat IoT yang tidak mengekspos API lokal dan hanya menampilkan data melalui cloud, dan saya ingin menangkap trafik antara perangkat dan cloud.
    Pada akhirnya, apakah tidak ada cara selain dump flash memory, mengganti CA, lalu mengunggahnya kembali?

    • Jika sertifikatnya “di-hardcode”, itu disebut certificate pinning. Kalau begitu, untuk mendekripsi trafik, sertifikatnya harus diganti atau dihapus, dan sertifikat yang sama harus dipindahkan ke proxy man-in-the-middle.
      Ada tulisan bagus yang bisa dicoba untuk mencegat perangkat IoT tanpa mengutak-atik hardware atau firmware:
      https://robertheaton.com/2019/11/21/how-to-man-in-the-middle...
    • Mencari cara melakukan man-in-the-middle pada perangkat yang tidak mengizinkan pemasangan CA kustom pada akhirnya berarti melawan tujuan TLS.
      Jika itu memungkinkan, berarti bergantung pada cacat implementasi.
      Sejujurnya, menurut saya beberapa perangkat yang sekarang masih memungkinkan pemasangan sertifikat tepercaya sendiri pun tidak akan lama lagi tetap seperti itu.

  • Metode baru untuk memblokir iklan di YouTube atau platform apa pun memang selalu muncul, tetapi beberapa bulan kemudian berubah dan menjadi tidak berguna.
    Bagaimana kalau sebagai gantinya menyerang pengiklan? YouTube/Google tampaknya hanya melacak “klik”, tetapi apakah mereka juga melacak pembelian nyata?
    Secara teori, jika cukup banyak bot palsu dan pengguna nyata mengklik iklan tetapi tidak membeli apa pun, anggaran iklan bisa dibakar habis. Seiring waktu, departemen pemasaran akan melihat bahwa di platform tertentu jumlah klik mencapai rekor tertinggi tetapi tingkat konversinya sangat rendah dibanding klik atau impresi, dan akhirnya bisa keluar dari platform itu.

    • Melihat Nauseum diblokir dari Chrome Store, tampaknya itu cukup efektif.

  • Tulisan yang luar biasa. Begitu melihat tahap patch mitm, saya merasa ini akan menjadi tulisan yang istimewa, dan memang benar.

  • Bagian daftar isi “Tujuan baru: membuat YouTube percaya bahwa saya pria 70 tahun yang tinggal di Italia” sangat berkesan.
    Dulu entah bagaimana penargetan iklan pernah dibuat percaya bahwa saya adalah orang yang ingin membeli piyama sutra yang bisa dicuci seharga 500 dolar untuk kekasih saya.
    Iklannya sendiri hebat, tetapi saya penasaran berapa yang mereka bayar per tayangan.
    Setelah beralih ke Apple TV, biasanya saya mendapat iklan lokal dengan penargetan wilayah yang salah. Rata-rata, mungkin itu justru lebih baik.

  • Ini bukan “cacat” pada Protobuf. Ketika byte diubah lalu didekode sebagai field di posisi lain, itu berfungsi sesuai rancangan
    Sejak awal Protobuf adalah protokol berbasis nomor field dan prefiks panjang, membuat asumsi wajar bahwa byte tidak berubah selama transmisi, dan menyerahkan integritas kepada pihak yang membaca
    Kalaupun itu disebut cacat, itu bukan cacat Protobuf melainkan cacat pada aplikasi YouTube untuk iOS; dan karena sebenarnya bukan cacat, sulit juga menyebutnya “eksploit”. Kecuali yang dimaksud adalah fakta bahwa dalam pertukaran Protobuf aplikasi YouTube iOS, hash payload yang dikembalikan tidak diperiksa
    Setelah tulisan ini, kemungkinan besar mereka akan mulai memeriksanya

    • Ungkapan penulisnya agak aneh. “Cacat” hanya muncul di judul, sedangkan isi tulisan hanya menjelaskan bagaimana formatnya bekerja
      Itu bukan cacat, melainkan bekerja sesuai desain
      Bagian yang mengatakan “Google membuat decoding, modifikasi, dan re-encoding mahal secara komputasi tanpa file proto sumber C++” juga aneh. Jika dilakukan dengan kode Python yang tidak dioptimalkan memang mahal, tetapi jika ditulis dalam C atau bahasa terkompilasi lain, memindai Protobuf 1,8 MB adalah hal sepele, ada atau tidak ada file sumber proto
      Sepertinya membuat file Protobuf sulit didekode tanpa sumber bukanlah tujuan desainnya. Jika itu tujuannya, hasilnya bisa dibilang cukup buruk
    • Saya tidak tahu bagaimana field wajib bekerja di Protobuf, tetapi untuk memitigasi serangan, klien YouTube milik Google bisa memperlakukan field tersebut sebagai field wajib, dan menolak layanan jika field itu tidak ada atau bernilai default
    • Tanggal tulisan ini Januari 2022. Jika mereka ingin memperkuat protokol setelah artikel blog itu, kemungkinan besar mereka sudah melakukannya