Windows Tabanlı Yerel LLM Uygulamalarında Artefakt’ların Standartlaştırılmasına Giriş: Ortam Modeli, Veri Üretimi ve Toplama

Bu makalenin amacı: tekrarlanabilir bir Windows lab. kurmak, standart bir kullanıcı verisi üretmek ve artefakt-toplama tasarımını (triage vs full image) netleştirmek. LangurTrace’in önerdiği ortam bileşenleri (backend runtime / client interface / integrated platform) ve artefakt sınıfları bu makalede izah edilecektir.

Bu yazı dizisinin temel amacı, Windows üzerinde çalışan yerel LLM uygulamalarının bıraktığı adli izleri (forensic artefakt) incelemek için tekrarlanabilir bir laboratuvar ortamı kurmak ve standart bir veri üretim protokolü oluşturmaktır. Yerel LLM uygulamaları, örneğin lokal model çalıştıran backend servisleri ve bunlara bağlanan sohbet arayüzleri, tıpkı klasik yazılımlar gibi kullanıcı davranışlarını yansıtan dosya ve loglar üretir.

Bu çalışmada referans aldığımız LangurTrace çerçevesi*, söz konusu izlerin sistematik analizini yapmak için LLM ortamlarını bileşenlerine ayıran bir yapı sunar. Şimdilik odak noktamız yalnızca Windows ve yerel (local) LLM ortamlarıdır; ChatGPT web/API gibi bulut tabanlı servisleri serinin ilerleyen bölümlerinde ele alacağız. (*https://dfrws.org/wp-content/uploads/2025/10/LangurTrace-Forensic-analysis-of-lo_2025_Forensic-Science-International-Di.pdf)

Buradaki yaklaşımımız, artefakt analizini soyut teoriler yerine somut dosya ve konumlar üzerinden yaparak öğretmek ve bu süreci bir standarda oturtmaktır. Bu bölümü, ileride yapacağımız detaylı analizlere zemin hazırlayacak bir “kurulum, veri üretimi ve toplama” rehberi olarak düşünebilirsiniz.

Yerel LLM ekosistemini doğru analiz edebilmek için mimariyi tek bir yazılım olarak değil, birbiriyle konuşan parçalar bütünü olarak görmemiz gerekir. Genellikle bir backend runtime (modeli çalıştıran servis) ve bir client interface (sohbet ve oturum yönetimi yapan arayüz) birlikte çalışır.

LangurTrace metodolojisinde ortamı “backend runtime / client interface / integrated platform” şeklinde sınıflandırıyoruz. Bu ayrım, adli analiz sürecinde hayati önem taşır çünkü konuşma kayıtlarını genellikle client tarafında bulurken; model indirme, çalıştırma veya silme gibi yaşam döngüsü izlerini backend tarafında tespit ederiz. Bilinmelidir ki, kullanılan modelin türü adli izlerin yapısını kökten değiştirmez; izler daha çok uygulamanın veriyi nasıl yönettiğine bağlıdır.

Bu seride, mimari farkı net görebilmek ve artefakt’ları kaynağına göre sınıflandırmayı kolaylaştırmak adına şu minimum kurulumu kullanacağız:

• Backend runtime: Ollama

• Client interface: Chatbox

Standartlaştırma için önce “hangi izler var?” sorusuna cevap vermek gerekir. LangurTrace, LLM uygulamalarında ortak görülen artefakt türlerini şu şekilde özetliyor: downloaded models, model setup history, conversation session configurations, chat history, uploaded/generated files, API keys. Bu kategoriler, adli incelemede iki temel ihtiyacı karşılar:

Kullanıcı niyeti ve davranışı (chat history, uploaded/generated files)

Zaman çizelgesi ve ilişkilendirme (model setup history, logs, manifests, API calls)

LangurTrace’e göre örneğin Chatbox tarafında config.json dosyası; ayarlar, API anahtarları, kayıtlı modeller, varsayılan prompt’lar ve sohbet oturumlarını bir arada tutabilir. Backend tarafında ise server log’ları ve model manifestleri, hangi modelin ne zaman indirildiği/çalıştırıldığı gibi adli değer taşıyan kayıtlar sunar.

Bu serideki tüm bulguların tekrar edilebilir olması için laboratuvar ortamı Hyper-V tabanlı kurgulanmıştır.

Konfigürasyonda kullanılan sistem bileşenleri aşağıdaki gibidir:

• Ollama version: 0.13.5

• Ollama API Host: http://127.0.0.1:11434

• Model: llama3.2: latest

• chatbox (v1.18.2)

• OS Name: Microsoft Windows 11 Pro

• OS Version: 10.0.26200 N/A Build 26200

Sanal makinanın imajı FTK Imager ile alınmıştır.

Kaynak türü: Logical

İmaj formatı: E01

İmaj alma işlemi hatasız tamamlanmış ve yazılım ara yüzünde başarılı şekilde doğrulanmıştır.

MD5: f99e8449a97ad803861e71c50fc3b2fa

SHA1: 294afc6d6a9f2d60e9c93f7221bc59ce2dfccd33

5.1.Ollama

LangurTrace Makalesi, bir LLM imajında en önemli üç artefaktın server.log, model manifest ve model layer olduğunu belirtmektedir. Server.log dosyası, API çağrı kayıtlarını içerir ve her bir çağrı için API türü, zaman damgası, çağrının başarı durumu, gecikme süresi ve çağrı yapan IP adresi gibi bilgileri sunar. Temel API işlemleri arasında model listeleme, indirme, çalıştırma, silme ve sohbet istekleri yer almaktadır. Özellikle model indirme kayıtları, ilgili modelin ayrıntılı meta verilerini içerir; bu sayede araştırmacılar modellerin daha önce hangi tarihlerde yüklendiğini tespit edebilirler.

Bizim incelediğimiz imajda da server.log içerisinde hem model kurulum (setup) süreçlerini hem de API çağrılarını gözlemleyebiliyoruz. Kullanıcı bir modeli indirdiğinde, Ollama bu modeli SHA-256 özetleri (hash) hâlinde saklamaktadır. Kullanıcı modeli silse bile, günlüklerdeki bu “parmak izleri” sayesinde hangi spesifik modelin kullanıldığı geriye dönük olarak kanıtlanabilir. Bu kısmı anlaşılır kılmak için “server.log” dosyasını analiz edeceğiz.

5.1.1.Server.log Dosyasının Analizi: Başlama (Startup) Artefaktlarının İncelenmesi

Bu log dosyası Ollama servisinin başlatılma sürecine ilişkin ayrıntılı yapılandırma ve çalışma parametrelerini bize göstermektedir. Kayda göre sunucunun 18.02.2026 11:20:56 (time) zamanında başlatıldığı, başlatma esnasında sistem çalışma ortamına ilişkin tüm çevresel değişkenleri (env) kaydettiği görülmüştür. Bu iki önemli bulgu adli analiz açısından önem arz eder; çalışma zamanı, değişkenlerin durumu bize sistemin konfigürasyonunu tam olarak göstermekle birlikte uygulamanın hangi parametreler ile çalıştığını doğrulama imkânı tanır.

5.1.2. Model Depolama Konumu ve Dosya Sistemi Artefaktları

Log içerisinde tespit edilen OLLAMA_MODELS:C:\\LLM_Forensic_Lab\\Ollama\\Models parametresi oldukça dikkat çekicidir. Şöyle ki, bu dizin bize dil modelimizin dosyaların fiziksel olarak depolandığı konumu göstermektedir. Adli bilişim açısından bu dizin, model bütünlüğünün doğrulanması, yetkisiz model değişiklerinin tespiti, zararlı veya manipüle edilmiş model dosyalarının analizi olarak değerlendirilebilir. Model dosyalarımızın belirli bir laboratuvar klasör yapısı altında konumlandırılmış olması, analiz ettiğimiz sistemin kontrollü bir test ortamı olmasındandır.

5.1.3. Bağlam Uzunluğu ve Bellek Davranışı

Log içerisinde tespit edilen OLLAMA_CONTEXT_LENGTH:4096 parametresi, modelin bağlam uzunluğunu (context length) belirtmektedir. Bağlam uzunluğu, modelin tek bir etkileşim kapsamında işleyebileceği maksimum token sayısını ifade eder. Bu değer, olası prompt truncation durumlarının analizinde ve uzun girdiye dayalı saldırıların (örneğin prompt flooding) değerlendirilmesinde referans noktası olarak

kullanılmaktadır.

Ayrıca, OLLAMA_NOHISTORY:false parametresi, istemci etkileşim geçmişinin devre dışı bırakılmadığını göstermektedir. Bu durum, uygulamanın geçmiş prompt ve yanıtları bellekte tutabileceğine işaret etmektedir. Dolayısıyla bellek (RAM) analizinde kullanıcı girdilerine ait kalıntıların tespit edilme olasılığı artmaktadır. OLLAMA_NOHISTORY:true olsa ne olurdu?

Elde ettiğimiz bu yapılandırma bilgileri, LLM tabanlı sistemlerde veri kalıcılığı (data persistence) ve gizlilik risklerinin değerlendirilmesi açısından önem arz eder.

5.1.4. Ağ Yapılandırması ve Erişim Analizi

Log içerisinde yer alan OLLAMA_HOST:http://0.0.0.0:11434 parametresi ile Ollama hostunun 0.0.0.0 adresine bağlanması, servisin yalnızca yerel makinede değil, ağ üzerindeki tüm ara yüzlerde erişilebilir olduğunu gösterir. Bu durum potansiyel risk taşısa da çalışmaların kontrollü laboratuvar ürünü olduğunu hatırlatmakta fayda var. Devam eden http erişim kayıtları incelendiğinde 127.0.0.1 | GET “/api/version” şeklindeki tüm isteklerin yalnızca localhost üzerinden geldiği görülmektedir. Bu da analiz edilen örnekte dış ağdan bir erişim gerçekleşmediğini göstermektedir.

Bu iki bulguyu birlikte değerlendirdiğimizde sistem ağ üzerinden erişime açık erişime yapılandırılmış olsa da, incelenen zaman aralığında yalnızca lokalden erişim gerçekleşmiştir.

5.1.5. Versiyon Bilgisi

Çalıştırılan sürüm bilgisinin log içerisinde yer aldığı tespit edilmiştir. İlgili parametre ve değer şöyledir: Listening on [::]:11434 (version 0.13.5)

5.1.6. Donanım Bilgisi

Log dosyası içerisinde sistemin açıkça GPU araması yaptığı görülmüştür: msg=”discovering available GPUs…”

Ancak logların devamında msg=”inference compute” id=cpu library=cpu compute=”” name=cpu description=cpu libdirs=ollama driver=”” pci_id=”” type=”” total=”16.0 GiB” available=”12.1 GiB” ifadelerinin yer aldığı görülmüş, sistemin GPU tespit edemediğini ve CPU taban

5.1.7. Runner Süreçleri ve Port Kullanımı

Log içerisinde birden fazla “runner” sürecinin başlatıldığı görülmektedir:

runner” cmd=”C:\\Users\\LLM_Forensics\\AppData\\Local\\Programs\\Ollama\\ollama.exe runner — ollama-engine –port 51759″

runner” cmd=”C:\\Users\\LLM_Forensics\\AppData\\Local\\Programs\\Ollama\\ollama.exe runner — ollama-engine –port 51767″

runner” cmd=”C:\\Users\\LLM_Forensics\\AppData\\Local\\Programs\\Ollama\\ollama.exe runner — ollama-engine –port 51776″

Runner’ları ollama’nın childprosesleri gibi düşünebiliriz. Port numaralarını işleme göre sürekli değişmesi ise dinamik port kullanımına işaret eder ve bu da hangi sürecin ya da hangi inference sürecinin hangi port ile ilişkili olduğunu gösterir.

Buna ek olarak, makaleye göre app.log dosyası startup ve runtime bilgilerini, upgrade.log ise yazılım güncelleme olaylarını belgelemektedir. İncelediğimiz imajda bu bilgiler de doğrulanabilmektedir.

5.1.8. app.log Dosyasının İncelenmesi: Başlatma (Startup), Sürüm ve Ortam Artefaktları

App.log, Ollama uygulamasının Windows ortamındaki genel çalışma davranışlarını, işletim sistemi ile olan etkileşimini ve arka plan işlemlerini izleyen ve kayıt altına alan bir dosyadır.

Bu kayıt bize ne söylüyor: Uygulamanın çalıştırma yolunun AppData\Local\Programs\Ollama dizini olduğunu, çalıştırılan sürümün 0.13.5 olduğunu, üzerinde çalıştığı işletim sisteminin Windows 10 ve yapım numarasının 26200 olduğunu net olarak ifade ediyor.

5.1.9. Araç (Tools) Kayıtları

Log içerisindeki msg=”initialized tools registry” tool_count=0 ifadesi, modelin harici araçları (fonksiyon çağırma, web araması, kod çalıştırma vb.) kullanabilme yeteneğini başlattığını göstermektedir. Ancak tool_count=0 değeri, bu analiz edilen oturumda Ollama’ya entegre edilmiş herhangi bir dış aracın yapılandırılmadığını veya yüklenmediğini gösterir. Bu durum, modelin dış dünya ile etkileşim kapasitesinin (izole bir laboratuvar ortamında olmasından ötürü) sınırlı olduğunu açıkça gösterir.

5.1.10. Arayüz ve Sunucu Süreçlerinin Ayrışması

Kayıtlarda yer alan şu iki satır, uygulamanın mimari yapısı hakkında önemli bir ipucu verir: msg=”starting ui server” port=51629 msg=”starting ollama server” Ollama’nın Windows sürümünde, arka planda çalışan ana LLM motoru (ollama server) ile kullanıcının etkileşime girdiği sistem tepsisi uygulaması (ui server) ayrı süreçler olarak ele alınmaktadır. UI sunucusunun 51629 gibi yüksek ve dinamik (geçici) bir port üzerinden başlatılması, uygulamanın yerel sistemdeki diğer servislerle çakışmamak adına esnek bir ağ tahsisi yaptığını gösterir. Ağ trafiği analizinde (PCAP vb.) bu portun tespiti, UI etkileşimlerini ayırt etmek için kritik bir göstergedir.

5.1.11. Güncelleme Mekanizması

Log dosyasının geri kalan büyük bir kısmı, uygulamanın otomatik güncelleme (updater) rutinine aittir. msg=”beginning update checker” interval=1h0m0s parametresi, sistemin her 1 saatte bir düzenli olarak yeni sürüm kontrolü yaptığını göstermektedir.

Bu sürecin adli açıdan en değerli artefaktları ağ iletişimi ve dosya indirme konumlarıdır:

msg=”New update available at

https://github.com/ollama/ollama/releases/download/v0.16.2/OllamaSetup.exe” kaydı, uygulamanın dış ağda doğrudan GitHub sunucularıyla iletişim kurduğunu ve bu adres üzerinden düzenli sinyal aktivitesi gerçekleştirdiğini doğrular.

Yeni kurulum dosyasının fiziksel olarak diske yazıldığı konum loglara detaylıca yansımıştır:

msg=”new update downloaded

C:\\Users\\LLM_Forensics\\AppData\\Local\\Ollama\\updates_v2\\0x8DE6DB006FA038D\\OllamaSetup.exe“. Burada yer alan updates_v2 klasörü altındaki 0x8DE6DB006FA038D şeklindeki hex (onaltılık) formatındaki klasör ismi, güncelleme paketinin bütünlüğünü doğrulamak için kullanılan bir hash veya kimlik (ID) değeridir.

Makale ayrıca model manifest ve model layer verilerinin de elde edilebileceğini belirtmektedir. Model manifest, model katmanlarının metadata’sını; model layers ise şablon (template) ve parametre bilgilerini sağlar.

İncelenen imajdaki dosya sistemi yapısına (Şekil 4) bakıldığında, model dosyalarının C:\LLM_Forensic_Lab\Ollama\Models\blobs dizini altında tutulduğu görülmektedir. Burada dikkat çeken en önemli adli artefakt, dosyaların klasik bir isim (örn: llama3.gguf) yerine, doğrudan kendi içeriklerinin SHA-256 özet (hash) değerleriyle isimlendirilmiş olmasıdır (örn: sha256-dde5aa…)

Bu mimari, soruşturmacılar için model bütünlüğünün (integrity) doğrulanmasını son derece kolaylaştırır.

Sistemdeki bir modelin kötü amaçlı olarak manipüle edilip edilmediği, dosyanın yeniden hash’lenip adıyla karşılaştırılması ile anında tespit edilebilir.

5.2.Chatbox

Client interface uygulamaları, LLM uygulama ortamında artefakt’ların birincil kaynağıdır. Bu kanıtlar, kullanılan LLM hakkında bilgi, system prompt yapılandırmaları ve konuşma içerikleri bulunur.

LangurTrace gibi temel çalışmalar, istemci arayüzlerinde yapılandırma ayarları ile sohbet geçmişlerinin (chat-sessions) genellikle config.json gibi merkezi dosyalarda, hibrit bir yapıda tutulabildiğine işaret etmektedir. Ancak Chatbox (v1.18.2) üzerinde yaptığımız bu inceleme, modern uygulamaların bu teorik beklentiden uzaklaştığını ve yapılandırma (config) ile döküm (sohbet) verilerini birbirinden ayıran bir veri ayrıştırma stratejisi izlediğini göstermektedir.

Elde ettiğimiz imaj üzerindeki config.json dosyası incelendiğinde, dosyanın işlevinin tamamen kullanıcı arayüzü tercihleri ve model tanımlamalarıyla sınırlandırıldığı tespit edilmiştir. Dosya içerisinde API anahtarları için ayrılan bölümlerin bulunmasına rağmen bu alanların boş olduğu görülmüş ve uygulamanın veri yapısında “chat-sessions” (sohbet geçmişi) anahtarına bu dosya içerisinde rastlanmamıştır.

Buna karşılık, elde edilen main.log kayıtları literatürde belirtilen yedekleme ve güncelleme takibi mekanizmalarını doğrular niteliktedir. config.json dosyasında sohbet geçmişine rastlanmamasına karşın, aşağıdaki dizinlerde kullanıcı verilerinin bulunduğu tespit edilmiştir:

Bu bulgular, güncel sürümde sohbet verilerinin tarayıcı tabanlı veri depolama mekanizmaları (LevelDB altyapısı) üzerinden tutulduğunu göstermektedir. Dolayısıyla adli analiz süreçlerinde yalnızca config.json dosyasına odaklanmak yeterli olmayıp, istemciye ait LocalStorage ve IndexedDB dizinlerinin de bütüncül olarak incelenmesi gerekmektedir.

İnceleme sırasında,

Users\LLM_Forensics\AppData\Roaming\xyz.chatboxapp.app\IndexedDB\file__0.indexeddb.leveldb dizinindeki veri tabanı kayıtları çözümlenmiş ve config.json dosyasında rastlanmayan “Sohbet Oturumları” (Chat Sessions) bu alanda tespit edilmiştir. Elde edilen ham (raw) veriler, uygulamanın kullanıcı mesajlarını ve yapay zekâ yanıtlarını karmaşık bir JSON nesnesi halinde bu veri tabanında sakladığını kanıtlamaktadır.

IndexedDB Ham Veri Sınıflandırma Tablosu

Users\LLM_Forensics\AppData\Roaming\xyz.chatboxapp.app\LocalStorage\leveldb dizini, uygulamanın çalışma anındaki durumunu (state) ve kullanıcı tercihlerini sakladığı ana merkezdir. Adli bir incelemede bu alanın analizi, kullanıcının niyetini, alışkanlıklarını ve uygulamanın en son hangi teknik parametrelerle kullanıldığını ortaya koyar. Özellikle uygulamanın kullanıcı yazarken gerçekleştirdiği otomatik kayıt işlemleri, bir sorgunun nasıl şekillendiğini ve hangi aşamalardan geçtiğini (örneğin hatalı yazımların düzeltilmesi) kronolojik olarak takip etmeyi mümkün kılar. Bu durum, sadece “ne konuşulduğunu” değil, kullanıcının “nasıl bir hazırlık yaptığını” da kanıtlayarak adli profil çıkarma sürecine büyük katkı sağlar.

IndexedDB yapısı, LLM ile gerçekleşen diyaloğun ‘nihai ve kalıcı’ kayıtlarını (chat-sessions) saklarken; LocalStorage yapısı, kullanıcının sorgu oluşturma sürecindeki ‘davranışsal ve geçici’ izlerini (input-history, drafts) barındırmaktadır. Adli bir incelemede her iki katmanın birlikte analizi hem gerçekleşen konuşmayı hem de kullanıcının o konuşmaya giden yoldaki silinmiş veya taslak aşamasındaki düşüncelerini ortaya çıkarmaktadır.

Bu çalışmada, Windows tabanlı yerel Büyük Dil Modeli (LLM) ortamlarının adli bilişim perspektifinden standartlaştırılmış bir analizi gerçekleştirilmiş; ortam bileşenleri (backend runtime ve client interface) izole edilerek tekrarlanabilir bir laboratuvar kurgusu üzerinden veri üretim ve toplama stratejileri netleştirilmiştir.

İncelenen LangurTrace metodolojisi rehberliğinde gerçekleştirilen pratik analizler, yerel LLM ekosistemlerinin bıraktığı adli izlerin (artefaktların) klasik yazılımlardan farklı, karmaşık ve çok katmanlı bir yapıya sahip olduğunu ortaya koymuştur. Elde edilen temel bulgular şu şekilde özetlenebilir:

• Motor (Backend) Tarafında Bütünlük ve İzlenebilirlik: Ollama örneğinde incelenen backend servislerinin, geleneksel tek parça dosya yapıları yerine Docker benzeri katmanlı bir blob mimarisi kullandığı görülmüştür. Modellerin isimlerle değil SHA-256 özet (hash) değerleriyle diske yazılması, adli araştırmacılara model bütünlüğünün doğrulanması ve yetkisiz manipülasyonların tespiti konusunda güçlü bir kriptografik zemin sunmaktadır. Ayrıca server.log ve app.log dosyaları; modelin yaşam döngüsü, ağ etkileşimleri ve donanım kullanımına dair kesin bir zaman çizelgesi (timeline) oluşturulmasını sağlamaktadır.
• Literatür ve Pratik Arasındaki Ayrışma: İstemci (Client) arayüzü olan Chatbox üzerinde yapılan incelemeler, çalışmanın en kritik adli bulgusunu ortaya çıkarmıştır. İlgili literatürde kullanıcı yapılandırmalarının ve sohbet oturumlarının ana merkezi olarak gösterilen config.json dosyasının, güncel mimarilerde bu işlevini yitirdiği tespit edilmiştir. İstemci uygulamalarının, verileri tarayıcı tabanlı modern depolama mekanizmalarına (LevelDB) taşıdığı kanıtlanmıştır.
• Davranışsal Profilleme ve Niyet Analizi: Sohbet geçmişinin (nihai kayıtların) IndexedDB üzerinde tutulmasına karşın; kullanıcının giriş kutusu geçmişi, taslakları (drafts) ve anlık tercihlerinin LocalStorage üzerinde saklandığı keşfedilmiştir. Bu veri ayrıştırma stratejisi, adli inceleme süreçlerine yeni bir boyut kazandırmaktadır: Soruşturmacılar artık yalnızca “yapay zekâ ile ne konuşulduğunu” değil, kullanıcının “nasıl bir sorgu hazırlığı yaptığını”, sildiği metinleri ve temel niyetini de kronolojik olarak haritalandırabilme imkanına sahiptir.

Özetle, yerel LLM uygulamalarının hızla yaygınlaştığı günümüz teknoloji ikliminde, adli bilişim uzmanlarının yalnızca belirli konfigürasyon dosyalarına odaklanması eksik ve yanıltıcı sonuçlar doğuracaktır. Doğru bir “triage” (önceliklendirilmiş veri toplama) ve imaj analizi için hem backend loglarının hash mimarisiyle çaprazlanması hem de istemci tarafındaki dinamik web veri tabanlarının (LevelDB) bütüncül olarak incelenmesi standart bir prosedür haline gelmelidir.

Bu makale, yerel LLM artefaktlarının standartlaştırılması adına bir temel oluşturmaktadır. Gelecek çalışmalarda, bu izlerin sistem belleği (RAM) üzerindeki yansımalarının (memory forensics) incelenmesi ve bulut tabanlı API etkileşimlerinin adli analiz süreçlerine dâhil edilmesi hedeflenmektedir.

Kâmil Akdağ, MSc

 - 10 Nisan 2026, Cuma