[REVERSE ENGINEERING] Bir Film Sitesinin İçinden Nasıl Geçtim? JS Deobfuscation, HLS Koruma Aşımı ve C# Otomasyonu ile DoodStream Macerası

ölmedim geri döndüm kaldığımız yerden devam
Süper Üye
Katılım
6 Eki 2019
Mesajlar
744
Çözümler
19
Tepki puanı
155
Ödüller
6
Sosyal
6 HİZMET YILI
Selamlar MemoryHackers ailesi,
Bugün size yaklaşık 1 yıldır arka planda yürüttüğüm, "Bu iş olmaz, çok korumalı" denilen sistemleri nasıl "bypass" ettiğimi ve bu süreçte nasıl bir pasif gelir sistemi kurduğumu anlatacağım. Olay sadece film izlemek değil; olay bir web sitesinin "Kara Kutusu"nu (Blackbox) açıp, içindeki hazineyi alıp, kendi sistemimize entegre etmek.

Hedefimizde popüler film sitelerinden biri vardı (İsim vermiyorum, reklam olmasın ama sektörün devlerinden). Sistemleri sağlamdı; Cloudflare, gizli oynatıcılar, şifreli linkler... Ama unuttukları bir şey vardı: Kod istemciye (Client-side) iniyorsa, o kod artık bizimdir.

İşte adım adım teknik analizim, karşılaştığım tuzaklar ve yazdığım C# botunun hikayesi



Bölüm 1: Keşif ve İlk Duvar (Obfuscation)



Her şey "Bu adamlar filmleri nereden çekiyor?" sorusuyla başladı. Tarayıcıda F12 (Geliştirici Araçları) ile siteye daldım. Klasik bir WordPress altyapısı vardı ama video oynatıcı ortada yoktu. Ne bir <iframe>, ne bir <video> etiketi...

Kaynak kodlarını (CTRL+U) incelediğimde şunu fark ettim: Site sahibi, video player kodlarını "Packer" yöntemiyle şifrelemişti. Karşımdaki kod şuna benziyordu:

JavaScript:
eval(function(p,a,c,k,e,d){...}("TPmUPJmUmTPmUmPTJUmTPJUmPPTUmPmTUm..."))

Bu, tarayıcının anlık olarak çözüp çalıştırdığı ama insan gözünün okuyamadığı bir JavaScript yığınıydı.

Çözüm: Burada "Brute Force"a gerek yoktu. Kodu aldım, basit bir JS Unpacker aracıyla "Deobfuscate" ettim. Ve Bingo! Şifrenin altından JW Player ayarları ve asıl video kaynağı çıktı.

Ama bir sorun vardı. Link .mp4 değildi. Şöyle bir şeydi:
Bağlantıları görmek için lütfen Giriş Yap



Bölüm 2: HLS Protokolü ve ".jpeg" Tuzağı




Bulduğum şey bir HLS (HTTP Live Streaming) yayınıydı. Yani film tek parça değil, binlerce küçük .ts dosyasına bölünmüştü.

"Kolay," dedim. "FFmpeg ile indiririm." CMD'yi açtım, klasik komutu yapıştırdım: ffmpeg -i "link.m3u8" -c copy film.mp4

Ve Bam! Hata: [hls @ ...] URL .../gomplayer-1.jpeg is not in allowed_segment_extensions
Analiz: Adamlar buraya mükemmel bir tuzak kurmuş. Filmin o binlerce küçük parçasının uzantısını .ts (Transport Stream) yapmak yerine .jpeg (Resim dosyası) yapmışlar. FFmpeg, "Kardeşim ben video birleştireceğim, sen bana resim veriyorsun, ben bunu yemem" diyip işlemi durduruyordu. Ayrıca sunucu "Referer" kontrolü yapıyordu, yani isteğin kendi sitelerinden gelmediğini anlayıp bağlantıyı kesiyordu.



Bölüm 3: HLS İsviçre Çakısı (N_m3u8DL-RE)




FFmpeg ile uğraşmak yerine, bu tür "Header" ve "Uzantı" manipülasyonları için özel yazılmış N_m3u8DL-RE aracını keşfettim.

Bu araca şu emri verdim: "Dosya uzantısı ne olursa olsun indir, ayrıca kimliğimi (User-Agent) ve geldiğim yeri (Referer) şu siteymiş gibi göster."

Kullandığım o sihirli PowerShell komutu:
PowerShell:
.\N_m3u8DL-RE.exe "HEDEF_M3U8_LINKI" --save-name "Film_Adi" --header "Referer: https://play.siteadi.com/" --header "User-Agent: Mozilla/5.0..." --auto-select

Sonuç? Yeşil çubuklar dolmaya başladı. O .jpeg görünümlü video parçaları, tek bir .mp4 dosyası olarak bilgisayarıma indi. 1 GB'lık film, diski öptü.



Bölüm 4: Otomasyon ve C# Botu


Manuel olarak başarmıştım ama hedefim büyüktü. 1000'lerce filmi elle indiremezdim. Hemen Visual Studio Code'u açtım ve bir C# Console Application projesi başlattım.

Botun çalışma mantığını şöyle kurdum:

  1. İndir: System.Diagnostics.Process kütüphanesi ile arka planda N_m3u8DL-RE.exeyi çalıştır ve filmi sunucuya (VDS) indir.
  2. Yükle (Upload): İndirilen filmi, API aracılığıyla DoodStream sunucularına yükle. (Neden DoodStream? Çünkü depolama sınırsız ve izlenme başına $$ veriyor).
  3. Temizle: VDS diski dolmasın diye indirilen yerel dosyayı sil.

İşte o botun Upload kısmından ufak bir kesit:
C#:
// DoodStream'e POST isteği atan fonksiyonumuz
static async Task<string> DoodStreamYukle(string dosyaYolu)
{
    // Önce sunucudan upload adresi istiyoruz
    string serverUrl = await GetUploadServer(apiKey);
 
    using (var form = new MultipartFormDataContent())
    {
        byte[] dosyaBaytlari = File.ReadAllBytes(dosyaYolu);
        var fileContent = new ByteArrayContent(dosyaBaytlari);
        fileContent.Headers.Add("Content-Type", "video/mp4");
    
        // Dosyayı çakıyoruz
        form.Add(fileContent, "file", Path.GetFileName(dosyaYolu));
        form.Add(new StringContent(apiKey), "api_key");

        var response = await client.PostAsync(serverUrl, form);
        // Gelen JSON'dan embed kodunu parse ediyoruz...
        return ParseEmbedLink(await response.Content.ReadAsStringAsync());
    }
}


Bölüm 5: Sonuç ve Gelir Modeli



Bu sistemi bir Windows VDS üzerine kurdum. Bot 7/24 çalıştı.

  • Kaynak siteden yeni düşen filmleri algıladı.
  • Korumaları delip indirdi.
  • DoodStream hesabıma yükledi.
  • Embed kodlarını kendi sitemin veritabanına yazdı.
1 Yılın Sonunda Tablo: Kendi sitemi (WordPress + Dizi Teması) "Offshore" bir hostingde yayına aldım. Bot içerikleri besledi, ben sadece SEO kastım. DoodStream'in "10.000 izlenmeye 1.5 - 3$" veren tarifesiyle, aylık 1M+ hit alan sitemiz pasif bir gelir kapısına dönüştü.



Özetle: Bir sistem ne kadar korunursa korunsun, veriyi tarayıcıya göndermek zorundaysa o veri çekilebilir. Önemli olan doğru anahtarı (Tool'u) ve doğru kapıyı (Header/Referer) bulmaktır.

Sorusu olan varsa konu altından yeşillendirebilir. İyi forumlar.

- Durmuk
 
Onaylı Üye
Katılım
30 May 2026
Mesajlar
76
Tepki puanı
2
Yaş
19
Sosyal
elinize sağlık çok güzel bir gönderi olmuş zevkle ve merakla sonuna kadar okudum.