Bugün

Öğrenme çıktısı (ÖÇ.3): RASP denetimlerini (bütünlük, anti-debug, ortam, kanca) tanımak · tepki politikası ve cihaz bağlama tasarlamak · RASP'in sınırlarını ve etik çerçevesini açıklamak

RASP = Runtime Application Self-Protection: uygulamanın çalışırken kendini izlemesi ve tehdide tepki vermesi. Algıla → savun → caydır. Ama tek denetim değil, katman.

Önceki haftalardan gelenler

• Beyaz kutu saldırgan modeli — cihazın sahibi olan kullanıcının aynı zamanda saldırgan olabildiği; belleği okuyup hata ayıklayıcı bağlayabildiği model (Hafta 1)
• Özet, MAC ve HMAC — özet bir veriden hesaplanan tek yönlü parmak izi; HMAC paylaşılan bir gizli anahtarla mesajın değişmediğini kanıtlar (Hafta 3)
• Ana sırdan anahtar türetme (HKDF) — bir ana sırdan Extract ve Expand adımlarıyla yeni anahtarlar türetme (Hafta 3)
• Cihaz bağlama — bir sırrın yalnızca belirli bir cihazda anlamlı olması, güvenlik kabuğunun en iç katmanı (Hafta 3)

Bu hafta: beyaz kutu modeli → MATE saldırgan modeli (Bölüm 1); HMAC → uygulamanın kendi kodunu doğrulamak (Bölüm 3); HKDF → cihaz parmak izinden anahtar türetmek (Bölüm 10); cihaz bağlama → bir RASP tepki politikasının parçası (Bölüm 10).

WAF ↔ RASP — şema

WAF ↔ RASP karşılaştırması

WAF "dışarıdan gelen istek zararlı mı?" sorar; RASP "ben kurcalandım mı?" sorar.

Saldırgan modeli: MATE

• MATE (Man-At-The-End): uygulamanın çalıştığı uç noktanın sahibi olan saldırgan. Belleği okur, kodu değiştirir, hata ayıklayıcıyla izler. 11. haftadaki beyaz kutu modeliyle aynıdır.
• Acı gerçek: cihazın sahibi saldırgansa, hiçbir istemci tarafı koruma nihai olarak kırılmaz değildir.
• O hâlde RASP neden var? Amaç kırılmazlık değil; saldırıyı ölçeklenemez ve pahalı kılmak.

Üç iş: algıla, savun, caydır

• Algıla: anormal ortamı/davranışı sez (debugger, emülatör, kurcalama).
• Savun: tehdit varsa işlevi kısıtla/durdur.
• Caydır: saldırıyı zahmetli kıl → saldırgan vazgeçsin.

RASP döngüsü — algıla → savun → caydır

RASP neyi tamamlar?

• Statik korumalar (4–5. hafta) çalışmadan geçerli.
• Gizleme (9/11/14) anlamayı zorlaştırır.
• RASP, program çalışırken aktif savunma ekler.

Gizleme RASP'ı gizler; RASP gizlemeyi çalışırken korur.

RASP neden gerekli?

• Beyaz kutu saldırgan programı çalıştırıp izler (debugger, Frida).
• Statik gizleme bunu tek başına durdurmaz.
• RASP "beni izliyorlar mı?" diye bakıp tepki verir.

Ana kural (baştan)

RASP tek başına aşılmaz değildir; katmanlı ve çeşitli denetimlerle güç kazanır.

Tek bir "root mu?" denetimi kolayca atlanır; onlarca farklı denetim birlikte zorlaşır.

Denetim ne zaman çalışır?

• Başlangıçta: açılışta ortam denetimi.
• Kritik işlem öncesi: ödeme/anahtar kullanımından hemen önce.
• Periyodik: arka planda düzenli.
• Rastgele: öngörülemez anlarda (saldırgan zamanlayamasın).

Denetim nerede çalışır?

• Native tarafta (C/C++): tersine mühendisliği zor, tercih edilir.
• Yönetilen tarafta (Java): daha kolay okunur, ama gerekli.
• Çapraz denetim: iki taraf birbirini denetler.

Çapraz denetim fikri

• Java tarafı, native kütüphanenin özetini denetler.
• Native taraf, Java tarafının bütünlüğünü denetler.
• Saldırgan ikisini birden atlamak zorunda.

Çok noktalılık ve sahte parametreler

• Çok noktalılık: aynı denetim kodun birçok yerinde, her seferinde biraz farklı biçimde yapılır; bir nokta yamalanınca diğerleri hâlâ çalışır.
• Korunan fonksiyonun içinde: değerli bir fonksiyon (ör. anahtar türetme) kendi giriş noktasında birkaç denetimi kendisi yapar — sahada on beşe yakın denetime kadar çıkabilir.
• Sahte parametreler: giriş noktasında, okunabilirlik için gizlenen ve bir bütünlük denetimini tetikleyen ek parametreler bulunabilir (4. hafta).

Denetim nasıl çalışır? (gizli)

• Denetim kodu gizlenir (9. hafta): saldırgan denetimi kolayca bulamasın.
• Sonuç opak (düz true/false değil).
• Tepki gecikmeli olabilir (birazdan).

Zayıf tasarım — tek karar noktası

if (debugger_present() || is_rooted() || integrity_broken())
    return ERROR;         /* patching this one line
                             bypasses everything */
decrypt_key();

Tek bir karşılaştırmayı ters çeviren saldırgan bütün korumayı geçer.

Güçlü tasarım — veri bağımlılığı

Denetim sonucu bir if'e değil, sonraki hesabın verisine karışır:

• Denetim sonuçları anahtar türetmeye katılır (temizse doğru anahtar, değilse farklı ama geçerli görünen anahtar).
• Denetim sonuçları opak değerlerle taşınır (4. hafta).
• Tepki, tetikleyiciden zaman ve kod olarak uzak bir yerde verilir.

Katmanlı denetim ağı

• Tek denetim değil, onlarca farklı denetim.
• Birbirini denetleyen ağ (checker network).
• Birini atlamak diğerini tetikler.

Katmanlar birbirini korur — şema

Mimari · özet şema

Bu bölümün kuralı (1–2)

Denetimi tek yerde, tek anda, tek if ile yapmayın.

Çok noktalı, çapraz, gizli ve veri bağımlı denetimler birlikte bir RASP mimarisi kurar.

Bölüm 1–2 — kısa sınama

1. RASP'in üç işi?
2. Çapraz denetim neden güçlü?
3. Neden tek denetim değil, ağ?

Bölüm 1–2 — cevaplar

1. Algıla (kurcalama/debug/emülatör), Savun (anahtar/veri koruma, işlevi kısıtla), Caydır (tepki: kapan/boz/bildir).
2. Denetimler birbirini kontrol eder; saldırgan birini kapatınca diğeri fark eder → tek noktayı susturmak yetmez.
3. Tek denetim tek yamayla atlanır; örtüşen ağ her düğümü ayrı kırmayı gerektirir → saldırı potansiyelini yükseltir.

Fikir

• Program, kendi kod bölümlerinin özetini hesaplar.
• Beklenen özetle karşılaştırır.
• Kurcalanmışsa özet tutmaz → tepki.

Nasıl çalışır? · adım adım

1. Derleme sonrası, kritik kod bloklarının özeti kaydedilir.
2. Çalışırken program aynı blokların özetini yeniden hesaplar.
3. Kayıtlı özetle karşılaştırır.
4. Fark varsa → kurcalama → tepki.

Adım 1 · özeti kaydet

• Derleme bittikten sonra, kritik kod/veri bölgesi belirlenir.
• Bu bölgenin özeti hesaplanır ve altın (golden) değer olarak saklanır.
• Bu değer, "kurcalanmamış hâlin" imzasıdır.

Adım 2 · çalışırken yeniden hesapla

• Program çalışırken, kayıtlı olan aynı kod/veri bölgesinin özetini yeniden hesaplar.
• Bu hesaplama derleme anında değil, çalışma anında olur.
• Hesaplama bir kez değil, periyodik de yapılabilir.

Adım 3 · karşılaştır

• Yeni hesaplanan özet, kayıtlı altın değerle karşılaştırılır.
• Karşılaştırma sabit zamanlı yapılmalı (memcmp değil): düz karşılaştırma ilk farklı baytta durup zamanlama sızdırır (3. hafta).
• Eşitse: bütünlük tamam.

Adım 4 · tepki ver

• Özet tutmuyorsa → kurcalama (yama) algılanmıştır.
• Sonuç doğrudan bir if'e değil, bir tepkiye bağlanır (10. bölüm).
• "Hemen çök" yerine daha akıllı bir tepki tercih edilir.

Self-hashing — şema

Neyi yakalar?

• Binary dosyaya yapılan yama (patch).
• Bir denetimi atlamak için değiştirilen baytlar.
• Enjekte edilmiş kod.

Demo 1 · çalışma zamanı bütünlük denetimi

code/week-06/01-integrity-hmac — self-hashing, HMAC-SHA-256.

• Ders kitabı (Viega & Messier, Tarif 12.2) bunu CRC32 ile yapar; CRC32 kriptografik değildir, saldırgan CRC'yi eşleyecek şekilde kolayca ayarlar. Biz HMAC-SHA-256 kullanıyoruz (gizli anahtar gerekir).
• Program kendi binary dosyasının özetini hesaplayıp altın değer olarak kaydeder.
• Binary dosyanın bir kopyası alınır, bir baytı değiştirilir (yama simülasyonu); yamalı kopyanın özeti altın değerle karşılaştırılır.

Demo 1 · özün kodu

/* Find own path, read the file, compute HMAC */
self_path(path, sizeof(path));
read_file(path, &data, &size);
crypto_hmac_sha256(RASP_KEY, 32, data, size, digest);

/* constant-time comparison */
unsigned char diff = 0;
for (int i = 0; i < 32; i++)
    diff |= expected[i] ^ digest[i];
if (diff == 0) { /* TAMAM */ } else { /* YAMA */ }

Bütünlük denetimi (animasyon)

Bütünlük denetimi — uç durum: ilk bayt yamalı

⚠️ Self-hashing tek başına yeterli değil

• Saldırgan, özet fonksiyonunu bulup her zaman "tutuyor" dedirtebilir.
• Ya da donanım kesme noktalarıyla denetimi atlar (van Oorschot vd.).
• Bu yüzden: gizle, çeşitlendir, çapraz denetle.

Güçlendirme

• Özet denetimi kodu gizli (9. hafta).
• Birden çok blok, örtüşen bölgeler.
• Sonuç düz karşılaştırma değil, hesaba karışır (denetim sonucu programın davranışını etkiler).

Örtüşen denetim

• Bir denetim başka bir denetimin kodunu da kapsar.
• Saldırgan birini kapatınca diğeri bozulur.
• Tek noktadan atlamak zorlaşır.

Bu bölümün kuralı (3)

Kritik kod/veri bölgelerinin bütünlüğünü çalışma zamanında kriptografik bir özetle (HMAC/imza) doğrulayın, CRC ile değil.

Denetimi tek noktada ve yalnız başlangıçta yapmayın; periyodik, çoklu ve örtüşen yapın.

Anti-debug yolları — şema

Neden debugger tehlikeli?

• Hata ayıklayıcı (debugger): programı adım adım çalıştırıp durduran, belleği okuyan araç (gdb, lldb, x64dbg, WinDbg).
• Saldırgan programı durdurup belleği okur, değer değiştirir.
• Denetimleri tek tek atlayabilir.
• RASP "bana debugger bağlı mı?" diye bakar.

Debugger algılama yolları (kavram)

• İşletim sisteminin "izleniyorum mu?" bilgisini sorma.
• Belirli hata ayıklama arayüzlerinin durumu.
• Zamanlama: bir işlem beklenenden çok uzun sürdüyse, biri adım adım çalıştırıyor olabilir.

Zamanlama tabanlı sezme

Debugger adımlaması işi yavaşlatır.

Demo 2 · hata ayıklayıcı algılama

code/week-06/02-debugger-detection — anti-debug, yalnız okuma.

• Program birden çok bağımsız sinyale bakar, hiçbir şeyi değiştirmez.
• Kendini ptrace ile de izlemez; yalnız /proc ve PEB alanlarını okur.
• demo.sh programı önce normal, sonra gdb altında çalıştırır.

/* Read TracerPid from /proc/self/status */
long tp = tracer_pid();
if (tp > 0) suspicious++;   /* a process is watching us */

Hata ayıklayıcı algılama (animasyon)

Hata ayıklayıcı algılama — uç durum: gdb bağlı

⚠️ Tespit–karşı-tespit yarışı

Anti-debug klasik bir silah yarışıdır: saldırgan ptrace'i LD_PRELOAD ile no-op yapabilir, IsDebuggerPresent'in dönüşünü yamalayabilir, PEB bayrağını temizleyebilir.

• Her tek yöntem bilinir ve atlanabilir.
• Güç: birçok farklı yöntem + gizleme + çeşitlendirme.
• Amaç yine caydırma ve gecikme.

Tepki nasıl?

• Hemen çökme her zaman iyi değil (saldırgana "burada denetim var" der).
• Daha iyi: gecikmeli, dolaylı tepki (birazdan bölüm 10).

Bu bölümün kuralı (4)

Anti-debug'ı tek bir if (IsDebuggerPresent()) exit(); olarak yazmayın.

Birden çok bağımsız sinyal toplayın, sonucu bir davranışa bağlayın, tepkiyi geciktirin.

Bölüm 3–4 — kısa sınama

1. Self-hashing neyi yakalar?
2. Neden tek başına yetmez?
3. Zamanlama nasıl debugger'ı ele verir?

Bölüm 3–4 — cevaplar

1. Kod/binary baytlarının değişmesini (yama, breakpoint/kod enjeksiyonu) — çalışırken kendi özetini hesaplayıp beklenenle karşılaştırır.
2. Saldırgan hash rutinini/beklenen değeri bulup atlar veya karşılaştırmayı NOP'lar; ayrıca yalnız statik değişikliği yakalar. Örtüşen denetim gerek.
3. Debugger/kesme noktası kodu yavaşlatır; iki nokta arası süre eşiği aşarsa hata ayıklama sezilir.

Emülatör yanlış pozitif — şema

Neden emülatör?

• Emülatör/VM: bir cihazı taklit eden yazılım ortamı (Android emülatör, QEMU).
• Saldırgan analizini gerçek cihaz yerine emülatörde yapar.
• Emülatörde durdurmak, izlemek, sıfırlamak kolaydır.
• RASP "gerçek cihazda mıyım?" diye bakar.

Algılama ipuçları (kavram)

• Emülatöre özgü donanım/sensör eksiklikleri.
• Tipik sahte tanımlayıcılar.
• Gerçek cihazda beklenen özelliklerin yokluğu.

Algılama teknikleri (somut)

Demo 3 · VM/emülatör ve zamanlama

code/week-06/03-environment-timing — yalnız CPU komutu ve saat okur.

(A) CPUID.1:ECX[31] hypervisor bit    : PRESENT
    Hypervisor vendor signature        : "Microsoft Hv"
(B) time for 2,000,000 iterations      : 0.662 ms
RESULT: a hypervisor was SEEN.

Bu çıktı gerçek bir Windows dizüstünde (Hyper-V) alındı.

VM/emülatör algılama (animasyon)

VM/emülatör algılama — uç durum: imza tamamen boş

⚠️ En önemli ders: yanlış pozitif

• Yukarıdaki çıktı hipervizör "PRESENT" dedi VE satıcı imzası görünür ("Microsoft Hv").
• Ama bu bir analiz ortamı değil — sıradan bir geliştirici makinesi!
• Modern Windows'ta Hyper-V, WSL2, VBS yüzünden çoğu makine hipervizör bildirir.

Yanlış pozitifin bedeli

• Bu bit tek başına "saldırgan analiz ediyor" anlamına gelmez.
• Bir uygulama sırf hipervizör gördüğü için çalışmayı reddetseydi, milyonlarca meşru kullanıcıyı engellerdi.
• Meşru kullanıcı: geliştirici, kurumsal VM kullanıcısı, WSL2/Hyper-V/VBS'li sıradan Windows kullanıcısı.
• RASP daima birden çok göstergeyi tartar ve her birinin atlatılabileceğini kabul eder.

Kural: risk skoru, ikili karar değil

• Ortam algılamayı bir risk skoru olarak kullanın.
• Birden çok göstergeyi birleştirin.
• Nihai kararı sunucu tarafı risk motoruyla birlikte verin.

Sahada nasıl uygulanır?

• Mobil dünyada karşılığı emülatör algılamadır: ro.kernel.qemu, sahte sensörler, tipik IMEI/seri değerleri.
• Aynı ilke geçerlidir: sinyal, kanıt değil.
• Kombinasyon + sunucu tarafı denetim.

Bu bölümün kuralı (5)

Emülatör/VM algılamada tek bir bit asla "saldırı" anlamına gelmez.

Sert tepki yerine risk skoru; sonuç sunucu tarafı doğrulamayla birlikte değerlendirilir.

Kısa tarihçe — statikten dinamiğe

• 1990'lar — IAT/PLT-GOT kancaları: elle yazılmış, hedefe özel araçlar.
• 2000'ler — LD_PRELOAD / DLL enjeksiyonu: genel amaçlı ama statik.
• 2013–2014 — Frida ortaya çıktı: kanca kodu JavaScript ile çalışma zamanında yazılır, derleme gerekmez.

Kanca algılama — şema

Kanca (hook) tehdidi

• Saldırgan kritik bir fonksiyonu kancalar: çağrıyı araya girip değiştirir.
• Örnek: "imza geçerli mi?" fonksiyonunu her zaman "evet" döndürtmek.
• Araç: Frida, Xposed.
• Enstrümantasyon: çalışan programa kod enjekte edip davranışını izleme/değiştirme; Frida bunun en yaygın aracıdır.

LD_PRELOAD kancası

• Linux'ta bir kütüphaneyi programdan önce yükletip fonksiyonları değiştirme.
• Kritik fonksiyon saldırganın sürümüyle değişir.
• RASP yüklenen kütüphaneleri denetler.

Kanca algılama yolları (kavram)

• Beklenmeyen yüklenmiş kütüphaneler/modüller.
• Bilinen enstrümantasyon araçlarının izleri (bellekte, portlarda).
• Fonksiyon adreslerinin beklenenden sapması.

⚠️ Zayıf yol: getenv

if (getenv("LD_PRELOAD") == NULL) printf("temiz\n");

getenv'in kendisi de kancalanıp NULL döndürebilir. Bu yüzden kaynağı doğrulamak gerekir:

1. Kritik fonksiyonu çöz (dlsym) → 2. geldiği modülü bul (dladdr) → 3. meşru mu denetle → 4. karar ver.

Adım 1 · fonksiyonu çöz

void *p = dlsym(RTLD_DEFAULT, "time");

• dlsym, çalışma anında hangi fonksiyonun çağrılacağını bulur.
• Önyüklü bir kanca varsa, dlsym onu döndürür (manipüle edilmiş sonuç).

Adım 2 · kaynağı bul

Dl_info info;
dladdr(p, &info);   /* the .so that provides the function */

• dladdr, bir adresin hangi paylaşımlı nesneden (.so) geldiğini söyler.
• getenv sahteciliğine dayanmaz — doğrudan bellek adresine bakar.

Adım 3 · meşru mu denetle

int hook = !is_legitimate(info.dli_fname);

• Beklenen kaynak libc, vDSO ya da dinamik yükleyicidir.
• Yabancı bir .so'dan geliyorsa → kanca var.

Adım 4 · karar ver

• Meşru kaynak listesinde yoksa → kanca bayrağı kaldırılır.
• Sonuç tek başına bırakılmaz; tepki politikasına bağlanır (10. bölüm).
• Birden çok fonksiyon için tekrarlanır (tek fonksiyon yetmez).

Fonksiyon bütünlüğü

• Kritik fonksiyonun ilk baytları beklenen mi?
• Kanca genelde başa bir atlama yerleştirir → baytlar değişir.
• Değişmişse → kanca var.

LD_PRELOAD sembol çözümleme sırası (animasyon)

LD_PRELOAD sırası — uç durum: kanca vDSO'dan hemen sonra

⚠️ Kanca algılama da atlanabilir

• Gelişmiş araçlar izlerini gizler.
• Güç: çoklu yöntem + gizleme + sunucu tarafı denetim.

Bu bölümün kuralı (6)

Kanca algılamada getenv(LD_PRELOAD) gibi manipüle edilebilir kaynaklara güvenmeyin.

Kritik fonksiyonların kaynağını (dlsym+dladdr) doğrulayın; birden çok fonksiyonu kontrol edin.

Kısa tarihçe — "yalnız RAM'de" yetmez

• 2008 — Halderman ve ortak yazarları, "Cold Boot Attacks" makalesinde DRAM'in güç kesilince bile
  saniyeler-dakikalar boyunca içeriğini koruduğunu gösterdi; bir dizüstünü soğutup yeniden başlatarak
  bellekteki tam disk şifreleme anahtarlarını kurtardılar.
• Bu, "kısa ömür" ve "asla açık tutma" önlemlerinin doğrudan motivasyonudur.

Bellek koruma katmanları — şema

Sorun

• Hassas değerler (anahtar, sayaç) bellekte durur.
• Saldırgan belleği okuyup/değiştirip denetimi atlayabilir.

Saldırgan bellekle ne yapar?

Hepsi için saldırganın süreç belleğine erişmesi gerekir (debugger, OS arayüzü, enjekte kütüphane).

Korunan sayaç fikri

• Kritik bir sayacı düz tutmak yerine:
  • bir gölge kopya + özet ile birlikte tut.
  • her okuma/yazmada tutarlılığı denetle.

Korunan değer · kavram

typedef struct { uint32_t value; uint32_t shadow; uint32_t mac; } Protected;
/* read: is value == ~shadow, and is mac correct? */

Saldırgan yalnız value'yi değiştirirse tutarsızlık yakalanır.

Bellek izleme tespiti

• Hassas bölgelere beklenmedik erişim izleniyor mu?
• Bellek dökümü/tarama izleri.
• Amaç: canlı bellek analizi maliyetini artırmak.

⚠️ Bellek koruması sınırlı

• Kararlı saldırgan yine erişebilir.
• Amaç: geciktirmek, anahtarı kısa ömürlü kılmak (10. hafta).

Bu bölümün kuralı (7)

Bellekte az, kısa ve dağınık tutun; kritik değeri gölge kopya + özetle koruyun.

Tutarsızlık bir tepkiye bağlanmalı — sessizce yok saymak korumayı boşa çıkarır.

Bölüm 5–7 — kısa sınama

1. Emülatör algılamada neden yanlış pozitif riski var?
2. Kanca (hook) fonksiyon baytlarını neden değiştirir?
3. Korunan sayaç neyi yakalar?

Bölüm 5–7 — cevaplar

1. Meşru kullanıcı da VM/emülatör/CI kullanabilir; zayıf sinyaller gerçek cihazda da görülür → suçsuzu engelleme riski. Sertliği derecelendir.
2. Hook, hedefin ilk baytlarını bir atlama (jmp/trampoline) ile değiştirir ki çağrı saldırgan koduna sapsın → prolog baytları beklenenden farklı olur.
3. Kontrol akışının atlanmasını: kritik denetimler çalıştıkça sayaç artar; beklenen değere ulaşmazsa bir denetim baypas edilmiştir.

Kısa tarihçe — paket imzalama

• Android 1.0 (2008) — orijinal APK imzalama (v1): değiştirilmiş APK orijinal imzayı taşıyamaz.
• Android 7.0 Nougat (2016) — APK Signature Scheme v2: dosya dosya değil, APK'nin tamamı imzalanır.
• Android 9 Pie (2018) — v3, aynı ilkeye anahtar döndürme desteği ekledi.

Kök göstergesinden karara — şema

Köklü cihaz neden risk?

• Kök (root) = tam yetki.
• Korumalar zayıflar; saldırgan belleğe, dosyaya, sürece erişir.
• RASP "cihaz köklü mü?" diye bakar.

Kök algılama (kavram)

• Bilinen kök araçlarının/dosyalarının varlığı.
• Normalde kısıtlı olan işlemlerin yapılabilmesi.
• Sistem bütünlüğü göstergeleri.

⚠️ Kök algılama atlanabilir

• Kök gizleyiciler (root hiding) vardır.
• Tek gösterge yetmez; birçok gösterge + sunucu denetimi.
• Tepki: kritik işlevi kısıtla, tümden engelleme (kullanıcı mağdur olmasın).

Bileşen imza doğrulaması

• Çağıran/yüklenen bileşenin dijital imzası beklenen mi?
• Sahte/değiştirilmiş bir uygulama kütüphaneyi çağırıyorsa yakala.
• Örnek: yalnız beklenen imzalı ana uygulama SDK'yı kullanabilsin.

İmza + özet birlikte

• İmza: bileşen kim tarafından yayımlandı?
• Özet: bileşen değişti mi?
• İkisi birlikte sahtekârlığı zorlaştırır.

Kök/ayrıcalık gösterge taraması (animasyon)

Kök göstergesi — uç durum: birden çok işaret + yükseltilmiş

Bileşen imzası doğrulama (animasyon)

Bileşen imzası — uç durum: modül kısaltıldı

Bu bölümün kuralı (8)

Kök/ayrıcalık göstergeleri kanıt değil, sinyaldir — kolayca sahtelenir.

Dinamik yüklenen her bileşeni yüklemeden önce kriptografik olarak doğrulayın; mümkünse karşılıklı doğrulama kurun.

Kısa tarihçe — kurcalamaya dayanıklılıktan CFI'ye

• 1996 — Aucsmith: birbirini çapraz doğrulayan dağıtık bütünlük kontrolleri fikri.
• 2001 — Collberg/Thomborson taksonomisi; Chang/Atallah "guard" (bekçi) fikri — birden çok denetleyici.
• 2005 — Abadi, Budiu, Erlingsson, Ligatti: Control-Flow Integrity (CFI)'yi akademik olarak tanımladı.

Tek if neden yetmez?

if (signature_valid()) proceed();   /* single point */

• Saldırgan bu tek dalı yamalar → denetim atlanır.
• 9. haftadaki opak boolean + rastgele çıkış burada kritik.

Kontrol akışı sayacı

• Kritik denetimler doğru sırayla geçilmeli.
• Her denetim bir sayacı günceller.
• Sonda sayaç beklenen değilse → biri atlandı.

Kontrol akışı sayacı — şema

Çift sayaç

• count (kaç kontrol noktası çalıştı) + visited_mask (hangi kontrol noktaları çalıştı, bit kümesi).
• İkisi de HMAC zincirinden ayrı, okunabilir bir teşhis verir — ama kararı tek başına vermez.
• Saldırgan bunları yamalasa bile gerçek anahtar hâlâ HMAC zincirinden türer (Demo 5).

Sonucu davranışa bağla

• Denetim sonucu düz bir if değil.
• Sonuç, bir sonraki adımın hesabına girer (ör. bir anahtar türetmesine).
• Atlanırsa program yanlış çalışır (sessizce bozulur).

Kontrol akışı sayacı (animasyon)

Kontrol akışı sayacı — uç durum: yanlış sırada

Bu bölümün kuralı (9)

Kritik kararları tek bir boolean'a bağlamayın (yamalanır).

Güvenlik kontrollerini bir kontrol akışı sayacına ve mümkünse bir veri bağımlılığına bağlayın.

"Hemen çök" neden kötü?

• Tepki politikası: RASP bir tehdit görünce ne yapacağına karar vermesidir.
• Saldırgana "işte tam burada denetim var" der.
• Denetimi bulup atlamayı kolaylaştırır.
• Daha akıllı tepkiler gerekir.

İyi tepki örnekleri

• Gecikmeli: tehdidi sonra, başka yerde tetikle (kaynağı gizle).
• Dolaylı: işlevi sessizce bozar (yanlış sonuç üret).
• Sunucuya bildir: risk skoru artır, işlemi sunucuda reddet.

Tepki tasarımı

• Kullanıcı deneyimini bozma (yanlış pozitif riski).
• Sert tepki yalnız yüksek güvenli göstergede.
• Çoğu durumda: kısıtla + sunucu denetimi.

Algıla → karar → tepki döngüsü

Demo 8 (code/week-06/08-tamper-response) bu döngüyü tek bir öz koruma motorunda birleştirir:

1. Bir dizi kontrol çalışır (bütünlük, anti-debug, ortam…).
2. Sır, cihaz-bağlı bir anahtarla (HKDF + AES-GCM) sarılıdır.
3. Başarısız kontrol sayısı (ve cihaz uyuşup uyuşmadığı) dört durumlu bir tepki politikasına
   (NORMAL/WARN/DEGRADE/LOCK) çevrilir — ikili bir "temiz/tamper" kararı değil.

RASP hattı: algıla → karar ver → tepki ver (animasyon)

RASP hattı — uç durum: cihaz uyuşmuyor ama kontroller geçti

Tepki politikası durum makinesi (animasyon)

Durum makinesi — uç durum: her zaman LOCK

Cihaz bağlama — şema

Cihaz bağlama

• Anahtar/veri yalnız belirli cihazda anlamlı.
• Kopyalanırsa (başka cihaz) işe yaramaz.
• Kod sökmeye (9/11. hafta) karşı.

Cihaz bağlama akışı · adım adım

Adım 1 — parmak izini oku: cihazın donanım/OS parmak izi okunur (5. hafta).

Adım 2 — anahtar türet: parmak izi + sürüm dizesinden HKDF ile bir anahtar türetilir; sır bu anahtarla AES-GCM ile sarılır.

Adım 3 — taşınırsa aç: dosya başka bir cihaza kopyalansa bile, o cihazın parmak izi farklı olduğundan türetilen anahtar tutmaz → sır açılamaz.

Caydırma · nihai amaç

RASP saldırıyı imkânsız kılmaz; zahmetli ve riskli kılar.

Yeterince katman + sunucu denetimi → saldırgan vazgeçer ya da yakalanır.

Tepki: nasıl karar verilir?

1. Gösterge ne kadar güvenilir? Çok güvenilir → reddet + sunucuya bildir. Belirsiz → devam et, risk skorunu artır.
2. Kullanıcı deneyimi etkilenir mi? Yanlış pozitif riski yüksekse sert tepki verme; sessiz kısıtlama + sunucu denetimi tercih et.
3. Tepki denetimi ele verir mi? Hemen çökme kaynağı gösterir; gecikmeli/dolaylı tepki kaynağı gizler.

Bu bölümün kuralı (10)

Tepkiyi tetikleyiciden ayırın: hemen exit() saldırgana yol gösterir.

Tamper anında sırrı silin, çökmek yerine decoy döndürün, olayı sunucuya bildirin, sırrı cihaza bağlayın.

Bölüm 8–10 — kısa sınama

1. Köklü cihaz neden risk?
2. Tek if'i sayaç neden güçlendirir?
3. Neden "hemen çök" kötü bir tepki olabilir?

Bölüm 8–10 — cevaplar

1. Root/jailbreak bellek okuma/yazma, hook, sertifika enjeksiyonu engellerini kaldırır → RASP varsayımları ve izolasyon çöker.
2. Tek if bir NOP/yama ile atlanır; sayaç denetimin gerçekten çalıştığını sonradan doğrular (dağıtık kanıt) → tek yama yetmez.
3. "Hemen çök" saldırgana denetimin tam yerini gösterir ve yanlış pozitifte meşru kullanıcıyı vurur. Gecikmeli/sessiz/aldatıcı tepki daha iyi.

RASP'in sınırları

• Her tek denetim atlanabilir.
• Köklü cihazda güç azalır.
• Yanlış pozitif → gerçek kullanıcı mağdur olabilir.
• Bakım maliyeti yüksek (araçlar gelişir).

RASP'in sınırları — şema

O yüzden RASP...

• Katmanlı (çok denetim), çeşitlendirilmiş, gizli.
• Sunucu tarafı denetimle birlikte (asıl güvence).
• Tek başına "aşılmaz" iddiası yanlıştır.

Etik ve kullanıcı

• RASP kullanıcının cihazında çalışır; aşırı veri toplama etik değil.
• Yanlış pozitif kullanıcıyı hizmetten edebilir → dikkatli tepki.
• Şeffaflık ve gizlilik dengesi.

⚠️ Güvenli örnek kuralı

• Ders demoları öğrenci cihazına zarar vermez.
• Gerçek kök/sistem değişikliği yok; sentetik göstergeler.
• Amaç kavramı öğretmek, saldırı aracı yapmak değil.

Uçtan uca: bir RASP katmanı kurmak

Sentetik bir "lisans denetimi"ni RASP ile koruyalım:

• bütünlük denetimi
• hata ayıklayıcı denetimi
• akıllı tepki

Adım 1 · korunacak nokta

int license_is_valid(void) {
    /* ... check ... */
    return result;   /* the attacker's target */
}

Bu fonksiyon ve onu çağıran akış kritik.

Adım 2 · bütünlük denetimi ekle

• Derleme sonrası bu bölgenin özetini kaydet.
• Çalışırken yeniden hesapla, karşılaştır.
• Fark → kurcalama bayrağı.

Adım 3 · anti-debug ekle

• Zamanlama + OS göstergesiyle "izleniyor muyum?".
• Sonucu tek başına bırakma; başka denetimle birleştir.

Adım 4 · sonucu davranışa bağla

• license_is_valid sonucu düz true/false değil.
• Bütünlük + anti-debug göstergeleri, sonucun hesabına girer.
• Kurcalama varsa fonksiyon yanlış çalışır.

Adım 5 · tepki

• Hemen çökme yerine: bayrağı sunucuya bildir, işlevi kısıtla.
• Gecikmeli tetik: kaynağı gizle.

Adım 6 · gizle ve çeşitlendir

• Denetim kodunu gizle (9. hafta).
• Her sürümde farklı yerleştirme (çeşitlendirme).
• Çapraz denetim ekle.

Adım 7 · ölç ve belgele

• Kaç denetim, nerede, hangi tepki?
• Başarım maliyeti (denetimler yavaşlatır).
• S10'a yaz.

Neden bu diyalog?

Güvenlik bir hamle-karşı hamle oyunudur.

Her savunmaya bir saldırı, her saldırıya yeni savunma.

Katmanlı savunma bu yüzden gereklidir.

Bütünlük · diyalog

• Savunma: self-hashing ekle.
• Saldırgan: özet fonksiyonunu bul, hep "tutuyor" dedirt.
• Savunma: özeti gizle, örtüştür, sonucu davranışa bağla.

Anti-debug · diyalog

• Savunma: debugger denetimi ekle.
• Saldırgan: denetimi bul, atla.
• Savunma: çok yöntem + zamanlama + gizleme; tepkiyi gecikmeli yap.

Hook · diyalog

• Savunma: fonksiyon baytlarını denetle.
• Saldırgan: kancayı gizle, baytları geri düzelt.
• Savunma: çapraz denetim + sunucu tarafı doğrulama.

Kök · diyalog

• Savunma: kök göstergelerini denetle.
• Saldırgan: kök gizleyici kullan.
• Savunma: çok gösterge + sunucu risk skoru; sert tepki değil kısıtlama.

Diyalogdan ders

• Tek savunma her zaman aşılır.
• Güç: çokluk + gizlilik + çeşitlilik + sunucu.
• Amaç: saldırıyı ekonomik olmaktan çıkarmak.

Katalogdan ders

• Her denetimin bir kör noktası var.
• Tek başına hiçbiri yeterli değil.
• Katalogdan birçoğunu seç, birleştir, çeşitlendir.

Denetim seçimi

• Varlığın değerine göre kaç katman?
• Platforma göre hangi denetimler anlamlı?
• Başarım bütçesi ne kadar?

Kararı ve gerekçesini S10'a yaz.

Sık yapılan hatalar

• Tek denetime güvenmek.
• Denetimi gizlememek (kolay bulunur).
• "Hemen çök" tepkisi (kaynağı ele verir).
• Sert tepki + yüksek yanlış pozitif (kullanıcı mağdur).
• Sunucu denetimini atlamak (asıl güvence orada).

Proje · S10 (RASP + tepki)

• [ ] En az iki farklı RASP denetimi (ör. bütünlük + anti-debug).
• [ ] Denetimler gizli ve çeşitlendirilmiş.
• [ ] Çapraz denetim (Java ↔ native) varsa belgele.
• [ ] Denetimlerin ne zaman/nerede çalıştığını belgele.
• [ ] Tepki politikası akıllı (gecikmeli/dolaylı — "hemen çök" değil).
• [ ] Cihaz bağlama kararı ve gerekçesi.
• [ ] Sunucu tarafı doğrulama var mı?
• [ ] Yanlış pozitif planı.
• [ ] Sınır ve kalan risk (neyi korumaz).

Değerlendirici gözüyle

• "RASP var" yetmez; kaç katman, nasıl gizli, nasıl tepki?
• Sunucu denetimiyle nasıl birleşiyor?
• Yanlış pozitif riski nasıl yönetiliyor?

Soru 1

RASP'in üç işi nedir?

Cevap: Algıla (anormal ortam/kurcalama), savun (işlevi kısıtla/durdur), caydır (maliyeti yükselt).

Soru 2

Self-hashing neyi yakalar, neden tek başına yetmez?

Cevap: Binary'ye yapılan yamayı/kurcalamayı yakalar. Saldırgan özet fonksiyonunu bulup atlatabildiği için tek başına yetmez; gizleme + çapraz + örtüşen denetim gerekir.

Soru 3

Çapraz denetim neden güçlüdür?

Cevap: Java native'i, native Java'yı denetler; saldırgan ikisini birden atlamak zorunda kalır.

Soru 4

Zamanlama tabanlı anti-debug nasıl çalışır?

Cevap: Küçük bir iş beklenenden çok uzun sürdüyse, biri programı adım adım çalıştırıyor (debugger) olabilir.

Soru 5

Tek if denetimini kontrol akışı sayacı neden güçlendirir?

Cevap: Denetimlerin doğru sırayla geçtiğini sayar; tek bir dalı yamalamak sayacı bozar, atlanma yakalanır.

Soru 6

"Hemen çök" neden her zaman iyi bir tepki değildir?

Cevap: Saldırgana denetimin tam yerini gösterir. Gecikmeli/dolaylı tepki + sunucu bildirimi daha iyidir.

Soru 7

Emülatör algılamada yanlış pozitif riski neden önemli?

Cevap: Gerçek cihaz/geliştirici ortamı emülatör gibi görünebilir; sert tepki gerçek kullanıcıyı mağdur eder.

Soru 8

RASP'in temel sınırı nedir?

Cevap: Her tek denetim atlanabilir; köklü cihazda zayıflar. Güç katmandan, çeşitlilikten ve sunucu denetiminden gelir.

Örnek · çoktan seçmeli

RASP çapraz denetiminde amaç nedir?

A) Kodu küçültmek
B) İki tarafı da atlamayı zorunlu kılmak ✓
C) Şifreleme hızını artırmak
D) Günlüğü kapatmak

Örnek · kısa cevap

Bir bütünlük denetimini güçlendiren üç yöntem yazın.

Gizleme · çoklu/örtüşen blok · çapraz denetim · sonucu davranışa bağlama.