Hafta 9 — Gelişmiş Kod Gizleme ve Çeşitlendirme¶

Sunumun içine tıklayıp ok tuşlarıyla ilerleyin; tam ekran için sunumun sağ altındaki düğmeyi ya da yukarıdaki "Sunumu tam ekran aç" bağlantısını kullanın.

# Windows (PowerShell) — 'code' klasöründe
.\build.ps1                                    # tüm demoları bir kez derle
cd week-09\01-manual-obfuscation
.\bin\windows\access_clean.exe CEN429-OK     # korumasız sürüm
.\bin\windows\access_obfuscated.exe CEN429-OK     # gizli sürüm — çıktı AYNI

# WSL / Linux — 'code' klasöründe
./build.sh
cd week-09/01-manual-obfuscation
sh demo.sh                                     # açıklamalı tam akış

0. Başlamadan önce¶

Bu bölüm haftaya hazırlık içindir. Önce bu haftanın dayandığı önceki konuları kısaca hatırlatır; sonra bu haftanın kavramlarını birer cümleyle tanımlayıp her birini ayrıntılı anlatıldığı bölüme bağlar. Önceki haftalarda görülmemiş temel bilgiler ise "Ön bilgi" başlıkları altında sıfırdan anlatılır.

Önceki haftalardan gelenler¶

• Beyaz kutu / MATE saldırgan modeli — cihazı elinde tutan kullanıcının aynı zamanda saldırgan olduğu, belleği okuyup hata ayıklayıcı bağlayabildiği tehdit modeli (Hafta 1, §3). Bu hafta §1'de bu modeli MATE (Man-At-The-End) adıyla kod gizlemenin motivasyonu olarak yeniden kullanıyoruz.
• Hata ayıklayıcı (debugger) — programı adım adım çalıştıran, değişkenleri gösteren araç (gdb, lldb); bir hata ayıklayıcının bağlı olup olmadığını çalışma anında denetlemeyi RASP bağlamında görmüştük (Hafta 6, §4). Bu hafta MATE saldırganının araçlarından biri olarak §1'de kısaca geçiyor.
• Entropi (rastgelelik) — bir verinin baytlarının ne kadar düzensiz/öngörülemez göründüğünün ölçüsü; H2'de şifreli/paketli içerik tespitinde (Hafta 2, §6), H3'te rastgele sayı üretiminin temelinde (Hafta 3, §3) gördük. Bu hafta aynı ölçütü, bir saldırganın binary dosyada yüksek entropili blokları (anahtar, şifreli veri) ayırt etmesi bağlamında sayısal bir örnekle derinleştiriyoruz (aşağıdaki "Ön bilgi").
• Derleme bayrağı, strings ve sembol tablosu — derleyiciye verilen seçenekler (-O2, -Wall, -DGUNLUK_ACIK; aynı kaynak bayrağa göre günlüklü ya da günlüksüz derlenebilir) ve bir binary dosyanın okunabilir metinlerini/isim listesini gösteren araçlar; H4'te bunları ilk kez tanımlamış, gizlemenin giriş seviyesindeki adımlarını görmüştük (Hafta 4, §15). Bu hafta K-06/K-07 aynı ipuçlarını daha ileri düzeyde kapatıyor.
• Tersine derleme — bir binary/bayt kodunu geri, okunabilir bir koda yaklaştırma işlemi; H5'te JVM bayt kodu üzerinde gördük (Hafta 5, §10). Bu hafta aynı fikri native (C/C++) binary dosyalar ve Ghidra/IDA gibi araçlarla genişletiyoruz.
• XOR — iki bit farklıysa 1, aynıysa 0 veren işlem; a^b^b=a özelliği sayesinde kendini geri alır. H5'te Java dize gizlemede XOR'u elle çözmüştük (Hafta 5, §12). Bu hafta aynı mekanizmayı K-02 ve K-07 kurallarının temeli olarak kullanıp bit tablosuyla adım adım yeniden izliyoruz (aşağıdaki "Ön bilgi").
• Günlük (log) — programın çalışırken yazdığı bilgi mesajları; hassas bilgi ya da iç durum günlüğe düşerse saldırgan okur. Ne kaydedilir/kaydedilmez ve kurcalamaya dayanıklı günlükleri H2'de ayrıntılı işlemiştik (Hafta 2, §9). Bu hafta yalnız "sürüm binary dosyasında günlüğün kaldırılması" düzen kuralı olarak §2'de kısaca geçiyor.

Bu haftanın kavram haritası¶

Ön bilgi: binary dosyalar, tersine mühendislik ve temel yapı taşları¶

Bu haftanın konusu **kod gizleme**dir; gizlemeyi anlamak için önce bir binary dosyanın nasıl üretildiğini ve bir saldırganın onu nasıl okuduğunu bilmek gerekir. Aşağıdaki kavramların hiçbiri önceki haftalarda öğretilmedi; tanımlardan sonra gelen işlenmiş örnekler bu hafta boyunca sürekli kullanacağımız araçlardır.

Kaynak koddan binary'ye: derleyici, makine kodu ve assembly¶

Kaynak kod, sizin yazdığınız, insanın okuyabildiği program metnidir (ör. bir C dosyası): int topla(int a, int b) { return a + b; }. Kaynak kod derlenir ve makinenin çalıştırdığı biçime döner. Derleyici (compiler), kaynak kodu makine koduna çeviren programdır (gcc, clang); binary dosya (binary) ise derleme sonucudur, bilgisayarın doğrudan çalıştırdığı dosyadır (.exe, .so).

Makine kodu, işlemcinin anladığı sayısal komutlardır; assembly ise makine kodunun insana biraz daha okunur hâlidir (mov, cmp, jmp). Binary dosyayı açtığınızda gördüğünüz şey budur.

Tersine mühendislik ve tersine derleyici¶

Tersine mühendislik (reverse engineering), bir binary dosyaya bakıp programın ne yaptığını anlamaya çalışmaktır — saldırganın temel işi budur. Tersine derleyici (decompiler), binary dosyayı geri, okunabilir koda yakın bir biçime çeviren araçtır (örnekler: Ghidra, IDA); amacı, kaynağa erişimi olmayan birinin binary'ye bakarak mantığı çıkarsamasıdır. (H5'te bunun JVM bayt kodu üzerindeki karşılığını görmüştük — bkz. yukarıdaki "Önceki haftalardan gelenler"; burada aynı fikri native binary dosyalara taşıyoruz.)

Tersine derleyici çıktısı neye benzer? Elimizde yalnız bir .exe/.so dosyası olduğunu, kaynak kodu görmediğimizi hayal edelim. int topla(int a, int b) { return a + b; } fonksiyonunu bir tersine derleyicide açtığımızda, tipik çıktı şuna benzer (araçtan araca biçim değişir, fikir aynıdır):

undefined4 FUN_00401020(int param_1, int param_2)
{
    return param_1 + param_2;
}

Dikkat edin: topla, a, b gibi anlamlı adlar kaybolmuştur (kaynak dosyada vardı, yalnız derleyicinin ürettiği binary dosyada saklı değildi); araç kendi ürettiği FUN_00401020 (adres tabanlı) ve param_1, param_2 gibi jenerik adları kullanır. Ama mantık korunur: toplama işlemi hâlâ açıkça görünür. Bu, gizlemenin neden yalnız adları değiştirmenin (düzen ailesi) yeterli olmadığının somut kanıtıdır — bir tersine derleyici zaten adları kaybetmiş bir şekilde çalışır; asıl mücadele mantığı (kontrol akışı ve veri) okunmaz kılmaktır, bu da bölüm 5 ve 6'nın konusudur.

Bit, bayt, onaltılık¶

Bit, 0 veya 1'dir. Bayt, 8 bittir. Onaltılık (hex), 0x ile yazılır; 0x2A = 42. Kodda 0x5A gibi değerler göreceğiz; bunlar sadece sayılardır.

Onaltılık-ikilik-onluk dönüşümünü tek tabloda pekiştirelim. Onaltılık her bir hanesi tam olarak 4 bit**e karşılık gelir (çünkü 2⁴ = 16); bu yüzden bir bayt (8 bit) her zaman **iki onaltılık haneyle yazılır:

Bu tabloyu birleştirerek 0x5A'yı çözelim: hane 5 → 0101, hane A → 1010; yan yana yazınca 0101 1010 (8 bit, 1 bayt). Onluğa çevirmek için basamak değerleriyle toplarız: 5 × 16 + 10 × 1 = 80 + 10 = 90. Yani 0x5A = 90 (onluk) = 0101 1010 (ikilik) — bu hafta boyunca kod örneklerinde göreceğiniz her 0x.. değeri bu üç gösterimin (hex/ikilik/onluk) aynı sayısının farklı yazılışlarından ibarettir; hiçbiri diğerinden "daha gizli" değildir, yalnız insan için okuma kolaylığı farklıdır (hex kısa, ikilik bit işlemlerini gösterir açıkça).

XOR: tersine çevrilebilir gizlemenin temeli¶

XOR (^), iki bit farklıysa 1, aynıysa 0 veren işlemdir. Özelliği: a ^ b ^ b == a → kendini geri alır:

c = a ^ 0x5A;   /* encode */
a = c ^ 0x5A;   /* decode */

Gizlemede çok kullanılır çünkü tersine çevrilebilir (H5'te Java dize gizlemede XOR'u elle çözmüştük — bkz. yukarıdaki "Önceki haftalardan gelenler"; burada aynı işlemi bit bit izliyoruz).

XOR'u adım adım izleyelim: 0x41 baytını gizleyip geri açalım. XOR'un "kendini geri alma" özelliğini soyut bırakmayalım; tek bir baytı bit bit izleyelim. 'A' harfinin ikilik (ASCII) karşılığı 0x41'dir (onaltılık) = 65 (onluk) = 0100 0001 (ikilik). Anahtar olarak 0x5A = 0101 1010 kullanalım.

Şifreleme: 0x41 ^ 0x5A

Sonuç: 0001 1011 = 0x1B. Kural basit: aynıysa (0^0=0, 1^1=0) sonuç 0, farklıysa (0^1=1, 1^0=1) sonuç 1 — tam da yukarıdaki "XOR" tanımının bit düzeyindeki karşılığı.

Geri çözme: aynı anahtarla tekrar XOR'layalım: 0x1B ^ 0x5A

Sonuç: 0100 0001 = 0x41 — tam olarak başladığımız bayt. Bunu garanti eden cebirsel kural şudur: a ^ b ^ b = a ^ (b ^ b) = a ^ 0 = a (herhangi bir değer kendisiyle XOR'lanınca 0 verir; 0 ile XOR'lanan değer değişmeden kalır). Bölüm 6'daki K-07 kuralında bir dizeyi tam olarak bu mekanizmayla kodlayıp çözeceğiz; orada aynı bit tablosunu tekrar kuracaksınız, sadece bir bayt yerine bir dizi bayt için.

Entropi: bir verinin ne kadar "rastgele" göründüğü¶

Entropi, bir verinin ne kadar "rastgele" göründüğünün ölçüsüdür; kriptografik anahtarlar yüksek entropili görünür (düzensiz baytlar). Saldırgan, binary'de yüksek entropili bir blok görürse "burada anahtar olabilir" der. (H2'de şifreli/paketli içerik tespitinde, H3'te rastgele sayı üretiminde gördüğümüz ölçütün aynısıdır — bkz. yukarıdaki "Önceki haftalardan gelenler"; burada sayısal bir örnekle derinleştiriyoruz.)

Sayısal bir entropi örneği. Yukarıdaki tanımı somutlaştıralım. Basit bir ölçüt olan Shannon entropisi, bir dizideki her farklı bayt değerinin görülme olasılığına bakar: H = -Σ p(x) · log2 p(x). İki küçük örnek üzerinde elle hesaplayalım:

• Dizi A: [0x41, 0x41, 0x41, 0x41] — dört bayt da aynı. Tek değerin olasılığı p = 1, log2(1) = 0, dolayısıyla H = -(1 · 0) = 0 bit/sembol. Tamamen öngörülebilir: ilk baytı görürseniz gerisini bilirsiniz.
• Dizi B: [0x3F, 0xA1, 0x08, 0xC7] — dört bayt da birbirinden farklı, her birinin olasılığı p = 1/4. H = -4 · (1/4 · log2(1/4)) = -4 · (1/4 · (-2)) = 2 bit/sembol — bu dört sembollük alfabede ulaşılabilecek en yüksek entropi değeri.

Gerçek bir kriptografik anahtar, yüzlerce baytlık ölçekte "dizi B" gibi görünür: baytlar arasında tekrar eden bir desen yoktur, her bayt değeri hemen hemen eşit olasılıkla çıkar. Bir saldırgan binary dosyayı tarayan bir araçla gezdiğinde, "dizi A" gibi düşük entropili bloklarla (sabit metinler, sıfır doldurmalar, tekrar eden yapılar) "dizi B" gibi yüksek entropili blokları (anahtarlar, sıkıştırılmış ya da şifreli veri) istatistiksel olarak ayırt edebilir — az önceki tanımdaki "saldırgan yüksek entropili bir blok görürse anahtar olabilir der" cümlesinin sayısal karşılığı tam olarak budur.

Fonksiyon, dal, temel blok ve kontrol akışı grafiği (CFG)¶

Fonksiyon, bir işi yapan kod bloğudur (grant_access); dal (branch), if gibi bir yol ayrımıdır; koşul, dalın hangi yöne gideceğini belirleyen ifadedir. Temel blok (basic block), dalsız, baştan sona akan komut dizisidir — bir if gelince blok biter, iki yeni blok başlar; program, temel blokların birbirine bağlanmasıdır. CFG (Control Flow Graph), temel blokları düğüm, geçişleri kenar yapan şemadır — programın "yol haritası"dır.

Somut bir örnekle "temel blok" ve "CFG" kavramlarını birleştirelim. Bölüm 5'te tekrar göreceğimiz şu küçük fonksiyonu ele alalım:

int check(int input) {
    int a = input + 1;      /* Block 1 */
    if (a > 10) {            /* Block 2 */
        return FAIL;
    }
    return a * 2;             /* Block 3 */
}

Bu fonksiyonu temel bloklara ayıralım: Blok 1 (a = input + 1 ve if koşulunun hesaplanması) dalsız akar, if'e geldiği an biter. Blok 2 koşul doğru ise return FAIL'e gider — bu tek satırlık ayrı bir blok (Blok 2a). Koşul yanlış ise Blok 2b'ye (return a*2) geçilir. CFG'nin düğümleri bu üç blok (1, 2a, 2b), kenarları ise aralarındaki geçişlerdir:

Toplam: 3 düğüm, 2 kenar. Bir tersine derleyici bu grafiği çizdiğinde, "girdi 10'dan büyükse hata, değilse iki katını dön" mantığını saniyeler içinde okur — çünkü düğüm sayısı az, kenarlar doğrudan ve dallanma kararı tek bir karşılaştırmadır. Bölüm 5'te aynı fonksiyonu K-04 ile düzleştirdiğimizde düğüm/kenar sayısının nasıl arttığını ve bu okunabilirliğin nasıl bozulduğunu birebir bu örnek üzerinden göreceğiz — burada tanımını, orada "neden saldırganı yorduğunu" öğreneceksiniz.

Sık karıştırılan üç terim: "kodlama", "şifreleme", "gizleme"¶

Bu üçü konuşma dilinde birbirinin yerine kullanılır ama teknik olarak farklı şeylerdir; karıştırmak sınavda ve projede en sık yapılan kavramsal hatalardan biridir:

• Kodlama (encoding): bir veriyi başka bir gösterime çevirmek (ör. XOR ile basit dönüştürme, Base64). Amaç gizlilik değil temsil**dir; matematiksel bir güvenlik iddiası yoktur. Anahtar (ör. 0x5A) bulunursa **anında geri çevrilir.
• Şifreleme (encryption): matematiksel olarak incelenmiş, anahtara dayalı, ispatlanabilir güvenlik sağlayan dönüşüm (ör. 3. haftadaki AES-GCM). Doğru anahtar olmadan, günümüz bilgisayarlarıyla makul sürede çözülemez.
• Gizleme (obfuscation): kodun insan tarafından anlaşılmasını zorlaştırma. Matematiksel bir güvenlik iddiası yoktur; yalnız çaba ve zaman maliyeti yükseltir (bölüm 1'deki "Kural 1").

Bu ayrım önemlidir çünkü K-07'de göreceğimiz "dize kodlama" tam olarak encoding'dir (XOR ile), encryption değildir — çözme anahtarı da binary dosyanın içinde durur, bu yüzden matematiksel bir gizlilik iddia edilmez; yalnız strings gibi statik araçları yavaşlatır. Bölüm 3'te bunu "gizleme anahtar saklamaz" kuralıyla tekrar göreceğiz.

Hızlı sözlük: bu haftanın İngilizce terimleri¶

Bu haftanın araçları (Ghidra, IDA, KLEE, Tigress, Obfuscator-LLVM) ve akademik kaynaklar İngilizcedir. Aşağıdaki sözlük, ders boyunca geçecek terimlerin İngilizce karşılıklarını verir — bir araç belgesinde ya da makalede karşılaştığınızda tanıyabilmeniz için:

Bir cümlede bu haftanın sorusu¶

Programı kullanıcıya teslim ettim; saldırgan artık ona sahip. Kodumu okumasını ve değiştirmesini nasıl zorlaştırırım?

Yanıt: kod gizleme kuralları. Başlıyoruz.

1. Gizleme neden bir güvenlik kuralıdır?¶

Dersin ilk haftasında (Hafta 1, §3) saldırgan modellerini ayırmıştık. Ağdan girdi gönderen bir saldırgana karşı savunmamız girdi doğrulama, bellek güvenliği ve kriptografiydi. Ama bir mobil uygulamayı, bir masaüstü programını ya da bir gömülü kütüphaneyi kullanıcıya teslim ettiğimizde, saldırgan artık programın kendisine sahiptir. Bu tehdit modeline literatürde MATE (Man-At-The-End, "uçtaki insan") ya da beyaz kutu denir: saldırgan binary dosyayı bir tersine derleyicide açabilir, adım adım çalıştırabilir, belleği okuyup değiştirebilir, istediği kadar deneyebilir. Sunucu tarafındaki hiçbir güvenlik denetimi burada geçerli değildir; çünkü kod saldırganın makinesinde çalışır.

"İmkânsızlık" ne demek? Barak vd.'nin sonucunu sıfırdan anlayalım¶

Tarihçedeki 2001 maddesini biraz açalım, çünkü bu hafta boyunca öğreneceğimiz her kuralın neden asla "kırılamaz" diye pazarlanmadığının temelidir. "Kusursuz kara-kutu gizleme" şu anlama gelir: bir programı öyle bir hâle getirmek ki, saldırgan girdi verip çıktısını gözlemlemekten öte hiçbir şey öğrenemesin — programın içini açıp baksa bile, yalnızca girdi-çıktı ilişkisini gözlemleyen biriyle aynı bilgiye sahip olsun. Barak ve arkadaşları, her program için böyle mükemmel bir dönüşümün var olamayacağını matematiksel olarak kanıtladılar: özel tasarlanmış bazı programlar vardır ki, onların içine bakmak, yalnızca dışarıdan gözlemlemekten kaçınılmaz olarak daha fazla bilgi verir — dönüşüm ne kadar iyi yapılırsa yapılsın.

Bu, dersimiz için iki somut sonuç doğurur:

1. Hiçbir K-01–K-12 kuralı (ya da bunların toplamı) "saldırgan hiçbir zaman hiçbir şey öğrenemez" diye iddia edilemez — böyle bir iddia matematiksel olarak çürütülmüştür.
2. Bu yüzden bu hafta her kuralı "neyi korur / maliyeti / sınırı" biçiminde yazıyoruz (bölüm 4'teki şablon): amaç kusursuz gizlilik değil, bölüm 1'deki üç kuralın (maliyeti artır, otomasyonu kır, zaman kazandır) pratik hedefleridir.

Bu modelde bir gerçekle başlamak dürüstlüktür: yeterli zamanı, becerisi ve motivasyonu olan bir saldırgan her gizlemeyi eninde sonunda çözer. Cookbook bunu açıkça söyler (Tarif 12.1): anti-tampering önlemleri "kırılamaz" değildir; amaçları kırmayı ekonomik olmaktan çıkarmaktır. O yüzden gizlemeyi bir sır saklama yöntemi değil, bir maliyet yükseltme kuralı olarak ele alırız:

• Kural 1 — Maliyeti değerin üstüne çıkar. Saldırıyı, korunan varlığın değerinden daha pahalı hale getir. 10 TL'lik bir sırrı 1000 TL'lik bir çabayla korumak akıldışıdır; tersi de geçerlidir.
• Kural 2 — Otomasyonu kır. Bir kopyada işe yarayan saldırının bütün kopyalarda otomatik işe yaramamasını sağla. Bunun adı çeşitlendirmedir (bu haftanın 5. bölümü, 14. haftada araçla).
• Kural 3 — Diğer katmanlara zaman kazandır. Gizleme tek başına bir savunma değildir; RASP (6. hafta), bütünlük denetimi, sunucu tarafı denetimler ve anahtar yenileme için zaman kazandıran bir katmandır. Anahtar yenilenene, sürüm güncellenene kadar dayanması yeter.

Sayısal örnek: "maliyeti değerin üstüne çıkar" ne demek?¶

Kural 1'i havada bırakmayalım; basit bir maliyet-fayda hesabıyla somutlaştıralım. Değerler tamamen varsayımsaldır (gerçek bir sözleşme ya da ürün rakamı değildir), amaç yalnız akıl yürütme biçimini göstermektir:

1. Deneyimli bir tersine mühendisin saatlik "pazar değeri"nin 500 TL olduğunu varsayalım.
2. Hiç gizleme uygulanmamış bir binary dosyada, lisans_dogrula gibi adı kendini ele veren bir fonksiyonu bulup mantığını çıkarmak 10 dakika (⅙ saat) sürsün. Saldırganın maliyeti: 500 × (1/6) ≈ 83 TL.
3. Bu hafta öğreneceğimiz üç kuralı (kontrol akışı düzleştirme K-04 + opak yüklem K-01 + dize kodlama K-07) birlikte uyguladığımızda, aynı analiz 40 saate çıksın (bu tür süreler gerçek projelerde ölçülür, tahmin edilmez — bölüm 9). Saldırganın maliyeti: 500 × 40 = 20.000 TL.
4. Şimdi iki senaryo karşılaştıralım:
   • Korunan varlığın (ör. bir lisans anahtarının kopyalanmasını engellemenin) değeri yıllık 5.000 TL'lik bir gelir kaybını önlüyorsa: 20.000 TL > 5.000 TL — saldırı ekonomik olarak anlamsızdır, kural amacına ulaşmıştır.
   • Korunan varlığın değeri yıllık 100.000 TL ise: 20.000 TL < 100.000 TL — saldırı hâlâ kârlıdır; tek başına bu üç kural yetmez, ek katmanlar (RASP — 6. hafta, whitebox — 11. hafta) gerekir.

Bu akıl yürütme aynı zamanda 1. haftada gördüğümüz risk = olasılık × etki çerçevesiyle örtüşür: burada "maliyeti yükseltmek" saldırının olasılığını (rasyonel bir saldırganın girişme ihtimalini) düşürmenin yoludur.

2. Gizleme taksonomisi: beş aile¶

Collberg ve arkadaşlarının yazılım koruma dizisinden bu derse taşıdığımız sınıflandırma, gizlemeyi neyi gizlediğine göre beş aileye ayırır. Bu harita 4. haftada tanıtıldı; burada her ailenin "ne zaman kural haline geldiğini" netleştiriyoruz.

İşlenmiş örnek: bir fonksiyonda beş aileyi ayrı ayrı görelim¶

Taksonomiyi soyut bırakmayalım. Aşağıdaki küçük (sentetik) fonksiyonda, hangi satırın hangi aileye ait olduğunu yorum satırlarıyla işaretleyelim:

/* LAYOUT: the function name isn't 'threshold_compute' but the meaningless 'f7' */
int f7(int x) {
    /* DATA: the 0x2A constant isn't written directly, it's produced from two parts (K-02, section 6) */
    uint8_t threshold = (uint8_t)(0x37 ^ 0x1D);

    /* CONTROL FLOW: branching via an opaque predicate (K-01, section 5) */
    if (((x * (x + 1)) & 1u) == 0u) {
        return threshold;     /* real path: since x*(x+1) is always even, this is ALWAYS entered */
    }
    return 0;                 /* ANTI-ANALYSIS dead branch: never runs, just distracts the analyst */
}

Beşinci aile — sanallaştırma — bu küçük örnekte yok, çünkü sanallaştırma tek bir satıra değil fonksiyonun tamamının makine koduna uygulanır (bölüm 7, K-10). Bu örnek şunu göstermek içindir: gerçek kodda beş aile iç içe yaşar; bir satırı okurken "bu hangi ailenin işi?" diye sorabilmek, kaynağın "hepsi birlikte kullanılmalı" uyarısını somutlaştırır.

Şimdi bu dört aileyi kavramsal f7 örneğinde değil, bu haftanın gerçek grant_access fonksiyonunda, gerçek satır numaralarıyla görelim — sonra aynı fonksiyonu 10 jetonla çalıştırıp davranışın korunduğunu doğrulayalım:

Normal, zor ve iki uç durum hazır örneği deneyin, 🎲 ile rastgele jeton kümesi üretin ya da kendi jetonlarınızı yazın.

Neden bu sıra? Aşağıdan yukarı güç ve maliyet neden artıyor?¶

Görseldeki (h09-01) "aşağıdan yukarı güç ve maliyet artar" notunu açalım — bu tesadüfi bir sıralama değildir, her ailenin neyi değiştirdiğiyle doğrudan ilgilidir:

• Düzen yalnız isimleri/meta veriyi değiştirir; programın davranışını üreten hiçbir şeye dokunmaz. Bu yüzden uygulaması ucuzdur (bir derleyici bayrağı ya da isim listesi) ama gücü de düşüktür — az önceki örnekte gördüğümüz gibi, mantık hâlâ aynı kalır.
• Veri ve kontrol akışı, programın ne işlediğini ve hangi sırayla işlediğini değiştirir; bu yüzden hem daha fazla mühendislik emeği (her sabiti, her dalı elden geçirmek) hem de çalışma zamanı maliyeti (fazladan komutlar) gerektirir — güçleri de buna paralel artar.
• Önleyici teknikler (K-06'daki fonksiyon değiştirme gibi) analiz araçlarının kendisini hedef alır; bu, yalnız veriyi/akışı gizlemekten daha zahmetlidir çünkü hangi aracın kullanılacağını tahmin etmeniz gerekir.
• Sanallaştırma, programın makine kodunun kendisini değiştirir — artık orijinal komutlar hiç yoktur, yerine bambaşka bir komut kümesi (VM bayt kodu) geçer. Bu en radikal değişikliktir; bu yüzden hem en güçlü hem de (K-10'da gördüğümüz gibi %'lerle ifade edilemeyecek kadar büyük, kata-dayalı) en pahalı seçenektir.

Kısacası: bir aile davranışı üreten mekanizmaya ne kadar yakınsa, onu gizlemek o kadar güçlü ama o kadar pahalı olur. Bölüm 9'daki dört ölçütü hatırlarsanız, bu sıralama aslında güç ↔ maliyet ödünleşiminin taksonomi üzerindeki yansımasıdır.

3. Gizleme ne verir, ne vermez?¶

Bir kuralı doğru uygulamak için sınırını bilmek gerekir. 4. haftada bu ayrımı kısaca görmüştük; burada tabloyu ve bir saldırganın ilk on dakikasını izleyen bir zaman çizelgesiyle derinleştiriyoruz. Gizlemenin verdikleri ve vermedikleri şunlardır:

Adım adım: bir saldırganın ilk 10 dakikası — gizleme öncesi ve sonrası¶

Tablodaki "verir/vermez" ayrımını bir zaman çizelgesine dökelim. İki sürümü de düşünün: korumasız ve bu haftanın kurallarıyla korunmuş.

Korumasız binary dosyada saldırganın ilk 10 dakikası:

1. strings program.exe çalıştırır → "CEN429-OK", "Erisim reddedildi" gibi dizeler doğrudan görünür (0. dakika).
2. Tersine derleyiciyi açar, sembol tablosunda grant_access, lisans_dogrula gibi adları görür (2. dakika).
3. Fonksiyonun CFG'sini okur: tek bir if/else, hangi dalın "izin", hangisinin "red" olduğu bir bakışta bellidir (5. dakika).
4. Karşılaştırma değerini ("CEN429-OK") bulur, kendi girdisiyle test eder, doğrular (10. dakika). İş bitmiştir.

Bu haftanın kurallarıyla korunmuş binary dosyada aynı 10 dakika:

1. strings çalıştırır → K-07 sayesinde dizeler görünmez; eline bir ipucu geçmez (0. dakika).
2. Sembol tablosuna bakar → K-06 ve düzen ailesi sayesinde tanınan bir ad yoktur (2. dakika).
3. CFG'yi açar → K-04 düzleştirmesi yüzünden tek bir switch dağıtıcısı görür; hangi case'in "izin" olduğu belli değildir; K-01 opak yüklemleri hangi dalın gerçek, hangisinin ölü olduğunu gizler (10. dakika, hâlâ çözülmemiştir).
4. Saldırgan bu noktada ya sembolik yürütme gibi otomatik bir araca geçer (bölüm 10 — dakikalar değil saatler alır) ya da vazgeçer.

Bu iki çizelge, tablodaki dört satırın zamana yayılmış hâlidir: gizleme "asla kırılmaz" demez, "10 dakika yerine saatler/günler ister" der.

4. "Koruma kuralı" şablonu¶

Bu hafta boyunca her tekniği aynı dört soruyla değerlendireceğiz. Kendi projenizin S9 bölümünü de bu şablonla yazmanızı bekliyoruz:

KURAL K-xx: <tekniğin adı>
  Neyi korur? : hangi varlık / hangi kod bölümü (ör. lisans denetimi, anahtar türetme)
  Hangi tehdide karşı? : statik analiz / dinamik analiz / otomatik saldırı / kurcalama
  Nasıl? : kavram düzeyinde uygulama (bir cümle)
  Maliyet : boyut, hız, bakım, hata ayıklama zorluğu
  Sınır : neyi korumaz, hangi saldırıya dayanmaz
  Ölçüm : etkinliği nasıl doğrularız (bkz. bölüm 5)

Bu şablonun değeri şudur: bir gizleme "var/yok" değildir. Değerlendirici (13. hafta, saldırı potansiyeli puanlaması) her katmanın saldırıyı ne kadar geciktirdiğini sorar. Yukarıdaki "Ölçüm" satırı olmadan bir koruma kararını savunamazsınız.

İşlenmiş örnek: şablonu bu haftanın demosuyla dolduralım¶

Soyut kalmasın diye, bu bölümün başındaki "Bu haftanın çalışan demosu" kutusunda verilen gerçek ölçüm sayılarıyla (K-04'ün demoda uygulanmış hâli) şablonu tam olarak dolduralım:

KURAL K-04-uygulama: grant_access fonksiyonuna kontrol akışı düzleştirme
  Neyi korur?       : erişim denetiminin akış sırası (CEN429-OK karşılaştırmasının nerede/nasıl yapıldığı)
  Hangi tehdide karşı?: statik analiz (tersine derleyicide CFG okuma), tek-bayt/tek-dal yama saldırısı
  Nasıl?            : switch tabanlı dağıtıcı (K-04) + opak yüklem (K-01) + rastgele çıkış (K-05)
  Maliyet           : komut sayısı 27 → 49 (+%81,5), dal/çağrı sayısı 4 → 9 (+%125) — objdump ile ölçüldü
  Sınır             : yalnız düzleştirme; sembolik yürütmeyle geri açılabilir (bölüm 10); veri hâlâ K-07 ister
  Ölçüm             : objdump çıktısında komut/dal sayısı karşılaştırması (bu haftanın demosu, adım adım kılavuzda)

Maliyet satırındaki yüzdeleri doğrulayalım: komut sayısında artış (49 − 27) / 27 × 100 ≈ %81,5; dal/çağrı sayısında artış (9 − 4) / 4 × 100 = %125 (ikiden fazla katına çıkmış). Bu, "Ölçüm" satırının iddia değil rakam olması gerektiğinin somut kanıtıdır — bölüm 9'da bu sayıları tekrar kullanacağız.

İkinci bir işlenmiş örnek: farklı bir varlık için şablonu dolduralım¶

Şablonun her varlık türüne uyduğunu görmek için, bu kez bölüm 6'da tanıyacağımız bir veri koruma kuralını dolduralım (fonksiyon değil, bir dize):

KURAL K-07-uygulama: hata mesajı dizgesine dize kodlama
  Neyi korur?       : ikili dosyada duran "Erisim reddedildi" gibi okunabilir metinler
  Hangi tehdide karşı?: strings taraması (bölüm 3'teki "saldırganın ilk 10 dakikası")
  Nasıl?            : XOR 0x5A ile kodla, kullanım anında çöz, memset_s ile hemen sil (bölüm 6)
  Maliyet           : düşük — birkaç ek komut, ölçülebilir bir hız kaybı yok
  Sınır             : çözme anahtarı ikilide durur; gerçek anahtar koruması değildir (bölüm 3 kuralı)
  Ölçüm             : strings çıktısında ilgili dizge sayısı: kodlama öncesi 1, sonrası 0

İki örneği (K-04-uygulama ve K-07-uygulama) yan yana koyduğumuzda fark netleşir: kontrol akışı kuralları genelde "komut/dal sayısı" ile, veri kuralları genelde "görünür dize/sabit sayısı" ile ölçülür — ama her ikisinde de şablonun altı satırı aynı disiplinle doldurulur. S9'unuzda en az bir kontrol akışı, bir de veri kuralı için bu şablonu ayrı ayrı doldurmanız beklenir.

Şablonu şimdi 5 gerçek kuralın (R-01, R-04, R-05, R-07, R-08) tümü için, iki farklı varlıkta (bu haftanın ÖLÇÜLMÜŞ grant_accessı ve bölüm 9'un kavramsal lisans_dogrula örneği) dolu görelim — ikisini KARIŞTIRMAMAK önemli:

Normal (10 satırın tamamı), zor (yalnız ölçülmüş grant_access, tekrarlı) ve iki uç durum (yalnız kavramsal varlık; tek kural iki varlıkta) örneğini deneyin.

5. Kontrol akışı kuralları (ileri)¶

Derlenmiş bir fonksiyonun kontrol akışı grafiği (CFG) algoritmanın iskeletini gösterir: hangi denetim hangi sırayla yapılıyor, hangi dal başarıya gidiyor. Beyaz kutu saldırganın ilk işi bu iskeleti çıkarmaktır. Kontrol akışı gizleme kuralları, bu iskeleti okunamaz kılar. 4. haftada düzleştirmeye giriş yaptık; burada onu güçlendiren kuralları ekliyoruz. Bütün örnekler sentetiktir ve tek bir küçük denetim (grant_access) üzerinden anlatılır.

KURAL K-01 — Opak yüklemler ve opak döngüler¶

Neyi korur? Bir dalın hangi koşulda alındığını; bir döngünün kaç kez döndüğünü. Nasıl? Değeri programcının bildiği ama analiz aracının kolayca çözemediği bir ifadeyle (opak yüklem) dallanma yapılır. Klasik örnek, her zaman doğru olan ama bunu statik olarak kanıtlaması zor bir aritmetik özdeşliktir:

/* x*(x+1) is always even → (x*(x+1)) % 2 == 0 is always true. */
static int opaque_true(unsigned x) { return ((x * (x + 1)) & 1u) == 0; }

if (opaque_true(counter)) {          /* real path: always entered */
    state = real_step(state);
} else {
    state = fake_step(state);    /* dead path: never runs, but looks real under analysis */
}

Kılavuz, opak döngüleri ayrı bir kural olarak yazar: döngüler (for, while) doğrudan görünmez; kontrol akışı düzleştirmenin içine gizlenir, gövde küçük bloklara bölünür ve yineleme bir durum değişkeniyle yönetilir. Böylece "şu döngü N kez dönüyor" bilgisi CFG'den okunamaz.

Maliyet: düşük–orta (fazladan aritmetik ve dal). Sınır: iyi bilinen opak yüklem kalıpları (kütüphaneler) otomatik tanınabilir; bu yüzden çeşitlendirilmeleri gerekir. Ölçüm: düzleştirme öncesi/sonrası temel blok sayısı.

Bu haftanın demosunda aynı fikir grant_accessin opaque_zero(x) = (x*(x+1)) & 1 ifadesiyle kullanılıyor — bir if değil, doğrudan state hesabına katılan bir opak sabit. Aşağıda bunu birçok x değeri için tarayıp gerçekten her zaman 0 döndüğünü, sonra gerçek kullanım satırını görelim:

Normal, zor ve iki uç durum hazır örneği deneyin, ya da 🎲 ile kendi x kümenizi üretin.

İşlenmiş örnek: opak bir döngü sınırını elle izleyelim. Kılavuzun "döngü sınırı CFG'den okunamaz" iddiasını sayılarla doğrulayalım. Gerçek yineleme sınırımız 3 olsun, ama bunu doğrudan yazmak yerine ikinci bir her zaman doğru opak yüklemle örtelim:

static int always_true(unsigned y) { return ((y * y + y) & 1u) == 0u; }  /* y*(y+1) is always even — see above */

unsigned i = 0;
while (always_true(i) && i < REAL_LIMIT) {   /* REAL_LIMIT = 3, defined in a separate constant (can be encoded with K-02) */
    process(i);
    i++;
}

Elle izleyelim (REAL_LIMIT = 3):

Sonuç: döngü tam olarak 3 kez çalışır (i = 0, 1, 2), tıpkı beklendiği gibi. Ama dikkat: always_true(i) her zaman true döner — bu yüzden bir analiz aracı, döngünün ne zaman biteceğini anlamak için always_true'yu değil i < REAL_LIMIT karşılaştırmasını izlemek zorundadır; ve always_true'nun her zaman doğru olduğunu kanıtlamak için de yukarıdaki tam-sayı özdeşliğini çözmesi gerekir. İki ayrı analiz yükü aynı satıra binmiştir.

KURAL K-02 — Aritmetik komutların kodlanması¶

Neyi korur? Sabitleri ve basit hesapları; "bu sayı 0x1F, bu işlem bir XOR" gibi doğrudan okunabilir ipuçlarını. Nasıl? Bir işlem, sonucu değişmeyen ama daha karmaşık görünen denk bir ifadeyle değiştirilir (mixed boolean-arithmetic). Örneğin a + b, (a ^ b) + 2*(a & b) ile aynıdır; x * 2, x << 1 ile. Sabitler doğrudan yazılmaz, çalışma anında küçük bir hesapla üretilir:

/* Produce it from two parts instead of 0x2A; a '0x2A' search in the binary returns nothing. */
static uint8_t threshold(void) { uint8_t a = 0x37, b = 0x1D; return (uint8_t)(a ^ b); } /* = 0x2A */

Maliyet: düşük. Sınır: modern tersine derleyiciler ve arybo/msynth gibi araçlar birçok MBA ifadesini sadeleştirebilir; tek başına zayıftır, kontrol akışı gizlemeyle birlikte anlam kazanır. Ölçüm: sabit için strings/bayt araması sonuç vermemeli.

İşlenmiş örnek: iki MBA özdeşliğini elle doğrulayalım. Kuralın verdiği örnek a + b ↔ (a ^ b) + 2·(a & b) iddiasını sayılarla kanıtlayalım (a = 5, b = 3):

İkisi de 8 — özdeşlik doğrulandı. Bu, dört bitlik her a,b çifti için geçerli bir cebirsel kimliktir (taşıma bitini 2·(a&b) terimi telafi eder); derleyici bunu a+b yerine üretirse, binary dosyada düz bir "toplama" görünmez, üç ayrı komut (XOR, AND, kaydırma+toplama) görünür.

Aynı mantıkla kuraldaki threshold() fonksiyonunun ürettiği 0x2A sabitini de doğrulayalım (a = 0x37, b = 0x1D):

Sonuç: 0010 1010 = 0x2A — kod bloğundaki yorumla birebir örtüşüyor. Binary dosyada 0x2A değeri hiçbir yerde tek bir bayt olarak durmaz; yalnız 0x37 ve 0x1D durur, strings/bayt taramasıyla 0x2A aranırsa sonuç çıkmaz.

KURAL K-03 — Sahte işlemler ve ölü dallar (ikisi farklıdır)¶

Kılavuz bu ikisini ayrı kurallar olarak yazar ve aradaki fark önemlidir:

crc = crc32_update(crc, data, n);
crc ^= (constant ^ constant);   /* = crc; bogus operation, result unchanged */

Neyi korur? Gerçek mantığı, onu çevreleyen anlamsız ama makul görünen kodla. Maliyet: düşük (sahte işlem) –orta (ölü dallar CFG'yi büyütür). Sınır: ölü kod eleme yapan bir analiz aracı, opak yüklem çözülürse ölü dalı atabilir; bu yüzden opak yüklemin kalitesine bağlıdır. Ölçüm: ölü dalların gerçek dallardan ayırt edilme süresi.

İşlenmiş örnek: sahte işlem gerçekten sonucu değiştirmiyor mu? Yukarıdaki crc ^= (constant ^ constant) satırını sayı ile doğrulayalım (constant = 0x11 olsun): constant ^ constant = 0x11 ^ 0x11 = 0x00 (herhangi bir değer kendisiyle XOR'lanınca her zaman 0 verir — bölüm 0'daki XOR özdeşliğinin aynısı). crc ^= 0x00 işlemi crc'yi değiştirmez (x ^ 0 = x). Yani constant ne olursa olsun bu satır matematiksel olarak her zaman etkisizdir; kalabalıklaştırma etkisi yalnız **derlenmiş komut sayısında**dır, crc'nin değerinde değil.

KURAL K-04 — Kontrol akışı düzleştirme (derin)¶

Neyi korur? Algoritmanın yapısını: blokların doğal komşuluğunu ve "hangi bloktan hangisine gidilir" bilgisini. Nasıl? Kılavuzun deyişiyle, dikey kontrol akışı yatay hale getirilir: bütün temel bloklar tek bir döngü içindeki bir switch dağıtıcısına taşınır; sıra yalnız bir durum değişkeninden okunur.

Kökeni: bu teknik akademik olarak Wang, Hill, Knight ve Davidson'ın 2000 tarihli "Software Tamper Resistance: Obstructing Static Analysis of Programs" raporuna dayanır — dolaylı adresleme (aliased pointer) ile birleştirilen düzleştirmenin, programı statik olarak kesin çözmeyi genel durumda NP-zor kıldığını kanıtlamışlardır (bölüm 1'deki tarihçe kutusu).

int state = START;
for (;;) {
    switch (state) {
    case START:  state = STEP1; break;
    case STEP1:  state = condition ? STEP2 : FAIL; break;
    case STEP2:  state = DONE; break;
    case FAIL:   return DENIED;
    case DONE:   return GRANTED;
    default:     return DENIED;          /* random exit lands here (K-05) */
    }
}

Dördüncü haftada bu şablonun tek başına deneyimli bir analist için kısa sürede çözülebildiğini söylemiştik. Kılavuzun "native tarafta bu düzleştirme birçok güvenlik özelliğiyle güçlendirilir" dediği güçlendirmeler tam olarak diğer kurallardır:

• Durum değerleri gizlenir (K-02): case 1, 2, 3 yerine dağınık, aritmetikle üretilen değerler; ardışıklık görünmez.
• Sahte ve ölü bloklar eklenir (K-03): hangi case gerçek, ayırt etmek zorlaşır.
• Rastgele çıkış (K-05): hata default dalından, öngörülemeyen bir durumla çıkar.
• Opak yüklemlerle dallanma (K-01): case geçişleri sabit değil, opak koşullara bağlıdır.

Maliyet: orta–yüksek (blok sayısı ve dal çok artar, başarım düşer). Sınır: yalnız düzleştirme, sembolik yürütmeyle (bölüm 5) geri açılabilir; gücü güçlendirmelerden gelir. Ölçüm: tersine derleyicide CFG düğüm/kenar sayısı, bir denetimi izlemek için gereken süre.

İşlenmiş örnek: üç bloklu bir fonksiyonu elle düzleştirelim. Aşağıdaki sıradan (düzleştirilmemiş) fonksiyonla başlayalım:

int check(int input) {
    int a = input + 1;      /* Block 1 */
    if (a > 10) {            /* Block 2 */
        return FAIL;
    }
    return a * 2;             /* Block 3 */
}

Bu üç bloğu, K-04'teki şablonla düzleştirilmiş haline elle taşıyalım:

int check(int input) {
    int state = S1, a = 0;
    for (;;) {
        switch (state) {
        case S1: a = input + 1; state = S2; break;
        case S2: state = (a > 10) ? S_FAIL : S3; break;
        case S3: return a * 2;
        case S_FAIL: return FAIL;
        default: return FAIL;      /* random exit lands here (K-05) */
        }
    }
}

input = 4 için elle izleyelim: state=S1 → a = 4+1 = 5, state=S2. state=S2 → a(5) > 10 yanlış, state=S3. state=S3 → return 5*2 = 10. İki sürüm de aynı input için aynı 10 değerini döndürür — davranış korunmuştur, yalnız akışın şekli değişmiştir: doğal sürümde üç blok art arda okunurken, düzleştirilmiş sürümde hepsi tek bir switch'in eşit mesafedeki dalları gibi görünür ve aralarındaki doğal komşuluk bilgisi (S1'den sonra hep S2 gelir) CFG'den silinmiştir; artık yalnız state değişkeninin çalışma anındaki değerinden okunabilir.

Şimdi bunu kavramsal check örneği yerine bu haftanın gerçek demosunda görelim: clean.c'nin doğal if-zinciri ile obfuscated.c'nin switch dağıtıcısı, aynı 10 jetonla yan yana.

Normal (düz sürüm) ve zor (düzleştirilmiş sürüm, aynı jetonlar) örneklerini karşılaştırın; iki uç durum (hepsi geçerli, hepsi yanlış uzunlukta) dağıtıcının en kısa ve en uzun yollarını gösterir.

KURAL K-05 — Kontrol akışından rastgele çıkış¶

Neyi korur? Bir denetimin nerede başarısız olduğunu. Saldırgan çoğu zaman "başarısızlık dalını" bulup onu "başarı dalına" çevirmeye çalışır. Nasıl? Kılavuzun anlattığı gibi: bir denetim başarısız olduğunda, program doğrudan bir "return RED" satırına gitmez; bunun yerine durum değişkeni öngörülemeyen büyük bir değere ayarlanır ve fonksiyon default dalından çıkar. Başarılı çıkış da aynı yöntemle yapılabilir, böylece başarı ve başarısızlık akışta birbirine benzer.

if (!signature_valid(p)) {
    state = unpredictable_value();   /* a value not defined in the switch → default */
    break;
}

Maliyet: düşük. Sınır: tek başına değil, düzleştirmeyle birlikte anlamlıdır. Ölçüm: "başarısızlık dalını bul ve tersine çevir" saldırısının süresi; ideal olarak tek bir bayt yaması denetimi atlatmaya yetmemeli.

KURAL K-06 — Fonksiyon çağrılarının ve dış kütüphane bağımlılığının gizlenmesi¶

4. haftada fonksiyon adı ve bellek ayırma gizlemeye kısaca değinmiştik; burada bunu dış kütüphane bağımlılığı ve sahte parametrelerle derinleştiriyoruz.

Neyi korur? "Şu fonksiyon memcmp çağırıyor, demek ki bir karşılaştırma yapıyor" gibi ipuçlarını. Standart kütüphane çağrıları, saldırgana bir fonksiyonun ne yaptığını doğrudan söyler. Nasıl? Kritik yollarda standart kütüphane fonksiyonları kendi iç sürümleriyle değiştirilir (ör. sabit zamanlı kendi is_equal fonksiyonunuz), böylece bağlantı çözümleyicide tanınan bir ad görünmez. Kılavuz ayrıca fonksiyon parametrelerinin gizlenmesini ve sahte parametreler eklenmesini de ayrı kurallar olarak listeler: gerçek parametrelerin yanına hiç kullanılmayan sahte parametreler konur; imza, saldırgan için yanıltıcı olur.

Maliyet: düşük–orta (kendi sürümleri bakım ister). Sınır: davranış analizi yine de ne yaptığını gösterebilir; bu bir gecikme kuralıdır. Ölçüm: binary dosyada tanınan kütüphane çağrılarının sayısı.

İşlenmiş örnek: memcmp yerine kendi sabit zamanlı karşılaştırmanız. Kural, standart memcmp'yi tanınabilir olduğu için değiştirmemizi söylüyor; ama asıl kazanç 3. haftadan tanıdık bir yan kanal kapatmaktır:

static int constant_time_equals(const uint8_t *a, const uint8_t *b, size_t n) {
    uint8_t diff = 0;
    for (size_t i = 0; i < n; i++) {
        diff |= (uint8_t)(a[i] ^ b[i]);   /* every byte is processed, does NOT stop at the first mismatch */
    }
    return diff == 0;                      /* a single comparison, at the end of the array */
}

a = {0x41,0x42,0x43}, b = {0x41,0x00,0x43} için izleyelim: i=0: 0x41^0x41=0x00, diff = 0x00. i=1: 0x42^0x00=0x42, diff = 0x00 | 0x42 = 0x42. i=2: 0x43^0x43=0x00, diff = 0x42 | 0x00 = 0x42. Döngü her zaman üç adım da çalışır, i=1'de uyuşmazlık bulunduğunda erken çıkmaz; sonunda diff = 0x42 ≠ 0, constant_time_equals 0 (false) döner. Standart bir memcmp ya da elle yazılmış for (...) if (a[i]!=b[i]) return 0; ise i=1'de erken döner — bu, uyuşmazlığın nerede olduğunu çalışma süresinden sızdırabilen klasik bir zamanlama kanalıdır (3. haftadaki CRYPTO_memcmp kuralının aynısı). K-06'nın kazancı iki katlıdır: hem memcmp adı binary dosyada görünmez hem de karşılaştırma sabit zamanlıdır.

Sahte parametre örneği. Kuralın ikinci kısmı — sahte parametreler — imzayı yanıltıcı yapar:

/* Real signature: int access_check(const char *code); */
int access_check(const char *code, int log_level, void *settings) {
    (void)log_level;   /* unused — bogus parameter */
    (void)settings;           /* unused — bogus parameter */
    return constant_time_equals((const uint8_t *)code, REAL_CODE, REAL_CODE_LENGTH);
}

Bir tersine derleyici bu fonksiyonu üç parametreli olarak gösterir; saldırgan "ikinci parametre günlük seviyesi mi, üçüncüsü bir yapı işaretçisi mi gerçekten kullanılıyor mu?" sorusuna cevap ararken zaman kaybeder — hâlbuki ikisi de hiç kullanılmaz. (void)parametre satırları derleyicinin "kullanılmayan parametre" uyarısını susturur; gerçek projelerde bu satırlar aranmadıkça sahte olduğu belli olmaz.

6. Veri gizleme kuralları¶

Kontrol akışı algoritmanın yapısını gizler; veri gizleme ise programın işlediği değerleri gizler: dizeler, sabitler, tablolar ve değişkenler. Cookbook'un anti-tampering bölümü ile teknik kılavuz burada aynı kuralları listeler.

KURAL K-07 — Statik dizelerin kodlanması¶

4. haftada dize gizlemeye giriş yapmış, 5. haftada Java tarafında XOR ile elle çözmüştük; burada aynı fikri C/C++ tarafında derinleştiriyoruz.

Neyi korur? Binary dosyadaki okunabilir metinleri. Tersine mühendisliğin en ucuz ilk adımı strings çalıştırmaktır; "Lisans gecersiz" ya da bir URL, saldırgana nereye bakacağını söyler. Nasıl? Hassas dizeler derleme öncesinde kodlanır (ör. bir XOR anahtarıyla ya da bir üretim betiğiyle şifrelenir), binary dosyada kodlanmış hâlde durur, kullanım anında çözülür ve iş biter bitmez bellekten silinir.

static const uint8_t HIDDEN[] = { 0x3B,0x2A,0x2E,0x2E,0x2D };   /* not "merhaba"; synthetic */
void use(void) {
    char tmp[sizeof HIDDEN];
    for (size_t i = 0; i < sizeof HIDDEN; i++) tmp[i] = HIDDEN[i] ^ 0x5A;  /* decode */
    process(tmp, sizeof HIDDEN);
    secure_wipe(tmp, sizeof tmp);   /* wipe immediately after use (week 3) */
}

Maliyet: düşük. Sınır: çalışan programda çözülmüş dize bellekte görünür; bu bir statik tarama önlemidir. Çözme anahtarı da binary dosyadadır — bu yüzden sahada çözme anahtarı parçalanır ve dağıtılır ve çözme fonksiyonu ek denetimlerle korunur. Ölçüm: strings çıktısında hassas dize bulunmamalı.

İşlenmiş örnek: yukarıdaki HIDDEN dizisini elle çözelim. Kod bloğundaki HIDDEN = {0x3B, 0x2A, 0x2E, 0x2E, 0x2D} dizisini, her baytı 0x5A ile XOR'layarak (bölüm 0'daki bit tablosuyla aynı yöntem) tek tek çözelim:

Çözülen bayt dizisi "apttw" — kod yorumundaki "merhaba değil; sentetik" ifadesiyle tutarlı: gerçek bir dizeyi değil, mekanizmayı gösteriyoruz. Önemli olan şudur: binary dosyada duran baytlar {0x3B, 0x2A, 0x2E, 0x2E, 0x2D}'dir; strings bu baytları çalıştırıp XOR uygulamaz, olduğu gibi okumaya çalışır ve okunabilir bir metin bulamaz (bu beş bayt yazdırılabilir ASCII aralığının dışına düşebilir ya da anlamsız görünür) — saldırganın ilk ve en ucuz adımı (bölüm 3'teki "ilk 10 dakika") burada boşa çıkar.

Şimdi HIDDEN/apttw kavramsal örneği yerine bu haftanın gerçek obfuscated.c kodunu — ENCODED[]in tüm yaşam döngüsünü (kodlu bekler → kullanım anında çözülür → hemen silinir) — görelim:

Normal, zor (geçerli jeton tekrar tekrar — silme her seferinde çalışıyor mu?) ve iki uç durum örneğini deneyin.

KURAL K-08 — Sabit dönüşümleri, opak boolean ve fonksiyon boolean dönüşleri¶

Kılavuz güvenlik sonuçlarının nasıl temsil edileceğini ayrı bir kural yapar. Bir denetimin sonucunu düz bir 0/1 olarak döndürmek tehlikelidir: saldırgan tek bir baytı çevirerek "başarısız"ı "başarılı"ya dönüştürebilir. Opak boolean kuralı, doğru/yanlış değerini birden çok değere bağlı ve tek bir bayt yamasıyla çevrilemeyecek biçimde tutar. Fonksiyonlar da düz boolean yerine bu tür opak dönüş kodları verir.

/* The "allow" value isn't a single constant; it's derived from two states, and the caller verifies both. */
typedef struct { uint32_t a, b; } Decision;
static Decision allow(void)  { return (Decision){ 0xA3C1u, 0x5C3Eu }; } /* a ^ b == 0xFFFF */
static int  decision_grants(Decision k) { return (k.a ^ k.b) == 0xFFFFu; }

Maliyet: düşük. Sınır: yeterince incelenirse çözülür; amacı tek-bayt yamayı ve kaba dal-çevirmeyi engellemektir. Ölçüm: "sonucu tersine çevir" saldırısında değiştirilmesi gereken bağımsız nokta sayısı > 1.

İşlenmiş örnek: 0xA3C1 ^ 0x5C3E gerçekten 0xFFFF mi? Kod örneğindeki iddiayı dörtlü gruplar (nibble) hâlinde doğrulayalım:

Dört nibble de F çıkıyor → a ^ b = 0xFFFF, iddia doğrulandı. Her nibble'ın F olmasının nedeni basit: iki değer birbirinin bit-tersi olacak şekilde seçilmiş (A=1010 ↔ 5=0101, 3=0011 ↔ C=1100, vb.).

Şimdi kuralın "tek bayt yamasıyla çevrilemez" iddiasını sınayalım: saldırgan a'nın yalnız alt baytını 0xC1'den 0x00'a değiştirsin (a artık 0xA300). Yeni sonuç: 0xA300 ^ 0x5C3E:

Sonuç: 0xFF3E — 0xFFFF'e eşit değil. decision_grants fonksiyonu (k.a ^ k.b) == 0xFFFFu kontrolünde false döner: tek baytlık kaba bir yama, "izin"i tetiklemeyi başaramaz. Saldırganın işe yaraması için hem a'nın hem b'nin birbiriyle tutarlı biçimde değiştirilmesi gerekir — bu da tek nokta yerine en az iki bağımsız noktayı aynı anda bulup değiştirmesini gerektirir; "Ölçüm" satırındaki "bağımsız nokta sayısı > 1" ifadesinin sayısal karşılığı tam olarak budur.

Bu haftanın demosunda aynı fikir obfuscated.cnin Decision{a,b}sinde: saf int result (0/1) ile karşılaştırmalı olarak görelim — bellek dökümünde hangisi anlamı hemen ele veriyor?

Normal, zor (GRANTED/DENIED dönüşümlü) ve iki uç durum örneğini deneyin.

KURAL K-09 — Değişken bölme, birleştirme ve dizi yeniden yapılandırma¶

Neyi korur? Hassas bir değişkenin bellekteki tanınabilir izini. "32 baytlık bir blok = bir AES anahtarı" gibi kalıplar saldırgana yol gösterir. Nasıl? Bir değişken iki parçaya bölünür (ör. bir 32-bit değeri iki 16-bit paydan hesaplamak), birden çok değişken tek bir söze birleştirilir, diziler yeniden düzenlenir; tamponların boyutu, sırası ve yerleşimi değiştirilir, araya sahte ayırmalar konur ve kullanımdan sonra rastgele değerle doldurulur.

Maliyet: düşük–orta. Sınır: yalnız statik/kalıp analizini yavaşlatır. Ölçüm: hassas tamponun bellek kalıbından tanınma süresi.

İşlenmiş örnek: 32 bitlik bir değeri bölüp geri birleştirelim. Saklamak istediğimiz değer 0x1234ABCD (32-bit) olsun. Bunu tek bir 4 baytlık blok olarak tutmak yerine, iki ayrı 16-bit **parça**ya bölelim:

uint16_t high = 0x1234;   /* upper 16 bits — in a separate variable, perhaps a separate struct */
uint16_t low  = 0xABCD;   /* lower 16 bits — kept somewhere else in the code */

uint32_t value = ((uint32_t)high << 16) | low;   /* re-merged at the moment of use */

Doğrulayalım: high << 16 işlemi 0x1234'ü 16 bit sola kaydırır → 0x12340000. Bunu low = 0x0000ABCD ile OR'larsak: 0x12340000 | 0x0000ABCD = 0x1234ABCD — orijinal değeri tam olarak geri verir.

Bunun neden işe yaradığını bellek tarayan bir araç gözünden düşünelim: böyle bir araç genelde "art arda duran 4 (ya da 16/32) baytlık, yüksek entropili bir blok" arar — bu, bölüm 0'daki entropi tanımının pratikte kullanıldığı yerdir (ör. bir AES anahtarının bellekte "dizi B" gibi görünmesi). high ve low ayrı değişkenlerde, hatta derleyicinin seçimine bağlı olarak bellekte bitişik olmayan adreslerde durabilir; taranan blok artık 4 bayt değil, iki ayrı 2 baytlık parçadır ve aralarında "bu ikisi birleşince bir anahtar oluşturur" bilgisi kodda açıkça yazmaz, yalnız birleştirme ifadesinde gizlidir.

7. Program bütünü düzeyinde kurallar¶

KURAL K-10 — Sanallaştırma tabanlı gizleme (kavram)¶

Neyi korur? Bir fonksiyonun makine kodunun kendisini. Nasıl? Fonksiyon, gerçek makine komutları yerine özel bir sanal makinenin (VM) bayt koduna çevrilir; binary dosyaya bu bayt kodu ile onu yorumlayan küçük bir yorumlayıcı gömülür. Saldırgan artık tanıdık makine kodunu değil, önce çözmesi gereken özel bir komut kümesini görür.

Maliyet: yüksek — hem başarım (yorumlanan kod yavaştır) hem bakım açısından pahalıdır; bu yüzden yalnız en kritik, küçük ve sık değişmeyen fonksiyonlara uygulanır. Sınır: VM'in kendisi bir kez çözülürse bütün korunan fonksiyonlar açılabilir; ve tek bir VM tasarımı bütün kopyalarda aynıysa çeşitlendirme yoktur. Ölçüm: korunan fonksiyonun boyut/hız maliyeti; bir analistin VM komut kümesini çözme süresi. 14. haftada Tigress'in Virtualize dönüşümüyle bunu kavramsal olarak göreceğiz.

İşlenmiş örnek: küçük, kavramsal bir bayt kodu ve yorumlayıcısı. Gerçek sanallaştırma araçları çok daha karmaşıktır; ama mekanizmayı görmek için üç komutluk minik bir "sanal makine" kuralım — amacımız 5 + 7 işlemini gerçek bir toplama komutu olmadan hesaplamak:

enum { OP_PUSH, OP_ADD, OP_RET };
uint8_t bytecode[] = { OP_PUSH, 5, OP_PUSH, 7, OP_ADD, OP_RET };   /* bytecode for 'compute 5 + 7' */

int interpret(const uint8_t *bytecode, size_t n) {
    int stack[8], sp = 0, pc = 0;
    for (;;) {
        switch (bytecode[pc++]) {
        case OP_PUSH: stack[sp++] = bytecode[pc++]; break;
        case OP_ADD:  { int b = stack[--sp], a = stack[--sp]; stack[sp++] = a + b; } break;
        case OP_RET:  return stack[--sp];
        }
    }
}

Elle izleyelim (yığın sp, program sayacı pc):

Sonuç 12 = 5 + 7 — doğru. Şimdi bir tersine mühendisin ne gördüğüne bakalım: binary dosyada interpret diye genel amaçlı, switch'li bir döngü ve ayrı bir yerde {0, 5, 0, 7, 1, 2} gibi bir bayt dizisi görür. "5 artı 7" diye bir komut hiçbir yerde yoktur; toplama, bu altı baytın interpret'in belirli bir sırayla işlenmesiyle ortaya çıkan bir yan etkidir. Analist gerçek mantığı anlamak için önce interpret'in kendisini (VM'i) çözmek, sonra her bayt kodu sürümünü ayrı ayrı yorumlamak zorundadır — K-10'un "maliyet yüksek ama VM bir kez çözülürse hepsi açılır" sınırının kaynağı da tam burada görülür: interpret fonksiyonunun kendisi tek bir yerdir, o çözülünce bütün bayt kodu dizileri okunabilir hâle gelir.

Maliyeti kabaca büyüklük mertebesiyle görelim. Yukarıdaki interpret fonksiyonunu bir daha inceleyin: 5 + 7 gibi tek bir toplama işlemi için gerçek makine kodunda bir komut (add) yeterliyken, yorumlayıcı sürümde her adım şunları gerektirir: bayt kodunu oku (kod[pc++]), switch ile hangi işlem olduğuna karar ver, yığından değer(ler) çek, işlemi yap, sonucu yığına koy, program sayacını ilerlet. Tek bir "toplama" en az 5-6 gerçek makine komutuna karşılık gelir; toplama döngü içinde tekrar tekrar çağrılıyorsa bu çarpan da tekrarlanır. Literatürde bayt kodu yorumlamanın 10 kata kadar (bazı tasarımlarda daha fazla) yavaşlamaya yol açması sık karşılaşılan bir büyüklük mertebesidir — kesin oran VM'in tasarımına (kaç yığın işlemi, kaç dolaylı erişim) bağlıdır ve projenizde ölçülmelidir, burada verilen sayı yalnız "neden bu kadar pahalı" sorusuna kaba bir cevaptır. Bu yüzden K-10'un "Maliyet: yüksek" satırı yalnız retorik değildir; her komutun 5-10 katına çıkması demektir ve bu yüzden yalnız saniyede binlerce kez çağrılmayan, küçük, kritik fonksiyonlara (ör. bir lisans anahtarı türetme adımı, saniyede bir kez çağrılan bir denetim) uygulanır — bir görüntü işleme döngüsüne ya da sık çağrılan bir yardımcı fonksiyona uygulanmaz.

KURAL K-11 — Derleyici tabanlı gizleme (O-LLVM ailesi)¶

Neyi korur? Yukarıdaki kontrol/veri kurallarını, el ile değil derleyici geçişleriyle uygulayarak. Nasıl? LLVM tabanlı gizleyiciler (Obfuscator-LLVM ve türevleri) düzleştirme, sahte kontrol akışı ve komut değiştirme geçişlerini derleme sırasında otomatik uygular. Avantajı: kaynak kodu okunur kalır, koruma bir derleme seçeneğidir; her sürümde farklı tohum (seed) vererek çeşitlendirme kolaydır. Maliyet: orta; başarım etkisi seçilen geçişlere bağlıdır. Sınır: iyi bilinen geçişlerin ürettiği kalıplar tanınabilir; araç sürümüyle güncel kalmak gerekir. Ölçüm: aynı geçişlerin farklı tohumlarla ürettiği binary dosyalar arasındaki fark (çeşitlendirme ölçütü, bölüm 5).

Kökeni: Obfuscator-LLVM, Junod, Rinaldini, Wehrli ve Michielin tarafından 2015'te "Obfuscator-LLVM — Software Protection for the Masses" başlığıyla IEEE/ACM SPRO (Software Protection) çalıştayında sunulmuştur: LLVM'in dil-bağımsız ara temsili (IR) üzerinde çalışan geçişler (düzleştirme, sahte kontrol akışı, komut değiştirme) olarak uygulanır — bu bölümdeki K-01/K-02/K-04 kurallarının otomatikleştirilmiş, derleyici düzeyindeki hâli budur.

Kavramsal örnek: aynı kaynak, iki tohum, iki farklı binary. Aynı grant_access kaynağını bir O-LLVM tabanlı derleyiciyle iki kez, yalnız --Seed değerini değiştirerek derlediğimizi düşünelim. Kaynak kod birebir aynıdır; değişen şeyler derleyicinin rastgele seçimleridir:

Ne değişmez? grant_access("CEN429-OK") çağrıldığında iki binary de aynı sonucu döner — kaynak kod ve davranış birebir aynıdır, yalnız derlenmiş şekil farklıdır. Bu, bölüm 8'de "çeşitlendirme" başlığı altında göreceğimiz tam olgudur; O-LLVM bunu elle yapmak yerine derleme sırasında otomatik üretir.

KURAL K-12 — Kendini değiştiren kod ve dinamik şifreleme (kavram, dikkatli)¶

Neyi korur? En hassas kod bölümlerini, binary dosyada şifreli tutarak. Nasıl? Bölüm binary dosyada şifreli durur; yalnız çalışacağı an belleğe çözülür, çalışır ve sonra yeniden şifrelenir ya da silinir. Maliyet: yüksek ve risklidir: modern işletim sistemlerinin bellek korumalarıyla (DEP/NX, yazılabilir-ve-çalıştırılabilir sayfa ayrımı, W^X) doğrudan çatışır; yanlış uygulanırsa hem çöker hem de yeni bir açık yaratır. Sınır: çalışırken bir noktada kod bellekte açıktır; bir bellek dökümü onu yakalayabilir. Ölçüm: açık pencerenin ne kadar kısa olduğu.

İşlenmiş örnek: çözme-çalıştırma-yeniden şifreleme döngüsünün zaman çizelgesi. Kavramsal akış şu adımlardan oluşur:

1. t₀: Fonksiyon çağrılır; ilgili bellek sayfası hâlâ şifrelidir.
2. t₁: Sayfa çözülür (bellekte açık hâle gelir), sayfa izinleri geçici olarak yazılabilir+çalıştırılabilir yapılır.
3. t₂: Kod çalışır (asıl iş burada olur) — bu, saldırganın bir bellek dökümü alması hâlinde kodu açık yakalayabileceği penceredir.
4. t₃: İş biter; sayfa yeniden şifrelenir ve izinler eski hâline (yalnız çalıştırılabilir, yazılamaz) döner.

Kritik nokta: t₃ adımı her çıkış yolunda çalışmalıdır — yalnız başarılı dönüşte değil, bir hata, istisna (exception) ya da erken return durumunda da. Aksi hâlde kod bellekte süresiz açık kalır ve "açık pencere" tanımdaki gibi kısa değil, sonsuz olur.

Bölüm 5–7 özet tablosu: on iki kural bir bakışta¶

Zayıf noktalardan biri, bu kadar çok kuralı bir arada tutmaktır. Aşağıdaki tablo bir kopyala-yapıştır listesi değil, bir hatırlatıcıdır; her satırın arkasında yukarıda tam açıklaması, işlenmiş örneği ve sık hata/kural kutusu bulunur:

Sınav ya da S9 hazırlığında "hangi kuralı ne zaman seçerim?" sorusuna hızlı cevap için: düşük değerli, sık değişen kod için üstteki satırlar (K-01, K-02, K-05, K-07 gibi düşük maliyetliler); yüksek değerli, az değişen, küçük kod bölümleri için alttaki satırlar (K-10, K-12) tercih edilir — tam olarak bölüm 9'daki "Karar kuralı"nın söylediği şey.

8. Çeşitlendirme: tek kırık her yeri açmasın¶

1. bölümdeki "Kural 2 — otomasyonu kır" burada somutlaşır. Bir saldırgan bir kopyayı kırdığında, ürettiği yamayı ya da betiği bütün kullanıcılara dağıtabiliyorsa, bir kırık her yeri açar. Çeşitlendirme (diversification), aynı kaynaktan farklı ama davranışça eş binary dosyalar üretmektir; böylece bir kopyaya karşı geliştirilen otomatik saldırı diğerlerinde çalışmaz.

Kökeni ve tarihçesi: biyolojiden ödünç bir fikir¶

Çeşitlendirmenin güvenlik fikri işletim sistemleri araştırmasından gelir, doğrudan biyolojiden esinlenerek:

• 1993 — Fred Cohen, "Operating System Protection Through Program Evolution" (Computers & Security, Cilt 12, Sayı 6) makalesinde, korunacak sistemi kendini zaman içinde değiştiren bir yazılımla donatma fikrini önerir: bugünün programı yarınkinden farklı olsun ki saldırganın bulduğu bir zayıflık kalıcı olmasın. Bu, aşağıdaki zamanda çeşitlendirme fikrinin köküdür.
• 1997 — Stephanie Forrest, Anil Somayaji ve David Ackley, "Building Diverse Computer Systems" (6. Hot Topics in Operating Systems — HotOS — çalıştayı) makalesinde, biyolojik popülasyonlardaki çeşitliliğin neden sağlamlık kattığını bilgisayar sistemlerine taşırlar: davranışı değiştirmeyen rastgeleleştirilmiş dönüşümlerin (ör. yığın çerçevesinin boyutunu rastgele değiştirmek) basit bir arabellek taşması saldırısını bile bozabileceğini gösterirler. Bu, aşağıdaki uzayda çeşitlendirme fikrinin köküdür.

İki makale de aynı gözlemi paylaşır: doğada çeşitlilik tek bir zayıflığın tüm popülasyonu yok etmesini önler (bir hastalık türün tamamını değil, yalnız dirençsiz bireyleri öldürür); yazılımda da aynı fikir tek bir kırığın tüm kopyaları açmasını önler. 14. haftada Tigress'in --Seed seçeneği bu otuz yıllık fikri tek bir komut satırı bayrağına indirger.

• Uzayda çeşitlendirme: her yapı (build) ya da her dağıtım farklı bir tohumla gizlenir; opak yüklemler, sahte bloklar ve durum değerleri kopyadan kopyaya değişir.
• Zamanda çeşitlendirme: her sürüm yeni bir düzenle gelir; eski sürüme karşı bulunan saldırı yeni sürümde bozulur. Bu, anahtar/sürüm yenileme politikanızla (10. hafta) birlikte çalışır.

Çeşitlendirme, gizlemenin gücünü artırmaz — bir kopyayı kırmak yine mümkündür — ama ölçeklenmesini engeller. On dördüncü haftada Tigress'in RandomFuns, --Seed ve dönüşüm birleştirme özellikleriyle bunu araçla üreteceğiz.

İşlenmiş örnek: fark oranını sayısal hesaplayalım. Yukarıdaki ölçütü somut bir sayıya dökelim. Diyelim korunan grant_access fonksiyonunun düzleştirilmiş hâli binary dosyada 512 bayt yer kaplıyor. İki farklı tohumla üretilen binary dosyalarda bu fonksiyonu bayt bayt karşılaştırdığımızda 340 baytın farklı çıktığını ölçtük (varsayımsal ama gerçekçi bir demo sonucu):

fark_orani = degisen_bayt_sayisi / toplam_bayt_sayisi × 100
           = 340 / 512 × 100
           ≈ 66,4 %

Yorum: iki kopyanın %66,4'ü farklı; yalnız %33,6'sı ortak kalmış (muhtemelen fonksiyon girişi/çıkışı gibi derleyicinin değiştiremeyeceği sabit parçalar). Bir saldırgan Kopya A'da bulduğu bir bayt yamasını (ör. "şu ofsete şu değeri yaz, denetim hep izin versin") doğrudan Kopya B'ye uygularsa, o ofsette artık farklı bir komut bulunduğu için yama ya işe yaramaz ya da programı çökertir. Bu, 1. bölümdeki "Kural 2 — otomasyonu kır"ın sayısal kanıtıdır.

Bu haftanın gerçek ölçümü (varsayımsal örnekten ayrı). demo.sh/demo.ps1 çalıştırıldığında (02-diversification), access_seed1001 ve access_seed2002 ikilileri tüm dosya düzeyinde karşılaştırıldığında (Linux cmp -l) ~29 bayt farklı çıktı; grant_access fonksiyonunun kendisi her iki tohumda da 50 komuttan oluşuyor — aynı sayıda komut, ama MASKe bağlı farklı sabitlerle kodlanmış. Yukarıdaki 512/340 bayt örneği yalnız kavramsal bir gösterimdir (tek bir fonksiyonun bayt düzeyinde farkını izole ölçmedik); gerçek sayı burada, ikili dosyanın tamamı içindir.

Çeşitlendirme kararı, RASP (6. hafta) ve anahtar/sürüm yenileme (10. hafta) ile birlikte düşünülür: bir kopya kırılıp bir bypass betiği yayılsa bile, hem o betik diğer kopyalarda çalışmaz (çeşitlendirme) hem de bir sonraki sürümde eski betik geçersiz kalır (zamanda çeşitlendirme + anahtar yenileme).

Bu haftanın gerçek 02-diversification demosunda aynı kaynak (diversified.c), iki farklı SEED ile derlenmiş: MASK ve dağıtıcının C0..C3 durumları tohuma göre değişir, ama grant_access her iki tohumda da AYNI GRANTED/DENIED cevabını verir. Aşağıda bunu 10 jetonla doğrulayalım:

Normal, zor (aynı uzunlukta, farklı içerik) ve iki uç durum örneğini deneyin.

9. Gizlemenin ölçülmesi¶

Bir koruma kararını savunmak için onu ölçmek gerekir. Collberg'in çerçevesi gizlemeyi dört boyutta değerlendirir; bu dört ölçüt aynı zamanda 13. haftadaki saldırı potansiyeli puanlamasının ("gereken süre", "gereken uzmanlık") temelidir.

Bu dört ölçüt bir ödünleşimdir: gücü ve dayanıklılığı artırdıkça maliyet artar, gizlilik çoğu zaman azalır (daha karmaşık kod daha çok dikkat çeker). İyi bir mühendislik kararı, korunan varlığın değerine göre bu dördü dengeler.

İşlenmiş örnek: dört ölçütü grant_access üzerinde sayılarla dolduralım¶

Bölüm 4'te tanıdığımız gerçek demo ölçümlerini (27 → 49 komut, 4 → 9 dal/çağrı) burada dört ölçüte dağıtalım:

Güç (potency). Basit bir yaklaşık ölçüt olarak McCabe'in çevrimsel karmaşıklık fikrini kabaca kullanalım: tek girişli/çıkışlı bir fonksiyon için karmaşıklık ≈ dal_sayısı + 1.

Öncesi : 4 dal/çağrı + 1 = 5
Sonrası: 9 dal/çağrı + 1 = 10
Artış  : (10 − 5) / 5 × 100 = %100

Karmaşıklık 5'ten 10'a, yani %100 artmış (tam iki katına çıkmış): bir insan analistin fonksiyonu elle çizip anlaması artık iki katı kadar "yol" barındırıyor.

Maliyet (cost). Komut sayısındaki artışı aynı şekilde hesaplayalım:

(49 − 27) / 27 × 100 ≈ %81,5

Yani bu tek kuralın (K-04 + K-01 + K-05) uygulanması, fonksiyonu %81,5 daha büyük ve muhtemelen biraz daha yavaş yapmıştır — bu, bölüm 4'teki koruma kuralı şablonunun "Maliyet" satırına yazılacak somut sayıdır.

Bu iki gerçek sayıyı (statik ölçüm) ve ayrıca dinamik maliyeti (her çağrıda kaç adım gerçekten çalışıyor, 10 jeton üzerinden) aşağıda görelim:

Normal, zor (dağıtıcı çoğunlukla tam dolaşıyor) ve iki uç durum (en ucuz/en pahalı yol) örneğini deneyin.

Dayanıklılık (resilience) ve gizlilik (stealth). Bu ikisi, yalnız komut/dal sayarak ölçülemez; dayanıklılık için gerçek bir deobfuscation aracı çalıştırıp (bölüm 10) "geri açma" süresini/başarısını ölçmek, gizlilik için gizlenmiş kodun istatistiksel olarak "normal" koddan ayrılıp ayrılmadığına (ör. anormal derecede yüksek dal yoğunluğu dikkat çeker mi) bakmak gerekir. Bu haftanın demosu yalnız güç ve maliyeti doğrudan ölçer; dayanıklılık ölçümü bir sonraki bölümün konusudur.

Karar kuralı (S9'a yazılır):

• Varlık değeri düşük → hafif, ucuz gizleme (K-01, K-02, K-07) yeter.
• Varlık değeri yüksek → katmanlı koruma (K-04 + K-05 + K-08 + çeşitlendirme); maliyeti kabul edilir.
• Her katman için güç ve dayanıklılık kazancı, boyut/hız maliyetine karşı ölçülür ve yazılır.

İşlenmiş örnek: karar kuralını iki farklı varlığa uygulayalım. Aynı uygulamada iki farklı kod bölümü olsun:

• Varlık A — bir "hoş geldiniz" ekranının metnini seçen yardımcı fonksiyon. Değeri düşüktür (sızsa bile büyük bir kayıp doğurmaz). Karar: yalnız K-07 (dize kodlama) yeterlidir; K-04 gibi pahalı bir dönüşüm gereksizdir — bölüm 9'un "maliyet" ölçütü burada "gereksiz maliyet eklemeyin" yönünde de çalışır.
• Varlık B — lisans anahtarının doğrulandığı lisans_dogrula fonksiyonu. Değeri yüksektir (bölüm 1'deki sayısal örnekte yıllık 100.000 TL'lik bir gelire bağlıydı). Karar: K-04 + K-01 + K-05 + K-08 + çeşitlendirme birlikte uygulanır; toplam maliyet (bölüm 9'da ölçtüğümüz gibi %81,5 komut artışı) kabul edilir çünkü korunan varlığın değeri bunu haklı çıkarır.

Bu karşılaştırma, "her fonksiyona aynı gizleme düzeyini uygulamak" yaklaşımının hem gereksiz maliyetli hem de yetersiz koruyucu olabileceğini gösterir: Varlık A'ya K-04 uygulamak boşuna performans kaybettirir; Varlık B'ye yalnız K-07 uygulamak ise CFG'yi tamamen açık bırakır. S9'unuzda her kod bölümü için ayrı bir karar verin.

10. Deobfuscation: karşı tarafın araçları ve dayanıklılık kuralı¶

Dayanıklılığı doğru ölçmek için saldırganın otomatik araçlarını kavramsal olarak bilmek gerekir. Bunları savunmayı sınamak için öğreniriz:

• Sembolik / eşzamanlı yürütme (KLEE gibi): program yolları matematiksel kısıtlar olarak çözülür; opak yüklemler ve düzleştirme bu yolla geri açılabilir. Dayanıklılık kuralı: çözücüyü zorlamak için opak yüklemleri, çözmesi pahalı (ör. çarpanlara ayırmaya ya da karma değerlere dayalı) yapılara bağla ve durum uzayını büyüt; ama maliyeti ölç.
• İfade sadeleştirme (MBA çözücüler): aritmetik kodlamayı (K-02) açar. Kural: aritmetik kodlamayı tek başına bir sır katmanı sayma; kontrol akışıyla birleştir.
• Kalıp tanıma: bilinen kütüphane/geçiş kalıplarını tanır. Kural: çeşitlendir; tek bir opak yüklem kalıbına ya da tek bir VM tasarımına bağlı kalma.

Banescu ve arkadaşlarının çalışması (Tigress + KLEE) tam da bunu yapar: hangi dönüşümlerin sembolik yürütmeye ne kadar dayandığını ölçer. Ders için çıkarım nettir: dayanıklılık bir iddia değil, ölçülen bir niceliktir. Bir korumanın "güçlü" olduğunu söylemek yerine, "şu araca karşı şu kadar dayandı" demek gerekir.

Sembolik yürütme K-01'deki opak yüklemi nasıl kırar? Adım adım¶

Bölüm 5'teki opaque_true(x) = ((x*(x+1)) & 1) == 0 yüklemine dönelim; o bölümdeki uyarı kutusu bunun "klasik bir kalıp, modern araçların kütüphanelerinde tanınır" olduğunu söylemişti. Şimdi neden böyle olduğunu görelim.

Bir sembolik yürütme aracı (KLEE gibi), programı somut değerlerle (x = 5 gibi) değil, x'i bilinmeyen bir sembol olarak tutup çalıştırır. if (opaque_true(x)) satırına geldiğinde, aracın sorması gereken soru şudur:

"x'in her değeri için ((x*(x+1)) & 1) == 0 doğru mudur, yoksa bunu yanlış yapan bir x var mıdır?"

Bu soruyu bir kısıt çözücüye (constraint solver / SMT solver) devreder. Çözücü, x'i tek ve çift olmak üzere iki duruma ayırarak (ki bu, tam sayı aritmetiğinde standart bir çözüm stratejisidir) hızlıca kanıtlar:

• x çiftse: x = 2k → x*(x+1) = 2k*(2k+1) → ifade 2'nin katı → & 1 = 0. ✅
• x tekse: x = 2k+1 → x+1 = 2k+2 = 2(k+1) çift → x*(x+1) yine 2'nin katı → & 1 = 0. ✅

İki durumda da sonuç 0; çözücü saniyeler içinde "bu yüklem her zaman doğru, ikinci dal (sahte) hiçbir zaman çalışmaz" sonucuna ulaşır ve ölü dalı otomatik eler. Bu yüzden K-01'deki uyarı kutusu, bu belirli özdeşliği tek başına yeterli görmüyor, 14. haftada tohumla çeşitlendirilmiş ve çözücüyü daha çok yoran (ör. çarpanlara ayırmaya ya da bir karma fonksiyonun tersini almaya dayanan) yüklemler öneriyordu — şimdi bu önerinin nedenini de görmüş olduk.

Aynı fikri bu haftanın gerçek obfuscated.csindeki opaque_zeroya uygulayalım — değerlendiricinin gözünden, periyodik kanıttan sabit katlamaya (constant folding) kadar:

Normal, zor ve iki uç durum (periyodu doğrudan gösteren sıralı çift/tek dahil) örneğini deneyin.

MBA sadeleştiriciler K-02'yi nasıl açar?¶

K-02'deki (a ^ b) + 2·(a & b) = a + b gibi bir ifade, insana karmaşık görünse de sonlu bir doğruluk tablosu (4 bitlik her a,b çifti için 2⁴ × 2⁴ = 256 satır, 8 bitlik için 65.536 satır) ile mekanik olarak sınanabilir. arybo/msynth gibi araçlar tam olarak bunu yapar: ifadeyi küçük bit genişliklerinde kaba kuvvetle dener, aynı doğruluk tablosunu veren en kısa standart ifadeyi (a+b) bulur ve ikisinin eşdeğer olduğunu rapor eder. Bu yüzden K-02'nin sınır satırı "tek başına zayıftır" diyordu: aritmetik kodlama tek katman olarak kalırsa, bu sadeleştirme adımı onu birkaç saniyede geri açabilir; ancak sonucu K-04'ün düzleştirilmiş switch'inin içine gömerseniz, sadeleştirici önce hangi ifadenin sadeleştirileceğini bulmak için düzleştirmeyi de çözmek zorunda kalır — iki zayıf katman, birlikte tek katmandan daha güçlüdür.

Kalıp tanıma K-04/K-11'i nasıl hedefler?¶

Bir "kalıp tanıma" aracı, binary dosyayı tarayıp bilinen yapısal imzaları arar: tek bir döngü içinde büyük bir switch, ardışık olmayan ama sabit bir kümeden gelen durum değerleri, default dalından çıkan bir hata yolu — tam olarak K-04'ün şablonu. O-LLVM gibi popüler araçların ürettiği düzleştirme şekli de zamanla "tanınan" bir imza hâline gelmiştir (bir yazılımın hangi gizleme aracıyla derlendiğini tahmin eden akademik çalışmalar bile vardır). Bu, K-11'in sınır satırındaki "iyi bilinen geçişlerin ürettiği kalıplar tanınabilir" uyarısının kaynağıdır.

Dayanıklılık ile maliyet aynı şey değildir — karıştırmayın¶

Bölüm 9'da "dayanıklılık" ve "maliyet"i iki ayrı ölçüt olarak tanımlamıştık; bu bölümden sonra aradaki farkı daha net görebiliriz. Maliyet, korumayı uygulamanın bize ne kadara mal olduğudur (komut sayısı, hız, bellek) — bunu kendi derleme sürecimizde doğrudan ölçeriz (bölüm 4 ve 9'daki objdump örnekleri). Dayanıklılık ise korumanın saldırganın aracına karşı ne kadar dayandığıdır — bunu ölçmek için saldırganın aracını (sembolik yürütme, MBA sadeleştirici, kalıp tanıma) gerçekten çalıştırıp sonucu gözlemlemek gerekir; yalnız "çok komut ekledim" demek dayanıklılığı kanıtlamaz. Bölüm 9'daki "%82 maliyet artışı" örneğini hatırlayın: bu sayı tek başına, K-04'ün sembolik yürütmeye karşı ne kadar dayandığını söylemez — o soru ancak bu bölümdeki gibi bir deobfuscation aracı gerçekten denenerek cevaplanabilir. S9'unuzda bu iki ölçütü karıştırmadan, ayrı ayrı raporlayın.

11. Katmanlı savunmada gizlemenin yeri¶

Gizleme, tek başına bir kale değil, derinlemesine savunmanın bir katmanıdır. Diğer haftalarla ilişkisi:

Tek bir örnek üzerinden bütün dönemi bağlayalım: bir mobil ödeme uygulamasının lisans denetimi¶

Bilgi bağlarını somutlaştırmak için, dönem boyunca aynı hayali işlevi — bir mobil ödeme uygulamasının lisans_dogrula fonksiyonunu — farklı haftaların gözünden izleyelim:

• 1. hafta: Tehdit modeli çıkarılır; lisans_dogrula MATE saldırganına (uygulamayı elinde tutan kullanıcı) karşı korunması gereken bir varlık olarak işaretlenir.
• 3. hafta: Fonksiyonun kullandığı anahtarlar AEAD ile şifrelenir, rastgele sayılar CSPRNG'den gelir; ama bu, verinin saklanma güvenliğidir, kodun okunma güvenliği değildir.
• 4. hafta: İlk gizleme adımları atılır: semboller görünmez yapılır, temel bir düzleştirme denenir.
• 6. hafta: RASP eklenir; bir hata ayıklayıcının bağlı olup olmadığı çalışma anında denetlenir.
• 9. hafta (bu hafta): K-01–K-12 uygulanır: kontrol akışı düzleştirilir ve güçlendirilir (K-01, K-03, K-05), veriler kodlanır (K-07, K-08, K-09), çeşitlendirme eklenir (bölüm 8), etkinlik ölçülür (bölüm 9).
• 10. hafta: Fonksiyonun kullandığı anahtarların yaşam döngüsü (üretim, dağıtım, yenileme) PKI ile yönetilir — gizleme anahtarı saklamaz, yalnız çevresini zorlaştırır (bölüm 3'teki kural).
• 11. hafta: En kritik anahtar türetme adımı whitebox kriptografi ile korunur — K-10'un (sanallaştırma) "yalnız en kritik küçük fonksiyona uygula" ilkesinin kriptografideki karşılığı.
• 12–13. hafta: Bağımsız bir değerlendirici, bütün bu katmanları saldırı potansiyeli çerçevesiyle puanlar; bölüm 4'teki koruma kuralı şablonundaki "Ölçüm" satırları burada kanıt olarak sunulur.
• 14. hafta: Bütün bu el ile yapılan işler Tigress ile otomatikleştirilir; aynı kaynak, her sürümde farklı tohumla, tek bir komutla yeniden üretilir.

Bu zincir, tek bir fonksiyonun dönem boyunca hangi haftalarda hangi farklı tehdide karşı korunduğunu gösterir: hiçbir hafta diğerinin yerine geçmez, her biri bir öncekinin bıraktığı boşluğu kapatır.

"Geciktirme süresi" pratikte neye bakılarak tahmin edilir?¶

12–13. haftada göreceğimiz saldırı potansiyeli değerlendirmeleri, genel olarak bir saldırının kaç faktörle zorlaştığına bakar; bu hafta öğrendiğimiz kurallar bu faktörleri şöyle etkiler (kesin puanlar sertifikasyon şemasına göre değişir, burada yalnız yönü gösteriyoruz):

Bu beş soru, sertifikasyon dünyasında yaygın kullanılan saldırı potansiyeli değerlendirme yaklaşımlarının ortak iskeletidir. Örneğin yalnız dize gizleme (K-07) uygularsanız, gereken zamanı birkaç dakika artırırsınız ama gereken uzmanlığı neredeyse hiç değiştirmezsiniz (herkes strings yerine bir tersine derleyicide dizeyi arayabilir). Kontrol akışı düzleştirme + opak yüklem + çeşitlendirme birlikte uygulanırsa, hem gereken zaman (CFG'yi elle çözmek saatler alır) hem gereken uzmanlık (jenerik bir araç yetmez, özel bir betik/analiz yazılması gerekir) hem de fırsat penceresi (her kopya farklı olduğu için bir betik yeniden yazılmalı) birlikte yükselir — bu, tek bir kuralın değil, katmanların neden değerlendirmede daha yüksek puan aldığının teknik açıklamasıdır.

Bu bölümün kısa özeti¶

Katmanlı savunmada gizlemenin yeri şu üç cümleyle özetlenebilir: (1) gizleme, bellek güvenliğinin (4. hafta), kriptografinin (3. hafta) ve RASP'ın (6. hafta) yerine geçmez, onların etrafını zorlaştırır; (2) her katman, saldırı potansiyeli değerlendirmesinde (12–13. hafta) ayrı bir "geciktirme" olarak sayılır, tek başına hiçbiri yeterli değildir; (3) bir sonraki bölümde (S9) yazacağınız her koruma satırı, bu tabloya ve bölüm 4'teki şablona geri bağlanabilmelidir — "bu koruma hangi katmana ait, hangi diğer katmanla birlikte çalışıyor" sorusuna cevap veremiyorsanız, o koruma muhtemelen izole ve yetersiz kalmıştır.

12. Dönem projesi: bu hafta (S9 — ileri sağlamlaştırma)¶

Vize sonrası projenizin S9 bölümünü ileri düzeye taşıyın:

1. Koruma tablosu: En kritik iki–üç kod bölümü için (ör. lisans/lisanslama, anahtar türetme, bütünlük denetimi)
2. bölümdeki "koruma kuralı" şablonunu doldurun: neyi korur, hangi tehdide karşı, nasıl, maliyet, sınır, ölçüm.
3. Ölçüm: En az bir teknik için gizleme öncesi/sonrası bir ölçüt verin (ör. strings çıktısındaki hassas dize sayısı; CFG düğüm sayısı; binary boyut ve bir işlemin süresi).
4. Çeşitlendirme kararı: Çeşitlendirme uygulayacak mısınız? Uygulamayacaksanız neden (gerekçe de bir yanıttır).
5. Sınır ve kalan risk: Her koruma için neyi korumadığını açıkça yazın. "Bu dize gizleme anahtarı korumaz; anahtar için S8'deki whitebox/donanım kullanılır" gibi.

İşlenmiş örnek: bir S9 taslağı baştan sona¶

Bu haftanın bütün örneklerini birleştirip kısa bir S9 taslağı yazalım (kendi projenizde fonksiyon adlarını ve sayıları kendi ölçümünüzle değiştirin):

S9 — İleri sağlamlaştırma (örnek taslak)

1) Koruma tablosu
   KURAL: lisans_dogrula fonksiyonuna K-04 (düzleştirme) + K-01 (opak yüklem) + K-05 (rastgele çıkış)
     Neyi korur?        : lisans anahtarının doğrulama sırası
     Hangi tehdide karşı?: statik CFG okuma, tek-bayt yama
     Nasıl?             : switch dağıtıcı + x*(x+1) tabanlı opak yüklem + öngörülemeyen hata çıkışı
     Maliyet             : komut 27→49 (+%81,5), dal/çağrı 4→9 (+%125) [bu haftanın gerçek grant_access
                            ölçümüyle aynı büyüklükte; lisans_dogrula bu derste ayrıca ölçülmedi]
     Sınır               : sembolik yürütmeye (bölüm 10) karşı zayıf; veri hâlâ K-07 ile korunmalı
     Ölçüm               : objdump çıktısı (ek A), CFG düğüm/kenar sayısı

   KURAL: anahtar dizesine K-07 (dize kodlama)
     Neyi korur?        : ikili dosyadaki hassas dizgeler
     Hangi tehdide karşı?: strings taraması (bölüm 3'teki "ilk 10 dakika" saldırısı)
     Nasıl?             : XOR 0x5A ile kodlama, kullanım anında çözüp memset_s ile silme
     Maliyet             : düşük (birkaç ek komut)
     Sınır               : çözme anahtarı ikilide durur; gerçek anahtar koruması S8/whitebox işidir
     Ölçüm               : strings çıktısında hassas dizge sayısı: 3 → 0

2) Ölçüm: yukarıdaki iki satırda "Ölçüm" alanı doldurulmuş durumda (objdump + strings)

3) Çeşitlendirme kararı: EVET — derleme betiğine rastgele bir --seed parametresi eklendi;
   her sürüm farklı durum sabitleriyle derlenir (bölüm 8, K-11 ile).

4) Sınır ve kalan risk: Bu katman anahtarı korumaz (yalnız statik taramayı geciktirir);
   sembolik yürütmeye karşı ölçülmedi (gelecek iş); anahtarın kalıcı koruması S10/S11'e bırakıldı.

Bu taslak, bölüm 4'teki şablonu bölüm 9'daki dört ölçütle ve bölüm 8'deki çeşitlendirme kararıyla birleştirir; her satırı kendi ölçtüğünüz sayılarla değiştirmeniz beklenir — yukarıdaki sayılar bu haftanın demosundan alınmıştır, kopyalanıp doğrudan başka bir projeye yazılmamalıdır.

13. Kendini sınama¶

14. Kaynaklar ve ileri okuma¶

• Secure Programming Cookbook for C and C++ (Viega & Messier) — Bölüm 12, Anti-Tampering: gizlemenin amacı ve sınırı, birkaç basit tekniği birlikte kullanma önerisi.
• Güvenli programlama teknik kılavuzu (ders kaynağı) — native kod sağlamlaştırma karşı önlemleri: opak döngü, aritmetik/dize/parametre gizleme, opak boolean, sahte işlem/ölü dal, kontrol akışı düzleştirme ve rastgele çıkış.
• C. Collberg, J. Nagra, Surreptitious Software — gizleme taksonomisi ve güç/dayanıklılık/gizlilik/maliyet çerçevesi.
• S. Schrittwieser vd., "Protecting Software through Obfuscation: Can It Keep Pace with Progress in Code Analysis?" (ACM Computing Surveys, 2016) — genel bakış ve deobfuscation araçları.
• S. Banescu vd., Tigress + KLEE ile dönüşüm dayanıklılığının ölçülmesi — 14. haftaya köprü.
• Obfuscator-LLVM (O-LLVM) — derleyici tabanlı gizlemeye örnek.

Hangi kaynağı ne zaman açmalısınız?¶

Bu kaynaklar birbirinin yerine geçmez; her biri farklı bir soruya cevap verir:

• S9'unuzu yazarken "bu tekniğin adı ne, nasıl tanımlanır" sorusuna takılırsanız → teknik kılavuz ve Cookbook Bölüm 12'ye bakın; bu ikisi bu haftanın K-01–K-12 kurallarının doğrudan kaynağıdır.
• "Bu taksonomiyi kim, ne zaman önerdi, neden bu beş aile?" sorusuna → Collberg & Nagra'ya bakın (bölüm 1'deki kısa tarihçenin ayrıntılı hâli).
• "Bu koruma gerçekte ne kadar dayanıklı, hangi araca karşı ölçülür?" sorusuna → Schrittwieser vd. (genel tarama) ve Banescu vd. (Tigress+KLEE ile somut ölçüm) makalelerine bakın; bölüm 10'daki deobfuscation tartışmasının akademik temelidir.
• "Bu kuralları elle değil araçla nasıl uygularım?" sorusuna → Obfuscator-LLVM belgelerine bakın; 14. hafta bunu Tigress üzerinden uygulamalı olarak gösterecek.