# md9.net — tüm sayfaların metni
Kaynak: https://www.md9.net · Oluşturma: 2026-09-27
---
# Dijital delil incelemesi, uzman görüşü ve yazılım geliştirme
URL: https://www.md9.net/
Güncelleme: 2026-09-27
md9, dijital kayıtları adli bilişim yöntemleriyle inceleyen, taraflar için uzman görüşü ve bilimsel mütalaa hazırlayan, ayrıca yazılım ve mobil uygulama geliştiren bağımsız bir teknik ofistir. Raporlarımıza bir kaydın gösterdiği kadarını yazarız, fazlasını değil; hukuki değerlendirme avukata ve mahkemeye aittir.
## Adli bilişim: hangi kayıtları inceliyoruz?
Operatörden gelen HTS dökümlerini, IP ve CGNAT eşleşmelerini, sunucu kayıtlarını (log), telefon ve bilgisayar içeriğini, e-postaları, veri tabanlarını ve belgelerin üst verisini (metadata) inceliyoruz. Ham madde çoğu zaman sıradan bir dosyadır: bir erişim kaydı, telefon yedeğindeki mesaj veri tabanı, bir e-postanın `Received:` satırları.
Soru ise hep somuttur. Operatörün bildirdiği IP–abone eşleşmesi port ve saat bilgisiyle tutarlı mı? Fotoğraftaki `DateTimeOriginal` değeri dosyanın diğer izleriyle uyuşuyor mu? "IBAN'ımız değişti" e-postası gerçekten tedarikçinin sunucusundan mı çıktı? Bazen cevap kayıtta yoktur. O zaman raporda bunu yazarız ve hangi kaydın cevabı verebileceğini söyleriz.
Yalnızca hukuka uygun yoldan elde edilmiş kayıtlarla ya da size ait cihaz ve hesaplarla çalışırız. On üç inceleme alanının tamamı [adli bilişim incelemeleri](https://www.md9.net/adli-bilisim/) sayfasında.
[Adli BilişimHTS Kayıt AnaliziArama, SMS, veri oturumu ve IMEI satırlarının kronolojik ve ilişkisel analizi; dosyadaki HTS raporlarının teknik kontrolü.](https://www.md9.net/adli-bilisim/hts-analizi/)[Adli BilişimBaz İstasyonu AnaliziCell ID, LAC, TAC ve ECI kodlarının baz listesiyle eşleştirilmesi; kapsama sınırları, harita gösterimi ve HTS ile birlikte değerlendirme.](https://www.md9.net/adli-bilisim/baz-istasyonu-analizi/)[Adli BilişimIP ve CGNAT AnaliziIP–port–zaman eşleştirmesi, CGNAT ve NAT kayıtları, abonelik eşleştirmesi ve IP'den kullanıcıya atfın teknik sınırları.](https://www.md9.net/adli-bilisim/ip-cgnat-analizi/)[Adli BilişimLog AnaliziSunucu, ağ, güvenlik ve bulut loglarının bütünlük kontrolü, saat normalizasyonu, korelasyonu ve olay zaman çizelgesi.](https://www.md9.net/adli-bilisim/log-analizi/)[Adli BilişimMobil Cihaz ve UygulamaTelefon ve uygulama verisi: SQLite veri tabanları ve WAL, bildirim ve önbellek kayıtları, API trafiği, izinler, güvenlik değerlendirmesi.](https://www.md9.net/adli-bilisim/mobil-cihaz-inceleme/)[Adli BilişimE-posta İncelemesiTaklit gönderici, benzer alan adı ve ele geçirilmiş hesap iddialarının başlık, SPF/DKIM/DMARC ve sunucu kayıtlarıyla incelenmesi.](https://www.md9.net/adli-bilisim/e-posta-inceleme/)
## Uzman görüşü, bilimsel mütalaa ve bilirkişi raporları
Uzman görüşü, yargılamanın bir tarafının teknik bir meseleyi kendi seçtiği uzmana inceletip dosyaya sunduğu yazılı değerlendirmedir. Dayanağı hukuk yargılamasında [HMK m.293](https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=6100&MevzuatTur=1&MevzuatTertip=5), ceza yargılamasında [CMK m.67/6](https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=5271&MevzuatTur=1&MevzuatTertip=5) hükmüdür. CMK'daki fıkra, bilimsel mütalaanın "bilirkişi raporu hakkında" da alınabileceğini açıkça yazar.
Bilirkişiyi ise mahkeme ya da savcılık görevlendirir. Bir taraf bilirkişi tutamaz, yalnızca bilirkişi incelemesi yapılmasını talep edebilir (HMK m.266, CMK m.63). Biz bilirkişi değiliz; dosyadaki bir bilirkişi raporunu tarafın uzmanı olarak okuruz. İlk baktığımız yerler genellikle şunlardır:
- İncelenen kopyanın özet değeri (hash) kaydedilmiş mi?
- Saat dilimi. Telefon imajındaki kayıtlar çoğunlukla UTC ile, operatör kayıtları çoğunlukla Türkiye saatiyle gelir; ikisini karşılaştıran bir rapor hangi dönüşümü yaptığını yazmak zorundadır.
- Baz istasyonu kaydı konum kanıtı gibi mi okunmuş?
- Hattın abonesi, telefonu kullanan kişiyle aynı kişi sayılmış mı?
Uzman görüşü mahkemeyi bağlamaz; mahkeme onu bilirkişi raporu ve dosyadaki diğer delillerle birlikte değerlendirir. İki belgenin farkı ayrı bir yazıda: [uzman görüşü ile bilirkişi raporu arasındaki fark](https://www.md9.net/bilgi/uzman-gorusu-bilirkisi-farki/).
[Uzman GörüşüTaraflar için HMK m.293 uzman görüşü, CMK m.67/6 bilimsel mütalaa, bilirkişi raporlarının teknik değerlendirmesi ve teknik rapor.](https://www.md9.net/uzman-gorusu/)[Uzman GörüşüBilimsel MütalaaCeza dosyalarında CMK m.67/6 bilimsel mütalaa: dijital delile ilişkin teknik iddiaların veri ve literatürle, kaynaklı incelenmesi.](https://www.md9.net/uzman-gorusu/bilimsel-mutalaa/)[Uzman GörüşüBilirkişi Raporu DeğerlendirmesiBilirkişi raporundaki teknik tespitlerin veri, yöntem ve hesap yönünden kontrolü; itiraza esas teknik not ve uzman görüşü.](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/)[Uzman GörüşüTeknik Rapor ve MütalaaOlay kronolojisi, çoklu delil korelasyonu, standart ve şartname incelemesi; dava, şirket içi soruşturma, sigorta ve ihale için teknik rapor.](https://www.md9.net/uzman-gorusu/teknik-rapor/)
## Kimlerle çalışıyoruz?
Bize yazanların çoğu dört gruptan birindedir. Tablodaki sorular tipik örneklerdir, gerçek dosyalardan alınmamıştır.
| Kim | Tipik teknik soru | Başlangıç noktası | [](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/)
| Avukatlar ve hukuk büroları | Bilirkişi raporu, HTS'deki baz kaydına bakıp "sanığın telefonu olay yerindeydi" demiş. Kayıt bunu gerçekten gösteriyor mu, hücrenin kapsama alanı ne kadar? | Bilirkişi raporunun teknik değerlendirmesi | [](https://www.md9.net/adli-bilisim/e-posta-inceleme/)
| Şirketler | Tedarikçiden geldiği görünen ödeme talimatı hangi sunucudan çıktı? İşten ayrılan bir çalışan müşteri listesini dışarı aktardı mı? | E-posta incelemesi; log ve siber olay incelemesi | [](https://www.md9.net/bilgi/dijital-delil-nasil-korunur/)
| Bireyler | WhatsApp yazışmaları, sahte ya da ele geçirilmiş bir hesap. Ekran görüntüsü yeter mi, delil nasıl korunur? | Dijital delil nasıl korunur? | [](https://www.md9.net/adli-bilisim/yazilim-kaynak-kod-inceleme/)
| Yazılım projesi tarafları | Teslim edilen yazılım sözleşmedeki işlevleri karşılıyor mu, kaynak kod eksiksiz teslim edildi mi? Ya da daha başta: yeni bir proje için ölçülebilir kabul kriterleri. | Yazılım ve kaynak kod incelemesi; şartname desteği |
## Bir inceleme nasıl başlar ve ilerler?
Dört adımda: ilk e-posta, ön değerlendirme, inceleme ve rapor.
1. **İlk e-posta.** [destek@md9.net](mailto:destek@md9.net) adresine dosyanın türünü (ceza, hukuk, iş, şirket içi), cevaplanmasını istediğiniz teknik soruyu, elinizdeki materyalin türünü ve yaklaşık hacmini, varsa süreyi yazın. Orijinal delili ve kişisel verileri bu mesaja eklemeyin.
2. **Ön değerlendirme.** Materyalin soruya cevap vermeye yetip yetmediğini söyleriz. Örnek: CGNAT arkasındaki bir bağlantıda kaynak port, hedef IP ve saniye düzeyinde zaman bilgisi yoksa, aynı IP adresini paylaşan aboneler arasından birine inmek çoğu zaman mümkün olmaz. Böyle bir durumda eksik kaydın ne olduğunu ve neden gerektiğini yazarız. Çıkar çatışması kontrolünden sonra kapsam, süre ve ücret yazılı olarak netleşir.
3. **İnceleme.** Materyal güvenli bir yolla gelir, teslimde özet değeri (ör. SHA-256) hesaplanıp kaydedilir ve çalışma doğrulanmış bir kopya üzerinde yapılır. Kullanılan araç, sürümü ve her işlem adımı not edilir.
4. **Rapor.** Kapsam, materyal, yöntem, bulgular, sınırlılıklar ve sonuç bölümlerinden oluşur. Raporu dosyaya siz ya da avukatınız sunar. Mahkeme, raporu hazırlayan uzmanın duruşmada dinlenmesine karar verebilir (HMK m.293/2; ceza yargılamasında istem üzerine, CMK m.68/3).
Delil teslimi, saklama, iade ve imha kuralları [çalışma ilkelerimizde](https://www.md9.net/calisma-ilkeleri/) adım adım yazılı.
## Neden md9?
Çünkü raporlarımızı dört kurala göre yazarız ve her birinin tutulup tutulmadığını raporun kendisinden denetleyebilirsiniz.
**Yöntem**
: Her bulgunun hangi dosyadan, hangi araçla ve hangi adımla çıktığı yazılır. Aynı materyali alan başka bir uzman aynı yoldan aynı sonuca ulaşabilmelidir.
**Bağımsızlık**
: Bulguyu veri belirler, işi veren taraf değil. Kayıtlar beklediğiniz şeyi göstermiyorsa bunu rapordan önce söyleriz.
**Gizlilik**
: Materyal yalnızca o iş için kullanılır; iş bitince baştan kararlaştırıldığı gibi iade edilir ya da silinir.
**Sınırlılık**
: "Bu kayıt şunu gösteremez" raporlarımızda ayrı bir bölümdür. Bizce bir raporun en çok işe yarayan kısmı da çoğu zaman burasıdır. Baz istasyonu kaydı telefonun hangi hücreye bağlandığını gösterir, kişinin belirli bir adreste bulunduğunu tek başına göstermez. Yargıtay'ın da baz sinyalini tek başına yeterli görmediği kararları var (ör. 2. Ceza Dairesi, E.2019/14274, K.2020/2085).
Yapmadığımız işler
Hukuk bürosu değiliz; hukuki danışmanlık, dilekçe yazımı ve dava takibi yapmayız. Bilirkişi değiliz ve bir dosyada görevlendirilmiş bilirkişiyle temas kurmayız. Başkasına ait bir telefona, hesaba ya da sisteme izinsiz erişme taleplerini, şifre kırma da dahil, kabul etmeyiz. Bir davanın sonucu hakkında söz vermeyiz.
## Yazılım, web ve mobil uygulama geliştirme
Özel iş yazılımı, iOS ve Android uygulamaları, API ve entegrasyon, kurumsal web sitesi, teknik SEO ve yapay zekâ aramalarında görünürlük (GEO) üzerinde çalışıyoruz. Yazılım uyuşmazlıklarını inceleyen taraf olduğumuz için kodu sonradan okunabilecek biçimde kurarız: kimin neyi ne zaman değiştirdiğini tutan denetim kaydı (audit log), UTC olarak saklanan zaman damgaları, geçmişi belli bir kod deposu ve teslimden önce yazılmış kabul kriterleri. Bir uyuşmazlıkta teknik incelemeyi en çok zorlayan şey bu kayıtların yokluğudur. Ayrıntılar [yazılım geliştirme bölümünde](https://www.md9.net/yazilim/).
[Yazılım GeliştirmeÖzel Yazılım ve Web UygulamasıYönetim paneli, CRM, e-ticaret, SaaS ve iş süreci otomasyonu: denetim kaydı ve kabul kriterleriyle geliştirilen web uygulamaları.](https://www.md9.net/yazilim/ozel-yazilim-gelistirme/)[Yazılım GeliştirmeMobil Uygulama GeliştirmeiPhone ve Android uygulamaları: platform seçimi, App Store ve Google Play yayını, abonelik ve reklam, cihazda işleyen gizlilik mimarisi.](https://www.md9.net/yazilim/mobil-uygulama-gelistirme/)[Yazılım GeliştirmeBackend, API ve EntegrasyonREST API tasarımı, ödeme ve ERP gibi dış sistem entegrasyonları, veri tabanı ve sistem mimarisi; mikroservis gerekmiyorsa bunu da söyleriz.](https://www.md9.net/yazilim/backend-api-entegrasyon/)[Yazılım GeliştirmeKurumsal Web SitesiStatik HTML, anlamsal işaretleme ve Core Web Vitals hedefleriyle geliştirilen, hızı ölçülerek teslim edilen kurumsal siteler.](https://www.md9.net/yazilim/web-sitesi-gelistirme/)[Yazılım GeliştirmeTeknik SEOTarama ve dizin sorunları, canonical ve site haritası, Schema.org, Search Console kurulumu, KVKK'ya uygun analiz ve dönüşüm takibi.](https://www.md9.net/yazilim/teknik-seo/)[Yazılım GeliştirmeGEO: Yapay Zekâ AramalarıChatGPT, Google AI Overviews, Perplexity ve Claude cevaplarında kaynak gösterilmek için erişim, içerik mimarisi, varlık netliği ve ölçüm.](https://www.md9.net/yazilim/geo/)
## Ürünler: UDF Mobil (md9)
UDF Mobil (md9), UYAP evrakının `.udf` dosyalarını bilgisayara gerek kalmadan iPhone'da açan uygulamamızdır; belgeyi düzenler, PDF'e ve Word'e çevirir. Belgeler cihazda işlenir, sunucuya gönderilmez. Uygulama T.C. Adalet Bakanlığı veya UYAP ile bağlantılı değildir. İmza özelliği belgeye görsel bir imza ekler, güvenli elektronik imza yerine geçmez.
Android sürümü yok; Android telefonda ve bilgisayarda UDF belgesini okumak için tarayıcıda çalışan UDF görüntüleyicimiz var. Uygulamanın neyi yapıp neyi yapmadığı [ürünler bölümünde](https://www.md9.net/urunler/) ayrıntılı.
[ÜrünlerUDF MobilUYAP UDF belgelerini iPhone'da açan, düzenleyen, PDF ve Word'e çeviren uygulama.](https://www.md9.net/udfmobil/tr/)[UDF RehberiUYAP UDF belgelerini hangi cihazda nasıl açacağınız, PDF ve Word'e çevirme, e-imza ve açılmayan dosyalar için rehberler.](https://www.md9.net/udf/)[UDF RehberiUDF Nasıl Açılır?UDF dosyasını Windows, Mac ve Pardus'ta resmî editörle ya da program kurmadan tarayıcıda açmanın adımları ve dikkat edilecekler.](https://www.md9.net/udf/udf-dosyasi-nasil-acilir/)[UDF RehberiUDF'yi PDF'e ÇevirmeResmî editörde Farklı Kaydet ve toplu çevirme, tarayıcıda yüklemeden PDF, telefonda seçenekler; PDF kopyası e-imzayı taşımaz.](https://www.md9.net/udf/udf-pdf-cevirme/)
## Bilgi merkezi: kaynaklı teknik yazılar
Bilgi merkezindeki yazılar, dosyalarda sık çıkan teknik soruları (IP adresi kişiyi gösterir mi, ekran görüntüsü delil olur mu, HTS kaydında ne yazar) kanun maddesine, Yargıtay kararına ya da RFC gibi birincil kaynağa bağlayarak anlatır. Her yazıda kaynak listesi ve son güncelleme tarihi var. Başlamak için altı yazı:
[Bilgi MerkeziHTS Kaydı Nedir?HTS dökümünün alanları, satır satır okunuşu, CMK m.135/6'ya göre elde edilişi ve kaydın cevap veremediği sorular.](https://www.md9.net/bilgi/hts-kaydi-nedir/)[Bilgi MerkeziCGNAT Nedir?Operatörün bir genel IP'yi port aralıklarıyla abonelere paylaştırması; kayıtlarda hangi alanlar olur, tespit neden port ve saniye ister.](https://www.md9.net/bilgi/cgnat-nedir/)[Bilgi MerkeziIP Adresi Delil mi?IP adresi aboneliği gösterir, kullanıcıyı değil. Atfı zayıflatan durumlar, Yargıtay kararları ve iki taraf için teknik kontrol listesi.](https://www.md9.net/bilgi/ip-adresi-delil-mi/)[Bilgi MerkeziEkran Görüntüsü Delil mi?Ekran görüntüsünün teknik zayıflıkları, sahteliğin neden görüntüden anlaşılamadığı, daha güçlü alternatifler ve pratik kontrol listesi.](https://www.md9.net/bilgi/ekran-goruntusu-delil/)[Bilgi MerkeziWhatsApp YazışmalarıWhatsApp verisinin telefonda ve yedekte nerede durduğu, dışa aktarmanın eksikleri, silinen mesajların gerçekçi sınırları ve cihaz incelemesi.](https://www.md9.net/bilgi/whatsapp-yazismalari-delil/)[Bilgi MerkeziE-posta Başlığı Nasıl Okunur?Gmail, Outlook, Apple Mail ve Yandex'te ham başlığı bulma; güvenilecek satırlar, SPF/DKIM/DMARC sonuçları ve sahte gönderici işaretleri.](https://www.md9.net/bilgi/e-posta-header-nasil-okunur/)
Diğer yazılar, terimler sözlüğü ve mevzuat listesi [bilgi merkezinde](https://www.md9.net/bilgi/).
## Tarayıcıda çalışan ücretsiz araçlar
Bu araçlar dosyanızı hiçbir yere yüklemez; hesaplama tarayıcınızda yapılır. Bir dosyanın SHA-256 değerini almak, e-posta başlığındaki `Received:` satırlarını sıraya dizmek, bir kayıttaki Unix zaman damgasını okunur tarihe çevirmek ya da bir IP adresinin CGNAT için ayrılmış paylaşımlı adres alanında (100.64.0.0/10) olup olmadığını görmek için kullanabilirsiniz. Bir aracın çıktısı delilin yerine geçmez; incelemenin başladığı yerdir.
[AraçlarHash HesaplamaDosya ve metin için MD5, SHA-1, SHA-256, SHA-384 ve SHA-512; beklenen değerle ve iki dosya arasında karşılaştırma.](https://www.md9.net/araclar/hash-hesaplama/)[AraçlarE-posta Başlık AnaliziBaşlığı yapıştırın: Received zinciri, gecikmeler, SPF/DKIM/DMARC sonuçları ve alan adı hizalaması. Tarayıcıda çalışır, veri gönderilmez.](https://www.md9.net/araclar/e-posta-baslik-analizi/)[AraçlarZaman Damgası DönüştürücüUnix, FILETIME, Chrome, Apple, GPS ve Excel değerlerini UTC ve o tarihte geçerli Türkiye saatine çevirir; toplu dönüştürme yapar.](https://www.md9.net/araclar/zaman-damgasi-donusturucu/)[AraçlarIP Adresi KontrolIPv4/IPv6 adresinin türünü IANA kayıtlarına göre gösterir; kayıt metninden adresleri ve portları ayıklar, CSV verir. Sorgu yapmaz.](https://www.md9.net/araclar/ip-adresi-kontrol/)[AraçlarEXIF GörüntüleyiciFotoğrafın çekim zamanını, saat dilimini, cihazını ve GPS konumunu tarayıcıda okur; XMP geçmişini gösterir. Dosya yüklenmez.](https://www.md9.net/araclar/exif-goruntuleyici/)[AraçlarUDF GörüntüleyiciUYAP .udf belgesini yüklemeden tarayıcıda açın; yazdırın, PDF olarak kaydedin, metnini kopyalayın.](https://www.md9.net/araclar/udf-goruntuleyici/)
## Sık sorulan sorular
### Adli bilişim uzmanı ne iş yapar?
Adli bilişim uzmanı; telefon, bilgisayar, sunucu kaydı, HTS dökümü ya da e-posta gibi dijital materyali bütünlüğünü bozmadan inceleyen ve bulgularını yöntemiyle birlikte rapora döken kişidir. İşin zor kısmı sınırı doğru çizmektir: IP adresi internet bağlantısını gösterir, bilgisayarın başındaki kişiyi göstermez; baz kaydı telefonun bağlandığı hücreyi gösterir, adresi göstermez. Bulgunun hukuki nitelendirmesi uzmanın değil, mahkemenin işidir.
### Özel olarak bilirkişi raporu alınabilir mi?
Hayır. Bilirkişiyi mahkeme ya da savcılık görevlendirir (HMK m.266, CMK m.63); taraflar yalnızca bilirkişi incelemesi yapılmasını talep edebilir. Uygulamada "özel bilirkişi raporu" denen belgenin kanundaki adı uzman görüşü ya da bilimsel mütalaadır: taraf, kendi seçtiği uzmandan bu görüşü alıp dosyaya sunabilir (HMK m.293, CMK m.67/6). md9 bu yolda çalışır ve taraflar için [uzman görüşü](https://www.md9.net/uzman-gorusu/) hazırlar.
### Adli bilişimde uzman görüşü mahkemede ne işe yarar?
Uzman görüşü mahkemeyi bağlamaz. Yargıtay 9. Hukuk Dairesi onu teknik anlamda delil değil, tarafın yazılı belgeye bağlı beyanı saymıştır (E.2022/2237, K.2022/3385). Buna karşılık 15. Hukuk Dairesi, dava konusuyla ilgili uzman görüşünün mutlaka değerlendirilmesi, bilirkişi raporuyla ciddi biçimde çelişiyorsa dosyanın yeni bir bilirkişi heyetine verilmesi gerektiğini belirtmiştir (E.2015/5127, K.2016/4635). Görüşün ağırlığını, gerekçesinin ne kadar denetlenebilir olduğu belirler.
### Delilleri ilk e-postada göndermeli miyim?
Hayır. İlk mesajda dosyanın türünü, teknik soruyu, materyalin türünü ve yaklaşık hacmini (ör. iki telefon ve bir aylık sunucu kaydı), varsa süreyi yazmanız yeterli. Orijinal delil, kimlik bilgileri ve yazışma içerikleri e-postaya eklenmemeli: ek, bütünlük kaydı tutulmadan sunucular arasında kopyalanır ve kişisel veriyi gereksiz yere çoğaltır. Güvenli aktarım ön değerlendirmeden sonra planlanır. Ayrıntılar [iletişim sayfasında](https://www.md9.net/iletisim/).
### Bir inceleme ne kadar sürer, ücret nasıl belirlenir?
İkisi de materyalin hacmine ve sorunun kapsamına bağlıdır. Tek bir e-postanın başlık incelemesi ile birkaç cihazın ve aylarca süren HTS kayıtlarının karşılaştırılması aynı iş değildir. Ön değerlendirmeden sonra kapsamı, süreyi ve ücreti yazılı olarak bildiririz; ücret raporun sonucuna bağlı değildir. Mahkemenin verdiği bir süre ya da yaklaşan bir duruşma varsa bunu ilk mesajda belirtin, planlama ona göre yapılır.
### UDF Mobil Android'de var mı?
Hayır. UDF Mobil (md9) yalnızca iPhone'da çalışır (iOS 15.5 veya üzeri); Android sürümü yok. Android telefonda ya da bilgisayarda bir UDF belgesini okumak için [tarayıcıda çalışan UDF görüntüleyiciyi](https://www.md9.net/araclar/udf-goruntuleyici/) kullanabilirsiniz; dosya sunucuya yüklenmez. UYAP'a gönderilecek belgeyi hazırlamanın ve e-imzalamanın resmî yolu ise Adalet Bakanlığı'nın UYAP Doküman Editörü'dür.
---
# md9 hakkında
URL: https://www.md9.net/hakkimizda/
Güncelleme: 2026-09-27
md9, dijital kayıtları adli bilişim yöntemleriyle inceleyen, dava taraflarına ve avukatlarına uzman görüşü ve bilimsel mütalaa hazırlayan, ayrıca yazılım ve mobil uygulama geliştiren bağımsız bir teknik ofistir. Hukuk bürosu değiliz; bir mahkemenin, kolluk biriminin ya da kamu kurumunun parçası da değiliz.
## md9 nedir?
md9, dijital kayıtları inceleyen ve yazılım geliştiren bağımsız bir teknik ofistir. İşin bir ucunda bir HTS dökümünün, sunucu kaydının ya da telefon imajının teknik incelemesi durur. Öbür ucunda bu incelemenin dava dosyasına girecek biçimi vardır: uzman görüşü, bilimsel mütalaa ya da teknik rapor. Bunların yanında yazılım ve mobil uygulama geliştiririz.
Hepsini birbirine bağlayan şey araştırmadır. Bir incelemede okuduğumuz kanun maddesini, RFC'yi ya da üretici dokümanını bilgi merkezinde kaynağıyla yayımlarız; sık ihtiyaç duyulan kontrolleri de dosyanızı hiçbir yere yüklemeden çalışan tarayıcı araçlarına dönüştürürüz. Yazılarda hangi kaynağa öncelik verdiğimizi ve bir hatayı nasıl düzelttiğimizi [editoryal ilkelerde](https://www.md9.net/bilgi/editoryal-ilkeler/) anlattık.
Bağımsız derken somut bir şeyi kastediyoruz: bir kolluk birimine, laboratuvara, hukuk bürosuna ya da yazılım satıcısına bağlı değiliz. İşi bize teknik görüş isteyen taraf ya da avukatı verir, bulguyu ise incelenen veri belirler. Bu ikisini nasıl ayrı tuttuğumuzu, ücretin raporun sonucuna bağlı olmamasından taslakta neyin düzeltilebileceğine kadar, [çalışma ilkelerimizde](https://www.md9.net/calisma-ilkeleri/) yazdık.
## Neden hem inceleme hem yazılım?
Çünkü incelediğimiz kayıtların neredeyse hepsini bir yazılım üretir. Bir log satırı da, bir veri tabanı alanı da birinin verdiği tasarım kararının sonucudur. Aynı kararları kendi projelerinde veren biri, kayıtta ne yazdığını olduğu kadar ne yazmadığını da fark eder. Üç örnek:
- Bir tablodaki `created_at` değerinin sunucu saatiyle mi, kullanıcının telefonundaki saatle mi yazıldığı kayda bakarak anlaşılmaz. Bunu uygulamanın kodu ya da API tanımı söyler. Fark küçük değildir, çünkü telefon saati elle değiştirilebilir.
- Arayüzde "silindi" görünen kayıt, birçok uygulamada veri tabanında durmaya devam eder; yalnızca `deleted_at` gibi bir alan doldurulup listeden gizlenmiştir (soft delete).
- Analitik servisine giden olay, cihazdaki veri tabanında hiç iz bırakmamış olabilir.
### Gerçek bir örnek: UDF Mobil
[UDF Mobil (md9)](https://www.md9.net/udfmobil/tr/), UYAP'ın kullandığı .udf belgelerini iPhone'da açan, düzenleyen, PDF ve Word'e çeviren uygulamamızdır. Biçimin yayımlanmış bir tanımına ulaşamadığımız için dosyanın iç yapısını çözmek gerekti. Bir UDF dosyası aslında bir ZIP arşividir. İçindeki `content.xml`, belgenin bütün düz metnini tek bir blokta tutar; kalın yazı, paragraf hizası ya da tablo gibi biçim bilgisi ise bu metnin karakter aralıklarını `startOffset` ve `length` değerleriyle işaret eden ayrı öğelerde durur. Sitedeki [tarayıcıda çalışan UDF görüntüleyici](https://www.md9.net/araclar/udf-goruntuleyici/) de aynı ayrıştırma kurallarını kullanır.
Uygulamayı yazarken her veri için aynı soruyu sorduk: bu veri cihazda mı kalıyor, bir sunucuya mı gidiyor? Belgeler yalnızca cihazda işleniyor. Kullanım istatistikleri, çökme raporları ve reklam verileri Google'ın servislerine, abonelik durumu RevenueCat'e ve Apple'a gidiyor; istatistik ve çökme verileri uygulama ayarlarından kapatılabiliyor. Ayrıntısı uygulamanın [gizlilik politikasında](https://www.md9.net/udfmobil/tr/privacy.html). Bir mobil uygulamayı incelerken sorduğumuz soru da budur: veri nerede üretildi, nerede tutuldu, kimin sistemine gitti?
Sınırlarını da aynı açıklıkla yazıyoruz. Açık kaynak ayrıştırıcıların belgelediği yapıya göre, e-imzalı bir UDF'de `content.xml` dosyasının yanında imzayı taşıyan `sign.sgn` dosyası bulunur. UDF Mobil bu dosyayı okumaz. İmzalı bir belgeyi düzenleyip kaydettiğinizde imza korunmaz, uygulama e-imzayı doğrulamaz da. Uygulamadaki imza özelliği belgeye görsel bir imza ekler; güvenli elektronik imzanın yerini tutmaz. UDF Mobil yalnızca iPhone'da çalışır ve T.C. Adalet Bakanlığı veya UYAP ile bağlantılı değildir.
### Ters yönde: incelemeler yazılıma ne öğretiyor?
Uyuşmazlığa dönüşmüş bir yazılım projesinde teknik incelemeyi en çok zorlayan şey, olması gereken kaydın hiç tutulmamış olmasıdır. Kimin neyi ne zaman değiştirdiğini gösteren bir denetim kaydı (audit log) yoktur. Zaman damgaları saat dilimi belirtilmeden yazılmıştır. Kabul kriterleri hiç kâğıda dökülmemiştir. Kendi geliştirdiğimiz yazılımda bu üçünü işin başında kurarız, çünkü sonradan eklenen bir denetim kaydı geçmişi geri getirmez.
## Çalışma alanlarımız
Türkiye genelinde çalışıyoruz. İncelemelerin çoğu, materyal güvenli bir yolla aktarıldıktan sonra uzaktan yapılır; bir sisteme yerinde bakmak gerekiyorsa bu ayrıca planlanır.
| Alan | Kapsam | [](https://www.md9.net/adli-bilisim/)
| Adli bilişim ve dijital delil incelemesi | HTS ve baz istasyonu kayıtları, log kayıtları, IP ve CGNAT kayıtları, bilgisayar ve telefon, e-posta, web sitesi, veri tabanı, kaynak kod, dosya üst verisi (metadata) | [](https://www.md9.net/uzman-gorusu/)
| Uzman görüşü ve bilimsel mütalaa | Hukuk yargılamasında HMK m.293, ceza yargılamasında CMK m.67/6 kapsamında taraflar için teknik görüş; dosyadaki bilirkişi raporlarının teknik değerlendirmesi | [](https://www.md9.net/yazilim/)
| Yazılım, web ve mobil | Özel iş yazılımı, iOS ve Android uygulamaları, API ve entegrasyon, kurumsal web sitesi, teknik SEO ve yapay zekâ aramalarında görünürlük (GEO), şartname desteği | [](https://www.md9.net/urunler/)
| Dijital ürünler | UDF Mobil (md9) | [](https://www.md9.net/bilgi/)
| Bilgi merkezi ve araçlar | Kanun maddesine, Yargıtay kararına ya da RFC gibi birincil kaynağa bağlanan teknik yazılar, terimler sözlüğü, mevzuat listesi; hash, zaman damgası, IP adresi, e-posta başlığı, EXIF ve UDF için tarayıcı araçları |
## md9 ne değildir?
**Hukuk bürosu değildir.** Hukuki mütalaa vermek, dava evrakı düzenlemek ve dava takip etmek Avukatlık Kanunu m.35'e göre baroya kayıtlı avukatların işidir. Biz teknik soruya cevap veririz; raporu dosyaya avukatınız sunar.
**Bilirkişi unvanıyla çalışmaz.** Bilirkişiyi mahkeme ya da savcılık görevlendirir (HMK m.266, CMK m.63); bir taraf bilirkişi seçemez, tutamaz. Taraflar için hazırladığımız şeyin kanundaki adı uzman görüşü ya da bilimsel mütalaadır. Kendimizi bilirkişi diye tanıtmayız, bir dosyada görevli bilirkişiyle de temas kurmayız.
**Sonuç vaat etmez.** Uzman görüşü mahkemeyi bağlamaz; Yargıtay 9. Hukuk Dairesi onu tarafın belgeye dayanan beyanı olarak nitelemiştir (E.2022/2237, K.2022/3385). Söz verebileceğimiz tek şey, her bulgunun neye dayandığını göstermektir.
Başkasının telefonuna, hesabına ya da sistemine erişmek, parola kırmak gibi talepleri de kabul etmeyiz. UYAP hesabı, dosya erişimi ya da e-tebligatla ilgili sorunlarda yardımcı olamayız; bu sistemle bir bağlantımız yok.
## Sitede neden kişi adı öne çıkmıyor?
Sitede kurum adıyla yazıyoruz; sayfalarda unvan, yıl ya da sertifika listesi bulamazsınız. Onun yerine her sayfada yöntemi, kaynakları ve sınırları yazıyoruz, çünkü bir iddianın arkasında ne olduğunu okurun kendisinin kontrol edebilmesini istiyoruz. Bizce bir teknik görüşün değeri de imzanın altındaki unvandan çok, gerekçesinin denetlenebilir olmasından gelir. Yasal tanıtıcı bilgiler [künye sayfasında](https://www.md9.net/kunye/) yer alır.
Raporlarda durum farklıdır. Uzman görüşünü hazırlayan kişinin kimliği ve imzası raporda bulunur, çünkü mahkeme, raporu hazırlayan uzmanın duruşmaya çağrılıp dinlenmesine karar verebilir (HMK m.293/2; ceza yargılamasında CMK m.68/3).
## md9'a nasıl ulaşılır?
Bütün talepler için adres aynıdır: [destek@md9.net](mailto:destek@md9.net). Hizmet talepleri, UDF Mobil desteği ve genel sorular aynı kutuya gelir; Türkçe ya da İngilizce yazabilirsiniz. İlk mesajda teknik soruyu ve materyalin türünü yazmanız yeterli. Orijinal delili ve kişisel verileri eklemeyin; neyin yazılıp neyin gönderilmeyeceği [iletişim sayfasında](https://www.md9.net/iletisim/) anlatılıyor.
## Sık sorulan sorular
### md9 kimdir, ne iş yapar?
md9, www.md9.net adresinde çalışan bağımsız bir teknik ofistir. HTS ve baz istasyonu kayıtları, log kayıtları, IP ve CGNAT kayıtları, bilgisayar ve telefon, e-posta, veri tabanı ve kaynak kod gibi dijital kayıtları adli bilişim yöntemleriyle inceler; taraflar ve avukatları için uzman görüşü ve bilimsel mütalaa hazırlar; yazılım ve mobil uygulama geliştirir. İlk ürünü, UYAP UDF belgelerini iPhone'da açan UDF Mobil (md9) uygulamasıdır. İletişim adresi destek@md9.net.
### md9 bir hukuk bürosu mu?
Hayır. md9 teknik inceleme yapar; hukuki danışmanlık, dilekçe hazırlama ve dava takibi yapmaz. Avukatlık Kanunu m.35'e göre hukuki mütalaa vermek ve dava evrakı düzenlemek baroya kayıtlı avukatların işidir. Hukuki stratejiyi belirlemek ve raporu dosyaya sunmak avukatınıza aittir; biz teknik soruya cevap veririz. Raporlarımızda 'suç oluşmuştur' ya da 'kusurludur' gibi hukuki nitelendirmeler yer almaz.
### md9 UYAP veya Adalet Bakanlığı ile bağlantılı mı?
Hayır. md9 ve ürünü UDF Mobil, T.C. Adalet Bakanlığı veya UYAP tarafından geliştirilmemiştir ve bu kurumlarla resmî bir bağlantısı yoktur. UDF Mobil UYAP'a bağlanmaz; yalnızca UYAP'ın kullandığı .udf biçimindeki dosyaları cihazda açar, düzenler ve dönüştürür. UYAP hesabı, dosya erişimi ya da e-tebligatla ilgili sorunlar için UYAP'ın kendi destek kanallarına başvurmak gerekir.
### md9, yazılım geliştirdiği bir şirketin uyuşmazlığında inceleme yapar mı?
Bu soru, işi kabul etmeden önce yaptığımız çıkar çatışması kontrolünün konusudur. Taraflardan biri için yazılım geliştirmişsek ya da incelenecek kaydı bizim yazdığımız bir yazılım üretmişse, bunu ön değerlendirmede açıkça söyleriz. Bağımsızlığımızı gölgeleyecek bir ilişki varsa işi almayız: kendi tasarım kararlarımızı tarafsız biçimde değerlendirdiğimizi iddia etmek inandırıcı olmaz. Kontrolün nasıl yapıldığı [çalışma ilkelerimizde](https://www.md9.net/calisma-ilkeleri/) anlatılıyor.
### md9 hangi şehirlerde çalışıyor?
Türkiye genelinde çalışıyoruz. İncelemelerin çoğu, materyal güvenli bir yolla aktarıldıktan sonra uzaktan yapılır; bir sunucuya ya da sisteme yerinde bakmak gerekiyorsa bu ayrıca planlanır. Bu yüzden bulunduğunuz şehirden çok materyalin türü ve teslim yolu belirleyicidir. İlk temas her durumda e-postayla, destek@md9.net adresinden kurulur; teslim yolunu ön değerlendirmeden sonra birlikte seçeriz.
---
# Adli bilişim inceleme süreci: md9'da bir inceleme nasıl yürür?
URL: https://www.md9.net/calisma-ilkeleri/
Güncelleme: 2026-09-27
md9'da bir adli bilişim incelemesi yedi adımda yürür: ilk e-posta, ön değerlendirme, çıkar çatışması kontrolü, yazılı kapsam, materyal teslimi, inceleme ve rapor. Bu sayfa her adımda uyduğumuz kuralları yazar; raporlarımızı bu kurallara göre denetleyebilirsiniz.
## Bir inceleme hangi adımlarla yürür?
Her inceleme aynı sırayla ilerler. Adımların hiçbiri atlanmaz; küçük işlerde bazıları birkaç e-postaya sığar.
1. **İlk e-posta.** Dosyanın türünü, cevaplanmasını istediğiniz teknik soruyu, materyalin türünü ve yaklaşık hacmini, varsa süreyi yazarsınız. Orijinal delil ve kişisel veri bu aşamada gönderilmez; neyin yazılacağı [iletişim sayfasında](https://www.md9.net/iletisim/) anlatılıyor.
2. **Ön değerlendirme.** Sorunun teknik olarak cevaplanabilir olup olmadığını ve elinizdeki materyalin buna yetip yetmediğini söyleriz. Yetmiyorsa hangi kaydın eksik olduğunu ve neden gerektiğini yazarız.
3. **Çıkar çatışması kontrolü.** Tarafların adını bu aşamada isteriz. Kontrol bitmeden materyal istemeyiz.
4. **Yazılı kapsam.** Cevaplanacak sorular, materyal listesi, teslim yolu, süre, ücret ve iş bitince materyalin iade mi imha mı edileceği yazılı olarak netleşir.
5. **Materyal teslimi.** Materyal güvenli bir yolla gelir; teslimde özet değeri (hash) hesaplanır ve bir teslim kaydı açılır.
6. **İnceleme.** Çalışma, doğrulanmış bir kopya üzerinde yapılır. Kullanılan araç, sürümü ve her adım not edilir. Kayıt türüne göre değişmeyen teknik sıra (materyal, bütünlük, inceleme, korelasyon, rapor) [adli bilişim incelemeleri](https://www.md9.net/adli-bilisim/) sayfasında adım adım anlatılıyor.
7. **Rapor ve sonrası.** İmzalı rapor ekleriyle birlikte teslim edilir. Ek sorular, gerekirse uzmanın duruşmada dinlenmesi ve materyalin iadesi ya da imhası bu aşamadadır.
## Bağımsızlık: bulguyu kim belirler?
Bulguyu incelenen veri belirler, işi veren taraf değil. Bunu bir iddia olarak bırakmıyoruz, çünkü uzman görüşünün yapısı gereği işi taraflardan biri verir: HMK m.293/1 ve CMK m.67/6, bilimsel mütalaayı tarafların kendi uzmanından alabileceği bir görüş olarak düzenler. Bu yapıda bağımsızlığı koruyan şey açık kurallardır:
- Ücret raporun sonucuna bağlı değildir. "Lehte çıkarsa" ödenen bir prim ya da ek ücret yoktur.
- Kayıtlar beklediğiniz şeyi göstermiyorsa bunu rapordan önce, ön değerlendirmede ya da inceleme sırasında söyleriz. Raporu dosyaya sunup sunmamak sizin ve avukatınızın kararıdır; raporun içeriğini ise bulguyu değiştirecek biçimde düzenlemeyiz.
- Taslakta düzeltilebilecek şey maddi hatadır: yanlış yazılmış bir dosya adı, hatalı aktarılmış bir tarih, eksik yazılmış bir soru.
- Bir kaydın başka açıklamaları varsa raporda yer alır. Aynı IP adresini aynı anda paylaşan başka aboneler, aynı hücreye bağlanabilecek başka bölgeler, elle değiştirilebilen bir cihaz saati, talep eden tarafın aleyhine olsa da yazılır.
Örnek: Bir taraf, karşı tarafın telefonunun belirli bir gece belirli bir mahallede olduğunu göstermek istiyor. HTS'de o saatlere ait satırlar, mahalleyi de kapsayan ama onun çok ötesine uzanan bir hücreye bağlanmış. Raporda "telefon o mahalledeydi" yazmaz. "Telefonun bağlandığı hücrenin kapsama alanı o mahalleyi de içerir; bu kayıt, telefonun mahallede bulunduğunu tek başına göstermez" yazar.
## Çıkar çatışması nasıl kontrol edilir?
Bir işi kabul etmeden önce üç şeye bakarız: aynı uyuşmazlıkta karşı taraf için çalışıp çalışmadığımız, ona bu konuda görüş verip vermediğimiz ve taraflardan biriyle bağımsızlığımızı gölgeleyecek bir ilişkimiz olup olmadığı. Sonuncusu yazılım işlerimizi de kapsar: taraflardan biri için yazılım geliştirmişsek ya da incelenecek kaydı bizim yazdığımız bir yazılım üretmişse, bunu ön değerlendirmede söyleriz.
Kontrol için tarafların (kişi ya da şirket) adını ve dosyanın hangi aşamada olduğunu ön değerlendirmeden sonra isteriz; ilk mesajda bu ayrıntıları sormamamızın nedeni de budur. Karşı taraf bize daha önce yazmış olabilir. O durumda onun dosyasına dair bilgiyi de sizinkine dair bilgiyi de aynı gizlilikle tutmamız gerekir. Bir çatışma varsa işi almayız ve nedenini ayrıntılandırmayız, çünkü kimin bize başvurduğunu söylemek o kişinin gizliliğini ihlal etmek olur.
## Dijital delil nasıl teslim edilir, bütünlüğü nasıl korunur?
Orijinal delil üzerinde çalışmayız: materyali teslim alırken özet değerini (hash) kaydeder, incelemeyi bu değerle doğrulanmış bir kopya üzerinde yaparız. Teslim şu adımlarla yürür:
1. **Teslim yolu birlikte seçilir.** Birkaç belge ya da dışa aktarılmış bir kayıt, parolalı ve şifreli bir arşivle gelebilir; parola, dosyanın gönderildiği kanaldan değil, ayrı bir kanaldan iletilir. Büyük imajlar şifreli bir diskle ya da şifreli bir aktarım bağlantısıyla, fiziksel cihazlar teslim tutanağıyla gelir.
2. **Göndermeden önce özet değeri alınır.** Gönderen taraf her dosyanın SHA-256 değerini hesaplar ve bize yazılı olarak bildirir. Bunu dosyayı hiçbir yere yüklemeden, tarayıcıda çalışan [hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) yapabilirsiniz. Teslim aldığımızda aynı değeri hesaplarız; iki değer aynıysa dosya yolda değişmemiştir.
3. **Teslim kaydı açılır.** Kayıtta materyalin tanımı (dosya adı ve boyutu; cihazsa marka, model, seri numarası ve fiziksel durumu), kimden, ne zaman ve hangi yolla alındığı ve özet değerleri bulunur. Materyal her el değiştirdiğinde aynı kayda işlenir. Delilin elde edilmesinden sunulmasına kadar bütünlüğünün bu şekilde belgelenmesine delil zinciri (chain of custody) denir.
4. **Çalışma kopyası oluşturulur.** Teslim alınan kopya salt okunur biçimde saklanır; inceleme, özet değeri kayıtlı bir çalışma kopyası üzerinde yapılır. Bir diskin ya da cihazın imajı alınacaksa yazma engelleyici (write blocker) kullanılır. NIST SP 800-86'nın tarif ettiği doğrulamada orijinalin özeti edinimden önce, kopyanınki edinimden sonra alınır ve ikisi karşılaştırılır.
5. **Analiz sırasında da iz bırakmamaya dikkat edilir.** Bir dosyayı açmak onu değiştirebilir. WAL kipindeki bir SQLite veri tabanını doğrudan açıp kapatmak buna iyi bir örnektir: son bağlantı kapanırken SQLite bir checkpoint yapar, WAL dosyasındaki işlemleri ana dosyaya aktarır ve `-wal` ile `-shm` dosyalarını siler. Değişmiş ya da silinmiş kayıtların izi tam da o WAL dosyasında olabilir. Bu yüzden veri tabanı `-wal` ve `-shm` dosyalarıyla birlikte kopyalanır, çalışma kopya üzerinde yapılır.
Özet değeri için SHA-256 kullanırız. Tutanakta ya da karşı tarafın raporunda MD5 veya SHA-1 değeri varsa onu da hesaplayıp karşılaştırırız. MD5 ve SHA-1'e karşı çakışma saldırıları bilindiği için güncel tercih SHA-256'dır; bu, eski bir algoritmayla kaydedilmiş değerin kendiliğinden geçersiz olduğu anlamına gelmez. Ayrıntısı: [hash değeri ve delil bütünlüğü](https://www.md9.net/bilgi/dijital-delil-butunlugu-hash/).
Ceza dosyalarında gelen kopya
Ceza dosyalarında incelenecek materyal, el koyma sırasında alınan yedeğin şüpheliye ya da vekiline verilen kopyası olabilir (CMK m.134/3 ve 4). İlk iş, bu kopyanın özet değerini tutanaktaki değerle karşılaştırmaktır. Kanun hash değerinin tutanağa yazılmasını açıkça istemez; ancak Yargıtay 8. Ceza Dairesi, usulünce imaj alınıp hash değerlerinin tespit edilmemiş olmasını beraat gerekçeleri arasında saymıştır (E.2012/21817, K.2013/25428). Tutanakta bir değer yoksa bunu raporda sınırlılık olarak yazarız. CMK m.134, Anayasa Mahkemesi'nin 12.02.2026 tarihli, E.2023/128, K.2026/36 sayılı kararıyla iptal edilmiştir (RG 25.05.2026). İptal 25.02.2027'de yürürlüğe girecektir; yerine gelecek yasal düzenleme takip edilmelidir.
## Materyal nerede, ne kadar süre tutulur?
Materyal şifreli depolama ortamlarında ve yalnızca iş süresince tutulur; iş bitince kararlaştırıldığı gibi iade edilir ya da silinir. O iş dışında kullanılmaz, üçüncü kişilerle paylaşılmaz, erişim işi yürüten kişiyle sınırlıdır. Bir kısmı için dışarıdan destek gerekirse (örneğin fiziksel olarak hasar görmüş bir diskin onarımı), bunu önceden yazılı olarak sorarız.
Materyal çoğu zaman üçüncü kişilere ait kişisel veri, bazen de sağlık bilgisi gibi özel nitelikli kişisel veri içerir (KVKK m.6; hangi hukuki sebeple işlendiği [gizlilik metninde](https://www.md9.net/gizlilik/)). Raporda, sorunun cevabı için gereken kadarını gösteririz. İlgisiz yazışmaları ve fotoğrafları rapora koymaz, gerektiğinde numaraları ve adları maskeleriz.
| Ne | İş bitince | Kayıt |
| Size ait fiziksel cihaz, disk ya da bellek | İade edilir | Teslim tutanağı ve özet değerleri |
| Aktarılan dosyalar, imajlar, çalışma kopyaları | Kararlaştırıldığı gibi iade edilir ya da güvenli biçimde silinir | İmha kaydı |
| Rapor, ekleri, özet değeri listesi, çalışma notları | Olası ek sorular ve duruşmada dinlenme için, kapsamda kararlaştırılan süre boyunca saklanır | Saklama süresi yazılı kapsamda |
İade mi imha mı, işin başında yazılı kapsamda seçilir. Tercih belirtilmemişse iş bitince size sorarız; cevabınız gelmeden imha etmeyiz.
## Yöntem: başka bir uzman aynı sonuca ulaşabilmeli
Bir bulgu, aynı materyali alan başka bir uzmanın aynı adımlarla aynı sonuca ulaşabildiği ölçüde güvenilirdir. Bu yüzden raporda kullanılan yazılımın adını ve sürümünü, uygulanan ayarları (ör. hangi saat diliminin esas alındığını), çalıştırılan sorguyu ya da filtreyi ve her bulgunun kaynağını (dosya yolu, satır numarası, kayıt kimliği) yazarız. İki araç aynı kayıt için farklı sonuç veriyorsa ham veriye inip elle doğrularız ve farkı raporda belirtiriz.
Yöntemimizi dayandırdığımız başlıca belgeler:
| Belge | Konusu | Çalışmamızdaki karşılığı |
| ISO/IEC 27037:2012 | Dijital delilin tanımlanması, toplanması, edinimi ve korunması | Teslim, imaj, özet değeri ve delil zinciri adımları |
| ISO/IEC 27042:2015 | Dijital delilin analizi ve yorumlanması | Analizin tekrarlanabilirliği, yorumun gerekçelendirilmesi |
| NIST SP 800-86 (2006) | Adli tekniklerin olay müdahalesine entegrasyonu; toplama, inceleme, analiz ve raporlama aşamaları | Edinim öncesi ve sonrası özet karşılaştırması, raporlama |
| ACPO Good Practice Guide for Digital Evidence, v5 | Dijital delile uygulanan her işlemin denetim izinin tutulması; bağımsız bir üçüncü tarafın aynı işlemlerle aynı sonuca ulaşabilmesi (3. ilke) | Adım adım tutulan çalışma notu |
Bu belgelere atıf yapmak bir sertifika ya da akreditasyon iddiası değildir; yöntemimizin hangi ilkelere dayandığını gösterir. ISO standartlarının metni ücretli olduğu için raporda dayanılan adımı açıkça yazarız. Okur, standardı satın almadan da ne yapıldığını izleyebilmelidir.
## Rapor hangi bölümlerden oluşur?
Raporlarımız altı bölümden oluşur: kapsam, materyal, yöntem, bulgular, sınırlılıklar ve sonuç. Tablodaki örnek satırlar kurgusaldır ve tek bir örnek soruyu izler.
| Bölüm | İçerik | Örnek satır |
| Kapsam | Cevaplanan teknik sorular (aynen), kapsam dışı bırakılan konular | "Soru 2: 203.0.113.25 adresi 14.03.2026 saat 21:40'ta (UTC+3) hangi aboneye tahsisliydi; bu, mevcut kayıtlardan belirlenebilir mi?" | ````
| Materyal | Her dosyanın adı, boyutu, SHA-256 değeri, kaynağı ve teslim tarihi | "erisim_kayitlari.zip, 412 MB, SHA-256 9f2c…e41a, 21.09.2026'da şifreli arşivle teslim alındı." |
| Yöntem | Araç ve sürümü, ayarlar, adımlar | "Kaynak dosyada saat dilimi belirtilmediğinden, operatör yazısındaki 'yerel saat' ifadesi esas alınarak UTC+3 uygulandı." | ````
| Bulgular | Her bulgu, kaynağıyla (dosya, satır, kayıt kimliği) | "access.log, satır 18.204: 203.0.113.25 adresinden 21:40:07'de /admin/login adresine POST isteği, yanıt kodu 302." |
| Sınırlılıklar | Materyalin gösteremedikleri, varsayımlar, eksik kayıtlar | "Operatör kaydında kaynak port bulunmadığından, aynı IP adresini paylaşan aboneler arasında ayrım yapılamamıştır." |
| Sonuç | Soru soru teknik cevap; hukuki nitelendirme yok | "Soru 2 mevcut kayıtlarla cevaplanamamaktadır. Cevap için gereken ek kayıt: kaynak port ve saniye hassasiyetinde zaman bilgisi." |
Eklerde özet değeri listesi, teslim kaydı ve gerektiğinde ham kayıt çıktıları bulunur. Raporu hazırlayan kişinin kimliği ve imzası raporda yer alır; mahkeme, uzmanın duruşmada dinlenmesine karar verebilir (HMK m.293/2; CMK m.68/3). Rapor şablonunun ayrıntısı [teknik rapor sayfasında](https://www.md9.net/uzman-gorusu/teknik-rapor/).
## Sınırlılıkları neden ayrı bir bölümde yazıyoruz?
Çünkü bir raporun en kolay yanlış okunan yeri, söylemediği şeydir. Sınırlılık, bulgunun değersiz olduğu anlamına gelmez; hangi soruya cevap verdiğini doğru çizer ve çoğu zaman hangi ek kaydın istenmesi gerektiğini de söyler. Sık rastlanan sınırlar:
- **Baz istasyonu kaydı** telefonun bağlandığı hücreyi gösterir, adresi göstermez. Yargıtay da baz sinyalini tek başına yeterli görmediği kararlar vermiştir (2. Ceza Dairesi, E.2019/14274, K.2020/2085). Ayrıntı: [baz istasyonu kaydı konumu ne kadar gösterir?](https://www.md9.net/bilgi/baz-istasyonu-konum-tespiti/)
- **IP adresi** bağlantıyı ve aboneyi gösterir, bilgisayarın başındaki kişiyi göstermez. CGNAT arkasında kaynak port ve saniye hassasiyetli zaman olmadan aboneye bile inilemeyebilir. Yargıtay 17. Ceza Dairesi, suç tarihine ait CGNAT verileri getirtilmeden kurulan mahkûmiyeti bozmuştur (E.2018/5732, K.2019/7785).
- **Ekran görüntüsü** kolayca düzenlenebilir ve kaydın kendisine ait üst veriyi taşımaz. Mümkünse orijinal kayıt ya da platformdan dışa aktarılmış veri istenir.
- **SSD'de silinen dosya**, mekanik diske göre çok daha düşük bir olasılıkla geri getirilebilir. Windows'ta NTFS birimlerinde TRIM, yönetici kapatmadıkça açıktır; diskin kendi çöp toplama işlemi de silinen blokları temizler. Yazma engelleyici bu iç işlemleri durdurmaz. Bu yüzden silinmiş verinin bulunamaması, hiç var olmadığını göstermez.
- **Saat bilgisi** kaynak dosyada çoğu zaman saat dilimi belirtilmeden gelir. Türkiye 2016'dan beri sürekli UTC+3'tür; daha eski kayıtlarda yaz saati uygulaması hesaba katılmalıdır. Ayrıntı: [zaman damgaları ve saat dilimi](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/).
## Ne yapmıyoruz?
Dört şeyi yapmayız: hukuki nitelendirme, sonuç vaadi, hukuka aykırı yoldan veri elde etme ve görevli bilirkişiyle temas.
### Hukuki nitelendirme
Kanun, bilirkişinin hukuki nitelendirme yapmasını yasaklar (6754 sayılı Bilirkişilik Kanunu m.3/2; HMK m.279/4; CMK m.67/3). Taraflar için hazırladığımız görüş bir bilirkişi raporu değildir, ama raporlarımızda aynı kurala uyarız: bulgunun hukuki anlamını değerlendirmek avukatın ve mahkemenin işidir. Aşağıdaki satırlar kurgusal örneklerdir.
| Yazmadığımız | Yerine yazdığımız | ````
| "Belge sahtedir." | "PDF'in bilgi sözlüğündeki ModDate değeri CreationDate'ten 14 gün sonradır; bu, belgenin oluşturulduktan sonra en az bir kez yeniden kaydedildiğiyle tutarlıdır." |
| "Sanık olay yerindeydi." | "Hattın 21:40 ile 22:10 arasındaki üç kaydı, olay adresini de kapsayan hücreye bağlanmıştır; bu, telefonun o adreste olduğunu tek başına göstermez." | ``
| "Çalışan müşteri listesini çalmıştır." | "Kullanıcı hesabının oturumunda, musteriler.xlsx dosyasının harici bir diske kopyalandığıyla tutarlı izler vardır; kopyalamayı hangi kişinin yaptığı kayıtlardan belirlenemez." |
### Sonuç vaadi
İncelemeden önce ne çıkacağını, incelemeden sonra da mahkemenin raporu nasıl değerlendireceğini söyleyemeyiz. Uzman görüşü hâkimi bağlamaz ve diğer delillerle birlikte değerlendirilir; Yargıtay 9. Hukuk Dairesi onu tarafın belgeye dayanan beyanı olarak nitelemiştir (E.2022/2237, K.2022/3385).
### Hukuka aykırı veri elde etme
Başkasının cihazına, hesabına ya da sistemine hukuka aykırı olarak girmek (TCK m.243) ya da oradaki verileri bozmak, yok etmek, değiştirmek (TCK m.244) suçtur. Bu yolla elde edilen veri de delil olarak kullanılamaz (HMK m.189/2; CMK m.206/2-a). Bu tür talepleri kabul etmeyiz. HTS kaydını da biz temin etmeyiz: bu kayıt mahkeme ya da savcılık eliyle alınır (ceza yargılamasında CMK m.135/6). Biz dosyaya girmiş ya da size usulüne uygun verilmiş kaydı inceleriz.
### Görevli bilirkişiyle temas
Bir dosyada görevlendirilmiş bilirkişiyle temas kurmaz, ona bilgi ya da belge iletmeyiz; görülmekte olan bir davada bilirkişiyi hukuka aykırı olarak etkilemeye teşebbüs, TCK m.277'de ayrıca suç olarak düzenlenmiştir. Teknik değerlendirmemiz mahkemeye yalnızca dosyaya sunulan rapor aracılığıyla ulaşır.
## Süre ve ücret nasıl belirlenir?
Süre ve ücret, ön değerlendirmeden sonra materyalin türüne, hacmine ve cevaplanacak soruların kapsamına göre yazılı olarak bildirilir. Materyali görmeden rakam vermeyiz, çünkü aynı adı taşıyan iki iş arasında büyük fark olabilir. Belirleyici etkenler:
| Etken | Süreyi neden etkiler? |
| Materyalin türü | Operatörden gelmiş düzenli bir Excel HTS dökümü ile kilitli bir telefonun imajı aynı iş değildir; edinim, ayrıştırma ve doğrulama ayrı adımlardır. |
| Hacim | Satır sayısı, gigabayt, cihaz ve hesap sayısı. |
| Kaynak sayısı | Tek bir log dosyasına bakmak ile HTS, sunucu kaydı ve e-posta başlıklarını aynı zaman çizelgesine oturtmak farklı işlerdir. Korelasyon çoğu zaman işin en uzun kısmıdır. |
| Sorunun açıklığı | "Her şeye bakın" kapsamı belirsizleştirir. "Bu IP adresi bu saatte hangi aboneye tahsisliydi?" gibi somut bir soru hem süreyi hem ücreti netleştirir. |
| Materyalin durumu | Bozuk ya da eksik dışa aktarılmış dosyalar, saat dilimi yazılmamış kayıtlar, farklı biçimlerde gelen operatör dökümleri ek iş çıkarır. |
| Takvim | Mahkemenin verdiği süre ve duruşma tarihi. HMK m.281'e göre taraflar bilirkişi raporuna karşı taleplerini tebliğden itibaren iki hafta içinde bildirir; talep özel ya da teknik bir çalışma gerektiriyorsa, süresi içinde istenirse bir defaya mahsus en çok iki haftalık ek süre verilebilir. Uzman görüşü almak ise tek başına ek süre isteme gerekçesi değildir (HMK m.293/1; CMK m.67/6). |
Teklif yazılıdır: sorular, ücret ve teslim tarihi aynı belgede yer alır. Kapsam iş sırasında genişlerse, örneğin incelemeye yeni bir cihaz eklenirse, devam etmeden önce yeniden yazılı olarak bildiririz.
## Sık sorulan sorular
### Adli bilişim incelemesi nasıl yapılır?
Önce teknik soru ve materyal e-postayla tarif edilir; ön değerlendirmede sorunun eldeki kayıtlarla cevaplanıp cevaplanamayacağı söylenir. Çıkar çatışması kontrolü ve yazılı kapsamdan sonra materyal güvenli bir yolla teslim alınır ve SHA-256 değeri kaydedilir. İnceleme, değeri doğrulanmış bir kopya üzerinde, kullanılan araç ve sürümü not edilerek yapılır. Rapor kapsam, materyal, yöntem, bulgular, sınırlılıklar ve sonuç bölümleriyle teslim edilir.
### Dijital delili teslim etmeden önce ne yapmalıyım?
Kapalı bir cihazı açmayın, açık olanı sıfırlamayın; dosyaları açıp yeniden kaydetmeyin, yeniden adlandırmayın. Göndereceğiniz her dosyanın SHA-256 değerini hesaplayıp not edin; teslim aldığımızda aynı değeri biz de hesaplarız. Bir cihaz teslim edecekseniz marka, model, seri numarası ve fiziksel durumunu yazın. Olaydan hemen sonra yapılması ve yapılmaması gerekenlerin tam listesi [dijital delil koruma rehberinde](https://www.md9.net/bilgi/dijital-delil-nasil-korunur/).
### İnceleme bittikten sonra materyalim ne oluyor?
Size ait fiziksel cihaz ve diskler iade edilir. Aktarılan dosyalar, imajlar ve çalışma kopyaları, işin başında yazılı olarak kararlaştırıldığı gibi iade edilir ya da güvenli biçimde silinir ve bir imha kaydı düzenlenir. Rapor, ekleri ve çalışma notları ise olası ek sorular ve uzmanın duruşmada dinlenmesi ihtimaline karşı, kapsamda yazan süre boyunca saklanır. Tercih belirtilmemişse iş bitince size sorarız.
### Rapor beklediğim sonucu göstermezse değiştirir misiniz?
Hayır. Taslaktaki maddi hataları, örneğin yanlış yazılmış bir dosya adını ya da hatalı aktarılmış bir tarihi düzeltiriz; bulgunun kendisini değiştirmeyiz. Kayıtlar beklediğiniz şeyi göstermiyorsa bunu rapordan önce söyleriz. Raporu dosyaya sunup sunmamak sizin ve avukatınızın kararıdır. Ücret de raporun sonucuna bağlı değildir; bir uzman görüşünün ağırlığı zaten bu bağımsızlıktan gelir.
### Hangi standartlara göre çalışıyorsunuz, sertifikanız var mı?
Yöntemimizi ISO/IEC 27037:2012 (dijital delilin tanımlanması, toplanması ve korunması), ISO/IEC 27042:2015 (analiz ve yorum) ve NIST SP 800-86 (2006) ilkelerine dayandırırız. Bu bir sertifika ya da akreditasyon iddiası değildir. Güvenceyi yöntemin açık yazılmasında görüyoruz: raporda araç ve sürümü, her adım ve her bulgunun kaynağı yazar; başka bir uzman aynı materyalle aynı yolu izleyip sonucu denetleyebilir.
### Aynı dosyada karşı taraf için de çalışır mısınız?
Hayır. İşi kabul etmeden önce, aynı uyuşmazlıkta karşı tarafa görüş verip vermediğimizi ya da onunla çalışıp çalışmadığımızı kontrol ederiz. Bunun için tarafların adını ön değerlendirmeden sonra isteriz. Bir çatışma varsa işi almayız ve kimin bize başvurduğunu açıklamayız; bu, diğer tarafın gizliliğinin gereğidir. Ön değerlendirme için gönderilen bilgiler de aynı gizlilikle tutulur.
---
# md9 ile iletişim
URL: https://www.md9.net/iletisim/
Güncelleme: 2026-09-27
md9'a e-postayla ulaşılır: destek@md9.net. Hizmet talepleri, UDF Mobil desteği ve genel sorular aynı adrese gelir; Türkçe ya da İngilizce yazabilirsiniz. İlk mesajda teknik soruyu ve materyalin türünü yazmanız yeterli, orijinal delili ve kişisel verileri eklemeyin.
**E-posta**
: [destek@md9.net](mailto:destek@md9.net) (hizmet talepleri, UDF Mobil desteği, genel sorular)
**Yazışma dili**
: Türkçe veya İngilizce
**Hizmet bölgesi**
: Türkiye geneli; incelemeler çoğunlukla uzaktan, gerektiğinde yerinde
**Yasal tanıtıcı bilgiler**
: [Künye](https://www.md9.net/kunye/)
İlk temas e-postayla kurulur. Teknik bir soru yazıya döküldüğünde netleşir; ön değerlendirmeyi de bu yazılı soru üzerinden yaparız.
## İlk e-postada ne yazmalısınız?
Dört bilgi yeter: dosyanın türü, cevaplanmasını istediğiniz teknik soru, materyalin türü ve yaklaşık hacmi, varsa süre. Bunlarla sorunun teknik olarak cevaplanıp cevaplanamayacağını ve elinizdeki materyalin buna yetip yetmediğini söyleyebiliriz. Tablodaki son iki bilgi zorunlu değildir ama işi hızlandırır.
| Bilgi | Ne yazılır? | Neden sorarız? |
| Dosyanın türü ve aşaması | Ceza, hukuk, iş, idari yargı, şirket içi soruşturma, sigorta; soruşturma, kovuşturma ya da istinaf aşaması. Henüz dava yoksa bu da bir bilgidir. | Hangi usulün uygulanacağı raporun biçimini ve takvimi değiştirir. |
| Teknik soru | Tek cümlelik, kayıtla cevaplanabilecek bir soru | Kapsamı ve ücreti soru belirler. |
| Materyalin türü ve hacmi | "Operatörden gelen üç aylık HTS dökümü (Excel) ve 38 sayfalık bilirkişi raporu", "bir sunucunun 30 günlük erişim kaydı, yaklaşık 4 GB", "iki telefon" | Sürenin büyük kısmını materyalin hacmi ve biçimi belirler. |
| Süre | Raporun tebliğ tarihi, mahkemenin verdiği süre, duruşma tarihi. Süre kısıtınız varsa konu satırına da yazın (ör. "Süreli: 06.10.2026"). | Takvimi buna göre kurarız. |
| Materyalin nerede olduğu | Dosyada CD ya da DVD olarak mı, sizde mi, bir şirketin sunucusunda mı, cihaz emanette mi? | Teslim yolunu ve neyin incelenebileceğini belirler. Emanetteki cihazı biz inceleyemeyiz; dosyaya girmiş ya da size usulüne uygun verilmiş kopyasını inceleyebiliriz. |
| Rolünüz | Avukat, şirket yetkilisi, dosyanın tarafı | Raporun kime ve nasıl teslim edileceğini belirler. |
### İyi bir teknik soru nasıl kurulur?
"Bu telefona bir bakın" bir soru değildir. Her şeye bakmak hem süreyi uzatır hem de dosyanın gerçek meselesini gözden kaçırır. Soru, kayıtla cevaplanabilecek biçimde kurulmalıdır:
- Zayıf: "Bilirkişi raporu yanlış mı?" Daha iyi: "Rapor, hattın 21:40'taki kaydının bağlandığı hücreye bakarak telefonun olay adresinde olduğunu söylüyor. Kayıt bunu gösteriyor mu?"
- Zayıf: "Bu e-posta sahte mi?" Daha iyi: "Bu e-posta tedarikçinin alan adına ait sunuculardan mı gönderilmiş, yoksa benzer bir alan adından mı?"
- Zayıf: "Çalışan veri kaçırdı mı?" Daha iyi: "Çalışanın hesabıyla, ayrılmadan önceki iki hafta içinde şirket sunucusundan dosya indirilmiş mi?"
### Örnek: kısa bir ilk e-posta
Aşağıdaki metin kurgusaldır. Kişi adı, telefon numarası ve dosya numarası içermediğine dikkat edin; bunlar ön değerlendirme için gerekmez.
```
Konu: Ön değerlendirme: HTS ve baz kayıtları (Süreli: 06.10.2026)
Dosya türü: Ceza, kovuşturma aşaması
Rolüm: Müdafi
Teknik soru: Bilirkişi raporu, hattın olay gecesi 21:40'taki kaydının
bağlandığı baz istasyonuna bakarak telefonun olay adresinde olduğunu
söylüyor. Kayıtlar bunu gösteriyor mu?
Materyal: Operatörden gelen HTS dökümü (Excel, yaklaşık 12.000 satır),
38 sayfalık bilirkişi raporu. Kayıtlar dosyada CD olarak mevcut.
Süre: Rapor 22.09.2026'da tebliğ edildi; mahkemenin verdiği süre
06.10.2026'da doluyor. Duruşma 20.10.2026.
```
## Neleri göndermemelisiniz?
İlk e-postaya eklemeyin
Orijinal delil, kimlik bilgileri, yazışma içerikleri, fotoğraflar, parola ve PIN kodları.
### Orijinal delil
E-posta eki, bütünlük kaydı tutulmadan kopyalanan bir dosyadır. Gönderen sunucuda, alıcı sunucuda ve cihazlarda kopyası kalır; hangi kopyanın asıl olduğu sonradan tartışılabilir. Bazı e-posta ve mesajlaşma uygulamaları fotoğrafları gönderirken yeniden boyutlandırır ya da üst verisini siler, o dosya artık orijinal değildir. Üstelik e-posta uçtan uca şifreli bir kanal değildir.
### Kişisel veriler
Ön değerlendirme için T.C. kimlik numarası, telefon numarası, adres, yazışma içeriği, sağlık bilgisi ya da fotoğraf gerekmez. Bunlar çoğu zaman sizin değil, üçüncü kişilerin verileridir ve işi alamazsak (ör. çıkar çatışması nedeniyle) elimizde gereksiz yere kalırlar. Tarafların adını, çıkar çatışması kontrolü için ön değerlendirmeden sonra isteriz. Paylaştığınız verilerin nasıl işlendiği [gizlilik ve KVKK aydınlatma metninde](https://www.md9.net/gizlilik/) anlatılıyor.
### Parola ve erişim bilgileri
Cihaz parolasını, e-posta ya da sosyal medya hesabının şifresini, e-imza PIN'ini e-postaya yazmayın. İnceleme için bir cihazın kilidinin açılması gerekiyorsa bunu teslim planında ayrıca konuşuruz.
## Materyali ne zaman ve nasıl göndereceksiniz?
Materyali ön değerlendirme, çıkar çatışması kontrolü ve yazılı kapsamdan sonra, birlikte seçtiğimiz güvenli bir yolla gönderirsiniz. Birkaç belge için bu çoğu zaman parolalı, şifreli bir arşivdir; parola ayrı bir kanaldan gelir. Büyük bir log arşivi ya da imaj şifreli bir diskle, fiziksel cihaz teslim tutanağıyla gelir.
Göndermeden önce her dosyanın SHA-256 değerini hesaplayıp bize yazın; teslim aldığımızda aynı değeri biz de hesaplarız. Bunu dosyayı hiçbir yere yüklemeden [tarayıcıdaki hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) yapabilirsiniz. Bir e-postayı inceletecekseniz ekran görüntüsü değil, orijinal ileti dosyası (`.eml` ya da `.msg`) gerekir; nedeni [e-posta incelemesi sayfasında](https://www.md9.net/adli-bilisim/e-posta-inceleme/). Teslim kaydının neleri içerdiği ve iş bitince materyale ne olduğu [çalışma ilkelerimizde](https://www.md9.net/calisma-ilkeleri/) yazılı.
## UDF Mobil desteği
[UDF Mobil (md9)](https://www.md9.net/udfmobil/tr/) ile ilgili sorular, hata bildirimleri ve öneriler için de aynı adrese yazın: destek@md9.net. Sorunu çabuk çözebilmemiz için şunları ekleyin:
- iPhone modeli ve iOS sürümü (Ayarlar › Genel › Hakkında)
- uygulamanın sürümü
- ne yaptığınız, ne beklediğiniz ve ne olduğu; varsa hata mesajının tam metni
- gerekirse hata ekranının görüntüsü, belgenin içeriği görünmeyecek biçimde
Açılmayan ya da hatalı görünen bir UDF'yi göndermek teşhisi kolaylaştırır, ama belge kişisel veri içeriyorsa göndermeyin. Önce sorunu tarif edin; gerekirse kişisel veri içermeyen bir örnek dosya üzerinden ilerleriz.
UDF Mobil yalnızca iPhone'da çalışır; Android'de ya da bilgisayarda [tarayıcıdaki UDF görüntüleyiciyi](https://www.md9.net/araclar/udf-goruntuleyici/) kullanabilirsiniz. Uygulama T.C. Adalet Bakanlığı veya UYAP ile bağlantılı değildir ve UYAP'a bağlanmaz. UYAP'a giriş, dosya erişimi, e-imza ya da e-tebligatla ilgili sorunlarda yardımcı olamayız.
## Hangi sorulara cevap veremeyiz?
Hukuki sorulara cevap vermeyiz. İtiraz edilip edilmeyeceği, sürenin ne zaman dolduğu ya da raporun dosyaya nasıl sunulacağı avukatınızın alanıdır; yazışmada teknik soruya odaklanırız. Başkasına ait bir telefona, hesaba ya da sisteme erişim, parola kırma veya HTS kaydını bizim temin etmemiz gibi taleplere de olumsuz cevap veririz; nedenleri [çalışma ilkelerinde](https://www.md9.net/calisma-ilkeleri/) yazılı.
Yazışma dili konusunda bir ayrıntı: size yazdığınız dilde, Türkçe ya da İngilizce cevap veririz, ama Türkiye'deki bir yargı dosyasına sunulacak rapor Türkçe hazırlanır.
## Sık sorulan sorular
### md9'a nasıl ulaşabilirim?
E-postayla: destek@md9.net. Hizmet talepleri, UDF Mobil desteği ve genel sorular için ayrı bir adres yoktur; Türkçe ya da İngilizce yazabilirsiniz. İlk mesajda dosyanın türünü, teknik soruyu, materyalin türünü ve yaklaşık hacmini, varsa süreyi yazın. Orijinal delil ve kişisel veri eklemeyin; güvenli aktarım ön değerlendirmeden sonra planlanır. Yasal tanıtıcı bilgiler [künye sayfasında](https://www.md9.net/kunye/) yer alır.
### İlk e-postaya bilirkişi raporunu ekleyebilir miyim?
İlk mesajda raporun konusunu, yaklaşık sayfa sayısını ve itiraz ettiğiniz teknik noktayı yazmanız yeterli. Bilirkişi raporları çoğu zaman tarafların ve üçüncü kişilerin kimlik, telefon ve adres bilgilerini içerir. Ön değerlendirmeden sonra raporu gerekiyorsa güvenli bir yolla isteriz; soruyla ilgisi olmayan kişisel veriler karartılmış olarak da gönderilebilir. Raporun tebliğ tarihini ise ilk mesajda mutlaka belirtin.
### İngilizce yazabilir miyim?
Evet. Yazışma Türkçe ya da İngilizce yürütülebilir ve size yazdığınız dilde cevap veririz. Bu, örneğin yurt dışındaki bir şirketin Türkiye'deki bir uyuşmazlığında işe yarar. Türkiye'deki bir yargı dosyasına sunulacak rapor ise Türkçe hazırlanır. You can write to destek@md9.net in English; we will reply in English.
### UDF Mobil'deki bir hatayı nereye bildiririm?
destek@md9.net adresine. iPhone modelini, iOS sürümünü, uygulamanın sürümünü, ne yaptığınızı ve ne olduğunu yazın; varsa hata mesajının tam metnini ekleyin. Belge kişisel veri içeriyorsa dosyanın kendisini göndermeyin. UDF Mobil UYAP'a bağlanmaz ve UYAP ile bağlantılı değildir; UYAP hesabı, e-imza ya da e-tebligat sorunları için UYAP'ın kendi destek kanallarına başvurmanız gerekir.
### E-postam gizli tutulur mu?
Yazışmalarınızı yalnızca talebinize cevap vermek ve iş kurulursa onu yürütmek için kullanırız; üçüncü kişilerle paylaşmayız. Ancak e-posta uçtan uca şifreli bir kanal değildir: ileti yolda birden çok sunucudan geçer ve buralarda kopyaları kalabilir. Bu yüzden hassas materyali e-postaya eklememenizi isteriz. Verilerin hangi amaçla, hangi hukuki sebeple ve ne kadar süre işlendiği [gizlilik metninde](https://www.md9.net/gizlilik/) anlatılıyor.
---
# Gizlilik politikası ve KVKK aydınlatma metni
URL: https://www.md9.net/gizlilik/
Güncelleme: 2026-09-27
md9.net çerez kullanmaz, analitik ya da reklam aracı çalıştırmaz ve sitedeki araçlara verdiğiniz dosyaları hiçbir sunucuya göndermez. Kişisel veriler iki yolla işlenir: siteyi sunan barındırma ve ağ altyapısının tuttuğu teknik kayıtlar ve bize gönderdiğiniz e-postalar. Bu metin, 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) m.10 ve Aydınlatma Yükümlülüğünün Yerine Getirilmesinde Uyulacak Usul ve Esaslar Hakkında Tebliğ uyarınca bu işlemeyi açıklar.
## Veri sorumlusu kimdir?
**Veri sorumlusu**
: md9 (www.md9.net)
**Başvuru ve iletişim**
: [destek@md9.net](mailto:destek@md9.net)
**Tanıtıcı bilgiler**
: [Künye](https://www.md9.net/kunye/)
Bu metin md9.net'i ziyaret edenleri ve bize e-posta gönderenleri kapsar. UDF Mobil uygulamasının veri işleme kuralları ayrıdır; aşağıda ayrıca anlatılıyor.
## Sitede çerez ya da analitik kullanılıyor mu?
Hayır. md9.net tarayıcınıza çerez (cookie) yerleştirmez; ziyaretçi sayan, sayfa içi davranışı izleyen ya da reklam gösteren bir araç çalıştırmaz. Sayfalar yazı tipi, betik veya görsel için üçüncü taraf sunuculara istek yapmaz, gereken her dosya md9.net alan adından gelir. Sitede üyelik ve giriş yoktur; bize veri gönderen bir form da yoktur. Araç sayfalarındaki alanlar yalnızca tarayıcınızda çalışır.
Bir ayrıntı: siteyi sunan Cloudflare, bir isteği otomatik trafik şüphesiyle doğrulaması gerekirse (ör. bot koruması ya da doğrulama sayfası) `__cf_bm` veya `cf_clearance` gibi kendi güvenlik çerezlerini yerleştirebilir. Cloudflare'in dokümantasyonuna göre bu çerezler ilgili güvenlik özelliğinin çalışması için gereklidir; `__cf_bm` kullanıcıyı siteden siteye ya da oturumdan oturuma izlemez. md9 bu çerezleri okumaz, ölçüm ya da reklam için de kullanmaz.
Bu tespitler, metnin son güncellendiği tarih için geçerlidir. İleride bir çerez ya da ölçüm aracı eklenirse bu metin, araç kullanılmaya başlanmadan önce güncellenir.
## Sitedeki araçlar dosyalarımı bir yere gönderir mi?
Hayır. [Araçlar](https://www.md9.net/araclar/) bölümündeki UDF görüntüleyici, hash hesaplama, zaman damgası dönüştürücü, IP adresi kontrolü, e-posta başlık analizi ve EXIF görüntüleyici, verdiğiniz dosyayı ya da yapıştırdığınız metni tarayıcınızın içinde işler. İçerik md9.net'e ya da başka bir sunucuya gönderilmez ve tarayıcıda kalıcı olarak saklanmaz; sayfayı kapattığınızda işlem de biter.
Tek istisna sizin tıklamanıza bağlıdır. EXIF görüntüleyici, fotoğrafta GPS koordinatı bulursa bir "OpenStreetMap'te aç" bağlantısı gösterir. Bu bağlantıya tıklarsanız koordinatlar bağlantı adresinin içinde OpenStreetMap'e gider ve orada [OpenStreetMap Vakfı'nın gizlilik politikası](https://osmfoundation.org/wiki/Privacy_Policy) geçerli olur. Tıklamazsanız hiçbir istek yapılmaz.
## Barındırma ve ağ altyapısı hangi kayıtları tutar?
md9.net, GitHub Pages üzerinde barındırılır ve Cloudflare'in ağ, önbellek ve güvenlik hizmeti üzerinden sunulur. Bir sayfayı açtığınızda tarayıcınız bu şirketlerin sunucularına bağlanır. Bu sırada IP adresiniz, istenen sayfa, tarih ve saat, tarayıcınızın gönderdiği tarayıcı ve işletim sistemi bilgisi (user-agent) gibi teknik veriler onların sistemlerine ulaşır ve otomatik yolla işlenir. Bir web sayfasının size ulaşabilmesi için bu kaçınılmazdır.
| Hizmet | İşlenen veri | Amaç |
| GitHub Pages (barındırma) | Ziyaretçinin IP adresi. GitHub'ın dokümantasyonuna göre ziyaretçi GitHub'da oturum açmış olsun ya da olmasın, IP adresi güvenlik amacıyla kaydedilir ve saklanır. GitHub'ın genel gizlilik bildirimi, hizmetlerine yapılan isteklerde ayrıca cihaz bilgisi, isteğin tarihi ve saati, işletim sistemi ve uygulama sürümü gibi verileri otomatik olarak topladığını belirtir. | Güvenlik, hizmetin sunulması |
| Cloudflare (ağ, önbellek, güvenlik) | IP adresi, trafik yönlendirme verisi, sistem yapılandırma bilgisi (tarayıcı ve işletim sistemi gibi) ve siteye gelen ve giden trafiğe ilişkin diğer bilgiler. Cloudflare, müşterileri adına işlediği bu kayıtlar bakımından kendisini veri işleyen olarak tanımlar. | Siteyi saldırılara karşı korumak, dosyaları önbellekten sunmak |
| Cloudflare Ağ Hatası Kaydı (Network Error Logging) | Bir bağlantı başarısız olursa tarayıcınızın gönderebileceği hata raporu: hata türü, geçen süre, HTTP yöntemi, protokol, yönlendiren sayfa (referrer). md9.net'in yanıt başlıklarına göre yalnızca başarısız bağlantılar raporlanır. Cloudflare'e göre raporlar kişiyi tanımlayan bilgi içermez; IP adresinden ülke ve ağ (ASN) gibi kaba konum bilgisi çıkarılır, IP adresinin kendisi yalnızca rapor alınırken, milisaniyeler mertebesinde bellekte tutulur. | Ağ hatalarını tespit etmek |
Bu kayıtlara erişimimiz sınırlıdır. GitHub'ın Pages ziyaretçileri için tuttuğu IP kayıtlarını biz göremeyiz. Cloudflare'in yönetim paneli ise bize toplu trafik istatistikleri (istek sayısı, ülke dağılımı gibi) ve bir güvenlik kuralına takılan isteklerin kayıtlarını gösterebilir; bu kayıtlarda IP adresi bulunabilir. Bunları yalnızca siteyi korumak ve arızaları gidermek için kullanırız, ziyaretçileri tanımlamak ya da profillemek için kullanmayız. Kayıtların ne kadar saklanacağını GitHub ve Cloudflare kendi politikalarına göre belirler; Cloudflare'in gizlilik politikası bunun için somut bir süre vermez.
Bu teknik kayıtların işlenmesinin hukuki sebebi, sitenin güvenli ve çalışır tutulmasındaki meşru menfaatimizdir (KVKK m.5/2-f).
## Bize e-posta gönderdiğinizde hangi veriler işlenir?
destek@md9.net adresine yazdığınızda, e-postanızda ve eklerinde ne varsa işlenir. Bu yüzden ilk mesajda yalnızca gerekeni yazmanızı öneriyoruz; neyin yeterli olduğu [iletişim sayfasında](https://www.md9.net/iletisim/) anlatılıyor. Veriler, sizin gönderdiğiniz e-posta ve ekleri aracılığıyla toplanır; e-postanın teknik başlıkları ise iletiyi taşıyan sunucular tarafından otomatik olarak eklenir.
| Veri kategorisi | Örnek |
| Kimlik ve iletişim | Ad, soyad, e-posta adresi; imzanızda yer alıyorsa unvan, kurum ve telefon |
| Talebin içeriği | Dosyanın türü, teknik soru, materyalin tanımı, süre |
| İş ilişkisi kurulursa | Tarafların adı (çıkar çatışması kontrolü için), teklif, sözleşme, fatura ve ödeme bilgileri |
| E-postanın teknik bilgileri | Gönderim tarihi ve saati, iletiyi taşıyan sunucuların adları ve IP adresleri gibi başlık (header) bilgileri |
| UDF Mobil desteği | Cihaz modeli, iOS ve uygulama sürümü, sorunun tarifi, gönderirseniz ekran görüntüsü |
Bu verileri aşağıdaki amaçlarla ve karşılarındaki hukuki sebeplere dayanarak işleriz:
| Amaç | Hukuki sebep (KVKK m.5/2) |
| Talebinize cevap vermek, ön değerlendirme yapmak, teklif hazırlamak | (c) bir sözleşmenin kurulmasıyla doğrudan ilgili olması; iş ilişkisine dönüşmeyen genel sorularda (f) meşru menfaat |
| İşi yürütmek, raporu teslim etmek, sonraki sorulara cevap vermek | (c) sözleşmenin ifası |
| Çıkar çatışması kontrolü | (f) meşru menfaat |
| Fatura ve muhasebe kayıtlarını tutmak | (ç) hukuki yükümlülüğümüzü yerine getirmek |
| Olası bir uyuşmazlıkta yazışmaları saklamak | (e) bir hakkın tesisi, kullanılması veya korunması |
| UDF Mobil destek taleplerine cevap vermek | (c) uygulamanın kullanım koşulları çerçevesinde sözleşmenin ifası; genel sorularda (f) meşru menfaat |
İş kapsamında teslim edilen materyal (HTS dökümü, log kayıtları, cihaz imajı gibi) çoğu zaman üçüncü kişilere ait kişisel veri ve özel nitelikli kişisel veri (KVKK m.6) içerir. Bu materyal, bir yargı sürecinde ya da uyuşmazlıkta hakkın tesisi, kullanılması veya korunması için teknik inceleme yapmak amacıyla işlenir (KVKK m.5/2-e; özel nitelikli veriler için m.6/3-d). Materyal yalnızca o işin kapsamında ve iş için gerekli ölçüde kullanılır; nasıl saklanacağı ve iş bitince iade mi imha mı edileceği işin başında yazılı olarak kararlaştırılır. Kurallar [çalışma ilkelerimizde](https://www.md9.net/calisma-ilkeleri/) yer alır.
## Veriler kimlere aktarılır?
- **E-posta altyapısı.** destek@md9.net adresine gelen iletiler, Cloudflare'in e-posta yönlendirme hizmetiyle (Email Routing) posta kutumuza iletilir; Cloudflare bu hizmette e-posta içeriğini saklamadığını ve içeriğe erişmediğini belirtir. İletiler, posta kutumuzu barındıran e-posta hizmet sağlayıcısının sunucularında saklanır.
- **Barındırma ve ağ hizmetleri.** Yer sağlayıcı: GitHub, Inc. (GitHub Pages), 88 Colin P. Kelly Jr. Street, San Francisco, CA 94107, ABD — github.com. Ağ ve güvenlik hizmeti: Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, ABD — cloudflare.com. Bu şirketler hizmeti sunmak için kendi alt yüklenicilerini kullanabilir; örneğin md9.net'in yanıt başlıklarında GitHub Pages yanıtlarının Fastly'nin içerik dağıtım ağından geçtiği görülür. Aktarımın amacı, sitenin size ulaştırılması ve korunmasıdır.
- **Kamu kurumları.** Mahkeme ve savcılık gibi yetkili kurumlara, yalnızca kanunen zorunlu olduğu hâllerde ve istenen ölçüde.
- **Mali kayıtlar.** Fatura ve muhasebe bilgileri, vergi mevzuatının gerektirdiği kurumlarla ve varsa muhasebe hizmeti aldığımız kişilerle.
Yazışmalarınızı ve materyali bunların dışında kimseyle paylaşmayız; raporu dosyaya siz ya da avukatınız sunarsınız. Veri satmayız ve reklam amacıyla kullanmayız.
GitHub ve Cloudflare ABD merkezli şirketlerdir; teknik kayıtlar ve e-posta trafiği Türkiye dışındaki sunucularda işlenebilir. GitHub, kişisel verileri ABD dahil faaliyet gösterdiği çeşitli ülkelerde işlediğini belirtir. Kişisel verilerin yurt dışına aktarımı KVKK m.9'daki şartlara tabidir.
## Veriler ne kadar süre saklanır?
Kişisel veriler, ilgili mevzuatta öngörülen ya da işlendikleri amaç için gereken süre kadar saklanır (KVKK m.4/2-d); işlenmelerini gerektiren sebep ortadan kalkınca silinir, yok edilir ya da anonim hâle getirilir (KVKK m.7/1).
| Veri | Saklama ölçütü |
| İş ilişkisine dönüşmeyen yazışmalar | Talebiniz sonuçlandıktan sonra, aynı konuda gelebilecek bir takip sorusuna cevap verebilecek kadar; sonra silinir. Daha erken silinmesini isteyebilirsiniz. |
| İş dosyası: yazışmalar, teklif, rapor ve ekleri | İş süresince ve sonrasında; olası ek sorular, uzmanın duruşmada dinlenmesi ve uyuşmazlık ihtimali için kapsamda kararlaştırılan süre boyunca |
| Fatura ve muhasebe kayıtları | Vergi mevzuatının öngördüğü süre boyunca |
| İncelenen materyal | İş bitince iade edilir ya da güvenli biçimde silinir; hangisinin olacağı baştan yazılır |
| Barındırma ve ağ kayıtları | GitHub ve Cloudflare'in kendi politikalarına göre |
## KVKK m.11 kapsamındaki haklarınız nelerdir?
KVKK m.11'e göre veri sorumlusuna başvurarak kendinizle ilgili olarak şu haklara sahipsiniz:
- kişisel verinizin işlenip işlenmediğini öğrenme, işlenmişse buna ilişkin bilgi talep etme,
- işlenme amacını ve verinin amacına uygun kullanılıp kullanılmadığını öğrenme,
- verinin yurt içinde veya yurt dışında aktarıldığı üçüncü kişileri bilme,
- eksik veya yanlış işlenmişse düzeltilmesini isteme,
- KVKK m.7'deki şartlar çerçevesinde silinmesini veya yok edilmesini isteme,
- düzeltme, silme ve yok etme işlemlerinin verinin aktarıldığı üçüncü kişilere bildirilmesini isteme,
- işlenen verinin münhasıran otomatik sistemlerle analiz edilmesi sonucu aleyhinize bir sonuç çıkmasına itiraz etme,
- kanuna aykırı işleme nedeniyle zarara uğradıysanız zararın giderilmesini talep etme.
### Nasıl başvurulur?
1. Başvurunuzu, bize daha önce yazdığınız ve sistemimizde kayıtlı olan e-posta adresinizden [destek@md9.net](mailto:destek@md9.net) adresine gönderebilirsiniz. Yazılı olarak, kayıtlı elektronik posta (KEP), güvenli elektronik imza ya da mobil imza ile de başvurulabilir (Veri Sorumlusuna Başvuru Usul ve Esasları Hakkında Tebliğ m.5/1). Yazılı başvuru için posta adresi [künye sayfasında](https://www.md9.net/kunye/) yayımlanır; orada göremezseniz adresi destek@md9.net'ten isteyebilirsiniz.
2. Başvuru Türkçe yapılır (Tebliğ m.4/2). Tebliğ m.5/2'ye göre başvuruda adınız, soyadınız ve yazılı başvuruda imzanız; T.C. vatandaşıysanız T.C. kimlik numaranız, değilseniz uyruğunuz ve pasaport ya da kimlik numaranız; tebligata esas yerleşim yeri veya iş yeri adresiniz; varsa bildirime esas e-posta adresiniz ve telefon numaranız; talebinizin konusu bulunmalıdır. Konuyla ilgili belgeleri ekleyin (Tebliğ m.5/3).
3. Başvurunuzu talebin niteliğine göre en kısa sürede ve en geç 30 gün içinde ücretsiz olarak sonuçlandırırız. İşlem ayrıca bir maliyet gerektirirse Kurulca belirlenen tarifedeki ücret alınabilir (KVKK m.13/2). Talebi kabul eder ya da gerekçesini açıklayarak reddederiz; cevabı yazılı olarak veya elektronik ortamda bildiririz (KVKK m.13/3).
4. Başvurunuz reddedilirse, cevabı yetersiz bulursanız ya da süresinde cevap verilmezse, cevabı öğrendiğiniz tarihten itibaren 30 gün ve her hâlde başvuru tarihinden itibaren 60 gün içinde Kişisel Verileri Koruma Kurulu'na şikâyette bulunabilirsiniz (KVKK m.14/1). Şikâyetten önce veri sorumlusuna başvurmuş olmak gerekir (KVKK m.14/2).
Başvurunun sizden geldiğini doğrulamak gerekirse ek bilgi isteyebiliriz; bu bilgiyi yalnızca başvuruyu sonuçlandırmak için kullanırız.
## UDF Mobil uygulaması
UDF Mobil (md9) iPhone uygulamasının veri işleme kuralları bu metinden ayrıdır ve [UDF Mobil Gizlilik Politikası](https://www.md9.net/udfmobil/tr/privacy.html)'nda anlatılır. Kısaca: uygulamada açtığınız, düzenlediğiniz ve dönüştürdüğünüz belgeler cihazınızda işlenir; belge içeriği ve dosya adları hiçbir sunucuya gönderilmez. Uygulama kullanım istatistikleri, çökme raporları, performans ölçümleri ve reklamlar için Google'ın Firebase ve AdMob hizmetlerini, abonelik durumunu doğrulamak için RevenueCat ve Apple'ı kullanır. İstatistik, çökme ve performans verileri ile reklam kişiselleştirme tercihi uygulama ayarlarından değiştirilebilir. UDF Mobil destek talebiyle bize gönderdiğiniz e-postalar ise bu metnin kapsamındadır.
## Verileri nasıl koruyoruz?
Kişisel verilerin hukuka aykırı işlenmesini ve bunlara hukuka aykırı erişilmesini önlemek, verilerin muhafazasını sağlamak için uygun teknik ve idari tedbirleri alırız (KVKK m.12/1). Yazışmalara ve materyale yalnızca işi yürüten kişi erişir. E-posta uçtan uca şifreli bir kanal olmadığından, hassas materyali e-postayla göndermemenizi isteriz; güvenli aktarım ayrıca planlanır. İşlenen verilerin kanuni olmayan yollarla başkalarınca elde edildiğini öğrenirsek, durumu en kısa sürede ilgililere ve Kişisel Verileri Koruma Kurulu'na bildiririz (KVKK m.12/5).
Bu metin, sitede ya da veri işleme biçimimizde bir değişiklik olduğunda güncellenir; sayfanın başındaki tarih son güncellemeyi gösterir.
## Sık sorulan sorular
### md9.net çerez kullanıyor mu?
Hayır. Site tarayıcınıza çerez yerleştirmez, analitik ya da reklam aracı çalıştırmaz ve sayfalar üçüncü taraf sunuculardan yazı tipi veya betik yüklemez. Bu tespit metnin son güncellendiği tarih için geçerlidir; bir çerez ya da ölçüm aracı eklenirse metin, araç kullanılmaya başlanmadan önce güncellenir. Tek istisna Cloudflare'in güvenlik katmanıdır: bir isteği otomatik trafik şüphesiyle doğrulaması gerekirse kendi güvenlik çerezini yerleştirebilir.
### Sitedeki araçlara verdiğim dosya bir sunucuya gider mi?
Hayır. Araçlar dosyanızı ya da yapıştırdığınız metni tarayıcınızın içinde işler; içerik md9.net'e veya başka bir sunucuya gönderilmez, tarayıcıda da kalıcı olarak saklanmaz. Tek istisna sizin tıklamanıza bağlıdır: EXIF görüntüleyicide 'OpenStreetMap'te aç' bağlantısına tıklarsanız fotoğraftaki koordinatlar OpenStreetMap'e gider. Araçların listesi [araçlar bölümünde](https://www.md9.net/araclar/).
### Siteyi ziyaret ettiğimde IP adresim kaydediliyor mu?
md9 bir analitik aracı çalıştırmadığı için ayrıca bir ziyaretçi kaydı tutmaz. Ancak siteyi barındıran GitHub Pages, ziyaretçinin IP adresini güvenlik amacıyla kaydeder ve saklar; siteyi sunan Cloudflare da IP adresi dahil trafik verisi işler. Bu kayıtlar o şirketlerin sistemlerindedir. Cloudflare panelinde bir güvenlik kuralına takılan isteklerin IP adresini görebiliriz; bunu yalnızca siteyi korumak için kullanırız.
### Kişisel verilerimin silinmesini nasıl isterim?
Bize daha önce yazdığınız e-posta adresinden destek@md9.net adresine 'KVKK başvurusu' konulu, Türkçe bir e-posta gönderin ve silinmesini istediğiniz veriyi belirtin. Başvuruyu en geç 30 gün içinde ücretsiz olarak sonuçlandırırız (KVKK m.13/2). Silme, verinin işlenmesini gerektiren sebep ortadan kalktığında yapılır (KVKK m.7/1); bu yüzden vergi mevzuatı gereği saklanması zorunlu fatura kayıtları gibi veriler, saklama süresi dolmadan silinmez.
### UDF Mobil'de açtığım belgeleri görebiliyor musunuz?
Hayır. UDF Mobil'de açtığınız, düzenlediğiniz ve dönüştürdüğünüz belgeler cihazınızda işlenir; belge içeriği ve dosya adları bize ya da başka bir sunucuya gönderilmez. Uygulamanın topladığı kullanım istatistikleri, çökme raporları ve reklam verileri belge içeriği içermez. Bu verilerin hangi hizmetlerle işlendiği ve nasıl kapatılacağı [UDF Mobil Gizlilik Politikası](https://www.md9.net/udfmobil/tr/privacy.html)'nda anlatılır.
---
# Adli bilişim ve dijital delil teknik incelemeleri
URL: https://www.md9.net/adli-bilisim/
Güncelleme: 2026-09-27
Adli bilişim, dijital kayıtların bir uyuşmazlıktaki teknik soruyu cevaplamak için bütünlüğü korunarak incelenmesi ve bulguların başka bir uzmanın tekrarlayabileceği biçimde raporlanmasıdır. md9 bu incelemeleri taraflar ve avukatları için yapar; bulgular uzman görüşü, bilimsel mütalaa veya teknik rapor olarak sunulur.
Dijital kayıtlar çoğu zaman olduğundan kesin görünür. Bir baz satırı telefonun durduğu noktayı, bir IP adresi klavyenin başındaki kişiyi göstermez. İncelemenin işi, kaydın ne söylediğini ve neyi söyleyemediğini ayırmaktır.
## Adli bilişim incelemesi hangi durumlarda gerekir?
Bir dijital kaydın içeriği, kaynağı ya da zamanı tartışmalı olduğunda. Soru, dosyanın türüne göre değişir:
| Dosya türü | Tipik teknik soru | Sık incelenen kayıtlar |
| Ceza dosyası | Telefon olay saatinde hangi hücreden hizmet aldı? IP adresi o saatte hangi aboneliğe aitti? | HTS, baz listesi, CGNAT kayıtları, cihaz inceleme raporu |
| Hukuk ve aile dosyası | Mesaj hangi cihazdan, ne zaman gönderildi? Ekran görüntüsü orijinal kayıtla örtüşüyor mu? | Mesajlaşma yedekleri, e-posta, fotoğraf metadata'sı |
| İş davası | Çalışan hangi tarihte hangi dosyalara erişti, hangi USB belleği taktı? | Windows olay günlükleri, USB geçmişi, e-posta sunucu kayıtları |
| Ticari uyuşmazlık | Yazılım şartnameye uygun teslim edildi mi? IBAN değişikliği e-postası tedarikçiden mi geldi? | Kaynak kod ve Git geçmişi, e-posta başlıkları, veri tabanı kayıtları |
| Şirket içi soruşturma | Hesap hangi IP'den, hangi cihazla kullanıldı? Veri nereye aktarıldı? | Kimlik doğrulama, VPN, firewall ve bulut denetim logları |
Materyal hukuka uygun yolla gelmiş olmalıdır: mahkeme ya da savcılık eliyle dosyaya girmiş kayıtlar veya tarafın kendi cihazı ve hesabı. Kanuna aykırı olarak elde edilmiş bulgular delil olarak kabul edilemez (Anayasa m.38).
## Hangi kayıtları inceliyoruz?
Her kayıt türü için neye baktığımızı, gereken materyali ve sık görülen hataları ayrı sayfada anlattık.
[Adli BilişimHTS Kayıt AnaliziArama, SMS, veri oturumu ve IMEI satırlarının kronolojik ve ilişkisel analizi; dosyadaki HTS raporlarının teknik kontrolü.](https://www.md9.net/adli-bilisim/hts-analizi/)[Adli BilişimBaz İstasyonu AnaliziCell ID, LAC, TAC ve ECI kodlarının baz listesiyle eşleştirilmesi; kapsama sınırları, harita gösterimi ve HTS ile birlikte değerlendirme.](https://www.md9.net/adli-bilisim/baz-istasyonu-analizi/)[Adli BilişimLog AnaliziSunucu, ağ, güvenlik ve bulut loglarının bütünlük kontrolü, saat normalizasyonu, korelasyonu ve olay zaman çizelgesi.](https://www.md9.net/adli-bilisim/log-analizi/)[Adli BilişimIP ve CGNAT AnaliziIP–port–zaman eşleştirmesi, CGNAT ve NAT kayıtları, abonelik eşleştirmesi ve IP'den kullanıcıya atfın teknik sınırları.](https://www.md9.net/adli-bilisim/ip-cgnat-analizi/)[Adli BilişimBilgisayar ve Dijital MateryalBilgisayar, HDD/SSD ve USB bellekte silinen dosya, USB geçmişi, tarayıcı ve registry izleri, dijital zaman çizelgesi.](https://www.md9.net/adli-bilisim/bilgisayar-inceleme/)[Adli BilişimMobil Cihaz ve UygulamaTelefon ve uygulama verisi: SQLite veri tabanları ve WAL, bildirim ve önbellek kayıtları, API trafiği, izinler, güvenlik değerlendirmesi.](https://www.md9.net/adli-bilisim/mobil-cihaz-inceleme/)[Adli BilişimWeb Sitesi ve Web UygulamasıSitenin belirli tarihteki içeriği, alan adı ve sertifika geçmişi, sunucu ve panel kayıtları, kullanıcı işlemlerinin teknik doğrulaması.](https://www.md9.net/adli-bilisim/web-sitesi-inceleme/)[Adli BilişimYazılım ve Kaynak KodTeslim ve ayıp uyuşmazlıklarında şartname eşlemesi, kaynak kod, Git geçmişi, sürüm farkları, lisans ve güvenlik bulguları.](https://www.md9.net/adli-bilisim/yazilim-kaynak-kod-inceleme/)[Adli BilişimVeri Tabanı ve Elektronik KayıtKaydın oluşturma, değişiklik ve silme geçmişi; transaction log, audit kayıtları, yedek karşılaştırması ve uygulama loglarıyla kronoloji.](https://www.md9.net/adli-bilisim/veritabani-inceleme/)[Adli BilişimE-posta İncelemesiTaklit gönderici, benzer alan adı ve ele geçirilmiş hesap iddialarının başlık, SPF/DKIM/DMARC ve sunucu kayıtlarıyla incelenmesi.](https://www.md9.net/adli-bilisim/e-posta-inceleme/)[Adli BilişimSiber Olay İncelemesiYetkisiz erişim, hesap ele geçirme, veri ihlali ve zararlı yazılım olaylarının kayıtlardan zaman çizelgesiyle yeniden kurulması.](https://www.md9.net/adli-bilisim/siber-olay-inceleme/)[Adli BilişimSosyal Medya ve PlatformlarPaylaşım zamanı, hesap erişim kayıtları, ele geçirme ve sahte hesap iddialarının platform dışa aktarımı ve diğer kayıtlarla incelenmesi.](https://www.md9.net/adli-bilisim/sosyal-medya-inceleme/)[Adli BilişimGörüntü, Video ve DokümanEXIF, video ve ses dosyası özellikleri, PDF ve Office metadata'sı ile hash karşılaştırmasının kesinlik sınırlarıyla değerlendirilmesi.](https://www.md9.net/adli-bilisim/metadata-inceleme/)
## Her incelemede izlediğimiz yöntem
Kayıt türü ne olursa olsun iş aynı beş adımda ilerler. Adımlar NIST SP 800-86'daki dört aşamaya (toplama, inceleme, analiz, raporlama) karşılık gelir; delilin edinimi ve korunmasında ISO/IEC 27037:2012'yi izleriz. Teslim ve bağımsızlık kuralları [çalışma ilkelerimizde](https://www.md9.net/calisma-ilkeleri/).
1. **Materyal.** Neyin, kimden, hangi yolla ve hangi tarihte geldiğini kayda geçiririz. Orijinal kayıt varsa elle aktarılmış kopya yerine onu isteriz; orijinal delil e-postaya eklenmez, aktarım yolu birlikte seçilir.
2. **Bütünlük.** Her dosyanın ve imajın SHA-256 [özet değeri (hash)](https://www.md9.net/bilgi/dijital-delil-butunlugu-hash/) alınır, inceleme doğrulanmış bir çalışma kopyasında yapılır. Dosyadaki imajın hash değeri hiç tespit edilmemişse bunu bulgu olarak yazarız: Yargıtay, usulünce imaj alınmamasını ve hash değerlerinin tespit edilmemesini beraat gerekçeleri arasında saymıştır (8. CD, E.2012/21817, K.2013/25428). Ceza soruşturmasında el koyma sırasında verilerin yedeklenmesi ve yedeğin bir kopyasının şüpheliye veya vekiline verilmesi CMK m.134'te düzenlenmiştir. Madde Anayasa Mahkemesinin E.2023/128, K.2026/36 sayılı kararıyla (RG 25.05.2026) iptal edilmiş olup iptal 25.02.2027'de yürürlüğe girecektir.
3. **İnceleme.** Kayıt kendi bağlamında okunur: hangi sistem üretti, saat UTC mi yerel mi, hangi alan neyi temsil ediyor. Kullanılan yazılım ve sürümü not edilir.
4. **Korelasyon.** HTS'yi cihazdaki arama geçmişiyle, sunucu logunu CGNAT kaydıyla karşılaştırır, hepsini tek bir zaman ekseninde birleştiririz. Kaynaklar çelişiyorsa çelişkiyi raporda gösteririz; birini sessizce seçmeyiz.
5. **Rapor.** Kapsam, materyal listesi ve hash değerleri, yöntem, bulgular ve sınırlılıklar. Hukuki nitelendirme yapmayız; bulgunun hukuki anlamını değerlendirmek avukata ve mahkemeye aittir.
## Bilirkişi raporlarının teknik değerlendirmesi
Dosyada zaten bir bilirkişi raporu varsa, gereken çoğu zaman yeni bir inceleme değil, raporun teknik tespitlerinin kontrolüdür. Bilirkişiyi mahkeme veya savcılık atar (HMK m.266, CMK m.63). CMK m.67/6 ise taraflara "bilirkişi raporu hakkında" uzmanından bilimsel mütalaa alma imkânı tanır; hukuktaki karşılığı HMK m.293'teki uzman görüşüdür.
Bilişim raporlarında sık rastlanan teknik eksikler: imajın hash değerinin yazılmaması, saat diliminin belirtilmemesi, hizmet veren hücrenin telefonun konumu gibi sunulması, IP adresinin portsuz ve saatsiz bir kişiye bağlanması, yöntemin ve yazılımın hiç anılmaması. Kontrol listesi ve sunum biçimi [bilirkişi raporu değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/) sayfasında, rapor türlerinin farkı [uzman görüşü bölümünde](https://www.md9.net/uzman-gorusu/).
Hukuk dosyalarında süre kısadır: rapora karşı talepler tebliğden itibaren iki hafta içinde bildirilir. Talep özel ya da teknik bir çalışma gerektiriyorsa, süre içinde başvurana bir defaya mahsus en çok iki hafta ek süre verilebilir (HMK m.281/1).
## Sık sorulan sorular
### Adli bilişim uzmanı ile bilirkişi arasındaki fark nedir?
Bilirkişi, mahkemenin ya da savcılığın bir dosyada görevlendirdiği kişidir (HMK m.266, CMK m.63); taraf bilirkişi seçemez, yalnızca atanmasını talep edebilir. Taraflar ise kendi seçtikleri uzmandan bilimsel mütalaa alıp dosyaya sunabilir (HMK m.293, CMK m.67/6). md9'un raporları bu ikinci türdendir. Ayrıntılı karşılaştırma: [uzman görüşü ile bilirkişi raporunun farkı](https://www.md9.net/bilgi/uzman-gorusu-bilirkisi-farki/).
### Karşı tarafın telefonunu veya hesabını inceleyebilir misiniz?
Hayır. Yalnızca dosyaya resmî yoldan gelmiş kayıtlar ya da sizin kendi cihazınız, hesabınız veya sisteminiz üzerinde çalışırız. Başkasının bilişim sistemine izinsiz girmek TCK m.243 kapsamında suçtur; hukuka aykırı elde edilen deliller de ispatta dikkate alınamaz (Anayasa m.38, HMK m.189/2). Karşı taraftaki bir kaydın getirtilmesini avukatınız mahkemeden ister.
### Operatör, platform veya sunucu kayıtlarını siz temin edebilir misiniz?
Hayır. HTS, baz ve CGNAT kayıtları gibi üçüncü kişilerde tutulan veriler hâkim, savcı ya da mahkeme kararıyla getirtilir; iletişimin tespitinin dayanağı CMK m.135/6'dır. Biz dosyaya gelmiş kayıtları inceleriz. Hangi kaydın ve tarih aralığının teknik soruya cevap vereceğini ön değerlendirmede söyleriz; talebi avukatınız yapar.
### Adli bilişim incelemesi ne kadar sürer, ücret nasıl belirlenir?
İkisi de materyalin hacmine ve soruların sayısına bağlıdır; birkaç bin satırlık bir HTS dökümüyle birkaç terabaytlık bir disk imajı aynı işi gerektirmez. Ön değerlendirmede materyalin sorulara elverişli olup olmadığını, tahmini süreyi ve ücreti yazılı olarak bildiririz; ücret raporun sonucuna bağlı değildir. İşleyen bir itiraz veya beyan süresi varsa ilk mesajda belirtin.
---
# HTS analizi: arama, SMS ve cihaz kayıtlarının teknik incelemesi
URL: https://www.md9.net/adli-bilisim/hts-analizi/
Güncelleme: 2026-09-27
HTS analizi, bir hattın iletişimin tespiti kayıtlarını (arama, aranma, SMS, veri oturumu ve tipik olarak IMEI ile hücre bilgisi) doğrulayıp tek bir zaman eksenine ve irtibat tablolarına dönüştüren teknik incelemedir. HTS görüşmenin içeriğini göstermez, telefonu kimin kullandığını da tek başına göstermez; raporda bu sınırlar bulguların hemen yanında yazılır.
HTS kaydı, operatörün bir hat için tuttuğu trafik bilgisinin dökümüdür; mevzuattaki karşılığı "iletişimin tespiti"dir. Sütunların ne anlattığını ve bir satırın nasıl okunduğunu [HTS kaydı nedir](https://www.md9.net/bilgi/hts-kaydi-nedir/) yazısında anlattık. Bu sayfa bir sonraki aşamayla ilgili: dosyadaki döküm doğru okunmuş mu, hangi sorulara cevap verebilir?
## HTS analizi hangi sorulara cevap verebilir?
Yalnızca dökümde gerçekten bulunan alanların taşıyabildiği sorulara. İşe, dosyadaki sorunun hangi sütuna dayanacağını belirleyerek başlarız:
| Soru | Dayanılan alanlar | Dikkat edilecek nokta |
| İki numara arasında irtibat var mı, ne sıklıkta? | Numara, diğer numara, tür (arama, aranma, SMS), tarih-saat, süre | Süresi sıfır görünen satırlar ayrı sayılmalı; toplam süre tek başına yakınlık göstermez |
| Belirli bir saat aralığında hat kimlerle iletişim kurdu? | Tarih-saat, diğer numara | Saat referansı netleşmeden aralık belirlenmez |
| Birden fazla hattın ortak irtibatı var mı? | Her hattın ayrı dökümü | Çağrı merkezi, kurye, banka gibi herkesin aradığı numaralar ayıklanmalı |
| Hat hangi cihazlarda kullanıldı, cihaz ya da SIM değişti mi? | IMEI, kayıtta varsa IMSI | Şebeke kaydında IMEI'nin son hanesi kutudakinden farklı görünebilir |
| Olay saatinde telefon hangi hücreden hizmet aldı? | Hücre kodu, tarih-saat | Hücre nokta değil, hizmet alanı gösterir |
| Beyan edilen bir görüşme kayıtta var mı? | Numara, tarih-saat, süre | Uygulama üzerinden yapılan aramalar HTS'de arama olarak görünmez |
Dört soruya ise döküm cevap vermez: görüşmenin ya da mesajın içeriği, telefonu o anda elinde tutan kişi, WhatsApp gibi uygulamalar üzerinden yapılan iletişim ve telefonun nokta konumu. Bir raporda bu sorulardan birine yalnızca HTS'ye dayanılarak kesin cevap verilmişse, incelemeye oradan başlarız.
## HTS analizinde neleri inceliyoruz?
Trafiğin kendisini, numaralar arası irtibatı, cihaz ve SIM geçişlerini, zaman–hücre ilişkisini, diğer kayıtlarla korelasyonu ve dosyadaki HTS raporlarını. Hangilerinin gerektiğini dosyadaki sorular belirler.
### Arama, aranma ve SMS trafiği
Arama ve aranma satırlarını, SMS trafik kayıtlarını ve veri oturumu satırlarını önce türüne göre ayrı sayar, sonra tek bir kronolojide birleştiririz. SMS satırı mesajın gönderildiğini ya da alındığını gösterir, metni içermez. Kronoloji olayın öncesindeki ve sonrasındaki örüntüyü görünür kılar. Gün boyu onlarca arama yapan bir hattın belirli bir saatte susması da bulgudur; anlamını ise dosyanın geri kalanı verir.
### İrtibat, ortak irtibat ve yoğunluk
Numaralar arasındaki irtibatı yönüyle (kim kimi aradı), sayısıyla ve süresiyle tabloya dökeriz. Ortak irtibat analizinde birden fazla hattın dökümü karşılaştırılır; iki hattın aynı üçüncü numarayla görüşmesi, o numaranın kime ait olduğu bilinmedikçe pek bir şey söylemez. Yoğunluk analizi iletişim sıklığını saat, gün ve hafta bazında gösterir. Sıklık iletişimin miktarını gösterir, ilişkinin niteliğini değil.
Karşı numaranın operatörünü ön ekinden çıkarmak yanıltır. Türkiye'de mobil numara taşınabilirliği 9 Kasım 2008'den beri uygulanıyor; bir numaranın taşınıp taşınmadığı e-Devlet'teki [BTK numara taşıma sorgulamasıyla](https://www.turkiye.gov.tr/btk-numara-tasima) kontrol edilebilir.
### IMEI, IMSI, cihaz–hat ilişkisi ve SIM değişiklikleri
IMEI cihazı, IMSI SIM kartı, MSISDN telefon numarasını tanımlar. Üçü birbirinden bağımsız değişebilir; 3GPP standardı, numara değişmeden IMSI'nin, IMSI değişmeden numaranın değiştirilebilmesini öngörür (TS 23.003 §3.2). Zaman çizelgesinde bu üçlünün geçiş anlarını işaretleriz:
- Aynı numara, farklı IMEI'ler: hat başka bir cihaza takılmış ya da cihaz değişmiş.
- Aynı IMEI, farklı numaralar: aynı cihazda birden fazla hat kullanılmış.
- Aynı numara, farklı IMSI: SIM kart değişmiş. Dökümde IMSI alanı yoksa bu doğrudan görülemez.
IMEI'nin ilk 8 hanesi (Type Allocation Code, TAC) cihazın marka ve modelini gösterir. Son hane şebeke kaydında 0 görünebilir: kontrol hanesi IMEI şebekede denetlenirken iletilmez, cihaz o konuma 0 yazar (TS 23.003 §6.2.1). Kutudaki IMEI ile karşılaştırmayı bu yüzden ilk 14 hane üzerinden yaparız.
Hattı kimin kullandığı sorusunda sorunun kuruluş biçimi belirleyicidir. Birleşik Krallık'taki hücre sitesi analizi kuralları, bir kişinin telefonu kullanıp kullanmadığının bu tür verilerle normalde doğrudan cevaplanamayacağını belirtir; cevaplanabilecek olan, telefonu o kişi kullanıyor olsaydı kayıtta beklenecek örüntünün görülüp görülmediğidir (FSR-C-135 §8.2.2). Raporda soruyu bu biçimde kurarız.
### Zaman ve konum ilişkileri
Her satırdaki hücre kodu, o iletişim sırasında telefona hizmet veren hücreyi gösterir. Ardışık satırlardaki hücre değişimleri bir hareketle tutarlı olabilir; ama yerinden kıpırdamayan bir telefon da yük dengeleme ya da sinyal koşulları nedeniyle farklı hücrelerden hizmet alabilir. Hücre kodlarının baz listesiyle eşleştirilmesi ve haritalanması ayrı bir iştir: [baz istasyonu analizi](https://www.md9.net/adli-bilisim/baz-istasyonu-analizi/).
### Çapraz karşılaştırma ve diğer kayıtlarla korelasyon
Birden fazla hattın dökümünü karşılaştırmak, tek dökümde görünmeyen tutarsızlıkları ortaya çıkarır. A hattının dökümünde 14.02'de görünen bir arama, B hattının dökümünde de aynı dakikada ve yakın bir süreyle görünmelidir; görünmüyorsa ya dökümlerden biri eksiktir ya da saat referansları farklıdır.
HTS'yi dosyadaki diğer kayıtlarla da karşılaştırırız: [cihaz incelemesinden](https://www.md9.net/adli-bilisim/mobil-cihaz-inceleme/) çıkan arama geçmişi ve mesajlaşma veri tabanları, internet oturum ve [CGNAT kayıtları](https://www.md9.net/adli-bilisim/ip-cgnat-analizi/), kamera ve giriş kartı kayıtları. Her kaynağın saat referansı ayrı belirlenir; cihazdaki Unix zaman damgalarını [zaman damgası dönüştürücüyle](https://www.md9.net/araclar/zaman-damgasi-donusturucu/) kendiniz de çevirebilirsiniz. Yargıtay kararlarına aktarılan inceleme raporlarında bile cihaz kayıtlarına ait zamanların kimi yerde "UTC+0", kimi yerde "UTC+3" etiketiyle yazıldığı görülür (ör. 3. CD, E.2022/23625, K.2023/1519).
### HTS raporlarının teknik yönden incelenmesi
Dosyada kolluk, bilirkişi ya da karşı taraf tarafından hazırlanmış bir HTS analizi varsa, raporun dayandığı ham döküme dönüp aynı tabloları yeniden üretiriz. Sayılar tutuyor mu, filtre neden o saat aralığıyla yapılmış, karşı hattın hücre bilgisi incelenen hatta mı yazılmış, "sık görüşme" hangi eşiğe göre tanımlanmış: her tablo için bunlara ayrı ayrı bakarız.
## HTS dökümlerinde sık görülen hatalar
Dosyaya gelen döküm çoğu zaman olduğu gibi analize hazır değildir. Önce şunlara bakarız:
1. **Saat referansı.** Dökümde saatin yerel mi UTC mi olduğu çoğu zaman yazmaz; SWGDE de operatörlerin kayıtlarda farklı saat referansları kullanabildiğini hatırlatır. Türkiye 2016'dan beri UTC+3'tedir ve bu 7 Eylül 2016 kararıyla kalıcı hâle geldi. Öncesinde kışın UTC+2 uygulanıyordu; 2011, 2014 ve 2015'te geçiş günleri Avrupa'dakinden farklıydı. Eski kayıtlarda ve eski saat dilimi verisi kullanan yazılımlarda bir saatlik kayma buradan doğabilir. Ayrıntı: [zaman damgaları ve saat dilimi](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/).
2. **Eksik kayıt.** Döküm yalnızca karardaki numarayı ve tarih aralığını kapsar; aralığın dışı "iletişim yok" demek değildir. Gerçekleşmeyen arama denemelerinin dökümde yer alıp almadığı döneme ve operatöre göre değişebilir. PDF'ten tabloya aktarılmış dökümlerde sayfa sonlarındaki satırlar kaybolabilir; satır sayısını kaynakla karşılaştırmadan analize geçmeyiz.
3. **Veri oturumu satırları.** GPRS ya da internet satırı, kullanıcının o anda telefonu elinde tuttuğunu göstermez; uygulamalar arka planda bağlantı kurar. Bu satırlarda zaman damgası ile hücre bilgisi arasındaki ilişki de değişkendir (SWGDE 17-F-001). Yargı metinlerinde "GPRS raporu" ifadesi araç takip (GPS) verisi için de kullanılabiliyor (ör. 2. CD, E.2023/28339, K.2026/5706); hangisinin kastedildiğini raporda açıkça yazarız.
4. **Mükerrer satır.** İki hattın dökümü birleştirildiğinde aynı görüşme iki kez sayılabilir. Aynı dönemin iki ayrı yazıyla iki kez gelmesi ya da sayfa başlıklarının veri satırı gibi okunması da sayıları şişirir.
5. **Karşı hattın hücre bilgisi.** Birleştirilmiş tablolarda diğer hattın hücresi incelenen telefona aitmiş gibi okunabilir. Birleşik Krallık Adli Bilim Düzenleyicisi'nin kuralları bu hatayı ayrıca sayar (FSR-C-135 §10.4.4).
6. **Kod tabanı.** LAC, CI ve ECI standartta onaltılık (hex) tanımlanır, raporlarda ise ondalık yazım yaygındır. Yanlış tabanda okunan bir sütun, hücreyi baz listesinde başka bir kayıtla eşleştirir.
## İnceleme için hangi materyal gerekir?
HTS kayıtları mahkeme ya da savcılık eliyle getirtilir; biz dosyaya gelmiş kaydı inceleriz. Bunun için:
- Dökümün dosyaya geldiği hâli, mümkünse elektronik dosya olarak. Taranmış çıktıyla da çalışılır, ama satır kaybı riski artar.
- Kaydın dayandığı karar ya da müzekkere: hangi hat, hangi tarih aralığı istendi.
- Varsa operatörün gönderdiği baz listesi.
- Dosyadaki HTS raporu, bilirkişi raporu veya kolluk analizi.
- Cevaplanması istenen sorular. "Her şeye bakın" yerine "şu iki numara 3–5 Mart arasında görüşmüş mü" gibi somut bir soru raporu hem kısaltır hem güçlendirir.
Kayıt henüz dosyada değilse
Hangi hattın, hangi aralığın ve hangi kaydın (arama-aranma dökümü, baz listesi, karşı hattın dökümü) teknik soruya cevap vereceğini ön değerlendirmede söyleyebiliriz; talebi avukatınız yapar. Beklemek kayda mal olabilir: 5809 sayılı Kanun saklama süresini bir ile iki yıl arasında yönetmeliğe bırakır (m.51/10), Yetkilendirme Yönetmeliği görüşmelere ait trafik bilgisi için iki yıl öngörür (m.19/1-f). Süresi dolmuş kayıt sonradan elde edilemeyebilir.
## İnceleme nasıl ilerler?
1. **Ön değerlendirme.** Soruları ve materyal listesini e-postayla alır, dökümün bu sorulara elverişli olup olmadığını söyleriz.
2. **Bütünlük.** Her dosyanın SHA-256 değeri kaydedilir, çalışma kopyası kullanılır.
3. **Normalizasyon.** Sütunlar tek şemaya getirilir, operatörler arası biçim farkları giderilir, zamanlar tek referansa çevrilir; dönüşüm kuralı rapora yazılır.
4. **Doğrulama.** Satır sayıları kaynakla karşılaştırılır, mükerrer ve eksik aralıklar işaretlenir, karşı hattın dökümü varsa karşılıklı satırlar eşleştirilir.
5. **Analiz.** Kronoloji, irtibat ve yoğunluk tabloları, IMEI geçişleri, sorulara özgü filtreler.
6. **Rapor.** Bulgular, her tablonun hangi satırlardan üretildiği ve sınırlılıklar.
## Raporda neler yer alır?
Rapor, başka bir uzmanın aynı tabloları ham dökümden yeniden üretebileceği biçimde yazılır: dosya listesi ve hash değerleri, zaman referansı ve dönüşüm kuralı, yazılım ve sürümü, her sorunun cevabı, cevabın dayandığı satırlar (ekte) ve bulgunun sınırları. Belirsizliği saklamayız:
Örnek: "0 5xx xxx xx 01 ile 0 5xx xxx xx 02 numaralı hatlar arasında 1–5 Mart tarihlerinde 14 arama satırı bulunmaktadır. Bunların 9'unun süre alanı 0'dır; bu satırların cevapsız arama mı, kurulamayan bağlantı mı olduğu dökümden anlaşılamamaktadır."
Rapor hukuk yargılamasında uzman görüşü (HMK m.293), ceza yargılamasında [bilimsel mütalaa](https://www.md9.net/uzman-gorusu/bilimsel-mutalaa/) (CMK m.67/6) olarak dosyaya sunulabilir; mahkeme raporu hazırlayan uzmanı duruşmada dinleyebilir (HMK m.293/2, CMK m.68/3). Uzman görüşü mahkemeyi bağlamaz, diğer delillerle birlikte değerlendirilir. Raporda hukuki nitelendirme yer almaz; bir irtibatın hukuki anlamını değerlendirmek avukata ve mahkemeye aittir.
## Sık sorulan sorular
### HTS kaydı konuşma içeriğini veya SMS metnini gösterir mi?
Hayır. HTS trafik bilgisidir: kim kimi, ne zaman, ne kadar süreyle aradı ya da kime SMS gönderdi. Görüşmenin ses kaydı ve SMS'in metni dökümde yer almaz. İçeriğe ulaşmak, iletişimin dinlenmesi ve kayda alınması gibi ayrı bir tedbir gerektirir; bu tedbir CMK m.135/1'deki koşullara ve m.135/8'deki katalog suçlara bağlıdır. HTS'ye dayanan bir bulgu, en fazla iki hat arasında iletişim kurulduğunu ve bunun zamanını gösterir.
### HTS kaydı kaç yıl geriye gider?
Sınırı operatörün saklama süresi belirler. 5809 sayılı Kanun m.51/10, trafik verilerinin haberleşme tarihinden itibaren bir yıldan az ve iki yıldan fazla olmamak üzere yönetmelikle belirlenecek süre kadar saklanmasını öngörür; Yetkilendirme Yönetmeliği m.19/1-f de telefon hizmeti sunan işletmecinin görüşmelere ait trafik bilgilerini iki yıl saklamasını ister. Sürenin her veri türüne uygulamada nasıl yansıdığını birincil kaynakta doğrulayamadık. Soruşturma, inceleme, denetleme veya uzlaşmazlığa konu veriler süreç tamamlanıncaya kadar saklanır (m.51/10-a).
### HTS kayıtlarını md9 temin edebilir mi?
Hayır. İletişimin tespiti, soruşturmada hâkim (gecikmesinde sakınca varsa Cumhuriyet savcısı), kovuşturmada mahkeme kararıyla yapılır (CMK m.135/6). Hukuk davalarında da mahkeme HTS'yi getirtebilir; Yargıtay, boşanma davasında dayanılan HTS kayıtlarının getirtilmemesini hukuki dinlenme hakkına aykırı bulmuştur (2. HD, E.2022/6774, K.2022/8947). Biz dosyaya gelmiş kaydı, çoğu zaman avukatınızın dosyadan aldığı kopya üzerinden inceleriz.
### Hat başkasının adına kayıtlıysa HTS telefonu kimin kullandığını gösterir mi?
Göstermez. HTS hattı ve cihazı tanımlar, telefonu elinde tutan kişiyi değil. CMK m.135/2 de karar talebine hattın sahibini ve biliniyorsa kullanıcısını gösteren belgenin eklenmesini ister; kanun abone ile kullanıcının farklı olabileceğini kabul eder. Kullanıcı sorusuna teknik destek; IMEI geçişlerinden, cihaz incelemesinden, hesap giriş kayıtlarından ve iletişim örüntüsünün diğer delillerle karşılaştırılmasından gelir.
### WhatsApp aramaları HTS'de görünür mü?
Ayrı bir arama veya mesaj satırı olarak görünmez. WhatsApp gibi internet üzerinden çalışan uygulamalarla yapılan görüşmeler ve mesajlar operatör açısından veri trafiğidir; HTS'de en fazla bir veri oturumu satırı olarak iz bırakabilir ve bu satır hangi uygulamanın kullanıldığını söylemez. Bu tür iletişim için telefonun kendisi, uygulamanın veri tabanı ya da platform kayıtları incelenir.
### Dosyadaki bilirkişinin HTS raporunu teknik olarak inceletebilir miyiz?
Evet. CMK m.67/6, taraflara bilirkişi raporu hakkında uzmanından bilimsel mütalaa alma imkânı tanır; hukuk yargılamasında karşılığı HMK m.293'teki uzman görüşüdür. Raporun dayandığı ham dökümden tabloları yeniden üretir; saat referansını, filtreleri, mükerrer satırları ve hücre eşleştirmelerini kontrol ederiz. Süreler kısa olabileceği için raporu tebliğ edildiği gün gönderin. Ayrıntı: [bilirkişi raporu değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/).
---
# Baz istasyonu analizi: hücre kayıtlarının teknik değerlendirmesi
URL: https://www.md9.net/adli-bilisim/baz-istasyonu-analizi/
Güncelleme: 2026-09-27
Baz istasyonu analizi, HTS ve benzeri kayıtlardaki hücre kimliklerini (2G/3G'de LAC ve Cell ID, 4G'de TAC ve ECI, 5G'de NCI) doğrulayıp operatörün baz listesiyle eşleştiren ve telefonun hangi hizmet alanlarıyla uyumlu olduğunu alternatif konumlarla birlikte gösteren incelemedir. Hücre kaydı telefonun bulunduğu noktayı değil, o anda hizmet veren hücreyi gösterir.
Bu sayfa, hücre kayıtları dosyaya girdikten sonra yapılan teknik incelemeyi anlatır. Bir baz kaydının konumu genel olarak ne kadar daraltabildiğini [baz istasyonu konum tespiti](https://www.md9.net/bilgi/baz-istasyonu-konum-tespiti/) yazısında ele aldık. Burada odak, somut bir dosyada hangi kontrollerin yapıldığı ve raporun neyi söyleyip neyi söyleyemeyeceğidir.
## Kayıtta hangi hücre kimlikleri bulunur?
Şebekenin nesline göre farklı kodlar. Hepsinin önünde ülkeyi ve operatörü gösteren MCC ve MNC kodları bulunur; Türkiye'nin MCC değeri 286'dır.
| Şebeke | Alan kodu | Hücre kimliği | Standarttaki uzunluk ve not |
| 2G / 3G | LAC (Location Area Code) | CI (Cell Identity) | LAC 16 bit, CI 16 bit. CI yalnızca kendi konum alanı içinde tekildir, bu yüzden LAC'sız okunmaz. |
| 4G (LTE) | TAC (Tracking Area Code) | ECI (E-UTRAN Cell Identity) | TAC 16 bit, ECI 28 bit; ECI, MCC ve MNC ile birlikte (ECGI) küresel olarak tekildir. Makro baz istasyonlarında ECI'nin ilk 20 biti eNB kimliği, son 8 biti hücre numarasıdır. |
| 5G (NR) | TAC (5GS) | NCI (NR Cell Identity) | TAC 24 bit, NCI 36 bit. NCI'nin gNB ve hücre bölümlerine ayrılışı operatörün yapılandırmasına bağlıdır. |
Bu ayrıntının pratik bir karşılığı var. Operatörün ondalık verdiği bir sütunu rapor yazan kişi onaltılık okursa, hücre baz listesinde başka bir kayıtla eşleşir. 4G'de ECI'yi eNB kimliği ve hücre numarası olarak ayırmak ise farklı görünen iki kodun aynı baz istasyonundaki iki hücre olup olmadığını gösterir.
**Örnek:** ECI değeri `26935555` (onaltılık `0x19B0103`) olan bir hücrede eNB kimliği 26935555 ÷ 256 = `105217`, hücre numarası kalan olan `3`'tür. `26935553` kodlu bir satır aynı eNB'nin 1 numaralı hücresine aittir. Değerler kurgusaldır. Standart, ECI ve NCI'nin ayrıntılı kodlamasını operatöre bıraktığı için (TS 23.003 §19.6) bu ayrımı her dosyada operatörün baz listesiyle doğrularız.
## Baz istasyonu analizinde neleri inceliyoruz?
**Baz istasyonu kayıtları**
: HTS satırlarındaki hücre kodları ([HTS kaydının alanları](https://www.md9.net/bilgi/hts-kaydi-nedir/) ayrı bir yazıda), baz dökümleri (belirli bir sürede bir baz üzerinden iletişim kuran tüm hatların listesi) ve internet oturum kayıtlarındaki hücre bilgileri. Yargıtay Ceza Genel Kurulu baz dökümünü de iletişimin tespiti işlemi sayar (E.2011/6-140, K.2011/222).
**Cell ID ve LAC değerlendirmesi**
: Kodların biçim ve taban kontrolü, neslin tespiti (LAC/CI mi, TAC/ECI mi, NCI mi), MCC/MNC tutarlılığı, eNB/gNB ve hücre numarası ayrımı.
**Baz eşleşmeleri**
: Kayıttaki her kodun operatörün baz listesindeki adres, koordinat ve anten yönü (azimut) ile eşleştirilmesi. Listede karşılığı olmayan kodları, adresi koordinatıyla çelişen kayıtları ve olay tarihinde faal olup olmadığı belirsiz hücreleri ayrıca işaretleriz.
**Zaman ve konum ilişkileri**
: Hücrelerin zaman sırası, iki satır arasındaki sürenin iddia edilen hareketle uyumu, olay saatine en yakın satırın olaydan kaç dakika önce ya da sonra olduğu. Arama ile olay nadiren aynı andadır; veri olay yerine gidişle de dönüşle de açıklanabiliyorsa rapor ikisini birlikte yazar (FSR-C-135 §8.2.2).
**HTS ile birlikte değerlendirme**
: Hücre bilgisi satırın türünden ayrı okunmaz. Sesli arama satırındaki hücre ile arka planda açılmış bir veri oturumundaki hücre aynı ağırlıkta değildir; SWGDE de veri oturumu kayıtlarında zaman damgası ile hücre bilgisi arasındaki ilişkinin değişken olduğunu belirtir. İletişim örüntüsünün kendisi için [HTS kayıt analizi](https://www.md9.net/adli-bilisim/hts-analizi/) sayfasına bakın.
## Hangi konum varsayımları hataya yol açar?
Hücreyi bir nokta gibi okuyan varsayımlar. Hücre bir hizmet alanıdır ve Birleşik Krallık Adli Bilim Düzenleyicisi'nin kurallarına göre hücre sitesi analizi cihazın yerini nokta olarak belirleyemez (FSR-C-135 §11.1.4). Dosyadaki raporları okurken şu varsayımları tek tek sınarız:
| Varsayım | Neden tutmaz |
| Baz istasyonunun adresi telefonun adresidir. | Hizmet alanının büyüklüğü hücreden hücreye çok değişir. FSR-C-135 üç örnek verir: bina içi bir hücre kullanıcının o binada olduğunu gösterir; çevresindeki binalardan alçak, 3 metrelik bir sokak hücresi birkaç sokağa hizmet verir; kırsalda 60 metrelik bir direkteki makro hücre 10–20 km uzağa hizmet verebilir (§11.1.5). Bina içi hücre taşınabilir bir femtocell ise, o tarihte o adreste olduğu ayrıca doğrulanmalıdır. |
| Telefon en yakın baza bağlanır. | Hücre seçimi mesafeye değil sinyal koşullarına ve şebeke parametrelerine göre yapılır. Bir hücre genellikle hizmet verdiği alandan daha geniş bir alanı kapsar (FSR-C-135, sözlük); LTE'deki yük dengeleme (Mobility Load Balancing) geçiş ve yeniden seçim parametrelerini kendiliğinden değiştirebilir (3GPP TS 36.300 §22.4.1.1). |
| Sektör çizgisi kapsamanın sınırıdır. | Üç sektörlü (3 × 120°) düzen yaygındır ve sinyal gücü azimut yönünde en yüksektir, ama sektör açısı kapsamanın kesin sınırı sayılmamalıdır (SWGDE 17-F-001). |
| Şehirde hücre küçüktür, konum kesindir. | Kentte hücreler küçüktür ama hizmet alanları iç içe geçer; aynı noktada birkaç hücre duyulur ve telefon bunlardan birine bağlanır. Kırsalda ise tek bir hücre birkaç köyü ve yolu birlikte kapsayabilir. "Şehirde birkaç yüz metre" gibi genel rakamlar için birincil kaynak bulamadık; kapsama her hücre için anten yüksekliği, yönü, gücü ve çevresine göre ayrı değerlendirilir. |
| Aynı bazdan sinyal veren iki telefon yan yanadır. | Yargıtay Ceza Genel Kurulu bunu tek başına buluşma saymaz (E.2013/247, K.2015/60). |
| Şebeke olay günü de bugünkü gibiydi. | Hücreler eklenir, kaldırılır, yönleri değişir; geçici arızalar hizmet alanlarını değiştirir (FSR-C-135 §11.1.2–11.1.3). Bugünkü ölçüm olay anını birebir temsil etmez. |
Kayıtta Timing Advance (TA) gibi bir gecikme ölçüsü varsa hizmet alanı bazın çevresinde bir mesafe halkasına daraltılabilir. GSM'de bir TA adımı yaklaşık 550 metreye karşılık gelir ve değer olağan durumda en fazla 63'tür (3GPP TS 45.010 §5.4–5.5). SWGDE, bu kayıtların kısa süre saklanabileceğini ve korunmasının hemen istenmesi gerektiğini belirtir. Dökümde böyle bir alan olup olmadığına her dosyada ayrıca bakarız.
Yargıtay kararları baz verisini tek başına belirleyici saymaz, ama önemsiz de saymaz: baz bilgilerinin görüşme içerikleri ve ifadelerle birlikte değerlendirilmesi gerektiği gerekçesiyle beraatin bozulduğu kararlar vardır (17. CD, E.2016/5449, K.2018/12335). Verinin ağırlığını diğer delillerle ilişkisi belirler; teknik incelemenin katkısı, bu ilişkinin hangi varsayımlara dayandığını göstermektir.
## Harita üzerinde gösterim ne zaman yanıltır?
Bir hizmet alanını tek bir noktaya dönüştürdüğünde. Raptiye okuyana "telefon buradaydı" der; veri ise yalnızca "telefon bu çevredeki bir hizmet alanında olabilir" der. Dosyadaki bir haritada şunları ararız (FSR-C-135 §10.4.4; SWGDE de ölçekli ve orantılı harita ister):
- Baz istasyonunun yanlış yere konması: adres ile koordinatın çelişmesi, enlem ve boylamın yer değiştirmesi, yanlış hücre koduyla etiketleme.
- Sektörün yanlış yöne çizilmesi ya da kapsamanın keskin kenarlı bir dilim gibi gösterilmesi.
- Ölçeksiz harita. Kilometrelerce alana hizmet verebilen bir hücrenin birkaç sokaklık bir çerçevede gösterilmesi.
- Yalnızca iddiayı destekleyen hücrelerin haritaya konması; alternatif konumu destekleyen satırların dışarıda bırakılması.
- Karşı hattın hücresinin incelenen telefonun hücresi gibi işaretlenmesi.
Kendi haritalarımızda ölçek, sektör yönü, belirsizlik ve alternatif konumlar birlikte gösterilir; tahmini sektör çizimleri tahmin olarak işaretlenir (FSR-C-135 §7.1.3), her işaretin hangi satırdan geldiği lejantta yazılır.
## Saha ölçümü ne zaman gerekir?
Bir hücrenin belirli bir adrese hizmet verip vermediği tartışmalı olduğunda. Bu soruya dökümden çok sahada yapılan ölçüm (drive test) cevap verir. Yargıtay, sanıkların bulunduklarını iddia ettikleri yerlerde telefonlarının hangi baz istasyonundan sinyal aldığının uygulamalı keşifle belirlenmesi gerektiğini belirterek eksik soruşturma nedeniyle bozma kararı vermiştir (1. CD, E.2008/5667, K.2012/337). Keşif ve ölçüm yargı mercii eliyle yapılır. Dosyada bir ölçüm raporu varsa yöntemini şu sorularla inceleriz:
- Ölçüm olaydan ne kadar sonra yapıldı, arada şebekede değişiklik oldu mu?
- Yalnızca sabit noktalarda mı ölçüldü? Statik ölçüm, meşru olarak hizmet veren bir hücreyi kaçırmaya yatkındır (FSR-C-135 §10.4.4).
- Ölçüm cihazı ve modu (boşta ya da görüşme sırasında) incelenen telefonu temsil ediyor mu?
- Bir hücrenin ölçümde görülmemesinden o alana hizmet vermediği sonucu çıkarılmış mı? Bu çıkarım kendi başına doğru değildir (FSR-C-135 §8.2.2).
## Materyal ve inceleme adımları
Hücre verisi, HTS gibi mahkeme veya savcılık eliyle dosyaya gelir. Raporda verinin hangi karar ve kapsamla geldiğini not ederiz; usule ilişkin değerlendirme avukata aittir.
İnceleme için gerekenler: HTS dökümünün elektronik hâli, operatörün baz listesi (hücre kodu, adres, koordinat, azimut), olay yeri ve saati, tarafların ileri sürdüğü alternatif konumlar, dosyadaki harita, keşif veya ölçüm raporları ve varsa bilirkişi raporu. Adımlar:
1. Dökümün ve baz listesinin SHA-256 değerleri kaydedilir.
2. Kodlar normalize edilir: taban, nesil, MCC/MNC, eNB/gNB ve hücre numarası.
3. Her satır baz listesiyle eşleştirilir; eşleşmeyenler ve tarih geçerliliği şüpheli olanlar ayrılır.
4. Zaman çizelgesi kurulur. Satır türü (sesli arama, SMS, veri) ve saat referansı her satırda korunur; [saat dilimi farkları](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/) bu adımda sık görülen bir hata kaynağıdır.
5. İddia edilen konum ile alternatif konumlar aynı ölçütle test edilir.
6. Ölçekli harita ve rapor hazırlanır.
## Raporda konum nasıl ifade edilir?
Verinin taşıdığı kadar. "Telefon olay saatinde X adresindeydi" cümlesini hücre verisi taşımaz. Kullandığımız kalıp, FSR-C-135 §11.1.4'teki önerinin Türkçe uyarlamasıdır:
"İncelenen telefonun kullandığı hücrenin, [ilgili konumu] da içine alan bir kapsama alanında hizmet verdiği tespit edilmiştir."
"Uyumludur" kelimesini ise ancak verinin uyumlu olduğu diğer konumları da sayarak kullanırız. Aynı kurallar, açıklamasız bir "uyumlu" kelimesinin sıradan okuyucu tarafından "oradaydı" diye anlaşılabileceğini belirtir ve İngiliz temyiz mahkemesinin R v Puaca [2005] EWCA Crim 3001 kararından şu tespiti aktarır: tutarsızlık çoğu zaman ispat değeri taşır, tutarlılığın ise çoğu zaman hiçbir ispat değeri yoktur. "En iyi hizmet veren hücre" (best serving cell) ifadesinden de kaçınırız, çünkü bir noktada tek bir hücre varmış izlenimi verir. Dosyadaki bir raporda bu tür ifadeler varsa, değerlendirmesi [bilirkişi raporu değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/) kapsamında yapılır.
Rapor dosyaya [uzman görüşü ya da bilimsel mütalaa](https://www.md9.net/uzman-gorusu/) olarak sunulabilir. Kişinin olay yerinde bulunup bulunmadığına dair kanaat mahkemeye aittir; rapor bu kanaate teknik veri sağlar, yerine geçmez.
## Sık sorulan sorular
### Baz istasyonu kaydı kişinin olay yerinde olduğunu kanıtlar mı?
Tek başına kanıtlamaz. Hücre kaydı, telefonun o anda belirli bir hücreden hizmet aldığını gösterir; hücrenin hizmet alanı bir binadan kilometrelerce genişliğe kadar değişebilir ve kayıt telefonu kimin taşıdığını söylemez. Yargıtay, telefonun olay yerindeki bazdan sinyal vermesini tek başına yeterli saymayan beraat kararını onamıştır (2. CD, E.2019/14274, K.2020/2085). Konumun ne kadar daraltılabildiği: [baz istasyonu konum tespiti](https://www.md9.net/bilgi/baz-istasyonu-konum-tespiti/).
### Cell ID, LAC, TAC ve ECI ne demek?
Hücreyi tanımlayan kodlardır. 2G/3G'de LAC konum alanını, Cell ID (CI) o alan içindeki hücreyi gösterir. 4G'de konum alanı TAC, hücre 28 bitlik ECI ile tanımlanır; ECI, ülke ve operatör kodlarıyla (MCC, MNC) birleşince küresel olarak tekildir. 5G'de hücre kimliği 36 bitlik NCI'dır (3GPP TS 23.003). Standart bu değerleri onaltılık tanımlar, raporlarda ise ondalık yazım yaygındır.
### Aynı baz istasyonundan sinyal vermek iki kişinin buluştuğunu gösterir mi?
Tek başına göstermez. Kalabalık yerleşim yerlerinde aynı anda çok sayıda telefon aynı bazdan hizmet alır; Yargıtay Ceza Genel Kurulu da farklı kişilerin telefonlarının aynı baz kapsama alanında bulunmasının tek başına buluştukları anlamına gelmediğini belirtmiştir (E.2013/247, K.2015/60). Teknik olarak bakılacak olan, iki telefonun aynı hücreyi aynı dakikalarda kullanıp kullanmadığı, hücrenin hizmet alanının büyüklüğü ve ardışık hücrelerin birlikte değişip değişmediğidir.
### Telefon neden en yakın baz istasyonuna bağlanmaz?
Hücre seçimi mesafeye değil, sinyal koşullarına ve şebekenin ayarladığı parametrelere göre yapılır. Yakındaki hücrenin anteni başka yöne bakıyor olabilir, bir bina ya da arazi sinyali kesebilir, yoğun bir hücre trafiği komşu hücreye aktarabilir. LTE standardındaki yük dengeleme işlevi, bu amaçla geçiş ve yeniden seçim parametrelerini kendiliğinden ayarlayabilir (3GPP TS 36.300 §22.4.1.1). “En yakın baz, telefonun konumudur” varsayımı bu yüzden hatalıdır.
### Baz istasyonu tespiti nasıl yapılır?
Dökümdeki hücre kodu, operatörün baz listesindeki kaydıyla eşleştirilir: baz istasyonunun adresi, koordinatı ve anten yönü (azimut). Önce kodun nesli (LAC/CI, TAC/ECI, NCI) ve tabanı doğrulanır. Ardından hücrenin olay tarihindeki olası hizmet alanı, iddia edilen konum ve alternatif konumlarla birlikte değerlendirilir. Hizmet alanı tartışmalıysa yargı mercii saha ölçümü yaptırabilir. Tespitin sonucu bir nokta değil, bir alandır.
### Baz istasyonu kayıtları nasıl elde edilir?
Yargı kararıyla; kişisel başvuruyla alınamaz. Arama-aranma dökümü CMK m.135/6'daki iletişimin tespiti kapsamındadır. Yargıtay Ceza Genel Kurulu ise telefonun hangi bazdan sinyal verdiğinin belirlenmesini m.135/1'deki sinyal bilgilerinin değerlendirilmesi sayar (E.2013/247, K.2015/60); bu tedbir m.135/8'deki katalog suçlarla sınırlıdır. Ayrımın dosyaya etkisini avukat değerlendirir. md9 kayıt temin etmez; dosyaya gelmiş kayıtları ve baz listesini teknik olarak inceler.
---
# Log analizi: sunucu, ağ ve bulut kayıtlarının teknik incelemesi
URL: https://www.md9.net/adli-bilisim/log-analizi/
Güncelleme: 2026-09-27
Log analizi, sistemlerin kendiliğinden tuttuğu kayıtlardan bir olayın ne zaman, hangi hesapla, hangi adresten ve hangi sistemde gerçekleştiğini yeniden kurma işidir. md9 log dosyalarını hash değeriyle teslim alır, her kaynağın saatini UTC'ye çevirip kaynakları birbirine bağlar ve bulguyu, neyi gösteremediğini de yazarak teknik rapor ya da uzman görüşüne dönüştürür.
Tipik sorular: ayrılan çalışanın hesabı ayrılış tarihinden sonra kullanılmış mı, bir müşteri kaydını kim sildi, yönetici paneline gece hangi adresten girildi. Cevap tek dosyada durmaz; VPN ağ geçidi, etki alanı denetleyicisi, uygulama ve firewall aynı olayın farklı parçalarını çoğu zaman farklı saat referanslarıyla yazar.
## Hangi log kaynaklarını inceliyoruz?
Dört grup kaynağı inceliyoruz: sistem ve sunucu, ağ, güvenlik, uygulama ve bulut. Alanların anlamını her sistemin kendi yapılandırmasından teyit ederiz; aynı adlı alan iki kurulumda farklı değer yazabilir.
### Sistem ve sunucu kayıtları
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta | ````
| Windows Event Log (Security.evtx, System.evtx) | Oturum açma (4624), başarısız deneme (4625), süreç başlatma (4688), günlük temizleme (1102), saat değişikliği (4616) | 4688'de komut satırı politika açılmadıkça boştur. Windows 10/11'de Security günlüğü varsayılan 20 MB'tır, dolunca en eski olayların üzerine yazar. |
| Active Directory kayıtları | Kerberos bilet istekleri (4768, 4769), NTLM doğrulaması (4776), hesap oluşturma (4720), kilitlenme (4740) | Logon ID yalnızca aynı bilgisayarda ve yeniden başlatmaya kadar tekildir; makineler arasında anahtar olamaz. | ``````````
| Linux sistem logları | /var/log/auth.log (Debian), /var/log/secure (RHEL), systemd journal, wtmp, btmp | Debian 12'den itibaren rsyslog varsayılan olarak kurulmaz; auth.log yoksa kayıtlar journal'dadır. | ````````
| Audit logları | auditd (/var/log/audit/audit.log), uygulamaların denetim izleri | auid alanı, kullanıcı su ile başka hesaba geçse de oturumu ilk açan hesabı taşır. |
| Hata ve olay kayıtları | Servis kurulumu (7045), beklenmedik kapanış (41, 6008), yeniden başlatma (1074), uygulama hata dosyaları | Hata satırı olayın kendisini değil, sistemin ona tepkisini gösterir. |
### Ağ kayıtları
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta |
| Firewall logları | İzin verilen ve reddedilen bağlantılar, IP ve port, NAT dönüşümü | Bağlantı NAT öncesinde iç, sonrasında dış adresle görünür; satırın hangisini yazdığını önce belirleriz. |
| VPN kayıtları | Kullanıcı adı, dış IP, tünel içi IP, bağlanma ve ayrılma zamanı | Tünel içi adresi hesaba bağlayan çoğu zaman yalnızca bu kayıttır. |
| Proxy logları | Kullanıcı ya da iç IP, istenen adres, yanıt kodu | HTTPS'te proxy genellikle yalnızca alan adını görür. Kayıtta tam URL varsa TLS denetimi yapılıp yapılmadığını sorarız. |
| DNS kayıtları | Hangi iç adresin hangi alan adını ne zaman sorguladığı | Şifreli DNS (DoH, DoT) kullanan cihazın sorguları kurumun DNS sunucusuna hiç uğramayabilir. | ``
| DHCP kayıtları | IP, MAC adresi ve cihaz adı eşlemesi, kira zamanları | Windows DHCP sunucusu gün adlı dosyalara (DhcpSrvLog-Mon.log gibi) yazar; dosya yerel saatle gece yarısı değişir, bir hafta sonra üzerine yazılır. |
| Router / switch kayıtları | Arayüz durumu, yapılandırma değişikliği, yönetici girişleri | Eski tip syslog (RFC 3164) satırında yıl ve saat dilimi yoktur; ikisi raporda varsayım olarak yazılır. |
### Güvenlik sistemleri
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta |
| IDS / IPS kayıtları | İmzaya ya da davranış kuralına uyan trafik, alarm önceliği | Alarm denemeyi gösterir, başarıyı değil. |
| WAF kayıtları | Gelen istek, eşleşen kural, engelleme kararı | Kural "yalnız izle" modundaysa engellendiği sanılan istek uygulamaya ulaşmış olabilir. |
| SIEM kayıtları | Farklı kaynaklardan tek biçime çevrilmiş olaylar, korelasyon alarmları | İşlenmiş kopyadır, dönüştürmede alan düşebilir; kritik satırları ham kaynakta da buluruz. |
| Authentication / login kayıtları | Kimlik sağlayıcı ve tek oturum açma (SSO) kayıtları, çok faktörlü doğrulama, başarısız denemeler | Microsoft Entra ID oturum açma kayıtlarını ücretsiz sürümde 7, P1 ve P2'de 30 gün tutar. |
### Uygulama, veri tabanı ve bulut kayıtları
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta | ````````
| Web server logları (Apache / Nginx) | İstemci IP'si, zaman, istek satırı, durum kodu, Referer, User-Agent | Önde ters proxy ya da CDN varsa, ayrıca yapılandırılmadıkça %h ve $remote_addr onun adresidir. Varsayılan biçim kaynak portu yazmaz. |
| Uygulama ve API logları | İstek kimliği, kullanıcı, uç nokta (endpoint), parametreler, yanıt kodu | Neyin loglanacağına geliştirici karar verir; kaydın yokluğu olayın yokluğu değildir. |
| Kullanıcı işlem kayıtları | Hangi hesabın hangi kaydı ne zaman oluşturduğu, değiştirdiği, sildiği | Uygulama yöneticisi bu tabloyu düzenleyebiliyorsa bağımsız bir kopyayla karşılaştırırız. | ````[](https://www.md9.net/adli-bilisim/veritabani-inceleme/)
| Veri tabanı logları | Bağlantı, sorgu ve hata kayıtları, işlem (transaction) günlükleri | PostgreSQL'de log_statement varsayılanı none, MySQL'de genel sorgu logu varsayılan olarak kapalıdır. Ayrıntı: veri tabanı incelemesi. | ``
| E-posta sunucu kayıtları | Gönderici, alıcı, Message-ID, sunucular arası aktarım, teslim durumu | Exchange Server ileti izleme kaydı UTC yazar, içeriği tutmaz, konu satırını varsayılan olarak tutar; dosyalar 30 günde, klasör dolarsa daha erken silinir. | ``
| Cloud sistem logları | AWS CloudTrail, Microsoft 365 birleşik denetim kaydı, Google Workspace denetim kayıtları | CloudTrail'de eventTime UTC'dir; olay geçmişi (Event history) son 90 günün yönetim olaylarını gösterir. |
## İnceleme için hangi materyal gerekir?
Log dosyalarının özgün hâli, onları üreten yapılandırma ve toplama kaydı. Ekran görüntüsü logun kendisi değildir; Excel'e aktarılmış dosyada da tarihler bölgesel ayara göre yeniden yorumlanmış olabilir.
- Özgün dosyalar: `.evtx`, `access.log` ve döndürülmüş arşivleri (`access.log.1`, `.gz`), journal dosyaları, bulut konsolundan JSON dışa aktarımı.
- Logu üreten yapılandırma: `log_format` satırı, `rsyslog.conf`, saat dilimi ve NTP ayarı, SIEM'in alan eşleme kuralları.
- Toplama kaydı: dosyayı kim, hangi yöntemle, ne zaman aldı; alındığı anda hesaplanan SHA-256 değeri. Değeri [hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) tarayıcıda da üretebilirsiniz.
- İç IP planı ve NAT kuralları. Bunlar olmadan `10.0.3.17` gibi bir adresin hangi cihaz olduğu anlaşılmaz.
Ceza soruşturmasında el konulan sistemlerin yedeğinden şüpheliye ya da vekiline verilen kopya (CMK m.134/4) da inceleme materyali olabilir. Madde, Anayasa Mahkemesi'nin 12.02.2026 tarihli, E.2023/128, K.2026/36 sayılı kararıyla iptal edilmiştir (RG 25.05.2026); iptal 25.02.2027'de yürürlüğe girecektir.
Logları toplamadan önce Sunucuyu yeniden başlatmayın, günlükleri temizlemeyin, log dosyasını düzenleyicide açıp kaydetmeyin. Önce olduğu gibi kopyalayın; hash değerini ve kopyayı kimin aldığını not edin.
## Log incelemesi nasıl ilerler?
1. **Soru ve zaman aralığı.** Hangi olay, hangi hesaplar, hangi tarihler.
2. **Teslim ve bütünlük.** Her dosyanın SHA-256 değeri teslim anındaki değerle karşılaştırılır; iş çalışma kopyası üzerinde yürür.
3. **Kaynak envanteri.** Her kaynak için biçim, alan anlamları, saat referansı, ilk ve son kaydın tarihi. Kayıtlar olaydan sonra başlıyorsa bunu işin başında söyleriz.
4. **Saat normalizasyonu.** Bütün zamanlar UTC'ye çevrilir. Her kaynağın saat sapması ayrı ölçülür, eşleştirme toleransı gerekçesiyle yazılır.
5. **Ayrıştırma.** Açık kaynak araçlar (ör. plaso/log2timeline) ve kendi betiklerimizle. Araç ve sürüm rapora geçer; adımları başka bir uzman tekrarlayabilmelidir.
6. **Değerlendirme.** Bütünlük, korelasyon, zaman çizelgesi, alternatif açıklamalar.
## Zaman damgası incelemesi: kayıtlardaki saatler neden tutmaz?
Çünkü her sistem zamanı kendi referansıyla yazar: kimi UTC, kimi yerel saat, kimi saat dilimini hiç belirtmez. Türkiye 2016'dan beri sürekli UTC+3 olduğundan aynı an iki kayıtta üç saat farkla görünebilir; incelemeye her kaynağın zaman damgasını (timestamp) çözerek başlarız.
| Kaynak | Zaman nasıl yazılır | ````
| Apache %t | İsteğin alındığı an, ofsetle: [14/Mar/2026:23:47:05 +0300] | ``
| Windows olay günlüğü | TimeCreated SystemTime, UTC (Olay Görüntüleyici ekranda yerel saate çevirir) | ````
| Linux auditd | msg=audit(1773521225.412:3187): Unix saniyesi ve kayıt numarası | ``
| Eski tip syslog (RFC 3164) | Mar 14 23:47:05: yerel saat; yıl ve saat dilimi yok | ``
| AWS CloudTrail, Exchange ileti izleme | ISO 8601, UTC: 2026-03-14T20:47:05Z |
Örnek: Tablodaki değerlerin hepsi 14 Mart 2026 20:47:05 UTC'dir; saat dilimine bakılmazsa 20:47 ile 23:47 iki ayrı olay gibi okunur. 2016 öncesi kayıtlarda yaz saati ve Avrupa'dan farklı geçiş tarihleri (2011, 2014, 2015) de hesaba katılır. Ayrıntı: [zaman damgaları ve saat dilimi](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/); dönüşüm için [zaman damgası dönüştürücü](https://www.md9.net/araclar/zaman-damgasi-donusturucu/).
Saat dilimi doğru olsa da saatin kendisi yanlış olabilir: NTP'nin (RFC 5905) varsaydığı 15 ppm frekans toleransı günde yaklaşık 1,3 saniye, altı ayda dört dakikaya yakın kayma demektir. Sapmayı her kaynakta ayrı ölçeriz (NTP durumu, 4616 olayları, `wtmp`).
## Log bütünlüğü ve manipülasyon değerlendirmesi nasıl yapılır?
İki soruyu ayırarak. Dosyanın toplandığı andan beri değişip değişmediği, toplama anındaki hash değeriyle kesin olarak sınanır. Kaydın olaydan sonra, toplamadan önce düzenlenip düzenlenmediğinin ise kesin testi yoktur; dolaylı izlerle tartılır. Düz metin logu yetkili biri değiştirebilir, syslog protokolünde de kriptografik koruma yoktur (RFC 5424).
- **Teslim zinciri.** Hash değeri, alan kişi, zaman, yöntem. Yargıtay 8. Ceza Dairesi, imaj alınıp hash değerlerinin tespit edilmemesini beraat gerekçeleri arasında saymıştır (E.2012/21817, K.2013/25428).
- **Süreklilik.** Kayıt numaralarında atlama, 1102 ve 4616 olayları, döndürülmüş dosyalar arasında boş kalan saatler, geriye akan zaman.
- **Kaynaklar arası çelişki.** Web sunucusu bir isteği yazmış, önündeki firewall o dakikada hiçbir bağlantı görmemiş.
- **Koruma mekanizmaları.** Merkezi log sunucusuna anlık gönderim, tek seferlik yazılabilir (WORM) depolama, journald'ın Forward Secure Sealing özelliği, ticari toplu kullanım sağlayıcılarının her gün kaydettiği bütünlük değeri.
İz bulunmaması değişiklik olmadığını ispatlamaz. Bizce en sağlam dayanak bağımsızlıktır: şirket sunucusu, servis sağlayıcı ve bulut gibi kontrolü farklı kişilerde olan sistemler aynı olayı tutarlı gösteriyorsa, hepsinin birlikte düzenlenmiş olması zayıf bir ihtimaldir. İzlerin ayrıntısı [log kayıtlarının delil değeri](https://www.md9.net/bilgi/log-kayitlari-delil-degeri/) yazısında.
## Farklı sistem loglarının korelasyonu ve olay zaman çizelgesi
Korelasyon, kayıtları ortak alanlar üzerinden birbirine bağlamaktır: IP ve zaman aralığı (varsa port), kullanıcı adı, oturum kimliği, `X-Request-ID` gibi istek kimlikleri, e-postada `Message-ID`. Her bağlantının gerekçesi raporda yazılır.
Örnek (veriler kurgusaldır, zamanlar UTC'ye çevrilmiştir): Bir şirket, ayrılan bir çalışanın müşteri listesini dışarı aldığından şüpheleniyor. Zaman çizelgesi şöyle kurulabilir:
| Saat (UTC) | Kaynak | Kayıt | ``
| 18:02:11 | VPN ağ geçidi | ornek.kullanici hesabı 203.0.113.25 adresinden bağlandı, tünel içi adres 10.8.0.14 |
| 18:02:40 | Etki alanı denetleyicisi | Aynı hesap için Kerberos bilet isteği (4768), istemci 10.8.0.14 |
| 18:05:03 | CRM uygulama logu | Aynı hesapla "müşteri listesini dışa aktar" işlemi, 4.812 satır |
| 18:05:09 | Firewall | 10.8.0.14'ten harici bir dosya paylaşım hizmetine 14 MB çıkış |
Çizelge hesabın kullanıldığını güçlü biçimde gösterebilir; hesabı kimin kullandığını ise tek başına göstermez, parola paylaşılmış ya da çalınmış olabilir. 203.0.113.25 adresinin olay anındaki abonesi ayrı bir eşleştirme ister ([IP adresi tespiti ve CGNAT analizi](https://www.md9.net/adli-bilisim/ip-cgnat-analizi/)). Saldırı ya da hesap ele geçirme şüphesinde inceleme [siber olay incelemesine](https://www.md9.net/adli-bilisim/siber-olay-inceleme/) dönüşür.
## Log analizi neyi gösteremez?
Loglanmayan bir olayı gösteremez; varsayılan ayarlar ise pek çok işlemi hiç kaydetmez. Bir satırın varlığı içeriğinin doğru olduğunu da göstermez: `User-Agent`, `Referer` ve `X-Forwarded-For` istemcinin kendi yazdığı değerlerdir. Olay dönemine ait kayıtlar silinmiş ya da üzerine yazılmışsa o aralığı tahminle doldurmayız; raporda boşluk olarak kalır.
## Raporda neler yer alır?
Soru, materyal listesi ve hash değerleri, yöntem ve araç sürümleri, saat referansı tablosu, bulgular, zaman çizelgesi, alternatif açıklamalar ve incelemenin sınırları. Ham satırlar ektedir; her bulgu kaynağındaki satıra kadar izlenebilir.
Rapor uzman görüşü (HMK m.293) ya da bilimsel mütalaa (CMK m.67/6) olarak hazırlanıp avukatınız tarafından dosyaya sunulabilir. Mahkemeyi bağlamaz, diğer delillerle birlikte değerlendirilir; hukuki nitelendirme avukata ve mahkemeye aittir. Dosyada loglara dayanan bir bilirkişi raporu varsa (uzmanlık alanları listesindeki adıyla "Veri ve Log Kaydı İnceleme"), teknik tespitlerini [bilirkişi raporunun teknik değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/) kapsamında inceleyebiliriz.
## Sık sorulan sorular
### Log kayıtları delil olarak kullanılabilir mi?
Kullanılabilir. HMK m.199 elektronik ortamdaki verileri belge sayar; ceza yargılamasında hukuka uygun elde edilmiş her türlü delil kullanılabilir (CMK m.217/2). Bir logun ağırlığı ise güvenilirliğine bağlıdır: kaydı hangi sistem üretti, kim değiştirebiliyordu, saat doğru muydu, toplama anı belgelendi mi. Takdir mahkemenindir. Ayrıntı: [log kayıtlarının delil değeri](https://www.md9.net/bilgi/log-kayitlari-delil-degeri/).
### Log kayıtları ne kadar süre saklanır?
Tek bir süre yoktur; çoğu zaman üreticinin varsayılan ayarı belirler. AWS CloudTrail olay geçmişi son 90 günü gösterir, Microsoft Entra ID ücretsiz sürümde oturum açma kayıtlarını 7 gün tutar, Exchange Server ileti izleme dosyalarını varsayılan ayarla 30 günde siler. Mevzuattan gelen sürelere bir örnek: internet toplu kullanım sağlayıcıları erişim kayıtlarını iki yıl saklar. Şüphe doğduğu gün kayıtları kopyalayın.
### Karşı tarafın sunucusundaki loglara nasıl ulaşılır?
Başkasının sistemine girip kayıt toplamayız; böyle elde edilen kayıt hukuka aykırı delil sorunu doğurur ve suç oluşturabilir. Karşı taraftaki ya da bir hizmet sağlayıcıdaki kayıtlar mahkeme veya savcılık eliyle istenir; dava açılmadan önce HMK m.400'deki delil tespiti de bir yoldur. Hangi yolun izleneceğine avukatınız karar verir; biz hangi kaydın hangi alanlar ve tarih aralığıyla isteneceğini teknik olarak tarif ederiz.
### Log incelemesi için sunucumuza erişim vermemiz gerekir mi?
Genellikle hayır. Kopyalar üzerinde çalışırız: hangi dosyaların hangi yöntemle alınacağını yazılı olarak tarif ederiz, toplamayı BT ekibiniz yapar ve her dosyanın hash değerini kaydeder. Canlı sistemden toplama zorunluysa adımları birlikte planlarız. Çalışan sistemde yapılan her işlem iz bıraktığı için kullanılan komutlar zamanlarıyla birlikte rapora geçer.
### Silinmiş log kayıtları geri getirilebilir mi?
Bazen. Önce silinen dosyayı kurtarmaya değil, kaydın başka kopyalarına bakarız: döndürülmüş arşivler, merkezi log sunucusu ya da SIEM, yedekler, Windows gölge kopyaları. Diskte üzerine yazılmamış içerik kurtarılabilir; SSD'lerde TRIM bu ihtimali ciddi biçimde düşürür. Kurtarılamaması, kaydın hiç var olmadığını göstermez.
---
# IP adresi ve CGNAT kayıtlarının teknik incelemesi
URL: https://www.md9.net/adli-bilisim/ip-cgnat-analizi/
Güncelleme: 2026-09-27
IP ve CGNAT analizi, bir kayıtta görünen IP adresinin olay anında hangi internet aboneliğine ve hangi ağa ait olduğunu IP, port ve saniye düzeyinde zaman bilgisiyle eşleştirme işidir. md9, dosyadaki kayıtlarla bu eşleştirmenin gerçekten kurulup kurulamadığını ve IP'den kişiye giden yolun hangi halkada koptuğunu inceler.
Dosyalarda IP adresi genellikle bir zincirin ilk halkasıdır. Bir platform, e-posta sağlayıcısı ya da şirket sunucusu "şu hesaba şu saatte şu IP'den girildi" der; ardından operatöre o IP'nin abonesi sorulur ve cevapta bir isim çıkar. Her halka teknik bir eşleştirmedir ve her birinde hata yapılabilir; biz halkaları tek tek kontrol ederiz.
## Hangi durumlarda IP ve CGNAT incelemesi gerekir?
- Yetkisiz hesap girişi, hakaret ya da tehdit içeren paylaşım, dolandırıcılık ilanı gibi dosyalarda failin kim olduğu sorusu bir IP abone sorgusuna dayanıyorsa.
- Abone tespit yazısında adınız çıkmış, ama o saatte o bağlantıyı kullanmadığınızı düşünüyorsanız.
- Bir bilirkişi raporu IP adresinden doğrudan kişiye ulaşmış; port, saat dilimi ya da ortak ağ ihtimalini tartışmamışsa.
- Şirketinize yönelik bir saldırıda, kendi loglarınıza dayanarak operatörden ne isteneceğini netleştirmek istiyorsanız.
## IP adresinden kişiye giden zincir nerede kopar?
Eşleştirmenin her adımı bir öncekinin doğruluğuna dayanır; birinde hata varsa sonrakiler başka bir kişiyi gösterir.
| Adım | Gereken kayıt | Tipik kırılma noktası |
| 1. Olay kaydı | Platform ya da sunucu logu: IP, kaynak port, zaman ve saat dilimi | Port yazılmamış; saat dilimi belirsiz; logdaki IP aslında bir proxy'nin ya da CDN'in adresi |
| 2. Adresin sahibi | IP bloğunun hangi işletmeciye tahsisli olduğu (RIPE NCC kayıtları) | Adres bir VPN hizmetine, bulut sunucusuna ya da Tor çıkış noktasına ait |
| 3. Operatörün NAT kaydı | Genel IP, port aralığı, başlangıç ve bitiş zamanı, iç adres ya da oturum kimliği | Sorgu yanlış saatle yapılmış; port olmadan birden fazla abone dönmüş |
| 4. Abonelik kaydı | Hat ya da müşteri numarası, abone kimliği, adres | Abone ile kullanıcı farklı kişi; abonelik bir şirkete ait |
| 5. Abonenin ağı | Modem DHCP tablosu, toplu kullanım erişim kayıtları, şirket firewall logu | Ortak Wi-Fi; kayıt hiç tutulmamış; MAC adresi rastgele |
| 6. Cihaz ve kişi | Cihaz incelemesi, hesap oturumları, diğer deliller | Cihazı birden fazla kişi kullanıyor |
Abone ile kullanıcının farklı olabileceğini kanun da kabul eder: iletişimin tespiti talebine hattın sahibini ve biliniyorsa kullanıcısını gösteren belge eklenir (CMK m.135/2). Yargıtay 8. Ceza Dairesi, IP numarasının kullanılan bilgisayarı değil internetle olan bağlantıyı gösterdiğini beraat gerekçeleri arasında saymıştır (E.2012/21817, K.2013/25428).
## Statik IP, dinamik IP, NAT ve CGNAT: fark ne?
Önce adresin türü belirlenir, çünkü gereken kayıt türe göre değişir.
| Tür | Ne demektir | Eşleştirme için gereken |
| Statik IP | Aboneye kalıcı atanmış adres; çoğunlukla kurumsal bağlantılar. Ticari toplu kullanım sağlayıcıların sabit IP kullanması zorunludur. | IP ve tarih çoğu zaman yeter; ağın içindeki cihaz ayrıca araştırılır. |
| Dinamik IP | Bağlantıdan bağlantıya değişen adres. Aynı adres farklı zamanlarda farklı abonelere verilir. | IP, doğru zaman ve operatörün oturum başlangıç-bitiş kaydı. |
| NAT (ev, iş yeri) | Modemin arkasındaki bütün cihazlar tek genel IP ile çıkar. | Aboneye kadar ulaşılır; içerideki cihaz ayrı kayıt ister. |
| CGNAT | Operatör genel IP'yi port aralıklarına bölerek aynı anda birçok aboneye paylaştırır. Operatör ile abone arasında 100.64.0.0/10 "paylaşılan adres alanı" kullanılabilir (RFC 6598). | IP, kaynak port, saniye hassasiyetinde zaman ve saat dilimi. |
| IPv6 | Adres paylaşımı genellikle yoktur, ama cihazlar gizlilik için geçici adresler üretir. | Aboneye atanan önek ve operatörün önek atama kaydı. |
Yargıtay 15. Ceza Dairesi, aynı IP adresinin değişik zamanlarda farklı kullanıcılara verilebileceği dikkate alınmadan kurulan hükmü eksik inceleme nedeniyle bozmuştur (E.2014/8947, K.2017/44). Dosyadaki bir adresin özel, CGNAT ya da genel aralıkta olup olmadığını [IP adresi kontrol aracıyla](https://www.md9.net/araclar/ip-adresi-kontrol/) görebilirsiniz; mekanizmanın kendisini [CGNAT nedir](https://www.md9.net/bilgi/cgnat-nedir/) yazısında anlattık.
## IP–port–zaman eşleştirmesinde port ve saat neden belirleyici?
CGNAT'ta genel IP tek bir aboneyi değil bir abone grubunu gösterir; gruptan tek aboneye inmenin yolu kaynak porttur. RFC 6302 bu yüzden internete açık sunucuların kaynak portu ve UTC'ye göre, saniye hassasiyetinde, güvenilir bir kaynağa bağlı zamanı kaydetmesini önerir. Aynı gereklilik operatör yazılarında da görülür: Yargıtay 11. Ceza Dairesi'nin incelediği bir dosyadaki operatör yazısına göre NAT'lı IP'lerde hattın tespiti için kaynak IP ve kaynak port bilgisiyle birlikte zaman aralığı ve erişilen sitenin IP adresi gerekir (E.2021/31653, K.2024/2780).
Örnek (kurgusal veriler): Bir platform, hesaba 14.03.2026 20:47:05 UTC'de 203.0.113.25 adresinden girildiğini bildiriyor, port vermiyor. BTK'nın 2020 tarihli İSS trafik logu teknik dokümanı, NAT yapan işletmecilere her kullanıcıya bölünmemiş sabit bir port aralığı atamayı (dokümandaki örnek 1.000 port) ve boşalan aralığı başka kullanıcıya vermeden önce en az bir saat bekletmeyi tavsiye eder. 1024–65535 aralığı 1.000'lik bloklara bölünürse aynı adresi aynı anda 64 abone kullanabilir. Kaynak port 40112 olarak bilinirse sorgu tek bloğa, yani tek aboneye iner. Aynı sorgu saat "20:47 Türkiye saati" sanılarak yapılırsa üç saat önceki bir ana bakılır; blok o arada el değiştirmişse cevap başka bir aboneyi gösterir. Saat dönüşümlerinin tuzakları [zaman damgaları ve saat dilimi](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/) yazısında.
Yargıtay 8. Ceza Dairesi 2014'te port bilgisinin önemini vurgularken, o tarihte bu bilgiyi tutmanın yasal zorunluluk olmadığını da not etmişti (E.2013/4668, K.2014/9860). 5651 sayılı Kanun'daki trafik bilgisi tanımına port bilgisi 2020'de (7253 s.K.), "kaynak ve hedef" ibaresi 2026'da (7590 s.K.) eklendi; bugünkü tanım IP adresini, kaynak ve hedef portu, hizmetin başlama ve bitiş zamanını, hizmet türünü, veri miktarını ve varsa abone kimlik bilgilerini sayar (m.2/1-j). Olay eskiyse o dönemde port kaydı tutulup tutulmadığı ayrıca değerlendirilir.
## İncelediğimiz kayıtlar
**İnternet erişim ve oturum kayıtları**
: Operatörün bağlantı için tuttuğu başlangıç, ara güncelleme ve bitiş satırları. Aynı oturum birkaç satırda görünebilir; satır saymak bağlantı saymak değildir, tekilleştirmeyi oturum kimliğiyle yaparız.
**CGNAT ve NAT kayıtları**
: İç adres, genel IP, port aralığı ve zaman. Mobil hatlarda bu kayıtları HTS'deki veri oturumu satırlarıyla karşılaştırmak tutarlılığı sınar; bunun için [HTS kayıt analizi](https://www.md9.net/adli-bilisim/hts-analizi/) ile birlikte çalışırız.
**Abonelik kayıtları**
: Abone kimliği, adres, hat ya da müşteri numarası. Teknik eşleştirme en fazla bu kayda kadar gelir.
**Platform ve sunucu logları**
: Hesap giriş geçmişi, web sunucusu erişim logu, e-posta başlığındaki `Received:` satırları. Logdaki IP'nin istemcinin mi yoksa bir ters proxy ya da CDN'in mi adresi olduğunu yapılandırmadan teyit ederiz; `X-Forwarded-For` başlığının en soldaki değeri istemci tarafından uydurulabilir. Ayrıntı: [log analizi](https://www.md9.net/adli-bilisim/log-analizi/).
**IP loglarının korelasyonu**
: Tek bir IP satırı zayıf bir göstergedir. Aynı hesabın giriş geçmişindeki bütün adresleri zaman ekseninde dizeriz: ev bağlantısı, mobil hat ve iş yeri adresleri arasındaki geçişler, aynı IP'nin başka hesaplarda görünmesi ya da bir adresin yalnızca olay saatinde ortaya çıkması bu dizilimde anlam kazanır.
**Yerel ağ kayıtları**
: Modemin DHCP tablosu, şirket firewall'unun NAT logu, otel ve kafe gibi toplu kullanım sağlayıcıların erişim kayıtları. Toplu kullanım sağlayıcılar iç IP'yi, kullanım zamanlarını, MAC adresini, hedef IP'yi ve NAT'ta tahsis edilen gerçek IP ile portu iki yıl saklamakla yükümlüdür.
**IPv4 ve IPv6'nın birlikte değerlendirilmesi**
: Çift yığınlı (dual-stack) bir cihaz aynı dakikada bir hizmete IPv6, diğerine IPv4 üzerinden bağlanabilir; Happy Eyeballs algoritması (RFC 8305) bağlantıları yarıştırır ve IPv6'yı öne alır. İki platformun farklı adres vermesi bu yüzden tek başına farklı bir kişiye işaret etmez. IPv6 geçici adresleri varsayılan olarak bir gün tercih edilir, iki gün geçerli kalır (RFC 8981).
## IP adresinden kullanıcıya atfın teknik sınırları
Eşleştirme eksiksiz kurulsa bile varılan yer bir aboneliktir. Aboneden kişiye geçişi zayıflatan durumlar:
- **Ortak ağ.** Evdeki herkes, iş yerindeki bütün çalışanlar, misafirler ve parolayı bilen komşu aynı genel IP ile çıkar. Kablosuz ağ parolasızsa çevre de hesaba girer.
- **Wi-Fi'da MAC adresi.** Modem kaydındaki MAC adresi cihazı her zaman göstermez. Apple cihazları her ağ için ayrı bir özel Wi-Fi adresi kullanır; iOS 18'den itibaren seçilebilen dönen adres iki haftada bir değişir.
- **VPN ve proxy.** Logdaki IP bir VPN sunucusuna aitse abonelik sorgusu kullanıcıyı değil VPN hizmetini gösterir.
- **Tor.** Tor, geliştiricileri dahil kimsenin kullanıcıyı izleyemeyeceği biçimde tasarlanmıştır. Bir adresin belirli bir tarihte Tor rölesi olarak çalışıp çalışmadığı ExoneraTor ile kontrol edilebilir.
- **CGNAT, portsuz kayıt ve saat.** Port yoksa operatörün cevabında birden fazla abone yer alabilir; port bloğunun el değiştirdiği anlarda birkaç saniyelik sapma bile sonucu değiştirir.
Yargıtay 17. Ceza Dairesi, suç tarihine ait CGNAT verileri getirtilmeden ve IP'nin sanık tarafından kullanılıp kullanılmadığı kesin ve somut verilerle belirlenmeden kurulan mahkûmiyeti bozmuştur (E.2018/5732, K.2019/7785).
## Kayıtlar nereden gelir, ne kadar süre saklanır?
Operatör ve platform kayıtlarını biz temin etmeyiz; bu kayıtlar mahkeme ya da savcılık eliyle istenir ve usulü avukatınız yürütür. Yargıtay kararlarında CGNAT verilerinin BTK'dan getirtilmesinden söz edilir. 5651 sayılı Kanun kapsamındaki yetkiler ise 31.07.2026'dan itibaren Siber Güvenlik Başkanlığına aittir (7590 s.K.); kaydın hangi kurumdan isteneceği güncel mevzuata göre belirlenir. Saklama süreleri tek bir sayıya bağlanmış değildir:
- Erişim sağlayıcılar trafik bilgisini altı ay ile iki yıl arasında, yönetmelikte belirlenecek süre kadar saklar (5651 m.6/1-b); somut süreyi koyan yönetmelik bendi Danıştay kararıyla iptal edildiğinden bugün uygulanan süre net değildir.
- Yer sağlayıcılar için kanundaki aralık bir ile iki yıldır (5651 m.5/3).
- Elektronik haberleşme mevzuatı trafik verilerinin saklama süresini bir ile iki yıl arasında olmak üzere yönetmeliğe bırakmıştır (5809 m.51/10).
- İnternet toplu kullanım sağlayıcıları erişim kayıtlarını iki yıl saklar.
Olaydan aylar sonra yapılan talepte kayıt artık bulunmayabilir. Hangi IP'nin, hangi portun, hangi zaman aralığı ve saat dilimiyle sorulacağı olayın hemen ardından netleştirilmelidir.
## Hangi materyalle çalışırız, raporda ne yer alır?
İnceleme, taraflarca ya da avukatınızca sağlanan ve hukuka uygun yolla elde edilmiş materyal üzerinde yapılır: platform ve operatör yazılarının özgün PDF ya da UDF hâli, varsa ham log dosyaları, abone tespit yazıları, dosyadaki bilirkişi raporu ve olayın zaman çizelgesi. Kendi sistemlerinizin loglarında toplama yöntemini ve hash değerini de isteriz.
Raporda her adres için adres türü, zincirin hangi halkalarının kayıtla desteklendiği ve hangilerinin varsayıma dayandığı, saat dönüşümleri, alternatif açıklamalar ve incelemenin sınırları yer alır. Rapor uzman görüşü (HMK m.293) ya da bilimsel mütalaa (CMK m.67/6) olarak hazırlanabilir; mahkemeyi bağlamaz ve hukuki nitelendirme içermez. Dosyadaki bir bilirkişi raporunun IP tespitlerini de [bilirkişi raporu değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/) kapsamında teknik yönden inceleyebiliriz.
## Sık sorulan sorular
### IP adresinden kişi tespit edilebilir mi?
Doğrudan hayır. IP adresi, operatör kayıtlarıyla doğru eşleştirildiğinde olay anındaki internet aboneliğini gösterebilir. O aboneliğin ağını kimin kullandığı; cihaz incelemesi, hesap oturum kayıtları ve diğer delillerle ayrıca değerlendirilir. Ayrıntı: [IP adresi tek başına delil mi](https://www.md9.net/bilgi/ip-adresi-delil-mi/).
### CGNAT kaydı nedir, dosyaya nasıl gelir?
CGNAT kaydı, operatörün bir genel IP'yi hangi zaman aralığında, hangi port aralığıyla, hangi aboneye verdiğini gösteren kayıttır. Tipik olarak iç adres, genel IP, port başlangıcı ve bitişi, oturum zamanları ve abone ya da hat bilgisi bulunur. Dosyaya mahkeme ya da savcılık yazısına verilen cevap olarak girer; trafik verisinin gizliliği esas olduğundan (5809 m.51/2) başkasına ait kaydı taraflar doğrudan operatörden alamaz.
### Port bilgisi yoksa IP ile abone bulunabilir mi?
Adres statik ya da CGNAT'sız dinamik bir adresse doğru zamanla tek aboneye ulaşılabilir. CGNAT'lı adreste ise aynı saniyede aynı IP'yi birden fazla abone kullanır ve kaynak port ile doğru zaman olmadan operatör müşteriyi tek başına belirleyemez (RFC 6302). Cevapta tek abone yazılmışsa hangi ölçütle seçildiğini sorarız.
### Aynı IP adresi iki farklı hesapta görünüyorsa hesaplar aynı kişinin mi?
Tek başına hayır. Adres CGNAT'lı bir mobil hatta aitse aynı dakikada onlarca abone o IP'yi paylaşabilir; iş yeri, okul ya da kafe ağı da aynı sonucu verir. Port ve saniye düzeyinde zaman, adresin türü, giriş saatlerinin örüntüsü ve cihaz bilgileri birlikte değerlendirildiğinde ilişki kurulabilir ya da ilişkinin olmadığı görülebilir.
### VPN kullanan birinin IP adresi tespit edilebilir mi?
Hedef sistemin logunda VPN sunucusunun adresi görünür; bu adresin abone sorgusu kullanıcıyı değil VPN hizmetini gösterir. Kullanıcıya ulaşmak için VPN sağlayıcısının bağlantı kaydı gerekir; sağlayıcı kayıt tutmuyor ya da yurt dışında olabilir. Bazen cihaz incelemesinde VPN uygulamasının ve bağlantı zamanlarının izleri bulunur. Sonuç dosyadan dosyaya değişir, önceden söz verilemez.
### Evde ortak Wi-Fi kullanılıyorsa IP adresi kimi gösterir?
Modemin bağlı olduğu aboneliği gösterir. Evdeki bütün cihazlar dışarıya aynı genel IP ile çıkar; bağlantıyı hangi cihazın kurduğu ancak modemin DHCP ve bağlantı kayıtlarından ve cihazların kendi izlerinden anlaşılabilir. Ev modemleri bu kayıtları genellikle kısa süre tutar, bir kısmı yeniden başlatmada siler; modeme dokunmadan önce ekranı belgeleyin.
---
# Adli bilişimde bilgisayar incelemesi: disk, USB ve kullanıcı izleri
URL: https://www.md9.net/adli-bilisim/bilgisayar-inceleme/
Güncelleme: 2026-09-27
Bilgisayar incelemesi, bir bilgisayarın ya da depolama ortamının birebir kopyası (imajı) üzerinde dosya sistemi, kayıt defteri, olay günlüğü ve tarayıcı izlerini okuyarak “bu cihazda ne zaman, hangi hesapla, ne yapıldı” sorusuna teknik cevap arayan adli bilişim çalışmasıdır. md9 bu incelemeyi taraflar için yapar; bulguları, yöntemi ve sınırları yazan bir uzman görüşü ya da teknik rapor hazırlar.
Bir bilgisayarda aynı olay çoğu zaman birkaç yerde iz bırakır: dosya sistemi günlüğünde, kayıt defterinde, bir kısayol dosyasında. İşimiz bu izlerin birbirini tutup tutmadığına bakmaktır; yanlış kurulmuş bir saat ya da sonradan değiştirilmiş bir tarih çoğu zaman bu karşılaştırmada ortaya çıkar.
## Bilgisayar incelemesi hangi sorulara cevap verir?
- Dosya ne zaman oluşturuldu, değiştirildi, açıldı mı?
- İşten ayrılan çalışan belgeleri USB belleğe ya da harici diske aktardı mı?
- Silinmiş klasörde neler vardı, ne zaman silindi?
- Program kuruldu mu, çalıştırıldı mı; hangi hesapla?
- Olay saatinde kim oturum açmıştı, uzak masaüstü bağlantısı var mıydı?
Saldırı ya da zararlı yazılım şüphesinde doğru adres [siber olay incelemesi](https://www.md9.net/adli-bilisim/siber-olay-inceleme/)dir.
## İnceleme için hangi materyal gerekir?
En iyisi cihazın kendisi ya da tam disk imajıdır; seçilmiş klasörlerin kopyası çoğu soruya yetmez.
| Materyal | Ne sağlar | Dikkat |
| Cihazın kendisi (bilgisayar, disk, USB bellek) | İmajı yazma engelleyici (write blocker) üzerinden biz alırız | Seri numarası, fotoğraf, teslim tutanağı |
| Tam disk imajı (E01, raw/dd, AFF4) | Silinmiş alanlar dahil diskin tamamı | Tutanaktaki hash değeri yeniden hesaplanır |
| Ceza dosyasında şüpheliye verilen yedek kopyası | İncelemeye konu verinin aynısı | Tutanak ve hash değerleri de istenir |
| Mantıksal kopya (seçilmiş klasörler) | Hızlı ama dar bir inceleme | Silinmiş veri ve sistem izlerinin çoğu yoktur |
Yalnızca hukuka uygun elde edilmiş materyal incelenir. Başkasının sistemine izinsiz erişim TCK m.243–244 kapsamında suç oluşturabilir; hukuka aykırı elde edilen delil hukuk yargılamasında dikkate alınmaz (HMK m.189/2), ceza yargılamasında reddedilir (CMK m.206/2-a).
Cihazı kendiniz açıp bakmayın
Kapalı bilgisayarı açmak, klasörlerde gezinmek ya da antivirüs taraması çok sayıda zaman damgasını değiştirir; SWGDE de kapalı bilgisayarın açılmamasını önerir. Ayrıntı: [dijital delil nasıl korunur](https://www.md9.net/bilgi/dijital-delil-nasil-korunur/).
## İnceleme adım adım nasıl ilerler?
1. **Kayıt.** Materyalin kimden, ne zaman, hangi durumda alındığı yazılır (delil zinciri).
2. **Edinim ve doğrulama.** NIST SP 800-86'daki sırayla kaynağın özeti (hash) alınır, imajınkiyle karşılaştırılır, kaynak yeniden doğrulanır. Hazır imajda tutanaktaki değer yeniden hesaplanır; tutmazsa inceleme durur.
3. **Ayrıştırma.** Çalışma kopyasından `$MFT`, `$UsnJrnl`, kayıt defteri (registry) dosyaları (`SYSTEM`, `SOFTWARE`, `SAM`, `NTUSER.DAT`, `USRCLASS.DAT`), olay günlükleri ve tarayıcı dosyaları çıkarılır.
4. **Rapor.** Ölçü ACPO'nun üçüncü ilkesi: bağımsız bir üçüncü kişi aynı işlemlerle aynı sonuca ulaşabilmeli.
## HDD, SSD ve USB bellek arasında ne fark var?
Fark en çok silinmiş veride görülür: HDD silinen veriyi üzerine yazılana kadar tutar, SSD ise çoğu zaman kendisi temizler.
| Ortam | Silinmiş veri | Özel durum |
| HDD | Üzerine yazılana kadar içerik kalabilir; dosya oyma (carving) ile parçalar kurtarılabilir | Kısmi üzerine yazma sık görülür | ``
| SSD | TRIM ve çöp toplama sonrasında kurtarma olasılığı düşüktür | Windows'ta TRIM, yönetici kapatmadıkça açıktır (fsutil behavior query DisableDeleteNotify). Yazma engelleyici diskin iç işlemlerini durdurmaz |
| USB bellek, hafıza kartı, harici disk | Ortama ve dosya sistemine bağlı | Çoğu FAT32 ya da exFAT biçimlidir. FAT zamanları yerel saattir; değiştirme zamanı 2 saniye, erişim zamanı yalnızca gün çözünürlüklüdür. exFAT yerel saatin yanına UTC farkını da yazabilir |
Bizce SSD raporlarında şu cümle mutlaka bulunmalı: silinmiş dosyanın bulunamaması, dosyanın hiç var olmadığını göstermez. Bell ve Boddington (2010), SSD'nin komut beklemeden yürüttüğü iç işlemlerle kurtarılabilir veriyi silebildiğini göstermişti.
## Dosya oluşturma, değiştirme ve erişim zamanları nasıl okunur?
NTFS her dosya için dört zaman tutar: değiştirme, erişim, MFT kaydının değişmesi ve oluşturma (MACB). Dörtlü iki öznitelikte tekrarlanır: `$STANDARD_INFORMATION` ($SI) ve `$FILE_NAME` ($FN). Gezgin'deki tarihler $SI'dan gelir ve diskte UTC durur.
- **Kopyalama.** Olağan kopyalamada yeni dosyanın oluşturma zamanı kopyalama anıdır, değiştirme zamanı kaynaktan gelir. “Değiştirilme tarihi oluşturmadan önce” görünen dosya çoğu zaman kopyalanmıştır; bu tek başına sahtecilik belirtisi değildir.
- **Son erişim.** NTFS bu güncellemeyi bir saate kadar erteleyebilir, `NtfsDisableLastAccessUpdate` ile tamamen kapatılabilir. Erişim zamanına dayanan sonuç zayıftır.
- **Zaman damgasıyla oynama (timestomping).** $SI zamanları kullanıcı düzeyindeki araçlarla değiştirilebilir (MITRE ATT&CK T1070.006). $FN ile karşılaştırma ilk kontroldür ama ikisini birden değiştiren yöntemler de var; USN günlüğündeki `USN_REASON_BASIC_INFO_CHANGE` kaydı, LNK dosyaları ve 4616 (sistem saati değişti) olayıyla çapraz kontrol yaparız.
Word ve PDF dosyalarının iç meta verisi ayrı bir kaynaktır: [doküman ve fotoğraf metadata incelemesi](https://www.md9.net/adli-bilisim/metadata-inceleme/).
## Silinen dosyanın izleri nerede kalır?
Silinen dosyanın *varlığı* çoğu zaman tespit edilir; *içeriğin* kurtarılması ortama ve geçen süreye bağlıdır:
- `C:\$Recycle.Bin\\`: `$I` dosyası orijinal yolu, boyutu ve silinme zamanını, `$R` dosyası içeriği tutar. SID, silen hesabı gösterir.
- `$MFT`: Kayıt yeniden kullanılana kadar adı ve zamanları durabilir.
- `$UsnJrnl`: `FILE_DELETE` ve yeniden adlandırma kayıtları. İçerik tutmaz.
- ShellBags, LNK dosyaları ve Jump Lists: artık diskte olmayan klasör ve dosyaların yolunu ve zamanını taşır.
- Gölge kopyalar (Volume Shadow Copies) ve HDD'de ayrılmamış alan.
## Hangi hesabın ne zaman oturum açtığı nasıl anlaşılır?
Hesaplar ve güvenlik kimlikleri (SID) çıkarılır, olay günlüğündeki oturum kayıtları bunlara bağlanır. `SAM` yerel hesapları, `ProfileList` her SID'in profil klasörünü tutar. Hesap yeniden adlandırılınca profil klasörünün adı değişmez; `C:\Users\` altındaki ad yanıltabilir.
| Olay kaydı | Ne gösterir |
| 4624 / 4625 | Başarılı / başarısız oturum açma. Logon Type 2 konsol, 7 kilit açma, 10 uzak masaüstü |
| 4634 / 4647 | Oturum kapanışı; 4624 ile Logon ID üzerinden eşleşir. Logon ID yalnızca o bilgisayarda ve yeniden başlatmaya kadar tekildir |
| 4720, 4616, 1102 | Yeni hesap oluşturuldu; sistem saati değiştirildi; güvenlik günlüğü temizlendi |
Günlükler eksik olabilir: denetim kapalıysa olay yazılmaz, dolan günlük eskinin üzerine yazar. Boşluğu kısmen SRUM veri tabanı (`C:\Windows\System32\SRU\`) kapatır; yaklaşık son 30–60 gün için hangi uygulamanın hangi hesapla çalıştığını saatlik tutar.
## Tarayıcı ve indirme geçmişinden ne çıkar?
Hangi adrese ne zaman gidildiği, hangi dosyanın nereden nereye indirildiği çıkar. Chrome ve Edge geçmişi `History` adlı SQLite dosyasında tutar: `urls` tablosunda adres, `visit_count`, `typed_count`, `last_visit_time`, `visits` tablosunda tek tek ziyaretler. `downloads` tablosu kayıt yolunu (`target_path`), başlangıç ve bitiş zamanını, indirmenin başladığı sayfayı (`tab_url`, `referrer`) ve dosyanın açılıp açılmadığını (`opened`) gösterir. Firefox'ta karşılığı `places.sqlite`'tır.
Tarayıcılar NTFS diske indirilen dosyaya `Zone.Identifier` adlı ek bir veri akışı yazar (`ZoneId=3`: internet). Chrome, Edge ve Firefox çoğu indirmede buraya indirme adresini (`HostUrl`) ve yönlendiren sayfayı (`ReferrerUrl`) da ekler; gizli pencerede eklemeyebilir. Geçmiş temizlense de dosyanın kaynağı buradan anlaşılabilir.
**Örnek:** Chrome'daki `last_visit_time = 13434984000000000` değeri (1601'den beri mikrosaniye) 27.09.2026 12:00:00 UTC'dir, yani Türkiye saatiyle 15:00. [Zaman damgası dönüştürücü](https://www.md9.net/araclar/zaman-damgasi-donusturucu/) ile kendiniz çevirebilirsiniz.
## USB bağlantı geçmişi nasıl çıkarılır?
Beş kaynak birleştirildiğinde “hangi aygıt, ilk ve son ne zaman, kimin oturumunda, hangi sürücü harfiyle” sorusu çoğu zaman cevaplanır:
1. `SYSTEM\CurrentControlSet\Enum\USBSTOR`: üretici, model ve seri numarası. Seri numarasının ikinci karakteri `&` ise aygıt tekil bir seri bildirmiyor olabilir.
2. Aynı kaydın `Properties\{83da6326-97a6-4088-9453-a1923f573b29}` alt anahtarı: `0064` kurulum, `0065` ilk kurulum; Windows 8 ve sonrasında `0066` son bağlanma, `0067` son çıkarma.
3. `C:\Windows\INF\setupapi.dev.log`: ilk kurulum zamanı, yerel saatle. Kayıt defteri UTC tuttuğu için bu unutulursa bugün Türkiye'de üç saatlik sahte bir “çelişki” doğar.
4. `SYSTEM\MountedDevices` sürücü harfini, kullanıcının `NTUSER.DAT` dosyasındaki `MountPoints2` aygıtı hangi hesabın bağladığını gösterir.
5. LNK, Jump Lists ve ShellBags kayıtlarında `E:\` gibi sürücü yolları aranır.
**Örnek:** Bir belleğin 14.05'te takılıp 14.21'de çıkarıldığı, aynı aralıkta `E:\musteri_listesi.xlsx` için bir LNK dosyası oluştuğu görülüyor. Bu, dosyanın o sırada bellekten açıldığını destekler; bellek incelenmeden bilgisayardan belleğe kopyalandığı kesin söylenemez.
## Program kurulum ve kullanım kayıtları neyi gösterir?
Kurulumu, bazen de çalıştırmayı gösterir; ama bazı izler sanıldığından zayıftır:
| İz | Gösterdiği | Sınırı | ``````
| Uninstall anahtarı | Kurulu programlar, sürüm, InstallDate | Windows Installer ürünlerinde InstallDate son güncelleme ya da onarım zamanı olabilir | ``
| Prefetch (C:\Windows\Prefetch\*.pf) | Çalışma sayısı; Windows 8 ve sonrasında son 8 çalışma zamanı | Dosya sayısı sınırlıdır | ``
| Amcache.hve | Yürütülebilir dosyalar, kurulumlar, SHA-1 | ANSSI'nin testlerine göre File anahtarındaki kayıt dosyanın sistemde bulunduğunu gösterir, çalıştırıldığını kanıtlamaz |
| ShimCache (AppCompatCache) | Sistemin gördüğü yürütülebilir dosyalar | Çalıştırılmamış dosyalar için de kayıt olabilir |
| UserAssist, BAM | Hesap bazında başlatılan programlar. UserAssist değer adları ROT-13 ile kodludur | Tek başına zaman çizelgesi kurmaya yetmez |
Yokluktan da sonuç çıkarmayız: Amcache'te görünmeyen bir program çalışmamış olmak zorunda değildir.
## Dijital zaman çizelgesi nasıl kurulur?
Dijital zaman çizelgesi, bütün kaynaklardaki zamanların tek saat dilimine çevrilip aynı eksende sıralanmasıdır. Asıl iş hangi kaynağın UTC, hangisinin yerel saat tuttuğunu bulmak ve cihaz saatini sınamaktır. Türkiye 2016'dan beri sürekli UTC+3'tedir; daha eski kayıtlarda kış saati UTC+2'dir, 25 Ekim–8 Kasım 2015 arasındaki cihaz kayıtlarında bir saat sapma olabilir. Ayrıntı: [zaman damgaları ve saat dilimi](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/).
## Hash değerleri ve delil bütünlüğü nasıl değerlendirilir?
Değerin neye ait olduğuna (disk, bölüm, dosya), algoritmasına ve bizim hesapladığımızla tutup tutmadığına bakarız. Klasik E01 (EWF1) biçimi yalnızca MD5 ve SHA-1 saklar; SHA-256'yı ayrıca hesaplayıp rapora yazarız. Eski imajdaki MD5 tek başına sorun değildir: SWGDE, güvenle kayda geçmiş MD5 ve SHA-1 değerlerini bütünlük doğrulamasında kabul edilebilir görür. Algoritma farkları: [hash değeri ve dijital delil bütünlüğü](https://www.md9.net/bilgi/dijital-delil-butunlugu-hash/). Tek dosyanın değerini [hash hesaplama aracı](https://www.md9.net/araclar/hash-hesaplama/) ile dosyayı yüklemeden alabilirsiniz.
CMK m.134/3 el koyma sırasında sistemdeki bütün verilerin yedeklenmesini, m.134/4 bu yedekten bir kopyanın şüpheliye veya vekiline verilmesini öngörür; kanun “hash” kelimesini kullanmaz. Yargıtay 8. Ceza Dairesi usulünce imaj alınıp hash değerlerinin tespit edilmemesini beraat gerekçeleri arasında saymış (E.2012/21817, K.2013/25428); 4. Ceza Dairesi inceleme ve imaj kararı ile yedeğin verildiğine dair tutanak bulunmayan dosyada delilleri delil değerlendirme yasağı kapsamında görmüştür (E.2021/16706, K.2021/23109). CMK m.134, Anayasa Mahkemesinin 12.02.2026 tarihli, E.2023/128, K.2026/36 sayılı kararıyla iptal edilmiştir (RG 25.05.2026); iptal 25.02.2027'de yürürlüğe girecektir ve yeni düzenleme takip edilmelidir.
## Raporda neler yer alır?
Raporumuz taraflardan birinin talebiyle hazırlanan bir uzman görüşü (HMK m.293) ya da bilimsel mütalaadır (CMK m.67/6). Mahkemeyi bağlamaz; hâkim onu diğer delillerle birlikte değerlendirir ve hazırlayan uzmanın duruşmada dinlenmesine karar verebilir (HMK m.293/2; CMK m.68/3). Hukuk davasında çağrılan uzman geçerli özrü olmadan gelmezse rapor değerlendirilmez (HMK m.293/3). İçerik:
- Kapsam ve cevaplanan teknik sorular
- Materyal listesi, hash değerleri, teslim zinciri
- Yöntem: araçlar, sürümleri, yapılan işlemler
- Bulgular: kaynak iz, ham değer ve dönüştürülmüş zaman
- Zaman çizelgesi ve sınırlılıklar
- Teknik dille sonuç; “suç oluşmuştur” gibi hukuki nitelendirme yapılmaz
Dosyadaki bilirkişi raporunu da aynı başlıklarla okuruz: [bilirkişi raporlarının teknik değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/).
## Sık sorulan sorular
### Silinen dosyalar geri getirilebilir mi?
Ortama bağlıdır. Sabit diskte (HDD) silinen dosyanın içeriği üzerine yazılana kadar kalır ve çoğu zaman kısmen ya da tamamen kurtarılır. SSD'de TRIM ve çöp toplama nedeniyle içerik genellikle geri gelmez. Dosyanın adı, yolu ve silinme zamanı ise iki ortamda da Geri Dönüşüm Kutusu kayıtlarından, $MFT'den ya da USN günlüğünden çoğu zaman bulunur.
### USB belleğe dosya kopyalandığı tespit edilebilir mi?
Bilgisayardaki kayıtlar hangi belleğin ne zaman takılıp çıkarıldığını ve hangi hesabın oturumunda bağlandığını çoğu zaman gösterir; kopyalanan dosyayı doğrudan göstermez. Kopyalama iddiası için belleğin kendisi ya da o sürücüdeki dosyalara açılmış kısayollar (LNK, Jump Lists) ve dosya sistemi kayıtları birlikte incelenir. Bellek yoksa sonuç çoğu zaman “destekler” düzeyinde kalır.
### Formatlanan diskten veri kurtarılır mı?
Türüne ve ortama bağlıdır. Hızlı biçimlendirme (quick format) dosya sistemini yeniden kurar, verinin çoğunu yerinde bırakır; sabit diskte bu veri çoğu zaman kurtarılır. Microsoft'a göre Windows Vista ve sonrasında tam biçimlendirme varsayılan olarak diskin tamamına sıfır yazar; bu durumda içerik geri gelmez. SSD'de Windows biçimlendirme sırasında TRIM de gönderdiği için sonuç çoğu zaman olumsuzdur.
### Dosyanın oluşturma tarihi sonradan değiştirilebilir mi?
Evet. Windows Gezgini'nde görünen tarihler ($STANDARD_INFORMATION) sıradan araçlarla değiştirilebilir. Bu yüzden Gezgin'deki tarihi $FILE_NAME zamanları, USN günlüğü, kısayol dosyaları ve olay günlükleriyle karşılaştırırız; tutarsızlık gerekçesiyle rapora yazılır. Tutarsızlık bulunmaması tarihin doğru olduğunu kanıtlamaz, yalnızca incelenen izlerle çelişmediğini gösterir.
### Şirket bilgisayarı, çalışanla ilgili bir iddia için incelenebilir mi?
Teknik açıdan mümkündür. Hukuka uygunluğu ise şirket politikasına, çalışanın bilgilendirilmesine ve kişisel verilerin korunması kurallarına bağlıdır; bunu avukatınızla değerlendirin. Başlamadan önce materyalin nasıl ve hangi yetkiyle elde edildiğini yazılı isteriz, incelemeyi de sorulan teknik soruyla sınırlı tutarız.
---
# Telefon ve mobil uygulama incelemesi: iOS ve Android
URL: https://www.md9.net/adli-bilisim/mobil-cihaz-inceleme/
Güncelleme: 2026-09-27
Mobil cihaz incelemesi, bir telefonun yedeğinden ya da dosya sistemi kopyasından uygulama veri tabanlarını, önbellekleri, bildirim ve kullanım kayıtlarını çıkarıp bir mesajın, aramanın ya da uygulama işleminin ne zaman ve nasıl gerçekleştiğini teknik olarak değerlendiren çalışmadır. Neyin görülebileceğini cihaz modeli, işletim sistemi sürümü, kilit durumu ve edinim yöntemi belirler; md9 önce bunu netleştirir, sonra uzman görüşü veya teknik rapor hazırlar.
Telefon incelemesi iki soruya hizmet eder. Cihaz tarafında: mesaj ne zaman gönderildi ya da silindi, olay saatinde hangi uygulama açıktı? Uygulama tarafında: uygulama hangi veriyi nerede saklıyor, sunucuya ne gönderiyor, hangi izinleri kullanıyor? Soru bir hesabın kime ait olduğu ya da nasıl ele geçirildiğiyse başlangıç noktası [sosyal medya ve platform incelemesi](https://www.md9.net/adli-bilisim/sosyal-medya-inceleme/)dir.
## Telefondan hangi yöntemle ne kadar veri alınabilir?
Edinim yöntemi, incelemenin neyi görebileceğini baştan belirler. NIST SP 800-101 Rev.1 araçları manuel çıkarımdan bellek yongasının okunmasına kadar beş seviyede sınıflandırır; uygulamada şu ayrım kullanılır:
| Edinim | Ne verir | Neyi vermez |
| Manuel (ekranın fotoğraflanması) | Ekranda görüneni | Silinmiş veri, veri tabanı alanları, meta veri | ****``````
| Yedek / mantıksal (iPhone yedeği, Android ADB yedeği) | Uygulama belgeleri, ayarlar, çoğu mesajlaşma veri tabanı. iPhone'un şifreli yedeği ayrıca kayıtlı parolaları, Wi-Fi ayarlarını, web geçmişini, Sağlık verilerini ve çağrı geçmişini içerir | iOS'ta uygulamaların Library/Caches ve tmp klasörleri yedeğe girmez. Android 12 ve üstünü hedefleyen uygulamaların verisi adb backup çıktısında yoktur |
| Tam dosya sistemi (FFS) | Uygulama kapsayıcılarının tamamı, sistem veri tabanları, kullanım kayıtları | Cihaza, sürüme ve araca bağlıdır; her modelde mümkün değildir |
| Fiziksel (bellek görüntüsü, chip-off) | Ham bellek içeriği | Modern cihazlarda veri şifreli olduğundan anahtarlar olmadan çoğu zaman okunamaz |
Kilit durumu da belirleyicidir. iPhone'da üçüncü taraf uygulama verisinin varsayılan koruma sınıfı, cihaz yeniden başlatıldıktan sonra ilk kilit açılana kadar (BFU) veriyi erişilemez tutar; ilk kilit açılışından sonra (AFU) veri erişilebilir olur. iOS 18 ile gelen hareketsizlik yeniden başlatması, uzun süre kilitli kalan cihazı kendiliğinden BFU durumuna döndürür; süre iOS 18.1'de 72 saat olarak raporlanmıştır. Android 10 ve sonrasıyla çıkan cihazlarda dosya tabanlı şifreleme (FBE) kullanılır ve uygulama verisinin durduğu “Credential Encrypted” alan kilit açılmadan okunamaz. Bu yüzden el koyma ile edinim arasındaki süreyi ve cihazın o aradaki durumunu kayda geçiririz.
Telefon incelemeye gidene kadar
Cihazı sıfırlamayın, güncellemeyin, ilgili uygulamayı silmeyin: Android'de uygulama kaldırılınca uygulamaya özel dosyalar da silinir. Uygulamayı kullanmaya devam etmek silinmiş kayıtların izini yok edebilir. Uçak modu ya da kapatma uzaktan silme riskini azaltır, ama kapatmak cihazı BFU durumuna sokar.
Ceza dosyalarında incelediğimiz materyal çoğu zaman CMK m.134/4 gereği şüpheliye veya vekiline verilen yedek kopyası ve ona eşlik eden çıkarım raporudur. CMK m.134, Anayasa Mahkemesinin 12.02.2026 tarihli, E.2023/128, K.2026/36 sayılı kararıyla iptal edilmiştir (RG 25.05.2026); iptal 25.02.2027'de yürürlüğe girecektir ve yeni düzenleme takip edilmelidir. Başkasına ait bir telefona erişim yöntemi sunmayız: izinsiz erişim TCK m.243–244 kapsamında suç oluşturabilir, hukuka aykırı elde edilen delil de kullanılamaz (Anayasa m.38; HMK m.189/2).
## Uygulama verisi nerede ve hangi biçimde tutulur?
Her uygulama kendi korumalı alanında (sandbox) çalışır ve verisini oraya yazar:
| Platform | Konum | Tipik içerik | ``````````
| Android | /data/data// | databases/ (SQLite), shared_prefs/ (XML ayarlar), files/, cache/. Dizine yalnızca uygulamanın kendi kullanıcı kimliği (UID) erişebilir | ``````````
| iOS | /private/var/mobile/Containers/Data/Application// | Documents, Library (plist ayar dosyaları dahil), Library/Caches, tmp | ``
| iOS, paylaşımlı alan | /private/var/mobile/Containers/Shared/AppGroup// | Aynı geliştiricinin uygulamaları ve uzantıları arasında paylaşılan veri; WhatsApp'ın iOS veri tabanı buradadır |
iOS'ta klasör adlarındaki UUID'ler rastgeledir; klasörün hangi uygulamaya ait olduğu kapsayıcıdaki meta veriden çıkarılır. Veri çoğunlukla SQLite veri tabanlarında, yanında plist, XML, JSON ve protobuf dosyalarında durur.
### SQLite kayıtları: WAL dosyası ve silinmiş kayıtların sınırı
- **WAL (write-ahead log).** WAL modunda değişiklikler önce ana dosyanın yanındaki `-wal` dosyasına eklenir; varsayılan ayarda WAL 1000 sayfaya ulaşınca ana dosyaya aktarılır (checkpoint). Son bağlantı kapanırken son bir checkpoint yapılır ve `-wal` ile `-shm` dosyaları silinir. Bu yüzden `.db`, `-wal` ve `-shm` üçlüsünü birlikte kopyalar, orijinali hiçbir araçla açmayız. Checkpoint öncesi yakalanan bir WAL, değiştirilmiş ya da silinmiş kaydın önceki hâlini taşıyabilir.
- **Silinmiş kayıtlar.** SQLite'ın `secure_delete` ayarı genellikle kapalıdır; silinen satırların içeriği serbest sayfalarda (freelist) ve sayfa içi boş alanda bir süre kalabilir. Uygulama silmeden sonra `VACUUM` çalıştırıyorsa bu izler de gider.
Bir adli yazılım üreticisinin WhatsApp testinde Android'de silinen mesajların çoğu WAL'den kurtarılmış, test edilen iOS örneğinde ise silinmiş kayıt izi bulunamamıştır. Bu yüzden “silinen mesajlar geri gelir” diye söz vermeyiz.
### WhatsApp veri tabanı incelemesi
Android'de mesajlar `/data/data/com.whatsapp/databases/msgstore.db`, kişiler `wa.db` içindedir; harici depolamadaki yerel yedekler şifrelidir (`msgstore.db.crypt*`). iPhone'da mesajlar App Group kapsayıcısındaki `ChatStorage.sqlite` dosyasının `ZWAMESSAGE` tablosunda, ekler `ZWAMEDIAITEM` tablosunda tutulur. Uçtan uca şifreli bulut yedeği açıksa yedeği ne WhatsApp ne bulut sağlayıcısı okuyabilir; kullanıcının parolası ya da 64 haneli anahtarı gerekir. Yazışmaların delil değeri ve dışa aktarmanın eksikleri: [WhatsApp yazışmaları delil olur mu](https://www.md9.net/bilgi/whatsapp-yazismalari-delil/).
## Önbellek, bildirim ve günlük kayıtları ne gösterir?
**Uygulama önbellekleri.** Uygulamalar görselleri, küçük resimleri ve sunucu yanıtlarını hız için önbelleğe yazar; sohbetten silinmiş bir görselin küçük resmi burada kalmış olabilir. Android depolama azaldığında önbellek dosyalarını kendiliğinden silebilir. iOS'ta `Library/Caches` yedeğe girmediği için önbelleğe ancak tam dosya sistemi ediniminde ulaşılır.
**Bildirim kayıtları.** Android'de bildirim geçmişi varsayılan olarak kapalıdır. Kullanıcı açtıysa son 24 saatin bildirimlerini `/data/system_ce//notification_history/` altında, kilit açılmadan okunamayan alanda tutar. Silinmiş bir mesajın bildirim metni burada görülebilir, ama kayıt kısa ömürlüdür. iOS'taki karşılığının yeri ve biçimi sürüme göre değiştiği için her incelemede ayrıca doğrulanır.
**Kullanım kayıtları (iOS).** `knowledgeC.db`, hangi uygulamanın ekranda olduğunu (`/app/inFocus`) ve cihazın kilitli olup olmadığını (`/device/isLocked`) yaklaşık dört hafta tutar; iOS 16'dan itibaren bu akışların önemli kısmı Biome'a taşınmıştır. İkisine de yalnızca tam dosya sistemi ediniminde ulaşılır.
**Mobil uygulama günlükleri.** Android'in sistem günlüğü (logcat), `logd` sürecinin tuttuğu dairesel tamponlardan (`main`, `system`, `crash`, `radio`, `events`) oluşur; yeni kayıt eskisinin yerini aldığı için kısa ömürlüdür. iOS'un birleşik günlüğünde (unified logging) geliştirici aksini belirtmedikçe dinamik metin `` olarak gizlenir. Birçok uygulama ayrıca kendi günlük dosyasını yazar. Uygulamanın sunucu tarafındaki kayıtları ise [log analizi](https://www.md9.net/adli-bilisim/log-analizi/) kapsamında incelenir.
## Uygulama tarafı: API trafiği, izinler ve güvenlik
Bir uygulamanın ne yaptığı bazen uyuşmazlığın kendisidir: teslim edilen uygulama sözleşmedeki işlevi yerine getiriyor mu, kullanıcı verisini üçüncü taraflara gönderiyor mu, bir sızıntı uygulamadaki bir açıktan mı kaynaklandı?
1. **API trafiği.** Uygulama test cihazında, araya konulan bir vekil sunucu (proxy) üzerinden çalıştırılır; hangi uç noktaya hangi alanlarla istek gittiği kaydedilir. Android 7.0 (API düzeyi 24) ve üstünü hedefleyen uygulamalar, açıkça izin vermedikçe kullanıcının yüklediği sertifikalara güvenmez; sertifika sabitleme (pinning) kullanan uygulamada trafik bu yolla görünmeyebilir. Bu çalışmayı yalnızca yetkili kapsamda yaparız: uygulama sahibinin ya da cihaz ve hesap sahibinin yazılı onayıyla veya mahkeme kararıyla.
2. **İzinler.** Android'de izinler, kurulumda verilenler ve Android 6.0'dan beri çalışma sırasında kullanıcıdan istenen “tehlikeli” izinler (konum, kamera, rehber) olarak ayrılır. Bildirilen izinleri kullanıcının verdikleriyle ve uygulamanın gerçekte yaptığı işle karşılaştırırız. İstenen ama hiç kullanılmayan bir izin de kendi başına bir bulgudur.
3. **Güvenlik değerlendirmesi.** OWASP'ın mobil uygulama güvenlik standardı MASVS'nin başlıklarını (depolama, kriptografi, kimlik doğrulama, ağ, platform, kod, dayanıklılık, gizlilik) ve test rehberi MASTG'yi çerçeve alırız. Tipik sorular: oturum anahtarı `shared_prefs` içinde düz metin mi duruyor, hassas veri önbelleğe ya da günlüklere düşüyor mu?
Bu değerlendirme bir sertifika değildir; belirli bir sürümde belirli sorulara verilen teknik cevaptır. Kaynak kod da konuysa çalışma [kaynak kod incelemesi](https://www.md9.net/adli-bilisim/yazilim-kaynak-kod-inceleme/) ile birlikte yürür.
## Cihaz ve uygulama kayıtlarının korelasyonu
Korelasyon, bir olayın farklı kaynaklardaki izlerini aynı zaman eksenine oturtup birbirini doğrulayıp doğrulamadığına bakmaktır. Aynı dakikada uygulamanın ekranda olduğu, bildirimin düştüğü ve operatör kaydında veri oturumu bulunduğu görülürse bulgu güçlenir.
En sık hata zaman biriminde yapılır: aynı telefonda bir alan saniye, diğeri milisaniye, bir başkası mikrosaniye tutabilir. iOS uygulamaları sıklıkla 2001-01-01 başlangıçlı Mac Absolute Time, Android uygulamaları çoğunlukla milisaniye cinsinden Unix zamanı kullanır. Birimi değerin büyüklüğünden tahmin etmek yetmez; bilinen bir test kaydıyla doğrularız.
**Örnek:** Gönderenin Android telefonundaki mesaj satırında `1790510400000` (milisaniye, Unix), alıcının iPhone'undaki kayıtta `812203200` (saniye, Mac Absolute Time) görülüyor. İkisi de 27.09.2026 12:00:00 UTC'ye, yani Türkiye saatiyle 15:00'e karşılık gelir; [zaman damgası dönüştürücü](https://www.md9.net/araclar/zaman-damgasi-donusturucu/) ile kendiniz çevirebilirsiniz. Operatör kayıtlarıyla karşılaştırma gerekiyorsa [HTS kayıt analizi](https://www.md9.net/adli-bilisim/hts-analizi/) ile birlikte çalışırız.
## Mobil uygulama geliştirme deneyimi incelemeye ne katar?
md9, iPhone için [UDF Mobil (md9)](https://www.md9.net/udfmobil/tr/) uygulamasını geliştirdi. UYAP'ın kullandığı UDF biçimindeki belgeleri açan, düzenleyen ve dönüştüren bu bağımsız uygulama, belgeleri yalnızca cihazda işler ve UYAP'a bağlanmaz. Bir uygulamayı yazıp yayına hazırlamak, inceleme tarafında şu ayrıntıları görmemizi kolaylaştırıyor:
- Verinin neden `Documents`, `Library/Caches` ya da `tmp` altına yazıldığı ve bunun yedeğe girip girmemeyi nasıl etkilediği.
- Bir zaman alanının kullanıcının işlem anı mı, senkronizasyon ya da son güncelleme anı mı olduğu. Alan adının “created” ile başlaması, kullanıcının o anda bir şey yaptığını göstermez.
- Güncellemelerin şemayı değiştirebildiği; yorumu aynı sürümü kurduğumuz test cihazında doğrulamamızın nedeni bu.
- Belgeyi sunucuya göndermeyen bir uygulamada cevabın sunucuda değil cihazda aranması gerektiği.
Bunu yeterlilik iddiası olarak değil, yöntemin parçası olarak görüyoruz: bir uygulama davranışı hakkında rapora cümle yazmadan önce onu mümkünse test ortamında yeniden üretiriz.
## Rapor neleri içerir, neleri söyleyemez?
Uzman görüşü (HMK m.293) veya bilimsel mütalaa (CMK m.67/6) olarak hazırladığımız rapor; cihaz ve sistem sürümünü, edinim yöntemini, araç sürümlerini, incelenen dosyaların hash değerlerini, ham değerleriyle bulguları, zaman çizelgesini ve sınırlılıkları içerir. Görüşümüz mahkemeyi bağlamaz; hukuki değerlendirme avukata ve mahkemeye aittir. Sınırlılıklar bölümüne sık yazdığımız cümleler:
- Mesajın bu cihazdan gönderildiği gösterilebilir; cihazı o anda kimin tuttuğu bu veriden tek başına çıkmaz.
- Silinmiş kaydın bulunamaması, kaydın hiç var olmadığını göstermez.
- Uçtan uca şifreli bir uygulamada mesaj içeriği uç cihazlardadır; platformdan içerik beklenmemelidir.
- Bulgular incelenen uygulama sürümü için geçerlidir.
Dosyadaki bir telefon inceleme raporunun değerlendirilmesi isteniyorsa aynı başlıklar üzerinden gideriz: [bilirkişi raporlarının teknik değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/).
## Sık sorulan sorular
### Silinen WhatsApp mesajları geri getirilebilir mi?
Bazen. Android'de silinen mesajların izi veri tabanının WAL dosyasında ya da serbest sayfalarında bir süre kalabilir; iPhone üzerinde yapılan bir testte bu iz bulunamamıştır. Sonuç cihaza, işletim sistemi ve uygulama sürümüne, geçen süreye ve edinim yöntemine bağlıdır. Parolası bilinen uçtan uca şifreli bir bulut yedeği de ayrı bir kaynaktır. Gerçekçi cevabı ön incelemeden sonra veririz.
### Telefon incelemesi için cihazı teslim etmek şart mı?
Her zaman değil. Ceza dosyasında size verilmiş bir edinim kopyası veya çıkarım raporu, iPhone'un şifreli yedeği ya da uygulamanın dışa aktarımı ile de çalışılabilir. Ancak her biri farklı miktarda veri içerir: iPhone yedeğinde uygulama önbellekleri, dışa aktarmada silinmiş kayıtlar yoktur. Sorunuza hangi materyalin yeteceğini ilk yazışmada söyleriz.
### Şifresini bilmediğimiz bir telefon incelenebilir mi?
Şifre kırma ya da kilit atlatma hizmeti vermiyoruz. Modern iPhone ve Android cihazlarda veri kilit açılmadan şifreli kalır; kilit durumu elde edilebilecek veriyi doğrudan sınırlar. Yargı sürecinde yetkili makamlarca yapılmış bir edinim varsa onun çıktısını inceleyebiliriz. Kendi cihazınızsa verinin yedek ya da hesap dışa aktarımı gibi başka bir kaynaktan alınıp alınamayacağına birlikte bakarız.
### iPhone yedeği ile tam dosya sistemi incelemesi arasındaki fark nedir?
Yedek, Apple'ın yedekleme mekanizmasının kopyaladığı veridir: uygulama belgeleri, ayarlar ve çoğu mesajlaşma veri tabanı. Uygulamaların `Library/Caches` ve `tmp` klasörleri ile knowledgeC ve Biome gibi kullanım kayıtları yedekte yoktur; bunlar için tam dosya sistemi edinimi gerekir ve bu her cihazda mümkün değildir.
### Bir uygulamanın kişisel veri gönderip göndermediği tespit edilebilir mi?
Yetkili bir kapsamda çoğu zaman evet. Uygulama test cihazında çalıştırılır ve sunucuyla alışverişi bir vekil sunucu (proxy) üzerinden kaydedilir; hangi alanın hangi adrese gittiği görülür. Sertifika sabitleme kullanan uygulamalarda trafik bu yolla görünmeyebilir; o zaman uygulama dosyaları ve varsa kaynak kod incelenir. Verinin sunucuda ne olduğu ise ancak sunucu kayıtlarıyla anlaşılır.
### Ekran görüntüsü varken neden telefon incelemesi isteniyor?
Ekran görüntüsü bir anın resmidir: kolay düzenlenir, mesajın ait olduğu sohbeti, gönderen hesabı ve zamanın cihazdaki kaydını göstermez. Cihaz incelemesinde mesaj, veri tabanındaki satırı, zaman alanı ve bağlı kayıtlarıyla birlikte ele alınır; incelenen dosyanın hash değeri rapora yazılır. Ekran görüntüsünün zayıf yanlarını [ekran görüntüsü delil olur mu](https://www.md9.net/bilgi/ekran-goruntusu-delil/) yazısında anlattık.
---
# Web sitesi ve web uygulaması incelemesi
URL: https://www.md9.net/adli-bilisim/web-sitesi-inceleme/
Güncelleme: 2026-09-27
Web sitesi incelemesi, bir internet sitesinin belirli bir tarihte ne yayımladığını, hangi altyapıda çalıştığını ve sitede yapıldığı söylenen bir işlemin (üyelik, sipariş, içerik değişikliği, giriş) sunucu, uygulama ve veri tabanı kayıtlarıyla doğrulanıp doğrulanamadığını ortaya koyan teknik incelemedir. Dışarıdan görülen izlerle sitenin içinden alınan kayıtları önce ayrı ayrı, sonra birlikte değerlendiririz.
## Web sitesi incelemesi hangi sorulara cevap verir?
İnceleme, kayıtlarla cevaplanabilecek bir teknik soruyla başlar. En sık gelenler:
- **İçerik:** Bu metin, bu fiyat ya da bu kampanya koşulu iddia edilen tarihte yayında mıydı, ne zaman değişti?
- **Altyapı:** Alan adı ne zaman alındı, site nerede barındırılıyor?
- **İşlem:** Üyelik, sipariş, onay kutusu ya da parola değişikliği gerçekten o hesaptan mı yapıldı?
- **Yönetim:** Panelden bir içeriği kim düzenledi, kim sildi?
- **Güvenlik:** İddia edilen yetkisiz erişim, sitenin o tarihteki sürümünde mümkün müydü?
## Dışarıdan görülen izler, içeriden alınan kayıtlar
Kayıtların bir kısmı herkese açıktır, bir kısmı yalnızca siteyi işleten tarafta bulunur. Site karşı taraftaysa ikinci grup ancak site işleteninden ya da mahkeme eliyle temin edilir.
| Kaynak | Erişim | Ne gösterir | Ne göstermez |
| Alan adı kaydı (RDAP/WHOIS) | Herkese açık | Kayıt, son değişiklik ve bitiş tarihleri; kayıt kuruluşu | Kayıt sahibini (çoğu zaman gizli); silinip yeniden alınmış alanın önceki sahiplerini |
| DNS ve pasif DNS | Herkese açık / ticari | Alan adının hangi IP'lere ve e-posta sunucularına yönlendiği, ilk ve son görülme | Yapılandırmanın gerçek tarihini |
| Sertifika kayıtları (CT) | Herkese açık | Alan ve alt alan adları için sertifikanın verildiği an | Sitenin içeriğini ve sahibini |
| Web arşivleri, canlı edinim | Herkese açık | Sayfanın geçmişteki yaklaşık ve bugünkü görünümü | Giriş gerektiren içeriği |
| Web sunucusu erişim logları | Site işleteni | Hangi adresten, hangi URL'ye, ne zaman, hangi yöntemle istek geldiği | Form içeriğini (varsayılan ayarda); CDN arkasındaki gerçek istemciyi (ayar yoksa) |
| Uygulama, oturum ve panel kayıtları | Site işleteni | Girişler, oturumlar, API çağrıları, içerik revizyonları | Uygulamanın hiç kaydetmediği olayları |
| Veri tabanı, yedekler, kaynak kod | Site işleteni | Kaydın kendisi, önceki hâlleri, çalışan kod | Dağıtım geçmişi olmadan, hangi sürümün yayında olduğunu |
## Alan adı, barındırma ve sertifika kayıtları ne gösterir?
Bu kayıtlar, bir sitenin en geç hangi tarihte kurulduğunu ve hangi altyapıda çalıştığını, siteyi işletenden bağımsız olarak gösterir. Sahte bir alışveriş sitesini tarihlemek için ilk bunlara bakarız.
ICANN, 28 Ocak 2025'ten itibaren genel uzantılı (gTLD) alan adlarında kayıt verisinin yetkili kaynağı olarak WHOIS yerine RDAP'ı esas aldı. RDAP yanıtındaki `events` dizisi, `eventAction` değerleriyle (`registration`, `last changed`, `expiration`) alan adının tarih çizelgesini verir. `.tr` alan adlarını 14 Eylül 2022'den beri BTK bünyesindeki TRABİS yönetir. Kayıt tarihi, alan adının *mevcut* kaydının tarihidir; süresi dolup yeniden alınmış bir alanda önceki sahiplik görünmez.
Certificate Transparency (RFC 6962), TLS sertifikalarının herkese açık ve yalnızca ekleme yapılabilen (append-only) loglara yazılmasını sağlar; crt.sh gibi arayüzlerle sorgulanır. Bir alt alan adı için verilmiş ilk sertifika, o adın en geç o tarihte kullanıma hazırlandığına dair güçlü ve bağımsız bir işarettir. Pasif DNS ise sensörlerin gördüğü sorgulardan oluşan bir gözlemdir; "ilk görülme" tarihi yapılandırmanın en geç o gün yapıldığını söyler, kesin tarihini değil.
Barındırma (hosting) tarafında IP adresinin hangi ağa ve firmaya ait olduğu, IP kayıt kuruluşlarının (Türkiye için RIPE NCC) kayıtlarından anlaşılır. Paylaşımlı barındırmada aynı IP adresinde çok sayıda site bulunabilir. Site bir CDN'in arkasındaysa görünen adres CDN'e aittir; asıl sunucu (origin) ancak eski DNS kayıtları gibi dolaylı izlerle bulunabilir, bazen hiç bulunamaz. `Server` ve `X-Powered-By` yanıt başlıkları sunucu yazılımına dair bir beyandır, gizlenebilir. MX ve SPF kayıtları e-postayı hangi hizmetin taşıdığını gösterir; konu sahte e-postaya uzanıyorsa [e-posta incelemesiyle](https://www.md9.net/adli-bilisim/e-posta-inceleme/) birleşir.
## Sitenin belirli bir tarihteki hâli nasıl tespit edilir?
Yayındaki içerik bugün birkaç yolla kayda alınabilir; değişmiş içeriğe ise ancak arşivler ve sitenin kendi kayıtları üzerinden bakılabilir.
| Yol | Ne sağlar | Sınırı |
| Ekran görüntüsü | Ekranda görüneni | Kolayca üretilir veya düzenlenir; URL, sunucu yanıtı ve zaman bilgisi taşımaz |
| Noter e-Tespit (TNB) | 1512 sayılı Noterlik Kanunu m.198/A kapsamında 01.03.2016'dan beri sunulan hizmet; oturum başına en fazla 10 ekran görüntüsü ve 1 dosya indirmesi (azami 5 MB) noter sisteminde kayda geçer | Ekranda görüneni belgeler; HTML kaynağı ve HTTP başlıkları için teknik edinimle tamamlanır |
| Mahkeme eliyle delil tespiti | Dava öncesinde keşif ve bilirkişi incelemesi (HMK m.400) | Mahkeme kararı gerektirir, zaman alabilir |
| Teknik edinim | HTML kaynağı, HTTP yanıt başlıkları, ekran kaydı, indirilen dosyalar ve SHA-256 değerleri; istenirse nitelikli zaman damgası (RFC 3161) | Sitenin veya hesabın kime ait olduğunu tek başına göstermez |
| Web arşivleri | Geçmiş tarihli görünüm | Yeniden kurgudur, bileşenler farklı anlarda arşivlenmiş olabilir; archive.today kayıtlarında içerik değiştirildiği tespit edildi |
Bizce yayındaki bir içerik için en sağlam sonuç, e-Tespit ile teknik edinimin aynı gün yapılmasıyla alınır: biri ekranda görüneni, diğeri onun arkasındaki teknik veriyi kayda geçirir. Tespitin hukuki değerini avukatınız ve mahkeme değerlendirir. Ekran görüntüsünün zayıflıklarını [ekran görüntüsünün delil değeri](https://www.md9.net/bilgi/ekran-goruntusu-delil/) yazımızda anlattık.
İçerik değişmişse ve site incelemeyi isteyen tarafa aitse, sitenin kendi kayıtları arşivlerden daha güçlüdür. WordPress, yazı ve sayfaların önceki hâllerini `wp_posts` tablosunda `post_type` değeri `revision` olan satırlar olarak saklar; `wp-config.php` içindeki `WP_POST_REVISIONS` sabitiyle bu sayı sınırlanmış ya da kapatılmış olabilir. Revizyonlar varsayılan olarak başlık, içerik ve özet gibi alanları izler; bir eklentinin özel alanında tutulan değerin (fiyat, stok) eski hâli revizyonda bulunmayabilir. O zaman yedeklere ve sürüm kontrol geçmişine döneriz.
## Erişim logları, oturumlar ve API çağrıları
Sunucu tarafı kayıtlar, sitede kimin ne yaptığına en yakın kanıttır; ama her kayıt yalnızca yapılandırıldığı kadarını tutar. Bu yüzden log dosyasından önce sunucunun log ayarlarını okuruz.
- Apache'nin combined biçimindeki `%r` alanı yalnızca istek satırıdır (yöntem, yol, sorgu dizesi, protokol). Bir `POST` isteğinde hangi adrese form gönderildiği görülür, forma ne yazıldığı görülmez.
- Site bir CDN veya ters vekil sunucunun arkasındaysa `%h` ya da Nginx'teki `$remote_addr` vekilin adresini gösterebilir. `X-Forwarded-For` başlığının güvenilir vekilin eklemediği kısımları sahte olabilir.
- Varsayılan log biçimleri istemcinin kaynak portunu yazmaz; oysa CGNAT arkasındaki kullanıcıyı eşleştirmek için port ve saniye hassasiyetli zaman gerekir ([IP ve CGNAT analizi](https://www.md9.net/adli-bilisim/ip-cgnat-analizi/)).
- Nginx'in `$time_local` alanı sunucunun yerel saatidir. Kaynaklar karşılaştırılmadan önce hepsi UTC'ye çevrilir.
Oturum kayıtları uygulamanın yapısına göre değişir. WordPress açık oturumları `wp_usermeta` tablosunda `session_tokens` anahtarıyla tutar; her oturum için giriş zamanı (`login`), IP adresi (`ip`), tarayıcı bilgisi (`ua`) ve bitiş zamanı (`expiration`) yazılır. Bu kayıt geçmişin değil o anın fotoğrafıdır: çıkış yapılan ya da süresi dolan oturumlar listeden düşer. JWT gibi sunucuda saklanmayan token'larla çalışan API'lerde ise oturum tablosu hiç olmayabilir; token'ın ne zaman hangi hesaba verildiği yalnızca kimlik doğrulama logunda görünür. Yönetici paneli işlemlerinin ayrı bir etkinlik günlüğü, yaygın içerik yönetim sistemlerinde çoğu zaman ancak bir eklentiyle tutulur; yoksa panel işlemleri erişim logu ve revizyonlardan yeniden kurulur.
API çağrılarında en değerli alan istek kimliğidir (ör. `X-Request-ID`). Aynı değer ters vekilde, uygulama logunda ve hata kaydında geçiyorsa tek bir isteği katmanlar boyunca izleyebiliriz. Site ile mobil uygulama çoğu zaman aynı API'yi kullanır; çağrının hangi istemciden geldiği User-Agent ve sürüm başlıklarından anlaşılır, ama bu alanlar istemcinin beyanıdır.
Saklama süresi ayrı bir sorudur. 5651 sayılı Kanun m.5/3, yer sağlayıcının (barındırma firmasının) trafik bilgisini bir ile iki yıl arasında yönetmelikte belirlenecek süre kadar saklamasını öngörür; 2007 tarihli Usul ve Esaslar Yönetmeliği (m.7/1-c) ise hâlâ altı ay der. Pratikte asıl soru, logun bugün sunucuda durup durmadığıdır. Diğer log türleri için: [log analizi](https://www.md9.net/adli-bilisim/log-analizi/).
Örnek
Bir kampanya sayfasındaki katılım koşullarının ne zaman ve hangi yönetici oturumundan değiştirildiği sorulsun. Erişim logunda o dakikada `/wp-admin/post.php` adresine giden bir `POST` isteği, veri tabanında aynı dakikaya ait bir revizyon satırı ve aynı IP'den (ör. `203.0.113.25`) açılmış bir yönetici oturumu birlikte bulunursa değişiklik o oturuma bağlanabilir. Üç kayıttan biri eksikse rapor bağlantıyı zayıf olarak niteler.
## Kullanıcı işlemleri teknik olarak nasıl doğrulanır?
Bir kullanıcının sitede bir işlem yaptığı iddiası, aynı olayın birbirinden bağımsız kayıtlarda aynı zamanla ve aynı oturumla görünmesiyle desteklenir. İzlediğimiz sıra:
1. Sorudaki işlemin veri tabanı kaydını ve tarih alanlarını alırız. Bu alanları çoğunlukla uygulama yazar ve yetkili bir kullanıcı değiştirebilir; tek başına kanıt saymayız ([veri tabanı incelemesi](https://www.md9.net/adli-bilisim/veritabani-inceleme/)).
2. Uygulama logunda aynı işlemin API çağrısını, istek kimliğini ve kullanıcı kimliğini buluruz.
3. Erişim logunda isteği yapan IP'yi, varsa portu ve User-Agent bilgisini oturumla eşleriz.
4. Oturumun parolayla mı, SMS koduyla mı, hatırlanan cihazla mı açıldığına ve başka bir adresten de kullanılıp kullanılmadığına bakarız.
5. Dış teyitleri ekleriz: e-posta bildirimleri, ödeme kuruluşu ve SMS gönderim kayıtları.
6. Bütün zamanları UTC'ye çevirip tek bir zaman çizelgesinde birleştiririz.
Bu adımlar işlemin hangi hesaptan ve hangi oturumdan yapıldığını gösterebilir. Hesabı o anda klavyenin başında kimin kullandığı ise teknik kayıtların tek başına cevaplayamayacağı bir sorudur.
## Kaynak kod, yetkilendirme ve güvenlik açıkları
Kaynak kod, sitede bir işlemin nasıl gerçekleştiğini ve bir yetki kontrolünün o tarihte var olup olmadığını gösterir. Tipik soru: kullanıcı adres çubuğundaki sipariş numarasını değiştirerek başkasının siparişini görebiliyor muydu? Bu, OWASP Top 10:2025 listesinin ilk sırasındaki "Broken Access Control" türüdür; bulguları bu listenin kategorileriyle sınıflandırırız.
Cevap bugünkü koda değil, o tarihte yayında olan sürüme bakılarak verilir; bunun için dağıtım kayıtları, Git etiketleri ve CI/CD geçmişi gerekir. Kodun ayrıntılı incelemesi [yazılım ve kaynak kod incelemesi](https://www.md9.net/adli-bilisim/yazilim-kaynak-kod-inceleme/) kapsamındadır. Güvenlik testini yalnızca incelemeyi isteyenin kendi sisteminde ya da yazılı izinle yaparız; başkasına ait sisteme izinsiz erişim TCK m.243 ve 244'ün konusudur. Yaşanmış bir saldırı için doğru başlangıç [siber olay incelemesidir](https://www.md9.net/adli-bilisim/siber-olay-inceleme/).
## İnceleme için hangi materyal gerekir?
- İncelenecek adresler (tam URL) ve tarih aralığı, saat dilimiyle birlikte.
- Varsa ekran görüntüleri, e-Tespit tutanağı, ilgili e-postalar.
- Site sizinse: erişim ve hata logları (sıkıştırılmış eski dosyalar dahil, ör. `access.log.2.gz`), veri tabanı yedeği, kaynak kod deposu, CDN ve WAF panel kayıtları.
- Site karşı taraftaysa herkese açık kaynaklarla çalışırız; içerideki kayıtların nasıl isteneceğini avukatınız belirler, biz hangi kaydın hangi soruyu cevaplayacağını listeleriz.
Loglar dönerek silinir
Site sizinse ilk iş, log dosyalarını ve veri tabanını bugünkü hâliyle kopyalamak ve dosyaların SHA-256 değerini kaydetmektir ([hash ve delil bütünlüğü](https://www.md9.net/bilgi/dijital-delil-butunlugu-hash/)). Log ayarlarını değiştirmeyin, eski dosyaları temizlemeyin. Hash değerini [hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) dosyalar cihazınızdan çıkmadan hesaplayabilirsiniz.
## Raporda neler yer alır, neler yer almaz?
Rapor; soruyu, materyal listesini ve hash değerlerini, edinim adımlarını ve araç sürümlerini, bulguları ve zaman çizelgesini, alternatif açıklamaları ve sınırları içerir. Erişilemeyen kaydın hangi soruyu cevapsız bıraktığı ayrıca yazılır.
Hukuki nitelendirme yapmayız: "haksız rekabet yapılmıştır" demeyiz, "koşullar metni 14.07 UTC'de şu oturumdan değiştirilmiştir" deriz. Dava sürecinde mahkeme bu konuda bilirkişi görevlendirebilir; Bilirkişilik Daire Başkanlığının uzmanlık listesinde "Web, İnternet ve Multimedya" (18.01) ayrı bir alt alandır. Biz bilirkişi değiliz; taraflardan biri için [uzman görüşü](https://www.md9.net/uzman-gorusu/) hazırlar ya da dosyadaki bilirkişi raporunu teknik yönden değerlendiririz. Raporumuz avukatınız tarafından dosyaya sunulabilir.
## Sık sorulan sorular
### İnternet sitesindeki bir içerik nasıl tespit ettirilir?
İçerik hâlâ yayındaysa üç yol vardır: Türkiye Noterler Birliği'nin e-Tespit hizmeti, dava öncesinde mahkemeden delil tespiti (HMK m.400) ve sayfanın HTML kaynağını, HTTP başlıklarını ve hash değerlerini kaydeden teknik edinim. E-Tespit ekranda görüneni, teknik edinim onun arkasındaki veriyi kayda geçirir. Yolu avukatınızla seçin; içerik her an kaldırılabilir, beklemeyin.
### Bir web sitesinin kime ait olduğu nasıl öğrenilir?
Alan adı kaydı (RDAP; .tr uzantılılarda TRABİS) kayıt kuruluşunu ve tarihleri gösterir, ama kayıt sahibinin adı çoğu zaman gizlilik nedeniyle görünmez. Sunucu IP'si barındırma firmasını gösterir. Kayıt sahibinin kimliği genellikle ancak resmî bir taleple kayıt kuruluşundan veya barındırma firmasından öğrenilir; teknik izler bu talebin kime yöneltileceğini gösterir.
### Sahte bir sitenin ne zaman kurulduğu anlaşılabilir mi?
Çoğu zaman yaklaşık bir tarih verilebilir. RDAP kaydı alan adının mevcut kaydının oluşturulma tarihini, Certificate Transparency kayıtları ilk TLS sertifikasının verildiği anı, pasif DNS alan adının ilk görüldüğü günü gösterir. Üçü birlikte sitenin en geç hangi tarihte yayına hazırlandığını ortaya koyar. Siteyi kimin kurduğunu ise göstermezler.
### Wayback Machine kaydı delil olarak kullanılabilir mi?
Wayback Machine kaydı, sayfanın arşivlendiği andaki hâline dair bağımsız bir işarettir; ancak birebir kopya değil, yeniden kurgudur. Görseller ve betik dosyaları farklı zamanlarda arşivlenip tek ekranda birlikte gösterilebilir; her bileşenin tarihini ayrıca kontrol ederiz. İçerik değiştirildiği tespit edilen archive.today kayıtlarına dayanmıyoruz. Delil değerini mahkeme takdir eder.
### Web sitesi uyuşmazlığında bilirkişiyi kim belirler?
Bilirkişiyi mahkeme veya savcılık görevlendirir; taraflar bilirkişi seçemez, yalnızca atanmasını talep edebilir (HMK m.266). Taraflar ise kendi seçtikleri bir uzmandan uzman görüşü (HMK m.293) ya da ceza yargılamasında bilimsel mütalaa (CMK m.67/6) alabilir. Biz bu çerçevede rapor hazırlar ya da dosyadaki bilirkişi raporunu teknik yönden değerlendiririz. Ayrıntı için [uzman görüşü ile bilirkişi farkı](https://www.md9.net/bilgi/uzman-gorusu-bilirkisi-farki/).
---
# Yazılım ve kaynak kod incelemesi
URL: https://www.md9.net/adli-bilisim/yazilim-kaynak-kod-inceleme/
Güncelleme: 2026-09-27
Kaynak kod incelemesi, teslim edilen yazılımın kodunu, sürüm geçmişini ve çalışan hâlini sözleşme ve teknik şartnameyle karşılaştırarak hangi işlevin çalıştığını, hangisinin eksik veya hatalı olduğunu ve kodun ne zaman, hangi hesaplardan geliştirildiğini kayıtlara dayanarak gösteren teknik incelemedir. Yazılım teslim ve ayıp uyuşmazlıklarında taraflardan biri için uzman görüşü olarak hazırlanır.
Bu inceleme çoğunlukla bir yazılım projesi bittiğinde ya da yarıda kaldığında gündeme gelir. İş sahibi yazılımın eksik veya hatalı teslim edildiğini, yüklenici işin şartnameye uygun tamamlandığını ve yeni taleplerin kapsam dışı olduğunu söyler. Teknik inceleme bu tartışmayı ölçülebilir hâle getirir. Uyuşmazlıkların tipik kökleri için [yazılım teslim uyuşmazlıkları](https://www.md9.net/bilgi/yazilim-projesi-teslim-uyusmazligi/) yazımıza bakabilirsiniz; bu sayfa incelemenin nasıl yapıldığını anlatır.
## Hangi uyuşmazlıklarda yazılım incelenir?
| İddia | Teknik soru | Başlıca kayıtlar |
| Teslim edilmedi, eksik teslim | Teslim edilen depo veya paket şartnamedeki modüllerin hangilerini içeriyor? | Depo, teslim e-postası veya tutanağı, sunucudaki kurulum, derleme kayıtları |
| Ayıplı, hatalı yazılım | Hata yeniden üretilebiliyor mu; kaynağı kod mu, ortam mı, veri mi? | Hata kayıtları (issue tracker), uygulama logları, test ortamı |
| Şartnameye aykırılık | Her madde karşılanmış mı? | Sözleşme, şartname, değişiklik talepleri, kabul testleri |
| Performans | Şartnamedeki ölçüt ölçülebilir mi, sağlanıyor mu? | Yük testleri, sunucu izleme kayıtları |
| Güvenlik | Bilinen türde açık var mı, teslim tarihinde var mıydı? | Kod, bağımlılık listesi, tarama çıktıları |
| Kod sahipliği, geliştirme geçmişi | Kod hangi hesaplardan, hangi tarihlerde depoya girdi; başka bir kod tabanıyla örtüşüyor mu? | Commit geçmişi, platform kayıtları, benzerlik analizi |
## Teknik şartnameye uygunluk nasıl değerlendirilir?
Uygunluk, şartnamenin her maddesinin test edilebilir bir ifadeye çevrilip teslim edilen sürüm üzerinde tek tek denenmesiyle değerlendirilir. Sıramız şöyle:
1. **Sürümü sabitleriz.** Hangi commit, hangi derleme, hangi paket; paketin SHA-256 değeri kayda geçer. Taraflar "teslim edilen yazılım" derken çoğu zaman farklı sürümlerden söz eder.
2. **Gereksinim listesi çıkarırız.** Sözleşme, şartname, teklif ekleri ve yazılı değişiklik taleplerinden. "Kullanıcı dostu arayüz" gibi ölçülemeyen maddeleri ayrıca işaretleriz; raporda ölçülmüş gibi sunulmazlar.
3. **Kaynak koddan derleyip kurarız.** Belgelenmiş, yalıtılmış bir ortamda. Derlenemiyorsa bu da bulgudur: eksik bağımlılık, belgelenmemiş yapılandırma, depoda olmayan dosya.
4. **Her maddeyi test ederiz** ve sonucu kanıtıyla (ekran kaydı, log, test çıktısı) saklarız.
5. **Kronolojiyi kurarız.** Hangi hata ne zaman bildirildi, ne zaman kapatıldı, hangi talep sonradan geldi; issue tracker kayıtları ve yazışmalar tek zaman çizelgesinde.
Sonuç bir uygunluk matrisidir. Örnek (kurgusal):
| Madde | Şartname ifadesi | Sonuç | Kanıt |
| 4.2 | Siparişler tarih aralığına göre Excel'e aktarılabilmeli | Kısmen | 10.000 satırın üzerinde zaman aşımı; test-4.2.log | ``
| 5.1 | Yetkiler rol bazlı tanımlanmalı | Karşılandı | Rol tablosu ve uç nokta kontrolleri, commit a1b2c3d |
| 6.3 | Girişte SMS doğrulaması | Test edilemedi | SMS sağlayıcı hesabı teslim edilmemiş |
| 7.4 | "Raporlar hızlı açılmalı" | Ölçülemez | Şartnamede ölçüt yok |
Şartnamede kalite ölçütü yoksa bulguları adlandırmak için ISO/IEC 25010 kalite modelinden yararlanırız; ama bu modeli taraflar üzerinde anlaşmış gibi sunmayız. Proje teslim kriterleri ayrıca okunur: kabul testi senaryoları, kullanıcı kabul (UAT) tutanakları, canlıya geçiş koşulları. Sistemin fiilen hangi tarihten beri kullanıldığı da kayıtlarla gösterilebilir: canlı veri tabanındaki ilk gerçek kayıtlar, kullanıcı trafiği, ödeme ya da e-fatura entegrasyonundaki canlı işlemler. Bu kullanımın hukuken kabul anlamına gelip gelmediğini ise avukat ve mahkeme değerlendirir. Yeni bir projede kabul kriterlerini baştan ölçülebilir yazmak için [proje danışmanlığı ve şartname](https://www.md9.net/yazilim/proje-danismanligi/) sayfamıza bakın.
## Hatalar ve sürüm farkları nasıl tespit edilir?
Bir hata, yeniden üretilebildiği ölçüde bulgu olur. Her hata için yeniden üretim adımlarını, beklenen ve gerçekleşen sonucu, sürümü ve kaynağını yazarız. Kaynak ayrımı çoğu uyuşmazlığın düğüm noktasıdır:
| Kaynak | Tipik belirti | Ayırmak için bakılan |
| Kod | Aynı girdiyle her ortamda aynı hata | Temiz kurulumda yeniden üretim, ilgili kod satırı |
| Yapılandırma, ortam | Testte çalışan işlev canlıda çalışmıyor | Ortam değişkenleri, çalışma zamanı sürümleri, zaman aşımı ayarları |
| Veri | Hata yalnızca belirli kayıtlarda çıkıyor | Hatayı tetikleyen kayıtlar, eski sistemden taşınan verinin biçimi |
| Dış hizmet | Hata belirli bir entegrasyonda, belirli saatlerde | Sağlayıcının API yanıt kodları ve sürüm notları |
Önem derecesini sözleşmede bir tanım varsa ona göre, yoksa işlevin kullanılabilirliğine etkisine göre ayrı bir sütunda gösterir, ölçütü raporda açıklarız.
Sürüm farkı için teslim edilen paketin hash değerini, depodaki etiketten (tag) yeniden derlenen paketle karşılaştırırız. Derleme her seferinde bayt bayt aynı çıktıyı vermeyebilir (gömülü derleme zamanı, imza); o zaman karşılaştırma dosya düzeyinde yapılır. İki sürüm arasındaki kod farkı `git diff v1.4..v1.5` gibi bir komutla çıkarılır ve her değişiklik bir talep ya da hata kaydıyla eşlenir. Web uygulamasında canlıdaki JavaScript paketinin, mobil uygulamada sürüm ve derleme numarasının hangi commit'e denk geldiğini ayrıca doğrularız.
## Git geçmişi ve commit kayıtları neyi gösterir?
Git geçmişi, kodun hangi sırayla ve hangi hesaplar adına depoya girdiğini gösterir. Ancak commit içindeki ad, e-posta ve tarih, commit'i oluşturan bilgisayarın yazdığı bilgilerdir; tek başına kimlik ya da zaman kanıtı değildir.
| Kayıt | Ne söyler | Dikkat | ````````
| Author date / committer date | Kodun yazıldığı beyan edilen an ve commit'in oluşturulduğu an | GIT_AUTHOR_DATE, GIT_COMMITTER_DATE veya git commit --date ile ayarlanabilir; git log --pretty=fuller ikisini ayrı gösterir |
| Yazar adı ve e-postası | Commit'i yapanın beyanı | Serbest metindir, herkes her adı yazabilir | ````
| İmzalı commit | İmzalayan anahtar sahibinin commit nesnesini onayladığı | Tarihin doğru olduğunu göstermez; git log --show-signature ve %G? ile doğrulanır |
| reflog | Yerel depoda dal uçlarının ne zaman değiştiği | Yalnızca geliştiricinin kendi bilgisayarında; varsayılan 90 gün, erişilemeyen girdiler 30 gün | ``
| Platform kayıtları (GitHub örneği) | Push, merge ve force push olaylarını kimliği doğrulanmış kullanıcıyla ilişkilendirir; doğrulanan imzada verified_at zamanı | Events API yalnızca son 30 gün ve en fazla 300 olay; kurumsal audit log 180 gün, Git olayları 7 gün |
Bu yüzden commit tarihlerini sunucu tarafında bağımsız tutulan zamanlarla karşılaştırırız: push kayıtları, CI/CD çalışma zamanları, imza doğrulama zamanı. Geçmiş force push veya rebase ile yeniden yazılmışsa eski hâl, geliştirici bilgisayarlarının reflog'unda ya da daha önce alınmış depo kopyalarında bulunabilir.
Platform kayıtları kısa sürede kaybolur
Uyuşmazlık başlıyorsa depoyu geçmişiyle birlikte (ör. `git clone --mirror`) ve platformun etkinlik kayıtlarını bugün dışa aktarın; ZIP olarak indirilen kod geçmişi taşımaz. Dışa aktarılan dosyaların SHA-256 değerini [hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) kaydedebilirsiniz; neden önemli olduğunu [hash ve delil bütünlüğü](https://www.md9.net/bilgi/dijital-delil-butunlugu-hash/) yazımızda anlattık.
## Kod sahipliği ve benzerlik hakkında teknik olarak ne söylenebilir?
Teknik inceleme, kodun hangi hesaplar adına, ne zaman ve hangi kaynaktan depoya girdiğine dair izleri ortaya koyar; kodun hukuken kime ait olduğuna mahkeme karar verir. Hangi dosyayı hangi hesapların değiştirdiğine, çalışmanın zamana yayılıp yayılmadığına ve tek commit'te on binlerce satırın eklendiği anlara bakarız. Sonuncusu kodun başka yerden taşındığına işaret edebilir, tek başına bunu göstermez.
İki kod tabanı arasındaki benzerlik için MOSS ve JPlag gibi araçlar kullanılır. Gizli ticari kodda hesaplamayı tamamen yerel yapan JPlag'ı tercih ederiz; MOSS kodu Stanford'daki sunucuya gönderir. Skor kopyalama kanıtı değildir; ortak kütüphaneleri ve açık kaynak bileşenleri ayıkladıktan sonra kalan eşleşmeleri tek tek inceler, raporda yüzde yerine eşleşen blokları gösteririz.
## API entegrasyonları, veri tabanı yapısı ve mimari
Pek çok "yazılım çalışmıyor" şikâyetinin kaynağı yazılımın bağlandığı dış hizmettir: ödeme kuruluşu, e-fatura entegratörü, SMS sağlayıcısı, kargo API'si. Entegrasyonun test anahtarlarıyla mı canlı anahtarlarla mı çalıştığına, yanıt kodlarının loglanıp loglanmadığına, hatada yeniden deneme yapılıp yapılmadığına bakarız. Veri tabanı şemasının şartnamedeki veri modelini karşılayıp karşılamadığını ve migration geçmişini ayrıca inceleriz; kayıt düzeyindeki sorular [veri tabanı incelemesinin](https://www.md9.net/adli-bilisim/veritabani-inceleme/) konusudur. Teklifte söz edilen mimari ("yüksek erişilebilirlik", "yatay ölçeklenebilir") ile kurulu sistem arasındaki farkı dağıtım yapılandırmasından gösteririz.
## Lisanslama mekanizmaları: iki ayrı soru
- **Üçüncü taraf lisansları:** Teslim edilen yazılımdaki açık kaynak ve ticari bileşenler hangi lisanslarla gelmiş? Bileşen listesini ScanCode gibi araçlarla çıkarır, lisansları SPDX tanımlayıcılarıyla (ISO/IEC 5962:2021) raporlarız. Sonuç bir yazılım malzeme listesi (SBOM) olarak SPDX veya CycloneDX (ECMA-424) biçiminde de verilebilir.
- **Lisans veya aktivasyon kilidi:** Yazılımda belirli bir tarihten sonra işlevleri kapatan, uzak bir sunucuya lisans sorgusu yapan ya da anahtar isteyen bir kod var mı? Varsa hangi commit'le eklendiğini ve nasıl tetiklendiğini gösteririz.
## Performans ve güvenlik bulguları
Performans ancak ölçütle değerlendirilir: "100 eş zamanlı kullanıcıda sayfa 2 saniyede açılmalı" test edilebilir, "hızlı olmalı" edilemez. Testi şartnamedeki koşullara en yakın ortamda yapar, donanım ve veri hacmi farklarını raporda belirtiriz. Yavaşlığın kaynağı sunucu kaynakları, eksik indeksler ya da kod olabilir; bunu izleme kayıtlarıyla ayırırız.
Güvenlik bulgularını OWASP Top 10:2025 kategorileriyle (ör. A01 Broken Access Control, A05 Injection) sınıflandırırız. Statik analiz ve bağımlılık taraması çıktılarını tek başına bulgu saymaz, her uyarıyı kodda doğrularız. Bir bağımlılıktaki açığın teslim tarihinde bilinip bilinmediği de kontrol edilir: teslimden sonra yayımlanan bir zafiyet, teslim anındaki durum hakkında aynı şeyi söylemez.
## Yazılım davasında bilirkişi ve uzman görüşü
Uyuşmazlık mahkemeye taşındığında teknik incelemeyi mahkemenin görevlendirdiği bilirkişi yapar; Bilirkişilik Daire Başkanlığının listesinde "Yazılım" (18.02) ayrı bir alt uzmanlık alanıdır. Sözleşme eser sözleşmesi olarak nitelendirilirse TBK m.474/2 de her iki tarafa, giderini karşılayarak eserin bilirkişi tarafından gözden geçirilmesini ve sonucun raporla belirlenmesini isteme imkânı tanır. Bilirkişiyi yargı mercii görevlendirdiği için (HMK m.266) talebin hangi yolla yapılacağını avukatınız değerlendirir; dava öncesi delil tespiti (HMK m.400) de bir yoldur.
Biz bilirkişi değiliz; taraflardan biri için çalışırız: dava öncesinde durumu kayda geçiren teknik rapor, dava sırasında HMK m.293 kapsamında uzman görüşü ya da dosyadaki bilirkişi raporunun [teknik değerlendirmesi](https://www.md9.net/uzman-gorusu/bilirkisi-raporu-degerlendirme/). Uzman görüşü mahkemeyi bağlamaz; Yargıtay'a göre tarafın belgeye dayalı beyanı niteliğindedir (9. HD, E.2022/2237, K.2022/3385). Öte yandan esaslı bir uzman görüşü bilirkişi raporuyla ciddi biçimde çelişiyorsa mahkemenin bu çelişkiyi gidermesi gerektiği de Yargıtay kararlarında yer alır (15. HD, E.2015/5127, K.2016/4635).
Süreler
TBK m.474/1'e göre iş sahibi, teslimden sonra eseri gözden geçirmek ve ayıpları uygun süre içinde bildirmekle yükümlüdür; m.477'ye göre gözden geçirme ve bildirim ihmal edilirse eser kabul edilmiş sayılır; m.478 taşınmaz yapılar dışındaki eserlerde ayıp davaları için teslimden itibaren iki yıllık (yüklenicinin ağır kusurunda yirmi yıllık) zamanaşımı öngörür. Sözleşmenizin bu hükümlere tabi olup olmadığını avukatınız değerlendirir. Teknik açıdan söyleyebileceğimiz şu: teslim edilen sürümü ve hata kayıtlarını erken sabitlemek sonraki her tartışmayı kolaylaştırır.
## İnceleme için hangi materyal gerekir?
- Sözleşme, teknik şartname, teklif ve ekleri, kabul kriterleri, yazılı değişiklik talepleri.
- Kaynak kod deposu, geçmişiyle birlikte: okuma yetkisi ya da ayna kopya.
- Teslim edilen paketler, kurulum dosyaları, teslim tutanağı veya e-postası.
- Hata ve iş takip kayıtlarının dışa aktarımı (Jira, GitHub Issues vb.), CI/CD çalışma kayıtları.
- Test ve canlı ortam erişimi; varsa izleme ve uygulama logları.
- Taraflar arasındaki yazışmalar, e-posta orijinalleriyle.
## Raporda neler bulunur?
İncelenen sürüm ve hash değerleri, test ortamı ve araç sürümleri, uygunluk matrisi, hata listesi, zaman çizelgesi, commit ve benzerlik analizi, test edilemeyen maddeler ve erişilemeyen kayıtlar. "Ayıplıdır" ya da "yüklenici kusurludur" demeyiz; "4.2 maddesindeki işlev teslim edilen sürümde şu koşulda çalışmıyor" der, kanıtını ekleriz.
## Sık sorulan sorular
### Yazılım teslim edilmedi ya da eksik teslim edildi; teknik inceleme nasıl yapılır?
Önce "teslim edilen" şeyin ne olduğunu sabitleriz: depo, paket, sunucudaki kurulum ve bunların hash değerleri. Sonra sözleşme ve şartnameden bir gereksinim listesi çıkarır, her maddeyi teslim edilen sürüm üzerinde test ederiz. Hata kayıtları ve yazışmalar tarihe göre dizilir; hangi eksikliğin ne zaman bildirildiği görünür. Sonuç, madde madde kanıtlı bir uygunluk matrisidir.
### Git commit tarihleri değiştirilebilir mi?
Evet. Her commit'te yazar tarihi (author date) ve commit tarihi (committer date) bulunur; ikisi de commit'i oluşturan bilgisayarda ortam değişkenleriyle veya `git commit --date` ile istenen değere ayarlanabilir. Yazar adı ve e-postası da serbest metindir. Bu yüzden commit bilgilerini, depo barındırma platformunun push kayıtları, CI/CD çalışma zamanları ve imza doğrulama zamanı gibi sunucu tarafı kayıtlarla karşılaştırırız.
### Kaynak kod teslim edilmediyse inceleme yapılabilir mi?
Kısmen. Derlenmiş yazılım ya da canlı sistem üzerinden işlevsel (kara kutu) test yapılabilir: şartnamedeki işlev var mı, doğru sonuç veriyor mu, performans ölçütü sağlanıyor mu. Kodun kalitesi, güvenlik açıklarının kaynağı, lisanslı bileşenler ve geliştirme geçmişi ise kod olmadan değerlendirilemez. Kodun kendisi mahkeme eliyle istenebilir; raporda hangi soruların kod olmadan cevapsız kaldığını açıkça yazarız.
### Yazılım intihali (kod kopyalama) nasıl tespit edilir?
Benzerlik araçları iki kod tabanında eşleşen blokları bulur; ama skor tek başına kopyalama kanıtı değildir. MOSS'u geliştiren ekip de skorlara tek başına dayanmanın aracın yanlış kullanımı olduğunu belirtir. Ortak kütüphaneleri, çerçeve şablonlarını ve açık kaynak bileşenleri ayıkladıktan sonra kalan eşleşmeleri tek tek inceler, raporda yüzde yerine eşleşen blokları ve Git geçmişindeki tarihlerini gösteririz.
### Yazılım davasında bilirkişiyi kim seçer?
Bilirkişiyi mahkeme görevlendirir; taraflar yalnızca bilirkişi incelemesi yapılmasını talep edebilir (HMK m.266). Taraf kendi seçtiği bir uzmandan ise uzman görüşü alabilir (HMK m.293). Biz bu kapsamda çalışırız: dava öncesinde durumu tespit eden teknik rapor, dava sırasında uzman görüşü ya da dosyadaki bilirkişi raporunun teknik değerlendirmesi. Ayrıntı: [uzman görüşü ile bilirkişi farkı](https://www.md9.net/bilgi/uzman-gorusu-bilirkisi-farki/).
### Teknik rapor, yazılımın ayıplı olduğunu söyleyebilir mi?
Hayır. "Ayıp" hukuki bir kavramdır ve bu nitelendirme mahkemeye aittir. Rapor teknik tespiti yapar: "şartnamenin 4.2 maddesindeki dışa aktarma işlevi teslim edilen sürümde 10.000 satırın üzerinde zaman aşımına uğruyor" gibi. Bu tespitin sözleşme ve kanun açısından ne anlama geldiğini avukatınız değerlendirir. Rapor ayrıca hatanın kaynağının kod, ortam ya da veri olduğunu ayırmaya çalışır.
---
# Veri tabanı ve elektronik kayıt incelemesi
URL: https://www.md9.net/adli-bilisim/veritabani-inceleme/
Güncelleme: 2026-09-27
Veri tabanı incelemesi, bir kaydın ne zaman oluşturulduğunu, değiştirildiğini ya da silindiğini ve bu işlemin hangi kullanıcı veya uygulama üzerinden yapıldığını, tablodaki tarih alanlarıyla yetinmeden veri tabanının işlem kayıtlarına, audit kayıtlarına, yedeklere ve uygulama loglarına dayanarak değerlendiren teknik incelemedir.
Sipariş ve fatura kayıtları, cari hesap hareketleri, stok girişleri, personel giriş-çıkış (PDKS) kayıtları, randevu ve abonelik onayları, bir ERP'deki onay akışı: hepsi bir veri tabanında satır olarak durur. Uyuşmazlık genellikle dört sorudan biriyle gelir. Bu kayıt iddia edilen tarihte var mıydı? Sonradan değiştirildi mi? Silinen kayıt var mı? Değişikliği kim, hangi yoldan yaptı?
## Kayıttaki tarih alanı neden tek başına yeterli değildir?
Çünkü o alan, kaydın geçmişini değil, en son yazılan değeri gösterir ve onu yazan da çoğunlukla incelenen uygulamanın kendisidir.
- **Kim yazar:** `created_at` değeri ya uygulama kodundan ya da veri tabanının varsayılan değerinden (`DEFAULT CURRENT_TIMESTAMP`) gelir. İlkinde uygulama sunucusunun, ikincisinde veri tabanı sunucusunun saati kullanılmıştır.
- **Değiştirilebilir:** Yetkili bir hesapla çalıştırılan tek bir `UPDATE` ile tarih alanı başka bir değere çekilebilir ve tablo bakıldığında hiçbir şey olağan dışı görünmez.
- **Saat dilimi:** MySQL, `TIMESTAMP` türündeki değerleri bağlantının saat diliminden UTC'ye çevirerek saklar ve okurken geri çevirir; `DATETIME` için bunu yapmaz. Aynı kayıt, farklı saat dilimi ayarıyla bağlanan iki araçta farklı saat gösterebilir. Ayrıntı: [zaman damgaları ve saat dilimi](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/).
- **Birim:** Tamsayı sütunlarda saniye, milisaniye ya da mikrosaniye cinsinden Unix zamanı tutulabilir; birim, bilinen bir test kaydıyla doğrulanmadan okunmaz. Tek tek değerleri [zaman damgası dönüştürücüyle](https://www.md9.net/araclar/zaman-damgasi-donusturucu/) çevirebilirsiniz.
Bu yüzden tarih alanını bir beyan olarak ele alır, doğrulamasını veri tabanının kendi işlem kayıtlarında ararız.
## Veri tabanları değişiklikleri nerede kaydeder?
SQL veri tabanlarının çoğu, veriyi değiştiren işlemleri kurtarma ve replikasyon amacıyla ayrı bir işlem kaydına (transaction log) yazar. Adli açıdan bu kayıt, satırın geçmişine en yakın bağımsız kaynaktır; ne kadar geriye gittiği ise ürüne ve ayarlara bağlıdır.
| Sistem | İşlem kaydı | İnceleme açısından dikkat | ``````
| MySQL | Binary log (mysqlbinlog ile okunur) | Yalnızca veriyi değiştiren işlemler; SELECT kaydedilmez. binlog_expire_logs_seconds varsayılanı 2.592.000 saniye (30 gün). Tüm sorguları tutan general query log varsayılan olarak kapalıdır. | ``````````
| PostgreSQL | WAL (pg_waldump) | Arşivleme (archive_mode) açık değilse gereksiz hâle gelen WAL dosyaları checkpoint sonrasında silinir ya da yeniden adlandırılıp kullanılır; wal_keep_size ve replikasyon yuvaları daha fazlasını tutabilir. UPDATE ve DELETE eski satır sürümünü hemen silmez; VACUUM çalışana kadar fiziksel sayfalarda kalabilir. | ``
| SQL Server | Transaction log | Simple recovery modelinde checkpoint sonrasında, full modelde log yedeğinden sonra log alanı boşaltılır (truncation). fn_dblog belgelenmemiş bir fonksiyondur; çıktısı dikkatli yorum ister. | ``
| Oracle | Redo ve arşivlenmiş redo (LogMiner, V$LOGMNR_CONTENTS) | Supplemental logging açık değilse bazı ayrıntılar eksik kalır. | ````````
| SQLite (mobil ve masaüstü uygulamalar) | -wal dosyası | Veri tabanı -wal ve -shm dosyalarıyla birlikte kopyalanmalı; orijinali açmak checkpoint tetikleyip WAL'ı silebilir. secure_delete genelde kapalıdır, silinen içerik serbest sayfalarda kalabilir. | ``
| MongoDB | Oplog (local.oplog.rs) | Replika set üyelerinde tutulur. Boyutla sınırlıdır: Linux ve Windows'ta WiredTiger ile varsayılan boyut boş disk alanının %5'i (en az 990 MB, en fazla 50 GB); dolunca en eski girdiler silinir, ayrıca saat cinsinden asgari saklama süresi tanımlanmış olabilir. |
## NoSQL veri tabanlarında durum farklı mı?
Çoğu zaman daha zordur, çünkü değişiklik geçmişi ürüne ve kurulum tercihine göre çok değişir. MongoDB'de oplog yalnızca replika set yapısında vardır; tek sunuculu, replika set olarak yapılandırılmamış bir kurulumda bu iz bulunmaz. Belgelerin `_id` alanındaki ObjectId değerinin ilk 4 baytı, değerin oluşturulduğu anı Unix zamanı cinsinden saniye olarak taşır. Bu yararlı bir işarettir ama iki sınırı var: ObjectId'yi çoğunlukla istemci tarafındaki sürücü üretir (yani uygulama sunucusunun saatini yansıtır) ve uygulama `_id` alanına istediği değeri yazabilir.
Anahtar-değer depoları, arama motorları ve bulut belge veri tabanlarında hangi geçmişin tutulduğu ürüne ve ayara göre değişir. Ön incelemede ilk sorduğumuz şey, sistemin değişiklik geçmişini nerede ve ne kadar süreyle tuttuğudur.
## Audit kayıtları ve kullanıcı hareketleri
Audit kaydı, kimin hangi veriye ne zaman eriştiğini veya onu değiştirdiğini tutan kayıttır; ancak "kim" sorusunun cevabı kaydın hangi katmanda tutulduğuna bağlıdır.
Web ve kurumsal uygulamaların çoğu veri tabanına tek bir hizmet hesabıyla (ör. `app_user`) bağlanır. Veri tabanının kendi audit kaydında bütün işlemler bu hesapla görünür; işlemi hangi kişinin yaptığını ancak uygulama logları veya uygulamanın kendi tuttuğu işlem tablosu gösterir. Bu yüzden iki katmanı birlikte isteriz.
| Audit türü | Örnek | Zayıf yanı |
| Veri tabanına yerleşik | SQL Server Audit, PostgreSQL için pgAudit, MySQL Enterprise Audit | Kurulumda açılmamışsa hiç yoktur; açıksa bile uygulama hesabını gösterir | ``
| Tetikleyici (trigger) tabanlı | Her değişiklikte bir audit_log tablosuna satır yazan tetikleyici | Yetkili bir hesap tetikleyiciyi kapatabilir ya da audit tablosunu düzenleyebilir |
| Uygulama düzeyinde | Kullanıcı kimliğiyle tutulan işlem geçmişi tablosu | Uygulamayı atlayan doğrudan SQL değişikliklerini görmez |
Audit tablosunun kendisini de inceleriz: sıra numaralarında ve zamanda boşluk var mı? Burada dikkatli olmak gerekir. MySQL InnoDB'de geri alınan (rollback) bir işlemin ürettiği `AUTO_INCREMENT` değerleri yeniden kullanılmaz; yani ID dizisindeki bir boşluk tek başına silme göstermez.
## Silinen ve değiştirilen kayıtlar değerlendirilebilir mi?
Çoğu zaman bir ölçüde; hangi ölçüde olduğunu saklama ayarları ve geçen süre belirler. Baktığımız kaynaklar, güvenilirlik sırasına göre kabaca şunlardır:
1. **İşlem kaydı:** MySQL 8.4'ün varsayılan ayarlarında (`binlog_format=ROW`, `binlog_row_image=full`) binlog, değişen satırın bütün sütunlarının önceki ve sonraki hâlini içerir. WAL ve transaction log da değişikliğin izini taşır, ama okunmaları daha çok uzmanlık ister.
2. **Yedekler:** Farklı günlere ait iki yedek karşılaştırıldığında hangi satırın ne zaman eklendiği, değiştiği ya da kaybolduğu dar bir aralıkta tarihlenir.
3. **Kopyalar:** Replikalar, raporlama ve veri ambarı kopyaları, dışa aktarılmış dosyalar, sistemin gönderdiği e-posta bildirimleri.
4. **"Yumuşak silme":** Birçok uygulama satırı silmez, `deleted_at` ya da `is_deleted` alanını işaretler. Bu durumda silme zamanı zaten tabloda durur.
5. **Fiziksel izler:** PostgreSQL'de VACUUM öncesindeki eski satır sürümleri, SQLite'ta serbest sayfalar. En az güvenilir ve en çok uzmanlık isteyen kaynaktır.
Bir kaydın silindiğini göstermek, silinen içeriği geri getirmekle aynı şey değildir. Raporda ikisini ayrı yazarız.
## Veri bütünlüğü nasıl değerlendirilir?
Veri bütünlüğü iki ayrı soruyu kapsar: incelenen kopyanın alındığı andan beri değişmediği ve verinin kendi içinde tutarlı olduğu. Birincisi hash değerleriyle gösterilir ([hash ve delil bütünlüğü](https://www.md9.net/bilgi/dijital-delil-butunlugu-hash/)). İkincisi daha çok şey anlatır, çünkü elle yapılan müdahaleler çoğu zaman bir tutarsızlık bırakır. Baktığımız tipik işaretler:
- Sıra numarası (`AUTO_INCREMENT`, sequence) büyük olan bir kaydın `created_at` değeri, kendinden önceki kayıtlardan saniyeler değil günlerce eskiyse. Kayıt sonradan eklenip tarihi geriye çekilmiş olabilir; toplu içe aktarma da aynı görüntüyü verir.
- `updated_at` değeri `created_at`'ten önceyse.
- Fatura toplamı kalemlerle, stok bakiyesi hareketlerle, cari bakiye hesap hareketleriyle tutmuyorsa.
- Başka tabloda karşılığı kalmamış (yetim) kayıtlar: silinmiş bir siparişin ödemesi, silinmiş bir kullanıcının oturumları.
- Ana tablodaki bir değişikliğin tetikleyiciyle tutulan audit tablosunda karşılığı yoksa.
Tutarsızlık tek başına müdahale kanıtı değildir; hatalı bir migration ya da yazılım hatası da aynı izi bırakır. Raporda gözlenen tutarsızlığı, olası açıklamalarıyla ve işlem kaydında doğrulanıp doğrulanamadığıyla birlikte yazarız.
## Veri tabanı ve uygulama logları nasıl karşılaştırılır?
Karşılaştırmanın amacı, her veri tabanı değişikliğinin arkasında bir uygulama isteği olup olmadığını görmektir. Adımlar:
1. Her kaynağın saat ayarını belirleriz: veri tabanı sunucusu (MySQL'de `@@global.time_zone` ve `@@session.time_zone`, PostgreSQL'de `SHOW timezone`), uygulama sunucusu, log biçimi. Hepsini UTC'ye çeviririz.
2. Sorudaki kaydın işlem kaydındaki bütün olaylarını çıkarırız: oluşturma, her güncelleme, silme.
3. Uygulama logunda aynı aralıktaki istekleri, kullanıcı kimliklerini ve istek kimliklerini buluruz.
4. Olayları eşleştiririz ve eşleşmeyenleri ayırırız. Uygulama isteği olmayan bir değişiklik; doğrudan SQL istemcisi, yönetim aracı, zamanlanmış görev ya da migration betiği olabilir. Hangisi olduğunu bağlantı ve audit kayıtlarından anlamaya çalışırız.
5. Sonucu tek bir kronolojide birleştiririz: her satırda UTC ve Türkiye saati, kaynak, olay ve kanıt.
Örnek
Bir e-ticaret veri tabanında 1042 numaralı siparişin tutarı iki kez değişmiş olsun. Binlog'da 11:02:11 ve 20:47:05 UTC'de iki `UPDATE` görünür. İlki aynı saniyede `PUT /api/orders/1042` isteğiyle ve bir müşteri hizmetleri kullanıcısının oturumuyla eşleşir. İkincisinin karşılığı uygulama logunda yoktur; audit kaydına göre `dbadmin` hesabıyla `203.0.113.40` adresinden açılmış bir bağlantıdan yapılmıştır. Rapor bu iki değişikliği ayrı ayrı, kanıtlarıyla anlatır; ikincisini kimin yaptığı sorusunu ise o hesabı kimlerin kullanabildiği bilgisine bağlı olarak açık bırakır.
Uygulama, API ve kimlik doğrulama loglarının kendisine ilişkin sorular için [log analizi](https://www.md9.net/adli-bilisim/log-analizi/), bu kayıtları üreten kodun davranışı için [kaynak kod incelemesi](https://www.md9.net/adli-bilisim/yazilim-kaynak-kod-inceleme/) sayfalarımıza bakabilirsiniz.
## Materyal nasıl alınmalı?
Canlı veri tabanında ilk iş sorgu çalıştırmak olmamalı
Önce izler korunur, sonra sorulur. Günlük bakım işleri (log temizliği, VACUUM, yedek rotasyonu) inceleme süresince incelenecek kayıtları silebilir; bunları sistem yöneticinizle birlikte gözden geçiririz.
- Tutarlı bir yedek veya dump; mümkünse ek olarak fiziksel yedek.
- İşlem kayıtları: binlog dosyaları, WAL arşivi, transaction log yedekleri. Süreleri dolmadan.
- Yapılandırma: `my.cnf`, `postgresql.conf`, recovery modeli, saat dilimi ve audit ayarları.
- Uygulama logları, şema ve migration geçmişi.
- Veri tabanı hesaplarının ve yetkilerinin listesi: hangi hesapla kimler bağlanabiliyor.
- Mevcut yedeklerin listesi, tarihleriyle.
Her dosyanın SHA-256 değeri alınır ve inceleme kopyalar üzerinde yapılır; SQLite dosyaları ise `-wal` ve `-shm` dosyalarıyla birlikte, salt okunur olarak açılır. Dosyaların hash değerini [hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) kendiniz de kaydedebilirsiniz.
## Raporda neler yer alır?
Kayıt bazında kronoloji tablosu, uygulama isteğiyle eşleşen ve eşleşmeyen değişiklikler, silme göstergeleri ve kurtarılabilen içerik, kullanılan yöntem ve araç sürümleri, erişilemeyen kayıtlar ve bunların hangi soruyu cevapsız bıraktığı. Rapor, kayıtların teknik güvenilirliğine ilişkin tespitleri içerir; bunların hukuki değerlendirmesi avukatınıza ve mahkemeye aittir. Raporumuz avukatınız tarafından [uzman görüşü](https://www.md9.net/uzman-gorusu/) olarak dosyaya sunulabilir.
## Sık sorulan sorular
### Veri tabanından silinen bir kayıt geri getirilebilir mi?
Bazen. Satır tabanlı işlem kaydı (ör. MySQL binlog) silinen satırın içeriğini hâlâ taşıyorsa, silme öncesine ait bir yedek varsa ya da kayıt bir raporlama kopyasına aktarılmışsa içerik bulunabilir. PostgreSQL'de VACUUM, SQLite'ta `secure_delete` ve SQL Server'da log truncation, fiziksel izlerin ömrünü belirler. Kurtarma imkânını ön incelemede değerlendiririz; her silinen kaydın geri geleceğini söylemeyiz.
### Bir kaydın sonradan değiştirildiği nasıl anlaşılır?
Tablodaki tarih alanına bakılarak değil. Değişiklik; işlem kaydında (binlog, WAL, transaction log) bir UPDATE olayı olarak, audit tablosunda bir satır olarak ya da iki yedek arasındaki fark olarak görünür. Bu kayıtlar uygulama loglarıyla karşılaştırılır: değişikliğin arkasında bir kullanıcı isteği var mı, yoksa doğrudan veri tabanına bağlanılarak mı yapıldı? Kayıtlar saklanmamışsa değişiklik iddiası çoğu zaman teknik olarak cevapsız kalır.
### Excel veya CSV çıktısı inceleme için yeterli mi?
Başlangıç için işe yarar, inceleme için yetmez. Excel ya da CSV çıktısı, bir sorgunun o anki sonucudur: kaydın geçmişini, silinen satırları, işlem kayıtlarını ve hangi sorguyla üretildiğini taşımaz, üstelik kolayca düzenlenebilir. Çıktıyı kullanmak zorundaysanız, hangi sorguyla, kim tarafından ve ne zaman alındığını yazılı olarak kaydedin ve dosyanın hash değerini hemen hesaplayın.
### Veri tabanı incelemesi için sistemi durdurmak gerekir mi?
Çoğu zaman hayır. Tutarlı bir yedek, çalışan sistemi durdurmadan alınabilir; işlem kayıtları ve yapılandırma dosyaları da kopyalanabilir. Durdurmadan önce dikkat edilmesi gereken, canlı veri tabanında ilk iş olarak sorgu çalıştırmamak ve günlük bakım işlerinin (log temizliği, VACUUM, yedek rotasyonu) incelenecek izleri silmesini önlemektir. Edinim planını sistem yöneticinizle birlikte yaparız.
### Veri tabanı logları ne kadar süre saklanır?
Tek bir süre yoktur; ürüne ve ayara bağlıdır. MySQL 8.4'te binary log dosyaları varsayılan olarak 30 gün sonra otomatik silinebilir. PostgreSQL'de WAL dosyaları arşivleme açık değilse checkpoint sonrasında silinir ya da yeniden kullanılır. SQL Server'da log alanı recovery modeline göre boşaltılır, MongoDB oplog'u ise boyutla sınırlıdır ve dolunca en eski girdileri siler. Bu yüzden uyuşmazlık başlar başlamaz log dosyalarının kopyalanmasını öneririz.
### Elektronik kayıtlar mahkemede delil olarak kullanılabilir mi?
HMK m.199, elektronik ortamdaki verileri belge sayar; bir kaydın somut dosyada ne değer taşıyacağını mahkeme takdir eder. Teknik inceleme bu değerlendirmeye kayıtların nereden geldiğini, nasıl korunduğunu ve değişikliğe karşı ne kadar güvenilir olduğunu göstererek katkı sunar. Log kayıtlarının güvenilirliğini etkileyen etkenleri [log kayıtlarının delil değeri](https://www.md9.net/bilgi/log-kayitlari-delil-degeri/) yazımızda anlattık.
---
# E-posta incelemesi: header analizi ve sahte e-posta iddiaları
URL: https://www.md9.net/adli-bilisim/e-posta-inceleme/
Güncelleme: 2026-09-27
E-posta incelemesi, bir iletinin iddia edilen sunucudan ve tarihte gönderilip gönderilmediğini, sonradan değiştirilip değiştirilmediğini başlık (header) alanları, SPF/DKIM/DMARC sonuçları ve sunucu kayıtlarıyla değerlendiren teknik incelemedir. Bunun için ekran görüntüsü yetmez; iletinin orijinal dosyası (.eml, .msg) ya da posta kutusundan alınmış dışa aktarımı gerekir.
Önümüze gelen sorular genellikle şöyledir: bu fatura e-postası gerçekten tedarikçimizden mi geldi, karşı tarafın dosyaya koyduğu e-posta sonradan mı üretildi, ileti iddia edilen tarihte gönderildi mi? Cevap tek bir satırda değil, iletideki izlerle sunucu kayıtlarının birlikte okunmasındadır. Ödeme bilgisi değiştirilmiş bir faturayla karşılaştıysanız önce [sahte IBAN e-postasında ilk 24 saatte yapılacaklara](https://www.md9.net/bilgi/sahte-iban-e-postasi/) bakın: o durumda ilk iş bankayı aramaktır.
## "Sahte e-posta" iddiaları hangi türlerde çıkar?
"Sahte e-posta" dediğimiz şey teknik olarak beş ayrı durumdur ve her birinde bakılacak kayıt değişir.
| Durum | Ne olmuştur | İncelemede bakılan | Dikkat | ````
| Gönderici taklidi (spoofing) | From alanına başkasının adresi yazılmıştır. SMTP bunu kendiliğinden engellemez (RFC 5321 §7.1). | Alıcı sunucunun Authentication-Results satırı, DMARC hizalaması, Received zinciri | DMARC politikası yoksa taklit ileti gelen kutusuna düşebilir. | ``
| Benzer alan adı | Saldırgan gerçeğine benzeyen kendi alan adından yazar (harf değişikliği, sona "-tr", "-fatura" eklenmesi). | Alan adının kayıt tarihi, ilk TLS sertifikasının tarihi, gösterilen ad ile gerçek adres farkı | SPF/DKIM/DMARC çoğu zaman pass döner, çünkü alan adı saldırganındır. | [](https://www.md9.net/adli-bilisim/siber-olay-inceleme/)
| Ele geçirilmiş gerçek hesap | İleti gerçekten o hesaptan ve o kurumun sunucusundan çıkmıştır. | Oturum açma kayıtları, posta kutusu kuralları, ileti izleme kayıtları | Başlık tek başına yetmez; hesap kayıtları gerekir (hesap ele geçirme incelemesi). | ````
| Sonradan üretilmiş ya da düzenlenmiş ileti | Metni değiştirilmiş .eml, düzenlenmiş ekran görüntüsü, gönderilmemiş taslak. | DKIM gövde özeti (bh=), Message-ID'nin sunucu kayıtlarındaki karşılığı, karşı taraftaki kopya | Elde yalnızca ekran görüntüsü varsa sonuç çoğu zaman "belirlenemedi" olur. | ``
| Gönderim ve teslim uyuşmazlığı | "Gönderdim" ve "almadım" beyanları çelişir. | Received zamanları, sunucunun teslim kaydı, gönderilmiş öğeler kopyası | Teslim kaydı iletinin okunduğunu göstermez. |
## Neden ekran görüntüsü değil, orijinal .eml dosyası?
Ekran görüntüsü, e-posta programının iletiyi nasıl gösterdiğinin resmidir. Gösterilen ad ("Muhasebe") gerçek adresi gizleyebilir; `Received` satırları, DKIM imzası ve doğrulama sonuçları görüntüde yoktur. Bu yüzden ekran görüntüsünden iletinin nereden geldiğine dair teknik sonuç çıkarılamaz (bkz. [ekran görüntüsünün delil değeri](https://www.md9.net/bilgi/ekran-goruntusu-delil/)). Normal iletme (forward) de yetmez: ileti yeni başlıklarla çıkar, asıl başlıklardan geriye çoğu zaman gövdeye alıntılanmış üç dört satır (kimden, tarih, konu) kalır. İletiyi birine aktarmak zorunluysa "ek olarak ilet" seçeneği iletinin kendisini dosya olarak ekler.
- **Tek tek iletiler:** webmail'de iletinin menüsünden indirilen `.eml`, Outlook masaüstünden kaydedilen `.msg`. `.eml` başlığı ve gövdeyi, ekler dahil, RFC 5322 biçiminde ham olarak taşır.
- **Kurumsal posta kutusu:** yöneticinin dışa aktarma veya eDiscovery aracıyla aldığı `.pst` ya da `.mbox`, aynı döneme ait ileti izleme ve oturum açma kayıtlarıyla.
- **Kendi sunucusunu işletenler:** posta kutusu ve loglar, değiştirilmeden.
Dosyayı açıp yeniden kaydetmeyin. Teslim aldığımız her dosyanın SHA-256 değerini kaydederiz; aynı değeri [tarayıcıda çalışan hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) siz de hesaplayabilirsiniz. Hash, elimizdeki kopyanın teslimden sonra değişmediğini gösterir, iletinin özgün olduğunu değil. Aynı ileti iki farklı programdan indirilirse hash'ler farklı çıkabilir; bu çelişki sayılmaz.
## Başlık analizinde neye bakıyoruz?
Başlık analizi, iletinin geçtiği sunucuları, zamanları ve doğrulama sonuçlarını satır satır çıkarıp birbiriyle sınamaktır. Aşağıdaki başlık kurgusaldır, adresler dokümantasyon aralıklarından alınmıştır.
**Örnek:**
```
Return-Path:
Received: from mx.example.com (mx.example.com [192.0.2.10])
by mx.example.org (Postfix) with ESMTPS id 4dW3Kx1Z2Qz9sQ
for ; Thu, 12 Mar 2026 10:21:07 +0300
Authentication-Results: mx.example.org;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com header.s=s1;
dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
h=from:to:subject:date:message-id:reply-to; bh=…; b=…
Received: from [10.0.0.23] (unknown [203.0.113.45])
by mx.example.com (Postfix) with ESMTPSA id 7C1E2A1B3
for ; Thu, 12 Mar 2026 07:21:05 +0000
From: "Tedarikçi A.Ş. Muhasebe"
Reply-To:
Date: Thu, 12 Mar 2026 10:21:04 +0300
Message-ID: <20260312072104.9F2A@mx.example.com>
Subject: Güncel IBAN bilgimiz
```
Başlık aşağıdan yukarı okunur, çünkü her sunucu kendi `Received` satırını en üste ekler ve öncekileri değiştiremez (RFC 5321 §4.4). Bu örnekten çıkanlar:
- En alttaki `Received`, gönderen sunucunun iletiyi 203.0.113.45 adresindeki istemciden kimlik doğrulamalı oturumla (`ESMTPSA`) aldığını söyler. EHLO'daki `[10.0.0.23]` istemcinin beyanıdır, parantezdeki adres bağlantıdan gelir. Satırı gönderen taraf yazmıştır; doğrulanması gereken bir beyandır.
- Üstteki `Received` ve `Authentication-Results` satırlarını alıcının kendi sunucusu eklemiştir. Güven sınırı burasıdır. Alıcı sunucu, kendi adını taşıyan ama güvendiği bir sunucudan gelmemiş sonuç satırlarını silmekle yükümlüdür (RFC 8601 §5); başka bir ada ait sonuçlara itibar etmeyiz.
- `id 4dW3Kx1Z2Qz9sQ`, alıcı sunucunun logundaki kuyruk kimliğidir. Sunucu kayıtlarına bu anahtarla geçilir.
- İki halkanın saatleri farklı dilimlerde yazılmış. UTC'ye çevrilince 07:21:05 ve 07:21:07 olur: sıra doğru, aralık iki saniye. Karşılaştırmayı hep UTC'de yaparız.
- `Date` gönderenin cihaz saatidir, taşıma zamanı değildir (RFC 5322 §3.6.1).
- `Reply-To` başka bir alan adına gidiyor. Tek başına sahtelik kanıtı değildir, ama ödeme değişikliği bildiren bir iletide ilk not ettiğimiz şeydir. İmza geçerli ve DKIM `h=` listesinde `reply-to` varsa bu alan imza anında vardı; aynı alandan iki tane varsa hangisinin imzalandığına bakarız.
- Message-ID her ileti için tekil olmalıdır (RFC 5322 §3.6.4). Sağ tarafı gönderen altyapıyla tutarlı; sol taraftaki `20260312072104` da Date'in UTC karşılığıyla örtüşüyor. Bazı sistemler kimliği zamandan üretir, ama bu bir kural değildir; asıl sınama, aynı kimliğin sunucu kayıtlarında bulunmasıdır.
Örnekte her şey `pass` ve tutarlı. Bu, iletinin `example.com`'un yetkili altyapısından çıktığını gösterir; `fatura@example.com` hesabının o anda kimin elinde olduğunu göstermez. Bundan sonrası hesap kayıtlarının işidir, başlığın değil. Başlığı kendiniz okumak isterseniz [e-posta başlığının nasıl bulunup okunduğunu](https://www.md9.net/bilgi/e-posta-header-nasil-okunur/) anlatan rehber ve tarayıcıda çalışan, hiçbir şey yüklemeyen [e-posta başlık analizi aracı](https://www.md9.net/araclar/e-posta-baslik-analizi/) işinizi görür.
## SPF, DKIM ve DMARC ne kanıtlar, ne kanıtlamaz?
Üçü de alan adını doğrular, kişiyi değil. Farkları, neyi denetledikleri ve hangi durumda yanlış alarm verdikleridir:
| Mekanizma | Neyi denetler | Neyi göstermez | İncelemede dikkat | ``
| SPF (RFC 7208) | Zarftaki MAIL FROM (ve HELO) alan adı için, bağlanan IP'nin DNS'te yetkilendirilmiş olup olmadığını | Ekranda görünen From adresini doğrudan denetlemez | Yönlendirilen iletilerde SPF bozulabilir; fail her zaman sahtelik değildir. | ``````
| DKIM (RFC 6376) | h= listesindeki başlıkların ve gövdenin imzadan sonra değişmediğini; imzanın d= alan adının anahtarıyla atıldığını | İletiyi hangi kişinin yazdığını; imzalanmamış başlıkları; l= sınırından sonra eklenen gövdeyi | Anahtar DNS'ten kaldırıldıysa aylar sonra doğrulama başarısız olur (RFC 6376 §6); bu tek başına sahtelik göstermez. | ``
| DMARC (RFC 9989) | From alanındaki alan adının, SPF veya DKIM ile doğrulanmış bir alan adıyla hizalı olup olmadığını | Adresin kullanıcı kısmını (fatura@) | Politika kaydının iletinin gönderildiği tarihteki hâli ayrıca araştırılır. |
DMARC'ı bugün Mayıs 2026'da yayımlanan RFC 9989 tanımlıyor; RFC 7489'un yerini aldı. `pct` etiketi kalktı, `np`, `psd` ve `t` etiketleri geldi. İnternetteki Türkçe anlatımların çoğu hâlâ eski metne dayanıyor, raporda hangi sürüme göre değerlendirme yaptığımızı yazarız.
DKIM imzası, HMK m.205/2'nin senet hükmü tanıdığı güvenli elektronik imza değildir; bir alan adına bağlıdır, kişiye değil.
## Sunucu kayıtları iletinin geçişini nasıl doğrular?
İletinin kendisi tek taraflı bir kayıttır; sunucu logları, iletinin gerçekten o sunucudan geçip geçmediğini bağımsız olarak gösterir. SMTP kayıtlarında aynı iletiye ait satırlar kuyruk kimliğiyle birbirine, Message-ID ile de başlığa bağlanır.
**Örnek (alıcı tarafta Postfix logu):**
```
Mar 12 10:21:07 mx postfix/smtpd[21877]: 4dW3Kx1Z2Qz9sQ: client=mx.example.com[192.0.2.10]
Mar 12 10:21:07 mx postfix/cleanup[21880]: 4dW3Kx1Z2Qz9sQ: message-id=<20260312072104.9F2A@mx.example.com>
Mar 12 10:21:08 mx postfix/qmgr[1022]: 4dW3Kx1Z2Qz9sQ: from=, size=48213, nrcpt=1 (queue active)
Mar 12 10:21:08 mx postfix/local[21885]: 4dW3Kx1Z2Qz9sQ: to=, relay=local, status=sent (delivered to mailbox)
```
Satırlarda yıl ve saat dilimi yok; klasik syslog biçimi bunları yazmaz. İkisini sunucu yapılandırmasından belirler, raporda varsayım olarak yazarız.
- **Exchange Server:** ileti izleme varsayılan olarak açıktır ve 30 günden eski kayıtları döngüsel siler. Satırlarda UTC zamanı, `client-ip`, `message-id`, zarftaki gönderen (`return-path`) ve `RECEIVE`, `DELIVER`, `FAIL` gibi olay türleri bulunur. İleti içeriği tutulmaz, konu satırı tutulur.
- **Exchange Online:** ileti izleme verisi 90 gün tutulur, süre değiştirilemez. İzdeki "gönderen", başlıktaki From değil zarftaki MAIL FROM'dur.
- **Postfix:** varsayılan olarak syslog'a yazar; saklama süresini log rotasyonu belirler.
Bcc alıcıları diğer alıcıların kopyasında görünmez; iletinin gerçekte kimlere gittiği gönderen sunucunun kaydından (Exchange'de `recipient-status` alanı To, Cc, Bcc ayrımını taşıyabilir) ya da "Gönderilmiş Öğeler" kopyasından anlaşılır.
## Ek dosyalar ve metadata
Ekler `.eml` dosyasının içinde MIME parçaları olarak durur; onları çıkarır, hash değerlerini alır ve metadata'larını ayrıca inceleriz. Sahte IBAN'lı fatura şüphesinde PDF'in `Creator` ve `Producer` alanları, `CreationDate`/`ModDate` ve sona eklenmiş güncellemeler (birden fazla `%%EOF`) aynı göndericinin önceki faturalarıyla karşılaştırılır. Bu alanlar da değiştirilebilir; tek başına hüküm kurmayız. Ayrıntı: [doküman ve metadata incelemesi](https://www.md9.net/adli-bilisim/metadata-inceleme/).
## İnceleme nasıl ilerler?
1. **Kapsam.** Hangi iletiler, hangi iddia, hangi posta kutularına hukuka uygun olarak erişilebildiği.
2. **Teslim.** Orijinal dosyalar SHA-256 değerleriyle kayda geçer; çalışma kopya üzerinde yapılır.
3. **Başlık tablosu.** Her `Received` satırı için sunucu, IP, protokol ve UTC zamanı; güven sınırı işaretlenir.
4. **Kimlik doğrulama.** Alındığı andaki `Authentication-Results` okunur, DNS kayıtlarının bugünkü hâli sorgulanır, DKIM yeniden doğrulanır.
5. **Alan adı.** Benzer alan adında kayıt tarihi RDAP'tan (.tr için TRABİS'ten), ilk TLS sertifikası sertifika şeffaflığı (Certificate Transparency) kayıtlarından bulunur. Olaydan birkaç gün önce kaydedilmiş alan adı güçlü bir işarettir.
6. **Sunucu ve hesap kayıtları.** İleti izleme, oturum açma ve posta kutusu kuralı kayıtları iletiyle eşleştirilir.
7. **Zaman çizelgesi ve rapor.** Olaylar UTC ve Türkiye saatiyle tek çizelgede birleşir.
## Raporda neler yer alır?
- İncelenen dosyaların listesi, SHA-256 değerleri ve teslim bilgisi
- Yöntem ve araçlar, sürümleriyle
- Başlık tablosu: her halka için sunucu, IP, zaman (UTC ve yerel) ve satırı hangi tarafın eklediği
- Kimlik doğrulama sonuçları ve DNS kayıtlarının inceleme tarihindeki hâli
- Sunucu kayıtlarıyla eşleştirme
- Her soru için bulgu: "uyumludur", "uyumlu değildir" ya da "mevcut materyalle belirlenemedi", dayandığı kayıtla birlikte
- Sınırlar ve sonucu güçlendirebilecek ek kayıtlar
Rapor, avukatınız tarafından dosyaya [uzman görüşü](https://www.md9.net/uzman-gorusu/) (HMK m.293) ya da ceza dosyasında bilimsel mütalaa olarak sunulabilir. Mahkemeyi bağlamaz; hâkim onu diğer delillerle birlikte değerlendirir. Hukuki nitelendirme yapmayız: "sahtecilik yapılmıştır" değil, "ileti şu kayıtlarla uyumsuzdur" deriz.
## Bu inceleme neyi gösteremez?
E-posta incelemesi klavyenin başındaki kişiyi göstermez; en iyi ihtimalle hesabı, sunucuyu ve bağlantıyı gösterir. Sunucu kayıtları silinmişse iletinin geçişi yalnızca kendi başlıklarından değerlendirilir. Elde yalnızca ekran görüntüsü varsa görüntünün iç tutarlılığına bakılabilir, o kadar. Bizce o durumda ilk iş, orijinal iletinin alıcıda ya da gönderende hâlâ durup durmadığını öğrenmektir.
## Sık sorulan sorular
### Sahte e-posta nasıl anlaşılır?
İlk bakılacak yer, alıcı sunucunun eklediği `Authentication-Results` satırıdır: DMARC sonucu `fail` ise From alanındaki alan adı doğrulanamamıştır. Ardından gösterilen adın arkasındaki gerçek adres, `Reply-To` farkı ve alan adının gerçeğine benzetilip benzetilmediği kontrol edilir. Bütün kontroller `pass` ise ileti ya gerçek (belki ele geçirilmiş) hesaptan ya da saldırgana ait benzer bir alan adından gelmiştir; bu ayrımı hesap kayıtları ve alan adının kayıt tarihi yapar.
### E-postayı gönderen kişinin IP adresi bulunabilir mi?
Çoğu zaman başlıktan bulunamaz. Başlıktaki IP'lerin çoğu sunuculara aittir; gönderen istemcinin adresini taşıyan `X-Originating-IP` standart bir alan değildir ve bazı büyük sağlayıcılar bu alanı kaldırmış ya da maskelemiştir. İstemci IP'si sağlayıcının oturum kayıtlarındadır ve mahkeme ya da savcılık eliyle istenebilir. IP bulunsa bile tek başına kişiyi göstermez; paylaşılan ağ, VPN ve [CGNAT](https://www.md9.net/adli-bilisim/ip-cgnat-analizi/) bu bağı zayıflatır.
### SPF, DKIM ve DMARC geçtiyse e-posta gerçek midir?
Bu sonuç, iletinin From alanındaki alan adının yetkili altyapısından çıktığını gösterir; iletiyi kimin yazdığını göstermez. Ele geçirilmiş gerçek bir hesaptan ya da saldırgana ait benzer bir alan adından gelen ileti de bu kontrollerden geçebilir. Tersi de geçerlidir: yönlendirme SPF'i, posta listeleri DKIM'i bozabildiği için `fail` her zaman sahtelik demek değildir.
### E-posta mahkemede delil olarak kullanılabilir mi?
HMK m.199'a göre elektronik ortamdaki veriler belgedir; e-postalar da bu kapsamda dosyaya sunulabilir. Senet hükmünde sayılan, usulüne göre güvenli elektronik imzayla oluşturulmuş elektronik verilerdir (HMK m.205/2); sıradan bir e-posta bu nitelikte değildir, DKIM imzası da bu anlamda bir imza sayılmaz. Uygulamada e-postanın ağırlığı, orijinal biçimde korunmasına ve kaynağının doğrulanabilmesine bağlıdır. Hukuki değerlendirme avukatınıza ve mahkemeye aittir.
### Karşı tarafın posta kutusunu veya sunucu kayıtlarını siz alabilir misiniz?
Hayır. Yalnızca hukuka uygun olarak elde edilmiş materyal üzerinde çalışırız: sizin posta kutunuz, kurumunuzun sunucusu ya da dosyaya girmiş kayıtlar. Karşı tarafın veya e-posta sağlayıcısının kayıtları mahkeme ya da savcılık eliyle istenebilir. Böyle bir talepte hangi kaydın hangi aralık için isteneceğini teknik olarak belirleyebiliriz.
### Aylar önce gelen bir e-posta hâlâ incelenebilir mi?
İleti posta kutusunda duruyorsa evet; başlıklar ve alındığı andaki doğrulama sonuçları iletiyle birlikte saklanır. Gönderen alan adı DKIM anahtarını değiştirmişse bugünkü doğrulama başarısız olur, ama bu iletinin sahte olduğunu göstermez. Sunucu kayıtları ise Exchange Server'da varsayılan 30, Exchange Online'da 90 gün sonra silinir; şüphe doğduğu anda dışa aktarılmalıdır.
---
# Siber olay incelemesi: yetkisiz erişim, hesap ele geçirme ve veri ihlali
URL: https://www.md9.net/adli-bilisim/siber-olay-inceleme/
Güncelleme: 2026-09-27
Siber olay incelemesi, yetkisiz erişim, hesap ele geçirme, veri ihlali ya da zararlı yazılım gibi bir olayın nasıl başladığını, hangi hesaplarla nelere erişildiğini ve hangi zaman aralığında yaşandığını log ve sistem kayıtlarından yeniden kuran teknik incelemedir. Sonuç, her bulgunun hangi kayda dayandığını gösteren bir zaman çizelgesi ve rapordur.
7545 sayılı Siber Güvenlik Kanunu siber olayı, bilişim sistemlerinin veya verinin gizlilik, bütünlük veya erişilebilirliğinin ihlal edilmesi olarak tanımlar (m.3). Bize gelen sorular daha somuttur: muhasebe hesabına kim girdi; müşteri veri tabanı dışarı çıktı mı, çıktıysa hangi kayıtlar; ayrılan çalışan sisteme erişmeye devam etti mi; web sitesine yapılan saldırı başarılı oldu mu?
Bu sayfadaki iş olayın teknik incelemesi ve raporlanmasıdır. İzole etme, temizleme ve yeniden kurma kararlarını kurumun BT ekibi ya da müdahale firması verir; incelemeyi bu adımların delili bozmayacağı sıraya göre planlarız.
## Olayın ilk saatlerinde ne yapılmalı?
İlk saatlerde yapılan her işlem ya delili korur ya da siler:
1. **Cihazı kapatmayın, yeniden kurmayın.** Yayılmayı durdurmak için ağ bağlantısını kesin, saatini not edin. Çalışan süreçler ve açık bağlantılar bellektedir, kapatınca kaybolur (RFC 3227).
2. **Kayıtları dışa aktarın.** Bulut, güvenlik duvarı ve sunucu loglarının ömrü kısadır; otomatik silmeyi durdurun.
3. **Saldırganın bıraktığını önce kaydedin, sonra kaldırın:** posta kutusu yönlendirme kuralı, yeni kullanıcı, zamanlanmış görev.
4. **Parolaları değiştirin, açık oturumları sonlandırın,** hesaba eklenmiş yeni çok faktörlü doğrulama (MFA) yöntemlerini kontrol edin.
5. **Olay günlüğü tutun:** kim, ne zaman, ne yaptı.
6. **Bildirim sürelerini hukukçunuzla değerlendirin.** Kişisel veri söz konusuysa KVKK süresi işlemeye başlamış olabilir.
Ayrıntılı kontrol listesi: [dijital delil nasıl korunur?](https://www.md9.net/bilgi/dijital-delil-nasil-korunur/)
## Hangi olayları, hangi kayıtlarla inceliyoruz?
| Olay | Cevaplanan soru | Başlıca kayıtlar |
| Yetkisiz erişim | Hangi hesapla, nereden, ne zaman girildi; neye erişildi? | Kimlik doğrulama ve VPN logları, uygulama denetim (audit) kayıtları, Windows 4624 | ``
| Hesap ele geçirme | İlk yetkisiz giriş ne zaman oldu, hesapta ne yapıldı? | Bulut oturum kayıtları, MFA değişiklikleri, posta kutusu kuralları, MailItemsAccessed | ``
| Brute-force | Deneme mi kaldı, başarılı giriş oldu mu? | 4625 ve 4740 olayları, sshd satırları, VPN ve uygulama giriş hataları |
| Web saldırıları (SQL Injection, XSS) | Açık istismar edildi mi, veri döndü mü? | Web sunucu erişim logları, WAF, uygulama ve veri tabanı logları | ``
| Yetki yükseltme | Sıradan bir hesap yönetici yetkisi aldı mı, kim verdi? | 4732, 4720, 4672; Linux'ta sudo kayıtları; uygulamadaki rol değişiklikleri |
| Zararlı ve fidye yazılımı | Nasıl girdi, ne çalıştırdı, nereye yayıldı? | 4688, 7045/4697 servis kurulumu, Prefetch, Amcache, EDR uyarıları |
| Veri ihlali ve sızıntı | Hangi veri, ne kadar, nereye çıktı? | Güvenlik duvarı ve proxy hacimleri, bulut paylaşım kayıtları, veri tabanı sorgu logları |
SIEM, IDS/IPS ve EDR uyarıları ilk ipucunu verir, kararı vermez; her uyarının arkasındaki ham kayda döneriz. Kaynak türleri için: [log analizi](https://www.md9.net/adli-bilisim/log-analizi/).
## Saldırı denemesi ile başarılı saldırı aynı şey değil
İnternete açık her sunucu her gün taranır; asıl soru denemenin başarılı olup olmadığıdır.
**Örnek (Apache erişim logu):**
```
203.0.113.45 - - [12/Mar/2026:02:11:09 +0300] "GET /urun.php?id=12%27%20OR%20%271%27%3D%271 HTTP/1.1" 500 612 "-" "sqlmap/1.8"
203.0.113.45 - - [12/Mar/2026:02:11:14 +0300] "GET /urun.php?id=-1%20UNION%20SELECT%20eposta,parola%20FROM%20uyeler-- HTTP/1.1" 200 48211 "-" "sqlmap/1.8"
```
Birinci satır bir SQL Injection denemesidir: URL-kodlu tırnak ve `OR '1'='1` kalıbı var, sunucu 500 hatası dönmüş. İkinci satırdaki olağandışı büyük yanıt veri döndüğüne işaret edebilir; kanıtı uygulama ve veri tabanı loglarındadır. Dikkat edilecekler:
- Apache'nin varsayılan erişim logu yalnızca istek satırını tutar, POST gövdesini tutmaz. Formdan yapılan enjeksiyon ya da kalıcı (stored) XSS bu logda görünmeyebilir.
- `User-Agent` istemcinin beyanıdır. "sqlmap" yazması aracı düşündürür, kanıtlamaz.
- Sunucu ters vekil ya da CDN arkasındaysa logdaki IP vekilindir; hangi alanın loglandığını yapılandırmadan doğrularız. Adresin özel, CGNAT ya da genel IP olduğunu [IP adresi kontrol aracı](https://www.md9.net/araclar/ip-adresi-kontrol/) gösterir.
- XSS denemesi `%3Cscript` gibi kalıplarla görünür; betiğin başka bir kullanıcının tarayıcısında çalışıp çalışmadığı çoğu zaman sunucu logundan gösterilemez.
Brute-force'ta da aynı ayrım geçerlidir. Windows'ta 4625 olayının alt durum kodu denemenin türünü söyler: `0xC000006A` var olan kullanıcı adına yanlış parola, `0xC0000064` var olmayan kullanıcı adıdır. Tek hesaba yığılmış yüzlerce `0xC000006A` parola tahminine (ATT&CK T1110.001), çok sayıda hesaba birkaç denemeyle yayılan girişimler parola püskürtmeye (password spraying, T1110.003) işaret eder. Aralarında çok sayıda `0xC0000064` olması, başka yerden sızmış kullanıcı adı ve parola listelerinin denendiğini (credential stuffing, T1110.004) düşündürür. Belirleyici olan, aynı kaynaktan gelen ilk başarılı 4624 kaydıdır. Linux'ta karşılığı `sshd`'nin `Failed password for invalid user` ve `Accepted password for` satırlarıdır. Açığın koddaki kaynağı ayrı bir incelemedir: [web sitesi ve web uygulaması incelemesi](https://www.md9.net/adli-bilisim/web-sitesi-inceleme/).
## Hesap ele geçirme ve şüpheli oturumlarda hangi kayıtlar belirleyici?
Hesabı ele geçiren kişi geçerli kimlik bilgileriyle girer (ATT&CK T1078); logda "başarılı giriş" görünür. Ayrımı bağlam yapar: IP ve servis sağlayıcı, ülke, cihaz ve tarayıcı, saat; bu işaretler tek tek değil birlikte okunur. MFA'nın "başarılı" görünmesi de girişi hesap sahibinin yaptığını göstermez: araya giren (adversary-in-the-middle) bir oltalama sayfası oturum çerezini ele geçirirse saldırgan MFA'ya takılmadan girebilir (ATT&CK T1539). Bu yüzden oturum kimliğini izler, o oturumun sonraki işlemlerini birlikte okuruz.
Microsoft 365'te bakılan başlıca yerler:
- **Microsoft Entra ID oturum kayıtları:** ücretsiz sürümde 7, P1/P2'de 30 gün tutulur. Olay geç fark edilirse ilk yetkisiz giriş bu pencerenin dışında kalır.
- **Birleşik denetim günlüğü:** 17 Ekim 2023'ten itibaren üretilen Audit (Standard) kayıtları 180 gün tutulur. Posta kutusu kuralı (`New-InboxRule`, `Set-InboxRule`, `UpdateInboxRules`) ve yönlendirme (`Set-Mailbox`) işlemleri burada görünür. Saldırganlar gelen iletileri RSS gibi göze batmayan klasörlere taşıyıp okundu işaretleyen kurallarla gizleyebilir.
- **`MailItemsAccessed`:** hangi iletilere erişildiğini gösterir; E3/E5 lisanslarında varsayılan olarak açıktır. Tek tek açılan iletilerde (bind) her iletinin `InternetMessageId` değeri kaydedilir. Masaüstü Outlook'la toplu indirmede (sync) kayıt klasör düzeyindedir ve o klasördeki bütün iletiler ele geçmiş kabul edilir; ihlalin kapsamını bu ayrım belirler.
Ele geçirilen hesaptan ödeme talimatı gönderildiyse iletinin kendisi de incelenir: [e-posta incelemesi](https://www.md9.net/adli-bilisim/e-posta-inceleme/).
## Yetki yükseltme ve zararlı yazılım izleri
Yetki yükseltmede aranan, sıradan bir hesabın yönetici yetkisi kazandığı an ve bunu kimin yaptığıdır. Windows'ta 4732 olayı yerel güvenlik grubuna (ör. Administrators) üye eklendiğini, ekleyen hesabı ve oturum kimliğini (Logon ID) kaydeder; bu kimlik aynı oturumun 4624 kaydına bağlanır.
Zararlı yazılım izlerinde iki ayrıntı sık yanılgı doğurur: 4688 olaylarının komut satırı alanı ilgili politika açılmadıysa boştur; Amcache'te bir dosyanın görünmesi ise sistemde bulunduğunu gösterir, çalıştırıldığını değil. Fidye yazılımında (ATT&CK T1486) şifrelenmiş dosyaların değişiklik zamanları, şifrelemenin nerede ve ne zaman başladığını gösterebilir.
Şüpheli dosyayı herkese açık tarama servislerine yüklemeyiz, yalnızca SHA-256 değeriyle sorgularız: VirusTotal, gönderilen dosyaların içeriğinin ücretli müşterileriyle paylaşılabileceğini belirtir. Değeri dosyayı hiçbir yere göndermeden [hash hesaplama aracıyla](https://www.md9.net/araclar/hash-hesaplama/) bulabilirsiniz.
## Veri ihlalinde teknik inceleme ve KVKK bildirimi
KVKK m.12/5'e göre işlenen kişisel veriler kanuni olmayan yollarla başkalarınca elde edilirse veri sorumlusu bunu en kısa sürede ilgilisine ve Kurul'a bildirir. Kurul'un 2019/10 sayılı kararına göre Kurul'a bildirim öğrenme tarihinden itibaren gecikmeksizin ve en geç 72 saat içinde, ilgili kişilere makul en kısa sürede yapılır; bilgiler aşamalı verilebilir, 72 saat aşılırsa gecikmenin nedeni eklenir. İhlalin bilgileri, etkileri ve tedbirler kayıt altında tutulur.
Bildirimin teknik soruları incelemeyle cevaplanır:
- İhlal ne zaman başladı, ne zaman fark edildi, ne zaman durduruldu?
- Hangi veri kategorileri, yaklaşık kaç kayıt ve kişi etkilendi?
- Giriş yolu neydi, erişim sürüyor mu?
- Hangi teknik tedbirler alındı?
İlk uyarının ne zaman üretildiği ve kime ulaştığı kayıtlardan gösterilebilir; bunun hukuken "öğrenme" anı sayılıp sayılmayacağı veri sorumlusunun ve hukukçusunun kararıdır. 7545 sayılı Kanun da kapsamındakilere, tespit ettikleri zafiyet veya siber olayları gecikmeksizin Siber Güvenlik Başkanlığına bildirme yükümlülüğü getirir (m.7/1-b); kurumunuzun kapsamda olup olmadığı ayrıca değerlendirilir.
## Siber olay zaman çizelgesi nasıl kurulur?
Zaman çizelgesi, farklı sistemlerin kayıtlarının tek bir saat eksenine dizilmesidir. Adımlar:
1. Kayıtlar dışa aktarılır; her dosyanın SHA-256 değeri, kimden ve nasıl alındığı yazılır.
2. Her kaynağın saat dilimi ve sapması belirlenir. Windows olay günlükleri UTC, Nginx'in `$time_local` alanı yerel saat tutar; sapmayı 4616 olayları ve NTP durumu gösterir.
3. Zamanlar UTC'ye çevrilir, yanına Türkiye saati (2016'dan beri UTC+3) yazılır. Ayrıntı: [zaman damgaları ve saat dilimi](https://www.md9.net/bilgi/zaman-damgasi-saat-dilimi/).
4. Olaylar ortak anahtarlarla bağlanır: hesap adı, IP, oturum kimliği, dosya hash'i.
5. Her satır ham kayda bağlanır; kayıt ile yorum ayrı sütunda durur.
**Örnek (kurgusal) çizelge kesiti:**
| Zaman (UTC) | Kaynak | Kayıt | Yorum | ``
| 2026-03-11 23:02 | VPN ağ geçidi | 203.0.113.45'ten muhasebe2 hesabına 36 dakikada 312 başarısız giriş | Parola denemesi (T1110) |
| 2026-03-11 23:38 | VPN ağ geçidi | Aynı IP'den aynı hesapla başarılı giriş | Geçerli hesapla giriş (T1078) | ``
| 2026-03-12 00:15 | Dosya sunucusu, 4732 | muhasebe2 Administrators grubuna eklendi | Yetki yükseltme; ekleyen hesap Logon ID ile izlenir |
| 2026-03-12 00:52 | Güvenlik duvarı | 198.51.100.7'ye 4,2 GB çıkış | Olası veri çıkışı (TA0010) |
| 2026-03-12 01:20 | Dosya sunucusu, 1102 | Güvenlik günlüğü temizlendi | İz silme girişimi |
Teknikleri MITRE ATT&CK sürümüyle yazarız: v19'da (Nisan 2026) "Defense Evasion" taktiği "Stealth" (TA0005) ve "Defense Impairment" (TA0112) olarak ikiye ayrıldı; eski raporlarla karşılaştırmada bu fark önemlidir.
## Olay müdahale kayıtlarının incelenmesi
Olaya daha önce BT ekibi ya da dış firma müdahale ettiyse onların kayıtları da incelenir: olay biletleri, EDR konsolu işlemleri, alınan imajlar, parola sıfırlamaları. İki soru sorarız: müdahalede hangi izler istemeden değişti, müdahale raporundaki sonuçlar ham veriden gerçekten çıkıyor mu? Referansımız, olay müdahalesini CSF 2.0 fonksiyonlarıyla ilişkilendiren NIST SP 800-61 Rev. 3'tür (Nisan 2025); 2012 tarihli Rev. 2'nin yerini almıştır.
## Raporda neler yer alır?
- İncelenen kayıt ve imajların listesi, SHA-256 değerleri ve teslim bilgisi
- Kaynak başına saat dilimi ve sapma notu
- Olay zaman çizelgesi (UTC ve Türkiye saati), her satırın dayandığı kayıtla
- Giriş yolu, kullanılan hesaplar, erişilen sistemler ve veriler; sürümüyle ATT&CK eşlemesi
- Gösterge listesi: IP, alan adı, dosya hash'i
- Bulgu dili: "gösterir", "ile uyumludur", "mevcut kayıtlarla belirlenemedi"
- Sınırlar: eksik kayıtlar, doğrulanamayan varsayımlar
Rapor şirket içi karar ve bildirimlerde ya da avukatınız aracılığıyla uzman görüşü olarak kullanılabilir. Suçun oluşup oluşmadığı ya da kusur gibi hukuki değerlendirmeler rapora girmez.
## İncelemenin sınırları
En sık sınır, kaydın hiç tutulmamış olmasıdır: süreç oluşturma denetimi kapalıdır, uygulama başarısız girişi yazmaz, loglar birkaç günde döner. Saldırganın sistemlerine erişmeyiz, karşı saldırı yapmayız; yalnızca hukuka uygun elde edilmiş kayıtlarla çalışırız. Bir kaydın yokluğu olayın yaşanmadığını göstermez; raporda bunu açıkça yazarız.
## Sık sorulan sorular
### Hesabımın ele geçirildiğini nasıl anlarım?
En güvenilir iz hesabın oturum kayıtlarıdır: tanımadığınız bir IP'den ya da ülkeden, alışılmadık bir cihazdan veya saatte yapılmış başarılı girişler. E-posta hesaplarında ayrıca yeni oluşturulmuş yönlendirme ve taşıma kuralları, hesaba eklenmiş MFA yöntemleri ve sizin yazmadığınız gönderilmiş iletiler aranır. Kuralları silmeden önce dışa aktarın.
### KVKK'ya veri ihlali bildirimi için 72 saat ne zaman başlar?
Kurul'un 2019/10 sayılı kararına göre süre, veri sorumlusunun ihlali öğrendiği tarihten itibaren işler; bildirim gecikmeksizin ve en geç 72 saat içinde yapılır, bilgiler gerekirse aşamalı verilir. Hangi anın öğrenme sayılacağı hukuki bir değerlendirmedir; biz ilk uyarının ve ilk tespitin zamanını kayıtlardan gösterebiliriz.
### Saldırganın kim olduğu tespit edilebilir mi?
Teknik inceleme çoğu zaman saldırının kullandığı altyapıyı gösterir: IP adresleri, alan adları, hesaplar ve araçlar. Buradan gerçek kişiye ulaşmak, VPN, ele geçirilmiş ara sunucular ve CGNAT yüzünden çoğu zaman sağlayıcı kayıtları gerektirir; bunlar savcılık veya mahkeme eliyle istenebilir (bkz. [IP adresi tek başına delil mi?](https://www.md9.net/bilgi/ip-adresi-delil-mi/)). Raporda altyapıyı ve kimlik tespitinin sınırlarını ayrı ayrı yazarız.
### Log kayıtları silinmişse inceleme yapılabilir mi?
Çoğu zaman kısmen. Temizlenen Windows güvenlik günlüğü arkasında 1102 olayını bırakır. Aynı olaylar SIEM'de, güvenlik duvarında, bulut kayıtlarında, gölge kopyalarda ya da yedeklerde durabilir. Silinmiş log dosyaları diskten kurtarılabilir, SSD'lerde bu ihtimal düşüktür. Bir kaydın bulunamaması olayın yaşanmadığını göstermez.
### Olaydan sonra bilgisayarları yeniden kurduk, inceleme hâlâ mümkün mü?
Yeniden kurulan makinedeki izler büyük ölçüde kaybolur, ama olay nadiren tek makinede kalır. Güvenlik duvarı, VPN, e-posta ve bulut kayıtları, etki alanı denetleyicisi olayları ve yedekler olayın ana hatlarını kurmaya çoğu zaman yeter. Hangi soruların cevaplanabileceğini ön değerlendirmede söyleriz.
### Siber olay raporu mahkemede kullanılabilir mi?
Rapor avukatınız tarafından dosyaya uzman görüşü ya da ceza dosyasında bilimsel mütalaa olarak sunulabilir. Mahkemeyi bağlamaz; hâkim onu diğer delillerle birlikte değerlendirir, gerekirse bilirkişi incelemesi yaptırır. Ağırlığı, her bulgunun dayandığı ham kaydın ve kayıt bütünlüğünün açıkça gösterilmesine bağlıdır. Ayrıntı: [uzman görüşü](https://www.md9.net/uzman-gorusu/).
---
# Sosyal medya hesap incelemesi: paylaşımlar, giriş kayıtları ve ele geçirme iddiaları
URL: https://www.md9.net/adli-bilisim/sosyal-medya-inceleme/
Güncelleme: 2026-09-27
Sosyal medya hesap incelemesi, bir hesap ya da paylaşım hakkındaki iddiaların (paylaşımı hangi hesap, ne zaman yaptı; hesaba kim, hangi cihazdan girdi; hesap ele geçirildi mi) platform dışa aktarımları, giriş kayıtları, bağlantılar ve dosya metadata'sı üzerinden değerlendirildiği teknik incelemedir. Ekran görüntüsünün taşımadığı kimlik, zaman ve bütünlük bilgisini kayıtlardan çıkarır, kaydın cevaplamadığı soruyu da raporda açıkça yazarız.
Bu dosyalar çoğunlukla bir ekran görüntüsüyle başlar: bir paylaşım, "hesabım çalındı, o mesajları ben göndermedim" savunması, bir şirketin adını kullanan taklit hesap. İlk iş, iddiayı teknik bir soruya çevirmek ve cevabı taşıyan kaydın kimde olduğunu bulmaktır: hesap sahibinde mi, platformda mı, servis sağlayıcıda mı?
## Hangi iddiada hangi kayda bakılır?
| İddia | Bakılan kayıt | Kaydın tek başına gösteremediği |
| Paylaşımı bu hesap yaptı | Tam URL, sayısal hesap ve gönderi kimliği, platform dışa aktarımı, zaman damgalı edinim | Hesabı o anda fiilen kimin kullandığı |
| Paylaşım şu gün, şu saatte yapıldı | Dışa aktarımdaki zaman damgası, sayfa kaynağı, X'te gönderi kimliği | Gönderinin sonradan düzenlenip düzenlenmediği (platform göstermiyorsa) |
| Hesabım ele geçirildi | Giriş ve oturum kayıtları, güvenlik e-postaları, şifre ve e-posta değişikliği zamanları, cihaz izleri | Girişi yapan kişinin kimliği |
| Bu sahte hesabı şu kişi açtı | Profil arşivi, katılma tarihi, eski kullanıcı adı sayısı, içerik ve bağlantı örtüşmeleri | Platform kaydı olmadan hesap sahibinin kimliği |
## Sosyal medya hesabına ilişkin teknik kayıtlar nelerdir?
Kayıt üç yerde oluşur: platformda, hesabı kullanan cihazlarda ve hesaba bağlı e-posta ile telefon hattında.
**Sayısal hesap ve gönderi kimlikleri**
: Kullanıcı adı her an değişebilir; platformun hesaba ve gönderiye verdiği kimlik değişmez.
**Hesap erişim kayıtları**
: Instagram ve Facebook'ta Hesaplar Merkezi → Şifre ve güvenlik → Giriş yaptığın yerler ekranı son girişleri listeler ([Instagram Yardım Merkezi](https://www.facebook.com/help/instagram/2761108904184084)); dışa aktarımda karşılığı, Meta'nın "hesabınızla ilgili teknik bilgiler ve kayıtlı hareketler" dediği Güvenlik ve Giriş Bilgileri kategorisidir. Ekrandaki şehir adını konum kanıtı saymayız.
**Güvenlik bildirimleri**
: Şifre, e-posta veya iki adımlı doğrulama değişince gelen iletilerin orijinalleri (`.eml`); alıcı sunucunun `Received` satırı değişikliğin zamanına bağımsız tanıktır ([e-posta başlık analizi aracı](https://www.md9.net/araclar/e-posta-baslik-analizi/)).
**Profil şeffaflık bilgisi**
: Instagram'ın "Bu hesap hakkında" bölümü katılma tarihini ve eski kullanıcı adı sayısını gösterir ([Instagram Yardım Merkezi](https://www.facebook.com/help/instagram/697961817256175)). Hesap kapanınca kaybolduğu için hemen kaydederiz.
**Cihaz tarafı**
: Uygulama veri tabanları, önbellek ve bildirimler ([mobil cihaz incelemesi](https://www.md9.net/adli-bilisim/mobil-cihaz-inceleme/)).
## Platformlardan veri nasıl indirilir: Meta, Google Takeout, X arşivi
Hesap sahibi kendi verisini platformun dışa aktarım aracıyla indirebilir; çoğu dosyada en zengin kayıt budur. Dışa aktarımı siz talep edersiniz, şifrenizi bizimle de paylaşmayın.
| Platform | Nereden | Dikkat edilecekler |
| Instagram, Facebook | Ayarlar → Hesaplar Merkezi → Bilgilerin ve izinlerin → Bilgilerini dışa aktar → Dışa aktarım oluştur → Cihaza aktar | Tarih aralığı, biçim ve medya kalitesi seçilir. Veri kayıtları yalnızca "belirli bilgi türleri" seçildiğinde pakete girer. Bağlantının gelmesi 30 güne kadar sürebilir, hazır dosya 4 gün indirilebilir. Silinen içerik pakette yoktur. | [](https://support.google.com/accounts/answer/3024190?hl=tr)
| Google hesabı, YouTube | Google Takeout | ZIP veya TGZ. Arşiv yaklaşık 7 gün geçerlidir, en fazla 5 kez indirilebilir. |
| X | Ayarlardaki "verilerinizin arşivini indirin" seçeneği | Arşivin yapısı ve hangi giriş ve cihaz bilgilerini taşıdığı sürüme göre değişebilir; dosyayı açınca doğrularız. |
1. Meta'da biçim olarak JSON'u seçin; analiz araçları onu doğrudan işler.
2. Talep tarihini ve "dosyan hazır" e-postasını saklayın.
3. ZIP'i açmadan SHA-256 değerini alın; [hash hesaplama aracı](https://www.md9.net/araclar/hash-hesaplama/) dosyayı yüklemeden tarayıcıda hesaplar.
4. Yalnızca bir kopya üzerinde çalışın.
Meta JSON'unda zaman alanları (`timestamp`, mesajlarda çoğunlukla `timestamp_ms`) Unix zaman damgasıdır; birimi, zamanını bildiğimiz bir mesajla doğrularız. Türkçe karakterlerin bozuk görünmesi (`ü` yerine `ü`) veri değişikliği değil, bilinen bir kodlama hatasıdır.
Karşı tarafın hesabına girmeyinBaşkasının hesabına girmek ya da oturumu açık kalmış bir cihazdan onun verisini indirmek, veriyi kullanılamaz hâle getirebilir: hukuka aykırı elde edilen deliller hukuk yargılamasında dikkate alınamaz (HMK m.189/2), ceza yargılamasında reddolunur (CMK m.206/2-a). Yalnızca hesap sahibinin kendi verisiyle ve resmî yoldan temin edilmiş kayıtlarla çalışırız.
## Karşı tarafın hesap kayıtlarına nasıl ulaşılır?
Başka birinin hesap kayıtları yalnızca resmî yoldan istenebilir. Türkiye'den günlük erişimi bir milyonu aşan yurt dışı kaynaklı sosyal ağ sağlayıcılar Türkiye'de temsilci belirlemek zorundadır (5651 s.K. Ek m.4/1). Temsilcinin faillere ulaşmak için gerekli bilgileri savcı ya da mahkeme talebiyle adli mercilere vermesini öngören Ek m.4/5 ise yalnızca sayılan suçlar içindir: TCK m.103, 217/A, 302, 309, 311–316, 328–331 ve 333–337. Hakaret ya da tehdit gibi listede olmayan suçlarda platformun kendi kolluk politikası ve uluslararası adli yardım gündeme gelir.
Meta, resmî süreç beklenirken hesap kayıtlarını 90 gün koruma altına alabildiğini, geçerli bir koruma talebi yoksa kullanıcının sildiği içeriği saklamadığını ve içeriğin açıklanması için adli yardım talebi (MLAT) ya da istinabe gerekebileceğini yazıyor. Hız bu yüzden önemlidir. Yolu seçmek avukatın ve savcılığın işidir; biz hangi hesap kimliği, tarih aralığı ve veri türünün (giriş IP'si, kaynak port, saat dilimi belirtilmiş saniye hassasiyetinde zaman) istenmesi gerektiğini bir teknik notla yazarız.
Tarih notu5651 sayılı Kanundaki yetkili idare 31.07.2026'dan beri Siber Güvenlik Başkanlığıdır (7590 s.K.). Ek m.4'te 7578 sayılı Kanunla yapılan değişiklikler 01.11.2026'da yürürlüğe girecek; bu tarihten sonra güncel metne bakılmalıdır.
## Instagram hesap ele geçirme iddiası nasıl incelenir?
Amaç, hesabın kontrolünün ne zaman ve nasıl el değiştirdiğini ve tartışmalı içeriğin bu aralığa düşüp düşmediğini göstermektir. Olay tazeyse önce hesap geri alınır: Instagram bunun için `instagram.com/hacked` adresini, e-posta değiştirildiyse `security@mail.instagram.com` adresinden gelen iletideki güvenceye alma bağlantısını gösteriyor. Bu iletileri silmeyin.
1. **Zaman çizelgesi iskeleti.** Son meşru giriş, şifre, e-posta ve telefon değişiklikleri, iki adımlı doğrulamanın kapatılması, tartışmalı içerik. Her olay UTC'ye çevrilir ve kaynağıyla yazılır.
2. **Giriş kayıtları.** Dışa aktarımdaki giriş hareketleri, hesap sahibinin bilinen cihazları ve bağlantılarıyla karşılaştırılır.
3. **Giriş yolu.** Oltalama iletisiyle alınan şifre, çalınmış oturum çerezi, SIM değişikliğiyle ele geçirilen doğrulama kodu ya da hesaba bağlanmış üçüncü taraf uygulama.
4. **Cihaz izleri.** Hesap sahibinin telefonunda o saatlerde uygulamanın kullanılıp kullanılmadığı.
5. **Tespit.** Kayda dayanan, sınırı belli bir cümle: "Tartışmalı mesajlar, hesaba bağlı e-posta adresinin değiştirilmesinden sonra ve hesap sahibinin bilinen cihazlarıyla ilişkilendirilemeyen bir oturumdan gönderilmiştir."
Sınır şudur: platformun gösterdiği IP çoğu zaman servis sağlayıcının paylaşımlı adresidir; CGNAT arkasında aboneye inmek için kaynak port ve saniye hassasiyetinde zaman gerekir. Yargıtay, suç tarihine ait CGNAT verileri getirtilmeden ve IP'nin sanıkça kullanıldığı kesin verilerle belirlenmeden kurulan mahkûmiyeti bozmuştur (Yarg. 17. CD, E.2018/5732, K.2019/7785). Ayrıntı: [IP ve CGNAT analizi](https://www.md9.net/adli-bilisim/ip-cgnat-analizi/). Kurumsal hesaplarda ya da birden fazla sistemi etkileyen olaylarda [siber olay incelemesi](https://www.md9.net/adli-bilisim/siber-olay-inceleme/) daha uygun çerçevedir.
## Paylaşım zamanı nasıl belirlenir?
Arayüzdeki "3 sa" ya da "2 g" gibi göreli zamanlar yetersizdir; tam tarih de ekranı açan cihazın saat dilimine göre biçimlenir. Tam zamanı üç kaynaktan alır, birbirleriyle sınarız:
- **Dışa aktarım.** Unix zaman damgasını [zaman damgası dönüştürücü](https://www.md9.net/araclar/zaman-damgasi-donusturucu/) UTC'ye ve Türkiye saatine çevirir.
- **Sayfa kaynağı.** Web arayüzü tam zamanı çoğu zaman makinece okunur bir öznitelikte taşır (ör. `