ZEKASTRA / FORENSIC / YÖNTEMLER
Dört yöntem. Her varsayım görünür.
Kaynakla tanımlanmış gösterim, tam sentetik örnek ve yorumdan önce gereken kontrol adımlarını birlikte incele. Her yöntem mevcut bir araç veya laboratuvara bağlanır.
Yalnızca eğitim örnekleridir. Bu sayfada delil dosyası okunmaz; yöntemler doğrulanmış edinim veya gerçek soruşturma iddiası taşımaz.
YÖNTEM · time-normalization
01 · Zaman damgasını kaynak alanından UTC'ye taşıma
Zaman damgası için önce biçim, birim ve üretici alanı belirlenir; sonrasında UTC dönüştürülür. Farklı sistemlerin aynı saati gösterdiği varsayılmaz.
Araştırma sorusu
Aynı olay için FILETIME, FAT son yazma ve ISO +03:00 kayıtları gelirse hangi adımda karşılaştırılabilir hâle gelir?
Tekrarlanabilir yöntem
- Kaynak alanı ve üretici sürümünü yaz: FILETIME dwLowDateTime/dwHighDateTime, uygulama tablo kolonu veya dosya sistemi alanı gibi. Veri tipi bilinmiyorsa saniye/milisaniye tahmini yapma.
- Epoch, birim, signedness ve özel/null değer politikasını kaynağın tanımıyla eşleştir. FILETIME için 1601-01-01 UTC ve 100 ns; POSIX saniyesinde 1970-01-01 UTC kullanılır.
- Tam sayı hassasiyetini kaybetmeden dönüştür. FILETIME → Unix 100 ns değeri için 116444736000000000 çıkar; kesirli 100 ns basamaklarını atma. Aralık dışı değeri reddet.
- FAT son yazma yerel duvar saati olduğu için UTC farkını ayrıca beyan et; geçmiş DST/saat dilimi bilgisini cihazın o anda hangi ayarda olduğuna dair kayıtla karşılaştır.
- Olayları önce normalleştirilmiş UTC değeriyle sırala; aynı UTC değeri, iki fiziksel işlemin aynı anda gerçekleştiğini kendiliğinden göstermez. Ham değerleri notta sakla.
Sentetik ham girdi
FILETIME: 116444736000000001 (100 ns)
ISO: 1970-01-01T03:00:00+03:00Beklenen yorum / kontrol
İki gösterim 1970-01-01T00:00:00Z çevresine karşılık gelir; FILETIME değeri bundan 100 ns sonradır. Milisaniyeye indirgerken farkın kaybolduğunu ayrıca kaydet.
Kaçınılacak hatalar
Yerel saat farkı belirlenmeden FAT zamanına Z eklemek; kayan nokta sayıyla FILETIME kırpılması; tek bir tarihten eylem/kişi isnadı.
Birincil teknik kaynaklar
YÖNTEM · sqlite-types
02 · SQLite alan türü, zaman dönüştürme ve şema doğrulama
SQLite bir tarih/saat depolama türü zorlamaz; TEXT, REAL veya INTEGER değer tek başına hangi uygulama olayının kaydedildiğini söylemez. Şema ve yazma kuralı birlikte incelenir.
Araştırma sorusu
Bir INTEGER sütunundaki 0 değeri neden bazen 1970, bazen Julian takvimi olarak yorumlanır?
Tekrarlanabilir yöntem
- Özgün veritabanının dosya adı, edinim özeti ve varsa -wal/-shm yan dosyalarını kayıt altına al. Bu rehberde gerçek DB okunmaz; sorgular sentetik örneğe yöneliktir.
- Okunan SQLite sürümünü ve CREATE TABLE şemasını not et. PRAGMA table_info ile sütun türü beyanını al; değer düzeyindeki saklama sınıfını ayrıca typeof(event_time) ile denetle.
- Uygulamanın INTEGER alanını Unix saniyesi olarak yazdığı doğrulanmışsa datetime(event_time,'unixepoch') kullan. Belgesiz birim veya sütun için bu dönüşümü sonuç gibi sunma.
- 'auto' değiştiricisi ilk 63 gün (1970) Unix değerlerinde Julian gününü seçebildiğinden varsayılan kabul etme. UTC/localtime değiştiricilerini dönüşüm sırasına göre açık yaz.
- Kaynak tablo, sütun, satır anahtarı, ham değer, typeof sonucu, kullanılan değiştirici, çıktı ve varsayımı aynı notta tut. Şema incelenmeden gerçek uygulama olay türü ileri sürme.
Sentetik ham girdi
-- Synthetic only
SELECT typeof(1704067200);
SELECT datetime(1704067200,'unixepoch');
SELECT datetime(0,'unixepoch');
SELECT datetime(0,'auto');Beklenen yorum / kontrol
typeof(1704067200) → integer; Unix saniyesi → 2024-01-01 00:00:00; sıfır+unixepoch → 1970-01-01. 'auto' için sıfır Julian takvimiyle yorumlanır.
Kaçınılacak hatalar
PRAGMA sütun bildirimini her satırın gerçek saklama sınıfı sanmak; tarih değerinin birimini basamak sayısıyla belirlemek; READ-ONLY olmayan sorguyu salt-okunur diye etiketlemek.
Birincil teknik kaynaklar
YÖNTEM · timeline-provenance
03 · Kaynak izine bağlı kronoloji ve alternatif açıklama
Zaman çizelgesi yalnız tarihler sıralanarak tamamlanmaz. Her satırın hangi dosyadan, hangi sürümden, hangi teknik yöntemle elde edildiği ve hangi varsayımla normalize edildiği korunur.
Araştırma sorusu
Bir rapor revizyonu kaynak logdan sonra görünüyorsa hangi teknik çıkarımlar güvenle yapılabilir?
Tekrarlanabilir yöntem
- Soru ve zaman aralığını yaz; olay tarihini soruşturma belgesi belirlemiyorsa 'olay öncesi/sonrası' kategorileri uydurma.
- Kaynak matrisi oluştur: kayıt ID, dosya/DB/tablo, ham zaman, biçim, UTC veya beyan edilen ofset, edinim/kopya sürümü. Kaynak ID'si olmayan satıra uydurma kaynak ekleme.
- Ham değeri ve dönüştürme kuralını tutarak UTC sıralamasını hesapla. Eşitlik ve kaynak saat sapmasını ayrı işaretle; kesin olmayan sıralamada nedensellik bağı kurma.
- Mesaj/thread devamlılığı, yinelenen log satırları, dosya kopyalama veya önbellek davranışıyla çapraz kontrol yap; farklı açıklamaları birer cümleyle test edilebilir şekilde kaydet.
- Bulgu olarak yalnız görülen ham kayıtları yaz; değerlendirmede ilişkiyi açıkla; sonuçta araştırma sorusuna cevap ver. Kaynağın doğrulamadığı kişi/eylem bağlantısını kurma.
Sentetik ham girdi
E: 2026-10-09T23:55:00+03:00
C: 2026-10-09T21:01:00Z
A: 2026-10-10T00:03:00+03:00Beklenen yorum / kontrol
E = 20:55Z, C = 21:01Z, A = 21:03Z; sıralama E → C → A. A'nın yerel takvim günü farklı olması UTC sırasını değiştirmez.
Kaçınılacak hatalar
Farklı kayıtlara tek kaynak atamak; saat sapması incelemeden nedensellik ileri sürmek; kurgusal vaka sırasını gerçek olay doğrulaması gibi yazmak.
Birincil teknik kaynaklar
YÖNTEM · hash-report
04 · Dosya hash değeri, kaynak eşleştirme ve rapor izi
Hash değeri belirli bir bayt dizisini tanımlar. İçeriğin olayla ilgisini, kaydın nasıl edinildiğini veya materyali kimin oluşturduğunu hash hesaplaması belirlemez.
Araştırma sorusu
SHA-256 aynıysa hangi unsur eşleşir; raporda hangi alanlar hâlâ ayrı doldurulmalıdır?
Tekrarlanabilir yöntem
- Önce hash'i alınacak nesnenin kapsamını yaz: tek TXT dosyası, çıkarılmış içerik, disk imajı veya arşiv. Birbirinden farklı kapsamları tek digest ile karşılaştırma.
- İzinli sentetik dosya seç; algoritmayı SHA-256 olarak kaydet; son satır sonu ve UTF-8 kodlaması dâhil dosyanın tam baytlarını hesapla.
- Karşılaştırılan iki değeri aynı algoritma ve aynı bayt kapsamıyla eşleştir. Dosya adı ve görünür metin eşitliği, dosya baytı eşitliğinin yerine geçmez.
- Raporu 'Bulgu, Değerlendirme, Sonuç' olarak ayır. Kaynak adı/konum, yöntem ve sürüm, ham değer, zaman temeli, dönüştürme, hesaplanan özet ve varsa gerçek işlem kaydını ayrı alanlarda tut.
- TXT/JSON/DOCX çıktılarında teknik kimlikleri, Unicode metni ve boş alanları gözden geçir. Gerçek edinim, zincir, uzman onayı yoksa üretilmiş rapora bunları ekleme.
Sentetik ham girdi
SHA-256('abc', UTF-8 üç bayt)
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015adBeklenen yorum / kontrol
Bu değer yayımlanmış bir test vektörüdür ve yalnız 'abc' üç baytına karşılık gelir; farklı satır sonu veya tek karakter değişimi özeti değiştirir.
Kaçınılacak hatalar
Ham veri hash'i ile görüntü/rapor dosyasının hash'ini karıştırmak; test vektörü hesaplandı diye gerçek edinimi doğrulamak; kaynak yolu yerine 'önceki not' yazmak.