Hafta 6 — Çalışma Zamanı Uygulama Öz Koruması (RASP)¶

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.

cd code
.\build.ps1
cd week-06\01-integrity-hmac
.\demo.ps1        # ya da demo.cmd dosyasına çift tıklayın

cd code
./build.sh
cd week-06/01-integrity-hmac
sh demo.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 haftalardan gelenler¶

• Beyaz kutu saldırgan modeli — cihazın sahibi olan kullanıcının aynı zamanda potansiyel saldırgan olduğu; belleği okuyup hata ayıklayıcı bağlayabildiği ve kodu değiştirebildiği model (Hafta 1, §3; "beyaz kutu saldırganın altı yolu" tablosuna da bakınız: Hafta 1, §5). Bu hafta bu modeli MATE adıyla RASP'in tek saldırgan modeli yapıyoruz (§1.1).
• Özet, MAC ve HMAC — özet bir veriden hesaplanan sabit boyutlu, tek yönlü bir parmak izidir; MAC/HMAC ise paylaşılan bir gizli anahtarla mesajın değişmediğini kanıtlar (Hafta 3, §2.4). Bu hafta HMAC-SHA-256'yı uygulamanın kendi kodunu doğrulamak (§3) ve bir kontrol akışı zinciri kurmak (§9) için kullanıyoruz.
• Ana sırdan anahtar türetme (HKDF) — RFC 5869 HKDF, bir ana sırdan Extract ve Expand adımlarıyla yeni anahtarlar türeten fonksiyondur (Hafta 3, §7). Bu hafta aynı iki adımı, bir ana sır yerine bir cihaz parmak izinden anahtar türetmek için elle izliyoruz (§10.1).
• Cihaz bağlama — bir sırrın yalnızca belirli bir cihazda anlamlı olması, güvenlik kabuğunun en iç katmanıdır (Hafta 3, §13.1). Bu hafta bu katmanı bir RASP tepki politikasının parçası yapıyoruz (§10).

Bu haftanın kavram haritası¶

Kavramlar birbirine nasıl bağlanır?¶

Yukarıdaki kavramlar rastgele bir liste değildir; her biri bir öncekinin üstüne oturur. Bir kavramı ilerideki bölümlerde unutursanız, aşağıdaki tablonun "önkoşul" sütununa dönüp önce onu tazeleyin.

1. RASP nedir? Algılama → savunma → caydırma¶

İlk beş hafta boyunca uygulamayı statik olarak sağlamlaştırdık: girdiyi doğruladık (Hafta 1, 4), veriyi şifreledik (Hafta 3), kodu gizledik (Hafta 4, 5). Ama bütün bunlar bir varsayıma dayanıyordu: program yazıldığı gibi çalışacak. Bu hafta o varsayımı bırakıyoruz ve çalışma anına (runtime) — programın derlenip diskte durduğu an değil, fiilen çalıştığı an — bakıyoruz. Uygulama, çalışırken düşman bir ortamda olabilir: kullanıcı cihazın sahibidir, root almış, hata ayıklayıcı bağlamış, kod parçalarını yamalamış, fonksiyonları kancalamış olabilir.

RASP (Runtime Application Self-Protection — Çalışma Zamanı Uygulama Öz Koruması), uygulamanın kendi içine gömülen, çalışma zamanında kendini izleyen ve saldırıya tepki veren korumalardır. Uygulama kendi kendinin muhafızıdır.

RASP üç iş yapar; bu haftanın omurgası bu üçlüdür:

• Algılama (detection): Bir şeyin yanlış olduğunu anlamak — binary yamalanmış, bir hata ayıklayıcı bağlı, ortam bir emülatör, uygulama root'lu cihazda, bileşen yeniden paketlenmiş.
• Savunma (defense): Algılamaya anlamlı bir yanıt vermek — sırrı sil, işlemi reddet (fail-closed), anahtarı cihaza bağla, kritik işlemi kontrol akışına bağla.
• Caydırma (deterrence): Saldırganın işini pahalılaştırmak — çökmek yerine sahte (decoy) sonuç döndür, tepkiyi geciktir, olayı sunucuya bildir. Amaç kırılmazlık değil; saldırıyı yeterince yavaşlatmaktır (Hafta 4'teki "gizleme geciktirir, engellemez" ilkesinin RASP hâli).

Bu üçlü, tek bir hat olarak da görülebilir: algıla → karar ver → tepki ver. Aşağıdaki animasyon, bir dizi bağımsız kontrolün (12 aşamaya kadar) nasıl tek bir "başarısız sayısına" indirgendiğini, bu sayının (ve cihaz uyuşmazlığının) nasıl bir duruma (NORMAL/WARN/DEGRADE/LOCK) çevrildiğini ve her durumun hangi somut tepkiye yol açtığını uçtan uca gösterir (bkz. Bölüm 10, Demo 8'in gerçek motoru):

normal/two-failed/edge örneklerini deneyin; kaç kontrolün başarısız olduğunu ve cihaz uyuşup uyuşmadığını değiştirerek dört durumun her birine ulaşabilirsiniz.

1.1 Saldırgan modeli: MATE ("Man-At-The-End")¶

Hafta 1'de üç saldırgan tipini görmüştük. RASP'in dünyası tümüyle MATE'tir: saldırgan uygulamanın çalıştığı uç noktanın sahibidir. Sunucuya karşı saldırgan dışarıdadır (ve TLS, kimlik doğrulama korur); ama istemci uygulamada saldırgan her şeyi görür: belleği okuyabilir, kodu değiştirebilir, hata ayıklayıcıyla adım adım izleyebilir. Bu, Hafta 11'deki beyaz kutu modeliyle aynı varsayımdır.

MATE saldırganını, Hafta 1'de gördüğümüz diğer saldırgan tiplerinden ayıran şey konumdur, yetenek değil:

Bu tablo neden önemli? Çünkü bir MATE saldırganına karşı ağ saldırganı savunmaları (TLS, sunucu tarafı girdi doğrulama) hiç işe yaramaz — TLS bağlantının içeriğini korur, ama saldırgan bağlantıyı açan uygulamanın kendisidir; şifreyi çözdüğü anda veriyi kendi belleğinde açık olarak görür. Bu yüzden RASP, önceki haftaların savunmalarının yerine değil, üstüne eklenir.

1.2 Bu haftanın örnek mimarisi ve ana fikri¶

Dönem boyunca kullandığımız örnek mimariyi hatırlayın: bir mobil ödeme uygulaması ve onun kritik işlerini yapan bir güvenlik kütüphanesi (native C/C++). Telefon güvenilmez ortamdır. Bu hafta o kütüphaneye, çalışırken kendini koruyan bir RASP katmanı ekliyoruz. Bütün örnek değerler sentetiktir (uydurma); gerçek anahtar, kart numarası, cihaz kimliği ya da ürün adı kullanılmaz.

Ana fikir tek cümlede: tek bir kontrole güvenme. Her algılama sinyali tek başına atlatılabilir; güç, birden çok bağımsız sinyalin, bir tepki politikasının ve cihaz bağlamanın birlikte çalışmasından gelir. Bu, Hafta 3'teki güvenlik kabuğunun çalışma zamanındaki karşılığıdır.

1.3 İşlenmiş örnek: aynı olayı üç farklı şekilde ele almak¶

Algılama, savunma ve caydırmanın neden ayrı kavramlar olduğunu somutlaştıralım. Senaryo: kripto kütüphanesi, ödeme anahtarını açmadan hemen önce bir hata ayıklayıcının bağlı olduğunu fark ediyor (Bölüm 4'teki TracerPid sinyali > 0). Üç uygulamacı bunu üç farklı şekilde ele alıyor:

1. Yalnız algılama, tepki yok: Kod suspicious değişkenini artırır ama hiçbir yere bakmaz; fonksiyon normal akışına devam eder. Sonuç: hata ayıklayıcı bağlı bir saldırgan anahtarı doğrudan okur. Algılama boşa gitmiştir — çünkü bir savunmaya bağlanmamıştır.
2. Algılama + kaba savunma: Kod if (suspicious) exit(1); yazar. Sonuç: saldırgan anahtarı okuyamaz, ama programın tam olarak hangi satırda durduğunu görür; birkaç deneme ile o if'i yamalar (Bölüm 3'teki "checker'ın kendisi de yamalanır" dersiyle aynı zaaf).
3. Algılama + savunma + caydırma: Kod, sinyali doğrudan exit()'e değil, anahtar türetme işlemine veri olarak karıştırır (Bölüm 9'daki kontrol akışı sayacının küçük hâli) ve tetiklenirse decoy bir sonuç üretir (Bölüm 10). Sonuç: saldırgan bir hata mesajı görmez; "başarılı" görünen ama işe yaramaz bir sonuç alır ve hangi kontrolün tetiklendiğini bilemez.

Bu üç seçenek aynı algılama koduna sahiptir; farkları yalnız savunma ve caydırma katmanındadır. Bu haftanın demoları ilerledikçe hep üçüncü yaklaşıma yaklaşacağız (bkz. Bölüm 10.2'deki tam karşılaştırma).

2. RASP mimarisi: denetimler ne zaman, nerede ve nasıl çalışır?¶

Önümüzdeki bölümlerde tek tek denetimleri (bütünlük, hata ayıklayıcı, ortam, kanca, root) göreceğiz. Ama sahada bir RASP çözümünün gücü, tek tek denetimlerin ne kadar akıllı olduğundan çok, bu denetimlerin nasıl bir araya getirildiğinden gelir. Tek bir yerde, tek bir kez çalışan, sonucu tek bir if ile değerlendirilen bir denetim, ne kadar iyi yazılmış olursa olsun, bulunup atlatılması en kolay denetimdir. Bu bölüm, denetimleri yerleştirmenin tasarım ilkelerini anlatır.

Ne zaman çalışır? Üç tetikleme anı¶

Tek bir tetikleme anı yetmez: yalnız açılışta yapılan bir hata ayıklayıcı denetimini, uygulama açıldıktan sonra bağlanan bir hata ayıklayıcı hiç görmez.

Nerede çalışır? Dağıtık denetim¶

• Çok noktalılık: Aynı denetim tek bir fonksiyonda değil, kodun birçok yerinde, her seferinde biraz farklı biçimde yapılır. Saldırgan bir noktayı yamaladığında diğerleri hâlâ çalışır.
• Karşılıklı denetim: Yönetilen katman (Java) ile native katman birbirinin bütünlüğünü denetler; biri değiştirilirse diğeri fark eder (5. haftadaki ayrık parmak izi ve 1. haftadaki arayüz tablosunda "karşılıklı bütünlük denetimi").
• Korunan fonksiyonun içinde: Değerli bir fonksiyon (ör. dize çözme ya da anahtar türetme), kendi giriş noktasında birkaç denetimi kendisi yapar. Sahada böyle tek bir fonksiyonun, yüklenme anında zaten yapılmış denetimlere ek olarak kendi başına on beşe yakın denetimle (kod bütünlüğü, hata ayıklayıcı, ortam, root, kontrol akışı sayacı) korunduğu görülür. Performans nedeniyle, yalnız iç kullanımdaki sürümlerinde bu denetimlerin bir kısmı giriş noktasına indirilir.
• Sahte parametreler: Hassas fonksiyonların giriş noktalarında, programcının okunabilirliği için makroyla gizlenen ve bir bütünlük denetimini tetikleyen ek parametreler bulunabilir (4. haftadaki "sahte parametreler").

Nasıl karar verir? Merkezî değil, veri bağımlı¶

En zayıf tasarım şudur:

if (hata_ayiklayici_var() || root_var() || butunluk_bozuk())
    return HATA;                     /* bu tek satırı değiştiren her şeyi atlatır */
anahtari_coz();

Tek bir karşılaştırmayı ters çeviren (ya da hata_ayiklayici_var fonksiyonunun hep "hayır" döndürmesini sağlayan) saldırgan bütün korumayı geçer. Güçlü tasarımda denetimlerin sonucu bir if'e değil, sonraki hesabın verisine karışır:

• Denetim sonuçları anahtar türetmeye katılır: ortam temizse doğru anahtar, değilse farklı ama geçerli görünen bir anahtar çıkar (kontrol akışı sayacı ve tepki politikasındaki decoy çıktı bu fikrin iki uygulamasıdır).
• Denetim sonuçları opak değerlerle taşınır (4. hafta): tek bir baytı değiştirerek "geçti"ye çevrilemez.
• Tepki, tetikleyiciden zaman ve kod olarak uzak bir yerde verilir (tepki politikası bölümü).

"Veri bağımlılığı" ne demek, somut olarak? Zayıf tasarımda if (kontrol_gecti) anahtari_kullan(); yazılır — anahtar zaten bellekte hazırdır, if yalnız onu kullanıp kullanmayacağına karar verir; saldırgan bu if'i yamalarsa anahtar zaten oradadır ve kullanılır. Güçlü tasarımda ise anahtarın kendisi henüz yoktur; kontrol sonucundan hesaplanarak üretilir: anahtar = HMAC(kontrol_sonucu, sabit_tuz). Kontrol başarısızsa kontrol_sonucu farklı bir değerdir, anahtar da farklı (ve işe yaramaz) çıkar — saldırganın atlayacağı bir if yoktur, çünkü ortada atlanacak bir karar değil, hesaplanacak bir değer vardır. Bölüm 9.1'deki acc zinciri ve Bölüm 10.1'deki cihaz anahtarı, bu fikrin iki somut uygulamasıdır.

Katmanlar birbirini korur¶

Her katman bir öncekinin zayıflığını kapatır: gizleme denetimleri saklar, bütünlük denetimi gizlenmiş denetimlerin değiştirilmesini fark eder, kontrol akışı sayacı bütünlük denetiminin atlanmasını fark eder, cihaz bağlama bütün bunlar aşılsa bile verinin başka bir yerde kullanılmasını engeller; sunucu doğrulaması ise istemci tamamen ele geçirilse bile son sözü söyler (tepki politikasındaki telemetri ve sunucu tarafı risk motoru).

2.1 İşlenmiş örnek: tek bir fonksiyonu üç noktada korumak¶

"Çok noktalılık" soyut kalmasın. Örnek mimarideki anahtar_coz() fonksiyonunu (ödeme anahtarını açan native fonksiyon) ele alalım ve üç tetikleme anını sırayla uygulayalım:

1. Yükleme anı: Kütüphane belleğe yüklendiğinde (native kütüphanenin başlatma fonksiyonunda) bir kez bütünlük denetimi (Bölüm 3) çalışır. Ortam en baştan bozuksa, anahtar_coz hiçbir zaman çağrılamaz hale getirilir (bir global bayrak sıfırlanır).
2. Hassas işlem öncesi: anahtar_coz()'un kendi girişinde, ayrıca bir anti-debug denetimi (Bölüm 4) ve bir kanca denetimi (Bölüm 6) çalışır — çünkü saldırgan hata ayıklayıcıyı yükleme anından sonra bağlamış olabilir.
3. Arka planda, düzensiz aralıklarla: Ayrı bir iş parçacığı, rastgele aralıklarla (ör. 2–7 saniye) ortam denetimini (Bölüm 5) tekrar çalıştırır; bir sonraki anahtar_coz() çağrısı bu iş parçacığının bulduğu sonucu okur.

Sonuç: anahtar_coz()'u atlatmak isteyen saldırganın üç ayrı zaman noktasındaki üç ayrı denetimi aynı anda yenmesi gerekir. Yalnız 2. noktayı (fonksiyonun kendi girişini) yamalamak, 1. ve 3. noktadaki denetimleri etkilemez — saldırgan işini bitirdiğini sanır ama arka plan iş parçacığı birkaç saniye içinde tutarsızlığı yakalar ve tepki politikası devreye girer (Bölüm 10).

3. Bütünlük denetimi: uygulama kendini doğrular (self-hashing)¶

RASP'in ilk ve en temel adımı: "Ben değiştirildim mi?" Saldırgan bir lisans kontrolünü, bir if (odendi) dalını ya da bir kripto çağrısını yamalayarak (patching) korumayı atlatmaya çalışır (Hafta 4'te gördüğümüz je → jmp yaması). Savunma: uygulama, kendi binary dosyasının (ya da korunan bir kod/veri bölgesinin) bir özetini çalışma zamanında hesaplar ve önceden bilinen altın (golden) değerle karşılaştırır. Tek bir bayt bile değişmişse, yama yakalanır.

Demo 1 — Çalışma zamanı bütünlük denetimi ve yama tespiti¶

Özün kodu (dosyayı okuyup HMAC hesaplar; cen429_crypto.h'dan crypto_hmac_sha256):

/* Kendi yolunu bul: Linux /proc/self/exe, Windows GetModuleFileNameA */
self_path(path, sizeof(path));
read_file(path, &data, &size);
crypto_hmac_sha256(RASP_KEY, 32, data, size, digest);   /* HMAC over the file */

/* verify: sabit zamanli karsilastirma (zamanlama sizintisini onler) */
unsigned char diff = 0;
for (int i = 0; i < 32; i++) diff |= expected[i] ^ digest[i];
if (diff == 0) { /* INTEGRITY OK */ } else { /* PATCH DETECTED */ }

normal, patched-mid ve edge-first-byte hazır örneklerini deneyin; 🎲 ile rastgele baytlar üretebilir, kendi baytlarınızı da girebilirsiniz.

Windows'ta alınan gerçek çıktı (kısaltılmış):

STEP 2 - Normal run: integrity verifies OK (no patch)
Expected   : 5aeaf45226dbb29af724cb7101a621419aa58e0630f1fee3d647f76b55115de4
Computed   : 5aeaf45226dbb29af724cb7101a621419aa58e0630f1fee3d647f76b55115de4
RESULT: INTEGRITY OK - target unchanged.

STEP 3 - Attack: a COPY of the binary is made and 1 byte is changed
> flip byte at offset 22272 (0xCC -> 0x33)
STEP 4 - The patched copy's HMAC is compared with the golden value
Expected   : 5aeaf45226dbb29af724cb7101a621419aa58e0630f1fee3d647f76b55115de4
Computed   : c47c35687dc205b93a2eec33df49c97defecfcb868fb8a23e6c01c2aca0ec8ac
RESULT: PATCH DETECTED - target was modified! (tamper)   (exit code 3)

Yama yokken özet altın değerle birebir aynı çıktı. Tek bir baytı değiştirince özet tamamen değişti (çığ etkisi) ve yama yakalandı. Karşılaştırma sabit zamanlı yapılır (memcmp değil), çünkü Hafta 3'te gördüğümüz gibi düz memcmp ilk farklı baytta durup zamanlama sızdırır.

3.1 İşlenmiş örnek: HMAC hangi baytları özetliyor, yama onu nasıl bozuyor?¶

Hangi baytlar özetleniyor? target_hmac() fonksiyonuna bakınca cevap nettir: read_file() hedefin (kendi binary dosyanın) tamamını belleğe okur (fread ile ofset 0'dan dosya sonuna kadar) ve crypto_hmac_sha256 bu bütün bayt dizisini tek seferde özetler — belirli bir fonksiyon ya da bölüm değil, dosyanın her baytı. demo.ps1'in gerçek çıktısında ofset 22272 değiştiriliyordu; bu, dosyanın ortasına (SIZE / 2) denk gelir — demek ki o çalıştırmada binary dosyanın toplam boyutu yaklaşık 22272 × 2 ≈ 44544 bayttı. Saldırgan dosyanın hangi baytını değiştirirse değiştirsin (başı, ortası, sonu fark etmez), o bayt hesaba dahildir ve özet değişir.

Yama onu nasıl bozuyor — küçük bir örnekte adım adım. Aynı çığ etkisini, koca bir binary dosya yerine tek bir karakterlik bir metinde görelim; mantık birebir aynıdır. "MERHABA" dizesini sabit bir anahtarla HMAC-SHA-256'layalım, sonra son karakteri A'dan B'ye çevirip tekrar hesaplayalım:

printf 'MERHABA' | openssl dgst -sha256 -hmac "ornek-anahtar"
printf 'MERHABB' | openssl dgst -sha256 -hmac "ornek-anahtar"

SHA2-256(stdin)= 4d45a6382deee7f75c75b3cf5a6a81a2776d317e1db9ec9b0125b69e09492615
SHA2-256(stdin)= 4fbdf8768822083c3fc3797c5f1d278dd1ea58ab0bfde31a8ebf85e260fbcbd7

Girdinin 7 baytından yalnız 1 tanesi (son karakter, A=0x41 → B=0x42; bu iki değer yalnız iki bitte ayrılır) değişti; ama çıktının 32 baytının tamamı farklı. Bu, kriptografik özet fonksiyonlarının çığ etkisi**dir: girdide tek bir bit değişirse, çıktının ortalama **yarısı değişir. Demo 1'in gerçek çıktısında gördüğünüz 5aeaf452...55115de4 → c47c3568...aca0ec8a dönüşümü de aynı özelliğin, koca bir binary dosya üzerindeki hâlidir: XOR 0xFF tek bir baytın her bitini ters çevirir, bu da HMAC-SHA-256'nın iç işleyişi (SHA-256'nın sıkıştırma fonksiyonunun her turu) yoluyla bütün 256 bit çıktıya yayılır.

"Periyodik" ne sıklıkta olmalı? Bir maliyet-gecikme dengesi. Bölüm 2'deki "arka planda, düzensiz aralıklarla" ilkesini bir sayıyla somutlaştıralım. Denetim aralığı ne kadar kısa olursa, bir yamanın fark edilmesi o kadar hızlı olur ama CPU/batarya maliyeti de o kadar artar; aralık ne kadar uzun olursa saldırgana o kadar fazla "fark edilmeden çalışma" penceresi kalır:

Sahada tercih edilen, bu dört seçeneğin hiçbiri tek başına değil, birlikte kullanılmasıdır: açılışta bir kez (ucuz, geniş kapsamlı), kritik işlem öncesi her seferinde (ucuz, dar kapsamlı ama en kritik an), ve arka planda rastgele aralıklarla (ucuz değil ama saldırganın "denetim ne zaman çalışıyor" diye tahmin etmesini engeller). Sabit bir aralık (ör. tam olarak her 30 saniyede bir) saldırgana bir tahmin edilebilirlik sunar; rastgele aralık bunu engeller — bu yüzden tablodaki üçüncü satır "rastgele" olarak işaretlidir.

4. Hata ayıklayıcı (debugger) algılama¶

Saldırganın en güçlü aracı bir hata ayıklayıcıdır (gdb, lldb, x64dbg, WinDbg, Visual Studio): programı durdurur, adım adım izler, belleği ve anahtarları okur, dalları değiştirir. RASP, bir hata ayıklayıcının bağlı olup olmadığını anlamaya çalışır.

Demo 2 — Hata ayıklayıcı algılama (Linux ptrace/TracerPid, Windows PEB)¶

/* /proc/self/status icinden TracerPid oku; >0 ise izleniyoruz */
long tp = tracer_pid();
if (tp > 0) suspicious++;      /* bir surec bizi ptrace ile izliyor */

Animasyonda /proc/self/status'un satır satır taranışını ve iki sinyalin (TracerPid, ana süreç adı) nasıl tartıldığını izleyin; clean/gdb-attached/edge örneklerini deneyin.

STEP 1 - Normal run (NO debugger): clean is expected
1) /proc/self/status TracerPid           : 0 (no tracer)
2) Parent process name                   : sh
RESULT: clean - no tracing tool visible.

STEP 2 - Run under gdb (TracerPid > 0 is expected)
1) /proc/self/status TracerPid           : 41885 (TRACED)
RESULT: a debugger/tracing TOOL was detected (2 signal(s)).

Hata ayıklayıcı yokken TracerPid 0, gdb altında >0 çıktı; program iki durumu ayırt etti. Windows'ta Visual Studio ile F5 (hata ayıklayıcıda) çalıştırırsanız IsDebuggerPresent EVET döndürür ve sonuç "algılandı" olur.

4.1 İşlenmiş örnek: TracerPid'in 0'dan sıfır olmayana geçişini adım adım izlemek¶

Demo 2'nin çıktısında TracerPid'in 0'dan 41885'a geçtiğini gördük; şimdi bu geçişin neden olduğunu adım adım açalım. /proc/self/status, çekirdeğin her süreç için tuttuğu, o sürecin kendisi tarafından da okunabilen bir metin dosyasıdır (Hafta 1'de /proc dosya sistemini "çekirdeğin sürece açtığı bir pencere" olarak tanımlamıştık). İçindeki TracerPid: satırı, o süreci ptrace() sistem çağrısıyla izleyen sürecin PID'ini (Process ID — süreç kimliği) tutar; kimse izlemiyorsa değer 0'dır.

Adım 1 — hata ayıklayıcı yokken. antidebug programı doğrudan kabuktan çalıştırılır ve kendi /proc/self/status dosyasını okur (temsilî, kısaltılmış içerik):

Name:      antidebug
Pid:       4821
PPid:      4820          <- calistiran kabuk (sh)
TracerPid: 0             <- kimse ptrace ile izlemiyor

Program bu satırı okur, sayısal değeri 0 bulur; tp > 0 koşulu yanlış olduğu için suspicious değişkenini artırmaz. Demo çıktısındaki "RESULT: clean - no tracing tool visible." satırı buradan gelir.

Adım 2 — gdb altında çalıştırılınca. demo.sh ikinci geçişte programı gdb içinden başlatır. gdb, hedef süreci başlatırken ya da ona bağlanırken çekirdeğe "bu süreci ben izliyorum" der; bu, ptrace(PTRACE_TRACEME, ...) ya da ptrace(PTRACE_ATTACH, ...) çağrısıyla olur. Çekirdek bunu kaydeder ve izlenen sürecin /proc/self/status dosyasındaki TracerPid alanını, izleyen gdb sürecinin kendi PID'iyle doldurur:

Name:      antidebug
Pid:       4821
PPid:      41885          <- artik ana surec gdb
TracerPid: 41885          <- gdb bizi ptrace ile izliyor

Bu, tam olarak demo çıktısında görülen 41885 değeridir. Programın kendisi hiçbir şey yapmamıştır — yalnız çekirdeğin zaten tuttuğu bir alanı okumuştur; bu yüzden teknik "yalnız okuma" (read-only) olarak sınıflandırılır ve hiçbir yan etkisi yoktur (demonun README'sindeki güvenlik sözü tam bu nedenle tutulabilir).

Adım 3 — karar. tp > 0 olduğu için suspicious sayacı 1 artar; ana sürecin adı da gdb olduğu için ikinci bağımsız bir sinyal (parent_process_name denetimi) daha eklenir; demo çıktısındaki "algilandi (2 sinyal)" ifadesi bu ikisinin toplamıdır. Tek bir alanın okunması yeterli olmasa da, çekirdek düzeyinde tutulan bu bilgi sahtelemesi zor bir sinyaldir: TracerPid'i doğrudan sıfırlamak sürecin kendi belleğinden değil çekirdek veri yapısından okunduğu için mümkün değildir — saldırganın bunu gizlemesi ancak /proc/self/status'u okuyan kütüphane fonksiyonuna kanca takmasıyla (hooking) mümkündür, ki bu da tam olarak Bölüm 6'nın konusudur.

4.2 Windows karşılığı: NtGlobalFlag'teki bitleri okumak¶

Windows'ta doğrudan bir /proc dosyası yoktur, ama aynı fikrin (çekirdeğin zaten tuttuğu bir bilgiyi okumak) bir karşılığı vardır: PEB (Process Environment Block — her sürecin çekirdek tarafından tutulan, sürecin kendisinin de okuyabildiği bir bellek yapısı). PEB'in NtGlobalFlag alanı, süreç bir hata ayıklayıcı altında başlatıldıysa (yalnız sonradan bağlanmadıysa) üç özel bayrak biti taşır:

Bu üç bit birlikte 0x70'i oluşturur (0x10 | 0x20 | 0x40 = 0x70); Windows yükleyicisi, süreci bir hata ayıklayıcı altında başlatırken yığın ayırıcısını daha sıkı denetimli bir moda otomatik olarak geçirir ve bu üç biti işaretler. Demo 2'nin Windows kodundaki (ntglobal & 0x70) != 0 satırı tam bunu okur: NtGlobalFlag değerinin bu üç bitten en az birini taşıyıp taşımadığına bakar. Tıpkı TracerPid gibi, bu da yalnız okuma işlemidir; program hiçbir şeyi değiştirmez, çekirdeğin/yükleyicinin zaten yazdığı bir alanı okur.

5. Ortam algılama: sanal makine ve emülatör¶

Saldırgan uygulamayı çoğu zaman kontrollü bir analiz ortamında — bir sanal makine, emülatör ya da kum havuzunda (sandbox) — çalıştırır. Emülatör, bir cihazı yazılımla taklit eden ortamdır (Android emülatörü, QEMU); sanal makine (VM) ise gerçek donanımı soyutlayıp üzerinde başka bir işletim sistemi çalıştırır. Saldırgan analizini gerçek cihaz yerine burada yapar, çünkü orada daha kolaydır. RASP bunu ortam ipuçlarından sezmeye çalışır.

Demo 3 — VM/emülatör ve zamanlama algılama (CPUID)¶

bare-metal/kvm/edge-blank-vendor/edge-slow-timing örneklerini deneyin; 🎲 ile rastgele hipervizör/zamanlama değerleri üretebilirsiniz.

(A) CPUID.1:ECX[31] hypervisor bit    : PRESENT
    Hypervisor vendor signature        : "Microsoft Hv"
(B) time for 2,000,000 iterations      : 0.662 ms  (checksum=4544)
RESULT: a hypervisor was SEEN. But WSL2/Hyper-V/VBS also look like this;
this ALONE does not mean 'analysis environment' - it is a weak signal.

5.1 İşlenmiş örnek: risk skoru ve eşik nasıl kurulur?¶

Bölüm 1.2'nin "tek kontrole güvenme" ilkesini burada sayılarla somutlaştıralım. Ortam algılamanın her sinyaline bir ağırlık (0–100 arası bir katkı puanı) verilir; bütün ağırlıklar toplanır ve bir risk skoru çıkar. Karar, tek bir if (hipervizor_var) değil, bu skorun bir eşiğin üstünde olup olmadığıdır.

Örnek 1 — Hyper-V'li sıradan bir Windows dizüstünde çalışan bir geliştirici (meşru kullanıcı). Bölüm 3'teki gerçek demo.ps1 çıktısında gördüğümüz gibi hipervizör biti PRESENT VE satıcı imzası görünür ("Microsoft Hv" — bkz. Bölüm 3), zamanlama normal, emülatör izi yok, hata ayıklayıcı bağlı değil. Toplam skor: hipervizör biti (15) + satıcı imzası görünür (25) = 40. Zamanlama ve emülatör/hata-ayıklayıcı sinyalleri katkı vermez.

Örnek 2 — analiz ortamında çalışan bir saldırgan. Hipervizör biti VAR (15) + satıcı imzası görünür (25) + zamanlama anomalisi (20) + hata ayıklayıcı bağlı (35) = toplam 95. Skor yüksek; işlem reddedilir ya da decoy döner (Bölüm 10).

Dikkat: Örnek 1 ile Örnek 2'nin ilk iki sinyali birebir aynı (40 puan) — Hyper-V'li bir geliştirici makinesi ile bir analiz sanal makinesi, salt bu iki sinyale bakan bir sisteme aynı görünebilir! Aradaki fark yalnız zamanlama anomalisi ve hata ayıklayıcı sinyalinde ortaya çıkar (Örnek 2'yi 40'tan 95'e taşıyan asıl fark budur). Eğer eşik 30 gibi düşük tutulursa (aşağıdaki bankacılık örneği), Örnek 1'in meşru geliştiricisi bile reddedilir — bu, hemen aşağıdaki "yanlış pozitifin gerçek maliyeti" uyarısının tam olarak anlattığı durumdur.

Aradaki fark tek bir bitin varlığı değil, kaç bağımsız sinyalin birlikte göründüğüdür. Eşik nereye konulmalı? Bu, üründen ürüne değişen bir risk iştahı (risk appetite) kararıdır — "kaç meşru kullanıcıyı engellemeye razıyım, karşılığında kaç saldırıyı önlerim" dengesi:

6. Kanca ve enstrümantasyon algılama (LD_PRELOAD, Frida)¶

Hata ayıklayıcıdan daha sinsi bir tehdit: fonksiyonlara kanca takma (hooking) ve dinamik enstrümantasyon. Kanca (hook), bir fonksiyonun çağrısını araya girip değiştirmektir; enstrümantasyon ise çalışan bir programa kod enjekte edip davranışını izleme ya da değiştirme tekniğidir (bunun en yaygın aracı Frida'dır). Saldırgan programı durdurmadan, çağırdığı fonksiyonları (kendi anti-debug/anti-root kontrollerimiz dâhil) kendi sürümüyle değiştirir. Böylece Demo 2'deki kontrolleri "her zaman temiz" döndürecek şekilde yalancıya çıkarabilir.

Algılama fikirleri (Katalog K7/K8/K18):

• LD_PRELOAD ortam değişkeni boş mu? (getenv — zayıf, çünkü getenv'in kendisi de kancalanabilir)
• Bir fonksiyon hangi paylaşımlı nesneden çözülüyor? dlsym(RTLD_DEFAULT, ...) + dladdr ile fonksiyonun geldiği .so dosyasına bakılır; beklenen libc yerine yabancı bir .so çıkıyorsa kanca vardır. (Bu, getenv sahteciliğine dayanmaz.)
• /proc/self/maps'te beklenmeyen yürütülebilir bölgeler, bilinen çerçeve göstergeleri.

Demo 4 — LD_PRELOAD ile kanca ve dladdr ile algılama¶

void *p = dlsym(RTLD_DEFAULT, "time");   /* onyuklu kanca varsa onu doner */
Dl_info info;
dladdr(p, &info);                        /* fonksiyonu saglayan .so */
int hook = !is_legitimate(info.dli_fname);   /* not libc/vdso/ld = HOOK */

Animasyon, time'ın yüklü nesneler arasında hangi SIRAYLA arandığını ve LD_PRELOAD kancası varsa neden onun kazandığını gösterir; clean/hooked-first/edge örneklerini deneyin.

STEP 1 - Normal run (no LD_PRELOAD): clean is expected
   time     -> linux-vdso.so.1
   getenv   -> /lib/x86_64-linux-gnu/libc.so.6
   time(NULL) returned              : 1790690227
RESULT: clean - no preload/hook visible.

STEP 2 - Attack: the fake hook is preloaded ONLY into this process
   time     -> bin/linux/libfake_hook.so (HOOK!)
   getenv   -> /lib/x86_64-linux-gnu/libc.so.6
   time(NULL) returned              : 1234567890
RESULT: function hook / preload DETECTED (2 signal(s)).

Temiz koşuda time, çekirdeğin vDSO'sundan çözüldü (bu meşrudur, kanca değil). Kanca yüklenince aynı time libfake_hook.so'dan çözüldü ve sabit sahte değer (1234567890) döndürdü; dladdr fonksiyonun yerini göstererek kancayı yakaladı. Dikkat: temiz koşuda linux-vdso'yu yanlış pozitif saymamak için algılama libc, vDSO ve dinamik yükleyiciyi meşru kaynaklar olarak kabul eder — bu, "algılama yazmak, algılamayı doğru yazmaktan kolaydır" dersidir.

6.1 İşlenmiş örnek: dlsym + dladdr ile fonksiyonun kaynağını adım adım bulmak¶

Demo 4'ün çekirdeği iki fonksiyon çağrısıdır: dlsym ve dladdr. İkisinin birlikte ne yaptığını adım adım açalım.

Adım 1 — dlsym(RTLD_DEFAULT, "time") ne yapar? dlsym, çalışan sürecin sembol tablosunda aranan isimde ("time") bir sembol arar ve onun bellek adresini döndürür. RTLD_DEFAULT, "programın normal sembol arama sırasını (kendi binary, sonra yüklenen kütüphaneler, LD_PRELOAD'lı kütüphaneler dâhil) kullan" anlamına gelen özel bir tanıtıcıdır. Bu adımın çıktısı yalnız bir sayı (bir bellek adresi); hangi dosyadan geldiğine dair bir bilgi taşımaz.

Adım 2 — bu adresi kim sağladı? İşte dladdr'nin işi budur: verilen bir adresi alır, çalışan sürecin belleğe yüklenmiş paylaşımlı nesnelerinin (.so dosyalarının) haritasında arar ve adresin hangi .so'nun bellek aralığına düştüğünü bulur. Sonucu bir Dl_info yapısına yazar; bizim kullandığımız alan dli_fname — o .so'nun dosya yolu.

Adım 3 — temiz koşuda. LD_PRELOAD boşken, time sembolü normal arama sırasıyla çözülür ve çekirdeğin sağladığı vDSO (virtual Dynamic Shared Object — çekirdeğin süreç belleğine kendiliğinden eklediği, sistem çağrısı yapmadan hızlı okuma sağlayan özel bir sanal .so) içinden gelir. Demo çıktısı: time -> linux-vdso.so.1. is_legitimate() fonksiyonu bu ismi tanır (linux-vdso alt dizesini arar) ve kanca değil der.

Adım 4 — LD_PRELOAD ile kanca yüklenince. demo.sh, LD_PRELOAD=./libfake_hook.so ortam değişkeniyle programı başlatır. Dinamik bağlayıcı (ld-linux.so), normal arama sırasının en başına bu kütüphaneyi sokar; kütüphane kendi time() fonksiyonunu tanımladığı için, dlsym(RTLD_DEFAULT, "time") artık vDSO'daki gerçek time'ı değil, libfake_hook.so'daki sahte time'ı bulur. dladdr bu adresin libfake_hook.so'nun bellek aralığına düştüğünü görür; dli_fname = "bin/linux/libfake_hook.so" döner. is_legitimate() bu ismi tanımadığı (libc/vDSO/ld değil) için KANCA der — tam demo çıktısındaki time -> bin/linux/libfake_hook.so (HOOK!) satırı.

Adım 5 — bu, neden getenv(LD_PRELOAD) denetiminden daha güçlü? getenv denetimi ortam değişkeninin kendisine bakar — ama ortam değişkeni yalnız programın başlatılma anında kütüphaneyi yüklemek için kullanılır; bir kez yüklendikten sonra saldırgan onu silebilir (unsetenv) ya da kendi sahte kütüphanesinde getenv'i de kancalayıp boş döndürebilir (tam olarak Etkinlik 1'in denediği şey). dladdr denetimi ise ortam değişkenine hiç bakmaz; doğrudan "bu fonksiyon şu an fiilen nereden çalışıyor?" sorusunu sorar — kanca zaten yüklenmiş olduğu için bu sorunun cevabı, ortam değişkeninden değil çalışan kodun kendisinden gelir ve bu yüzden getenv sahteciliğine dayanmaz.

7. Dinamik bellek koruması ve bellek izleme tespiti¶

İzlencenin bu haftaya koyduğu maddelerden biri dinamik bellek korumasıdır: program çalışırken bellekteki hassas verinin okunmasına ve değiştirilmesine karşı alınan önlemler. 1. haftada sırları bellekten silmeyi ve takasa düşmesini önlemeyi, 3. haftada "kullanımda veri" katmanlarını gördük. Bu bölüm aynı soruyu çalışma anı saldırganı açısından yeniden sorar: saldırgan belleği izliyor ya da değiştiriyorsa ne yapabiliriz?

Saldırgan bellekle ne yapar?¶

Bu saldırıların hepsi için saldırganın süreç belleğine erişmesi gerekir: bir hata ayıklayıcıyla, işletim sisteminin süreç belleği arayüzleriyle ya da sürecin içine yüklenmiş bir kütüphaneyle. Bu yüzden bellek koruması, önceki bölümlerdeki hata ayıklayıcı ve kanca algılamayla birlikte düşünülür.

Önlem 1: Bellekte az, kısa ve dağınık tut¶

En etkili bellek koruması, bellekte okunacak bir şey bırakmamaktır:

1. Kısa ömür: Sır, yalnız kullanıldığı fonksiyonun içinde açık olur ve fonksiyon dönmeden silinir (3. hafta: açıklık penceresi).
2. Örtme ve parçalama: Kullanılmadığı sürede sır, rastgele bir maskeyle XOR'lanmış ya da parçalara bölünmüş olarak durur; bellekte tek bir yerde sırrın kendisi bulunmaz.
3. Rastgele değerle silme: İş bitince bellek sıfırla değil rastgele değerlerle doldurulur; "burada az önce bir sır vardı" izini de bırakmaz. Sahada native tarafta rastgele üretecin tek kullanım yeri budur.
4. Hiç açılmamak: Whitebox kriptografide anahtar hiçbir anda açık halde bellekte bulunmaz (11. hafta). Sahadaki kabuk matrisinde ödeme sırasında native tarafta kalan tek kabuk budur (3. hafta).

Önlem 2: Belleğin okunmasını işletim sistemiyle zorlaştır¶

Bu önlemler yönetici (root) yetkisine sahip bir saldırganı durdurmaz; ama saldırganı daha güçlü bir konuma çıkmaya zorlar ve bu da root algılamanın devreye girdiği yerdir.

Somut bir örnek: PR_SET_DUMPABLE neyi değiştirir? Linux'ta her süreç varsayılan olarak "dump edilebilir"dir — çekirdek çökme anında bir çekirdek dökümü (core dump) üretebilir ve aynı kullanıcıya ait başka bir süreç ptrace(PTRACE_ATTACH, pid, ...) ile ona bağlanabilir. prctl(PR_SET_DUMPABLE, 0) çağrısı bu bayrağı kapatır:

Bu, Bölüm 4'teki TracerPid denetimiyle tamamlayıcı çalışır: TracerPid "şu an biri izliyor mu?" diye algılar; PR_SET_DUMPABLE = 0 ise "aynı kullanıcıya ait sıradan bir araç izleyemesin" diye önler. Kök yetkisine sahip bir saldırgan bu bayrağı yine de aşabilir (ptrace_scope ayarına ve yetkisine bağlı) — bu yüzden Bölüm 8'deki kök göstergesiyle birlikte değerlendirilmelidir.

Önlem 3: Değiştirilen veriyi fark et¶

Bellekteki kritik bir yapının (bir sayaç, bir yetki bayrağı, bir yapılandırma tablosu) sessizce değiştirilmesini fark etmenin yolu, o veriyi tek başına bırakmamaktır:

typedef struct {
    uint32_t value;         /* asıl değer                           */
    uint32_t shadow;        /* value XOR çalışma anı maskesi        */
    uint32_t mac;           /* value ve shadow üzerinden kısa bir MAC */
} ProtectedCounter;

/* Okurken üçünün tutarlılığı denetlenir; tutmuyorsa değer bellekte değiştirilmiştir. */
int counter_read(const ProtectedCounter *s, uint32_t *out)
{
    if ((s->shadow ^ runtime_mask) != s->value) return -1;
    if (short_mac(s->value, s->shadow) != s->mac) return -1;
    *out = s->value;
    return 0;
}

Saldırgan bellekte yalnız value alanını değiştirirse gölge kopya ve özet tutmaz. Üçünü birden tutarlı biçimde değiştirmek için maskeyi ve özet anahtarını da bulması gerekir; bu da işin maliyetini artırır. Aynı fikir, 5. haftadaki cihaz parmak izinin iki farklı özetle iki farklı yerde saklanmasında ve 2. haftadaki kurcalamaya dayanıklı günlükte de vardır.

7.1 İşlenmiş örnek: ProtectedCounter bir saldırıyı nasıl yakalar?¶

Yukarıdaki yapıyı sayılarla izleyelim. runtime_mask, çalışma başında rastgele üretilmiş sabit bir değer olsun: 0xA5A5A5A5. Bir ödeme denemesi sayacı value = 3 (üçüncü deneme) olduğunda yapı şöyle doldurulur:

counter_read() her okumada shadow XOR runtime_mask'in value'ya eşit olup olmadığına bakar: 0xA5A5A5A6 XOR 0xA5A5A5A5 = 0x00000003 — value ile eşit, tutarlı; fonksiyon 0 döner.

Şimdi saldırganın bir bellek düzenleyicisiyle yalnız value alanını 0x00000063 (99) yaptığını düşünelim (bir deneme sayacını ya da bir puanı sıfırlamaya/artırmaya çalışıyor). shadow ve mac alanları değişmedi. Bir sonraki counter_read() çağrısı: shadow XOR runtime_mask = 0xA5A5A5A6 XOR 0xA5A5A5A5 = 0x00000003 — ama value artık 0x00000063. İkisi eşleşmiyor; fonksiyon -1 döner, tutarsızlık yakalanır. Saldırganın bunu atlatabilmesi için shadow'ı da doğru maskeyle yeniden hesaplaması ve mac'i de tutarlı üretmesi gerekir — ki short_mac'in anahtarını bilmediği sürece bu, Bölüm 3.1'deki HMAC altın değerini yeniden üretmekle aynı zorluktadır.

Önlem 4: İzlendiğini fark et¶

Bellek izleme araçlarının çoğu, sürece bir hata ayıklayıcı olarak bağlanarak ya da sürecin içine bir kütüphane yükleyerek çalışır. Bu yüzden izleme tespitinin temeli, hata ayıklayıcı ve kanca algılama bölümlerinde gördüğümüz yöntemlerdir. Bunlara ek olarak bazı dolaylı sinyaller kullanılır:

• Zamanlama: Tek adımlı çalıştırılan ya da kesme noktalarıyla durdurulan kod, normalden çok daha yavaş çalışır; iki nokta arasındaki beklenmedik uzun süre bir sinyaldir (ortam algılamadaki zamanlama ölçümüyle aynı fikir).
• Beklenmeyen modüller: Süreç belleğinde, uygulamanın kendisinin yüklemediği kütüphaneler bulunması.
• Tutarlılık bozulması: Önlem 3'teki gibi korunan değerlerin tutarsızlaşması.

Bu sinyallerin hiçbiri tek başına kesin değildir; hepsi tepki politikasındaki risk skoruna katkı olarak kullanılır.

8. Kök/ayrıcalıklı ortam ve bileşen imza doğrulaması¶

8.1 Kök (root) / ayrıcalıklı ortam göstergesi¶

Kök (root), bir cihaz üzerinde normalde kısıtlı olan tam yetkidir; jailbreak aynı yetkiyi iOS gibi kapalı sistemlerde zorla açmanın adıdır. Root'lu (ya da jailbreak'li) bir cihazda uygulamanın güvenlik varsayımları çöker: her süreç belleği okuyabilir, dosya sistemi korumaları aşılır. RASP root göstergelerine bakar (Katalog K4/K5): su ikilisinin varlığı, tehlikeli paketler, yazılabilir sistem yolları, root gizleme çerçeveleri. Masaüstündeki taşınabilir karşılığı: uygulama yükseltilmiş yetkiyle mi çalışıyor (Linux geteuid()==0, Windows yükseltilmiş token)?

Mobil "root" ile masaüstü "yükseltilmiş yetki" arasındaki fark yalnız isimdir, fikir aynıdır. Android'de bir uygulamanın su ikilisini bulması, root erişiminin kurulu olduğunu gösterir; Linux/masaüstünde bir sürecin geteuid()'i 0 döndürmesi, sürecin fiilen root kullanıcısı olarak çalıştığını gösterir. İkisi arasındaki küçük ama önemli fark: mobilde root kurulu olabilir ama o an kullanılmıyor olabilir (gösterge, göstergedir); masaüstünde geteuid()==0 ise o anki gerçek durumu bildirir (çekirdeğin kendisi bu bilgiyi tutar, tıpkı Bölüm 4.1'deki TracerPid gibi sahtelemesi zordur). Bu yüzden masaüstü/sunucu tarafındaki "ayrıcalıklı süreç" denetimi, mobildeki "root göstergesi" taramasından biraz daha güvenilir bir sinyaldir — yine de tek başına karar vermek yerine Bölüm 8.1.1'deki risk skoruna eklenmelidir.

Demo 7 — Root/ayrıcalıklı ortam göstergesi (yalnız okuma)¶

clean/rooted-one-mark/edge örneklerini deneyin; animasyon 14 bilinen göstergenin taranışını ve ayrıcalık seviyesinin nasıl eklendiğini gösterir.

STEP 2 - Flagged case: a fake 'su' indicator file is created
1) Privilege level : normal user
2) Dangerous-indicator scan:
   [FOUND] output\fake_su (extra indicator)
RESULT: an elevated/risky environment INDICATOR is present (1 signal(s)).

8.1.1 Kök göstergesini de bir risk skoruna bağlamak¶

Bölüm 5.1'deki risk skoru fikri kök/ayrıcalık göstergesi için de geçerlidir; hatta sahada tek bir gösterge yerine bir liste önerilir, çünkü her gösterge tek başına hem kaçırılabilir (saldırgan gizler) hem yanlış pozitif üretebilir (meşru kullanıcı cihazını gerçekten root'lamıştır).

Demo 7'nin gerçek çıktısındaki tek sinyal (output/fake_su bulundu → 1 sinyal) düşük bir skora karşılık gelir; tek başına bir bankacılık uygulamasını durdurmaya yetmemelidir. Skorun yüksek çıkması için birden çok göstergenin birlikte görünmesi beklenir — tıpkı Bölüm 5.1'deki ortam örneğinde olduğu gibi.

8.2 Bileşen/paket imza ve özet doğrulaması (APK imza doğrulamasının genel hâli)¶

Android'de uygulama, yeniden paketlemeye (repackaging) karşı APK imzasını doğrular (APK Signature Scheme v1/v2/v3): saldırgan uygulamayı açıp değiştirse ve yeniden paketlese bile, orijinal geliştiricinin özel anahtarıyla üretilmiş imzayı taşıyamaz. Bu, "yüklediğim/çağırdığım bileşen beklenen, değiştirilmemiş sürüm mü?" sorusunun genel hâlidir (Katalog K2/K3/K6).

Demo 6 — Bileşen imza doğrulaması ve repackaging tespiti¶

holds/appended-byte/edge örneklerini deneyin; animasyon üretim-zamanı imzalamayı ve yükleme-öncesi doğrulamayı yan yana gösterir.

STEP 3 - Verify before loading (module unchanged): HOLDS
Module signature HELD -> safe to load.
STEP 4 - Attack: the module is REPACKAGED (one character changes)
Module signature DID NOT HOLD -> REPACKAGED/modified.
Loading REJECTED.   (exit code 3)

8.2.1 İşlenmiş örnek: repackaging bir bayt eklemekle nasıl yakalanır?¶

Demo 6'nın gerçek çıktısındaki "modül YENIDEN PAKETLENIR (tek bayt eklenir)" adımını Bölüm 3.1'deki mantıkla birleştirelim. Modülün doğrulaması da tıpkı Demo 1 gibi dosyanın tamamı üzerinden hesaplanan bir HMAC-SHA-256'dır; fark, hedefin bu kez programın kendisi değil, ayrı bir dosya (eklenti modülü) olmasıdır.

Adım 1 — orijinal modül. Modül dosyası N bayttır; yükleyici onu okur, HMAC(anahtar, modul[0..N)) hesaplar ve önceden kaydedilmiş imzayla karşılaştırır. Eşleşir → "TUTAR" → güvenle yüklenir.

Adım 2 — saldırgan modülü açar, bir özellik ekler, yeniden paketler. Bu işlem dosyanın sonuna bir bayt ekler (N+1 bayt oldu) — modülün amaçlanan işlevine hiç dokunmasa bile. Yükleyici bu kez HMAC(anahtar, modul[0..N+1)) hesaplar. Girdinin uzunluğu bile değiştiği için (Bölüm 3.1'deki tek bayt değeri değişikliğinden daha köklü bir fark), HMAC'in dahili blok işleme mekanizması en baştan farklı bloklar görür ve sonuç tümüyle farklı çıkar — tıpkı Demo 1'de gördüğümüz gibi.

Adım 3 — karşılaştırma başarısız. Yeni HMAC, kaydedilmiş imzayla eşleşmez → "TUTMADI" → "YENIDEN PAKETLENMIS/degistirilmis" → yükleme reddedilir (çıkış kodu 3). Saldırgan tek bir bayt bile eklese, imzayı yeniden üretebilmesi için imzalama anahtarına ihtiyacı vardır; bu anahtar (öğretim amaçlı HMAC'te) yükleyicinin içindedir, ama gerçek APK imzasında (asimetrik) yalnız orijinal geliştiricide bulunan özel anahtardır — bu da Bölüm 8.2'nin "Önemli fark" notundaki ayrımın can alıcı noktasıdır: HMAC'i doğrulayan herkes aynı zamanda üretebilir de; asimetrik imzada doğrulayan yalnız doğrular, üretemez.

9. Kontrol akışı bütünlüğü: tek bir if neden yetmez¶

Şu ana kadarki bütün kontroller (bütünlük, anti-debug, ortam, root) bir noktada bir karar verir: if (tehlike) reddet;. Saldırganın işi basittir: o tek atlamayı (je → jmp) yamalayıp kontrolü es geçmek (Bölüm 3'teki yama). O hâlde kontrolleri atlanamaz kılmanın yolu nedir?

Cevap: güvenlik kontrollerini bir kontrol akışı sayacına / anahtar zincirine bağlamak (Katalog K17). Kritik işlem, doğru sonucu ancak bütün kontrol noktalarından sırayla geçilmişse üretebilir. Bunu bir veri bağımlılığıyla kurarız: her kontrol noktası bir anahtar zincirini ilerletir (acc = HMAC(acc, "asama-i")); kritik işlem bu zincirden türetilen anahtarla bir sırrı açar.

Bir kontrol atlanır ya da sırası bozulursa acc farklı çıkar, anahtar yanlış olur ve GCM çözme reddedilir — gerçek sonuç üretilemez. Böylece tek bir jmp yaması işe yaramaz.

Demo 5 — Kontrol akışı sayacı ve skip saldırısı¶

Animasyon 10-14 aşamalı bir akışı, altın (golden) zincirle karşılaştırarak gösterir; in-order/skip-half/edge örneklerini deneyin — hiçbir aşama çalışmasa bile, ya da bütün aşamalar YANLIŞ sırada çalışsa bile zincir bozulur.

SCENARIO 1 - normal: every checkpoint runs in order
   [passed] checkpoint 0 (integrity (Demo 1))
   [passed] checkpoint 1 (anti-debug (Demo 2))
   [passed] checkpoint 2 (environment (Demo 3))
RESULT: PAYMENT APPROVED -> "PAYMENT-APPROVAL-TOKEN-4242"

SCENARIO 2 - skip: the checks are SKIPPED entirely (straight to the critical operation)
   [SKIPPED] no checkpoint ran
   (warning: count=0 visited_mask=0x0 expected=3/0x7)
RESULT: PAYMENT DENIED (wrong chain key).

SCENARIO 4 - reorder: the checks run in the WRONG ORDER
RESULT: PAYMENT DENIED (wrong chain key).

Normal akışta üç kontrol sırayla geçildi, zincir doğru oldu ve ödeme onaylandı. Kontroller atlandığında, kısmen geçildiğinde ya da yanlış sırada geçildiğinde zincir farklı çıktı; kritik işlem gerçek sonucu üretemedi ve sahte (decoy) döndü. Program ayrıca bir çift sayaç (count + visited_mask biti) tutar (K17); bu, anahtar zinciriyle birlikte üçlü bir tutarlılık kontrolü sağlar.

"Çift sayaç" neden gerekli, acc zinciri yetmiyor mu? acc zinciri hangi aşamaların hangi sırayla çalıştığını dolaylı olarak kanıtlar (yanlış aşama/sıra → yanlış anahtar), ama demo çıktısındaki uyarı satırında gördüğümüz gibi (warning: count=0 visited_mask=0x0 expected=3/0x7) program ayrıca iki basit sayaç daha tutar: count (kaç kontrol noktasının çalıştığını sayan düz bir tam sayı) ve visited_mask (her kontrol noktasının kendi bit konumunu 1 yaptığı bir bit kümesi, ör. 0., 1. ve 2. kontrol geçtiyse visited_mask = 0b111 = 0x7). Bunların amacı acc'ten farklıdır: acc kriptografik olarak güçlüdür ama tek başına "kaç kontrol geçti, hangileri" gibi okunabilir bir teşhis bilgisi vermez (HMAC çıktısından geriye "üç kontrol de geçti" diye çıkarım yapılamaz). count ve visited_mask, geliştiriciye ve günlüğe (log) okunabilir bir özet sağlarken, gerçek yetkilendirme kararı yine yalnız acc'ten türeyen anahtara dayanır — count ve visited_mask alanlarının kendisi yamalanıp 3 ve 0x7 yapılsa bile, acc zinciri yanlış olduğu için anahtar yine yanlış çıkar. Üç değer (acc, count, visited_mask) böylece birbirini çapraz doğrular: biri tutarsızsa günlükte fark edilir, hiçbiri tek başına yetkilendirme kararını değiştiremez.

9.1 İşlenmiş örnek: anahtar zincirini elle hesaplamak¶

acc = HMAC(acc, "stage-i") cümlesini soyut bırakmayalım; gerçek openssl komutlarıyla elle hesaplayalım. Başlangıç değeri acc0, 32 sıfır bayttan oluşan sabit bir anahtarla boş veriyi HMAC'leyerek üretilsin (gerçek sistemde bu, oturum başına rastgele üretilir):

A0=$(printf '' | openssl dgst -sha256 -mac HMAC \
     -macopt hexkey:0000000000000000000000000000000000000000000000000000000000000000 \
     -binary | xxd -p -c 256)
echo "acc0 = $A0"

acc0 = b613679a0814d9ec772f95d778c35fc5ff1697c493715653c6c712144292c5ad

Doğru sıra — kontrol noktası 0, sonra 1, sonra 2 sırayla geçilir. Her aşamada bir önceki acc anahtar, aşama etiketi veri olarak HMAC'lenir ve sonuç yeni acc olur:

A1=$(printf 'stage-0' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$A0 -binary | xxd -p -c 256)
A2=$(printf 'stage-1' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$A1 -binary | xxd -p -c 256)
A3=$(printf 'stage-2' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$A2 -binary | xxd -p -c 256)
echo "acc3 (DOGRU zincir) = $A3"

acc3 (DOGRU zincir) = e2db3f2ffdeefc8e58749330d64e0bab04e79b8ce63ba185fcd83a8c3e0942ee

Kritik işlem (ör. ödeme onayı), yalnız acc3 tam olarak bu değere eşitse doğru anahtarı türetir ve gerçek sonucu üretir — Demo 5'in normal senaryosu.

Saldırı — kontrol noktaları atlanır, yalnız birinci aşama çalışır. Saldırgan 0 ve 2 numaralı kontrol fonksiyonlarına giden çağrıları bir yamayla es geçer (Bölüm 3'teki je → jmp yamasıyla aynı fikir); yalnız stage-1 etiketi işlenir:

B1=$(printf 'stage-1' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$A0 -binary | xxd -p -c 256)
echo "acc (ATLANMIS zincir) = $B1"

acc (ATLANMIS zincir) = 1af937ede233313e8a3765bb48ca09a81970c91652abb42060838fcecb37bf73

e2db3f2f... ile 1af937ed... tamamen farklı iki değerdir. Kritik işlem bu yanlış acc'ten türettiği anahtarla gerçek sırrı açamaz; Demo 5'in skip ve reorder senaryolarında gördüğümüz "RESULT: PAYMENT DENIED ... a decoy is returned" sonucu tam olarak budur. Saldırganın jmp yaması hangi kontrolü atladığını değiştirmiyor bile — atlanan her kombinasyon farklı ama hep yanlış bir acc üretir, çünkü HMAC zinciri girdisindeki her değişikliği çığ etkisiyle yayar (Bölüm 3.1'deki aynı özellik, burada zincirlenmiş hâliyle).

10. Tepki (response) politikası, cihaz bağlama ve caydırma¶

Algılama tek başına işe yaramaz; asıl önemli olan tepkidir. Kötü bir tepki (ör. tespit anında exit(1)), saldırgana tam olarak hangi kontrolün tetiklendiğini söyler ve onu doğrudan o kontrolün yamasına yönlendirir. İyi bir tepki politikası saldırganı yavaşlatır ve yanıltır:

Cihaz bağlama (Hafta 3, §13.1'in, Demo 9'un en iç kabuğu) burada RASP'in bir parçası olur: değerli sır, cihaz parmak izinden ve sürüm dizesinden HKDF ile türetilen bir anahtarla sarılır. Telefon klonlansa, dosyalar başka cihaza kopyalansa bile anahtar farklı çıkar ve sır açılamaz.

10.1 İşlenmiş örnek: cihaz parmak izinden anahtar türetmek (adım adım HKDF)¶

Demo 8'in "cihaz/sürüm bağlama" adımını gerçek değerlerle elle izleyelim. crypto_hkdf_sha256, Hafta 3'te gördüğümüz RFC 5869 HKDF'in iki adımını (Extract, Expand) uygular; burada ikm (girdi anahtar malzemesi) cihaz parmak izi, tuz (salt) sürüm dizesi, info ise sabit bir bağlam etiketidir:

Adım 1 — Extract. Bu adım, uzunluğu ve rastgeleliği belirsiz olan ikm'i (cihaz parmak izi düz bir metindir, kriptografik olarak "iyi dağılmış" olmayabilir) sabit uzunlukta, güvenli bir ara anahtara sıkıştırır; bu ara anahtarın standart adı PRK'dir (Pseudo-Random Key — sözde rastgele anahtar): PRK = HMAC-SHA256(anahtar = tuz, veri = ikm). openssl ile aynı hesabı yapalım:

printf '%s' 'device=SIM-MODEL-A;serial=SN-0001;maker=DEMO' \
  | openssl dgst -sha256 -mac HMAC -macopt hexkey:$(printf '%s' 'version=1.0.0' | xxd -p -c 256) -binary \
  | xxd -p -c 256

PRK (gercek cihaz) = cdbff87f64c1f39f778590faf7f1825b1c6caf759cfaa38af5c7b6d386eb00f4

Adım 2 — Expand. İhtiyacımız 32 bayt (tek blok) olduğu için tek bir HMAC yeter: T1 = HMAC-SHA256(anahtar = PRK, veri = info || 0x01) (0x01, RFC 5869'daki blok sayacıdır). Bu T1, doğrudan 32 baytlık veri anahtarı olur:

anahtar (gercek cihaz) = 3c8af67f5d09f3bf2ee6be6164a99e8027a73a208ca43599909a4f63d06d7499

Adım 3 — aynı hesabı "başka cihaz" parmak iziyle tekrarlamak. Yalnız seri numarasını SN-0001'den SN-9999'a değiştirip (tıpkı bir saldırganın veri dosyasını başka bir telefona kopyalaması gibi) aynı iki adımı tekrarlayalım:

PRK (baska cihaz)      = ac53ee1fffc9fc61b5a2d3f874187855f40e6d3514d92a7df955d26e35638cdb
anahtar (baska cihaz)  = b68e35acc1ce116e1879a5dd6243e5c4a194821dbd234d15c2f0a22f462073d6

Sonuç. İki anahtar (3c8af67f... ve b68e35ac...) hiçbir ortak baytları olmayacak kadar farklıdır — tek bir karakterlik seri numarası farkı, HKDF'in HMAC çekirdeği yüzünden (Bölüm 3.1'deki çığ etkisi) baştan sona farklı bir anahtar üretir. Demo 8'in other-device senaryosunda gördüğümüz "device/version binding failed (cloned?)" sonucu tam olarak budur: paketin şifrelendiği anahtar (3c8af67f...) ile çözmeye çalışılan anahtar (b68e35ac...) aynı olmadığı için AES-GCM'in kimlik doğrulama etiketi tutmaz ve crypto_gcm_decrypt başarısız döner — sır hiçbir zaman açığa çıkmaz, dosyalar başka cihaza kopyalansa bile.

Demo 8 — RASP motoru: algılama + tepki + cihaz/sürüm bağlama (capstone)¶

SCENARIO 1 - normal: 0 failed checks, device matches -> NORMAL
RESULT: NORMAL. The secret opened and is in use -> "PAYMENT-KEY-7C4A"
(the secret was safely wiped from memory after use)

SCENARIO 2 - warn: 1 failed check -> WARN (still opens, just logged)
RESULT: WARN. One weak signal is not worth degrading service over.
The secret still opened -> "PAYMENT-KEY-7C4A"
   Policy: event logged, monitoring tightened, no functionality lost.

SCENARIO 3 - degrade: 2 failed checks -> DEGRADE (wiped, redacted result)
RESULT: DEGRADE. Multiple signals -> full trust withdrawn.
   Policy: secret wiped; a REDACTED result is returned, the full
   operation is refused, but the application keeps running.
RESULT-VALUE: PAYM**** (redacted)

SCENARIO 4 - lock: 3 failed checks -> LOCK (wipe + decoy + flag)
RESULT: LOCK -> detection checks failed (tamper)
   A DECOY result was returned instead of crashing: 9be972a7...

SCENARIO 5 - other-device: checks pass, device key does not hold -> LOCK
RESULT: LOCK -> device/version binding failed (cloned?)
   A DECOY result was returned instead of crashing: 39f368f4...

Normal akışta kontroller geçti, cihaz doğruydu, sır açıldı, kullanıldı ve hemen silindi (NORMAL). Tek bir kontrol başarısız olunca motor hâlâ sırrı açtı — ama olayı kaydetti (WARN); tek zayıf bir sinyal yüzünden meşru bir kullanıcının deneyimini bozmaya değmez. İki kontrol başarısız olunca sır silindi ve yalnız sansürlü bir sonuç döndü (DEGRADE) — uygulama tamamen durmadı, ama artık tam sonucu vermedi. Üç veya daha fazla kontrol başarısız olduğunda YA DA paket başka bir cihaza taşındığında (kontroller geçse bile) motor tam olarak kilitlendi (LOCK): sır silindi, decoy döndü, bayrak kaldırıldı. Bu, Hafta 3'teki güvenlik kabuğunun en iç katmanının (cihaz bağlama) RASP'in kademeli tepki politikasıyla birleşmiş hâlidir.

Dört durumu bir durum makinesi olarak görselleştirelim: aşağıdaki animasyon, bir izleme zaman çizelgesindeki her bağımsız çağrıyı (decide_response()'un gerçek karar tablosuyla) NORMAL/WARN/DEGRADE/LOCK durumlarından birine sınıflandırır ve hangi durumun ne sıklıkta tetiklendiğini özetler:

escalating/noisy/edge örneklerini deneyin; escalating örneği bir oturumun zamanla NORMAL'den LOCK'a nasıl kötüleşebileceğini, edge-all-device-mismatch ise cihaz uyuşmazlığının kontrol sayısından bağımsız olarak her zaman LOCK'a sıçradığını gösterir.

10.2 İşlenmiş örnek: aynı olaya üç farklı tepki, üç farklı sonuç¶

Bölüm 1.3'te aynı algılama sinyaline üç farklı tepkiyi kısaca karşılaştırmıştık; şimdi bunu Demo 8'in LOCK senaryosu üzerinden sonuç sonuç karşılaştıralım. Olay: üç kontrol başarısız oldu (Demo 8 SCENARIO 4 — lock). (Yalnızca bir kontrol başarısız olsaydı motor WARN durumuna geçer ve sırrı yine de açardı — bkz. Bölüm 10; decoy yalnız LOCK durumunda devreye girer.)

Üçü de aynı algılama koduna (Bölüm 1.3) dayanır; farkları yalnız ne zaman ve ne döndürdükleridir. Demo 8'in gerçek çıktısında © seçeneği LOCK durumunda uygulanır: "A DECOY result was returned instead of crashing: 9be972a7...". Bu sayı her çalıştırmada farklıdır (Alıştırma 7); sabit bir "HATA-0x1234" değeri olsaydı, saldırgan bu sabiti tanır ve gerçek sonuçtan ayırt ederdi — decoy'un rastgele olması bu ayrımı da engeller.

11. RASP'in sınırları ve etik¶

12. Dönem projesi: bu hafta¶

Bu hafta güvenlik kılavuzunuzun RASP (öz koruma) bölümlerini yazacak ve ilk RASP kontrolünüzü projenize ekleyeceksiniz. Bu, vize proje gösteriminin (Hafta 7) ve Quiz-1'in (Hafta 8, 1–6. haftalar) doğrudan konusudur; ara proje rubriğinde A2.4 RASP Teknikleri (15p → ÖÇ.3), final rubriğinde F2.4 Binary Uygulama Korumaları (15p → ÖÇ.3) olarak puanlanır.

• S10 — RASP algılama envanteri: Projenizdeki her kritik işlem için hangi RASP kontrollerini (bütünlük, anti-debug, ortam, kanca, root, imza) uyguladığınızı, her birinin neyi algıladığını ve nasıl atlatılabildiğini tabloya dökün.
• S10 — Tepki politikası: Tamper algılandığında ne olacağını yazın: hangi sır silinir, fail-closed mı, decoy mu, cihaz/sürüm bağlama var mı, sunucuya bildirim var mı.

| Kontrol            | Neyi algilar        | Nasil atlatilir      | Guclendirme        |
| ------------------ | ------------------- | -------------------- | ------------------ |
| Butunluk (HMAC)    | Ikili yama          | Checker yamalanir    | Ortusen denetleyici|
| Anti-debug         | Hata ayiklayici     | ptrace no-op / yama  | Coklu sinyal+sayac |
| Kanca algilama     | LD_PRELOAD/Frida    | maps gizleme         | dladdr + maps      |
| Cihaz baglama      | Klonlama            | (cihaza bagli)       | HKDF + AES-GCM     |

| Tetikleyici        | Tepki                          | Bildirim         |
| ------------------ | ------------------------------ | ---------------- |
| butunluk basarisiz | sirri sil + decoy + fail-close | sunucuya olay    |
| cihaz tutmaz       | ac-ma, decoy                   | sunucuya olay    |

13. Sınıf etkinlikleri¶

14. Kod okuma alıştırmaları¶

if (IsDebuggerPresent()) {
    exit(1);
}
do_payment();

uint32_t crc = crc32(code, code_len);
if (crc != EXPECTED_CRC) tamper();

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

unsigned int ecx;
__cpuid_ecx(1, &ecx);
if (ecx & (1u << 31)) {
    /* hypervisor bit set */
    exit(1);           /* "analysis environment, refuse to run" */
}

15. Kendi başına çalış¶

Bu alıştırmalar not verilmez; pekiştirme içindir. Hepsi kendi bilgisayarınızda, code/week-06 demoları üzerinde yapılır.

16. Kendini sınama¶

17. Quiz-1 tarzı örnek sorular¶

18. Kaynaklar ve ileri okuma¶

Ders kitabı — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Tarif 12.2 (Detecting Modification — CRC → HMAC/imza olarak güncellendi)
• Tarif 12.12–12.15 (Detecting Debuggers — Unix/Windows; SoftICE → modern araçlar)
• Bölüm 12 (Anti-Tampering) genel olarak bu haftanın ve Hafta 9'un çekirdeğidir.

Açık standartlar ve kaynaklar

• OWASP MASVS-RESILIENCE ve MASTG (mobil dayanıklılık: anti-debug, anti-tamper, root/emülatör algılama, imza doğrulama).
• Android APK Signature Scheme v2/v3 (yeniden paketlemeye karşı imza); Play Integrity / donanım destekli attestation.
• MITRE CWE: CWE-693 (Protection Mechanism Failure), CWE-919 (mobil zayıflıklar), CWE-925 (uygunsuz doğrulama).
• SEI CERT C: ENV ve FIO kuralları (ortam ve dosya güvenli kullanımı).