Hafta 14 — Tigress 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.

# WSL / Linux (Windows'ta WSL kullanın)
cd week-14/01-kaynaktan-kaynaga
sh tigress-hatti.sh

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¶

• Kaynak kod, derleyici ve ikili dosya — insanın yazdığı program metninin (kaynak kod) bir derleyiciyle makine koduna çevrilip çalıştırılabilir bir ikili dosyaya dönüşmesi (Hafta 9, Ön bilgi). Bu hafta aynı zinciri, kaynağı önce gizleme aracından sonra derleyiciden geçirerek genişletiyoruz.
• Kod gizleme (obfuscation) — davranışı değiştirmeden kodu insan için anlaşılması zor kılan, saldırı maliyetini artıran karşı önlem (Hafta 9, §1). 9. hafta bu kuralları el ile uyguladı; bu hafta aynı kuralların otomatik (Tigress) karşılığını görüyoruz.
• 9. haftanın gizleme kuralları (K-01–K-12) — opak yüklem, aritmetik kodlama, kontrol akışı düzleştirme, dize kodlama, değişken bölme, sanallaştırma gibi el ile uygulanan kurallar (Hafta 9, §5, §6, §7). Bölüm 3'te bunları Tigress'in dönüşümleriyle tek tek eşliyoruz.
• Kontrol akışı grafiği (CFG) — temel blokları düğüm, geçişleri kenar yapan şema (Hafta 9, Ön bilgi). 9. hafta bu grafiği kaynak koddan elle çizip düğüm/kenar saymıştı; bu hafta aynı sayımı objdump ile derlenmiş ikili üzerinde otomatikleştiriyoruz (aşağıdaki "Ön bilgi").
• Sembolik yürütme — program yollarını matematiksel kısıt olarak çözen otomatik analiz yöntemi (ör. KLEE) (Hafta 9, §10). Bu hafta bölüm 7'de dayanıklılığı ölçmenin aracı olarak yeniden kullanıyoruz.
• Çeşitlendirme (diversification) — aynı kaynaktan davranışça eş, yapıca farklı ikili dosyalar üretme fikri (Hafta 9, §8). Bu hafta bölüm 6'da Tigress'in --Seed bayrağıyla otomatikleştiriyoruz.
• CI (sürekli entegrasyon) ve derleme hattı — her kod değişikliğinde otomatik derleme/test adımlarını çalıştıran sistem ve kaynaktan ürüne giden sıralı adımlar (Hafta 4, §13). Bu hafta bölüm 9'da gizleme ve çeşitlendirmeyi de bu hatta birer adım olarak ekliyoruz.
• Sürüm kimliği ve özet (hash) değeri — bir yazılımın tam olarak hangi ikili/kaynak/özet üçlüsüyle değerlendirildiğini/dağıtıldığını gösteren kayıt (Hafta 1, §19). Bu hafta bölüm 9'da bu kayda bir de tohum alanı ekliyoruz, çünkü çeşitlendirme aynı sürüm etiketiyle kasıtlı olarak farklı ikililer üretebiliyor.

Bu haftanın kavram haritası¶

Ön bilgi: Tigress'in kelime dağarcığı¶

Aşağıdaki terimlerin hiçbiri önceki haftalarda öğretilmedi; hepsi bu haftanın aracı olan Tigress'i ve onun komut satırını anlamak için gerekir. Tanımlar birbirinin üstüne kurulacak biçimde sırayla verilir.

Kaynaktan kaynağa dönüşüm, hat ve tohum¶

Bu haftanın konusu kaynaktan kaynağa (source-to-source) gizlemedir: girdi olarak bir C kaynağı alınır, çıktı olarak yine bir C kaynağı üretilir — yalnız gizlenmiş hâliyle; bu yeni kaynak sonra normal derleyicinizle (gcc/clang) derlenir.

Kaynağa uygulanan tek bir gizleme işlemine dönüşüm (transform) denir (örneğin kontrol akışını düzleştirmek). Bir araç genelde birçok dönüşüm sunar; hangisinin hangi fonksiyona uygulanacağına siz karar verirsiniz. Birden çok dönüşümü sırayla uygulamaya dönüşüm hattı (pipeline) denir; her dönüşüm bir öncekinin ürettiği kaynağa uygulanır, bu yüzden sıra önemlidir (bölüm 4).

Dönüşümlerin çoğu bir miktar rastgelelik içerir (ör. bir opak yüklemin hangi sabitle kurulacağı). Bu rastgeleliği yöneten başlangıç sayısına tohum (seed) denir: aynı dönüşüm hattı farklı bir tohumla çalıştırıldığında farklı bir gizlenmiş çıktı üretir — bölüm 6'daki çeşitlendirmenin (bkz. yukarıdaki "Önceki haftalardan gelenler") aracı tam olarak budur.

CLI ve birim testi ile çalışmak¶

Tigress, komutları yazarak çalıştırdığınız bir arayüz olan CLI'dan (Command-Line Interface, komut satırı arayüzü) çalışır: tigress --Transform=... dosya.c gibi bir satır yazarsınız, araç da gizlenmiş kaynağı üretir. Bir fonksiyonun doğru çalıştığını otomatik olarak denetleyen küçük bir teste birim testi (unit test) denir; bu haftanın kuralı, gizlemeden önce yazılmış birim testlerinin gizlemeden sonra da aynen geçmesi gerektiğidir — davranış korunmalıdır (bölüm 2).

Tigress'e özgü iki ayrıntı: ortam bayrağı ve dönüşüm bağımlılığı¶

--Environment bayrağı Tigress'e hedef platformu söyler: işlemci mimarisi, işletim sistemi ve derleyici sürümü (demo betiğinde --Environment=x86_64:Linux:Gcc:11 → 64-bit Intel/AMD mimarisi, Linux, GCC sürüm 11). Bazı dönüşümler (özellikle sanallaştırma ve düşük seviyeli opak yüklem türleri) derleyiciye özgü ayrıntılar bilmek zorundadır; yanlış ortam bilgisiyle üretilen kaynak, hedef makinede derlenemeyebilir ya da yanlış davranabilir.

Bazı dönüşümlerin çalışabilmesi önce başka bir dönüşümün çalışmış olmasına bağlıdır; buna dönüşüm bağımlılığı denir (örnek: AddOpaque'in InitOpaque'e ihtiyaç duyması — bölüm 3'te ayrıntısıyla göreceğiz). Bu, bölüm 4'teki "sıra önemlidir" kuralının yalnız sonucu iyileştirme değil, bazen çalışmanın önkoşulu olduğu anlamına gelir.

Maliyeti ölçmek ve karşılaştırmak: objdump, diff, cmp¶

Bu haftanın demo betiği (tigress-hatti.sh), bir ikili dosyadaki tek bir fonksiyonun ne kadar büyüdüğünü ölçmek için objdump adlı bir araç kullanır: bir ikili dosyayı (.exe, ELF, ...) açıp içindeki assembly komutlarını insan tarafından okunabilir biçimde döken bir komut satırı aracıdır (GNU Binutils paketinin parçası; Linux/WSL'de hazır gelir). objdump -d dosya ("disassemble", tersine çöz) ikili dosyanın kod bölümünü makine kodundan assembly'ye çevirip yazdırır; buradaki komut (instruction) sayısı, bir fonksiyonun assembly çıktısında kaç satır komut olduğudur (her satır mov, cmp, add gibi tek bir işlemci komutu), dal/çağrı (branch/call) sayısı ise bu komutlardan kaçının atlama (j ile başlayan jmp, je, jne, ...) ya da çağrı (call) olduğu — yani programın "başka bir yere gitme" kararı aldığı kaç nokta olduğudur.

Demo betiğindeki ölçüm fonksiyonu (olc()) tam olarak bunu yapar:

objdump -d "$f" | awk '/<erisim_ver>:/{a=1;next} /^$/{a=0} a{n++; if($0 ~ /\t(j|call)/)b++} END{printf "%d komut, %d dal/cagri", n, b}'

Satır satır ne yapıyor: objdump -d bütün ikiliyi assembly'ye çevirir; awk betiği yalnız <erisim_ver>: etiketiyle başlayan bölümü (a=1 bayrağı) okur, boş satıra (fonksiyonun sonu) gelince durur (a=0); okuduğu her satırı n sayacına ekler, satırda sekme sonrası j... ya da call görürse b sayacını da artırır. Sonuç: o fonksiyona ait kaç komut, kaçının dal/çağrı olduğu.

Bu sayı, 9. haftada elle ölçtüğümüz temel blok ve CFG düğüm/kenar sayımının otomatik ve daha ince taneli karşılığıdır: 9. hafta bu grafiği kaynak koddan elle çizip düğüm/kenar saymıştı (Hafta 9, Ön bilgi — denetim fonksiyonu örneği: 3 düğüm, 2 kenar); burada aynı fikri derlenmiş ikili üzerinde, bir araçla otomatik sayıyoruz. İkisi de aynı soruyu sorar: "bu fonksiyonu okumak/analiz etmek ne kadar iş?"

Ölçtüğümüz sayıları (temiz/gizli sürüm) karşılaştırmanın iki farklı yolu vardır: cmp, iki dosyayı bayt bayt karşılaştırır, yalnız "aynı mı, farklı mı" (ve isteğe bağlı olarak ilk farkın konumunu) söyler — bütün dosya için tek bir sonuç verir. diff ise iki metin/kaynak dosyasını satır satır karşılaştırır, hangi satırların eklendiğini/çıkarıldığını/değiştiğini ayrıntılı listeler; assembly çıktısı gibi satırlara ayrılmış metinlerde cmp'den daha bilgilendiricidir. Bölüm 6'daki "önce cmp ile kaba kontrol, sonra objdump+diff ile hedefe odaklı doğrulama" akışı, bu iki aracın birbirini tamamladığı fikrine dayanır: cmp hızlı ama kaba, diff yavaş ama ayrıntılıdır.

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

Dokuzuncu haftadaki sözlüğe (Obfuscation, Reverse engineering, Decompiler, ...) bu hafta şunlar eklenir; Tigress'in resmî belgelerinde ve komut satırında bu İngilizce adlarla karşılaşacaksınız:

1. Kaynaktan kaynağa gizleme nedir?¶

Dokuzuncu haftada gizleme kurallarını el ile uyguladık: opak yüklem, düzleştirme, dize kodlama, sahte dal. El ile gizleme öğreticidir ama üç sorunu vardır: (1) hataya açıktır — el ile yazılan gizleme kodu davranışı bozabilir; (2) bakımı zordur — kaynak okunamaz hale gelir; (3) çeşitlendirilemez — her kopyayı el ile farklılaştıramazsınız. Çözüm, gizlemeyi bir araca yaptırmaktır.

Tarihçeyi biraz daha açalım¶

• 1993 — Cohen, "program evolution": Fred Cohen (bilgisayar virüsü kavramını da akademik olarak tanımlayan araştırmacı), bir programın işlevini değiştirmeden yapısını otomatik olarak değiştirebileceğini gösterdi; bu, "her kopya farklı görünsün" fikrinin (bu haftaki çeşitlendirmenin) akademik kökenidir.
• 1997 — Collberg, Thomborson, Low: Bugün 9. haftada kullandığımız beş ailelik taksonomiyi (düzen, veri, kontrol akışı, önleyici, sanallaştırma) ve güç/dayanıklılık/gizlilik/maliyet çerçevesini yayımladılar; bu makale hâlâ alanın referans noktasıdır ve bu haftaki eşleme tablosunun (bölüm 3) temelidir.
• 2013 — Obfuscator-LLVM (O-LLVM): LLVM derleyici altyapısına eklenen açık kaynaklı bir gizleme geçidi; düzleştirme ve opak yüklem gibi teknikleri derleme sırasında, ayrı bir kaynaktan-kaynağa adımı olmadan uygular (9. hafta K-11). Tigress'ten farkı, kaynak kod yerine derleyicinin ara temsiline (IR) müdahale etmesidir — bu yüzden O-LLVM'in çıktısını "yine C kaynağı" olarak göremezsiniz, doğrudan ikili üretir.
• 2010'lar — Tigress: Christian Collberg ve ekibi, 1997'deki taksonomiyi çalışan bir kaynaktan-kaynağa araca dönüştürdü; akademik dayanıklılık araştırmalarının (aşağıdaki Banescu çalışması dahil) fiili test platformu hâline geldi — bu yüzden bu hafta Tigress'i öğrenmek, yalnız bir aracı değil, alanın ortak ölçüm dilini öğrenmek demektir.
• 2016–2017 — Banescu vd.: Tigress'in ürettiği dönüşümleri KLEE ile sistematik olarak kırıp, hangi dönüşüm kombinasyonunun ne kadar sürede çözüldüğünü ölçtüler; bu hafta bölüm 7'de tekrar değineceğimiz "dayanıklılık ↔ maliyet" ilişkisinin deneysel kanıtı budur.

Bu beş nokta, aslında tek bir çizginin parçalarıdır: fikir (1993) → sınıflandırma (1997) → iki farklı uygulama yolu: derleyici tabanlı (2013) ve kaynaktan-kaynağa (2010'lar) → o uygulamanın bilimsel olarak sınanması (2016–2017). Bu hafta bu çizginin son iki adımını (Tigress'i kullanmak ve onu Banescu'nun yöntemiyle değerlendirmeyi anlamak — bölüm 7) uyguluyoruz.

Kaynaktan kaynağa (source-to-source) gizleme, bir aracın C kaynağını girdi alıp yine C kaynağı üretmesidir; üretilen kaynak, davranışça özdeş ama okunması çok daha zordur ve normal derleyicinizle derlenir. Bu yaklaşımın en bilinen aracı Tigress'tir.

Önemli fark: siz okunur kaynağı korur ve bakımını yaparsınız; gizleme, derleme hattında otomatik bir adım olarak çalışır. Bu, 9. haftadaki "her gizleme bakım maliyeti getirir" sorununu büyük ölçüde çözer: bakım maliyeti okunur kaynakta kalır, dağıtılan kaynak gizlidir.

Tigress nedir, nereye oturur?¶

Tigress, Arizona Üniversitesi'nden Christian Collberg ve ekibinin geliştirdiği bir kaynaktan kaynağa C gizleyici ve çeşitlendiricidir. Bu dersteki yeri:

• 1. haftadaki el ile kuralların otomatik karşılığıdır: düzleştirme, opak yüklem, veri kodlama, sanallaştırma — hepsi birer dönüşüm (transform) olarak.
• Çok platformludur (Linux, macOS, Windows, Android; Intel/ARM/WebAssembly) ve GCC/Clang/MSVC ile çalışır.
• Güncel sürümü v4'tür.

Neden bir araç, el ile değil?¶

Hangi koda ne kadar gizleme? (karar akışı)¶

Her fonksiyonu gizlemek hem gereksiz hem pahalıdır: boyut ve çalışma süresi artar, hata ayıklama zorlaşır. Karar iki soruyla verilir. Önce hassas mı — lisans denetimi, anahtar işleme, ödeme mantığı gibi saldırganın ilgilendiği bir kod mu? Değilse gizlemeye gerek yoktur. Hassassa değeri ne kadar — orta değerli kod için sabit gizleme, aritmetik dönüşüm, düzleştirme ve opak yüklem yeterlidir; yüksek değerli ve küçük bir çekirdek için bunlara sanallaştırma da eklenir (sanallaştırma yavaştır, bu yüzden yalnız küçük bölümlere uygulanır). Her durumda sonuç çeşitlendirilir, ölçülür, testten geçirilir ve kararın gerekçesi S9/S15 kayıtlarına yazılır.

İşlenmiş örnek: aynı fonksiyonu el ile ve araçla karşılaştıralım¶

Dokuzuncu haftada K-07 kuralını (dize kodlama) el ile uyguladığımızda, kaynak kodun kendisi değişiyordu: sabit dizge yerine XOR'lu baytlar ve çözme döngüsü yazıyorduk. Aynı fikri şimdi kaynaktan kaynağa bir araçla yapalım — girdi ve çıktı hâlâ ikisi de C'dir, ama çıktıyı siz yazmazsınız, araç üretir.

int erisim_ver(const char *jeton) {
    if (jeton_gecerli(jeton)) return IZIN;   /* tek dal, tek dönüş: kolay hedef */
    return RED;
}

int erisim_ver(const char *jeton) {
    /* IZIN ve RED artık düz sabit değil; çalışma anında bir kod-çözme adımından geçer.
       Fikir 9. haftadaki K-07 ile birebir aynıdır (bkz. 0x41 XOR 0x5A örneği); farkı
       çözme kodunu SİZİN değil, ARACIN üretmiş olmasıdır. */
    if (jeton_gecerli(jeton)) return _cozul_sabit_0x9F2A();  /* == IZIN, ama kaynakta IZIN yazmıyor */
    return _cozul_sabit_0x117C();                            /* == RED */
}

İkinci blok gerçek bir Tigress çıktısı değildir — sürüme, derleyiciye ve --Seed değerine göre üretilen kod değişir; bu yalnız EncodeLiterals'in fikrini göstermek içindir (tıpkı bu dosyadaki diğer "kavramsal akış" bloklarının komut sözdizimini gösterip gerçek çıktıyı iddia etmemesi gibi). Önemli olan şu fark: 9. haftada _cozul_sabit_0x9F2A() gibi bir fonksiyonu siz elle yazıp, elle test eder, bir sonraki fonksiyona geçtiğinizde yeniden yazardınız. Burada bu adımı --Functions=erisim_ver ile işaretlediğiniz her fonksiyona araç otomatik uygular.

Ne kadar zaman kazandırır? Kaba bir karşılaştırma (varsayımsal)¶

Neden-bir-araç sorusuna bir de zaman açısından bakalım. Aşağıdaki sayılar varsayımsaldır, yalnızca büyüklük mertebesini göstermek içindir:

Buradaki asıl kazanç doğrusal değil, katlanarak büyüyen bir farktır: fonksiyon sayısı arttıkça el ile yöntemin maliyeti orantılı artar, araçla yöntemin maliyeti hemen hemen sabit kalır. Bu, bölüm 9'daki "S15'te CI'ye gizleme adımı ekleyin" tavsiyesinin de altında yatan pratik nedendir.

İşlenmiş örnek: bir yıllık bakım senaryosu (varsayımsal)¶

"Ne kadar zaman kazandırır?" tablosunu bir yıla yayalım. Diyelim bir ürünün 12 ayda 12 sürümü çıkıyor ve her sürümde ortalama 3 fonksiyon yeni hassas hâle geliyor (ör. yeni bir ödeme akışı, yeni bir lisans kontrolü):

Bu tablo varsayımsaldır, ama iki gerçek eğilimi doğru yansıtır: (1) el ile yöntemin maliyeti fonksiyon ve sürüm sayısıyla doğrusal büyür, araçla yöntemin maliyeti hemen hemen sabit kalır (yukarıdaki ilk tablonun büyütülmüş hâli); (2) el ile yöntemde "unutma riski" gerçek bir güvenlik açığıdır — yeni eklenen hassas bir fonksiyonun gizlenmeyi atlaması, kod incelemesinde fark edilmezse hiç korunmadan yayınlanabilir; araçla yöntemde bu risk --Functions listesinin kendisi bir denetlenebilir belge olduğu için azalır.

2. Temel akış: bir programı adım adım gizlemek¶

Tigress komut satırından çalışır: hangi dönüşümlerin, hangi fonksiyonlara, hangi sırayla uygulanacağını söylersiniz; çıktı gizlenmiş bir C dosyasıdır. Kavramsal akış (sözdizimi sürümle değişebilir, resmî belgeden doğrulayın):

# girdi: temiz.c  → çıktı: gizli.c  (sonra normal derlenir)
tigress --Transform=Flatten --Functions=erisim_ver \
        --out=gizli.c temiz.c
cc -o program gizli.c

Buradaki üç fikir, bütün Tigress kullanımının temelidir:

1. --Transform=... hangi dönüşümün uygulanacağını söyler (Flatten = kontrol akışı düzleştirme, 9. hafta K-04).
2. --Functions=... dönüşümün hangi fonksiyonlara uygulanacağını söyler — çünkü gizlemeyi yalnız hassas fonksiyonlara uygularız (maliyet kuralı).
3. Çıktı yine C'dir; kendi derleyicinizle derlersiniz. Gizleme, derleme hattına eklenen bir adımdır.

Neden --Functions bu kadar önemli? Seçici ile toptan gizlemeyi karşılaştıralım¶

--Functions=erisim_ver gibi bir bayrak, "yalnız bu fonksiyona uygula" demektir. Bunun tersini — bir dosyadaki bütün fonksiyonları gizlemeyi — düşünelim ve iki yaklaşımı karşılaştıralım:

Uçtan uca: tigress-hatti.sh betiğini satır satır okuyalım¶

Kavramsal akışı somutlaştırmak için, bu haftanın gerçek demo betiğini (code/week-14/01-kaynaktan-kaynaga/tigress-hatti.sh) baştan sona, adım adım okuyalım. Betik dört adımdan oluşur; hiçbirini atlamadan geçelim.

Adım 0 — Hazırlık. Betik önce çalıştığı klasöre geçer (cd "$(dirname "$0")") ve bir derleyici seçer (CC=cc, yoksa gcc'ye düşer). Bu, hangi makinede çalıştırılırsa çalıştırılsın betiğin kendi kendine yeteceğini garanti eder — 1. haftadan beri gördüğümüz "ortam farkını betikte çöz" alışkanlığının bir örneğidir.

ADIM 1 — Temiz sürümü derle ve çalıştır.

"$CC" -O2 -o ornek_temiz ornek.c && ./ornek_temiz "CEN429-OK" && ./ornek_temiz "yanlis"

Bu satır ornek.c'yi (bölüm 0'da tanımladığımız erisim_ver fonksiyonunun bulunduğu gerçek dosya) hiçbir gizleme uygulanmadan derler ve iki kez çalıştırır: bir kez doğru jetonla (CEN429-OK), bir kez yanlış jetonla (yanlis). Beklenen çıktı:

erisim_ver("CEN429-OK") = IZIN
erisim_ver("yanlis") = RED

Bu, gizlemeden önceki referans davranıştır — bölüm 3 ve sonrasında yapılacak her gizlemenin doğruluğu bu iki satırla karşılaştırılarak sınanır (davranış korundu mu?).

ADIM 2 — Tigress kontrolü ve dönüşüm hattı. Betik önce command -v tigress ile Tigress'in kurulu olup olmadığına bakar. İki yol vardır:

tigress --Environment=x86_64:Linux:Gcc:11 \
        --Transform=EncodeLiterals --Functions=erisim_ver \
        --Transform=EncodeArithmetic --Functions=erisim_ver \
        --Transform=Flatten --Functions=erisim_ver \
        --Transform=InitOpaque --Functions=main \
        --Transform=AddOpaque --Functions=erisim_ver --AddOpaqueKinds=call \
        --out=gizli.c ornek.c

ADIM 2 - Tigress KURULU DEGIL.
  Tigress'i resmi siteden indirin: https://tigress.wtf
  Lisans: kar amaci gutmeyen (akademik) kullanim UCRETSIZ; ticari icin Arizona Univ. lisansi.
  Kurulumdan sonra 'tigress' PATH'te olunca bu betik hatti otomatik uygular ve olcer.

  Tigress olmadan bile: ayni kurallarin EL ILE surumu ve olcumu week-09'da CALISIR:
    cd ../../week-09/01-manuel-gizleme && sh demo.sh

ADIM 3 — Davranışı doğrula. Tigress bulunduysa betik şunu yapar:

[ "$(./ornek_temiz CEN429-OK)" = "$(./ornek_gizli CEN429-OK)" ] && echo "  ✓ ayni cikti" || echo "  ✗ FARK"

Temiz ve gizli sürümün aynı girdiyle aynı çıktıyı verip vermediğini karşılaştırır. ✓ ayni cikti çıkmazsa, gizleme hattı davranışı bozmuş demektir — bölüm 4'teki "sıra ve test kuralı"nın betikteki karşılığı budur.

ADIM 4 — Çeşitlendirme. İki farklı tohumla iki ayrı ikili üretilir (--Seed=1001, --Seed=2002) ve cmp -s A B ile bayt bayt karşılaştırılır; betik ikisi farklıysa ✓ iki tohum farkli ikili uretti yazar. Bu, bölüm 6'nın konusudur.

--out ve birden çok fonksiyonu aynı anda gizlemek¶

--out=gizli.c bayrağı, üretilecek gizlenmiş kaynağın hangi dosyaya yazılacağını belirtir; belirtilmezse Tigress varsayılan bir ad kullanır (resmî belgeden doğrulanmalı). Bu hafta boyunca gördüğümüz örneklerin hepsi tek bir fonksiyona (erisim_ver) odaklandı; ama --Functions bir liste alabilir. Diyelim projenizde erisim_ver'in yanında bir de anahtar_turet fonksiyonu var ve ikisi de hassas:

tigress --Transform=Flatten --Functions=erisim_ver,anahtar_turet \
        --Transform=AddOpaque --Functions=erisim_ver,anahtar_turet \
        --out=gizli.c proje.c

--Functions=erisim_ver,anahtar_turet (virgülle ayrılmış liste), her iki fonksiyona da aynı dönüşümü uygular. Bu, bölüm 1'deki "10 fonksiyona aynı kuralı uygulamak" karşılaştırmasının somut söz dizimidir: el ile yöntemde her fonksiyon için ayrı bir kodlama yazmanız gerekirdi, burada tek bir bayrağa bir isim daha eklemeniz yeterlidir.

3. Dönüşüm aileleri ve 9. hafta kurallarıyla eşleme¶

Tigress dönüşümleri, 9. haftada gördüğümüz gizleme ailelerine karşılık gelir. Aşağıdaki tablo, en çok kullanılan dönüşümleri ve dersteki karşılıklarını verir (dönüşüm adları resmî belgeden doğrulanmalıdır; sürümle küçük farklar olabilir):

İşlenmiş örnek: K-01'i Tigress dönüşümüne eşleyelim, adım adım¶

Eşleme tablosunu soyut bırakmayalım; K-01'i (9. hafta, opak yüklem/döngü) uçtan uca Tigress'e bağlayalım.

1. 9. haftadaki tanım (hatırlatma): K-01, doğruluğu sabit ama saldırgana belirsiz görünen bir koşulla (opak yüklem) sahte bir dallanma eklemektir — ((x*(x+1)) & 1) == 0 örneği ve neden her zaman doğru olduğu (Hafta 9, §5) orada işlenmişti.
2. Tigress'teki karşılığı iki adımdır, tek değil: demo betiğinin gerçek komutunda görüldüğü gibi önce --Transform=InitOpaque --Functions=main çalışır, sonra --Transform=AddOpaque --Functions=erisim_ver --AddOpaqueKinds=call. InitOpaque, opak yüklemlerin dayanacağı gizli durum değişkenlerini hazırlar (bölüm 2'de gördüğümüz gibi genelde main içinde ilklendirilir); AddOpaque bu durumu kullanarak hedef fonksiyona (erisim_ver) gerçek opak koşulları ekler. --AddOpaqueKinds=call ise eklenecek opak yüklemin türünü seçer (burada "call" tabanlı bir çeşit).
3. Sonuç: K-01'in "sabit doğru ama belirsiz görünen koşul" tanımı, AddOpaque'in ürettiği koşullarla birebir örtüşür; InitOpaque ise K-01'in kendi başına yetmediği, bir hazırlık adımı gerektirdiği gerçeğini gösterir.

İşlenmiş örnek: K-07'yi EncodeLiterals'e eşleyelim¶

Aynı adımları K-07 (dize kodlama) için de tekrarlayalım, çünkü bu kural demo betiğinde de kullanılıyor:

1. 9. haftadaki tanım (hatırlatma): K-07, "CEN429-OK" gibi bir dizgeyi ikili dosyada düz metin olarak bırakmamak; XOR gibi tersine çevrilebilir bir kodlamayla saklamak ve yalnız kullanım anında çözmektir — bit bit izlenen 0x41 ^ 0x5A örneği (Hafta 9, §6) orada işlenmişti.
2. Tigress'teki karşılığı: --Transform=EncodeLiterals --Functions=erisim_ver. Bu dönüşüm, hedef fonksiyondaki sabit dizgeleri ve sayısal sabitleri kodlayıp, çalışma anında çözen kod üretir — K-07'nin "elle yazılan" hâlinin otomatikleştirilmiş karşılığı (bölüm 2'deki "ÖNCE/SONRA" örneği).
3. Doğrulama: demo betiğindeki gibi bir strings denetimi (9. haftanın demosunda olduğu gibi) gizlenmiş ikili dosyada CEN429-OK metninin artık görünmediğini doğrular; bu, K-07'nin "başarı ölçütü"dür.

Bu iki örnek (K-01 → InitOpaque+AddOpaque, K-07 → EncodeLiterals) tablonun geri kalanını da nasıl okuyacağınızı gösterir: her satırda önce 9. haftadaki tanımı hatırlayın, sonra hangi bayrağın/bayrakların bunu ürettiğini bulun, sonra bir doğrulama yolu belirleyin.

İşlenmiş örnek: Flattenin K-04'ü nasıl uyguladığını kod üzerinde görelim¶

K-01 ve K-07'den sonra, tablodaki en güçlü kontrol akışı dönüşümünü — Flatteni — kod düzeyinde somutlaştıralım. Bölüm 2'deki erisim_ver'i temel alalım:

int erisim_ver(const char *jeton) {
    if (jeton_gecerli(jeton)) return IZIN;
    return RED;
}

int erisim_ver(const char *jeton) {
    int _durum = 7341;          /* dağınık, öngörülemez başlangıç durumu */
    int _sonuc;
    while (1) {
        switch (_durum) {
            case 7341:
                _durum = jeton_gecerli(jeton) ? 2098 : 5560;   /* karar burada gizlendi */
                break;
            case 2098:
                _sonuc = IZIN;
                _durum = 9999;
                break;
            case 5560:
                _sonuc = RED;
                _durum = 9999;
                break;
            case 9999:
                return _sonuc;
        }
    }
}

Bu ikinci blok da gerçek bir Tigress çıktısı değildir; yalnız Flatten'in fikrini göstermek içindir. Üç noktaya dikkat edin:

1. Orijinal if/return yapısı kayboldu; yerine tek bir while(1) döngüsü içinde bir switch dağıtıcısı geldi. Bir tersine derleyicide bu döngü, if (jeton_gecerli(...)) kadar anında okunmaz.
2. Durum sabitleri (7341, 2098, 5560, 9999) ardışık değil, dağınıktır — yukarıdaki "değerleri K-02 ile ya da rastgele, dağınık sabitlerle üretilmeli" notunun somut karşılığı budur; ardışık sabitler (1, 2, 3, 4) bir tersine derleyicide anında "bu bir düzleştirilmiş dağıtıcı" imzası olarak tanınır.
3. Dal sayısı arttı: orijinalde tek bir if (1 dal noktası) vardı; düzleştirilmiş hâlde switch içinde 4 case ve bunlar arasındaki geçişler var — bölüm 5 ve 7'deki "dal sayısı yalnız Flatten'de sıçrıyor" gözleminin kaynağı tam olarak budur.

Dönüşümleri tek tek açalım: her satırın arkasındaki fikir¶

Tablodaki on satırı sırayla, 9. haftadaki tanımlarına referans vererek açalım. Her birinde üç soruyu yanıtlıyoruz: ne yapar, hangi K kuralının otomatik hâlidir, ne zaman tercih edilir.

1. Flatten — kontrol akışı düzleştirme. Bir fonksiyonun if/else/döngü yapısını, tek bir while döngüsü içindeki bir switch dağıtıcısına çevirir; her orijinal blok bir case olur, bloklar arası geçiş case numarasını değiştirmekle sağlanır. 9. hafta K-04'ün (bölüm 5, "KURAL K-04 — Kontrol akışı düzleştirme") birebir otomatik karşılığıdır. Bölüm 5'teki erisim_ver örneğinde gördüğümüz gibi, "tek dal, tek dönüş" gibi kolay hedefler için orta maliyetli, orta-yüksek güçlü bir ilk adımdır.

2. InitOpaque / AddOpaque / UpdateOpaque — opak yüklem ailesi. K-01'in (opak yüklem/döngü) otomatik hâlidir. Üç ayrı komuta bölünmüş olması bilinçlidir: InitOpaque hazırlık (durum değişkenlerini kurar, genelde main'de), AddOpaque ekleme (hedef fonksiyona gerçek koşulları yerleştirir), UpdateOpaque ise zaten eklenmiş opak yapıları güncellemek/çeşitlendirmek için kullanılır (birden çok gizleme turunda). Yukarıda ayrıntılandırdık.

3. EncodeArithmetic — aritmetik kodlama (MBA). K-02'nin (9. hafta bölüm 6: "aritmetik komutların kodlanması") otomatik hâlidir; a + b gibi basit bir işlemi, aynı sonucu veren ama okunması zor mixed boolean-arithmetic (karma mantıksal-aritmetik) ifadelere çevirir (9. haftanın (a^b) + 2·(a&b) = a+b örneğini hatırlayın). Düşük maliyetlidir; ama 9. haftanın "MBA sadeleştiricilerle açılabilir" uyarısı burada da geçerlidir (bölüm 7).

4. EncodeLiterals — sabit ve dizge kodlama. K-07'nin (dize kodlama) otomatik hâlidir; yukarıda ayrıntısıyla işledik. Çok düşük maliyetli, ama tek başına zayıf (çalışırken bellekte açığa çıkar — 9. haftanın "gizleme anahtar saklamaz" uyarısı).

5. EncodeData — değişken gösterimini kodlama. K-09'un (9. hafta bölüm 6: "değişken bölme, birleştirme ve dizi yeniden yapılandırma") otomatik hâline en yakın karşılıktır; bir değişkenin bellekteki temsilini (ör. tek bir 32-bit tamsayı yerine parçalanmış/kodlanmış bir yapı) değiştirir. Amaç, bir bellek dökümünde değerin doğrudan görünmemesidir.

6. Split / Merge — fonksiyon bölme/birleştirme. K-06'nın (9. hafta bölüm 5: "fonksiyon çağrılarının ve dış kütüphane bağımlılığının gizlenmesi") bir parçasıdır; Split bir fonksiyonu birden çok küçük parçaya böler, Merge birden çok fonksiyonu tek bir büyük fonksiyonda birleştirir. İkisi de fonksiyonun sınırlarını bulanıklaştırır — bir tersine derleyicide "bu, tek bir mantıksal işlem mi yoksa birkaçının birleşimi mi?" sorusunu zorlaştırır.

7. Virtualize — sanallaştırma tabanlı gizleme. K-10'un (9. hafta bölüm 7) otomatik hâlidir; fonksiyonu özel bir sanal makinenin bayt koduna çevirir. Tablodaki en pahalı satırdır (yukarıdaki "Aileler ve maliyet" kutusundaki "onlarca kat yavaşlama" uyarısı); yalnız küçük, kritik fonksiyonlara uygulanır (bölüm 1'deki karar akışı, bölüm 5'teki "Adım 5").

8. Jit — çalışma anında kod üretimi. K-12'nin (9. hafta bölüm 7: "kendini değiştiren kod ve dinamik şifreleme") kavramsal karşılığıdır; kodun bir kısmı derleme anında değil, çalışma anında üretilir. 9. haftanın K-12 için verdiği uyarı (işletim sisteminin bellek korumalarıyla — DEP/NX, W^X — çatışabilmesi) burada da geçerlidir; bu yüzden tabloda "(kavram)" notuyla işaretlidir — derste uygulanmaz, yalnız tanınır.

9. AntiBranchAnalysis / AntiAliasAnalysis / AntiTaintAnalysis — önleyici (anti-analysis) ailesi. 9. haftanın "önleyici" ailesinin (bölüm 2'deki beş aileden biri) doğrudan otomatik karşılığıdır; bu üçü sırasıyla dal analizini, takma ad (alias) analizini ve kirlenme (taint) analizini yapan araçları (bir tersine derleyicinin veya sembolik yürütücünün kullandığı teknikleri) hedef alıp zorlaştırır. K-06'daki "analiz araçlarının kendisini hedef almak daha zahmetlidir" notunun somut örnekleridir.

10. RandomFuns / RndArgs — rastgele fonksiyon/parametre ekleme. Bölüm 6'daki "Çeşitlendirme" notunda göreceğimiz gibi, bunlar tek başlarına bir K kuralına değil, çeşitlendirmeye ve K-06'daki "sahte parametre" fikrine hizmet eder: RandomFuns rastgele, işlevsiz (ama gerçek gibi görünen) fonksiyonlar ekler; RndArgs mevcut fonksiyonlara sahte parametreler ekler. İkisi de tohumla birlikte kullanıldığında her kopyayı farklılaştırır.

İşlenmiş örnek: EncodeData bir değişkeni nasıl parçalar (kavramsal)¶

K-09'un (9. hafta: değişken bölme/birleştirme) otomatik karşılığı olan EncodeData'yı somutlaştıralım. Diyelim erisim_ver içinde bir "deneme sayacı" değişkeni var:

int deneme_sayaci = 0;
...
deneme_sayaci++;
if (deneme_sayaci > 3) return KILITLI;

struct { unsigned char alt; unsigned char ust; } _sayac_parcalari = {0, 0};
...
/* deneme_sayaci++ karşılığı: alt baytı artır, taşarsa üst baytı güncelle */
_sayac_parcalari.alt++;
if (_sayac_parcalari.alt == 0) _sayac_parcalari.ust++;
/* deneme_sayaci > 3 karşılığı: iki parçayı birleştirip karşılaştır */
if (((_sayac_parcalari.ust << 8) | _sayac_parcalari.alt) > 3) return KILITLI;

Bir bellek dökümünde (ör. bir hata ayıklayıcıyla programı durdurup belleği okumak), deneme_sayaci'nin tek, bütün bir 32-bit tam sayı olarak görünmesi yerine, birbirinden bağımsız iki bayt olarak, üstelik bir yapı (struct) içinde dağılmış olarak durur — bölüm 0'daki "bellek dökümünde değerin doğrudan görünmemesi" hedefine birebir uyar.

İşlenmiş örnek: Split bir fonksiyonu nasıl böler (kavramsal)¶

Split dönüşümünü de somutlaştıralım. Diyelim erisim_ver iki mantıksal adımı art arda yapıyor: uzunluk kontrolü ve içerik karşılaştırması (tam olarak ornek.c'deki gerçek erisim_ver'in yaptığı gibi — bölüm 0'daki kod).

int erisim_ver(const char *jeton) {
    if (strlen(jeton) != strlen(GECERLI)) return 0;
    unsigned fark = 0;
    for (unsigned i = 0; i < sizeof GECERLI - 1; i++)
        fark |= (unsigned)((unsigned char)jeton[i] ^ (unsigned char)GECERLI[i]);
    return fark == 0;
}

static int _adim_a(const char *jeton) {          /* yalnız uzunluk kontrolü */
    return strlen(jeton) == strlen(GECERLI);
}
static unsigned _adim_b(const char *jeton) {      /* yalnız fark hesabı */
    unsigned fark = 0;
    for (unsigned i = 0; i < sizeof GECERLI - 1; i++)
        fark |= (unsigned)((unsigned char)jeton[i] ^ (unsigned char)GECERLI[i]);
    return fark;
}
int erisim_ver(const char *jeton) {
    if (!_adim_a(jeton)) return 0;
    return _adim_b(jeton) == 0;
}

Sonuç iki yeni, adı jenerik iki yardımcı fonksiyondur (_adim_a, _adim_b); bir tersine derleyicide artık üç ayrı sembol vardır (bölüm 0'daki "sembol tablosu" tanımını hatırlayın), ve erisim_ver'in kendisi artık yalnız iki çağrıdan ibarettir — asıl mantık başka fonksiyonlara dağılmıştır. Merge bunun tam tersini yapar: birden çok küçük fonksiyonu tek, büyük bir fonksiyonda birleştirir; sonuç, "bu tek bir işlem mi yoksa birkaçının toplamı mı?" sorusunu tersinden zorlaştırır.

4. Dönüşüm hattı: birden çok dönüşümü birleştirmek¶

Dokuzuncu haftanın en önemli kuralı "tek teknik değil, birlikte" idi. Tigress'te bu, dönüşümleri sırayla (bir hat olarak) uygulamak demektir. Her --Transform bir öncekinin çıktısına uygulanır; sıra önemlidir.

İmza en son gelir (önce gizle, sonra imzala); her hattan sonra davranışı test et ve maliyeti ölç.

tigress \
  --Transform=EncodeLiterals --Functions=erisim_ver \
  --Transform=EncodeArithmetic --Functions=erisim_ver \
  --Transform=Flatten        --Functions=erisim_ver \
  --Transform=AddOpaque      --Functions=erisim_ver \
  --out=gizli.c temiz.c

Bu hat, tek bir denetimi (erisim_ver) önce sabit/dize kodlar, sonra aritmetiğini kodlar, sonra düzleştirir, sonra opak yüklemlerle güçlendirir. Sonuç, 9. haftada K-04'ün "güçlendirilmiş düzleştirme" dediği şeyin otomatik halidir.

İki farklı sırayı somut karşılaştıralım¶

"Sıra önemlidir" cümlesini soyut bırakmayalım. Aynı dört dönüşümü (EncodeLiterals, EncodeArithmetic, Flatten, AddOpaque) iki farklı sırayla düşünelim ve her sırada neyin neyi kapsadığını izleyelim. Kural basit ama sonuçları farklıdır: bir dönüşüm, yalnızca çalıştığı anda kaynakta zaten var olan şeyi dönüştürebilir; kendisinden sonra gelen bir dönüşümün ürettiği yeni kodu göremez.

Sıra 1 (bu bölümdeki hat, demo betiğinin kullandığı sıra):

EncodeLiterals → EncodeArithmetic → Flatten → AddOpaque

EncodeLiterals ilk çalıştığı için yalnızca orijinal kaynaktaki (ornek.c'deki) sabitleri/dizgeleri kodlar. Flatten üçüncü sırada çalıştığında, düzleştirilmiş switch dağıtıcısının kendi ürettiği yeni durum sabitlerini (case 1, case 2, ...) EncodeLiterals artık göremez — çünkü o adım çoktan geçti. Bunun sakıncası yoktur, çünkü Flatten kendi durum değerlerini zaten dağınık/öngörülemez üretir (bölüm 5'teki not: "değerleri K-02 ile ya da rastgele, dağınık sabitlerle üretilmeli" — bu iş burada Flatten'in kendisine düşer). Bu sırada kazanç şudur: Flatten çalıştığında dağıtıcının her case'inin içindeki aritmetik zaten (EncodeArithmetic sayesinde) karmaşıklaştırılmış durumdadır — yani düzleştirilmiş kod hem yapı hem içerik olarak zor okunur.

Sıra 2 (yapısal dönüşümler önce, kodlama dönüşümleri sonra):

Flatten → AddOpaque → EncodeArithmetic → EncodeLiterals

Burada EncodeLiterals son adımdır; artık yalnız orijinal kaynaktaki sabitleri değil, Flatten'in ürettiği durum sabitlerini ve AddOpaque'in eklediği opak koşul sabitlerini de görebilir ve kodlayabilir — daha geniş bir kapsama alanı. Ama bir bedeli vardır: EncodeArithmetic de dördüncü sırada çalıştığı için artık tek bir küçük fonksiyonun aritmetiğini değil, Flatten'in dağıtıcı mantığına ve AddOpaque'in eklediği koşullara yayılmış aritmetiği kodlamak zorundadır — dönüşümün işi büyür, üretilen kod ve maliyet de büyür.

Çıkarım: "doğru" tek bir sıra yoktur; sıra bir kapsam/maliyet ödünleşimidir. Bu hafta demo betiğinin kullandığı Sıra 1'i temel alıyoruz çünkü basit ve öngörülebilir; ama kendi projenizde farklı bir sıra denerseniz, bölüm 7'deki ölçüm adımlarını her sıra için ayrı ayrı çalıştırıp karşılaştırmadan "bu sıra daha iyi" demeyin — bu tam olarak yukarıdaki "sıra ve test kuralı"nın pratikte ne anlama geldiğidir.

İşlenmiş örnek: imzalama sırası bozulursa ne olur?¶

"İmza en son gelir" kuralını bir somut senaryoyla test edelim. Diyelim bir geliştirici yanlışlıkla sırayı tersine çevirdi:

1. temiz.c derlenir → program (imzasız).
2. program imzalanır → program.imzali (bir dijital imza, dosyanın o anki bayt içeriğine bağlıdır).
3. Sonra "unutulan" gizleme adımı fark edilir; temiz.c'den gizli.c üretilip yeniden derlenip, çıkan yeni ikili eski imzalı dosyanın üzerine kopyalanır.

Sonuç: adım 3'te üretilen yeni ikili dosya, adım 2'de imzalanan bayt içeriğinden farklıdır (gizleme dosyanın her baytını değiştirebilir — bölüm 5/7'deki komut sayısı artışını hatırlayın). Doğrulama yapan taraf (ör. bir yükleyici, bir mağaza) imzayı geçersiz bulur ve programı reddeder — üretim ortamında bu, "sürüm yayınlanamadı" anlamına gelir.

5. Adım adım örnek: bir denetimi güçlendirmek (sentetik)¶

Tek bir sentetik erişim denetimini alıp katman katman güçlendirelim. Amaç, her adımın ne eklediğini ve ne kadara mal olduğunu görmektir.

int erisim_ver(const char *jeton) {
    if (jeton_gecerli(jeton)) return IZIN;   /* tek dal, tek dönüş: kolay hedef */
    return RED;
}

Çıkarım: Her adım saldırıyı biraz daha pahalı yapar; ama her adım bir maliyet ekler. Nerede duracağınıza, korunan varlığın değerine ve ölçtüğünüz maliyete göre karar verirsiniz (bölüm 4). Adım 5 (Virtualize) çoğu denetim için gereksizdir; yalnız en kritik ve küçük fonksiyonlara uygulanır.

Sayısal bir örnekle adım adım maliyet artışını izleyelim (varsayımsal)¶

Yukarıdaki tabloyu sayılarla dolduralım. Aşağıdaki komut/dal sayıları varsayımsaldır (Tigress kurulu değilken gerçek ölçüm alınamaz); yalnız her adımın büyüklük mertebesini ve aritmetiğin nasıl doğrulandığını göstermek içindir. Gerçek sayılar için tigress-hatti.sh'yi Tigress kuruluyken çalıştırıp betiğin bastığı objdump çıktısını okuyun (bölüm 0'daki "komut/dal sayımı" tanımını hatırlayın).

Üç gözlem:

1. Dal sayısı yalnız Flatten'de sıçrıyor (2 → 5): bu beklenir, çünkü düzleştirme mantığı gereği tek bir if yerine çok yollu bir switch dağıtıcısı kurar (bölüm 7'nin "güç" ölçütünün doğrudan kaynağı).
2. Kümülatif artış, adım artışlarının toplamı değildir — her yüzde bir öncekinin üzerine çarpımsal eklenir (%36,4 sonra %53,3 ekleyince toplam %109,1 olur, %36,4+%53,3=%89,7 değil). Bu, yüzde hesaplarken sık yapılan bir aritmetik hatadır; her satırı kendi paydasıyla (bir önceki adımın sayısıyla) hesaplayın.
3. %359 gibi büyük bir kümülatif sayı, dört dönüşümü üst üste yığmanın beklenen sonucudur; tek bir dönüşümün (9. haftadaki elle Flatten+AddOpaque örneğinde ölçülen gerçek %82) maliyetiyle karıştırılmamalıdır — burada dört dönüşüm birlikte sayılıyor.

İşlenmiş örnek: tek dönüşüm mü, dört dönüşüm birlikte mi? Sayısal karşılaştırma¶

Bölüm 1'deki "birlikte kullanmanın" gerekçesini yukarıdaki sayılarla sınayalım. Aynı erisim_ver fonksiyonuna yalnız tek bir dönüşüm uygulasaydık ne olurdu, dört dönüşümü birlikte uyguladığımızda ne oldu — ikisini yan yana koyalım (sayılar yukarıdaki tablodan alınmış/varsayımsaldır):

Son sütun asıl noktadır: yalnız EncodeLiterals uygulamak, saldırganın yalnız bir aracını (strings) etkisiz kılar; saldırgan hâlâ kontrol akışını doğrudan okuyabilir. Dört dönüşümü birlikte uygulamak, saldırganın dört farklı analiz tekniğini aynı anda ve birbirine bağımlı biçimde yenmesini gerektirir (9. haftanın "iki zayıf katman, birlikte tek katmandan daha güçlüdür" kuralının sayısal gerekçesi).

6. Çeşitlendirme: aynı kaynaktan farklı ikili dosyalar¶

Dokuzuncu haftanın "Kural 2 — otomasyonu kır" ilkesini hatırlayın: bir saldırgan bir kopyayı kırıp saldırısını bütün kopyalara dağıtabiliyorsa, bir kırık her yeri açar. Çeşitlendirme (diversification), aynı kaynaktan davranışça özdeş ama yapıca farklı ikili dosyalar üretmektir. Tigress bunu bir tohum (seed) ile yapar: aynı dönüşümleri farklı tohumlarla çalıştırırsanız, opak yüklemler, sahte dallar ve düzleştirme durumları kopyadan kopyaya değişir.

tigress --Seed=1001 --Transform=Flatten --Transform=AddOpaque \
        --Functions=erisim_ver --out=gizli_a.c temiz.c
tigress --Seed=2002 --Transform=Flatten --Transform=AddOpaque \
        --Functions=erisim_ver --out=gizli_b.c temiz.c
# gizli_a.c ve gizli_b.c aynı işi yapar; makine kodları farklıdır

İki tür çeşitlendirme (9. haftadan):

• Uzayda çeşitlendirme: farklı kullanıcılara/cihazlara farklı tohumla üretilmiş kopyalar dağıtmak. Bir kopyaya yazılan otomatik saldırı, başka kopyada çalışmaz.
• Zamanda çeşitlendirme: her sürümü yeni bir tohumla üretmek. Eski sürüme karşı bulunan saldırı, yeni sürümde bozulur. Bu, 10. haftadaki anahtar/sürüm yenileme politikanızla birlikte çalışır.

İşlenmiş örnek: iki tohumla üretilen ikiliyi adım adım karşılaştıralım¶

Demo betiğinin ADIM 4'ü tam olarak bunu yapar: --Seed=1001 ve --Seed=2002 ile aynı ornek.c'den iki ayrı erisim_ver üretir, derler ve cmp -s A B ile bayt bayt karşılaştırır. Adımları tek tek izleyelim:

1. Aynı kaynak, iki komut:

tigress --Seed=1001 --Transform=Flatten --Transform=AddOpaque --Functions=erisim_ver --out=a.c ornek.c
tigress --Seed=2002 --Transform=Flatten --Transform=AddOpaque --Functions=erisim_ver --out=b.c ornek.c

Dikkat: --Transform listesi ikisinde de birebir aynı (Flatten, AddOpaque); tek fark --Seed değeri. 2. Derle: a.c ve b.c, aynı derleyici ve bayraklarla (-O2) iki ayrı ikiliye (A, B) derlenir. 3. Davranışı karşılaştır (önce bu!): her iki ikili de CEN429-OK girdisiyle çalıştırılıp aynı çıktıyı (IZIN) verdiği doğrulanmalıdır — çeşitlendirme davranışı asla değiştirmemelidir (bölüm 4'teki kuralın burada da geçerli olması). 4. Yapıyı karşılaştır: cmp -s A B, iki dosyayı bayt bayt karşılaştırır; $? (çıkış kodu) 0 ise dosyalar özdeştir (kötü — çeşitlendirme işe yaramamış demektir), 1 ise farklıdır (beklenen sonuç).

Fark oranını sayısallaştıralım (varsayımsal, 9. haftanın gerçek %66,4'lük örneğine benzer biçimde). Diyelim erisim_ver'in düzleştirilmiş+opak-yüklemli hâli her iki ikilide de 160 bayt yer kaplıyor; bayt bayt karşılaştırdığımızda 96 baytın farklı çıktığını ölçtük:

fark_orani = degisen_bayt / toplam_bayt × 100
           = 96 / 160 × 100
           = %60

Yorum: iki kopyanın %60'ı farklı, %40'ı ortak (muhtemelen fonksiyon girişi/çıkışı gibi derleyicinin sabit tuttuğu parçalar — 9. haftadaki 512 baytlık örnekte kalan %33,6'nın aynı nedeni). 9. haftadaki elle çeşitlendirmede ölçülen %66,4 ile bu hafta Tigress'in --Seed ile ürettiği %60 aynı büyüklük mertebesindedir — bu beklenir, çünkü ikisi de aynı fikri (rastgele seçimlerle yapıyı değiştirmek) uygular; tam sayı elle yazılan ile araçla üretilen kod arasında elbette farklı olacaktır.

İşlenmiş örnek: cmp yerine hedef fonksiyonu doğrudan karşılaştıralım¶

Yukarıdaki "sık yapılan hata" kutusunun önerdiği doğru yöntemi uygulayalım. cmp -s A B yalnız "farklı/aynı" der; hedefin (erisim_ver) kendisinin farklı olup olmadığını görmek için bölüm 0'daki objdump yöntemini iki ikiliye birden uygulayıp yalnız o fonksiyonun bölümünü karşılaştırırız:

# Her iki ikiliden yalnız <erisim_ver>: etiketinin altını çıkar
objdump -d A | awk '/<erisim_ver>:/{a=1} a{print} /^$/{if(a)exit}' > erisim_A.asm
objdump -d B | awk '/<erisim_ver>:/{a=1} a{print} /^$/{if(a)exit}' > erisim_B.asm
diff erisim_A.asm erisim_B.asm | wc -l    # 0 ise hedef fonksiyon AYNI kalmış demektir

Eğer diff çıktısı boşsa (satır sayısı 0), bu iki tohumun erisim_ver üzerinde hiçbir fark yaratmadığı anlamına gelir — yani bölüm 6'daki iddia (çeşitlendirme oldu) yanlış olur, cmp'nin bütün dosyada bulduğu fark yalnız önemsiz bir yerdeydi (ör. derleme zaman damgası). diff çıktısı doluysa, hedef fonksiyonun kendisi gerçekten değişmiş demektir — ancak o zaman "çeşitlendirme kanıtlandı" denebilir. Bu iki adımlı doğrulama (önce cmp ile "bir şeyler farklı mı?", sonra objdump+diff ile "hedefin kendisi mi farklı?") bölüm 6'nın başındaki demo betiği anlatımını tamamlar.

Kaç kullanıcı, kaç tohum? Uzayda çeşitlendirmeyi ölçekte düşünelim (varsayımsal)¶

Bölüm 6'nın başındaki "uzayda çeşitlendirme" tanımını bir dağıtım senaryosuyla somutlaştıralım. Diyelim bir mobil uygulamanın 10.000 kullanıcısı var ve her kurulumda farklı bir tohum kullanılıyor:

Üçüncü satırdaki hesap basittir: bir saldırgan tek bir kopyayı kırıp o kopyaya özel bir bayt yaması üretse bile, bu yama yalnız aynı tohumla üretilmiş ikililerde işe yarar; her kullanıcı farklı bir tohuma sahipse, yama başka hiçbir kopyada çalışmaz. Bu sayılar varsayımsaldır (gerçek etki, saldırganın yamayı ne kadar genelleştirebildiğine de bağlıdır — ör. bir yama yalnız belirli bir bayt ofsetini hedefliyorsa etkisi daha da dar olur, davranışsal bir desene dayanıyorsa biraz daha geniş olabilir); amaç yalnız "tohum sayısı arttıkça bir kırığın yayılma yüzeyi küçülür" ilişkisini göstermektir.

İşlenmiş örnek: zamanda çeşitlendirmeyi bir zaman çizelgesinde izleyelim (varsayımsal)¶

Yukarıdaki "uzayda çeşitlendirme" örneğinin ikizi olan zamanda çeşitlendirmeyi de bir sürüm takvimiyle somutlaştıralım. Diyelim bir ürün her ay yeni bir sürüm yayınlıyor ve her sürüm CI'de (bölüm 9'un kuralı) yeni bir tohumla gizleniyor:

Şubat'taki kırığın "ömrü" yalnız bir ay (v1.1'in yayın tarihinden v1.2'nin yayın tarihine kadar) sürdü — bölüm 1'in "Kural 3 — diğer katmanlara zaman kazandır" ilkesinin sayısal karşılığı budur. Eğer ürün tohumu hiç değiştirmeden (zamanda çeşitlendirme olmadan) her ay yeni özellik eklese bile aynı gizleme yapısını korusaydı, Şubat'taki kırık süresiz olarak geçerli kalırdı.

Bu döngünün maliyeti neredeyse sıfırdır, çünkü bölüm 9'daki CI iskeleti her sürümde gizleme + ölçüm + imzalamayı otomatik çalıştırır (bölüm 2'deki "araçla mı, el ile mi" karşılaştırmasını hatırlayın); el ile çeşitlendirme yapılsaydı, her ay yeniden elle gizleme yazmak gerekirdi — bu da pratikte hiç sürdürülemezdi.

7. Gizlemeyi ve çeşitlendirmeyi ölçmek¶

Dokuzuncu haftada gizlemeyi dört boyutta (güç, dayanıklılık, gizlilik, maliyet) ölçmeyi öğrendik. Tigress'in en büyük öğretim değeri, bu ölçümleri somut yapabilmenizdir: aynı programı gizleyip önce/sonra ölçersiniz.

Maliyet ölçümü (kolay ve zorunlu)¶

Her dönüşüm hattı için şunları ölçün ve S9/S15'e yazın:

size ./program_temiz ./program_gizli        # boyut farkı
# süre: aynı girdiyle N kez çalıştır, ortalamayı karşılaştır

Dayanıklılık ölçümü (ileri, kavramsal)¶

Dokuzuncu haftada dayanıklılığın "bir iddia değil, ölçülen bir nicelik" olduğunu söylemiştik. Tigress bu konuda akademik çalışmanın merkezindedir: Banescu ve arkadaşlarının çalışması, Tigress dönüşümlerinin sembolik yürütmeye (KLEE gibi) ne kadar dayandığını ölçer. Bulgu, ders için önemli bir kuraldır:

• Tek bir dönüşüm (yalnız Flatten) sembolik yürütmeyle çoğu zaman geri açılabilir.
• Dönüşümleri birleştirmek ve durum uzayını büyütmek (opak yüklemleri çözmesi pahalı yapılara bağlamak) çözücünün işini üstel olarak zorlaştırabilir.
• Ama bu, maliyeti de artırır. Yani dayanıklılık ve maliyet, tam da 9. haftada dediğimiz gibi ödünleşir.

Boyut ve süre ölçümünü tamamlayalım: bölüm 5'teki sayılara ekleyelim¶

Bölüm 5'te tek bir fonksiyonun (erisim_ver) komut ve dal sayısındaki artışı adım adım izledik (varsayımsal %359,1 kümülatif komut artışı, adım 0'daki 2 daldan adım 4'teki 7 dala çıkış). Şimdi bu sayıları Collberg'in dört ölçütüne (yukarıdaki tablo) dağıtalım ve boyut ile **süre**yi de ekleyelim.

Güç (potency), 9. haftanın çevrimsel karmaşıklık formülüyle (dal_sayısı + 1):

Adım 0 (temiz)  : 2 dal + 1 = 3
Adım 4 (tam hat): 7 dal + 1 = 8
Artış           : (8 − 3) / 3 × 100 ≈ %166,7

Maliyet (cost), bölüm 5'teki komut sayısı artışı: zaten hesapladık, %359,1 (kümülatif, dört dönüşüm birlikte).

Boyut: Bu noktada önemli bir uyarı gerekir.

Süre: Benzer bir uyarı süre için de geçerlidir — bu kadar küçük bir fonksiyonun tek çağrısı, işletim sisteminin zamanlayıcı hassasiyetinin (genelde milisaniye altı) çok altında sürer; anlamlı bir süre farkı görmek için fonksiyonu çok sayıda (ör. bir milyon) kez döngüde çağırıp toplam süreyi ölçmek gerekir:

# Sözde kod: gerçek ölçüm aracı platforma göre değişir (ör. `time`, bir kıyaslama döngüsü)
for i in $(seq 1 1000000); do ./ornek_temiz CEN429-OK >/dev/null; done   # zaman ölçülür
for i in $(seq 1 1000000); do ./ornek_gizli CEN429-OK >/dev/null; done  # zaman ölçülür, karşılaştırılır

Not: yukarıdaki döngü aslında her seferinde yeni bir süreç başlatma maliyetini de ölçer (fork/exec), bu da gerçek fonksiyon süresini gölgeleyebilir; gerçek bir ölçümde fonksiyon bir döngü içinde, aynı süreçte milyonlarca kez çağrılıp yalnız o döngünün süresi ölçülür. Bu ayrım — "sürecin başlatma maliyeti" ile "fonksiyonun kendi süresi" — küçük demolarda sık karıştırılan bir noktadır.

Dört ölçütü tek tabloda toplayalım¶

Dayanıklılığı biraz daha somutlaştıralım: AddOpaque'in ürettiği koşulu sembolik yürütme nasıl kırar?¶

Yukarıdaki bölüm "dayanıklılık ölçümü (ileri, kavramsal)" dedi ve Banescu vd. çalışmasına atıfta bulundu; 9. hafta bu mekanizmayı klasik bir opak yüklem üzerinde (((x*(x+1)) & 1) == 0) adım adım göstermişti. Aynı akıl yürütmeyi, bu haftanın konusu olan araçla üretilmiş bir opak yükleme (Tigress'in AddOpaque ile eklediği koşullardan biri, kavramsal olarak) uygulayalım:

1. Bir sembolik yürütme aracı (KLEE gibi), programı somut değerlerle değil, girdiyi bilinmeyen bir sembol olarak tutup çalıştırır.
2. AddOpaque'in eklediği bir dala geldiğinde, aracın sorması gereken soru aynıdır: "bu koşul, girdinin her değeri için aynı sonucu mu verir, yoksa onu bozan bir girdi var mı?"
3. Bu soruyu bir kısıt çözücüye (SMT solver) devreder. Eğer AddOpaque'in ürettiği koşul, 9. haftadaki x*(x+1) örneği gibi matematiksel olarak basit ve bilinen bir kalıba dayanıyorsa, çözücü bunu saniyeler içinde çözer ve o dalın "ölü" (hiç çalışmayan) olduğunu kanıtlar.
4. Sonuç: araçla üretilmiş olması, opak yüklemi otomatik olarak daha dayanıklı yapmaz — üretilen koşulun matematiksel yapısı hâlâ belirleyicidir. Bu, 9. haftanın "her tekniğin her araca eşit dayanmadığı" uyarısının Tigress'in kendi çıktısı için de geçerli olduğunu gösterir.

12. haftanın ölçüm/kanıt disipliniyle bağ¶

On ikinci hafta, bir güvenlik iddiasının yalnız bir test sonucuyla (S16) desteklenmesi gerektiğini, "plan değil sonuç" beklendiğini öğretmişti; aynı disiplin burada da geçerlidir. Bu haftaki dört ölçüt tablosu (güç, dayanıklılık, gizlilik, maliyet), S9/S15 belgenizde tek başına bir iddia değil, her biri kendi kanıtına (ölçüm tablosu, cmp çıktısı, sembolik yürütme denemesi) bağlı bir sonuç olarak yer almalıdır. 12. haftadaki TOE kimliğine (bölüm 0) bu ölçüm tablosunun hangi tohum ve hangi dönüşüm hattıyla üretilen ikiliye ait olduğunu da eklemeyi unutmayın — aksi hâlde bir değerlendirici, hangi ölçümün hangi ikiliyi anlattığını ayırt edemez.

İşlenmiş örnek: gizlilik (stealth) ölçütünü kavramsallaştıralım¶

9. haftadaki entropi örneğini (bölüm 0: [0x41,0x41,0x41,0x41] düşük entropili, [0x3F,0xA1,0x08,0xC7] yüksek entropili) hatırlayın. Gizlilik, gizlenmiş kodun normal koddan istatistiksel olarak ayırt edilebilir olup olmadığını sorar — ve bu ayırt edilebilirlik çoğu zaman tam olarak entropi/yoğunluk farkından kaynaklanır.

Varsayımsal bir örnek: bir ikili dosyayı tarayan bir araç, her 256 baytlık pencerede dal komutu yoğunluğunu ölçüyor olsun:

Yorum: gizlenmiş erisim_ver'in dal yoğunluğu, dosyadaki diğer sıradan fonksiyonlardan istatistiksel olarak belirgin biçimde farklıdır. Bir saldırgan, bütün ikiliyi taramak zorunda kalmadan, yalnız "anormal derecede yoğun dallı bölgeleri" arayarak doğrudan erisim_ver'e yönelebilir — bu, "gizlilik düşüyor" demektir: güç ve maliyet artarken (bölüm 7'nin ilk tablosu), gizlilik azalmıştır.

Sayısal bir örnek: farklı dönüşüm bileşimleri için varsayımsal çözücü süresi¶

Banescu vd.'nin yönteminin biçimini (gerçek sayılarını değil) bir tabloyla gösterelim; aşağıdaki süreler tamamen varsayımsaldır, yalnız "daha çok katman = çözücü için daha uzun süre" ilişkisinin biçimini görmek içindir:

Son satır, bölüm 6'nın "çeşitlendirme gücü artırmaz, ölçeklenmeyi engeller" kuralının dayanıklılık ölçütü üzerindeki yansımasıdır: bir kopya için harcanan "saatler" mertebesindeki çözücü emeği, bir sonraki kopya için sıfırdan harcanmalıdır — çünkü farklı tohum farklı opak yüklem sabitleri üretir.

8. Sınıf içi akış: gizle, karşılaştır, ölç, çeşitlendir¶

Bu haftanın uygulaması, öğrencinin kendi küçük programı üzerinde, kendi makinesinde yapılır (Tigress'i resmî siteden kendisi indirir). Akış tümüyle savunma amaçlıdır: kendi kodunuzu koruyup korumanın maliyetini ölçersiniz.

1. Hazırlık: Küçük, sentetik bir program yazın (ör. bir erisim_ver denetimi). Birim testleriyle doğru çalıştığını gösterin.
2. Gizle: Bir dönüşüm hattı uygulayın (EncodeLiterals → EncodeArithmetic → Flatten → AddOpaque).
3. Davranışı doğrula: Aynı birim testlerini gizlenmiş sürümde çalıştırın — sonuç birebir aynı olmalı. Değilse hat yanlıştır.
4. Karşılaştır: Tersine derleyicide (ör. Ghidra/objdump) temiz ve gizli sürümün kontrol akışını karşılaştırın; temel blok sayısındaki artışı not edin.
5. Ölç: İkili boyut ve çalışma süresini önce/sonra ölçün.
6. Çeşitlendir: Aynı hattı iki farklı tohumla çalıştırın; iki ikilinin farklı olduğunu gösterin.
7. Raporla: Bulguları bir tabloya dökün (dönüşüm, boyut, süre, blok sayısı, tohum farkı) — bu tablo doğrudan S9/S15'e girer.

Sık yapılan hata: adım 3'ü (davranışı doğrula) atlayıp doğrudan adım 5'e (ölç) geçmek¶

Zaman baskısı altında bazı öğrenciler dönüşüm hattını çalıştırır, ikili boyutunu hemen ölçer ve "gizleme işe yaradı" sonucuna atlar — davranış doğrulamasını (adım 3) hiç yapmadan. Bu tehlikelidir çünkü büyümüş ama bozuk bir fonksiyon da boyut ölçütünde "başarılı" görünür; asıl soru büyüklük değil, doğruluğun korunup korunmadığıdır.

İşlenmiş örnek: yedi adımı gerçek bir öğrenci senaryosunda izleyelim (varsayımsal)¶

Bir öğrencinin kendi küçük "PIN doğrulama" fonksiyonu üzerinde bu yedi adımı nasıl uyguladığını, kısa bir kayıt tablosuyla özetleyelim (sayılar varsayımsaldır, yalnızca sürecin biçimini göstermek içindir):

Bu tablo biçimi, dönem projenizin S9/S15 bölümüne doğrudan kopyalanabilir bir şablondur; yalnız sayıları kendi ölçümlerinizle değiştirmeniz yeterlidir.

İşlenmiş örnek: bir adımın atlanması zinciri nasıl bozar (varsayımsal)¶

Yedi adımlık akışın "bir adımı atlamak zincirin geri kalanını anlamsızlaştırır" uyarısını bir tabloyla somutlaştıralım:

Bu tablo, yedi adımın hiçbirinin isteğe bağlı olmadığını gösterir: her satır, bir öncekinin atlanmasının hangi sonraki adımı anlamsızlaştırdığını işaret eder — tıpkı bölüm 4'teki dönüşüm hattında olduğu gibi, burada da "hat" fikri sürecin kendisine uygulanır.

9. Gizlemeyi derleme ve dağıtım hattına yerleştirmek (S15)¶

Gizleme, "en sonda elle yapılan bir iş" değil, derleme hattının bir adımı olmalıdır. Vize sonrası projenizin S15 bölümü tam olarak bunu belgeler:

• Yalnız hassas fonksiyonlar gizlenir (--Functions); gerekçesi yazılır.
• Her sürüm bir tohumla çeşitlendirilir; tohum ve sürüm kimliği kaydedilir.
• Gizlemeden sonra imzalama yapılır; sürüm kimliği ve özet değerleri (12. haftadaki TOE kimliği) tutarlı olur.
• Hat, sürekli entegrasyonda (CI) çalışır; her sürümde birim testleri + boyut/hız ölçümü otomatik koşar.

S15 hattını adım adım okuyalım¶

Görseldeki (h14-07) dört kutuyu (gizleme, imzalama, sürüm kimliği, CI) sıradaki bir listeye açalım — her adım bir öncekinin girdisidir, tıpkı bölüm 4'teki dönüşüm hattında olduğu gibi:

1. Derle (temiz): temiz.c (okunur kaynak) normal derlenir; birim testleri bu sürüme karşı çalıştırılır.
2. Gizle: yalnız --Functions ile işaretlenmiş hassas fonksiyonlara, kararlaştırılmış dönüşüm hattı (bölüm 4) uygulanır; yeni bir --Seed üretilir (bölüm 6'nın "tohumu her zaman kaydedin" kuralı burada devreye girer — CI, kullandığı tohumu bir günlüğe/artefakta yazmalıdır).
3. Yeniden derle (gizli): gizli.c normal derlenir; aynı birim testleri bu sürüme karşı da çalıştırılır (bölüm 2'deki ADIM 3'ün CI'deki karşılığı — davranış değişmediyse testler geçer, değiştiyse CI başarısız olmalıdır).
4. Ölç: boyut/komut/dal (bölüm 5, 7) otomatik ölçülür ve bir önceki sürümle karşılaştırılır; ani ve açıklanamayan bir sapma (ör. beklenmedik biçimde küçülme) bir hataya işaret edebilir.
5. İmzala: yalnız test + ölçüm adımlarını geçen ikili imzalanır — bölüm 4'teki "imza en son gelir" kuralının CI'deki karşılığı.
6. Sürüm kimliğini kaydet: kullanılan tohum, dönüşüm hattı, özet (hash) değeri ve imza birlikte bir kayda (S15 belgesine) yazılır — bu, 12. haftadaki TOE kimliği (sürüm + ikili + kaynak + özet) tanımının doğrudan uygulamasıdır; farkı, burada dört bileşene beşinci bir alan (kullanılan tohum) eklenmesidir, çünkü aynı kaynak+sürüm etiketi farklı tohumlarla kasıtlı olarak farklı ikililer üretebilir (bölüm 0'daki "Sürüm kimliği ve özet değeri" tanımını hatırlayın).

Bu altı adımı bir CI betiğinin kavramsal iskeleti olarak yazalım (belirli bir CI ürününün sözdizimi değil, adımların sırasını gösteren sözde kod):

asama derle_temiz:
    cc -O2 -o cikti/temiz temiz.c
    calistir_birim_testleri cikti/temiz

asama gizle:
    tohum = yeni_rastgele_tohum()
    tigress --Seed=$tohum --Transform=... --Functions=... --out=gizli.c temiz.c
    kaydet tohum -> gunluk/surum-$SURUM.txt

asama derle_gizli:
    cc -O2 -o cikti/gizli gizli.c
    calistir_birim_testleri cikti/gizli   # basarisizsa CI DURUR

asama olc:
    objdump -d cikti/gizli | olc_komut_dal erisim_ver >> gunluk/surum-$SURUM.txt

asama imzala:
    imzala cikti/gizli -> cikti/gizli.imzali

asama kaydet_surum:
    ozet = sha256(cikti/gizli.imzali)
    kaydet SURUM, tohum, ozet, donusum_hatti -> TOE-kayit-$SURUM.txt

Bu iskeletin her satırı, bu haftanın bir bölümüne karşılık gelir: derle_temiz → bölüm 2 ADIM 1; gizle → bölüm 4 (hat) + bölüm 6 (tohum); derle_gizlinin test adımı → bölüm 2 ADIM 3; olc → bölüm 0/5/7; imzala → bu bölümün "imza en son" kuralı; kaydet_surum → 12. haftadaki TOE kimliği.

İşlenmiş örnek: üç sürümlük bir TOE kaydı¶

Bölüm 0 ve bu bölümdeki "sürüm kimliği + tohum" fikrini, üç ardışık sürüm için doldurulmuş bir kayıt tablosuyla somutlaştıralım (varsayımsal):

Bu tablo, bölüm 6'daki "zamanda çeşitlendirme" örneğinin S15 belgesindeki karşılığıdır: her satır, o sürümün tam olarak hangi ikili olduğunu (tohum + hat + özet ile) ve o ikilinin imzalı ve test edilmiş olduğunu kanıtlar. v1.2'deki "hat değişikliği" (RandomFuns eklenmesi) da kayda geçmiştir — bu, 12. haftadaki "delta değerlendirme" (yalnız değişen kısmın yeniden değerlendirilmesi) için gereken bilgidir: bir değerlendirici v1.1'den v1.2'ye ne değiştiğini bu tablodan doğrudan okuyabilir, kaynak kodu satır satır karşılaştırmak zorunda kalmaz.

10. Dönem projesi: bu hafta (S9 ileri + S15 hat)¶

1. Bir dönüşüm hattı seçin ve S9'a yazın: hangi fonksiyonlar, hangi dönüşümler, hangi sırayla, neden.
2. Ölçüm tablosu: boyut, süre ve (varsa) blok sayısı — önce/sonra.
3. Çeşitlendirme: iki tohumla üretim ve fark ölçütü; uygulamayacaksanız gerekçesi.
4. S15 hattı: gizleme + imzalama + sürüm kimliği adımlarını bir diyagramla belgeleyin.
5. Davranış kanıtı: gizlenmiş sürümün birim testlerini geçtiğini gösterin (S16 ile bağ).

Doldurulmuş bir örnek: S9/S15 için "KURAL" şablonu¶

Dokuzuncu haftanın bölüm 4'ü, her koruma kararını "Neyi korur / Nasıl / Maliyet / Sınır" şablonuyla yazmayı öğretmişti. Bu haftanın Tigress hattı için aynı şablonu dolduralım:

Neyi korur?       : Sentetik erişim denetiminin mantığını (hangi jetonun geçerli sayıldığı)
                     tersine mühendisliğe karşı geciktirir.
Nasıl?            : Tigress --Transform=EncodeLiterals,EncodeArithmetic,Flatten,InitOpaque,AddOpaque
                     (bölüm 2 ADIM 2'deki tam komut), --Seed her sürümde yeni üretilir (bölüm 6).
Maliyet           : ~%359,1 komut artışı, ~%166,7 karmaşıklık (güç) artışı (bölüm 7, varsayımsal
                     demo sayılarıyla; gerçek sayılar `tigress-hatti.sh` ile ölçülür).
Sınır             : Dayanıklılık ve gizlilik bu demoda ölçülmedi (bölüm 7); tek başına Virtualize
                     olmadan whitebox düzeyinde bir koruma iddia edilmez (11. hafta ile karşılaştırın).

Bu doldurulmuş örneği kendi projenizde kendi fonksiyonunuz, kendi ölçtüğünüz sayılarla tekrarlayın; şablonun dört satırının hiçbiri boş bırakılmamalıdır.

Örnek doldurulmuş bir mini-rapor (S9/S15 için başlangıç şablonu)¶

Bu haftanın bütün parçalarını (dönüşüm hattı, ölçüm, çeşitlendirme, S15 hattı) tek bir örnek raporda birleştirelim. Aşağıdaki metin, sayıları kendi ölçümlerinizle değiştirerek doğrudan S9/S15 bölümünüze taşıyabileceğiniz bir başlangıç noktasıdır (bütün sayılar bu haftanın varsayımsal örnekleriyle tutarlıdır):

Fonksiyon         : erisim_ver
Neden hassas?     : Sentetik jeton denetimi (bölüm 1'deki karar akışı: hassas + orta değerli)
Dönüşüm hattı     : EncodeLiterals -> EncodeArithmetic -> Flatten -> InitOpaque(main) -> AddOpaque
Tohum (surum 1.0) : 1001
Davranış kanıtı   : Temiz ve gizli sürüm CEN429-OK / yanlis girdileriyle aynı çıktıyı verdi (ADIM 3: ayni cikti)
Maliyet           : Komut 22->101 (%359,1), dal 2->7, karmaşıklık (güç) 3->8 (%166,7)
Çeşitlendirme     : Seed=1001 ve Seed=2002 ile üretilen ikililer %60 bayt farkı gösterdi (cmp: farklı)
Dayanıklılık      : Ölçülmedi bu turda; bir sonraki iterasyonda KLEE ile sınanacak (bölüm 7)
Gizlilik          : Ölçülmedi bu turda; dal yoğunluğu haritası çıkarılacak (bölüm 7)
S15 durumu        : CI'de gizle->test->ölç->imzala->kaydet adımları tanımlı; sürüm kaydı TOE-kayit-1.0.txt
Sınır             : Tek başına whitebox düzeyinde koruma iddia edilmiyor (11. hafta ile karşılaştırın)

Bu şablonun her satırı, bu haftanın bir bölümüne karşılık gelir (yukarıdaki "Doldurulmuş bir örnek: KURAL şablonu" bölümüyle birlikte okuyun): Fonksiyon/Neden hassas → bölüm 1; Dönüşüm hattı/Tohum → bölüm 4, 6, 9; Davranış kanıtı → bölüm 2 ADIM 3; Maliyet → bölüm 5, 7; Çeşitlendirme → bölüm 6; Dayanıklılık/Gizlilik → bölüm 7; S15 durumu → bölüm 9; Sınır → bölüm 1, 9, 11.

Haftanın büyük resmi: bölümler nasıl birbirine bağlanıyor?¶

Çok fazla yeni terim ve örnek gördükten sonra, hepsini tek bir zincir olarak görmek zorlaşabilir. Aşağıdaki tablo bu haftanın on bir bölümünü sırayla özetler; her satır bir öncekine neyi eklediğini anlatır:

Bu tablo, sınav ya da proje hazırlığında "hangi bölümü unuttum?" sorusuna hızlı bir cevap verir: bir bölümün bir öncekine ne eklediğini anlatamıyorsanız, o bölümü yeniden okuyun; zincirin bir halkası eksikse geri kalanı da anlamını yitirir (tıpkı bölüm 4'teki dönüşüm hattında olduğu gibi).

11. Kendini sınama¶

12. Kaynaklar ve ileri okuma¶

• Tigress resmî sitesi ve çalışma sayfaları (tigress.wtf) — dönüşümler, sözdizimi, güncel sürüm (v4) ve lisans. Öğrenciler güncel sürümü ve koşulları buradan doğrular.
• C. Collberg, J. Nagra, Surreptitious Software — gizleme taksonomisi ve ölçme çerçevesi (9. haftayla ortak).
• S. Banescu, C. Collberg vd. — Tigress dönüşümlerinin sembolik yürütmeye (KLEE) dayanıklılığının ölçülmesi.
• Obfuscator-LLVM (O-LLVM) — derleyici tabanlı gizlemeye alternatif (9. hafta K-11).