ext4’ün günlükleme mekanizması, özellikle sistem çökmesi veya elektrik kesintisi gibi durumlarda dosya sisteminin tutarlı kalmasını sağlar. Basit fikir şudur: Kritik meta veri değişiklikleri önce “journal” denen özel bir alana yazılır, ardından asıl konumlarına uygulanır. Böylece sistem yarıda kesilirse ext4, günlüğe bakarak işlemi tamamlayabilir veya geri alabilir.

Teorik olarak bunu küçük bir işlem sırası gibi düşünebiliriz:

Burada commit block, “bu işlem grubu tamamlandı” damgası gibidir. ext4 varsayılan olarak genellikle data=ordered kipinde çalışır: dosya verisi asıl yerine yazılır, meta veri ise journal üzerinden güvenceye alınır.

Journal alanı ext4 içinde çoğunlukla özel bir inode olarak tutulur: inode 8. Biz bu inode’un fiziksel bloklarını debugfs ile bulacağız. Bir blok numarası $P$, blok boyutu $B$ ise byte cinsinden konum:

dd komutu bu ofsete gidip blokları okuyacak, hexdump da bize ham içeriği gösterecek.

Önce güvenli bir laboratuvar oluşturalım:

truncate -s 256M ext4-lab.img
mkfs.ext4 -F ext4-lab.img
mkdir -p mnt-lab
sudo mount -o loop ext4-lab.img mnt-lab

Şimdi izleme betiğimiz gelsin. Bu betik imaj dosyasından blok boyutunu öğrenir, journal inode’unun ilk extent’ini bulur ve belirli aralıklarla o bölgeden veri okuyup hexadecimal biçimde gösterir.

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

IMG="${1:-ext4-lab.img}"
BLOCKS_TO_READ="${2:-4}"
INTERVAL="${3:-1}"

if [[ ! -f "$IMG" ]]; then
  echo "İmaj bulunamadı: $IMG" >&2
  exit 1
fi

BS=$(dumpe2fs -h "$IMG" 2>/dev/null | awk -F: '/Block size/ {gsub(/ /,"",$2); print $2}')

JOURNAL_RANGE=$(debugfs -R 'stat <8>' "$IMG" 2>/dev/null \
  | awk '
    match($0, /\):([0-9]+)-([0-9]+)/, a) { print a[1], a[2]; exit }
    match($0, /\):([0-9]+)/, a) { print a[1], a[1]; exit }
  ')

START_BLOCK=$(echo "$JOURNAL_RANGE" | awk '{print $1}')
END_BLOCK=$(echo "$JOURNAL_RANGE" | awk '{print $2}')

if [[ -z "${START_BLOCK:-}" ]]; then
  echo "Journal blokları bulunamadı. debugfs çıktısını kontrol edin." >&2
  exit 1
fi

OFFSET=$((START_BLOCK * BS))

printf "Blok boyutu      : %s byte\n" "$BS"
printf "Journal başlangıcı: blok %s\n" "$START_BLOCK"
printf "Journal bitişi    : blok %s\n" "$END_BLOCK"
printf "Okunan offset     : %s byte\n\n" "$OFFSET"

while true; do
  clear
  date
  echo "Journal bölgesinden $BLOCKS_TO_READ blok okunuyor..."
  dd if="$IMG" bs="$BS" skip="$START_BLOCK" count="$BLOCKS_TO_READ" status=none \
    | hexdump -C | head -n 40
  sleep "$INTERVAL"
done

Kaydedip çalıştırın:

chmod +x watch-ext4-journal.sh
./watch-ext4-journal.sh ext4-lab.img 8 1

Başka bir terminalde dosya sistemine yazma yapalım:

for i in {1..20}; do
  sudo dd if=/dev/urandom of=mnt-lab/file-$i.bin bs=1M count=2 status=none
  sync
  sleep 1
done

İzleme ekranında bazı byte dizilerinin değiştiğini göreceksiniz. Bunlar her zaman “dosya içeriği” değildir; çoğunlukla inode, dizin girdisi, blok bitmap’i gibi meta veri değişikliklerinin journal kayıtlarıdır.

Buradaki önemli nokta şudur: ext4 journal’ı bir metin günlüğü değildir; insanlar için değil, dosya sisteminin kendisi için tasarlanmış ikili bir yapıdır. Yani ekranda anlamlı cümleler değil, işlem kayıtlarının ham temsillerini görürsünüz. Yine de yazma yaptıkça bu alanın değiştiğini izlemek, journal fikrini soyut bir kavram olmaktan çıkarır.

Deney bitince temizleyin:

sudo umount mnt-lab
rmdir mnt-lab
rm ext4-lab.img

Bu küçük proje sayesinde ext4’ün “önce not al, sonra uygula” mantığını canlı gözlemledik. Dosya sistemleri sessiz çalışır; ama doğru araçlarla bakınca oldukça konuşkandırlar.

GDB’nin Python tarafında en sevdiğimiz oyuncular gdb.Command, gdb.selected_inferior() ve read_memory() fonksiyonlarıdır. gdb.Command ile yeni komut tanımlarız, inferior dediğimiz şey debug edilen süreçtir, read_memory() ise belirli adres aralığındaki ham baytları okumamızı sağlar. Linux üzerinde /proc/<pid>/maps dosyasından [stack] satırını okuyarak gerçek yığın sınırlarını yakalayabiliriz.

Aşağıdaki betik stackstrings adlı yeni bir GDB komutu ekler. Minimum uzunluğu parametre olarak verebilir, aksi halde 4 karakterden uzun stringleri listeler. Çıktıda adresler mavi, stringler yeşil renktedir; çünkü debug yaparken biraz neon ışık herkesin hakkı!

# stackstrings.py
import gdb
import string

GREEN = '\033[92m'
BLUE = '\033[94m'
YELLOW = '\033[93m'
RESET = '\033[0m'

PRINTABLE = set(bytes(string.printable, 'ascii')) - {0x0b, 0x0c}

class StackStrings(gdb.Command):
    '''Yığın bölgesindeki yazdırılabilir stringleri bulur: stackstrings [min_len]'''

    def __init__(self):
        super(StackStrings, self).__init__('stackstrings', gdb.COMMAND_DATA)

    def get_stack_range(self):
        inferior = gdb.selected_inferior()
        pid = inferior.pid
        if pid == 0:
            raise gdb.GdbError('Çalışan bir süreç yok. Önce run veya attach kullan.')

        with open(f'/proc/{pid}/maps', 'r') as maps:
            for line in maps:
                if '[stack]' in line:
                    region = line.split()[0]
                    start_s, end_s = region.split('-')
                    return int(start_s, 16), int(end_s, 16)
        raise gdb.GdbError('Stack bölgesi bulunamadı.')

    def invoke(self, arg, from_tty):
        min_len = int(arg) if arg.strip() else 4
        start, end = self.get_stack_range()
        inferior = gdb.selected_inferior()
        mem = inferior.read_memory(start, end - start).tobytes()

        found = 0
        i = 0
        while i < len(mem):
            if mem[i] in PRINTABLE:
                j = i
                while j < len(mem) and mem[j] in PRINTABLE:
                    j += 1
                if j - i >= min_len:
                    raw = mem[i:j]
                    text = raw.decode('ascii', errors='replace')
                    addr = start + i
                    print(f'{BLUE}0x{addr:x}{RESET}: {GREEN}{text}{RESET}')
                    found += 1
                i = j
            else:
                i += 1

        print(f'{YELLOW}Toplam {found} string bulundu. Aralık: 0x{start:x}-0x{end:x}{RESET}')

StackStrings()

Kullanmak için betiği kaydedip GDB içinde yüklemek yeterli:

gdb ./program
(gdb) run
(gdb) source stackstrings.py
(gdb) stackstrings 6

Buradaki algoritma oldukça basittir: belleği soldan sağa tarar, karakter PRINTABLE kümesindeyse bir koşu başlatır, koşu uzunluğu minimum değeri geçerse sonuç üretir. Zaman karmaşıklığı \(O(N)\), bellek maliyeti ise okunan yığın kadar yani \(O(N)\) kabul edilir. Büyük yığınlarda parça parça okuma yapılabilir; fakat öğretici olması için tek parça okuma daha anlaşılırdır.

Bu komut özellikle CTF, tersine mühendislik, exploit geliştirme ve “ben bu değişkene ne zaman ne yazdım?” soruşturmasında işe yarar. Yine de dikkat: Stack içinde gördüğünüz her karakter dizisi anlamlı string değildir. Rastgele baytlar bazen tesadüfen okunabilir karakterlere dönüşebilir. Bu yüzden bulunan sonuçları bağlamla, register’larla ve backtrace ile birlikte değerlendirmek gerekir.

Sonuç olarak GDB’nin Python API’si, debugger’ı kişisel bir analiz laboratuvarına çevirir. Bugün stack stringlerini renklendirdik; yarın heap tarayıcı, otomatik breakpoint raporlayıcı ya da şüpheli pointer avcısı yazabilirsiniz. Debug dünyasında büyüteç sizde, Python ise büyütecin LED ışığıdır.

Bunun için Linux çekirdeğinin trafik kontrol sistemi olan tc ve onun meşhur netem modülünü kullanacağız. netem, network emulator demektir; paketleri geciktirebilir, düşürebilir, çoğaltabilir, bozabilir veya yeniden sıralayabilir. Bizim hedefimiz şu: izole bir test alanı oluşturmak, uygulamayı bu alanın içinden çalıştırmak ve dış dünyaya çıkan/gelen trafiği bozmak.

Teorik olarak paket kaybını şöyle düşünebiliriz: Her paketin düşme olasılığı $p = 0.05$ ise, bir paketin başarıyla ulaşma olasılığı $1-p = 0.95$ olur. Art arda $n$ paketin tamamının ulaşma olasılığı ise:

Yani 100 paketlik küçük bir aktarımda bile tamamının sorunsuz ulaşma ihtimali yaklaşık $0.95^{100} \approx 0.0059$ olur. Kısacası %5 kulağa az gelir ama protokoller ve kullanıcı deneyimi üzerinde ciddi etkisi vardır.

Önce gerekli araçların kurulu olduğundan emin olalım. Debian/Ubuntu için:

sudo apt update
sudo apt install iproute2 iputils-ping -y

Şimdi bir network namespace ve iki uçlu sanal arayüz oluşturalım. bad0 host tarafında, eth0 ise kötü ağ simülasyonunun içinde kalacak.

# Test namespace oluştur
sudo ip netns add badnet

# Sanal ethernet çifti oluştur
sudo ip link add bad0 type veth peer name eth0

# eth0 ucunu namespace içine taşı
sudo ip link set eth0 netns badnet

# IP adreslerini ver
sudo ip addr add 10.10.0.1/24 dev bad0
sudo ip netns exec badnet ip addr add 10.10.0.2/24 dev eth0

# Arayüzleri ayağa kaldır
sudo ip link set bad0 up
sudo ip netns exec badnet ip link set eth0 up
sudo ip netns exec badnet ip link set lo up

Bu noktada host ile namespace birbirini görebilir. Test edelim:

sudo ip netns exec badnet ping -c 3 10.10.0.1

Şimdi işin eğlenceli kısmı: paket kaybı ve gecikme. Gelen trafiği simüle etmek için host tarafındaki bad0 arayüzünün namespace’e doğru gönderdiği paketlere kural ekleyeceğiz. Yani namespace açısından bu trafik “gelen paket” gibi davranır.

sudo tc qdisc add dev bad0 root netem loss 5% delay 120ms 60ms distribution normal

Bu komut şunu söyler: bad0 üzerinden çıkan paketlerin %5’ini düşür, kalanlara ortalama 120 ms gecikme ekle, bu gecikmeyi 60 ms sapmayla rastgele dağıt. Basitçe gecikmeyi şöyle modelleyebiliriz:

Burada $X$, normal dağılıma benzeyen rastgele bir sapmadır. Böylece her paket aynı sürede gelmez; gerçek ağlardaki “jitter” hissi oluşur.

Eğer namespace içindeki bir uygulamanın internete çıkmasını istiyorsanız IP forwarding ve NAT da ekleyebilirsiniz:

sudo sysctl -w net.ipv4.ip_forward=1
sudo ip netns exec badnet ip route add default via 10.10.0.1

# eth0 yerine internete çıkan gerçek arayüzünüzü yazın; örn: wlan0 veya enp3s0
sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o wlan0 -j MASQUERADE

Artık kötü ağın içinden komut çalıştırabilirsiniz:

sudo ip netns exec badnet curl https://example.com
sudo ip netns exec badnet ping -c 20 8.8.8.8

Sonuçlarda zaman zaman paket kaybı ve değişken ping süreleri görmelisiniz. Web API istemciniz burada timeout, retry, circuit breaker ve kullanıcıya hata gösterme davranışları açısından güzelce sınanır.

Kuralları görmek için:

tc qdisc show dev bad0

Simülasyonu kaldırmak için:

sudo tc qdisc del dev bad0 root
sudo ip netns del badnet
sudo ip link del bad0 2>/dev/null || true

Bu kurulum küçük görünür ama gerçek hayatta çok değerlidir. Çünkü iyi yazılım sadece hızlı ağda çalışan yazılım değildir; paketler kaybolduğunda sakin kalabilen, gecikmede paniklemeyen ve kullanıcıya düzgün geri bildirim verebilen yazılımdır. Kısacası artık bilgisayarınızda minik, kontrollü ve biraz da huysuz bir internet servis sağlayıcınız var.

Netfilter, Linux kernel içinde paketlerin geçtiği kontrol noktaları sunar. Basitleştirilmiş akış şöyle düşünülebilir: paket üretildiğinde LOCAL_OUT, yönlendirilirken FORWARD, makineye girerken LOCAL_IN gibi kancalar devreye girer. Biz yerel makineden çıkan HTTP isteklerini hedeflediğimiz için NF_INET_LOCAL_OUT iyi bir başlangıçtır.

Kernel tarafındaki iskelet kod, paketin TCP ve hedef portunun 80 olup olmadığını kontrol eder. Aşağıdaki örnek tam bir modül değil, mantığı gösteren orta seviye bir kesittir:

#include <linux/module.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/ip.h>
#include <linux/tcp.h>

static unsigned int cat_hook(void *priv,
    struct sk_buff *skb,
    const struct nf_hook_state *state) {

    struct iphdr *iph;
    struct tcphdr *tcph;

    if (!skb) return NF_ACCEPT;
    iph = ip_hdr(skb);
    if (!iph || iph->protocol != IPPROTO_TCP) return NF_ACCEPT;

    tcph = tcp_hdr(skb);
    if (!tcph) return NF_ACCEPT;

    if (ntohs(tcph->dest) == 80) {
        skb->mark = 0xC47;
    }

    return NF_ACCEPT;
}

Bu işaret daha sonra iptables veya nftables ile yerel proxyye yönlendirilebilir. Örneğin işaretli paketleri 8080 portuna almak gibi. Kernel içinde HTTP ayrıştırmaya çalışmak cazip görünse de parçalanmış TCP akışı, checksum güncelleme, bellek güvenliği ve performans nedeniyle kullanıcı alanı çok daha sağlıklı bir yerdir.

Proxy tarafında mantık şudur: isteği gerçek sunucuya gönder, yanıt başlıklarını oku, gövde bir görselse belleğe al, ters çevir, Content-Length değerini güncelle ve istemciye dön. Python ile minik bir örnek:

from io import BytesIO
from PIL import Image

def flip_if_cat(url, headers, body):
    ctype = headers.get('Content-Type', '')
    looks_like_cat = any(x in url.lower() for x in ['cat', 'kitten', 'kedi'])

    if not looks_like_cat:
        return headers, body

    if not ctype.startswith('image/'):
        return headers, body

    img = Image.open(BytesIO(body))
    flipped = img.transpose(Image.Transpose.FLIP_TOP_BOTTOM)

    out = BytesIO()
    fmt = img.format or 'PNG'
    flipped.save(out, format=fmt)
    new_body = out.getvalue()

    headers['Content-Length'] = str(len(new_body))
    return headers, new_body

Buradaki en önemli ayrıntı, HTTP yanıtının sıkıştırılmış olabileceğidir. Content-Encoding: gzip varsa önce açmak, işlemden sonra tekrar sıkıştırmak gerekir. Ayrıca büyük görselleri tamamen belleğe almak yerine akış tabanlı işlemek daha güvenlidir. Deney ortamında ise curl --proxy localhost:8080 http://site/cat.jpg komutu ile hızlıca test yapılabilir.

Sonuç olarak bu proje, netfilterın paket seviyesindeki gücü ile kullanıcı alanındaki esnekliği eğlenceli bir şekilde birleştiriyor. Kernel sadece trafiği seçiyor, proxy ise HTTP ve görsel işleme gibi karmaşık işleri üstleniyor. Böylece hem Linux ağ mimarisini öğreniyor hem de internetin kedilerini kısa süreliğine baş aşağı izliyoruz.

Device Tree, donanıma ait hiyerarşik bir tarif dosyasıdır. Kernel açılırken “şu adreste GPIO var”, “bu I2C kontrolcüsü şu kesmeyi kullanıyor” gibi bilgileri buradan okur. Raspberry Pi’de bu ağaç genellikle /proc/device-tree altında sanal dosya sistemi olarak görünür. Her klasör bir düğüm, her dosya ise bir özelliktir. Örneğin compatible, status, reg ve ranges en sık karşımıza çıkan özelliklerdir.

Buradaki asıl sihir reg alanındadır. Ancak reg düz bir sayı değildir; kaç hücreden oluşacağı üst düğümdeki #address-cells ve #size-cells değerlerine bağlıdır. Basitçe düşünürsek:

Eğer #address-cells = 1 ve #size-cells = 1 ise reg içinde önce başlangıç adresi, ardından boyut gelir. Raspberry Pi SoC çevre birimleri çoğunlukla bellek eşlemeli I/O kullandığından, bu adresler CPU’nun fiziksel adres haritasına bağlanır. Yani GPIO’ya yazmak aslında belirli bir bellek adresine yazmaktır. Eğlenceli tarafı şu: LED yakmak, teoride RAM’e mektup bırakmak gibidir; sadece mektubu alan kişi bir GPIO kontrolcüsüdür.

Adres yorumlarken önemli bir ayrım vardır: Device Tree’de görülen bus adresi her zaman CPU fiziksel adresi olmayabilir. Özellikle Raspberry Pi modellerinde peripheral base adresi modele göre değişebilir. Örneğin eski modellerde 0x20000000, Pi 2/3 tarafında 0x3f000000, Pi 4 tarafında 0xfe000000 sık görülür. Device Tree’deki ranges alanı bu dönüşümün ipucunu verir.

Şimdi Python ile bir tarayıcı yazalım. Amaç: /proc/device-tree altında gezmek, compatible veya düğüm adına göre GPIO/I2C/SPI adaylarını bulmak, reg alanını okuyup adresleri hesaplamak.

from pathlib import Path
import struct

DT = Path('/proc/device-tree')
KEYWORDS = ('gpio', 'i2c', 'spi')

def read_prop(path):
    try:
        return path.read_bytes()
    except FileNotFoundError:
        return None

def read_u32_cells(prop):
    if not prop:
        return []
    count = len(prop) // 4
    return list(struct.unpack('>' + 'I' * count, prop[:count * 4]))

def read_text(prop):
    if not prop:
        return ''
    return prop.replace(b'\x00', b',').decode(errors='ignore').strip(',')

def get_cells(node, name, default):
    current = node
    while current != current.parent:
        value = read_prop(current / name)
        if value:
            cells = read_u32_cells(value)
            return cells[0] if cells else default
        current = current.parent
    return default

def parse_reg(node):
    reg = read_u32_cells(read_prop(node / 'reg'))
    if not reg:
        return []

    parent = node.parent
    addr_cells = get_cells(parent, '#address-cells', 1)
    size_cells = get_cells(parent, '#size-cells', 1)
    step = addr_cells + size_cells
    results = []

    for i in range(0, len(reg), step):
        addr = 0
        size = 0
        for cell in reg[i:i + addr_cells]:
            addr = (addr << 32) | cell
        for cell in reg[i + addr_cells:i + step]:
            size = (size << 32) | cell
        results.append((addr, size))
    return results

def scan():
    for node in DT.rglob('*'):
        if not node.is_dir():
            continue
        name = node.name.lower()
        compatible = read_text(read_prop(node / 'compatible')).lower()
        if any(k in name or k in compatible for k in KEYWORDS):
            regs = parse_reg(node)
            status = read_text(read_prop(node / 'status')) or 'okay?'
            if regs:
                print(f'[{status}] {node.relative_to(DT)}')
                print(f'  compatible: {compatible}')
                for addr, size in regs:
                    print(f'  reg: 0x{addr:08x} size=0x{size:x}')

if __name__ == '__main__':
    scan()

Kodun yaptığı şey oldukça mekanik: dosyaları byte olarak okuyor, Device Tree hücreleri big-endian olduğu için struct.unpack('>I') kullanıyor ve reg alanını üst düğümdeki hücre sayılarına göre parçalıyor. Burada dikkat edilmesi gereken nokta, çıktıdaki adresin her zaman nihai CPU fiziksel adresi olmayabileceğidir. Daha ileri sürümde ranges ayrıştırması ekleyerek bus adresinden fiziksel adrese dönüşüm yapabiliriz.

Mini aracın örnek çıktısı şöyle görünebilir:

[okay] soc/gpio@7e200000
  compatible: brcm,bcm2711-gpio
  reg: 0x7e200000 size=0xb4

[okay] soc/i2c@7e804000
  compatible: brcm,bcm2711-i2c
  reg: 0x7e804000 size=0x1000

Bu proje bize iki önemli şey öğretir: Linux altında donanım bilgisi çoğu zaman zaten elimizin altındadır ve “adres” dediğimiz şey bağlama göre değişir. Device Tree okuma aracı, gömülü Linux dünyasında debugging için İsviçre çakısı gibidir. Bir sonraki adımda çıktıyı JSON’a çevirip web arayüzü ekleyebilir, hatta devmem ile güvenli salt-okunur register inceleme modülü yazabilirsin.

Fikir: Kablo Yok, Ama Seri Hat Var

Seri port haberleşmesi temelde baytların sırayla akmasıdır. Bir uç yazar, diğer uç okur. Gerçek dünyada bu iki ucu RS-232 kablosu bağlar; sanal dünyada ise işletim sistemi içinde oluşturulan bir port çifti bağlar. Linux’ta bunun için en pratik araçlardan biri socattır. Windows tarafında benzer fikir için com0com, macOS/Linux tarafında ise socat veya tty0tty kullanılabilir.

Seri haberleşmede sık duyulan 9600 8N1 ifadesi şunu anlatır: saniyede 9600 bit, 8 veri biti, parity yok, 1 stop biti. Aslında her karakter yalnızca 8 bit değildir; start ve stop bitleriyle birlikte yaklaşık 10 bit taşınır. Bu yüzden teorik karakter hızı yaklaşık $9600 / 10 = 960$ byte/s olur. Genel olarak $R_{byte} \approx \frac{baud}{start + data + parity + stop}$ diyebiliriz.

Sanal Port Çiftini Kurmak

Linux’ta iki uçlu sahte bir seri kabloyu şöyle oluşturabiliriz:

socat -d -d pty,raw,echo=0,link=/tmp/ttyV0 pty,raw,echo=0,link=/tmp/ttyV1

Bu komut /tmp/ttyV0 ve /tmp/ttyV1 adında iki sanal uç üretir. Birine yazılan veri diğerinden okunur. raw modu karakterleri pişirmeden geçirir, echo=0 ise yazdığımız karakterlerin aynı uçtan geri dönmesini engeller. Gerekirse ayarları klasik terminal aracıyla da sabitleyebiliriz:

stty -F /tmp/ttyV0 9600 cs8 -cstopb -parenb raw -echo
stty -F /tmp/ttyV1 9600 cs8 -cstopb -parenb raw -echo

Process 1: Komut Gönderen Terminal

Aşağıdaki Python betiği kendini eski bir terminal programı gibi davranmaya zorlar. ATZ, ATI ve ATD5551234 komutlarını sırayla yollar, gelen cevapları okur.

import serial
import time

port = serial.Serial('/tmp/ttyV0', 9600, timeout=1)

commands = [b'ATZ\r', b'ATI\r', b'ATD5551234\r']

for cmd in commands:
    print('Gonderiliyor:', cmd)
    port.write(cmd)
    time.sleep(0.2)
    response = port.read(128)
    print('Cevap:', response)

port.close()

Burada önemli nokta satır sonudur. Modemler genellikle komutun bittiğini carriage return, yani \r ile anlar. Modern metin dosyalarındaki \n alışkanlığı seri dünyada her zaman yeterli değildir.

Process 2: Modem Rolü Yapan Okuyucu

İkinci process diğer ucu dinler. Gelen komutu buffer’a alır, \r görünce işler ve uygun cevabı üretir.

import serial

modem = serial.Serial('/tmp/ttyV1', 9600, timeout=1)
buffer = b''

while True:
    b = modem.read(1)
    if not b:
        continue

    buffer += b
    if b == b'\r':
        command = buffer.strip().upper()
        print('Komut alindi:', command)

        if command == b'ATZ':
            modem.write(b'OK\r\n')
        elif command == b'ATI':
            modem.write(b'VIRTUAL MODEM 1.0\r\nOK\r\n')
        elif command.startswith(b'ATD'):
            modem.write(b'CONNECT 9600\r\n')
        else:
            modem.write(b'ERROR\r\n')

        buffer = b''

Bu küçük döngü aslında protokol tasarımının minyatür hâlidir: veri birikir, ayraç görülür, mesaj çözümlenir, cevap üretilir. TCP’de paketler, HTTP’de header’lar, MQTT’de frame’ler neyse; burada da \r odur.

Neden Bu Deney Değerli?

Çünkü süreçler arası haberleşmeyi sihir olmaktan çıkarır. Bir API çağrısı da özünde kuralları belirlenmiş bayt alışverişidir. Burada hız, çerçeveleme ve zaman aşımı açıkça görünür. Baud rate düşükse kuyruk dolar; timeout kısa ise cevap kaçırılır; satır sonu yanlışsa modem sonsuza kadar bekler.

Küçük bir nostalji projesi gibi görünse de bu yöntem gömülü sistem testlerinde, donanım olmadan firmware simülasyonunda ve eski cihaz protokollerini tersine mühendislikle anlamada çok işe yarar. Üstelik iki process’i konuştururken duyulmayan o modem cızırtısını zihniniz otomatik tamamlar: cııııııık, hrrr, bıp… CONNECT 9600!

Yılan oyununu modellemek için birkaç kavram yeterlidir. Yılanın gövdesi koordinat çiftlerinden oluşan bir listedir: [(x1,y1), (x2,y2), ...]. Her karede baş, mevcut yöne göre ilerler. Matematiksel olarak bunu şöyle düşünebiliriz: $p_{t+1}=p_t+v_t$. Burada $p$ konum, $v$ ise yöndür. Sağ için $(1,0)$, sol için $(-1,0)$, aşağı için $(0,1)$ kullanırız. Kenarlardan geçişli bir harita istersek yeni konumu mod ile hesaplarız: $x=(x+dx) \bmod W$.

Gerçek zamanlılık için klasik input() kullanamayız; çünkü Enter bekler. Python’da terminali “raw mode”a alarak tuşları anında okuyabiliriz. Aşağıdaki örnek, Linux/macOS terminallerinde çalışacak sade bir çekirdektir. Windows tarafında ANSI desteği yeni terminallerde vardır, fakat anlık tuş okuma için ek uyarlama gerekebilir.

import sys, time, random, select, tty, termios

W, H = 40, 20
ESC = '\x1b['

def move(x, y):
    return f'{ESC}{y};{x}H'

def color(c):
    return f'{ESC}{c}m'

def draw(snake, food, score):
    out = []
    out.append(move(1, 1) + color(36) + f'Skor: {score}' + color(0))
    out.append(move(food[0], food[1]) + color(31) + '●' + color(0))
    for i, (x, y) in enumerate(snake):
        ch = '◎' if i == 0 else '■'
        out.append(move(x, y) + color(32) + ch + color(0))
    sys.stdout.write(''.join(out))
    sys.stdout.flush()

def read_key():
    if select.select([sys.stdin], [], [], 0)[0]:
        return sys.stdin.read(1)
    return None

old = termios.tcgetattr(sys.stdin)
try:
    tty.setcbreak(sys.stdin)
    sys.stdout.write(ESC + '2J' + ESC + '?25l')

    snake = [(10, 10), (9, 10), (8, 10)]
    direction = (1, 0)
    food = (random.randint(2, W), random.randint(3, H))
    score = 0

    while True:
        key = read_key()
        if key == 'q': break
        if key == 'w' and direction != (0, 1): direction = (0, -1)
        if key == 's' and direction != (0, -1): direction = (0, 1)
        if key == 'a' and direction != (1, 0): direction = (-1, 0)
        if key == 'd' and direction != (-1, 0): direction = (1, 0)

        hx, hy = snake[0]
        dx, dy = direction
        head = ((hx + dx - 1) % W + 1, (hy + dy - 2) % (H - 1) + 2)

        if head in snake:
            break

        snake.insert(0, head)
        if head == food:
            score += 1
            food = (random.randint(2, W), random.randint(3, H))
        else:
            tail = snake.pop()
            sys.stdout.write(move(tail[0], tail[1]) + ' ')

        draw(snake, food, score)
        time.sleep(max(0.04, 0.12 - score * 0.003))
finally:
    termios.tcsetattr(sys.stdin, termios.TCSADRAIN, old)
    sys.stdout.write(ESC + '?25h' + ESC + '0m' + '\n')

Kodda önemli bir performans hilesi var: Her karede tüm ekranı temizlemek yerine sadece değişen hücreleri çiziyoruz. Kuyruğun eski konumuna boşluk basılıyor, yeni baş koordinatına sembol yazılıyor. Bu yaklaşım titremeyi azaltır. Eğer her karede \x1b[2J kullanırsan oyun çalışır ama göz kırpan bir disko topuna dönüşebilir.

Renk geçişleri için skora göre ANSI renkleri değiştirebilirsin. Örneğin düşük skorda yeşil, orta skorda sarı, yüksek skorda mor yılan kullanmak mümkündür. Hatta RGB destekleyen terminallerde \x1b[38;2;R;G;Bm biçimiyle gerçek renkler kullanılabilir. Böylece $renk=f(skor)$ gibi küçük bir fonksiyonla oyuna görsel ilerleme hissi katarsın.

Sonuç olarak terminalde yılan oyunu yapmak, oyun programlamanın minyatür laboratuvarı gibidir: koordinat sistemi, olay okuma, zamanlama, çarpışma kontrolü ve render mantığı tek dosyada buluşur. Üstelik tüm bunları grafik kütüphanesi olmadan, yalnızca metin ve birkaç kaçış koduyla yapmak oldukça tatmin edici. Bir sonraki adım olarak duvarlar, seviye sistemi veya renkli parçacık efektleri ekleyebilirsin; terminal sandığından daha canlı bir sahne!

Bu proje için Alpine Linux güzel bir adaydır; çünkü küçüktür, hızlı kurulur ve minimal sistemlere yakışır. Fakat mantık Debian debootstrap, BusyBox veya kendi initramfs’inizle de aynıdır: çekirdek başlar, initramfs devreye girer, RAM’de bir kök dosya sistemi hazırlanır ve sistem switch_root ile oraya geçer.

İlk adımda mevcut çalışan bir Linux üzerinde RAM kök alanı oluşturalım. Bu aşama sistemi gerçekten boot ettirmez; sadece rootfs hazırlama laboratuvarıdır:

sudo mkdir -p /mnt/ramroot
sudo mount -t tmpfs -o size=2G,mode=0755 tmpfs /mnt/ramroot

Burada size=2G, tmpfs’in üst sınırıdır. Bu, RAM’in anında 2 GB’ının dolduğu anlamına gelmez; tmpfs kullandıkça büyür. Şimdi Alpine mini rootfs arşivini indirip buraya açabiliriz:

cd /mnt/ramroot
sudo wget https://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86_64/alpine-minirootfs-latest-x86_64.tar.gz
sudo tar xzf alpine-minirootfs-latest-x86_64.tar.gz
sudo rm alpine-minirootfs-latest-x86_64.tar.gz

Bu noktada /mnt/ramroot içinde küçük ama gerçek bir Linux kullanıcı alanı vardır. DNS, proc, sys ve dev bağlamalarını ekleyip içine chroot ile girebiliriz:

sudo mount -t proc proc /mnt/ramroot/proc
sudo mount --rbind /sys /mnt/ramroot/sys
sudo mount --rbind /dev /mnt/ramroot/dev
sudo cp /etc/resolv.conf /mnt/ramroot/etc/resolv.conf
sudo chroot /mnt/ramroot /bin/sh

Chroot içindeyken temel paketleri ekleyebiliriz. Ama unutmayın: şu an RAM’e yazıyoruz. Kapanınca her şey puf!

apk update
apk add busybox-openrc openssh vim curl
passwd

Asıl sihir boot tarafındadır. Bilgisayar açılırken diskten sadece çekirdek ve initramfs okunur. initramfs içindeki küçük init betiği tmpfs’i bağlar, sıkıştırılmış rootfs’i RAM’e açar ve kontrolü oraya devreder. Basitleştirilmiş akış şöyledir:

Örnek bir init mantığı şu şekildedir:

#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sys /sys
mount -t devtmpfs dev /dev
mkdir /newroot
mount -t tmpfs -o size=2G tmpfs /newroot
tar -xzf /rootfs.tar.gz -C /newroot
exec switch_root /newroot /sbin/init

Burada /rootfs.tar.gz, initramfs içine gömülmüş minimal sistem arşividir. Daha üretilebilir bir yapı için rootfs’i SquashFS olarak saklayıp açılışta tmpfs’e kopyalayabilirsiniz. SquashFS daha az yer kaplar; tar.gz ise basitliğiyle kazanır.

Bu mimarinin en güzel yanı güvenlik ve tekrarlanabilirliktir. Bir eğitim laboratuvarında öğrenciler sistemi bozabilir, zararlı yazılım bulaşabilir veya konfigürasyon darmadağın olabilir. Yeniden başlatınca her şey başlangıç haline döner. Dezavantajı ise doğal olarak kalıcılığın olmamasıdır. Log, ayar veya dosya saklamak istiyorsanız ayrı bir kalıcı bölüm bağlamanız gerekir.

Sonuç olarak tmpfs tabanlı RAM Linux; çekirdek, initramfs ve minimal rootfs üçlüsünün dansıdır. Disk sadece kıvılcımı çakar, asıl parti RAM’de döner. Doğru boyutlandırma, küçük dağıtım seçimi ve sade init betiğiyle açılışta doğan, kapanışta hafızalardan silinen sevimli bir işletim sistemi elde edebilirsiniz.

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.