Linux'ta User Space Analizi ve ltrace: Kütüphaneler, Parolalar ve Zafiyetler

Önceki yazımızda Linux’ta CPU Profiling ve perf Kullanımı başlığı altında, CPU’yu sömüren hayalet süreçleri perf ile nasıl yakaladığımızı ve User Space’in derinliklerine nasıl indiğimizi görmüştük.

Peki ya sorun performans değilse? Ya bir “Gizli Veri” peşindeysek?

Önünüzde kapalı kutu (Black Box) bir program var. Çalıştırıyorsunuz, sizden bir parola istiyor. 12345 yazıyorsunuz. “Yanlış Parola!” diyor ve kapanıyor. Hemen en sevdiğiniz oyuncağınız strace‘e sarılıyorsunuz. “Kesin o parolayı bir dosyadan okuyor, yakalayacağım!” diyorsunuz.

Siz: “Göster bakalım dosya okumalarını!” Strace: read(0, "12345\n", ...) (Enter tuşu \n olarak gelir) Siz: “Eee? Karşılaştırma nerede? Doğru parola nerede?” Kernel: “Ben bilmem. Onlar kendi aralarında (User Space) fısıldaşıyor. Bana resmi bir evrak (Syscall) gelmedi.”

📚 Teknik Mola: Kütüphane Çağrısı (Library Call) Nedir? Linux Kernel’ı, strcmp (String Karşılaştırma) veya AES_encrypt (Şifreleme) gibi mantıksal işlemleri bilmez. Bunlar, işlemci (CPU) ve RAM arasında, Kernel’a hiç uğramadan gerçekleşir. strace sadece bir programın Devletle (Kernel) olan ilişkisini izler. ltrace ise programın Kütüphanelerle (libc, openssl) olan fısıldaşmalarını dinler.

Bu yazıda, strace‘in kör noktasını aydınlatıyor ve ltrace ile kütüphane çağrılarını canlı canlı dinliyoruz.

📌 Bu Yazıda Ne Öğreneceksin?

Bu yazı, sizi sadece bir gözlemci değil, bir “Tersine Mühendis” yapacak. Okumayı bitirdiğinizde:

• Görünmez Diyaloglar: strace‘in göremediği parola kontrollerini (strcmp) nasıl suçüstü yakalayacağınızı.
• Bellek Dedektifliği: malloc ve free takiplerini yaparak bellek sızıntılarını (Memory Leak) nasıl bulacağınızı.
• Kanca Atmak (Hooking): ltrace‘in çalışan bir programa canlı canlı nasıl “böcek” (Breakpoint) yerleştirdiğini.
• Security Bypass: Basit parola korumalarını kaynak kodu olmadan nasıl aşabileceğinizi (-s parametresinin gücü).

Hazırsanız, mikrofonları yerleştirelim. Hedefimiz: libc.

🧱 1. Büyük Resim: Syscall vs Library Call

Linux’ta bir programın dış dünyayla (Donanım, Ağ, Dosya Sistemi) konuşmasının tek yolu System Call (Syscall) yapmaktır. strace bunları yakalar.

Ancak programlar, tekerleği yeniden icat etmezler. Hazır fonksiyon kütüphanelerini kullanırlar (Shared Libraries).

• Ekrana yazı yazmak için printf (C kütüphanesi - libc)
• İki metni kıyaslamak için strcmp (libc)
• Şifreleme yapmak için AES_encrypt (OpenSSL)

Bu fonksiyonlara Library Call (Kütüphane Çağrısı) denir.

Metafor: Restoran ve Aşçı

• Programınız: Müşteri.
• Kernel: Garson. (Sadece siparişi mutfağa iletir ve yemeği getirir).
• Library (Kütüphane): Masadaki tuzluk, biberlik veya müşterinin kendi çatal bıçağı.

strace (Garsonu izleyen kamera), müşterinin garsona ne sipariş verdiğini görür (“Bana makarna getir” -> read()). Ama strace, müşterinin makarnayı yerken üzerine ne kadar tuz döktüğünü, yemeği kaç parçaya böldüğünü veya arkadaşıyla ne konuştuğunu GÖREMEZ. Bunlar masada (User Space) olur. Garsonu ilgilendirmez.

ltrace, masaya yerleştirilmiş gizli bir mikrofondur. Müşterinin “Tuzu uzatır mısın?” (malloc) veya “Bu yemek çok tuzlu olmuş” (strcmp) gibi kendi içindeki (veya kütüphane ile olan) etkileşimlerini kaydeder.

graph TD
    subgraph UserSpace ["User Space"]
        App["Uygulama (Müşteri)"]
        Lib["Kütüphane / libc (Tuzluk/Biberlik)"]
        
        App -- "strcmp / printf" --> Lib
        Lib -.-> App
    end
    
    subgraph KernelSpace ["Kernel Space"]
        Kernel["Kernel (Garson)"]
    end
    
    App -- "read / write" --> Kernel
    
    LTRACE["ltrace (Mikrofon)"] -.- UserSpace
    STRACE["strace (Kamera)"] -.- KernelSpace
    
    style UserSpace stroke:#4caf50,stroke-width:2px
    style KernelSpace stroke:#f44336,stroke-width:2px
    style LTRACE stroke:#4caf50,stroke-dasharray: 5 5
    style STRACE stroke:#f44336,stroke-dasharray: 5 5

🔬 2. Nasıl Çalışır? (PLT ve Dinamik Linkleme)

Linux’ta modern programların çoğu Dinamik Linkleme (Dynamic Linking) kullanır. Yani printf fonksiyonunun kodu, programın kendi içinde (.exe dosyasında) bulunmaz. Sistemdeki /lib64/libc.so.6 dosyasında durur.

Program çalışırken printf çağırdığında, aslında doğrudan o adrese gitmez. PLT (Procedure Linkage Table) denen bir sıçrama tahtasına gider. ltrace tam olarak buraya kancayı (hook) takar. Programın PLT tablosuna bir INT 3 (Software Breakpoint) talimatı enjekte eder. İşlemci bu talimata geldiğinde durur ve kontrolü Kernel üzerinden ptrace aracılığıyla ltrace‘e devreder. ltrace araya girer:

1. Programı durdurur.
2. Fonksiyonun adını (printf) ve parametrelerini (“Merhaba Dünya”) kaydeder.
3. Fonksiyonun çalışmasına izin verir.
4. Fonksiyon bitince geri dönen sonucu (return value) kaydeder.

sequenceDiagram
    participant App as Uygulama
    participant PLT as PLT (Sıçrama Tahtası)
    participant Lib as Libc (Gerçek Fonksiyon)
    participant Ltrace as ltrace (Ajan)

    Note over App: "printf" çağırıyor...
    App->>PLT: Jump to PLT
    
    Note right of PLT: 🛑 INT 3 (Breakpoint)!
    PLT->>Ltrace: Sinyal Gönder (SIGTRAP)
    Ltrace->>Ltrace: Logla: "printf('Merhaba')"
    
    Ltrace->>Lib: Orijinal Kodu Çalıştır
    Lib-->>Ltrace: Sonuç Döndü (Return)
    Ltrace->>App: Devam Et

🧠 Teknik Detay: Procedure Linkage Table (PLT) Bir program derlendiğinde, printf fonksiyonunun bellekteki yerini bilemez. (Çünkü libc.so her açılışta RAM’in farklı bir yerine yüklenebilir - ASLR). Bu yüzden derleyici, kodun içine “Gerçek adresi bilmiyorum ama PLT tablosuna sor” diyen bir not bırakır. Program ilk kez printf çağırdığında, PLT tablosu gerçek adresi bulur (Lazy Binding) ve oraya zıplar. ltrace işte bu tabelayı manipüle eder.

Bu sayede, kaynak kodunu görmediğiniz bir programın, hangi fonksiyonları hangi parametrelerle çağırdığını canlı izleyebilirsiniz.

👑 Teknik Sözlük: ptrace (Process Trace) Linux’un “Tanrı Modu” sistem çağrısıdır. Bir sürecin (Tracer), başka bir sürecin (Tracee) hafızasını okumasını, yazmasını, durdurmasını ve adım adım işletmesini sağlar. gdb, strace ve ltrace araçlarının hepsi arka planda bu gücü kullanır.

🕵️‍♂️ 3. Vaka Analizi: Gizli Parolayı Bulmak (CTF Tarzı)

💡 İpucu: Analize başlamadan önce ldd ./program ile kütüphane bağımlılıklarına bakmayı unutmayın.

Hadi basit bir senaryo üzerinden gidelim. Elimizde gizli_kasa adında derlenmiş bir program var. Kaynak kodu yok.

./gizli_kasa
Parolayı Girin: 12345
Yanlış Parola!

strace ile baktık, bir şey çıkmadı. Şimdi ltrace zamanı.

# -s 100: String limitini artır (Varsayılan 32 karakterdir, uzun parolaları keser)
ltrace -s 100 ./gizli_kasa

Çıktı akar:

__libc_start_main(...)
printf("Parolayı Girin: ")                       = 16
fgets("12345\n", 100, 0x7f...)                   = 0x7ffe...
strcspn("12345\n", "\n")                         = 5
strcmp("12345", "SusamAcil")                     = -1
printf("Yanlış Parola!\n")                       = 15
exit(1)

BINGO!

1. satıra dikkat edin: strcmp("12345", "SusamAcil") Program, bizim girdiğimiz “12345” değerini, kendi içindeki “SusamAcil” değeriyle kıyaslıyor (strcmp - String Compare). Ve sonuç -1 (Eşit değil) dönüyor.

strace bunu asla göremezdi çünkü karşılaştırma işlemi CPU’nun register’larında yapıldı. Kernel’a bir iş düşmedi. Ama ltrace, strcmp fonksiyonunun (libc kütüphanesi) arasına girerek parametreleri yakaladı.

(Not: strace çıktısında gördüğünüz read çağrısı, aslında libc içindeki fgets fonksiyonunun Kernel’dan isteğidir. ltrace ise aradaki fgets‘i yakalar.)

💡 Kullanım Alanı: Bu yöntem, tersine mühendislik (Reverse Engineering), Malware analizi ve kaybedilen konfigürasyon şifrelerinin kurtarılması için son derece güçlüdür.

🧠 4. malloc ve Bellek Sızıntısı (Memory Leak) Takibi

Bir programın çok RAM tükettiğini düşünüyorsunuz ama top dışında elinizde kanıt yok. Programın ne kadar bellek istediğini ve bunu iade edip etmediğini görmek istiyorsunuz. Bellek ayırma işlemi (malloc, calloc) ve iade işlemi (free) birer kütüphane çağrısıdır.

📦 Teknik Sözlük: Stack vs Heap

• Stack (Yığın): Düzenlidir. Fonksiyon değişkenleri burada tutulur. Fonksiyon bitince otomatik temizlenir. Hızlıdır ama boyutu sınırlıdır.
• Heap (Öbek): Karmaşıktır. malloc ile buradan yer istersiniz. İşiniz bitince free ile iade etmek zorundasınız. Etmezseniz o alan sonsuza kadar kilitli kalır (Memory Leak) ve sonunda RAM biter (OOM Killer gelir).

# Sadece malloc ve free çağrılarını izleyelim (-e filtresi)
ltrace -e malloc+free ./memory_hog

Çıktı:

malloc(1024)         = 0x55a1...
malloc(2048)         = 0x55a2...
free(0x55a1...)      = <void>
... (Program devam ediyor) ...

Eğer sürekli malloc görüyor ama hiç free görmüyorsanız, tebrikler, bir Memory Leak (Bellek Sızıntısı) buldunuz. Yazılımcıya bu çıktıyı göndererek “Bak, sürekli yer ayırıyorsun ama temizlemiyorsun” diyebilirsiniz.

⚙️ 5. Konfigürasyon Dosyası Nereye Gitti? (getenv)

Bazen programlar dosya yollarını (Path) çevre değişkenlerinden (Environment Variables) okur. Program çalışıyor ama config dosyasını bulamıyor. strace ile open çağrılarına bakıyorsunuz, hiçbir şey yok. Çünkü program dosya yolunu oluşturamadığı için open çağırma aşamasına gelemiyor bile!

ltrace ile getenv çağrılarını izleyelim:

ltrace -e getenv ./myapp

Çıktı:

getenv("MYAPP_CONFIG_PATH")      = NULL
getenv("HOME")                   = "/home/ali"

Program MYAPP_CONFIG_PATH değişkenini okumaya çalışmış ama NULL (Boş) dönmüş. Demek ki bu değişkeni set etmeyi unuttunuz! Program da varsayılan bir yol olmadığı için sessizce hata moduna geçti. strace bunu gösteremezdi çünkü getenv sadece process’in kendi hafızasındaki environment bloğunu okur, kernel’a gitmez.

⚠️ 6. Karanlık Taraf: ltrace’in Sınırları ve Riskleri

Her kahramanın bir zayıf noktası vardır. ltrace her derde deva değildir.

A. Statik Derlenmiş Programlar (Statically Linked Binaries)

Burada bir ayrım yapalım:

• Stripped Binaries (Debug sembolleri silinmiş): ltrace ÇALIŞIR. Çünkü programın çalışması için gerekli olan dinamik semboller (Dynamic Symbols - .dynsym) silinemez. ltrace bunları kullanır.
• Statically Linked (Statik Derlenmiş): ltrace ÇALIŞMAZ. Çünkü kütüphaneler (libc) programın içine gömülmüştür. Dışarıya giden bir PLT jump yoktur. Özellikle Go ve Rust programlarında bu durumla sık karşılaşılır. (Not: Go programları için user space probing veya uprobes gerekir, bu başka bir yazının konusu).

💡 İpucu: Eğer ltrace çok yavaş geliyorsa veya programın davranışını değiştirmek istiyorsanız, LD_PRELOAD tekniğini araştırın. ltrace edilgendir (izler), LD_PRELOAD etkendir (fonksiyonu kendi yazdığınız kodla değiştirir).

B. Aşırı Yavaşlık

strace, kernel seviyesinde çalıştığı için performansı nispeten az etkiler. Ancak ltrace, programı her fonksiyonda durdurur (sıçrama yapar). Eğer programınız saniyede milyonlarca kez döngü içinde strcmp veya memcpy yapıyorsa, ltrace ile çalıştırdığınızda program 100 kata kadar yavaşlayabilir. Production ortamında ltrace çalıştırırken çok dikkatli olun.

C. Güvenlik Kısıtlamaları

Bazı Linux dağıtımları (Ubuntu, Fedora), güvenlik gereği bir kullanıcının başka süreçleri “trace” etmesini kısıtlar (ptrace_scope). Root olmanız gerekebilir. (Genellikle /proc/sys/kernel/yama/ptrace_scope değeri 1 veya 2 olduğu için. Geçici çözüm: echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope)

🧬 7. Modern Zorluklar: C++ ve Mangling (-C)

C++ ile yazılmış programlarda fonksiyon isimleri _ZNSt7__cxx1112basic_stringIcSt11char_traits... gibi korkunç görünür (Name Mangling).

📖 Teknik Detay: Name Mangling C dilinde fonksiyonlar basittir: topla(). Ama C++’ta, aynı isimde birden fazla fonksiyon olabilir (Overloading). Derleyici bunları birbirinden ayırmak için isimleri şifreler (Mangle). topla(int) fonksiyonunu _Z5toplai yapar. İnsan gözü bunu okuyamaz. ltrace -C (Demangle), c++filt aracı gibi çalışarak bu şifreyi çözer ve size tekrar topla(int) gösterir.

# -C: İsimleri düzelt (Demangle)
ltrace -C ./oyun_sunucusu

Adres Takibi (-i) ve ASLR

“Bu strcmp çağrısını kodun neresi yaptı?” diye merak ediyorsanız (Ghidra/IDA’da bakmak için), -i ile Instruction Pointer (IP) adresini yazdırın.

ltrace -i ./program
# Çıktı: [0x40125a] strcmp(...)

⚠️ Önemli Not (ASLR & PIE): Modern Linux dağıtımlarında (Arch, Fedora, Ubuntu) PIE (Position Independent Executable) varsayılan olarak açıktır. Bu, programın her çalıştığında RAM’in farklı bir adresine yüklenmesi (ASLR - Address Space Layout Randomization) demektir.

🏠 Analoji: Taşınan Ev (ASLR) ASLR, evinizin adresini her gün değiştirmek gibidir. Dün “Atatürk Cad. No:5”teydiniz, bugün “İnönü Cad. No:12”desiniz. ltrace size sadece o anki geçici adresi gösterir. Eğer evi haritada (Ghidra) bulmak istiyorsanız, adresi değil, evinizin sokak başından ne kadar uzakta olduğunu (Base Address + Offset) bilmeniz gerekir.

⚠️ 8. User Space Savaş Alanı: Zafiyetler ve Anti-Forensics

Dedektiflik basit vakalarla bitmez. Gerçek dünyada karşınıza çıkacak zorluklar şunlardır:

A. Çoklu Süreç Takibi (-f)

Apache, Nginx veya modern malware’ler tek bir süreçte çalışmaz. fork() veya clone() çağrıları yaparak “yavru süreçler” (child processes) oluştururlar. Eğer -f kullanmazsanız, ltrace sadece ana kapıdaki güvenlik görevlisini izler, arka kapıdan giren hırsızları (child processes) kaçırır.

🍴 Teknik Sözlük: fork() Mevcut sürecin (Process) birebir kopyasını oluşturur. Kod, değişkenler, her şey kopyalanır. Ayrım şudur: Eğer uygulamanız “Thread” kullanıyorsa tek bir sürecin altında çalışır (ltrace genelde görür). Ama “Process” (fork) kullanıyorsa tamamen yeni bir Kimlik (PID) alır ve ltrace’in radarından çıkar. -f bu yüzden gereklidir.

👨‍💼 Analoji: Müdür ve Stajyerler Ana süreç (Parent) bir “Müdür” gibidir. İşi kendisi yapmaz, fork() yaparak bir “Stajyer” (Child) yaratır, dosya indirme işini ona devreder ve kahvesini yudumlar. Eğer -f kullanmazsanız, ltrace sadece Müdür’ü izler (ki o hiçbir şey yapmıyordur). Asıl işi yapan stajyeri görmek için -f (Follow) şarttır.

# -f: Follow Fork (Yavruları da izle)
ltrace -f -e "open+write" ./web_server

B. Zafiyet Avı: Buffer Overflow Yakalamak

Bir güvenlikçi olarak sadece parolayı değil, hatayı da aramalısınız. ltrace ile hafıza taşmalarını (Buffer Overflow) tespit edebilirsiniz. Örnek: Program 10 byte yer ayırmış ama 100 byte kopyalamaya çalışıyor.

malloc(10)                       = 0x55a1...
strcpy(0x55a1..., "AAAA...(100 tane A)...")

Bu çıktıyı gördüğünüz an, orada bir Heap Overflow zafiyeti olduğunu anlarsınız. Kaynak koda bile bakmadan “Burada taşma var!” diyebilmek büyük süksedir.

Yazılımcı malloc(10) diyerek masaya “Yarım Litrelik Bardak” koydu. Ama sonra strcpy ile bu bardağa “1 Litre Su” boşalttı. Sonuç? O yarım litre taşar ve masadaki diğer önemli evrakları (Return Address, Function Pointers) ıslatıp bozar. ltrace size “Bardağın boyu 10, dökülen su 100” diye bağırır.

graph TD
    subgraph Memory ["BELLEK (Yığın/Heap)"]
        Alloc["Malloc(10 Byte) - Bardak"]
        Overflow["Strcpy(100 Byte) - Sürahi"]
        
        Overflow -- "Veri Kopyala" --> Alloc
        Alloc -.->|TAŞMA!| Crash["Hafıza Bozulması (Segfault)"]
    end
    
    style Alloc stroke:#4caf50,stroke-width:2px
    style Overflow stroke:#f44336,stroke-width:2px
    style Crash stroke:#f44336,stroke-width:4px
    style Memory stroke:#fff,stroke-width:1px,stroke-dasharray: 5 5

C. Düşmanı Tanı: Anti-Debugging

Her suçlu teslim olmaz. Bazı programlar (özellikle malware’ler), izlendiklerini anlarlarsa kendilerini kapatırlar veya sahte davranış sergilerler. En yaygın taktik ptrace kontrolüdür:

🛑 Anti-Debug Mantığı: Linux’ta bir süreci aynı anda sadece BİR kişi ptrace ile izleyebilir. Malware başlatıldığında hemen kendi kendine ptrace(PTRACE_TRACEME, 0, ...) çağrısı yapar.

• Eğer başarılı olursa: “Tamam, beni kimse izlemiyor.” der ve kötü niyetli kodunu çalıştırır.
• Eğer başarısız olursa (-1 dönerse): “Biri (ltrace/strace/gdb) beni zaten izliyor!” der ve hemen kapanır (exit).

🎬 Analoji: Truman Show Bir film setindesiniz (Process). Rejisör (Kernel) sizi yönetiyor. ptrace kuralı şudur: Sadece bir yönetmen olabilir. Malware uyanıktır. Sete girer girmez “Yönetmen benim!” diye bağırır (PTRACE_TRACEME). Eğer Kernel “Tamam” derse sorun yok. Ama Kernel “Hayır, zaten başka bir yönetmen (ltrace/strace) seni şu an çekiyor” derse (-1 hatası), Malware tuzağa düştüğünü anlar ve intihar eder (exit).

graph TD
    Start["Malware Başlatıldı"] --> Call["ptrace(PTRACE_TRACEME)"]
    Call --> Kernel{"Kernel Kontrolü<br>(Başka kimse izliyor mu?)"}
    
    Kernel -- "HAYIR<br>(Özgürsün)" --> Success["Normal Çalışmaya Devam Et"]
    Kernel -- "EVET<br>(ltrace seni izliyor!)" --> Fail["Tespit Edildi!"]
    
    Fail --> Exit["KENDİNİ KAPAT (exit)"]
    
    style Start stroke:#fff,stroke-width:2px
    style Call stroke:#2196f3,stroke-width:2px
    style Kernel stroke:#ff9800,stroke-width:2px
    style Success stroke:#4caf50,stroke-width:2px
    style Fail stroke:#f44336,stroke-width:2px
    style Exit stroke:#f44336,stroke-width:4px

Bu durumda ltrace kullanarak analiz yapamazsınız. Frida gibi daha gelişmiş araçlarla bu kontrolü atlatmanız (bypass) gerekir.

🛠️ 9. Profesyonel İpuçları ve Filtreleme

Gerçek hayatta ltrace çıktısı binlerce satır olabilir. Samanlıkta iğne aramamak için filtreleme şarttır.

1. Sadece Belirli Kütüphaneyi İzle (-l): Sadece OpenSSL çağrılarını görmek istiyorsanız:

   ltrace -l libssl.so* ./https_client
   

2. Sadece Belirli Fonksiyonları İzle (-e): Sadece string işlemlerini gör:

   ltrace -e "str*+mem*" ./text_processor
   

3. Çağrı İç İçe Derinliğini Sınırla (-n): Çıktı çok içeri giriyorsa okunabilirliği artırmak için indentasyonu ayarlayın.

4. Zaman Damgası (-T): Hangi kütüphane çağrısı ne kadar sürdü? Performans analizi için.

   Connect(...) = 0 <0.502>  (500ms sürmüş)
   

5. Otomasyon için Çıktıyı Kaydet (-o): Analizi daha sonra sakince incelemek veya grep ile taramak için çıktıyı dosyaya yazın.

   ltrace -o analiz_raporu.txt ./program
   

🤝 10. ltrace ve strace Ne Zaman Birlikte Kullanılır?

En iyi debug yöntemi, ikisini birleştirmektir. Bazen bir problemin kökü User Space’te başlar (ltrace), Kernel Space’te biter (strace).

Örnek: DNS Çözümleme.

1. User Space (ltrace): Program getaddrinfo("google.com") fonksiyonunu çağırır.
2. Library Logic: libc, /etc/resolv.conf dosyasını okur (User Space logic).
3. Kernel Space (strace): Kernel, DNS sunucusuna (8.8.8.8) UDP paketi (syscall sendto) gönderir.

Bu akışı tam anlamak için bazen iki aracı da kullanmak, hatta “Hangi parametreyle girdi, hangi syscall’a dönüştü?” sorusunu cevaplamak gerekir.

👋 Son Söz: Dedektiflik Seviye Atlıyor

Linux sistem programlama serisinin bu bölümünde, Kernel’ın güvenli ama sınırlı dünyasından çıkıp, uygulamaların kaotik ve karmaşık User Space dünyasına adım attık.

Öğrendik ki:

• Syscall (Kernel) her şey değildir. Mantık ve Karar Mekanizmaları User Space’tedir.
• strace dışarıyı, ltrace içeriyi izler.
• strcmp, parolaları bulmanın anahtarıdır.
• malloc/free dengesi, bellek sağlığı için kritiktir.

Bir sonraki yazımızda, bu işi bir adım daha ileri götüreceğiz. Hazır araçların yetmediği, kaynak kodunu değiştiremediğimiz ve Production’ı durduramadığımız durumlarda, canlı dokuya müdahale etmemizi sağlayan eBPF ve Dynamic Tracing teknolojilerini konuşacağız.

O zamana kadar, kütüphaneleriniz güncel, sembolleriniz (Debug Symbols) açık olsun. Saklanacak bir şeyiniz yoksa, ltrace‘den korkmanıza da gerek yok :)