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 incelemesidir.
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.
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/<paket-adı>/ | 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/<UUID>/ | Documents, Library (plist ayar dosyaları dahil), Library/Caches, tmp |
| iOS, paylaşımlı alan | /private/var/mobile/Containers/Shared/AppGroup/<UUID>/ | 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
-waldosyası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-walile-shmdosyaları silinir. Bu yüzden.db,-walve-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_deleteayarı 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 sonraVACUUMç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.
Ö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/<kullanıcı-no>/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 <private> olarak gizlenir. Birçok uygulama ayrıca kendi günlük dosyasını yazar. Uygulamanın sunucu tarafındaki kayıtları ise 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ı?
- 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.
- İ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.
- 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_prefsiç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 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ü ile kendiniz çevirebilirsiniz. Operatör kayıtlarıyla karşılaştırma gerekiyorsa HTS kayıt analizi ile birlikte çalışırız.
Mobil uygulama geliştirme deneyimi incelemeye ne katar?
md9, iPhone için UDF Mobil (md9) 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/Cachesya datmpaltı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.