HTS analizi nasıl yapılır? Adım adım yöntem ve örnek rapor iskeleti

Bu yazı, bir HTS dökümünü incelemek ya da dosyadaki bir analizi denetlemek isteyenler için. Sütunların ne anlattığını HTS kaydı nedir yazısında satır satır gösterdik; burada okumanın bir adım ötesine, analizin kendisine geçiyoruz. Sıra önemli: dosya doğrulanmadan normalizasyona, saat referansı belirlenmeden tablolara geçilmez.

Analize başlamadan dosya nasıl doğrulanır?

Dört kontrolle: kaynak, hash, satır sayısı, biçim.

1. Kaynak. Döküm hangi yazıyla geldi, hangi hattı ve hangi tarih aralığını kapsıyor? Aralığın dışındaki günler için döküm bir şey söylemez.
2. Hash değeri. Elektronik dosyanın SHA-256 değeri hesaplanır: macOS ve Linux'ta shasum -a 256 dokum.csv, Windows PowerShell'de Get-FileHash dokum.csv; bu komut kendiliğinden SHA256 kullanır. Değer rapora yazılır, bütün çalışma kopya üzerinde yapılır. Neden gerektiğini hash ile dijital delil bütünlüğü yazısında anlattık.
3. Satır sayısı. Her sayfanın ve her dosyanın satırları sayılır; ilk ve son satırın tarihi istenen aralıkla karşılaştırılır. Üst yazıda toplam verilmişse onunla da.
4. Biçim. Metin katmanı olan bir PDF tabloya aktarılabilir; taranmış bir çıktı ise karakter tanımadan (OCR) geçer ve 0 ile O, 1 ile l, 8 ile B karışabilir. Bu durumda numara sütununu örnek satırlarla elle karşılaştırırız.

Alanlar nasıl tek biçime getirilir?

Her alan için bir hedef biçim seçilir ve dönüştürme kuralı yazılır. Sütun adları ve biçimler operatöre ve döneme göre değişir.

Tablo programının iki davranışı bu adımda sık sorun çıkarır. Excel, sayıları hesapta kullanabilmek için baştaki sıfırları siler; en fazla 15 anlamlı basamak tuttuğu için de 16 haneli bir IMEISV'nin son hanesi sıfıra döner (Microsoft Destek). Bu yüzden numara, IMEI ve hücre sütunlarını içe aktarırken metin olarak tanımlarız. Normalize tabloya her satırın kaynak dosyasını ve kaynak satır numarasını da yazarız; sonraki her tablo bu iki sütun sayesinde ham satıra geri izlenebilir.

Saat referansı neden ilk sorudur?

Çünkü bütün filtreler saate göre kurulur ve dökümde saatin yerel mi UTC mi olduğu çoğu zaman yazmaz. Bunu üç yoldan belirlemeye çalışırız: operatörün üst yazısı, karşı hattın dökümündeki aynı görüşme ve saat referansı bilinen başka bir kayıt (örneğin cihazdan çıkarılmış arama geçmişi). Türkiye 2016 sonbaharından beri kışın da UTC+3 kullanıyor; daha eski kayıtlarda kış aylarında UTC+2 geçerliydi (IANA tz). Seçilen referans rapora yazılır. Örnekler: zaman damgaları ve saat dilimi.

Mükerrer ve eksik satırlar nasıl ayıklanır?

Mükerrer satırları silmeyiz, işaretleriz. Anahtar olarak zaman, hat, karşı numara, tip ve süreyi kullanırız; aynı anahtarı taşıyan iki satır mükerrer adayıdır. Sebebi çoğu zaman sıradandır: aynı dönem iki ayrı yazıyla iki kez gelmiştir ya da PDF'ten aktarılırken bir sayfa iki kez okunmuştur. İki hattın dökümü birleştirildiğinde ise durum farklıdır. A'nın dökümündeki giden arama ile B'nin dökümündeki gelen arama aynı görüşmenin iki kaydıdır; ikisi de doğrudur, ama irtibat sayımında bir kez sayılır.

Eksik satırı bulmak daha zordur, çünkü olmayanı ararsınız. Günlük satır sayısını çizeriz: her gün onlarca satır üreten bir hattın iki gün boyunca sıfıra düşmesi telefonun kapalı olmasından da, eksik bir sayfadan da kaynaklanabilir. Hangisi olduğunu döküm söylemez; raporda bu aralığı tarihleriyle ayrıca gösteririz.

Hangi analiz tabloları çıkarılır?

Temiz tablodan dört çıktı üretilir; hangilerinin rapora gireceğini dosyadaki sorular belirler.

Kronoloji

Bütün satırlar tek zaman ekseninde, tipleri ayrı işaretli. Süresi 0 olan arama satırları ayrıca işaretlenir; bunlar cevapsız ya da kurulamayan aramalar olabilir ve görüşme sayısına katılırsa iletişim olduğundan yoğun görünür.

İrtibat tablosu

Her karşı numara için giden ve gelen arama, SMS, toplam süre, ilk ve son temas. Çağrı merkezi ve 0850 gibi hizmet numaraları ayrı bir grupta toplanır.

Hücre ve konum

Hücre kodları operatörün baz listesiyle eşleştirilip zaman çizelgesine eklenir. Hücre bir alan gösterir; olay saatindeki hücreyi sektör ve deneme aramalarıyla daraltmanın yolunu daraltılmış baz analizi yazısında anlattık.

IMEI ve hat

IMEI'nin değiştiği anlar işaretlenir. İlk 8 hane (TAC) cihazın modelini gösterir. 15. hane bir kontrol hanesidir ve IMEI şebekede denetlenirken iletilmez; 16 haneli IMEISV'de son iki hane yazılım sürümüdür (3GPP TS 23.003 §6.2.1–6.2.2). Aynı cihaz yazılım güncellemesinden sonra farklı bir IMEISV ile görünebileceği için karşılaştırmayı ilk 14 hane üzerinden yaparız.

Örnek: kurgusal bir döküm üzerinde analiz

Aşağıdaki sekiz satır kurgusaldır. İncelenen hat 0 5xx xxx xx 17; numaralar maskeli, IMEI değerleri örnektir, hücreler etikettir.

Bu sekiz satırdan çıkanlar:

• 4 ve 5 aynı anahtarı taşıyor. Kaynak dosyada iki ayrı sayfada mı göründüğüne bakarız; ayıklandıktan sonra 08 numarasıyla tek bir gelen arama kalır.
• 1 ve 2, 31 saniye arayla aynı numaraya. İlkinin süresi 0. Bu “iki görüşme” değil; bir süresiz arama ve 213 saniyelik bir görüşme.
• 3 bir hizmet numarası; irtibat tablosunda ayrı grupta.
• IMEI 4. satırla 6. satır arasında değişmiş. Değişimin anı bilinmez; yalnızca 14.03 23:15 ile 15.03 07:58 arasında olduğu söylenebilir.

Mükerrer ayıklandıktan sonra irtibat tablosu şöyle olur: 42 numarasına 3 giden arama (biri 0 saniye, toplam 250 saniye) ve 1 SMS satırı; 08 numarasından 1 gelen arama (96 saniye); 0850'li hizmet numarasından 1 gelen arama. H-101'den H-205'e geçiş, hücreler baz listesiyle eşleştirilmeden yorumlanmaz.

Örnek HTS raporu nasıl olur?

İyi bir HTS raporu, başka bir uzmanın aynı tabloları ham dökümden yeniden üretebileceği kadar açık yazılır. Hukuki nitelendirme içermez; CMK m.67/3 bunu mahkemenin atadığı bilirkişiye de yasaklar. Bizim kullandığımız iskelet:

1. Görev ve sorular

Raporu kimin istediği ve soruların kendisi, yazıldığı gibi. “Her şeye bakın” bir soru değildir; “42 ve 17 numaraları 14–15 Mart arasında görüşmüş mü” bir sorudur.

2. İncelenen materyal

Dosya adları, kaynağı, SHA-256 değerleri, satır sayıları, kapsanan hat ile tarih aralığı.

3. Yöntem

Normalizasyon kuralları, saat referansı, mükerrer tanımı, yazılımın adı ve sürümü, filtreler.

4. Veri kalitesi

Mükerrer adaylar, satırsız aralıklar, okunamayan satırlar.

5. Bulgular

Her soru için ayrı başlık. Her tablonun altında dayandığı satır numaraları (tam liste ekte).

6. Sınırlılıklar

Bu dökümün bu dosyada gösteremediği şeyler, somut olarak.

7. Cevaplar

Soruların kısa cevabı, ilgili bulgu numarasıyla.

8. Ekler

Normalize tablo, irtibat tablosu, harita.

Kurgusal örnekten bir bulgu ve bir sınırlılık cümlesi:

“0 5xx xxx xx 17 numaralı hattan 0 5xx xxx xx 42 numaralı hatta 14.03.2025 21:02 ile 15.03.2025 08:12 arasında 3 giden arama satırı bulunmaktadır (Ek-1, satır 1, 2, 7). Satır 1'in süre alanı 0'dır; bu satırın cevapsız arama mı, kurulamayan bağlantı mı olduğu dökümden anlaşılamamaktadır.”

“Dökümde saat referansı belirtilmemiştir. Saatler, 0 5xx xxx xx 42 numaralı hattın dökümüyle doğrulanıncaya kadar dökümdeki hâliyle verilmiştir.”

HTS analizi hangi programla yapılır?

Belirli bir program şart değildir; şart olan, her işlemin tekrarlanabilmesidir. Birkaç bin satırlık tek bir döküm tablo programında incelenebilir. Birden fazla hat ya da aylara yayılan dökümler için veri tabanı sorgusu (SQL) veya bir betik dili daha güvenlidir, çünkü her filtre yazılı bir komut olarak kalır. Haritalama için coğrafi bilgi sistemi (CBS) yazılımı kullanılır. Kolluğun ve ticari firmaların hazır analiz programları da var. Hangisi kullanılırsa kullanılsın programın adı ve sürümü rapora girer; ekrandaki bir grafik, dayandığı satır listesi olmadan denetlenemez. İrtibat tablosunun sorgu karşılığı kabaca şöyle:

SELECT karsi_no,
       SUM(tip = 'giden') AS giden, SUM(tip = 'gelen') AS gelen,
       SUM(sure_sn) AS toplam_sn, MIN(zaman), MAX(zaman)
FROM hts_temiz
WHERE mukerrer = 0 AND tip IN ('giden', 'gelen')
GROUP BY karsi_no
ORDER BY giden + gelen DESC;

md9'un HTS incelemesinin nasıl yürüdüğü HTS analizi sayfasında.