Siber Güvenlik Uzmanlığı Eğitimi

Siber güvenlik yalnızca saldırı araçlarının kullanımı veya hazır komutların uygulanması şeklinde ele alınmaz. Eğitimde bir sistemin nasıl çalıştığı, hangi katmanlarda güven sınırları oluşturduğu, bu sınırların hangi hata sınıflarıyla bozulabildiği ve sistemin saldırı sonrasında hangi teknik izleri bıraktığı incelenir.
Katılımcılar yalnızca “hangi araç kullanılır?” sorusuna değil; “bu araç sistemde hangi davranışı gözlemliyor, hangi varsayıma dayanıyor ve verdiği sonuç nasıl doğrulanır?” sorularına cevap üretir.
Eğitimin temel akışı şöyledir:
Sistem nasıl çalışır → Güven sınırı nerede oluşur → Hata nasıl ortaya çıkar → Yetki nasıl değişir → Sistem nasıl korunur → Olay nasıl doğrulanır?

Hayır. HTTP, tarayıcı güvenliği, session yönetimi ve XSS gibi web konuları işlenir; ancak programın ana ekseni web uygulamalarından ibaret değildir.
Eğitimin ağırlık merkezi Linux ve Android işletim sistemi mimarileri, kernel-user space ilişkisi, process ve yetki modeli, donanım haberleşme hatları, firmware analizi, boot zinciri, tersine mühendislik, dinamik enstrümantasyon ve exploit mekanizmalarıdır.
Web güvenliği, sistem güvenliğinin uygulama katmanındaki bir örneği olarak ele alınır. Asıl amaç, öğrencinin yalnızca bir web payload’ını değil, farklı platformlardaki güvenlik sınırlarını okuyabilmesidir.

Evet. Terminal, Linux, ağ, sanallaştırma ve temel programlama bilgileri eğitim içinde oluşturulur. Önceden profesyonel siber güvenlik deneyimi zorunlu değildir.
Bununla birlikte eğitim yüzeysel bir farkındalık semineri değildir. Başlangıç seviyesinden ilerleyen katılımcılar zaman içinde system call, process memory, Linux erişim kontrolleri, kernel mitigation’ları, firmware, bootloader, Android Binder, SELinux, Zygote ve Verified Boot gibi ileri konularla karşılaşır.
Önceden bilmek zorunlu değildir; mekanizmayı öğrenmek ve teknik ayrıntıya emek vermek zorunludur.

Çalışmalar izinli ve izole laboratuvar ortamlarında yürütülür. VirtualBox ve UTM gibi sanallaştırma platformlarıyla host, hypervisor ve guest sistemleri birbirinden ayrılır.
NAT, bridged ve host-only ağ modelleri; snapshot, geri yükleme, sanal disk, sanal ağ kartı ve kaynak sınırlandırma davranışları incelenir. Bir sanal makinenin yalnızca ayrı bir pencere olmadığı; kendi firmware, kernel, process, filesystem ve ağ görünümüne sahip bir sistem olduğu gösterilir.
Laboratuvar kurulumu yalnızca işletim sistemi yüklemek değildir. Test sisteminin hangi ağa erişebileceği, host ile hangi kaynakları paylaşabileceği ve bir hata sonrasında nasıl güvenli duruma döndürüleceği de tasarlanır.

Linux yalnızca terminal komutları ezberletilerek anlatılmaz. Kernel, dağıtım, shell, terminal, process, service, filesystem ve package manager gibi sık karıştırılan katmanlar birbirinden ayrılır.
Bir grafik arayüz davranışının altında hangi process’in, system call’un, permission kontrolünün, service’in, logun ve kernel state’inin oluştuğu incelenir.
Kernel space ve user space, system call arayüzü, VFS, process yaşam döngüsü, PID/PPID, UID/GID, signals, virtual memory, file descriptor, socket, /proc, systemd ve journal birbirine bağlı biçimde ele alınır.

Çünkü diskte bulunan program dosyası ile o programın çalışan process’i aynı şey değildir. Çalışan process’in kendi kimliği, parent process’i, yetkileri, memory map’i, açık dosyaları, socket’leri, environment alanı ve signal davranışı bulunur.
Şüpheli bir process yalnızca görünen adına bakılarak değerlendirilmez. Gerçek executable yolu, komut satırı, parent-child ilişkileri, UID/GID ve capability setleri, açık file descriptor’lar, memory map, ağ bağlantıları, bağlı service, paket kaynağı ve log kayıtları birlikte incelenir.
Açık bir porttan socket’e, socket’ten process’e, process’ten executable’a ve executable’dan paket kaynağına kadar kanıt zinciri oluşturulur.

Evet. Kernel güvenliği yalnızca kernel sürümünü bir CVE listesiyle eşleştirmek şeklinde ele alınmaz.
Dağıtımların güvenlik yamalarını geriye taşıyabileceği; aynı görünen kernel sürümünün paket revision’ı, build configuration’ı, mimarisi ve etkin mitigation’ları nedeniyle farklı güvenlik davranışı gösterebileceği açıklanır.
Kernel exploit analizinde şu ayrımlar incelenir:
Kullanıcı alanından kernel alanına ulaşan giriş noktası
Hatanın oluştuğu subsystem veya driver
Memory corruption, mantık hatası veya yarış durumu gibi vulnerability sınıfı
Hatanın yalnız crash mi ürettiği, yoksa kontrol edilebilir bir primitive oluşturup oluşturmadığı
Kernel state veya kontrol akışı üzerinde ne ölçüde etki kurulabildiği
Credential ve privilege sınırının nasıl değiştiği
Mitigation’ların zinciri hangi noktada durdurduğu
Olayın hangi log, crash veya memory izlerini bıraktığı
Bir vulnerability’nin tetiklenmesi ile güvenilir exploit zinciri oluşturulması aynı şey değildir.

Modern işletim sistemlerinde bir bellek hatasının bulunması otomatik olarak yetki yükseltme anlamına gelmez. Exploit zincirinin aktif güvenlik önlemleriyle birlikte değerlendirilmesi gerekir.
Eğitimde mimariye ve platforma göre KASLR, NX, stack canary, SMEP, SMAP, PAN, CFI, hardened usercopy, seccomp, kernel lockdown, module signature, SELinux ve diğer LSM politikaları ele alınır.
Amaç bir mitigation ismini ezberlemek değil; hangi saldırı primitive’ini engellediğini, hangi varsayıma dayandığını ve tek başına neden mutlak koruma sağlamadığını anlamaktır.
Aynı PoC’nin patch, config, mimari ve mitigation farkı nedeniyle başka sistemde çalışmayabileceği açıklanır.

Exploit, tek bir sihirli kod parçası olarak değil, birbirine bağlı aşamalardan oluşan bir yetki ve güven sınırı geçişi olarak incelenir.
Genel analiz modeli şöyledir:
Giriş noktası → Hata sınıfı → İlk primitive → Kontrol akışı veya state etkisi → Sandbox/privilege sınırı → Kernel veya güvenli dünya geçişi → Kalıcılık → Veri erişimi → Forensic iz → Mitigation
Bir uygulama açığının yalnızca uygulama process’i içinde kod yürütmesi ile sandbox dışına çıkması aynı şey değildir. Benzer biçimde kernel code execution, bootloader kontrolü veya TrustZone seviyesine ulaşmak birbirinden farklı güven sınırlarıdır.
Vaka analizlerinde zincirin hangi halkasının kullanıcı alanında, hangisinin kernel’de, hangisinin boot veya güvenli yürütme ortamında gerçekleştiği ayrıştırılır.

Donanım bölümü yalnızca UART kablosu bağlayıp terminal çıktısı okuma seviyesinde değildir. Bir cihazın kartı üzerindeki işlemci, flash, EEPROM, güç, clock, reset, debug ve haberleşme yüzeyleri birlikte değerlendirilir.
Test point, pinout, voltage level, ortak ground, signal direction, baud rate, clock, frame ve bus timing gibi fiziksel koşullar incelenir. Bir hatta veri görülmesi ile bu verinin doğru protokol, clock ve elektriksel referansla okunması arasındaki fark gösterilir.
UART, SPI ve I²C hatları üzerinden cihazın boot davranışı, hata mesajları, servis arayüzleri, çevrebirim trafiği ve bellek erişim modelleri analiz edilir. Logic analyzer ve gerektiğinde osiloskop kullanılarak yazılımda görünmeyen fiziksel trafik gözlemlenir.
Donanım katmanı, uygulamadan bağımsız ayrı bir dünya değil; firmware ve işletim sisteminin fiziksel olarak çalıştığı temel olarak ele alınır.
11. UART, SPI ve I²C güvenlik açısından nasıl incelenir?
Her protokol hem elektriksel hem de mantıksal katmanda değerlendirilir.
UART’ta TX/RX yönü, baud rate, frame yapısı, parity, boot logları ve debug console davranışı incelenir. SPI tarafında clock, MOSI, MISO, chip-select, flash command’ları ve bellek transaction’ları ele alınır. I²C’de open-drain yapı, pull-up dirençleri, adresleme, ACK/NACK, timing ve ortak bus davranışı analiz edilir.
Amaç yalnız paket decode etmek değildir. Hattın boot sırasında aktif olup olmadığı, üretim cihazında debug erişiminin açık kalıp kalmadığı, trafikte hassas veri bulunup bulunmadığı, harici flash ile işlemci arasındaki verinin doğrulanıp doğrulanmadığı ve firmware güncelleme akışının bu hatlardan etkilenip etkilenemediği araştırılır.

Firmware yalnızca bir araçla dosya çıkarmak şeklinde değerlendirilmez. Önce firmware’in cihaz içindeki görevi ve hangi işlemci-bellek mimarisi için üretildiği belirlenir.
Dosya formatı, header, section, memory map, reset vector, string’ler, sabitler, fonksiyonlar, register erişimleri, protokol kodu, hata mesajları ve update bileşenleri incelenir.
Ghidra ile mimari ve endianness belirleme, code/data ayrımı, function boundary analizi, cross-reference takibi, control-flow graph incelemesi, donanım register erişimlerinin yorumlanması ve güncelleme fonksiyonlarının bulunması ele alınır.
Decompiler çıktısının orijinal kaynak kod olmadığı; optimizasyon, sembol kaybı ve dolaylı çağrıların analiz sonucunu etkileyebileceği özellikle vurgulanır.

Evet. Cihazın yalnızca çalışan işletim sistemi değil, ilk güç verildiği andan itibaren oluşan güven zinciri incelenir.
Boot ROM, bootloader, firmware image, kernel, recovery ve kullanıcı alanı arasındaki doğrulama ilişkileri ele alınır. Root of trust, imza doğrulama, hash zinciri, rollback protection, recovery politikası ve güncelleme bütünlüğü değerlendirilir.
Bir boot zincirinde her katman güvenli görünse bile zincirin en zayıf doğrulama veya geçiş noktası tüm sistemi etkileyebilir.
Boot ve recovery modlarının cihaz üzerinde hangi veri, kontrol ve güncelleme yüzeylerini açtığı; crash dump ve memory region bilgilerinin nasıl yorumlandığı da ele alınır.

Evet. Normal dünya ile güvenli dünya arasındaki ayrım yalnızca “gizli bölge” şeklinde anlatılmaz.
İşlemci ayrıcalık seviyeleri, secure ve non-secure kaynaklar, exception geçişleri, secure service çağrıları, shared memory ve güven sınırları incelenir.
Bir kullanıcı alanı açığının doğrudan TrustZone kontrolü anlamına gelmediği; gelişmiş zincirlerde uygulama, kernel, secure world ve ayrı güvenlik işlemcisi gibi birden fazla bağlamın aşılması gerekebileceği gösterilir.
Bu yaklaşım, “root oldum, sistemdeki her şeyi kontrol ederim” düşüncesinin neden her platform için doğru olmadığını açıklar.

Evet. Fault injection, programın ileri seviye donanım ve firmware güvenliği bölümünde kavramsal, mimari ve savunma odaklı olarak ele alınır.
Voltage glitch, clock glitch, brownout ve beklenmeyen reset gibi fiziksel hata koşullarının işlemci zamanlamasını, instruction yürütmesini, branch kararlarını, exception davranışını ve güvenlik doğrulamalarını nasıl etkileyebileceği incelenir.
Bu konu özellikle Secure Boot ve bootloader güvenliğiyle ilişkilendirilir. İmza veya bütünlük kontrolünün normal koşullarda doğru çalışmasının tek başına yeterli olmadığı; sistemin zamanlama ihlali, yanlış yürütme, kesinti ve reset durumlarında da güvenli davranması gerektiği açıklanır.
Savunma tarafında fail-secure tasarım, bağımsız doğrulama, boot state kontrolü, hassas verinin güvenli biçimde temizlenmesi, reset nedenlerinin kaydedilmesi, watchdog davranışı ve güvenlik kararlarının tek bir kritik zamanlama penceresine bağlanmaması ele alınır.
Cihaza özgü saldırı parametreleri veya yetkisiz sistemlere yönelik uygulama reçeteleri yerine, fiziksel hata enjeksiyonunun hangi güven varsayımlarını bozduğu ve dayanıklı sistemlerin buna karşı nasıl tasarlandığı incelenir.

Android güvenliği yalnızca APK açıp permission listesine bakmak şeklinde işlenmez. Android’in uygulama katmanından donanıma kadar uzanan mimarisi incelenir:
Uygulama → Java API Framework → System Service → Binder IPC → HAL → Kernel Driver → Donanım
Her Android uygulamasının ayrı Linux UID ile çalışması, filesystem izinleri, SELinux domain’i, PackageManager kaydı, runtime permission’lar, uygulama imzası ve Binder service kontrolleri birlikte değerlendirilir.
Android sandbox’ın tek bir güvenlik mekanizması olmadığı; Linux UID, SELinux, package signing, Binder permission checks, Verified Boot ve filesystem isolation gibi birden fazla katmandan oluştuğu gösterilir.

APK; manifest, DEX bytecode, resource tablosu, native kütüphaneler ve imza yapısından oluşan bir paket olarak incelenir.
Manifest üzerinde activity, service, receiver, provider, intent-filter, exported ve permission ilişkileri değerlendirilir. PackageManager’ın kurulum sırasında imza, paket adı, version, UID ve component kayıtlarını nasıl oluşturduğu ele alınır.
JADX ile DEX yapısı, APKTool ile manifest-resource-Smali, ADB ile canlı package ve process durumu, apksigner ile imza bütünlüğü, Ghidra ile native .so dosyaları incelenir.
WebView, exported component, SharedPreferences, SQLite, dosya alanları, loglar, native JNI katmanı ve istemci tarafı güvenlik kararları analiz edilir. Otomatik analiz raporları sonuç kabul edilmez; manuel ve runtime kontrolleriyle doğrulanır.

Android uygulamaları çoğu sistem kaynağına doğrudan ulaşmaz. Kamera, konum, paket bilgisi, pencere yönetimi ve benzeri işlevler system service’ler üzerinden sunulur.
Uygulama API çağrısı yapar; istek Binder IPC ile ilgili servise taşınır. Servis çağıran process’in UID’sini, permission’larını ve policy durumunu değerlendirir; ardından isteği kabul eder veya reddeder.
Bu nedenle Android exploit analizinde yalnız uygulama koduna değil; Binder transaction’a, service giriş noktasına, parcel verisine, çağıran kimliğe ve Binder kernel driver’a kadar uzanan zincire bakılır.
Untrusted app process’indeki bir crash ile system_server veya ayrıcalıklı native daemon içindeki bir memory corruption aynı güvenlik etkisine sahip değildir.

Zygote, Android uygulama process’lerinin doğduğu merkezi runtime process’i olarak ele alınır.
Genel akış şöyledir:
init → Zygote → fork → process specialization → UID/GID → SELinux domain → ART → uygulama kodu
Bir app process’i doğarken UID, GID, supplementary group, resource limit, mount namespace ve SELinux context gibi sınırlar uygulanır. Bu nedenle process specialization öncesi ve sonrası aynı güvenlik bağlamı değildir.
Zygisk, çalışan uygulamaya sonradan bağlanan sıradan bir library injection modeli olarak anlatılmaz. Zygote fork hattına yerleşerek child process’in specialization öncesi ve sonrası aşamalarında kod çalıştırabilen bir lifecycle modeli olarak incelenir.
Magisk tarafında boot image veya init_boot değişikliği, erken init, systemless yapı, mount namespace, daemon, hedefli SELinux policy değişiklikleri, DenyList ve integrity kontrollerinin sınırları ele alınır.

Android boot süreci; boot ROM, bootloader, vbmeta, boot veya init_boot, kernel, ramdisk, init, system ve vendor katmanları üzerinden incelenir.
AVB ve dm-verity mekanizmalarının image ve partition bütünlüğünü nasıl doğruladığı; hash tree, imza, public key, rollback index ve boot state kavramlarıyla birlikte ele alınır.
Bootloader kilidinin açılması, custom image yüklenmesi, recovery davranışı, systemless root ve kalıcılık girişimleri güven zinciri açısından değerlendirilir.
Amaç yalnızca “root nasıl yapılır?” sorusu değildir. Root of trust’ın nerede başladığı, hangi katmanın bir sonrakini doğruladığı, değişikliğin nerede tespit edildiği ve sistem değişikliğinin hangi forensic izleri bıraktığı araştırılır.

Statik analiz uygulamanın ne yapabileceğini gösterir; dinamik analiz belirli bir çalışma anında ne yaptığını gösterir.
Frida ile Java ve native fonksiyonların çağrılması, argümanlar, dönüş değerleri, class loading, JNI geçişleri ve runtime veri akışı gözlemlenir. Reflection veya dinamik yükleme nedeniyle statik analizde görünmeyen davranışlar canlı sistemde incelenir.
Dinamik enstrümantasyon yalnızca bir kontrolü geçersiz kılma aracı olarak kullanılmaz. Uygulamanın güvenlik kararını nerede verdiğini, veriyi nerede dönüştürdüğünü ve hangi native veya sistem servisine geçtiğini anlamak için kullanılır.

Malware analizi yalnızca zararlı yazılım türlerinin isimlerini öğrenmekten ibaret değildir.
Dosyanın sisteme nasıl ulaştığı, ilk kod yürütmeyi nasıl elde ettiği, hangi process içinde çalıştığı, privilege sınırlarını nasıl geçtiği, kalıcılığı nerede oluşturduğu, hangi verilere eriştiği ve hangi kanaldan dışarı aktardığı incelenir.
Pegasus gibi vaka analizlerinde zincir şu bölümlere ayrılır:
Teslimat → Exploit → Loader → Yetki geçişi → Ajan → Veri erişimi → İletişim → Forensic iz
Amaç belirli bir spyware ürününü ezberlemek değil; gelişmiş bir exploit zincirinin farklı privilege ve trust katmanlarında nasıl ilerlediğini anlayabilmektir.

Hayır. Ağ ve web güvenliği hâlâ eğitimin önemli parçalarıdır; ancak diğer katmanlardan kopuk biçimde işlenmez.
TCP/IP, ARP, DNS, DHCP, socket, routing, firewall, paket analizi, HTTP, cookie, session, origin ve tarayıcı depolama alanları ele alınır.
XSS örneklerinde yalnız payload değil; kullanıcı girdisinin hangi noktada kod olarak yorumlandığı, session bilgisinin localStorage ile HttpOnly cookie içinde saklanması arasındaki fark ve tarayıcı güven sınırları incelenir.
Bu bölüm, sistem seviyesindeki genel güvenlik modelinin ağ ve uygulama katmanındaki karşılığıdır.

Hayır. Gereken temel Python bilgisi eğitim içinde oluşturulur.
Socket programlama, timeout, hata yönetimi, HTTP istekleri, dosya işlemleri, hash hesaplama, log parsing, IOC çıkarımı, metadata analizi ve yapılandırılmış rapor üretimi ele alınır.
Amaç yalnızca başka araçları çağıran scriptler yazmak değildir. Girdi kontrolü, hata durumu, kaynak yönetimi, timeout, yeniden deneme, false positive ve raporlama davranışı bulunan küçük analiz araçları geliştirilir.

Eğitimde exploit kavramı yalnızca hazır bir PoC’nin çalıştırılması olarak ele alınmaz. Bir güvenlik açığının erişilebilirliği, ürettiği primitive, etkilediği privilege seviyesi, aktif mitigation’lar ve zincirin güvenilirliği birlikte değerlendirilir.
Memory corruption, logic flaw, information leak, controlled read/write, sandbox escape ve privilege escalation gibi kavramların birbirinden farklı aşamalar olduğu açıklanır.
Amaç yetkisiz sistemlere yönelik çalışır saldırı reçeteleri üretmek değil; yayımlanmış exploit ve vulnerability iddialarını teknik olarak okuyabilmek, eksik halkaları belirlemek ve savunma mekanizmalarının zinciri nerede durdurduğunu anlayabilmektir.

Bir CVE kaydının kernel veya yazılım sürümüyle eşleşmesi, sistemin kesin olarak savunmasız olduğunu göstermez.
Dağıtımların backport ettiği yamalar, paket revision’ı, build configuration, işlemci mimarisi, aktif mitigation’lar ve exploit ön koşulları ayrıca incelenir.
İnternetten elde edilen PoC kodu doğrudan çalıştırılmaz. Kaynak kodun yaptığı filesystem ve ağ işlemleri, çağırdığı komutlar, sabit adresleri, mimari bağımlılıkları ve dış payload davranışları statik olarak değerlendirilir.
PoC, güvenilir bir program olarak değil; kontrollü ve izole ortamda incelenmesi gereken araştırma materyali olarak kabul edilir.

Hayır. Eğitim saldırı ve savunmayı birbirinden kopuk disiplinler olarak ele almaz.
Bir debug arayüzü, system call, Binder servisi veya bootloader hatası saldırgan için erişim yüzeyi oluştururken savunmacı için loglanması, sınırlandırılması ve doğrulanması gereken bir sistem davranışıdır.
Exploit mekanizması incelenirken aynı anda mitigation, erişim kontrolü, isolation, monitoring, forensic ve recovery davranışları da değerlendirilir.
Bu yaklaşım; reverse engineering, vulnerability research, malware analizi, incident response, mobil güvenlik, firmware güvenliği ve güvenli sistem tasarımı gibi farklı alanlara ortak bir temel sağlar.

Eğitimin donanım ve firmware bölümlerinde gerçek cihaz davranışları; kart üzerindeki haberleşme, debug, güç, reset ve bellek yüzeyleri üzerinden incelenir.
Logic analyzer ile UART, SPI ve I²C sinyalleri yakalanır; gerektiğinde osiloskopla gerilim, zamanlama, clock, reset ve fiziksel hata davranışları değerlendirilir.
Ölçülen sinyal yalnızca ekranda görülen bir dalga şekli olarak bırakılmaz. Sinyalin hangi firmware işlemi, protokol frame’i, boot aşaması veya hata durumu tarafından üretildiği araştırılır.
Amaç yalnızca cihazdan veri çıkarmak değil; fiziksel ölçümü yazılım, firmware ve güvenlik modeliyle ilişkilendirebilmektir.

Android, Linux kernel üzerine kurulmuş olsa da güvenlik modeli yalnızca klasik Linux izinlerinden oluşmaz.
Android uygulamaları Linux UID, filesystem izinleri, SELinux domain’leri, Binder IPC, PackageManager, uygulama imzası, runtime permission’lar, Zygote process modeli ve Verified Boot gibi birden fazla güvenlik katmanı içinde çalışır.
Linux temeli bilinmeden process, UID, system call, memory map, driver veya kernel privilege sınırları anlaşılamaz. Android katmanları bilinmeden de Binder, system_server, Zygote, Magisk, Zygisk, AVB veya platform exploit zincirleri doğru konumlandırılamaz.
Bu nedenle Linux ve Android iki bağımsız konu değil; aynı sistem mimarisinin farklı katmanları olarak birlikte incelenir.