Not: Bu yazı adli analiz ve kendi verinizi kurtarma senaryoları içindir. Gerçek diskte değil, imaj kopyası üzerinde çalışın. Yazma işlemi, kurtarılabilir veriyi ezebilir.

Silinme Ne Demek?

Dosya sistemi bir dosyayı genellikle iki parçayla takip eder: metadata ve data. Metadata; isim, izin, zaman damgası, inode numarası ve verinin hangi bloklarda durduğunu söyler. Data ise dosyanın gerçek içeriğidir.

Basitleştirilmiş denklem şöyle düşünülebilir:

Silme sırasında dizin girdisi kaldırılır, inode’un bağlantı sayısı düşer ve bloklar “boş” kabul edilir. Ama bloklar üzerine yeni veri yazılmadıysa hâlâ oradadır.

Bu yazıda ana örneği Ext4 üzerinden kuracağız; Btrfs için de mantığı karşılaştıracağız.

Güvenli Laboratuvar Hazırlığı

Önce diskten ya da bölümden imaj alın:

sudo dd if=/dev/sdb1 of=disk.img bs=4M status=progress conv=noerror,sync
cp disk.img lab.img
hexedit lab.img

hexedit içinde gezinirken unutmayın: sayılar çoğu zaman little-endian saklanır. Yani ekranda 00 10 00 00 görüyorsanız bu değer 0x00001000, yani 4096 olabilir.

Ext4 Inode Adresini Hesaplamak

Ext4’te süperblok genelde bölüm başlangıcından 1024 byte sonra başlar. Buradan blok boyutu, inode boyutu, grup başına inode sayısı gibi bilgiler okunur.

Blok boyutu formülü:

Bir inode’un disk üzerindeki konumu için:

Örneğin inode numarası 131083, blok boyutu 4096, inode boyutu 256 ve grup başına inode sayısı 8192 ise ilgili blok grubunu ve inode tablosundaki yerini bu formüllerle buluruz.

Inode İçindeki İpuçları

Ext4 inode yapısında önemli alanlar şunlardır:

Silinmiş dosyada i_links_count sıfır olabilir ve i_dtime doludur. Asıl hazine ise i_block alanındadır. Modern Ext4 çoğunlukla extent kullanır. i_block alanında 0a f3 görürseniz, bu little-endian 0xf30a extent sihirli değeridir.

Extent başlığı kabaca şöyledir:

struct ext4_extent_header {
  __le16 eh_magic;    // 0xf30a
  __le16 eh_entries;  // kaç kayıt var
  __le16 eh_max;
  __le16 eh_depth;    // 0 ise yaprak
  __le32 eh_generation;
}

eh_depth = 0 ise hemen ardından gerçek extent kayıtları gelir:

struct ext4_extent {
  __le32 ee_block;     // dosya içi mantıksal blok
  __le16 ee_len;       // uzunluk
  __le16 ee_start_hi;  // fiziksel blok üst bitler
  __le32 ee_start_lo;  // fiziksel blok alt bitler
}

Fiziksel blok hesabı:

Byte offset ise:

Veriyi Çekmek

Diyelim extent bize fiziksel blok 250000, uzunluk 12, blok boyutu 4096 dedi. Dosyayı şöyle çıkarabiliriz:

dd if=lab.img of=recovered.bin bs=4096 skip=250000 count=12 status=progress

Bu komut imajdan 12 blok okur ve recovered.bin dosyasına yazar. Dosya parçalıysa her extent ayrı çıkarılır, sonra mantıksal blok sırasına göre birleştirilir.

Btrfs Neden Daha Çetrefilli?

Btrfs’te klasik “inode tablosu” beklentisi boşa düşer. Metadata B-tree yapılarında tutulur; ayrıca Copy-on-Write sayesinde eski sürümlerin izleri kalabilir. Bu harika bir kurtarma şansı sunar ama elle hex ile çözümlemek Ext4’e göre daha zahmetlidir.

Sonuç

Ext4’te manuel kurtarma; süperbloktan parametreleri okumak, inode adresini hesaplamak, extent kayıtlarını yorumlamak ve fiziksel blokları dd ile çekmekten ibarettir. Btrfs ise daha modern ve güçlüdür ama elle analizde daha fazla ağaç gezmeyi gerektirir. Kısacası: Ext4 düz bir harita, Btrfs ise üç boyutlu labirenttir. İkisi de çözülebilir; yeter ki byte’lar hâlâ yerinde olsun.

Önce teoriyi netleştirelim. Linux namespace, bir sürece gerçek sistemin yalnızca belirli bir görünümünü verir. Yani süreç kendini ayrı bir makinedeymiş gibi hisseder. Cgroup ise o sürecin ne kadar CPU, bellek veya süreç sayısı kullanabileceğini sınırlar. Basit denklemle: konteyner hissi = izolasyon + kaynak limiti + ayrı dosya sistemi. Bunu şöyle yazabiliriz: $K = N + C + R$, burada $N$ namespace, $C$ cgroup, $R$ rootfs anlamına gelir.

Bir konteynerin kök dosya sistemine ihtiyacı vardır. Debian tabanlı küçük bir rootfs hazırlamak için örnek:

sudo debootstrap --variant=minbase bookworm ./rootfs http://deb.debian.org/debian
sudo mkdir -p ./rootfs/{proc,sys,tmp}

Burada rootfs, konteynerin kendi dünyasıdır. chroot ile bir sürecin kök dizinini buraya çevirebiliriz; fakat tek başına chroot güvenlik sınırı değildir. Asıl izolasyonu unshare komutu ile namespace oluşturarak sağlarız.

Şimdi küçük motorumuzun iskeletini yazalım:

cat > mini-run.sh <<'SH'
#!/usr/bin/env bash
set -euo pipefail

ROOTFS=${ROOTFS:-./rootfs}
ID=${1:-demo}
CG=/sys/fs/cgroup/mini-$ID

mkdir -p $CG
echo +cpu +memory +pids > /sys/fs/cgroup/cgroup.subtree_control 2>/dev/null || true
echo '50000 100000' > $CG/cpu.max
echo $((128*1024*1024)) > $CG/memory.max
echo 64 > $CG/pids.max

unshare --fork --pid --mount --uts --ipc --net --mount-proc \
  chroot $ROOTFS /bin/bash -lc 'hostname mini; mount -t proc proc /proc; exec /bin/bash' &

CHILD=$!
echo $CHILD > $CG/cgroup.procs
wait $CHILD
rm -rf $CG
SH

chmod +x mini-run.sh
sudo ./mini-run.sh ilk-konteyner

Bu betik birkaç kritik şey yapar. Önce cgroup dizini açar, sonra CPU, bellek ve süreç sayısı sınırı koyar. cpu.max satırındaki 50000 100000, her 100000 mikrosaniyelik periyotta 50000 mikrosaniye CPU hakkı demektir. Yani $oran = 50000 / 100000 = 0.5$; kabaca yarım CPU çekirdeği. Bellek sınırı ise $128 * 1024 * 1024$ bayt, yani 128 MB olur.

unshare tarafı daha eğlenceli. --pid ile içerideki kabuk kendini yeni bir süreç ağacında görür. --mount sayesinde mount değişiklikleri dışarı sızmaz. --uts hostname değiştirmeye izin verir. --net yeni ve boş bir ağ namespace açar; bu yüzden konteyner ilk anda internetsizdir. Gerçek motorlar burada veth çifti, bridge ve NAT kurar.

Ağ eklemek istersen fikir şudur: host tarafında bir bridge oluşturulur, konteyner namespace içine bir veth ucu taşınır, IP verilir ve NAT açılır. Bunu elle yapmak öğreticidir ama dağıtıma göre komutlar değişebilir.

Önemli uyarı: Bu betiği root yetkisiyle çalıştırırsın ve bu bir öğrenme aracıdır. Güvenli konteyner motoru yazmak; capability düşürme, salt okunur mount, kullanıcı namespace, seccomp profili ve dikkatli cleanup gerektirir.

Sonuç olarak konteyner, gizemli bir kutu değil; iyi düzenlenmiş bir Linux illüzyonudur. Namespace sürece ayrı bir evren gösterir, cgroup o evrende ne kadar kaynak yakabileceğini belirler, rootfs ise dekoru tamamlar. Docker veya Podman kullandığında artık sadece komut çalıştırmış olmayacaksın; çekirdeğin hangi düğmelerine basıldığını da zihninde göreceksin.

Teorik olarak bir giriş olayı şu üçlüyle düşünülebilir:

Örneğin klavyede A tuşuna basmak için tip EV_KEY, kod KEY_A, değer 1 gönderilir. Tuşu bırakmak için değer 0 kullanılır. Fare hareketi ise EV_REL, REL_X, REL_Y gibi göreli eksen olaylarıyla temsil edilir. Her olay grubundan sonra EV_SYN gönderilerek “bu paket tamamlandı” denir.

Bu yapı fiziksel donanımla sanal donanım arasında hoş bir soyutlama sağlar. Masaüstü ortamı çoğu zaman olayın gerçek fareden mi yoksa sanal aygıttan mı geldiğini umursamaz. Matematiksel olarak fare imlecinin göreli hareketini şöyle düşünebiliriz:

Yani sanal fare REL_X = 30, REL_Y = 10 gönderirse imleç mevcut konumdan sağa 30, aşağı 10 birim hareket eder.

Pratik tarafta Python için evdev kütüphanesi işleri oldukça kolaylaştırır. Önce kurulum yapalım:

sudo apt install python3-evdev

Ayrıca /dev/uinput erişimi gerekir. Çoğu sistemde root yetkisiyle çalıştırmak yeterlidir:

sudo python3 virtual_input.py

Aşağıdaki örnek hem sanal klavye hem de sanal fare özellikleri olan bir cihaz oluşturur. Önce A tuşuna basıp bırakır, ardından fareyi hareket ettirip sol tık gönderir.

from evdev import UInput, ecodes as e
import time

capabilities = {
    e.EV_KEY: [
        e.KEY_A,
        e.KEY_ENTER,
        e.BTN_LEFT
    ],
    e.EV_REL: [
        e.REL_X,
        e.REL_Y
    ]
}

with UInput(capabilities, name='blog-virtual-keyboard-mouse') as ui:
    time.sleep(1)

    # A tuşuna bas ve bırak
    ui.write(e.EV_KEY, e.KEY_A, 1)
    ui.write(e.EV_SYN, e.SYN_REPORT, 0)
    time.sleep(0.1)
    ui.write(e.EV_KEY, e.KEY_A, 0)
    ui.write(e.EV_SYN, e.SYN_REPORT, 0)

    # Fareyi sağa ve aşağı hareket ettir
    ui.write(e.EV_REL, e.REL_X, 80)
    ui.write(e.EV_REL, e.REL_Y, 40)
    ui.write(e.EV_SYN, e.SYN_REPORT, 0)

    # Sol tık
    ui.write(e.EV_KEY, e.BTN_LEFT, 1)
    ui.write(e.EV_SYN, e.SYN_REPORT, 0)
    time.sleep(0.05)
    ui.write(e.EV_KEY, e.BTN_LEFT, 0)
    ui.write(e.EV_SYN, e.SYN_REPORT, 0)

Buradaki capabilities sözlüğü sanal cihazın hangi olayları üretebileceğini bildirir. Eğer KEY_A tanımlamazsanız sonradan A tuşu göndermeye çalışmak anlamlı olmaz; çünkü çekirdek bu aygıtın böyle bir yeteneği olduğunu bilmez.

Güvenlik tarafı önemlidir. Sanal klavye oluşturabilen bir program parola alanına da yazı yazabilir. Bu yüzden /dev/uinput erişimi herkese verilmemelidir. Geliştirme ortamında root kullanmak pratik olsa da üretimde özel grup, udev kuralı ve minimum yetki prensibi tercih edilmelidir.

Sonuç olarak /dev/uinput, Linux’ta fiziksel donanım olmadan giriş simülasyonu yapmak için güçlü ve esnek bir kapıdır. Mantığı kavradığınızda olay tipleri, kodlar ve değerlerden oluşan küçük paketlerle sisteme “gerçekmiş gibi” davranan sanal aygıtlar tanımlayabilirsiniz. Bu da test otomasyonundan erişilebilirlik çözümlerine kadar oldukça geniş ve eğlenceli bir oyun alanı açar.

Önce kritik gerçeği netleştirelim: LUKS yanlış parolayla gerçek diski açamaz. Kriptografik olarak “yanlış ama yine de açılmış gibi” yapmak mümkün değildir; çünkü anahtar türetme sonucu bambaşka olur. Basitçe:

Doğru parola için $K = K_{gerçek}$ olurken, yanlış parola için pratikte rastgele bir $K’$ oluşur. Yani sahte masaüstü, gerçek veriyi açmak yerine ayrı ve izole bir “decoy” sistemden başlatılmalıdır.

Genel mimari

Tasarlayacağımız sistem üç parçadan oluşur:

1. Gerçek LUKS bölüm: Asıl işletim sistemi ve veriler burada durur.
2. Decoy işletim sistemi: Ayrı bir bölümde veya salt-okunur imajda bulunan sahte masaüstü.
3. Initramfs karar katmanı: Boot sırasında parola denemelerini yönetir; başarısızlık eşiği aşılırsa decoy sisteme geçer.

Bu tasarımın en önemli ilkesi şudur: Decoy ortam “inandırıcı” olabilir, ama saldırgana zarar vermemeli, parola toplamamalı ve üçüncü taraf sistemlere saldırı yapmamalıdır. Amaç alarm üretmek ve gerçek veriyi korumaktır.

Eşik mantığı

Sistem, örneğin üç başarısız denemeden sonra decoy ortamı açabilir. Yanlışlıkla kendi kendinizi decoy’a düşürme ihtimali de hesaplanmalıdır. Eğer her denemede doğru girme olasılığınız $q$ ise, $N$ başarısız denemeden sonra decoy’a düşme olasılığı yaklaşık:

Örneğin $q=0.9$ ve $N=3$ için:

Yani binde bir. Bu yüzden eşik değeri güvenlik ile kullanılabilirlik arasında dengelenmelidir.

Karar akışı

Aşağıdaki örnek gerçek sisteme doğrudan kopyalanacak üretim kodu değil, mantığı göstermek için yazılmış güvenli bir iskelettir. Gerçek uygulamada bunu initramfs-tools veya dracut hook yapısına uyarlamak gerekir.

MAX_FAILS=3
fails=0
REAL_DEV=/dev/nvme0n1p3
DECOY_BOOT=/dev/nvme0n1p4

while true; do
  echo 'LUKS parolasını girin:'

  if cryptsetup open --test-passphrase $REAL_DEV; then
    echo 'Doğrulama başarılı, gerçek sistem açılıyor.'
    exec /sbin/boot-real-root
  fi

  fails=$((fails + 1))
  echo 'Parola doğrulanamadı.'

  if [ $fails -ge $MAX_FAILS ]; then
    echo 'Sistem hazırlanıyor...'
    exec /sbin/boot-decoy-root $DECOY_BOOT
  fi

  sleep 2
done

Burada dikkat edilmesi gereken nokta, script’in parolayı dosyaya yazmamasıdır. Ayrıca decoy’a geçerken kullanılan bölüm gerçek LUKS bölümünden tamamen bağımsız olmalıdır.

Decoy masaüstünü inandırıcı yapmak

Decoy sistemin amacı saldırganı oyalamak değil, gerçek veriye ulaştığını düşündürürken hiçbir kritik bilgi sunmamaktır. Örneğin:

• Sahte belgeler ve örnek proje klasörleri bulunabilir.
• Tarayıcı geçmişi gerçek hesaplara bağlı olmamalıdır.
• Ağ erişimi kısıtlanmalı veya yalnızca güvenli bir izleme ağına açılmalıdır.
• Sistem salt-okunur imajdan başlatılıp her açılışta temizlenmelidir.

[decoy]
root_mode=readonly
network=restricted
audit=metadata_only
reset_on_boot=true

Bu yapılandırma fikri, decoy ortamın her açılışta temiz bir duruma dönmesini sağlar. Böylece saldırganın bıraktığı dosyalar kalıcı olmaz; yalnızca zaman, deneme sayısı ve cihaz durumu gibi zararsız metaveriler kaydedilir.

Son söz

LUKS tabanlı bir sahte masaüstü tuzağı, kriptografiyi kırmaya çalışmaz; aksine kriptografinin sağlamlığını kabul edip aldatma katmanını boot sürecine ekler. En güvenli yaklaşım, gerçek veriyi hiçbir koşulda decoy ortama bağlamamak, parola toplamamak ve sistemi önce sanal makinede test etmektir. Doğru tasarlandığında bu yöntem, dizüstü bilgisayarınızı yalnızca kilitleyen değil, aynı zamanda saldırı davranışını görünür kılan akıllı bir savunma katmanına dönüştürür.

Temel fikir: satır = görev, process = işçi

Klasik bir program dosyayı satır satır okur ve her satırı sırayla işler. Paralel modelde ise $n$ satır için en fazla $n$ child process üretilebilir. Her child kendi satırını işler, sonucunu pipe üzerinden parent process’e yollar. Parent da sonuçları okuyup tek satır hâline getirir.

Teorik olarak toplam süre şöyle düşünülebilir:

$T_{seri} = \sum_{i=1}^{n} t_i$

Paralel modelde ideal durumda:

$T_{paralel} \approx \max(t_i) + T_{fork} + T_{pipe} + T_{wait}$

Yani her şey bedava değildir. Process oluşturmanın, pipe açmanın ve context switch’in maliyeti vardır. Bu yüzden bu yöntem özellikle satır başına yapılan işlem yeterince “ağırsa” mantıklıdır.

Kullanacağımız sistem çağrıları

Aşağıdaki örnekte her satırı ayrı child process’e veriyoruz. Child, satırı küçük bir işlemden geçiriyor: boşlukları _ karakterine çeviriyor ve sonucu pipe ile parent’a gönderiyor. Gerçek hayatta bu bölüm exec() ile harici bir programa da devredilebilir.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>

#define MAX_LINE 256
#define MAX_CHILD 128

void transform(char *s) {
    for (int i = 0; s[i]; i++) {
        if (s[i] == ' ' || s[i] == '\n') s[i] = '_';
    }
}

int main(int argc, char *argv[]) {
    if (argc != 2) {
        fprintf(stderr, "Kullanim: %s dosya.txt\n", argv[0]);
        return 1;
    }

    FILE *fp = fopen(argv[1], "r");
    if (!fp) { perror("fopen"); return 1; }

    int pipes[MAX_CHILD][2];
    pid_t pids[MAX_CHILD];
    int count = 0;
    char line[MAX_LINE];

    while (fgets(line, sizeof(line), fp) && count < MAX_CHILD) {
        if (pipe(pipes[count]) == -1) { perror("pipe"); exit(1); }

        pid_t pid = fork();
        if (pid == -1) { perror("fork"); exit(1); }

        if (pid == 0) {
            close(pipes[count][0]);
            transform(line);
            dprintf(pipes[count][1], "%s", line);
            close(pipes[count][1]);
            _exit(0);
        }

        close(pipes[count][1]);
        pids[count] = pid;
        count++;
    }
    fclose(fp);

    printf("Sonuc: ");
    for (int i = 0; i < count; i++) {
        char buffer[MAX_LINE];
        ssize_t n = read(pipes[i][0], buffer, sizeof(buffer) - 1);
        if (n > 0) {
            buffer[n] = '\0';
            printf("%s ", buffer);
        }
        close(pipes[i][0]);
        waitpid(pids[i], NULL, 0);
    }
    printf("\n");

    return 0;
}

Kodun önemli noktası şudur: Child sadece yazma ucunu, parent ise sadece okuma ucunu kullanır. Kullanılmayan pipe uçlarını kapatmazsak EOF davranışı bozulabilir ve program “neden bitmiyor?” diye bizi gece 03:00’te kahveye mahkûm edebilir.

exec() eklemek istersek

Child içinde kendi fonksiyonumuzu çalıştırmak yerine harici bir komuta veri göndermek mümkündür. Bunun için genellikle iki pipe gerekir: biri child’ın stdin’ine, diğeri stdout’una bağlanır. Mantık şu şekildedir:

// child tarafında kavramsal akış
// dup2(inputPipe[0], STDIN_FILENO);
// dup2(outputPipe[1], STDOUT_FILENO);
// execlp("tr", "tr", "a-z", "A-Z", NULL);

Burada tr komutu stdin’den aldığı metni dönüştürür, stdout’a yazar. Parent da stdout pipe’ından sonucu toplar. Böylece her satır ayrı bir Unix filtresinden geçmiş olur.

Sıralama ve güvenlik notları

Parent sonuçları pids dizisindeki sıraya göre okuduğu için çıktı dosyadaki satır sırasını korur. Ancak çok büyük dosyalarda her satıra process açmak tehlikelidir. Daha sağlıklı model, aynı anda en fazla $k$ child çalıştırmaktır. Bu durumda yaklaşık kaynak sınırı:

$aktif_process \leq k$

Sonuç olarak bu paralel boru hattı, process izolasyonunu, pipe tabanlı iletişimi ve Unix’in “her şey dosya tanımlayıcıdır” felsefesini aynı sahnede buluşturur. Küçük dosyalarda eğlenceli, ağır satır işlemlerinde güçlü, sınırsız process açıldığında ise tam bir kaynak canavarına dönüşebilir.

Yani $f_s=44100$ ve $N=4096$ ise çözünürlük yaklaşık 10.77 Hz olur. Bu, gitar akordu için çalışır ama çok hassas değildir. Buffer büyüdükçe frekans çözünürlüğü artar, fakat gecikme de artar. Akort uygulamasının temel tasarım savaşı budur: hızlı mı olsun, hassas mı?

Ham sinyal doğrudan Fourier dönüşümüne verildiğinde bazı sorunlar çıkar. Çünkü biz sonsuz uzunlukta değil, kısa bir ses parçası inceleriz. Kesilen sinyalin kenarları ani sıçrama gibi davranır ve spektral sızıntı oluşur. Bu yüzden buffer’a Hann penceresi uygularız. Ayrık Fourier dönüşümünün fikri şudur:

Burada $X[k]$, sinyalin hangi frekans bileşenlerinde güçlü olduğunu söyler. En büyük genlikli frekans çoğu zaman temel frekanstır; ama enstrümanlarda harmonikler yüzünden bazen ikinci ya da üçüncü harmonik temel frekanstan daha güçlü olabilir. Bu yüzden gerçek uygulamalarda yalnızca en yüksek tepeye güvenmek yerine belirli aralıkta arama, parabolik interpolasyon veya YIN gibi algoritmalar da kullanılır.

Nota tahmini için frekansı en yakın müzikal notaya eşleriz. Batı müziğinde A4 notası 440 Hz kabul edilirse MIDI nota numarası şu formülle bulunabilir:

Sonra $m$ değerini en yakın tam sayıya yuvarlarız. Farkı cent cinsinden gösterirsek kullanıcıya telin pes mi tiz mi olduğunu anlatabiliriz:

Aşağıdaki Python örneği sounddevice ile ses kartından veri alır, NumPy ile FFT uygular ve en yakın notayı hesaplar. Kod öğretici amaçlıdır; sahnede kullanmadan önce gürültü eşiği ve daha sağlam temel frekans algılama eklemek iyi olur.

import numpy as np
import sounddevice as sd

FS = 44100
N = 4096
NOTE_NAMES = ['C', 'C#', 'D', 'D#', 'E', 'F', 'F#', 'G', 'G#', 'A', 'A#', 'B']

def freq_to_note(freq):
    midi = 69 + 12 * np.log2(freq / 440.0)
    nearest = int(round(midi))
    note_freq = 440.0 * (2 ** ((nearest - 69) / 12))
    cents = 1200 * np.log2(freq / note_freq)
    name = NOTE_NAMES[nearest % 12] + str(nearest // 12 - 1)
    return name, cents, note_freq

def detect_pitch(samples):
    samples = samples - np.mean(samples)
    windowed = samples * np.hanning(len(samples))
    spectrum = np.fft.rfft(windowed)
    magnitudes = np.abs(spectrum)
    freqs = np.fft.rfftfreq(len(samples), 1 / FS)

    valid = (freqs > 60) & (freqs < 1200)
    index = np.argmax(magnitudes[valid])
    freq = freqs[valid][index]
    return freq

with sd.InputStream(channels=1, samplerate=FS, blocksize=N) as stream:
    while True:
        data, _ = stream.read(N)
        samples = data[:, 0]
        if np.max(np.abs(samples)) < 0.01:
            continue
        freq = detect_pitch(samples)
        note, cents, target = freq_to_note(freq)
        print(f'{freq:7.2f} Hz -> {note}, hedef {target:7.2f} Hz, sapma {cents:+5.1f} cent')

Kodda önce DC bileşenini temizlemek için ortalamayı çıkarıyoruz. Ardından Hann penceresi uygulayıp rfft ile yalnızca pozitif frekansları hesaplıyoruz. 60-1200 Hz aralığı gitar, bağlama, ukulele ve birçok melodik enstrüman için pratik bir başlangıçtır. En büyük spektral tepe bulunuyor, sonra bu frekans nota adına çevriliyor.

Daha profesyonel bir akort uygulaması için üç geliştirme önerisi çok işe yarar: tepe çevresinde parabolik interpolasyonla frekansı inceltmek, harmonikleri kontrol ederek temel frekansı doğrulamak ve ekranda cent sapmasını ibre ya da renkli göstergeyle sunmak. Sonuçta iyi bir tuner sadece matematik yapmaz; müzisyene sakin, okunabilir ve güvenilir geri bildirim verir. Fourier burada büyülü değnek değil, sesin içindeki düzeni görünür kılan güçlü bir büyüteçtir.

Önce etik sınır: SSH anahtarın varsa her şeyi yapabilir misin?

Hayır. SSH erişimi teknik yetki verir, hukuki ve etik izin vermez. Mikrofon, kamera gibi algılayıcılar kişisel veri toplar. Bir makinede yönetici olsan bile ortamda bulunan herkesin açık rızası olmadan mikrofonu etkinleştirip odadan ses almak kabul edilemez. Güvenli yaklaşım şudur: cihaz sahibi, ortam kullanıcıları ve test zamanı önceden belli olmalı; kayıt yapılmamalı; test göstergesi görünür olmalı.

Akustik geri beslemenin mantığı

Mikrofondan alınan sinyal hoparlörden tekrar ortama verildiğinde bir döngü oluşur. Basitleştirilmiş model:

Burada $G$ toplam kazanç, $\tau$ ise gecikmedir. Eğer belirli bir frekansta döngü kazancı $G(f) \ge 1$ olur ve faz yaklaşık $2\pi k$ hizasına gelirse sistem ıslık, uğultu veya çınlama üretir. Yani sorun sadece sesin yüksekliği değil; mikrofon-hoparlör mesafesi, oda yansımaları, ekolayzır ve gecikmedir.

SSH burada ne işe yarar?

SSH, ses kablosu değil; uzaktan yönetim kanalıdır. Güvenli kullanımda SSH ile cihaz durumu okunabilir, test servisleri başlatılabilir veya sanal ses aygıtları denetlenebilir. Örneğin aşağıdaki komutlar yalnızca ses altyapısını listeler; mikrofonu canlı dinlemeye açmaz:

ssh admin@lab-makinesi 'hostname; pactl info; pactl list short sources; pactl list short sinks'

Bu çıktılar PipeWire/PulseAudio üzerinde hangi giriş ve çıkışların bulunduğunu anlamaya yarar. Burada kritik nokta, gerçek mikrofon kaynağını hoparlöre bağlayan otomatik bir komut çalıştırmamaktır.

Güvenli test: gerçek oda sesi yerine sanal kaynak

Akustik zinciri öğrenmek için önce sanal bir çıkış oluşturmak daha güvenlidir. Böylece gerçek ortam sesi toplanmaz:

pactl load-module module-null-sink sink_name=lab_sink sink_properties=device.description=Lab_Test_Sink
pactl list short sinks

Bu komut bir null sink oluşturur. Yani ses sistemi içinde hedef gibi görünen ama fiziksel hoparlöre gitmeyen bir test noktası üretir. Ardından kısa bir test tonu yerel makinede çalınabilir:

speaker-test -t sine -f 440 -l 1

440 Hz tonu, zincirin çalışıp çalışmadığını anlamak için klasik ve zararsız bir referanstır. Ölçüm yaparken ses seviyesini düşük tutmak kulak sağlığı açısından önemlidir.

Basit güvenlik kapısı fikri

Yetkili laboratuvarlarda bile test komutlarının yanlışlıkla çalışmasını önlemek gerekir. Aşağıdaki örnek betik, açık rıza dosyası yoksa testi durdurur:

#!/usr/bin/env bash
set -euo pipefail

CONSENT_FILE='/tmp/audio-test-consent-ok'

if [ ! -f "$CONSENT_FILE" ]; then
  echo 'Onay dosyası yok. Ses testi başlatılmadı.'
  exit 1
fi

echo 'Onay bulundu. Sadece cihaz listesi okunuyor.'
pactl list short sources
pactl list short sinks

Bu betik bir güvenlik çözümü değil, iyi alışkanlık örneğidir. Asıl güvenlik; süreç, bilgilendirme ve erişim kontrolünden gelir.

Sonuç

Mikrofonu hoparlöre döndürmek, sinyal işleme açısından eğitici bir konudur: kazanç, faz, gecikme ve oda akustiği aynı anda devreye girer. Fakat SSH üzerinden uzaktaki bir ortamın sesini dinlemek, izinsiz yapıldığında teknik meraktan çıkar ve mahremiyet ihlaline dönüşür. En doğru yol; sanal aygıtlarla öğrenmek, fiziksel testlerde açık rıza almak ve gerçek mikrofon verisini yalnızca gerekli, görünür ve kayıt dışı koşullarda kullanmaktır.

X11, Linux masaüstlerinde uzun yıllardır kullanılan bir pencereleme sistemidir. Burada uygulamalar “client”, ekran, klavye ve fare gibi kaynakları yöneten yapı ise “server” gibi düşünülebilir. Fare imleci de bu sunucunun yönettiği ortak bir varlıktır. Biz xinput ile giriş aygıtlarını ve olaylarını gözlemleyebilir, xdotool ile imleci hareket ettirebilir veya konumunu okuyabiliriz.

Temel matematik oldukça sade. İmlecin ekrandaki konumunu şu vektörle temsil edelim: $p_t = (x_t, y_t)$. Bir sonraki örnekte elimizde $p_{t+1} = (x_{t+1}, y_{t+1})$ varsa, tuvale çizeceğimiz çizgi parçası bu iki noktanın birleşimidir. İmleci piksel piksel hareket ettirmek istediğimizde ise her adımda $\Delta x$ ve $\Delta y$ değerlerini genellikle $-1$, $0$ veya $1$ seçeriz. Böylece hareket, büyük sıçramalar yerine minik adımlar halinde gerçekleşir.

Önce sistemde gerekli araçları kurarak başlayalım:

sudo apt install xdotool xinput python3-tk

Fare aygıtlarını görmek için:

xinput list

Daha detaylı olay akışını izlemek isterseniz şu komut faydalıdır:

xinput test-xi2 --root

Bu çıktı, X11’in fare hareketini nasıl olaylara dönüştürdüğünü anlamak için harikadır. Ancak canlı çizim uygulamasında pratiklik adına konumu xdotool getmouselocation ile okuyacağız.

Aşağıdaki Python kodu bir Tkinter penceresi açar, imlecin ekran koordinatlarını düzenli olarak okur ve önceki konumla yeni konum arasına çizgi çeker. Ayrıca küçük bir otomasyon fonksiyonu, imleci piksel piksel hareket ettirerek ekranda iz bırakmasını sağlar.

import tkinter as tk
import subprocess
import time
import threading

WIDTH, HEIGHT = 900, 600
last_point = None

def get_mouse_position():
    out = subprocess.check_output(['xdotool', 'getmouselocation']).decode()
    parts = dict(item.split(':') for item in out.split() if ':' in item)
    return int(parts['x']), int(parts['y'])

def move_relative(dx, dy):
    subprocess.call(['xdotool', 'mousemove_relative', '--sync', '--', str(dx), str(dy)])

def draw_loop():
    global last_point
    x, y = get_mouse_position()

    # Ekran koordinatlarını basitçe tuval sınırlarına sıkıştırıyoruz.
    cx = max(0, min(WIDTH, x))
    cy = max(0, min(HEIGHT, y))

    if last_point is not None:
        canvas.create_line(last_point[0], last_point[1], cx, cy, fill='lime', width=2)

    last_point = (cx, cy)
    root.after(16, draw_loop)  # Yaklaşık 60 FPS örnekleme

def pixel_walk():
    # Küçük kare benzeri bir rota: sağ, aşağı, sol, yukarı
    route = [(1, 0)] * 120 + [(0, 1)] * 80 + [(-1, 0)] * 120 + [(0, -1)] * 80
    for dx, dy in route:
        move_relative(dx, dy)
        time.sleep(0.01)

def start_walk():
    threading.Thread(target=pixel_walk, daemon=True).start()

root = tk.Tk()
root.title('X11 Canlı İmleç Tuvali')
canvas = tk.Canvas(root, width=WIDTH, height=HEIGHT, bg='black')
canvas.pack()

button = tk.Button(root, text='Piksel Piksel Yürüt', command=start_walk)
button.pack(fill='x')

draw_loop()
root.mainloop()

Burada draw_loop fonksiyonu kalp atışı gibidir. Her 16 milisaniyede bir imlecin nerede olduğunu sorar. Eğer önceki nokta biliniyorsa, iki nokta arasına çizgi çeker. Bu yüzden imleç hızlı hareket etse bile yol, kesik noktalar yerine çizgi segmentleri olarak görünür. pixel_walk ise imleci küçük adımlarla gezdirir; yani bizim minik robot ressamımızdır.

Koordinat dönüşümü önemlidir. Örnekte ekran koordinatlarını doğrudan tuval sınırlarına sıkıştırdık. Daha doğru bir yaklaşım için ekran boyutu $S_w \times S_h$, tuval boyutu $C_w \times C_h$ ise dönüşüm şöyle olabilir: $c_x = x \cdot C_w / S_w$, $c_y = y \cdot C_h / S_h$.

Bu proje X11’in ne kadar esnek olduğunu gösteren eğlenceli bir örnektir. Wayland oturumlarında güvenlik nedeniyle bu komutların bazıları çalışmayabilir; bu yüzden denemeyi X11 oturumunda yapmalısınız. Sonuçta birkaç komut satırı aracı, biraz Python ve basit vektör mantığıyla imleci hem hareket ettiren hem de izini çizen canlı bir dijital eskiz defteri elde etmiş olduk.

DCG, görünüşte basit bir sözdizimi sunar. Aşağıdaki mini gramer, İngilizce küçük cümleleri tanır:

sentence --> noun_phrase, verb_phrase.

noun_phrase --> determiner, noun.
verb_phrase --> verb.

determiner --> [the].
determiner --> [a].

noun --> [cat].
noun --> [dog].

verb --> [sleeps].
verb --> [runs].

Bu kodda sentence --> noun_phrase, verb_phrase. kuralı, bir cümlenin önce isim öbeği sonra fiil öbeğinden oluştuğunu söyler. Köşeli parantez içindeki ifadeler ise doğrudan tüketilecek kelimelerdir. Prolog tarafında şu sorgu çalıştırılabilir:

?- phrase(sentence, [the, cat, sleeps]).
true.

Burada phrase/2, verilen kelime listesinin gramer tarafından tamamen ayrıştırılıp ayrıştırılamadığını kontrol eder. Eğer liste kurallara uyuyorsa sonuç true olur. Uymuyorsa Prolog başka kural yollarını dener; bulamazsa başarısız olur. Bu noktada DCG’nin güzelliği ortaya çıkar: Ayrıştırma, aslında mantıksal çıkarımdır.

İşin teorik tarafında DCG, bağlamdan bağımsız gramerlere oldukça yakındır; fakat Prolog’un değişkenleri ve hedefleri sayesinde daha esnektir. Örneğin yalnızca cümleyi tanımak değil, aynı zamanda bir ayrıştırma ağacı üretmek de mümkündür:

sentence(s(NP, VP)) --> noun_phrase(NP), verb_phrase(VP).

noun_phrase(np(Det, Noun)) --> determiner(Det), noun(Noun).
verb_phrase(vp(Verb)) --> verb(Verb).

determiner(det(the)) --> [the].
noun(n(cat)) --> [cat].
verb(v(sleeps)) --> [sleeps].

Sorgu şöyle olur:

?- phrase(sentence(Tree), [the, cat, sleeps]).
Tree = s(np(det(the), n(cat)), vp(v(sleeps))).

Bu ağaç, cümlenin yalnızca geçerli olduğunu değil, hangi parçalarının hangi dilbilgisel rolleri üstlendiğini de gösterir. Yani DCG, kelimeleri boncuk gibi dizmekten çok, onlardan anlamlı bir iskelet çıkarır.

DCG’nin perde arkasında fark listeleri bulunur. Prolog, s --> np, vp. gibi bir kuralı aslında giriş ve kalan listeyi taşıyan bir yapıya çevirir. Mantıksal olarak amaç şuna benzer: $phrase(Gramer, Girdi, Kalan)$. Eğer Kalan = [] ise tüm cümle başarıyla tüketilmiştir. Bu sayede ayrıştırma verimli ve deklaratif kalır.

Elbette insan dili karmaşıktır: ekler, belirsizlikler, devrik cümleler, çok anlamlılık ve bağlam gibi canavarlar pusudadır. Yine de DCG, bu canavarlarla savaşmak için harika bir başlangıç kılıcıdır. Küçük bir sözlük, birkaç kural ve Prolog’un arama mekanizmasıyla kendi mini ayrıştırıcınızı yazabilirsiniz. Sonuçta DCG bize şunu öğretir: Dil yalnızca kelimelerden değil, kurallardan; programlama ise yalnızca komutlardan değil, ilişkilerden oluşur.

Bu fikir özellikle uzman sistemlerde, oyun yapay zekasında, kural motorlarında ve interaktif asistanlarda çok değerlidir. Çünkü dünya değişir. Kullanıcı yeni bir bilgi verir, sensör farklı bir değer okur, oyunda karakterin canı azalır ya da bir stok ürünü tükenir. Sistem bu değişikliği yalnızca kaydetmekle kalmaz, çıkarım mekanizmasına da hemen yansıtır.

Prolog tarafında assert yeni bir gerçeği veya kuralı belleğe ekler. retract ise eşleşen bir bilgiyi siler. Mini bir örnekle görelim:

:- dynamic hasta/2.
:- dynamic riskli/1.

% Yeni bir hasta bilgisi ekler
hasta_ekle(Isim, Yas) :-
    assert(hasta(Isim, Yas)).

% Yaşı 65 üstü olanları riskli olarak işaretler
risk_degerlendir(Isim) :-
    hasta(Isim, Yas),
    Yas >= 65,
    assert(riskli(Isim)).

% Hasta kaydı silinir
hasta_sil(Isim) :-
    retract(hasta(Isim, _)),
    retractall(riskli(Isim)).

Bu kodda :- dynamic hasta/2. bildirimi önemlidir. Prolog’a bu ilişkinin çalışma zamanında değiştirilebileceğini söyler. hasta_ekle(ayse, 70). çağrıldığında belleğe yeni bir gerçek eklenir. Ardından risk_degerlendir(ayse). çalıştırılırsa sistem Ayşe için riskli(ayse). bilgisini üretir. Yani program yalnızca veri saklamaz; yeni veriye göre kendi bilgi tabanını genişletir.

Ancak burada tatlı bir tehlike var: Kontrolsüz assert kullanımı bilgi tabanını çorba yapabilir. Aynı gerçeği defalarca eklemek, eski bilgiyi silmeden yenisini yazmak veya çelişkili kuralları birlikte tutmak çıkarımları bozabilir. Örneğin hem aktif(kullanici1) hem de pasif(kullanici1) varsa sistemin ne yapacağı tasarıma bağlıdır. Bu yüzden dinamik sistemlerde tutarlılık kuralları gerekir. Mantıksal olarak bir çelişkiyi şöyle düşünebiliriz: $aktif(x) \land pasif(x) \rightarrow \bot$. Buradaki $\bot$, kabul edilemez durumu temsil eder.

Daha güvenli bir güncelleme için önce eski bilgiyi temizleyip sonra yenisini eklemek yaygın bir taktiktir:

:- dynamic konum/2.

% Bir varlığın konumunu günceller
konum_guncelle(Nesne, YeniKonum) :-
    retractall(konum(Nesne, _)),
    assert(konum(Nesne, YeniKonum)).

% Örnek sorgu:
% konum_guncelle(robot1, depo).
% konum(robot1, Nerede).

Burada amaç robotun aynı anda hem mutfakta hem depoda görünmesini engellemektir. Önce robotun eski konumu silinir, ardından güncel konumu eklenir. Bu desen, oyun karakterleri, IoT cihazları veya oturum yönetimi gibi birçok alanda işe yarar.

Sonuç olarak dinamik veri tabanı yönetimi, programa hafıza ve refleks kazandırır. assert ile öğrenen, retract ile unutan sistemler kurabiliriz. Ama her güçlü araç gibi bunun da disiplini vardır: değiştirilebilir predikatları açıkça tanımla, tutarsızlıkları engelle, eski bilgiyi temizle ve güncelleme kurallarını sade tut. Böylece programın sadece çalışan değil, yaşayan bir bilgi sistemine dönüşür.