Ücretsiz ön görüşmeHukuka uygunluk ön testi81 ilde sahaYazılı kapsam · KVKK
WhatsApp'tan yazın →
Kanıt Dedektiflik
Dijital Delil ve OSINT Güncelleme: 42 dk okuma

Dijital Delilin Mahkemede Kabulü: Hash, Metadata ve Bütünlük

Dijital delil mahkemede nasıl kabul edilir? HMK m.199, imaj ve hash, e-posta başlığı, metadata, bulut verisi, bilirkişi süreci ve e-imza rehberi.

Kanıt Dedektiflik Editör MasasıMevzuat kontrolü yapılmıştır

Kısa cevap

Dijital delil, HMK m.199 uyarınca belge sayılan elektronik veridir. Hukuka uygun elde edildiyse mahkemede ağırlığı dört teknik soruya bağlıdır: Kaynağı gösterilebiliyor mu, elde edildiğinden beri değişmedi mi, zamanı bağımsız kayıtlarla doğrulanıyor mu, bağlamıyla eksiksiz mi? Hash bütünlüğü, e-posta başlığı ve metadata kökeni, sunucu kayıtları zamanı gösterir; itirazda tartışmayı çoğunlukla HMK m.266 vd. uyarınca atanan bilirkişi çözer.

  • Elektronik veri HMK m.199 uyarınca belgedir ve hâkimce serbestçe değerlendirilir; yalnızca usulüne göre güvenli elektronik imzayla oluşturulan veri HMK m.205/2 uyarınca senet hükmündedir.
  • E-postanın özgünlüğü ekrandaki gönderen adıyla değil, alıcı sunucunun yazdığı Received satırları, DKIM imzası ve kimlik doğrulama sonuçlarıyla tartışılır; iletmek (forward) ve PDF'e yazdırmak bu katmanı siler.
  • Metadata tek başına kesin kanıt değildir; belge içi alanlar, dosya sistemi kayıtları ve bulut sürüm geçmişi birbirini tuttuğunda güçlü bir zaman ve köken göstergesine dönüşür.
  • Hash yalnızca hesaplandığı andan sonraki değişmezliği gösterir; 5070 sayılı Kanun'daki zaman damgası bu hash'e tarih verir, güvenli elektronik imza ise kimlik ve bütünlüğü birlikte bağlar.
  • Bilirkişi ret talebi sebebin öğrenilmesinden itibaren bir hafta, rapora itiraz tebliğden itibaren iki hafta içinde yapılır; bilirkişi raporunda hukuki nitelendirme yapamaz (HMK m.272, 281, 279/4).
İçindekiler
Dijital Delilin Mahkemede Kabulü: Hash, Metadata ve Bütünlük

Bir dosyanın mahkemede işe yaraması için içeriğinin ikna edici olması yetmez; o içeriğin nereden geldiğini, ne zaman oluştuğunu ve o günden bu yana değişmediğini gösteren teknik kayıtların da ayakta kalması gerekir. Dijital delilin mahkemede kabulü bu yüzden çoğu dosyada içerik tartışmasından önce bir köken ve bütünlük tartışmasıdır. Karşı taraf "bu e-postayı ben göndermedim", "bu belge o tarihte yoktu" ya da "bu dosya sonradan değiştirildi" dediğinde cevap ekrandaki görüntüde değil; e-postanın başlık satırlarında, belgenin üst verisinde, sunucunun kayıtlarında ve hash değerlerinde aranır.

Bu rehber o teknik katmana odaklanıyor. Hukuka uygunluk, ilgililik ve zamanlama gibi genel ölçütleri delilin kabul edilebilirliğine ilişkin yedi kriter yazısında ele aldık. Burada imaj alma stratejisi, hash'in neyi kanıtlayıp neyi kanıtlamadığı, 5070 sayılı Elektronik İmza Kanunu ve zaman damgası, e-posta başlığı ve metadata analizi, bulut verisi, ekran görüntüsü ile orijinal veri arasındaki fark, HMK m.266 vd. kapsamındaki bilirkişi süreci ve ceza yargılamasındaki çerçeve anlatılıyor.

Anlatım teknik terimlerden kaçmıyor, ama her terimi ilk geçtiği yerde açıklıyor. Amaç sizi bir adli bilişim uzmanına dönüştürmek değil. Elinizdeki verinin hangi sorulara cevap verebileceğini, hangilerine veremeyeceğini ve avukatınızla birlikte hangi adımı ne zaman atmanız gerektiğini görebilmenizi sağlamak.

Dijital delil nedir? HMK m.199 ve elektronik verinin hukuki niteliği

Dijital delil, uyuşmazlık konusu bir vakıayı ispata elverişli olan ve elektronik, optik veya benzeri yollarla üretilen, taşınan ya da saklanan veridir. Hukuk yargılamasında HMK m.199 bu verileri açıkça belge sayar; bir e-posta, bir PDF, bir sistem kaydı ya da bir bulut klasöründeki sürüm geçmişi, kâğıt bir belge gibi delil olarak sunulabilir.

Belge olmak, kesin delil olmak demek değildir. HMK m.198'e göre kanuni istisnalar dışında hâkim delilleri serbestçe değerlendirir. Sıradan bir e-posta, bir Word dosyası ya da bir ekran kaydı bu serbest değerlendirmeye tabidir; ağırlığını kaynağının ve bütünlüğünün ne kadar iyi gösterildiği belirler. Güvenli elektronik imzalı veri ise senet hükmünde olduğu için, senetle ispat zorunluluğunun bulunduğu işlemlerde de kullanılabilir ve imza inkâr edildiğinde tartışma imzanın teknik doğrulamasına kayar.

Elektronik veri türü Hukuki konumu Özgünlüğü gösteren Tipik itiraz
Sıradan dosya (Word, PDF, tablo, fotoğraf) HMK m.199 belge; serbest değerlendirme Üst veri, kaynak cihaz, hash, bağımsız kayıtlar "Sonradan hazırlandı", "değiştirildi"
E-posta iletisi Belge; imzasızsa senet değildir Başlık satırları, DKIM imzası, sunucu kayıtları "Ben göndermedim", "içerik değişti"
Güvenli elektronik imzalı veri Senet hükmünde (HMK m.205/2) İmza doğrulaması, nitelikli sertifika Sertifikanın geçerliliği, temsil yetkisi
Kayıtlı elektronik posta (KEP) iletisi Tacirler arası bazı ihbar ve ihtarların kanuni yollarından biri (TTK m.18/3) Sağlayıcının gönderim ve teslim kayıtları İçeriğin yorumu; nadiren gönderimin kendisi
Zaman damgalı dosya Damgalama anında o içerikle var olduğunun kaydı (5070 m.3) Damgadaki hash ile dosya hash'inin eşleşmesi "Asıl oluşturma anı başka"
Sistem ve sunucu kaydı (log) Belge; çoğu zaman üçüncü kişinin elindedir Kaydı tutan sistemin bütünlüğü, saat eşitlemesi "Saat yanlış", "kayıt eksik"
Barkodlu kurum çıktısı Düzenleyen kurumun kaydına dayanır Kurumun doğrulama servisinden alınan sonuç Belgenin güncelliği

"İncelemeye elverişli" biçim ne demektir?

HMK m.219'daki "incelemeye elverişli" ifadesi, pratikte bilirkişinin üzerinde çalışabileceği biçimi anlatır. Bir e-postanın PDF çıktısı okunabilir, ama incelenemez; içinde başlık satırları, imza bilgisi ve ekin orijinali yoktur. İncelemeye elverişli biçim, verinin doğduğu formattaki hâlidir: e-posta için ham ileti dosyası, belge için orijinal Word ya da PDF dosyası, kayıt için sistemin ürettiği dosya.

Bu yüzden dosyaya genellikle iki katman birlikte konur. Hâkimin ve karşı tarafın okuyacağı açıklamalı çıktılar ile bilirkişinin inceleyeceği orijinal dosyaları içeren bir veri ortamı. İkinci katmanın yanına her dosyanın adını, boyutunu ve hash değerini gösteren bir liste eklenir. Liste, çıktıdaki sayfa ile ortamdaki dosya arasında köprü kurar: "Ek-4'teki çıktı, ortamdaki şu dosyanın görüntüsüdür."

Mahkeme dijital delilde neye bakar? Dört teknik soru

Hukuka uygun elde edilmiş bir dijital delil karşısında hâkim ve bilirkişi dört soruya cevap arar: Veri iddia edilen kaynaktan mı geliyor, elde edildiği andan beri değişmedi mi, iddia edilen zamanda mı oluştu ve bağlamıyla eksiksiz mi sunuluyor? Bu dört soru köken, bütünlük, zaman ve tamlık diye özetlenebilir; her birinin kendine özgü teknik dayanakları vardır.

Soru Teknik dayanak Güçlendiren Zayıflatan
Köken: Kimden, hangi sistemden? E-posta başlığı, DKIM, hesap ve cihaz kimlikleri, belge üst verisi Sunanın kontrol etmediği bağımsız bir kayıt Yalnızca çıktı veya ekran görüntüsü
Bütünlük: Değişti mi? Hash değeri, imaj, elektronik imza Edinme anında hesaplanmış hash Geç hesaplanan hash, orijinal üzerinde çalışma
Zaman: Ne zaman oluştu? Sunucu zaman kayıtları, dosya sistemi, zaman damgası Birbirinden bağımsız saatlerin örtüşmesi Tek kaynaklı, cihaz saatine dayalı tarih
Tamlık: Bütün mü? Tam yazışma zinciri, tam dışa aktarma, sürüm geçmişi Seçim ölçütünün yazılı olması Seçilmiş parçalar, kesilmiş zincir

Dört sorunun öncesinde bir ön koşul vardır: Delilin hukuka uygun elde edilmiş olması. Anayasa m.38/6, HMK m.189/2 ve ceza yargılamasında CMK m.206/2-a ile m.217/2 bu kapıyı belirler. Teknik açıdan kusursuz bir veri, başkasının hesabına girilerek elde edilmişse dört sorunun hiçbirine sıra gelmeyebilir.

Bağımsız kaynak ilkesi

Dijital delillerin ağırlığını belirleyen en pratik ölçüt, delili doğrulayan bir kaydın sunan tarafın kontrolü dışında bulunup bulunmadığıdır. Kendi bilgisayarınızda duran bir belgenin tarihi, sonuçta sizin sisteminizin söylediği tarihtir. Aynı belgenin üç ay önce bir müşteriye e-posta eki olarak gittiğini gösteren, alıcı şirketin sunucusundaki kayıt ise sizin değiştiremeyeceğiniz bir tanıktır.

Bu ilke dosya hazırlarken sorulacak soruyu da değiştirir. "Bu dosyayı nasıl daha inandırıcı gösteririm?" yerine "Bu dosyanın varlığını ve tarihini benden bağımsız olarak hangi sistem doğrulayabilir?" diye sormak gerekir. Karşı tarafın sunucusu, bir bulut sağlayıcının sürüm geçmişi, bir bankanın işlem kaydı, bir kargo şirketinin teslim kaydı ya da bir zaman damgası sağlayıcısı bu sorunun tipik cevaplarıdır.

İmaj alma: Tam imaj, hedefli toplama ve canlı edinim

İmaj alma, bir depolama ortamının birebir adli kopyasını çıkarmaktır; ama her dosyada tam disk imajı ne gerekli ne de mümkündür. Edinme yöntemi; verinin nerede durduğuna, cihazın açık ya da kapalı olmasına, şifrelemeye, uyuşmazlığın ağırlığına ve kişisel verilerin ölçülü işlenmesi ilkesine göre seçilir ve gerekçesiyle yazılır.

Yazma engelleyici, adli imaj formatları ve edinme kaydının temel unsurları delil zincirinin dokuz halkasını anlattığımız rehberde ele alındı. Burada seçim mantığına odaklanıyoruz: Hangi durumda hangi edinme stratejisi tercih edilir ve her birinin bedeli nedir?

Edinme stratejisi Ne alır? Ne zaman tercih edilir? Sınırı
Tam fiziksel imaj Silinmiş ve kullanılmayan alanlar dahil bütün ortam Silme şüphesi, kapsamlı kurumsal inceleme, şirket cihazı Büyük hacim; ilgisiz kişisel veri; şifreli diskte anahtar gerekir
Mantıksal imaj Bir bölüm veya klasördeki görünür dosya sistemi içeriği Belirli kullanıcı profili veya proje klasörü Silinmiş alanlar dışarıda kalır
Hedefli toplama Önceden tanımlanmış dosya türleri, tarih aralığı, anahtar kelimeler Ölçülülüğün öne çıktığı işyeri incelemeleri Ölçüt dışında kalan delil kaçabilir; ölçüt yazılı olmalıdır
Canlı edinim Bellek, açık oturumlar, ağ bağlantıları, şifresi çözülmüş birimler Cihaz açık, disk şifreli veya bulut oturumu açık İşlemin kendisi sistemde iz bırakır; her adım kaydedilir
Mobil edinim Mantıksal veya dosya sistemi düzeyinde telefon verisi Telefon ve tabletler Sonuç modele ve yazılım sürümüne bağlıdır
Hesap ve bulut edinimi Sunucudaki içerik, sürümler, erişim kayıtları Veri cihazda değil, sağlayıcının sunucusunda Yetki; sağlayıcının dışa aktarma biçimi

Hedefli toplama ve ölçülülük

Kurumsal bir incelemede çalışanın kullandığı şirket bilgisayarının tamamını imajlamak teknik olarak en güvenli yol gibi görünür. Ama o diskte çoğu zaman çalışanın sağlık raporları, aile fotoğrafları ve özel yazışmaları da vardır. KVKK m.4'teki "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" ilkesi, toplanacak verinin kapsamını uyuşmazlıkla sınırlamayı gerektirir.

Burada iki yaklaşım birlikte kullanılabilir. Tam imaj alınıp mühürlü olarak saklanır, inceleme ise yazılı ölçütlerle sınırlanır; ya da baştan hedefli toplama yapılır ve ölçüt edinme kaydına yazılır. İkinci yolda karşı tarafın "lehime olan dosyalar toplanmadı" itirazı beklenir. Bu itiraza verilecek cevap, ölçütün inceleme başlamadan önce belirlenmiş ve belgelenmiş olmasıdır.

Şifreleme, kapatma kararı ve canlı edinim

Modern dizüstü bilgisayarların ve telefonların çoğunda depolama şifrelidir. Açık ve oturumu açık bir cihazda veriler o anda okunabilir durumdadır; cihaz kapatıldığında ise kurtarma anahtarı veya parola olmadan imaj anlamsız bir veri yığınına dönüşebilir. Bu yüzden "cihazı hemen kapatın" refleksi her dosyada doğru değildir.

Canlı edinim, açık bir sistemden bellek içeriğinin, açık oturumların ve şifresi çözülmüş birimlerin alınmasıdır. Kaçınılmaz olarak sistemde küçük değişiklikler yaratır: araç çalışır, belleğe yüklenir, bazı kayıtlar oluşur. Bu değişiklikler kusur değildir, ama kayıt altına alınmazsa itiraz malzemesine dönüşür. Hangi aracın, hangi sırayla, hangi saatte çalıştırıldığı ve neden canlı edinimin tercih edildiği yazılı olmalıdır.

SSD, telefon ve silinmiş verinin sınırları

Klasik manyetik disklerde silinen bir dosya, üzerine yeni veri yazılana kadar çoğu zaman fiziksel olarak yerinde durur. SSD'lerde ise işletim sistemi, silinen blokları diske bildiren bir komutla temizlenmeye işaretleyebilir ve disk bu alanları kısa sürede boşaltabilir. Şifrelemeli modern telefonlarda silinen dosyanın şifreleme anahtarı da yok edildiği için, içerik çoğu zaman kurtarılamaz.

Bu gerçek, iki yönde beklenti yönetimi gerektirir. Bir tarafta "silinen her şey geri getirilir" vaadi gerçekçi değildir. Öte yandan silinen içeriğe ulaşılamasa bile silme işleminin kendisi; dosya sistemi günlüklerinde, bulut sürüm geçmişinde ya da yazışmanın karşı tarafındaki kopyada iz bırakabilir. Silme davranışının hukuki sonuçlarını ve meşru gizlilik temizliğiyle farkını dijital iz silme ile delil koruma arasındaki denge yazısında ayrıca ele aldık.

Bulutla eşitlenen klasör tuzağı

Bulut depolama istemcilerinin çoğu, disk alanından tasarruf için dosyaların yalnızca yer tutucusunu bilgisayarda bırakır; içerik ancak açıldığında sunucudan indirilir. Böyle bir bilgisayarın imajında dosya adları ve klasör yapısı görünür, ama içeriklerin önemli bir kısmı bulunmaz. Kurumsal incelemelerde bu nedenle cihaz imajı ile bulut hesabının edinimi birlikte planlanır.

Aynı eşitleme, ters yönde de sürpriz yaratabilir. Cihaz incelenmeyi beklerken internete bağlı kalırsa, buluttaki bir silme işlemi cihaza da yansıyabilir. Edinme planı, cihazın ağ bağlantısının ne zaman ve nasıl kesileceğini de içermelidir.

Aracın doğrulanmış ve işlemin tekrarlanabilir olması

Bir adli bilişim raporunun ağırlığı, başka bir uzmanın aynı materyal üzerinde aynı adımları tekrar ederek aynı sonuca ulaşabilmesine bağlıdır. Bunun için kullanılan araçların adı ve sürümü, ayarları ve işlem sırası rapora yazılır. Uluslararası uygulamada araçların doğrulanmasına yönelik test programları ile ISO/IEC 27037 (tanımlama, toplama, edinme ve koruma), ISO/IEC 27041 (yöntemin uygunluğunun güvencesi) ve ISO/IEC 27042 (analiz ve yorumlama) gibi standartlar bu tekrarlanabilirliğin çerçevesini çizer. Bu standartlar Türk mahkemelerini bağlamaz; ama bir raporun yöntem kısmının neyi içermesi gerektiğine dair yaygın kabul görmüş bir ölçüt sunar.

Hash doğrulama ve zaman damgası: Bütünlüğü zamana bağlamak

Hash doğrulama, bir verinin hesaplama anından sonra değişmediğini gösterir; verinin ne zaman oluştuğunu, kimin ürettiğini veya içeriğinin doğru olup olmadığını göstermez. Bu boşluğun bir kısmını 5070 sayılı Elektronik İmza Kanunu kapsamındaki zaman damgası ve güvenli elektronik imza kapatır.

Hash değerinin ne olduğu ve kendi bilgisayarınızda nasıl hesaplanacağı daha önce anlatıldı. Dijital delil açısından asıl ince nokta, hash'in hangi düzeyde alındığıdır. Aynı veri; disk imajı, tek dosya, arşiv paketi ya da tek bir e-posta iletisi düzeyinde farklı sonuçlar verir ve karşılaştırma ancak aynı düzeydeki değerler arasında anlamlıdır.

Hash düzeyi Örnek Neyi güvenceye alır? Dikkat edilecek nokta
Ortam veya imaj Bir diskin ya da telefonun imaj dosyası İmajın bütünü İmajdan çıkarılan her dosyanın ayrıca kendi değeri hesaplanır
Dosya Tek bir PDF, video veya tablo O dosyanın içeriği Dosya adı değişse de değer aynı kalır; ad değil içerik ölçülür
Kapsayıcı ZIP arşivi, posta kutusu dosyası, dışa aktarma paketi Paketin o kopyası Aynı içerik yeniden dışa aktarıldığında paketin değeri değişebilir
Öğe Tek bir e-posta iletisi, tek bir sohbet kaydı İletinin içeriği Araçların öğe değeri hesaplama yöntemi farklıdır; yöntem yazılmalıdır
Kayıt aralığı Bir sunucu kaydının belirli tarih aralığı Seçilen aralık Aralığın nasıl seçildiği ayrıca belgelenir

Yeniden dışa aktarma neden farklı hash verir?

Bir posta kutusunu bugün ve bir ay sonra aynı ayarlarla dışa aktardığınızda, iki paketin hash değerleri büyük ihtimalle farklı çıkar. Bunun nedeni içerik değişikliği değil, paketin kendisine yazılan dışa aktarma tarihi, sıralama ve sıkıştırma gibi ayrıntılardır. Karşı tarafın uzmanı bu farkı "veri değişmiş" diye sunabilir.

Bu itirazın cevabı, bütünlüğü paket düzeyinde değil öğe düzeyinde de kayda geçirmektir. İletilerin veya dosyaların tek tek hash değerleri ilk edinmede listelenirse, sonraki bir dışa aktarmada paketin değeri farklı çıksa bile her iletinin aynı kaldığı gösterilebilir.

Hash eşleşmesi aynılığı kanıtlar, kimliği değil

Bir çalışanın kişisel belleğinde bulunan bir dosyanın hash değeri, şirketin gizli fiyat listesinin değeriyle eşleşiyorsa, iki dosyanın birebir aynı olduğu kanıtlanmıştır. Dosyayı kimin, ne zaman ve nasıl kopyaladığı ise ayrı bir sorudur ve işletim sistemi kayıtları, bağlantı geçmişi ve diğer delillerle cevaplanır.

Uygulamada hash'in iki ek kullanımı daha vardır. Birincisi, işletim sistemi dosyaları gibi bilinen ve ilgisiz dosyaların hash kümeleriyle elenmesidir; bu, inceleme yükünü azaltır ve kişisel verinin gereksiz yere açılmasını önler. İkincisi, benzerlik hash'i (fuzzy hashing) adı verilen yöntemlerdir. Klasik hash tek bir karakter değişikliğinde tamamen farklılaşırken, benzerlik hash'i bir dosyanın düzenlenmiş sürümlerini "büyük ölçüde benzer" olarak yakalayabilir. Sızıntı soruşturmalarında, adı ve birkaç satırı değiştirilmiş bir belgenin izini sürmek için bu yöntemlerden yararlanılır.

Zaman damgası: Hash'e tarih vermek

5070 sayılı Kanun m.3, zaman damgasını bir elektronik verinin üretildiği, değiştirildiği, gönderildiği, alındığı ve/veya kaydedildiği zamanın tespit edilmesi amacıyla elektronik sertifika hizmet sağlayıcısı tarafından elektronik imzayla doğrulanan kayıt olarak tanımlar. Teknik uygulamada sağlayıcıya dosyanın kendisi değil, hash değeri gönderilir; sağlayıcı bu değeri kendi saatine göre tarihleyip imzalar.

Bu yapı, hash'in tek başına veremediği bir bilgiyi ekler: Bu içerik en geç damgalama anında vardı. Dosyanın ne zaman oluşturulduğunu, kim tarafından üretildiğini ya da damgalamadan önce ne olduğunu ise göstermez. Değerini en yüksek kılan şey, edinmeye en yakın anda uygulanmasıdır. Elektronik sertifika hizmet sağlayıcıları, faaliyete geçmeden önce Kanun'da sayılan güvenlik şartlarını sağladıklarını göstermek ve faaliyetleri boyunca kamu denetimine tabi olmak zorundadır.

Güvenli elektronik imza ve KEP: Kimlik ile bütünlüğü birlikte bağlamak

Tanımdaki son unsur, yani sonradan değişiklik yapılıp yapılmadığının tespiti, hash mantığının hukuka taşınmış hâlidir. İmzalı bir PDF'te imzadan sonra tek bir karakter değiştirilirse, imza doğrulama aracı bunu "imzadan sonra değiştirilmiş" diye gösterir. Bu nedenle güvenli elektronik imzalı bir belgede tartışma çoğunlukla içeriğin değişip değişmediğinden, sertifikanın geçerliliğine ve imzalayanın temsil yetkisine kayar.

Kayıtlı elektronik posta (KEP) ise bir iletinin gönderilmesini ve teslimini, sağlayıcının tuttuğu kayıtlarla belgeleyen bir sistemdir. TTK m.18/3, tacirler arasında temerrüde düşürme, fesih ve sözleşmeden dönmeye ilişkin ihbar ve ihtarların noter aracılığıyla, taahhütlü mektupla, telgrafla veya güvenli elektronik imza kullanılarak KEP ile yapılacağını düzenler. Sıradan e-postada "almadım" itirazı başlık analizine ve sunucu kayıtlarına dayanırken, KEP'te bu tartışma büyük ölçüde baştan kapanır.

Araç Neyi gösterir? Neyi göstermez? Ne zaman anlamlı?
Hash değeri Hesaplama anından sonra değişiklik olmadığını Oluşturma zamanını, yazarı, doğruluğu Her dijital delilde, edinme anında
Zaman damgası Hash'e sahip içeriğin en geç damgalama anında var olduğunu Oluşturma anını, yazarı Uzun sürecek, değeri yüksek dosyalarda
Güvenli elektronik imza İmzalayanın kimliğini ve imzadan sonra değişiklik olup olmadığını İçeriğin doğru olduğunu, imzalayanın yetkisini Sözleşme, tutanak, beyan gibi irade açıklamalarında
KEP Gönderim ve teslim anını ve iletilen içeriği İçeriğin hukuki sonucunu İhtar, ihbar, fesih gibi süre başlatan bildirimlerde

E-posta başlığı analizi: Bir iletinin gerçek yolculuğu

E-posta başlığı (header), iletinin hangi sunuculardan, hangi sırayla ve hangi saatlerde geçtiğini ve gönderen alan adı için yapılan kimlik doğrulamalarının sonuçlarını gösteren teknik satırlardır. Ekranda gördüğünüz gönderen adı ve tarih bu satırların en kolay değiştirilebilen kısmıdır; özgünlük tartışması asıl olarak başlığın geri kalanında çözülür.

Bir iletinin başlığında onlarca satır bulunabilir; bunların bir kısmı gönderen tarafın, bir kısmı yoldaki sunucuların, bir kısmı da alıcı tarafın sistemleri tarafından yazılır. Kimin yazdığı, satırın güvenilirliğini belirler: Gönderenin kendi istemcisinin yazdığı bir alan, gönderen tarafından kolayca değiştirilebilir. Alıcı tarafın sunucusunun eklediği bir satırı ise gönderen değiştiremez.

Başlık alanı Ne gösterir? Kim yazar? Güvenilirliği
From Görünen ad ve gönderen adresi Gönderen istemci Düşük; tek başına kolay taklit edilir
Reply-To Yanıtların gideceği adres Gönderen istemci From'dan farklıysa dikkat gerektirir
Return-Path Zarf göndericisi, yani iade adresi Son alıcı sunucu, zarf bilgisinden SPF denetimi bu alan adına göre yapılır
Date İletinin yazıldığı iddia edilen an Gönderen istemci Düşük; gönderen cihazın saatine bağlıdır
Received Her sunucunun iletiyi kimden ve ne zaman aldığı Yoldaki her sunucu Alıcı tarafın kendi sunucularının yazdığı satırlar en güvenilirdir
Message-ID İletinin tekil kimliği Gönderen sistem Karşı tarafın posta kutusunda aranabilir
In-Reply-To ve References Yazışma zincirindeki önceki iletiler Gönderen istemci Zincirin sırasını ve bütünlüğünü doğrular
DKIM-Signature Gönderen alan adının kriptografik imzası Gönderen sunucu Yüksek; içerik değişirse doğrulama bozulur
Authentication-Results SPF, DKIM ve DMARC denetimlerinin sonucu Alıcı sunucu Alıcı sistemin teslim anındaki değerlendirmesi
ARC alanları Yönlendirme sırasında doğrulama sonuçlarının taşınması Ara sunucular Yönlendirilmiş iletilerde önem kazanır

Received satırları aşağıdan yukarıya okunur

Her sunucu iletiyi aldığında başlığın en üstüne yeni bir Received satırı ekler. Bu yüzden iletinin yolculuğu aşağıdan yukarıya okunur: En alttaki satır iletinin çıkış noktasına en yakın sunucuyu, en üstteki satır alıcının posta kutusuna teslimi gösterir. Her satırda, iletinin hangi sunucudan alındığı, hangi sunucu tarafından alındığı ve saat dilimiyle birlikte tarih ve saat yer alır.

Analizde iki şeye bakılır. Birincisi zincirin kendi içinde tutarlı olmasıdır: Bir satırdaki "kimden aldım" bilgisi, bir alttaki satırın "ben kimim" bilgisiyle örtüşmelidir ve saatler, saat dilimi dönüşümü yapıldıktan sonra mantıklı bir sıra izlemelidir. İkincisi güven sınırıdır: Alıcı şirketin kendi sunucularının eklediği satırlar güvenilirdir. Bunların altında kalan satırlar ise gönderen tarafından taklit edilebilir; bu yüzden analiz, güvenilir ilk satırın "iletiyi şu adresten aldım" dediği noktadan başlar.

SPF, DKIM ve DMARC: Alan adının kimliği

Gönderen alan adının kimliğini sınayan üç mekanizma vardır. SPF (Sender Policy Framework), iletiyi gönderen sunucunun, zarf göndericisindeki alan adı adına e-posta göndermeye yetkili olup olmadığını denetler. DKIM (DomainKeys Identified Mail), gönderen sunucunun iletiye eklediği kriptografik imzadır; imza, iletinin gövdesinin özetini ve seçilmiş başlık alanlarını kapsar. DMARC ise ekranda görünen From adresindeki alan adının SPF veya DKIM ile doğrulanan alan adıyla uyumlu olup olmadığına bakar ve alan adı sahibinin uyumsuz iletiler için belirlediği politikayı uygular.

Delil açısından en değerli olanı DKIM'dir, çünkü bir tür bütünlük mührü işlevi görür. Gövde veya imzaya dahil edilen başlıklar teslimden sonra değiştirilirse imza doğrulanamaz. Ancak bir sınırı vardır: Doğrulama, gönderen alan adının alan adı sisteminde (DNS) yayımladığı açık anahtara dayanır ve alan adı sahipleri bu anahtarları zaman içinde değiştirebilir. Aylar sonra anahtar kaldırılmışsa imza artık doğrulanamaz. Bu yüzden tartışmalı bir iletinin DKIM doğrulaması mümkün olan en erken anda yapılmalı, sonucu ve o tarihteki DNS kaydı raporda belgelenmelidir.

Orijinal ileti nasıl korunur?

Bir e-postayı avukatınıza "ilet" (forward) seçeneğiyle göndermek, orijinal iletiyi değil sizin sunucunuzdan çıkan yeni bir iletiyi gönderir; orijinalin başlık satırları büyük ölçüde kaybolur. E-postayı yazdırmak veya PDF'e dönüştürmek ise başlığın tamamını siler. Doğru yöntem, iletinin ham hâlini dosya olarak dışa aktarmaktır.

Webmail hizmetlerinin çoğunda ileti menüsünde orijinali gösterme veya ileti kaynağını görüntüleme seçeneği bulunur ve ileti buradan .eml dosyası olarak indirilebilir. Masaüstü e-posta programlarında ileti, başlıklarıyla birlikte .eml ya da .msg dosyası olarak kaydedilebilir. Kurumsal hesaplarda ise yöneticinin dışa aktarma ve arama araçlarıyla, kimin hangi ölçütle aradığını gösteren bir kayıt eşliğinde toplama yapılır. Her durumda dışa aktarılan dosyanın hash değeri hesaplanır ve posta kutusundaki asıl ileti silinmez.

Başlık analizinin sınırları

Başlık analizi iletinin hangi sistemden çıktığını gösterebilir, ama klavyenin başında kimin oturduğunu göstermez. Ele geçirilmiş bir hesaptan gönderilen ileti, bütün kimlik doğrulama denetimlerinden geçer; çünkü gerçekten o hesabın sistemi tarafından gönderilmiştir. Bu durumda tartışma, hesabın oturum kayıtlarına, hangi IP adresinden ve hangi cihazdan oturum açıldığına kayar.

Bazı büyük e-posta hizmetleri, web arayüzünden gönderilen iletilerde göndericinin IP adresini başlığa yazmaz. Sanal özel ağ (VPN) kullanımı da görünen adresi değiştirir. Bir IP adresi bir bağlantıyı gösterir, bir kişiyi değil; aynı ağı paylaşan bir ofis, bir aile ya da halka açık bir kablosuz ağ, tek bir adresin arkasında çok sayıda kişi olabileceğini hatırlatır.

Metadata analizi: Belge, dosya sistemi ve işletim sistemi izleri

Metadata (üst veri), bir dosyanın içeriği dışında kalan ve onu kimin, hangi yazılımla, ne zaman oluşturup değiştirdiğine dair ipuçları taşıyan veridir. Tek başına kesin kanıt değildir, çünkü değiştirilebilir ve yanlış ayarlanmış bir sistemin hatasını da taşır; ama birbirinden bağımsız katmanlardaki üst veriler birbirini tutuyorsa güçlü bir köken ve zaman göstergesine dönüşür.

Fotoğraf ve videolardaki EXIF alanlarını, çekim zamanını ve konum bilgisini fotoğraf ve video kaydının hukuki değeri rehberinde ele aldık. Bu bölüm belgelerin, dosya sisteminin ve işletim sisteminin bıraktığı izler üzerinde duruyor; ticari, kurumsal ve ortaklık uyuşmazlıklarında tartışmanın çoğu bu katmanlarda geçer.

Katman Örnek alanlar Neyi gösterebilir? Zayıf yanı
Office belgesi içi Oluşturan, son kaydeden, oluşturma ve değiştirme tarihi, revizyon sayısı, toplam düzenleme süresi, şablon, uygulama sürümü Belgenin hangi hesapla, kaç oturumda, hangi şablondan hazırlandığı Kullanıcı adı bilgisayardaki ayara bağlıdır; araçlarla değiştirilebilir
PDF belgesi içi Üreten yazılım, oluşturma ve değiştirme tarihi, belge kimlikleri, artımlı kayıtlar Dönüştürme zinciri, sonradan yapılan eklemeler Yeniden kaydetme ve yazdırma bilgileri sıfırlayabilir
Dosya sistemi Oluşturma, değiştirme, erişim ve kayıt değişikliği zamanları Dosyanın o diskteki yaşam öyküsü Kopyalama ve arşivleme değiştirir; son erişim tarihi çoğu zaman güvenilmez
Dosya sistemi günlükleri Değişiklik günlüğü kayıtları Oluşturma, yeniden adlandırma ve silme olaylarının sırası Sınırlı süre tutulur, üzerine yazılır
İndirme izi Dosyanın indirildiği adresi taşıyan ek bilgi Dosyanın hangi siteden veya hizmetten geldiği Bazı taşıma yöntemlerinde kaybolur
İşletim sistemi kayıtları Son açılan dosyalar, kısayol dosyaları, harici bellek bağlantı geçmişi, oturum açma kayıtları Dosyanın hangi cihazda, hangi bellekten açıldığı Yorumu uzmanlık ister; sistem ayarlarına bağlıdır

Office belgelerinde iz: Revizyon, düzenleme süresi ve şablon

Güncel Word, Excel ve PowerPoint dosyaları aslında içinde XML dosyaları bulunan sıkıştırılmış paketlerdir. Paketin içindeki özellik dosyaları; belgeyi oluşturan ve en son kaydeden kullanıcı adını, oluşturma ve son değiştirme zamanını, kaç kez kaydedildiğini gösteren revizyon sayısını, toplam düzenleme süresini, kullanılan şablonu ve uygulama sürümünü taşır. Word ayrıca her düzenleme oturumuna rastgele bir kimlik atar; bu kimlikler, iki belgenin ortak bir kaynaktan türeyip türemediğini anlamaya yardımcı olabilir.

Bu alanların değeri, çelişki yakalamaktır. "Toplantıdan hemen sonra yazıldı" denilen bir tutanağın toplam düzenleme süresi iki dakika, revizyon sayısı bir ise ve belge bir başka dosyadan kopyalanarak oluşturulmuşsa, bu hikâyeyi tek başına çürütmez ama soru işareti doğurur. İddia edilen tarihte henüz kullanılmayan bir şablonun, logonun ya da yazılım sürümünün izi ise daha güçlü bir zaman çelişkisidir.

PDF'te artımlı kayıt ve dönüştürme zinciri

PDF dosyalarında üst veri iki yerde tutulabilir: belge bilgi sözlüğünde ve XMP denilen ayrı bir veri bloğunda. Üreten yazılım alanı, PDF'in doğrudan bir kelime işlemciden mi, bir tarayıcıdan mı, yoksa "PDF'e yazdır" işleviyle mi oluşturulduğunu gösterebilir. İki alan arasındaki tutarsızlık, dosyanın sonradan bir araçla düzenlendiğine işaret edebilir.

PDF'in bir başka özelliği artımlı kayıttır. Bazı programlar bir PDF'te değişiklik yapıldığında dosyayı baştan yazmak yerine değişiklikleri dosyanın sonuna ekler. Bu durumda dosyanın önceki sürümleri teknik incelemeyle görünür hâle gelebilir. İmzalı PDF'lerde de imzanın kapsadığı bayt aralığından sonra eklenen her şey doğrulama aracında ayrıca görünür.

Dosya sistemi tarihleri ve kopyalama paradoksu

Dosya sistemleri her dosya için birkaç zaman bilgisi tutar: oluşturma, son değiştirme, son erişim ve dosya kaydının değiştirilme zamanı. Bunlar kolayca yanlış okunur. Örneğin Windows'ta bir dosya başka bir diske kopyalandığında, yeni kopyanın oluşturma tarihi kopyalama anı olur, ama son değiştirme tarihi orijinalden taşınır. Ortaya "oluşturulmadan önce değiştirilmiş" görünen bir dosya çıkar. Bu tablo sahtecilik değil, kopyalamanın olağan izidir.

Windows'un dosya sistemi her dosya için iki ayrı zaman kümesi tutar ve zaman bilgisini değiştirmeye yarayan araçlar çoğu zaman bunlardan yalnızca birini değiştirir. İki küme ve dosya sisteminin değişiklik günlüğü arasındaki tutarsızlık, bilirkişinin bilinçli tarih değişikliğinden şüphelendiği tipik noktadır. Bu karşılaştırma uzmanlık ister ve yalnızca adli kopya üzerinde anlamlıdır; dosyayı açıp kaydetmek ya da başka bir klasöre taşımak bu izleri kendiliğinden değiştirebilir.

İndirme izi, harici bellek ve son açılan dosyalar

İşletim sistemleri internetten indirilen dosyalara, kaynağına ilişkin ek bilgiler ekler. Windows'ta bu bilgi dosyaya bağlı ayrı bir veri akışında, macOS'ta ise dosyanın genişletilmiş özniteliklerinde tutulur ve çoğu zaman dosyanın indirildiği adresi içerir. "Bu belgeyi rakibe ben göndermedim, internette buldum" savunmasının sınanmasında bu iz değerli olabilir.

Harici bellek bağlantı geçmişi, kısayol dosyaları ve son açılan dosyalar listeleri ise bir dosyanın hangi bellekten, hangi tarihte açıldığını gösterebilir. Bu kayıtlar özellikle kurumsal soruşturma dosyalarında, bir belgenin şirket bilgisayarından kişisel bir belleğe aktarılıp aktarılmadığı sorusunda merkezî rol oynar. Yalnızca şirkete ait ve kullanım kuralları çalışana önceden bildirilmiş cihazlarda, iş hukuku ve KVKK sınırları içinde incelenebilirler.

Metadata çeliştiğinde ne düşünülmeli?

Üst verinin eksik ya da tutarsız olması tek başına sahtelik anlamına gelmez. Eşitleme hizmetleri, biçim dönüştürmeleri, e-posta sistemlerinin ekleri yeniden kodlaması, saat dilimi ayarları ve yazılım güncellemeleri masum tutarsızlıklar üretir. İyi bir rapor bu açıklamaları tek tek sınar ve hangilerinin elendiğini yazar.

Tersi de geçerlidir: Kusursuz görünen bir üst veri, belgenin gerçek olduğunu kanıtlamaz. Bilinçli bir sahtecilik, belge içi alanları tutarlı hâle getirebilir; ama dosya sistemi günlükleri, bulut sürüm geçmişi, e-posta sunucusunun gönderim kaydı ve yedekler gibi sahtecinin kontrol etmediği katmanların hepsini aynı anda tutarlı kılmak çok daha zordur. Bağımsız kaynak ilkesi metadata analizinde de geçerlidir.

Bulut verisi ve sunucu kayıtları: Cihazda olmayan delil

Bulut verisi, bir hizmet sağlayıcının sunucusunda tutulan içerik ile o içeriğe ilişkin sürüm, paylaşım, oturum ve erişim kayıtlarıdır. Delil değeri yüksektir, çünkü zaman bilgisi kullanıcının cihaz saatinden bağımsız olarak üretilir; ama verinin kime ait olduğuna göre edinme yolu tamamen değişir.

Bulutun delil açısından asıl zenginliği içerikte değil, içerik etrafındaki kayıtlardadır. Bir belgenin sürüm geçmişi, belgenin hangi tarihte hangi hesap tarafından değiştirildiğini; paylaşım kayıtları, kime ne zaman erişim verildiğini; oturum kayıtları ise hesaba hangi cihazdan ve hangi IP adresinden girildiğini gösterebilir. Bu kayıtların hiçbiri kullanıcının bilgisayarında değil, sağlayıcının sunucusunda üretilir.

Kaynak Ne içerir? Kim, nasıl edinebilir? Dikkat edilecek nokta
Kendi kişisel hesabınız İçerik, sürüm geçmişi, oturum ve cihaz listesi Hesap sahibi; sağlayıcının veri indirme aracı İndirme tarihi, kapsam ve arşiv hash'i kaydedilir
Şirket hesapları İleti izleme, denetim kayıtları, paylaşım geçmişi Şirketin yetkili yöneticisi; şirket politikası ve aydınlatma çerçevesinde Kayıtların saklama süresi lisansa ve ayara bağlıdır
Karşı tarafın veya üçüncü kişinin hesabı İçerik ve kayıtlar Yalnızca mahkeme veya savcılık kanalıyla Kendi başına erişim TCK m.243 vd. kapsamında suç oluşturabilir
Türkiye'de hizmet veren yer ve erişim sağlayıcıların trafik bilgisi Bağlantı zamanı, IP adresi, hizmet kayıtları Yargı mercilerinin talebiyle 5651 m.5 ve m.6'daki saklama süreleri
Yurt dışındaki sağlayıcılar İçerik ve abone bilgileri Uluslararası adli yardım ve sağlayıcının resmî talep süreçleri Uzun sürer; içerik çoğu zaman yalnızca ceza soruşturmasında

Kendi bulut verinizi indirirken

Büyük hizmet sağlayıcıların çoğu, hesap sahibine verilerinin bir kopyasını indirme imkânı tanır: Google'ın Takeout aracı, Apple'ın veri ve gizlilik sayfası, Meta'nın "Bilgilerini indir" aracı ve Microsoft'un gizlilik paneli bunların örnekleridir. Bu araçlarla alınan arşiv, sağlayıcının kendi biçiminde hazırlandığı için bilirkişi açısından değerlidir.

İndirme sırasında dört şey not edilmelidir: talebin ve indirmenin tarihi ve saati, hangi hizmetlerin ve hangi tarih aralığının seçildiği, arşiv dosyalarının adları ve hash değerleri ile indirmeyi kimin, hangi cihazla yaptığı. Arşiv bir kez alındıktan sonra açılıp üzerinde çalışılacaksa, bu çalışma her zaman bir kopya üzerinde yapılır.

Kurumsal kayıtlar: Denetim günlüğünün ömrü kısadır

Kurumsal e-posta ve ortak depolama hizmetleri, ileti izleme ve denetim kayıtları tutar: Hangi ileti ne zaman kime gitti, hangi dosya kim tarafından indirildi, hangi hesap hangi IP adresinden oturum açtı? Bu kayıtlar şirketin kendi sistemine ait olduğu için, şirket politikası ve çalışanlara yapılan aydınlatma çerçevesinde şirket tarafından alınabilir.

Ama bu kayıtların saklama süresi çoğu zaman sınırlıdır ve lisans türüne ve ayarlara göre değişir. Bir sızıntı şüphesi doğduğunda ilk haftalarda yapılması gerekenlerden biri, ilgili kayıtların dışa aktarılması ve saklama ayarlarının uzatılmasıdır. Yukarıdaki temsili senaryoda tedarikçinin elinden kaçan şey tam olarak budur.

Saat dilimi: UTC ile Türkiye saati

Sunucu kayıtlarının çoğu eşgüdümlü evrensel zamana (UTC) göre tutulur; Türkiye 2016 sonbaharından bu yana yıl boyunca UTC+3 saatini kullanmaktadır. Bir e-posta başlığında "+0000" ile biten bir saat ile "+0300" ile biten bir saat arasındaki üç saatlik fark, dikkatsiz bir okumada "ileti gönderilmeden alınmış" gibi görünebilir. 2016 öncesine ait kayıtlarda ise yaz ve kış saati uygulaması nedeniyle fark dönemine göre değişir.

İyi bir raporda her zaman bilgisinin hangi saat diliminde olduğu ve nasıl dönüştürüldüğü açıkça yazılır. Farklı kaynaklardan gelen kayıtlar tek bir zaman çizelgesinde birleştirilirken, her kaynağın saatinin neye göre ayarlandığı da sorulur. Ağ üzerinden saat eşitlemesi yapan bir sunucu ile saati elle ayarlanmış eski bir kayıt cihazı aynı güvenilirlikte değildir.

Trafik bilgisi ve yurt dışı sağlayıcılar

5651 sayılı Kanun, yer sağlayıcıların sağladıkları hizmetlere ilişkin trafik bilgilerini bir yıldan az ve iki yıldan fazla olmamak üzere, erişim sağlayıcıların ise altı aydan az ve iki yıldan fazla olmamak üzere yönetmelikte belirlenecek süre kadar saklamasını ve bu bilgilerin doğruluğunu, bütünlüğünü ve gizliliğini sağlamasını öngörür. Bu kayıtlar, bir IP adresinin belirli bir anda hangi aboneye ait olduğu gibi soruların cevabıdır ve yalnızca yargı mercilerinin talebiyle alınabilir.

Hizmet sağlayıcı yurt dışındaysa süreç uzar. Türkiye'nin de taraf olduğu Avrupa Konseyi Siber Suç Sözleşmesi gibi araçlar ve uluslararası adli yardım kanalları kullanılır; birçok sağlayıcı kolluk ve savcılıktan gelen veri koruma ve veri talep başvuruları için ayrı süreçler işletir. İçerik verisine erişim çoğu zaman yalnızca ceza soruşturmasında ve uzun bir takvimle mümkündür. Bu nedenle hukuk davalarında taraflar, mümkün olan her veriyi kendi hesaplarından ve kendi cihazlarından korumaya öncelik vermelidir.

Ekran görüntüsü mü, orijinal veri mi? Kaybolan katmanlar

Ekran görüntüsü, verinin ekrandaki görünümünün bir resmidir; orijinal verinin kendisi değildir. Ekranda görünen içeriği gösterir, ama köken, bütünlük ve zaman sorularını cevaplayan teknik katmanları geride bırakır.

Katman Orijinal veride Ekran görüntüsünde
Gönderen kimliği Adres, numara, hesap kimliği, başlık satırları Rehberdeki ad veya görünen ad
Zaman Sunucu ve cihaz zaman kayıtları, saat dilimi Ekranda biçimlendirilmiş saat
Bütünlük DKIM, elektronik imza, kaynak dosyanın hash'i Yalnızca görüntü dosyasının hash'i
Bağlam Tam yazışma zinciri, ekler, önceki ve sonraki iletiler Yalnızca kadraja giren kısım
Düzenleme ve silme izi "Düzenlendi" ibaresi, sürüm geçmişi, silme kayıtları Görünmez
Bilirkişi incelemesi Kaynağa ulaşılarak yapılabilir Çoğu zaman yalnızca görüntünün kendisi incelenebilir

Tablonun son satırı uygulamada en çok hissedilen farktır. Bilirkişiye yalnızca ekran görüntüsü verildiğinde, rapor çoğu zaman görüntüde düzenleme izine rastlanıp rastlanmadığıyla sınırlı kalır. Görüntünün gösterdiği iletinin gerçekten iddia edilen hesaptan gelip gelmediği ise kaynağa ulaşılmadan cevaplanamaz.

Ekran görüntüsü ne zaman yine de işe yarar?

Ekran görüntüsünün değeri, kalıcı bir kaynağın bulunmadığı ya da kaynağın kaybolma riski taşıdığı durumlarda ortaya çıkar: 24 saat sonra kaybolan bir paylaşım, sonradan değiştirilebilecek bir web sayfası, bir uygulamanın yalnızca ekranda gösterdiği bir bildirim. Bu durumlarda ekran görüntüsü tek başına değil; sayfa adresi, hesabın değişmeyen sayısal kimliği, erişim saati, mümkünse kesintisiz ekran kaydı ve bir web arşivi kopyasıyla birlikte alınmalıdır.

Mesajlaşma uygulamalarında ekran görüntüsü, sohbet dışa aktarma, yedek ve cihazın kendisi arasındaki farkı WhatsApp mesajlarının delil değerini anlattığımız rehberde ayrıntılı olarak ele aldık. Oradaki ilke dijital delilin her türü için geçerlidir: Ekran görüntüsü okumayı kolaylaştıran bir yardımcıdır; delilin ağırlığını ise orijinal veri taşır.

PDF'e yazdırmak ve iletmek de bir tür ekran görüntüsüdür

Bir e-postayı veya web sayfasını "PDF olarak yazdır" işleviyle kaydetmek, ekran görüntüsünden daha düzenli görünür; ama teknik olarak aynı sonucu doğurur. Ortaya çıkan PDF yeni bir dosyadır. Üst verisi yazdırma anını ve yazdırma yazılımını gösterir, orijinalin başlık satırlarını, imzasını ve eklerinin orijinallerini taşımaz.

İletme (forward) ve kopyala-yapıştır da aynı kategoridedir. Bunlar içeriği taşır ama içeriğin kanıt değerini oluşturan bağlamı taşımaz. Pratik kural basittir: Sunumda kullanacağınız her çıktının yanında, onun türetildiği orijinal dosyanın da dokunulmadan saklandığından emin olun.

Bilirkişi süreci: HMK m.266 vd. ile dijital inceleme nasıl işler?

Dijital bir delilin gerçekliği veya içeriği hukuk dışında özel ya da teknik bilgi gerektirdiğinde mahkeme HMK m.266 uyarınca bilirkişiye başvurur. Bilirkişi, bölge kurullarının hazırladığı listelerden ilgili uzmanlık alanına göre seçilir, mahkemenin sevk ve idaresi altında çalışır ve hukuki değerlendirme yapamaz; taraflar sürece ret, itiraz ve uzman görüşü araçlarıyla katılır.

HMK m.266, genel bilgi veya tecrübeyle ya da hâkimlik mesleğinin gerektirdiği hukuki bilgiyle çözülebilecek konularda bilirkişiye başvurulamayacağını da söyler. Ayrıca hukuk öğrenimi görmüş kişiler, hukuk alanı dışında ayrı bir uzmanlığa sahip olduklarını belgelendirmedikçe bilirkişi olarak görevlendirilemez. Dijital delil açısından bu, adli bilişim gibi teknik bir uzmanlık alanından bilirkişi seçilmesinin önemini gösterir.

Aşama Dayanak Tarafın dikkat edeceği nokta
Bilirkişiye başvurma kararı HMK m.266 Teknik sorunun açık ve sınırlı biçimde tanımlanması
Sayı ve seçim HMK m.267, m.268; 6754 sayılı Bilirkişilik Kanunu Uzmanlık alanının dijital incelemeye uygunluğu; gerekirse gerekçeli olarak tek sayıda kurul
Yasaklılık ve ret HMK m.272 Ret talebi, sebebin öğrenilmesinden itibaren en geç bir hafta içinde
İnceleme HMK m.276–278 Bilirkişinin görevi bizzat yapması; materyalin eksiksiz teslimi; tarafın bilgisine mahkemenin uygun bulmasıyla başvurulması
Rapor süresi HMK m.274 En çok üç ay; bilirkişinin talebi ve gerekçeli kararla en çok üç ay uzatma; basit yargılamada bu süreler iki ay
Raporun içeriği HMK m.279 Gözlem ve inceleme konusu vakıalar, gerekçe ve sonuç; hukuki nitelendirme yasağı
Rapora itiraz HMK m.281 Tebliğden itibaren iki hafta; teknik çalışma gerekiyorsa süre içinde başvuruyla bir defaya mahsus en çok iki hafta ek süre
Uzman görüşü HMK m.293 Tarafın kendi aldığı bilimsel mütalaa; uzman çağrıldığı duruşmaya geçerli özrü olmadan gelmezse rapor değerlendirilmez

Bilirkişiye doğru soruyu sormak

Bilirkişi raporunun kalitesi, büyük ölçüde mahkemenin bilirkişiye yönelttiği sorulara bağlıdır. "Dosyadaki e-postalar gerçek mi?" gibi geniş bir soru, geniş ve çoğu zaman kaçamak bir cevap üretir. Avukatınızın mahkemeye önerebileceği soruların teknik olarak sınırlı ve cevaplanabilir olması gerekir. Dijital delilde tipik sorular şöyledir:

  1. Tartışmalı iletinin başlık bilgileri, gönderen olduğu iddia edilen alan adının e-posta altyapısıyla ve önceki iletilerle uyumlu mu; DKIM imzası doğrulanabiliyor mu?
  2. Belgenin üst verisindeki oluşturma ve değiştirme bilgileri; dosya sistemi kayıtlarıyla, bulut sürüm geçmişiyle ve belgenin gönderildiği e-postanın tarihiyle tutarlı mı?
  3. İncelenen dosyaların ve imajların hash değerleri, edinme kayıtlarındaki değerlerle eşleşiyor mu?
  4. İlgili tarih aralığında cihazda veya hesapta silme, toplu yeniden adlandırma ya da zaman bilgisini değiştirmeye yönelik bir işlem izi var mı?
  5. Kayıtların saati hangi kaynağa göre ayarlıydı ve saat dilimi dönüşümü nasıl yapıldı?
  6. Tespit edilen izler, eşitleme, biçim dönüştürme veya otomatik güncelleme gibi başka bir açıklamayla da uyumlu olabilir mi?

Altıncı soru özellikle önemlidir. İyi bir adli bilişim raporu yalnızca bir hipotezi doğrulamaz; rakip açıklamaları da sınar ve hangilerinin neden elendiğini gösterir. Bu soruyu baştan sormak, raporun karşı tarafın itirazlarına dayanıklı olmasını sağlar.

Kontrol listesi: Bir dijital inceleme raporunu okurken

  • [ ] İncelenen materyalin listesi, tekil numaraları ve hash değerleri raporda yer alıyor.
  • [ ] Edinme yöntemi, kullanılan araçların adı ve sürümü, işlemin tarihi ve saati yazılı.
  • [ ] Analize başlamadan önce hash doğrulamasının yapıldığı ve sonucu belirtilmiş.
  • [ ] Gözlenen bulgular ile bunlardan yapılan çıkarımlar ayrı ayrı gösterilmiş.
  • [ ] Alternatif açıklamalar sınanmış ve neden elendikleri açıklanmış.
  • [ ] Saat dilimi ve saat kaynağı açıkça belirtilmiş.
  • [ ] İncelenemeyen alanlar ve yöntemin sınırları yazılmış.
  • [ ] Başka bir uzmanın aynı adımları tekrar edebileceği ayrıntı düzeyinde.
  • [ ] Hukuki nitelendirme yapılmamış; sorular teknik düzeyde cevaplanmış.

Bu listede eksik bulduğunuz her madde, HMK m.281 kapsamındaki itirazın somut gerekçesi olabilir. İtiraz süresi tebliğden itibaren iki haftadır ve teknik bir çalışma gerektiğinde ek süre de bu iki hafta içinde istenmelidir. Bu takvim, rapor tebliğ edildiği gün avukatınızla birlikte not edilmelidir.

Uzman görüşü: Sürecin öbür kanadı

HMK m.293, tarafların dava konusu olayla ilgili olarak uzmanından bilimsel mütalaa alabileceğini düzenler. Uzman görüşü mahkemenin bilirkişisinin yerini tutmaz; ama iki noktada belirleyici olabilir. Birincisi, bilirkişiye sorulacak soruların teknik olarak doğru kurulmasıdır. İkincisi, bilirkişi raporundaki yöntem eksikliklerinin somut olarak gösterilmesidir. Hâkim, talep üzerine veya resen uzmanı dinleyebilir; uzman çağrıldığı duruşmaya geçerli bir özrü olmadan gelmezse raporu değerlendirilmez.

Ceza yargılamasında dijital delil: CMK m.134 ve bilirkişi

Ceza soruşturmasında şüphelinin kullandığı bilgisayar, program ve kütüklerde arama, kopyalama ve el koyma, CMK m.134'teki koşullarla hâkim kararıyla, gecikmesinde sakınca bulunan hâllerde Cumhuriyet savcısının kararıyla yapılır; teknik inceleme ise CMK m.63 vd. uyarınca bilirkişiye yaptırılır. Özel kişiler bu yetkileri kullanamaz.

CMK m.134, somut delillere dayanan kuvvetli şüphe sebeplerinin varlığını ve başka surette delil elde etme imkânının bulunmamasını arar. Savcının kararı yirmi dört saat içinde hâkim onayına sunulur; hâkim de en geç yirmi dört saat içinde karar verir, aksi hâlde çıkarılan kopyalar derhâl imha edilir. El koyma sırasında sistemdeki bütün verilerin yedeği alınır ve bu yedekten bir kopya şüpheliye veya vekiline verilerek tutanağa bağlanır. Bu son kural, savunmanın kendi uzmanıyla aynı veriyi bağımsız olarak inceleyebilmesinin dayanağıdır ve hash değerleri, iki tarafın aynı veriye baktığının teknik kanıtıdır.

Ceza yargılamasında bilirkişi rejimi hukuk yargılamasına paraleldir. CMK m.63, çözümü uzmanlık, özel veya teknik bilgi gerektiren hâllerde bilirkişiye başvurulacağını; CMK m.67/3, bilirkişinin hukuki nitelendirme ve değerlendirme yapamayacağını düzenler. CMK m.67/5 uyarınca taraflara yeni bilirkişi incelemesi isteme ve itirazlarını bildirme için süre verilir. CMK m.67/6 ise savcı, katılan, şüpheli veya sanık ve müdafiinin uzmanından bilimsel mütalaa alabileceğini öngörür; m.68/3'e göre mütalaayı hazırlayan uzman istem üzerine duruşmada dinlenebilir.

Bir IP adresi bir kişi değildir

Ceza dosyalarında dijital delilin en sık tartışılan noktası, verinin bir kişiye bağlanmasıdır. Bir IP adresi, belirli bir anda belirli bir aboneliğe ait bağlantıyı gösterir. O bağlantıyı aynı evde yaşayan başka biri, ofisteki bir çalışma arkadaşı, şifresi paylaşılmış bir kablosuz ağın komşusu ya da ele geçirilmiş bir cihaz da kullanmış olabilir.

Şüpheden sanığın yararlanması ilkesi, bu bağlantı boşluğunu ceza yargılamasında özellikle belirleyici kılar. Dijital iz, cihazın fiziksel olarak kimde olduğu, oturumun hangi hesapla açıldığı, aynı anda başka bir yerde bulunulup bulunulmadığı ve içeriğin yalnızca o kişinin bilebileceği ayrıntılar taşıyıp taşımadığı gibi diğer delillerle birleştiğinde anlam kazanır.

Aynı veri, iki ayrı dosya

Bir dijital delil çoğu zaman hem ceza hem hukuk dosyasında karşımıza çıkar: Bir sızıntı soruşturması ile tazminat davası, bir dolandırıcılık şikâyeti ile alacak davası gibi. Ceza dosyasındaki el koyma tutanakları ve bilirkişi raporları, avukatınızın talebiyle hukuk dosyasına getirtilebilir; ama hukuk hâkimi bu belgeleri kendi dosyasındaki diğer delillerle birlikte değerlendirir.

İki dosyada aynı verinin farklı kopyalarının dolaşması, hash listesinin değerini artırır. Ceza dosyasındaki yedeğin değeri ile sizin elinizdeki dışa aktarmanın değeri farklı düzeylerde olabilir; ama öğe düzeyinde alınmış hash değerleri, iki dosyadaki iletinin aynı ileti olduğunu göstermenin en sade yoludur.

Sık yapılan hatalar

Dijital delillerdeki hataların çoğu kötü niyetten değil, verinin "zaten bilgisayarda duruyor" diye sıradan bir dosya gibi ele alınmasından kaynaklanır. Aşağıdaki hatalar, sağlam bir dijital delilin ağırlığını en sık aşındıran davranışlardır.

  1. E-postayı avukata iletmek ve sonra orijinali silmek. İletme işlemi başlık satırlarını korumaz; orijinal silinince köken tartışmasının dayanağı da gider.
  2. E-postayı veya web sayfasını PDF'e yazdırıp orijinal saymak. Yazdırılan dosya yeni bir dosyadır ve yazdırma anının üst verisini taşır.
  3. Belgeyi "bir bakayım" diye açıp kaydetmek. Otomatik kaydetme özelliği bile son değiştirme tarihini ve son kaydeden kullanıcı bilgisini değiştirebilir.
  4. Bulut klasöründeki dosyaları düzenlemek için taşımak, yeniden adlandırmak veya silmek. Sürüm geçmişi ve paylaşım kayıtları bu işlemlerle karışır.
  5. Hash değerini yalnızca arşiv paketi için almak. Yeniden dışa aktarmada paketin değeri değişebilir; öğe düzeyinde liste olmadan bütünlük savunması zayıflar.
  6. Saat dilimini belirtmemek. UTC ile Türkiye saati arasındaki üç saatlik fark, kronolojide yapay çelişkiler üretir.
  7. DKIM doğrulamasını aylar sonraya bırakmak. Alan adı sahibi açık anahtarı değiştirmişse imza artık doğrulanamaz.
  8. Kurumsal denetim kayıtlarının saklama süresini kaçırmak. Kısa saklama ayarı, oturum ve indirme kayıtlarının kendiliğinden silinmesine yol açar.
  9. Karşı tarafın hesabına "sadece bakmak için" girmek. Bu tek davranış, bütün dosyayı hukuka aykırı delil ve ceza sorumluluğu tartışmasına çeker.
  10. Tek bir metadata alanından "sahte" sonucu çıkarmak. Masum tutarsızlıklar elenmeden yapılan suçlama, sunanın güvenilirliğini zedeler.
  11. Bilirkişiyi reddetme ve rapora itiraz sürelerini kaçırmak. Ret için bir hafta, itiraz için iki haftalık süreler dosyanın en kısa takvimidir.
  12. Bilirkişi raporundan hukuki sonuç beklemek. Bilirkişi teknik vakıayı tespit eder; zararın kimde kalacağına veya kusura hâkim karar verir.

Kanıt Dedektiflik bu süreçte ne yapar?

Kanıt Dedektiflik bilirkişi değildir ve mahkemenin atadığı bilirkişinin yerine geçmez. Rolü, hukuka uygun yollarla elde edilen dijital verinin baştan doğru korunmasını sağlamak ve avukatınızın bilirkişi sürecine güçlü bir materyalle girmesine yardımcı olmaktır. Her dosya, Kanıt Yöntemi'nin ilk adımı olan hukuka uygunluk ön testiyle başlar; başkasına ait hesaba, cihaza veya bulut klasörüne erişim gerektiren talepler kabul edilmez.

Dijital iz ve açık kaynak araştırması bulguları; sayfa adresi, hesabın değişmeyen kimliği, erişim zamanı, arşiv kopyası ve hash değeriyle kayda geçirilir. Müvekkilin kendi hesabından veya şirketin kendi sistemlerinden yapılan dışa aktarmalarda öğe düzeyinde hash listesi tutulur, saat dilimi ve saat kaynağı belgelenir. Cihaz imajı gerektiren kurumsal dosyalarda çalışma, yazma engelleyici kullanan bir adli bilişim uzmanıyla ve tutanakla yürütülür.

Teslim edilen Delil Dosyası; kronolojiyi, yöntem beyanını, bütünlük listesini ve her bulgunun neyi gösterip neyi göstermediğini ayıran açıklamaları içerir. Avukat brifinginde, bilirkişiye önerilebilecek teknik sorular ve ret ile itiraz süreleri ayrıca not edilir. Elinizde zaten bir dijital delil varsa, onu yeniden üretmeye çalışmak yerine orijinalin nasıl dondurulacağı ve hangi bağımsız kaydın onu doğrulayabileceği birlikte planlanır.

Teslimden önce dijital delil envanteri: Bilirkişinin ilk sorularına bugünden cevap

Bir dijital delilin mahkemedeki ağırlığı, büyük ölçüde dava açılmadan önce verilen kararlarla belirlenir. Bilirkişinin ilk soracağı sorular bellidir: Orijinal nerede, ne zaman ve nasıl alındı, hash değeri nedir, saat neye göre ayarlıydı ve bu veriyi sizden bağımsız olarak hangi kayıt doğruluyor? Bu soruların cevabını bugünden yazılı hâle getirmek, aylar sonra hatırlamaya çalışmaktan çok daha güvenlidir.

  1. Kaynakları listeleyin. Verinin bulunduğu her cihazı, hesabı ve bulut klasörünü ayrı satıra yazın; hangisinin size, hangisinin şirkete, hangisinin başkasına ait olduğunu belirtin.
  2. Orijinali dondurun. Posta kutusundaki iletileri, bulut klasöründeki dosyaları ve cihazdaki verileri değiştirmeyin; otomatik silme ve temizleme ayarlarını kapatın.
  3. Ham hâlde dışa aktarın. E-postaları .eml veya .msg olarak, hesap verilerini sağlayıcının indirme aracıyla, belgeleri orijinal formatlarında alın.
  4. Öğe düzeyinde hash alın. Her dosyanın ve iletinin SHA-256 değerini, dışa aktarma tarih ve saatiyle birlikte listeleyin.
  5. Saat ve saat dilimini not edin. Her kaynağın saatinin neye göre ayarlı olduğunu ve kayıtlardaki saat diliminin ne olduğunu yazın.
  6. Bağımsız doğrulayıcıları belirleyin. Karşı tarafın sunucusu, bir bulut sağlayıcının sürüm geçmişi, bir banka ya da kargo kaydı gibi sizden bağımsız kaynakları ve bunlara hangi kanalla ulaşılabileceğini not edin.
  7. Kaybolma riskini değerlendirin. Kısa süre tutulan kayıtlar için avukatınızla HMK m.400 vd. kapsamında delil tespitini veya gerekirse zaman damgasını konuşun.

Kontrol listesi: Dijital delil envanteriniz hazır mı?

  • [ ] Her kaynak cihaz, hesap ve klasör sahibiyle birlikte listelendi.
  • [ ] Orijinaller değiştirilmeden duruyor; otomatik silme ve temizleme ayarları kapatıldı.
  • [ ] E-postalar başlık bilgileriyle birlikte ham dosya olarak dışa aktarıldı.
  • [ ] Her dosya ve ileti için SHA-256 değeri, tarih ve saatle listelendi.
  • [ ] Saat kaynakları ve saat dilimleri yazılı.
  • [ ] Bağımsız doğrulayıcı kayıtlar ve bunlara ulaşma yolu belirlendi.
  • [ ] Kısa süre tutulan kayıtlar için delil tespiti veya zaman damgası ihtiyacı avukatla değerlendirildi.
  • [ ] Verinin hukuka uygun yolla elde edildiği avukatla birlikte teyit edildi.

Bu envanter, avukatınızla yapacağınız ilk teknik görüşmenin gündemi, bilirkişiye önerilecek soruların taslağı ve karşı tarafın itirazlarına verilecek cevapların iskeleti olarak işe yarar. Elinizdeki dijital veriyi bu çerçevede gözden geçirmek ya da hukuka uygun bir koruma planı kurmak isterseniz, ücretsiz bir ön görüşme için iletişim sayfasından bize ulaşabilirsiniz.

Kaynaklar ve mevzuat

  1. 6100 sayılı Hukuk Muhakemeleri Kanunu (m.198, 199, 205, 219, 266–281, 293, 400)
  2. 5271 sayılı Ceza Muhakemesi Kanunu (m.63, 67, 68, 134, 206, 217)
  3. 5070 sayılı Elektronik İmza Kanunu (m.3, 4, 5)
  4. 6754 sayılı Bilirkişilik Kanunu
  5. 5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi Hakkında Kanun (m.5, 6)
  6. 6102 sayılı Türk Ticaret Kanunu (m.18/3)

Bu konuyla ilgili hizmetler

SSS

Sık sorulan sorular

Dijital delil mahkemede nasıl kabul edilir?
Önce hukuka uygun elde edilmiş olması gerekir; başkasının hesabından veya cihazından izinsiz alınan veri HMK m.189/2 ve Anayasa m.38/6 nedeniyle dikkate alınmayabilir. Hukuka uygun bir dijital delilin ağırlığını ise kaynağının, bütünlüğünün, zamanının ve tamlığının gösterilebilmesi belirler. Bunun için orijinal dosya, hash listesi, varsa e-posta başlığı ve sunucu kayıtları korunur. Karşı taraf itiraz ederse mahkeme HMK m.266 uyarınca bilirkişi incelemesine başvurur.
E-posta çıktısı mahkemede delil olarak yeterli mi?
Çoğu zaman yeterli değildir. Çıktı yalnızca görünen adı, tarihi ve metni gösterir; iletinin hangi sunuculardan geçtiğini, gönderen alan adının imzasını ve gerçek gönderim zamanını göstermez. HMK m.219, elektronik belgelerin çıktıyla birlikte talep edildiğinde incelemeye elverişli biçimde elektronik ortamda da sunulmasını ister. Bu yüzden iletinin orijinali .eml veya .msg dosyası olarak dışa aktarılmalı, hash değeri alınmalı ve posta kutusu silinmeden korunmalıdır.
E-postanın başlık bilgilerini nasıl görebilirim?
Webmail hizmetlerinin çoğunda ileti menüsünde orijinali gösterme veya ileti kaynağını görüntüleme seçeneği bulunur; buradan iletinin ham hâli .eml dosyası olarak indirilebilir. Masaüstü e-posta programlarında ileti, başlıklarıyla birlikte dosya olarak kaydedilebilir. İletiyi kendinize veya avukatınıza iletmek başlığı korumaz; yeni bir ileti oluşturur. İndirdiğiniz dosyanın SHA-256 değerini hesaplayıp tarih ve saatle not edin ve posta kutusundaki asıl iletiyi silmeyin.
Metadata değiştirilebilir mi, değiştirilmişse delil değersiz mi olur?
Belge içi metadata alanları uygun araçlarla değiştirilebilir; bu yüzden tek bir alana dayanılarak kesin bir hükme varılmaz. Ancak değişiklik çoğu zaman başka katmanlarla çelişki yaratır: dosya sistemi kayıtları, bulut sürüm geçmişi, e-posta eklerinin gönderim zamanı veya yedekler. Bilirkişi bu katmanları karşılaştırır. Metadata'nın değiştirildiğinin anlaşılması delili otomatik olarak dışlatmaz, ama güvenilirliğini ciddi biçimde sarsar ve sunan tarafın inandırıcılığını tartışmaya açar.
İmaj alma işlemi cihazdaki verileri değiştirir mi?
Doğru yapıldığında değiştirmez. Kapalı bir diskten imaj alınırken kaynağa veri yazılmasını önleyen yazma engelleyici kullanılır ve kaynak ile imajın hash değerleri karşılaştırılır. Açık bir cihazda yapılan canlı edinimde ise sistemde kaçınılmaz küçük değişiklikler olur; bu nedenle her adım, saatiyle ve gerekçesiyle kayda geçirilir. Telefonlarda kullanılan yöntem, cihazın modeline ve yazılım sürümüne göre değişir ve raporda açıkça yazılmalıdır.
Bulut hesabımdaki verileri delil olarak nasıl sunabilirim?
Kendi hesabınızdaki veriyi, sağlayıcının resmî veri indirme aracıyla dışa aktarabilirsiniz. İndirme tarihini, hangi hizmetlerin seçildiğini ve arşiv dosyalarının hash değerlerini kaydedin. Sürüm geçmişi, paylaşım kayıtları ve oturum listesi gibi sunucu tarafı bilgiler de ayrıca belgelenmelidir. Başka birinin bulut hesabındaki veriye ise yalnızca mahkeme veya savcılık kanalıyla ulaşılabilir; kendi başınıza erişmek TCK m.243 kapsamında suç oluşturabilir.
Mahkemenin atadığı bilirkişiyi reddedebilir miyim?
Hâkimler için öngörülen yasaklılık ve ret sebepleri bilirkişiler için de uygulanır (HMK m.272). Örneğin bilirkişinin taraflardan biriyle yakın ilişkisi veya daha önce aynı konuda bir tarafa görüş vermiş olması ret sebebi olabilir. Ret talebi, sebebin öğrenilmesinden itibaren en geç bir hafta içinde yapılmalıdır ve ret sebeplerinin ispatı için yemin teklif edilemez. Bilirkişinin uzmanlık alanının dijital incelemeye uygun olmaması ise ret sebebi değildir; bu itiraz dilekçeyle mahkemeye bildirilir ve rapora itirazda da ileri sürülebilir.
Güvenli elektronik imzalı belge ile sıradan dijital dosya arasındaki fark nedir?
Sıradan bir dijital dosya HMK m.199 uyarınca belgedir ve hâkim onu serbestçe değerlendirir. Usulüne göre güvenli elektronik imzayla oluşturulan elektronik veri ise HMK m.205/2 uyarınca senet hükmündedir ve 5070 sayılı Kanun m.5 uyarınca elle atılan imza ile aynı hukuki sonucu doğurur. Güvenli elektronik imza, imzalayanın kimliğini nitelikli sertifikayla bağlar ve imzadan sonra veride değişiklik yapılıp yapılmadığının tespitini sağlar.
Zaman damgası almak zorunlu mu?
Zorunlu değildir; hash listesi, edinme kaydı ve bağımsız sunucu kayıtlarıyla da güçlü bir dosya kurulabilir. Zaman damgası, bir dosyanın hash değerinin belirli bir anda var olduğunu elektronik sertifika hizmet sağlayıcısının imzasıyla belgeler ve özellikle değeri yüksek, uzun süre tartışılması beklenen dosyalarda zamanı sabitler. Dosyanın ne zaman oluşturulduğunu veya kimin ürettiğini göstermez; bu nedenle edinmeye en yakın anda uygulanması gerekir.
Silinmiş dosyalar delil olarak kullanılabilir mi?
Kurtarılabildikleri ve hukuka uygun bir incelemeyle elde edildikleri ölçüde kullanılabilir. Ancak SSD disklerde ve şifrelemeli modern telefonlarda silinen verinin kurtarılması çoğu zaman mümkün değildir. Silinen içerik kurtarılamasa bile silme işleminin kendisi dosya sistemi günlüklerinde, bulut denetim kayıtlarında veya sürüm geçmişinde iz bırakabilir. Kurtarma ve inceleme, kendi cihazınızda bile uzman eliyle ve kayıt tutularak yapılmalıdır.
Ücretsiz ön görüşme

Şüphe değil, kanıt.

Durumunuzu anlatın; talebin hukuka uygun olup olmadığını, hangi delilin işinize yarayacağını ve sürecin nasıl ilerleyeceğini açıkça söyleyelim. Ön görüşme ücretsizdir ve kayıt altına alınmaz.

WhatsApp'tan yazın Hemen arayın

Ön görüşme: her gün 09:00–22:00 · WhatsApp mesajı: 7/24