DDC/CI ile monitör ayarlarının analog kontrolü bölüm 2.

Bir önceki yazıda Arduino Uno ve Python kullanarak DDC/CI protokolü üzerinden monitör parlaklık ve kontrast kontrolünü iki potansiyometreyle nasıl yapabileceğimizi anlatmıştım. O yazının sonunda birkaç yapılacak madde listelemiştim. Bu yazı o listedeki en kritik iki maddenin hayata geçirilmesini anlatıyor: Arduino'dan bağımsız bir MCU'ya geçiş ve uygulamanın Win32 ile yeniden yazılması.

Neden Arduino değil?

Arduino Uno güzel bir prototipleme platformu, ancak bu proje için fazla büyük ve gereksiz. Bizim ihtiyacımız olan tek şey iki ADC kanalı ve USB iletişimi. Bunun için 28 pinli bir AVR ve ayrı bir USB-Serial çevirici çipi kullanmak israf.

Daha da önemlisi, Arduino Uno USB üzerinden HID olarak görünmüyor — seri port (CDC) üzerinden haberleşiyor. Bu da Python tarafında pyserial kütüphanesi ve COM port yönetimi gerektiriyor. Farklı bilgisayarlarda farklı COM port numaraları atanıyor, kullanıcı bunu elle değiştirmek zorunda kalıyor.

Hedef: cihazı taktığında ek bir kurulum veya konfigürasyon gerektirmeden çalışan, native USB HID olarak görünen, mümkün olduğunca küçük bir devre.

CH552: USB HID yetenekli minimal MCU

WCH firmasının ürettiği CH552, bu iş için biçilmiş kaftan. Enhanced 8051 çekirdeği üzerine kurulu bu MCU'nun öne çıkan özellikleri:

• Dahili USB full-speed transceiver — harici USB-Serial çeviriciye gerek yok
• 4 kanallı 8-bit ADC (P1.1, P1.4, P1.5, P3.2)
• 16KB program ROM, 1KB xRAM
• DIP20 pakette mevcut — breadboard dostu
• Adet fiyatı 0.5-1 dolar civarı
• ch55xduino ile Arduino IDE desteği

Geliştirme için WeAct Studio'nun CH552 Core Board'unu kullandım. USB konektörü, boot ve reset butonu dahil, breadboard uyumlu, tüm pinler erişilebilir.

Bağlantı şeması

Devre son derece sade:

• POT1 (Parlaklık): Orta bacak → P1.1, uçlar → GND / 3.3V
• POT2 (Kontrast): Orta bacak → P1.4, uçlar → GND / 3.3V
• Her iki pot için 10kΩ değer ideal
• USB, hem güç hem veri için kullanılıyor

USB HID descriptor: Vendor HID

Önceki Arduino versiyonunda CDC (seri port) kullanıyorduk. Bu versiyonda cihaz native USB HID olarak görünüyor. Ancak burada önemli bir detay var: standart keyboard veya mouse descriptor kullanırsak Windows cihazı gerçek bir giriş aygıtı olarak tanımlıyor ve klavye girişlerini karıştırabiliyor.

Bunun yerine Vendor Defined HID (Usage Page 0xFF00) kullandım. Bu şekilde Windows cihazı tanıyor ama sistem giriş aygıtı olarak muamele etmiyor. Device Manager'da "HID-compliant device" olarak görünüyor, herhangi bir sürücü kurulumu gerekmiyor.

CH552 ADC: Dikkat edilmesi gereken detaylar

CH552'nin ADC'sini kullanırken birkaç önemli nokta var. Standart Arduino analogRead() fonksiyonu çalışıyor, ancak kanal seçimi biraz farklı. ch55xduino'da pin numaralandırması port.pin formatında: P1.1 için pin 11, P1.4 için pin 14.

Öte yandan ADC çıkışı 8-bit olmasına rağmen dahili referans voltajı nedeniyle değerler 0-255 aralığının tamamını kullanmıyor. Pratikte 4-174 arası bir aralık elde ettim. Python tarafında bu değerleri 0-100 aralığına map ediyorum:

ADC_MIN = 4
ADC_MAX = 174

def map_val(raw):
    val = (ADC_MAX - raw) * 100 // (ADC_MAX - ADC_MIN)
    return max(0, min(100, val))

Firmware: HID veri gönderimi

USB HID üzerinden veri göndermek için ch55xduino'nun HID keyboard örneğinin kaynak dosyalarını kullandım. Descriptor'ı Vendor HID olarak değiştirdim, veri gönderimi için mevcut USB_EP1_send() fonksiyonunu ve HIDKey[] buffer'ını kullandım.

Her HID paketi şu şekilde:

• HIDKey[0] — Parlaklık (ADC P1.1)
• HIDKey[1] — Kontrast (ADC P1.4)

Firmware ana döngüsü 50ms aralıklarla çalışıyor:

void loop() {
    uint8_t b = adc_read_ch(0);  // P1.1
    uint8_t c = adc_read_ch(1);  // P1.4

    HIDKey[0] = b;
    HIDKey[1] = c;
    USB_EP1_send();
    delay(50);
}

Cihazı flash'lamak için WCHISPTool kullandım. Boot moduna girmek için P3.6 butonuna basılı tutarken USB bağlamak yeterli.

Cold boot sonrası sorunu ve çözümü

Projeyi tamamladıktan sonra kritik bir bug fark ettim: devre Windows yeniden başlatıldıktan sonra resetlemeden çalışmıyordu. Sök-tak veya board reset sonrası her şey normal çalışıyordu, ancak bilgisayar kapatılmadan yeniden başlatıldığında potansiyometreler tepki vermiyordu.

Başlangıçta USB enumerate sorunu olduğunu düşündüm. Device Manager'da cihaz görünüyordu, hid.enumerate() ile descriptor bilgileri okunabiliyordu. Sorun farklı bir yerdeydi.

Kök neden UpPoint1_Busy flag'inin stuck kalmasıydı. Windows başlatma sırasında USB host controller enumerate sürecinde bir veya birden fazla USB bus reset sinyali gönderiyor. Eğer CH552 o anda EP1 üzerinden veri gönderiyorsa transfer yarıda kesiliyor; ancak USB_EP1_IN() callback'i tetiklenmediği için UpPoint1_Busy flag'i 1 olarak kalıyor. Bundan sonra USB_EP1_send() her çağrıda sessizce return 0 dönüyor — cihaz çalışır görünüyor ama hiç HID raporu göndermiyor. Kullanıcı CH552'yi fiziksel olarak resetleyince MCU yeniden başlar, flag sıfırlanır ve çalışır.

Çözüm USBhandler.c'deki UIF_BUS_RST interrupt handler'ına üç satır eklemekten ibaretti:

// USBhandler.c - UIF_BUS_RST handler
extern volatile __xdata uint8_t UpPoint1_Busy;

// ... handler içinde:
UsbConfig = 0;
UpPoint1_Busy = 0;  // Bus reset gelince stuck flag'i temizle

Bus reset geldiğinde UpPoint1_Busy sıfırlanıyor, bir sonraki USB_EP1_send() çağrısında transfer yeniden başlıyor. Windows'un başlatma sırasında gönderdiği bus reset sinyali artık sorunu çözmek için kullanılıyor. Soğuk açılışta artık resetlemeye gerek kalmadı.

Python daemon: Win32 ve dxva2

Önceki versiyonda Python GUI için tkinter, DDC/CI için monitorcontrol kütüphanesi kullanıyordum. Bu versiyonda her ikisini de değiştirdim.

OSD: tkinter yerine doğrudan Win32 GDI ile layered window. Transparan arka plan, her zaman üstte, tıklanamaz. Sağ alt köşede 2 saniye görünüp kayboluyor.

DDC/CI: monitorcontrol kütüphanesi yerine Windows'un native dxva2.dll API'si. SetMonitorBrightness ve SetMonitorContrast fonksiyonları doğrudan çağrılıyor. Bu yöntem hem daha hızlı hem de monitorcontrol kütüphanesinin yaşadığı "failed to get VCP feature" hatasını tamamen ortadan kaldırıyor.

dxva2 = ctypes.windll.dxva2

def _ddc_worker():
    while True:
        brightness, contrast = _ddc_queue.get()
        for h in _monitor_handles:
            if brightness is not None:
                dxva2.SetMonitorBrightness(h, brightness)
            if contrast is not None:
                time.sleep(0.05)
                dxva2.SetMonitorContrast(h, contrast)

DDC/CI komutları bir queue üzerinden tek bir worker thread'e gönderiliyor. Queue kapasitesi 1 — yeni komut geldiğinde işlenmemiş eski komut atılıyor. Bu sayede monitör hiçbir zaman komut yağmuruna tutulmuyor.

Sonuç

Arduino versiyonuyla karşılaştırıldığında bu versiyon birçok açıdan daha iyi:

• COM port konfigürasyonu yok — USB tak, çalış
• Ayrı USB-Serial çevirici yok — tek çip, tek USB kablo
• OSD daha responsive ve görsel olarak daha temiz
• DDC/CI iletişimi daha stabil
• Soğuk açılışta resetleme gerekmiyor
• Devre boyutu ve maliyeti önemli ölçüde düştü

Yapılacaklar listesinde hala birkaç madde var: ADC gürültüsü için firmware tarafında smoothing buffer, Python daemon yerine standalone exe, ve nihai hedef olarak özel PCB tasarımı. Önümüzdeki yazılarda bunları ele alacağım.

Projenin kaynak kodlarına GitHub üzerinden ulaşabilirsiniz.

E=mc² ve Maddenin Gerçek Yüzü

Little Boy ve 0,7 Gram

1945'te Hiroşima'ya atılan Little Boy bombası yaklaşık 64 kg U-235 içeriyordu. Ama bunun sadece yaklaşık 1 kg'ı gerçekten fisyona girdi. Daha da çarpıcısı, bu reaksiyona giren kısmın da sadece yaklaşık 0,7 gramı saf enerjiye dönüştü.

Bunu sayıya dökersen:

\[ E = 0{,}0007 \times c^2 \approx 6 \times 10^{13} \text{ joule} \]

Bu da yaklaşık 15 kiloton TNT demek.

Yani koca 64 kg'lık sistemde:

• %98'i reaksiyona bile girmiyor
• Reaksiyona girenin de %99,9'u hâlâ "madde" olarak kalıyor

Ve yine de: bir şehir yok oluyor.

Bu tek başına şu cümleyi gerçek yapıyor: Madde inanılmaz yoğun bir enerji deposudur. Ama aynı zamanda şunu da gösteriyor: nükleer silahlar bile aslında çok verimsiz.

Kütle mi, Ağırlık mı?

Fiziği ilk öğrenirken dünya bize çok basit görünür. Cisimler vardır, ağırlıkları vardır, hareket ederler. Momentum da sanki "ağırlık çarpı hız" gibi bir şeydir. Ama işin içine girince ilk çatlak burada oluşur. Çünkü momentum aslında şöyle tanımlanır:

\[ p = mv \]

Burada \(m\) kütledir, ağırlık değil. Ağırlık ise tamamen farklı bir şeydir:

\[ W = mg \]

Biri cismin kendisiyle ilgili, diğeri bulunduğu ortamla. Dünya'da 80 kg olan biri Ay'da hâlâ 80 kg'dır ama ağırlığı ciddi şekilde düşer. Bu küçük ayrım aslında büyük bir kapıyı açar: ölçtüğümüz şey ile gerçek fiziksel büyüklük aynı şey olmayabilir.

Fiziğin Kalbi

Momentumun bu basit hali Newton dünyasında çalışır, ama biraz derine inince bunun sadece özel bir durum olduğunu fark ediyorsun. Daha genel çerçevede enerji ve momentum birlikte hareket eder:

\[ E^2 = (pc)^2 + (mc^2)^2 \]

Parçacık duruyorsa (\(p = 0\)), buradan direkt şu çıkar:

\[ E = mc^2 \]

Yani bir cismin sadece var olması bile enerji demektir. Ama daha da ilginci, kütle sıfırsa (\(m = 0\)) denklem şu hale gelir:

\[ E = pc \quad \Rightarrow \quad p = \frac{E}{c} \]

İşte ışığın sırrı burada. Kütlesi yoktur ama enerjisi vardır, dolayısıyla momentumu da vardır. "Momentumu taşıyan şey kütle değil, enerjidir" fikri ilk kez gerçekten anlam kazanır.

Einstein'ın Sıçraması

Bir cisim düşün, iki yana eşit ışık yayıyor. Kendi referansında hareket etmiyor, her şey dengede. Ama başka bir gözlemciye göre bu ışıkların enerjisi eşit değildir (Doppler etkisi). Momentum dengesi bozulur gibi görünür. Bu çelişkiyi çözmenin tek yolu şudur: cisim enerji kaybettiyse kütle de kaybetmelidir.

\[ \Delta m = \frac{E}{c^2} \]

Bu noktada "madde = enerji" artık slogan değil, zorunluluk haline gelir.

Parçacık Yok, Alan Var

"Madde enerjidir" dediğinde insan şunu sorar: peki bu somut şeyler nereden geliyor? Proton, nötron, elektron? Burada modern fizik sahneye çıkar ve der ki: evrende parçacık diye bir şey yoktur, aslında her şey alanların titreşimidir. Elektron bir elektron alanının, foton elektromanyetik alanın titreşimidir.

Proton ise daha karmaşık: quark ve gluon alanlarının birleşik bir enerji konfigürasyonu. Ve protonun kütlesinin büyük bölümü quarklardan gelmez. Asıl kaynak, onları bağlayan güçlü etkileşimin enerjisidir. Bu yüzden bir çekirdeğin toplam kütlesi, içindeki parçacıkların toplamından daha küçüktür. Aradaki fark:

\[ E_{\text{bağ}} = \Delta m \cdot c^2 \]

Fisyon ve füzyon tam olarak bu farktan enerji üretir. Little Boy'un "verimsizliği" de burada anlam kazanır: sistem çok daha büyük bir enerji rezervine sahipken onun sadece çok küçük bir kısmını kullanabilmiştir. Eğer teorik olarak 1 kg madde tamamen enerjiye dönüşseydi:

\[ E = 1 \times c^2 \approx 9 \times 10^{16} \text{ joule} \]

Bu, yaklaşık 21 megaton TNT ederdi. Hiroşima'daki patlamanın binlerce katı.

Işığı Tartabilir misin?

Bu noktada "katı madde" fikri tamamen çözülmeye başlar. Katılık, sadece atomlar arası elektromanyetik kuvvetlerin makroskopik etkisidir. Temel seviyede her şey enerji ve alan organizasyonudur. Bu yüzden ışık gibi tamamen kütlesiz bir şey bile mekanik etki yaratabilir — çünkü momentum taşıyordur.

Ama asıl zihin açan nokta şu: ışığı tek başına tartamazsın çünkü durduramazsın. Kütle dediğimiz şey aslında bir sistemin "durgun haldeki enerjisi" ile tanımlıdır. Foton için böyle bir durum yoktur, hep \(c\) ile gider. Ama ışığı bir kutunun içine hapsedersen, sistemin toplam momentumu sıfır olur ve artık bir "durgun sistem" elde edersin. O zaman sistemin kütlesi:

\[ m = \frac{E_{\text{toplam}}}{c^2} \]

kadar artar. Yani bir kutunun içine ışık koyarsan gerçekten daha ağır olur. Bir cismi ısıtırsan, içine enerji koyduğun için kütlesi artar. Fark çok küçüktür ama prensip kesindir.

Yerçekimi ve Eğri Uzay

Son adımda yerçekimine baktığında yine aynı hikâyeyi görürsün. Newton'a göre yerçekimi bir kuvvettir ve kütleleri çeker. Ama Einstein'a göre kütle ve enerji uzay-zamanı büker. Işık da bu eğri geometri içinde hareket eder. Bu yüzden bükülür — "çekildiği" için değil, bulunduğu uzay eğri olduğu için yolunu değiştirir.

---

Bütün bu hikâyeyi tek bir cümleyle özetlemek mümkün: evren, katı nesnelerden oluşan bir yer değil; enerji ve alanların belirli kurallara göre organize olmuş halidir. Kütle, momentum, bağ enerjisi ve yerçekimi, bu organizasyonun farklı yüzleridir.

Ve en güzel tarafı şu: bu hikâyeyi gerçekten anlamaya başladığın anlar hep aynı şekilde geliyor — "oha" 😄

Steelseries Engine 3 ve Rival 100 not connected problemi.

Rival 100 mouse kullanıyorum. Bazen soldaki B4-B5 tuşlarına atadığım ses kontrolü çalışmıyor.

SteelSeries Engine 3'ü açıp bakınca Rival 100'ün yanında Not Connected yazıyor.

Mouse takılı ve çalışıyor, ama Steelseries Engine 3 yazılımı mouse'u görmüyor.

SteelSeries Engine 3, mouse'u tanıyamazsa tüm özel atamalar devre dışı kalıyor. Volume up, volume down, ben sadece bu tuşları kullandığım bunlar gidiyor, muhtemelen diğer atamalar da gidiyordur, denemedim. Çözüm için USB'yi çıkarıp takıyorum ya da bilgisayarı yeniden başlatıyorum, sorun geçici olarak düzeliyor. Ama bu her seferinde yapılacak bir şey değil. Zaten sonra rastgele bir restartta tekrar ediyor.

Rival 100, Windows'a USB Composite Device olarak bağlanıyor. Yani tek bir fiziksel cihaz, Windows'a birden fazla giriş olarak görünüyor. Bunların hepsinin düzgün başlatılması gerekiyor.

Bazen sistem açılışında bu başlatma süreci aksıyor. Mouse fiziksel olarak çalışıyor ama Engine 3 cihazı recognize edememiş oluyor.

Device Manager'da driver uninstall/reinstall yapmak işe yaramıyor.

Yazılımsal çözüm: USBDeview

Fiziksel olarak USB'yi çıkarıp takmanın tam yazılım karşılığı NirSoft'un ücretsiz aracı USBDeview.

İndirme linki: nirsoft.net/utils/usb_devices_view.html

Kurulum yok, portable .exe.

1. USBDeview yönetici olarak çalıştırılır. (Sağ tık → Run as Administrator)
2. Listede SteelSeries Rival 100 için üç satır var: USB Composite Device olanı resetlenecek.
3. Üzerine sağ tıklayıp, Disable+Enable seçilir.
4. Engine 3 kapatıp açılır.

Mouse connected görünüyor, atamalar geri geliyor.

Neden Composite Device? Çünkü diğer iki girişin (HID ve USB Input Device) ebeveyni o. Onu sıfırlayınca altındaki her şey yeniden başlatılıyor. Tek tek uğraşmaya gerek yok.

Kalıcı çözüm: USB güç tasarrufunu kapatmak

USBDeview sorunu çözüyor. Ama sorun tekrar yaşanıyor. 

Sebep büyük ihtimalle Windows'un USB güç tasarrufu özelliği. Bu seçenek belirli koşullarda USB cihazlarını uyutabiliyor. Mouse fiziksel olarak çalışmaya devam ediyor ama Engine 3 bağlantıyı kaybediyor.

Kapatmak için:

1. Denetim Masası → Güç Seçenekleri
2. Aktif planın yanındaki Plan ayarlarını değiştir
3. Gelişmiş güç ayarlarını değiştir
4. USB ayarları → USB seçici askıya alma ayarı → Devre dışı

Şimdilik bu kadar. Sorunun tekrarlanıp tekrarlamadığını birkaç gün izleyeceğim.

---

Açık Kaynağın Karanlık Yüzü: Dependency Hell ve Güvenlik Kabusu

"Sadece npm install yap"

Bir uygulama geliştirmeye karar verdiniz. Modern, açık kaynak araçlar kullanacaksınız. Ücretsiz, özgür, topluluk destekli. Harika.

İlk komutunuzu yazıyorsunuz:

npm install

Ve başlıyor. Ekran dolup taşıyor. Yüzlerce paket, onlarca uyarı, birkaç hata. Beş dakika sonra hâlâ kurulum yapıyor. On dakika sonra bir şeyler ters gidiyor.

Hoş geldiniz. Dependency hell'e düştünüz.

Bu nasıl bir yer?

Bir Node.js projesi açın, node_modules klasörüne bakın. Siz 5 paket istediniz. Ama orada 1.500, belki 2.000 paket vardır. Geri kalanı ne?

Onların bağımlılıkları. Onların bağımlılıklarının bağımlılıkları. Onların bağımlılıklarının bağımlılıklarının bağımlılıkları.

Bir paket "A" ister, A paketi "B v2.x" ister, başka bir paket "B v3.x" ister, ikisi uyuşmaz, Metro bundler çöker, ekran kırmızıya döner. Günün geri kalanı bu hatayla geçer.

npm ekosisteminde 2 milyondan fazla paket var. Bu sayı her gün büyüyor. Hiçbir merkezi denetim mekanizması yok. Herkes her şeyi yayınlayabiliyor.

left-pad: İnternetin 11 Satıra Bağlı Olduğu Gün

2016 yılında Azer Koçulu isminde bir geliştirici, npm'deki "left-pad" adlı paketini sildi. Bir hukuki anlaşmazlık yüzünden kızmıştı, paketi çekti.

left-pad ne yapıyordu? Bir string'in soluna boşluk ekliyordu. 11 satır kod.

Sonuç: React çöktü. Babel çöktü. Binlerce proje build edilemez hale geldi. Dünyanın dört bir yanında CI/CD pipeline'ları durdu. Şirketler saatler içinde milyonlarca dolar kaybetti.

İnternetin önemli bir kısmı, tek bir insanın sinirli bir öğleden sonrasına bağlıydı.

event-stream: Hacker'ın Hediyelik Paketi

2018'de daha da ürkütücü bir şey yaşandı.

"event-stream" popüler bir npm paketiydi. Geliştirici paketi artık aktif olarak sürdürmediğini, devretmek istediğini açıkladı. "right9ctrl" isimli biri gönüllü oldu ve paketi devraldı.

Haftalarca kimse fark etmedi. Ta ki bir araştırmacı, paketin içine gizlenmiş kod parçasını bulana kadar.

O kod ne yapıyordu? Kullanıcıların kripto para cüzdanlarını arıyor, özel anahtarları çalıyordu. Hedef spesifikti: Copay isimli bir Bitcoin cüzdan uygulaması.

Paket bu sürede milyonlarca kez indirilmişti.

Peki kim fark etti? Bir GitHub kullanıcısı. Gönüllü, ücretsiz çalışan biri.

Kim Denetliyor?

Kısa cevap: Kimse.

npm'in otomatik tarama sistemleri var. Bilinen zararlı yazılım imzalarını arıyor. Ama sıfırıncı gün saldırıları için, özellikle hazırlanmış hedefli kötü kod için bu taramalar kör.

Büyük şirketler kendi çözümlerini üretmiş durumda. Google, Meta, Microsoft kritik paketleri fork edip kendi güvenlik ekiplerinden geçiriyor. Ama bu lüks her şirkete nasip olmuyor.

Snyk, Dependabot, Socket gibi araçlar bilinen açıkları takip ediyor. CVE veritabanlarıyla karşılaştırıyor. Faydalılar, ama reaktifler: açık önce bulunuyor, sonra işaretleniyor, sonra siz güncelliyorsunuz. Bu arada ne kadar süre geçiyor?

Açık Kaynak'ın Trajedisi

Burada bir paradoks var.

Açık kaynak, yazılım dünyasını demokratikleştirdi. Bir öğrenci, dünyaca kullanılan bir kütüphane yazabiliyor. Küçük şirketler, enterprise araçları ücretsiz kullanabiliyor. Bilgi paylaşılıyor, ilerleme hızlanıyor.

Ama bu ekosistem, gönüllü emeği üzerine kurulu. Ve gönüllü emek tükeniyor.

"left-pad" geliştiricisi yoruldu, bıraktı. "event-stream" geliştiricisi yoruldu, devretti. Her gün onlarca kritik paket, hayatının farklı bir dönemine geçmiş, artık ilgilenemeyen biri tarafından "sürdürülüyor."

Siz o paketi kullanıyorsunuz. Onun bağımlılığının bağımlılığı olarak. Habersizce.

Microsoft'un Kapalı Dünyası mı Daha İyiydi?

Nostalji tehlikeli. Eski Microsoft dünyasının da bedelleri vardı.

Her şey Windows'a kilitliydi. Lisanslar pahalıydı. Topluluk katkısı neredeyse sıfırdı. "Linux bir kanser" diyen bir şirketten bahsediyoruz. Yenilik yavaştı, her şey Microsoft'un roadmap'ine bağlıydı.

O dünya güvenliydi çünkü dardı. Bugünkü dünya özgür ama kaotik.

İkisi arasında sağlıklı bir denge henüz bulunamadı.

Ne Yapmalı?

Bağımlılıklarınızı tanıyın. npm ls ile dependency tree'ye bakın. Her paketin ne yaptığını en azından kabaca bilin.

Sürümleri kilitleyin. package-lock.json'u commit edin. ^ ve ~ versiyonlarına dikkat edin, her npm install'da farklı bir şey kurulabilir.

Güvenlik taraması yapın. npm audit çalıştırın. Snyk veya Dependabot entegre edin. Mükemmel değil ama hiç yoktan iyi.

Az bağımlılık, daha az risk. Her şey için paket kurmak yerine zaman zaman kendiniz yazın. 11 satırlık bir şey için left-pad kurmayın.

Büyük, aktif topluluğa sahip paketleri tercih edin. Son commit tarihi 4 yıl önceyse, o paket için iki kez düşünün.

Son Söz

Bugün bir uygulama kurarken Node versiyonu uyumsuzluğu, Expo SDK çakışması, TurboModule hatası, babel-preset eksikliği derken saatler harcadım.

Şikâyet etmek kolay. Ama şunu da söylemek lazım: bu kaotik, güvensiz, yorucu ekosistemi gönüllüler inşa etti. Ücretsiz. Bazen gecenin üçünde. Karşılıksız.

Belki de asıl sorun, milyar dolarlık şirketlerin bu gönüllü emeğin üzerine ticari ürünler inşa etmesi ve o emekçilere yeterince geri vermemesi.

Ama bu başka bir yazının konusu.

---

Bu yazıyı bir React Native uygulaması kurulum hatasının 15. dakikasında yazmaya karar verdim. Uygulama 1.5 saatte çalıştı.

Calibro'dan satın aldığım kitabı okumak için verdiğim uğraş.

Geçen hafta Calibro'dan Cynthia Stokes Brown'ın Büyük Tarih: Büyük Patlamadan Bugüne adlı kitabını e-kitap formatında satın aldım, indirdim, açmaya çalıştım — ve işte o zaman eğlence başladı.

Kitap açılmıyordu. Daha doğrusu, sadece Calibro'nun kendi uygulamasında açılıyordu. Bu uygulamayı telefona kurmayı denedim, Android telefonumda uygulama güncel değil gibi bir hata verdi ve çalışmadı. Bilgisayarda okumayı denedim, olmadı. Satın aldığım bir şeyi okuyamıyordum.

Calibro'ya mail attım. Tweet attım. Yanıt vermediler.

O gece bir karar verdim: Bu kitabı okuyacaktım.

---

DRM Nedir?

DRM (Digital Rights Management), dijital içerikleri korumak için kullanılan şifreleme sistemidir. Teoride mantıklıdır: İçerik üreticilerinin haklarını korur. Pratikte ise satın aldığın bir şeyi kullanamamana neden olur.

Calibro, PocketBook'un PBDRM sistemini kullanıyor. Kitap .lndrm uzantılı bir dosya olarak geliyor. İçini hex editörle açınca şunu gördüm:

50 42 44 52 4D ...  →  "PBDRM" magic bytes

Adobe ADEPT altyapısı üzerine kurulu, RSA + AES-128-CBC şifreleme kullanıyor. Yani:

1. Kitabın içeriği AES-128-CBC ile şifrelenmiş
2. AES anahtarı RSA ile şifrelenmiş
3. RSA şifrelemek için Calibro'nun sunucu tarafındaki public key kullanılmış
4. Çözmek için Calibro'nun elindeki private key gerekiyor

---

İlk Hamle: Adobe Digital Editions

İlk denediğim şey Adobe Digital Editions (ADE) ve DeDRM plugin'iydi. Bu ikili çoğu e-kitap DRM'ini kaldırabiliyor. Ama ADE denemeye başlamadan önce şöyle bir hata verdi:

E_ADEPT_NO_TOKEN

Bu hata, ADE'nin Adobe'nin lisans sunucusundan (adeactivate.adobe.com) token alamaması anlamına geliyor. Çözüm denemeleri:

• ADE'yi deauthorize edip yeniden authorize etmek
• VPN'i kapatmak
• Hosts dosyasında Adobe sunucularının bloklanıp bloklanmadığını kontrol etmek (/etc/hosts veya C:\Windows\System32\drivers\etc\hosts)
• ADE'yi güncellemek

Hiçbiri işe yaramadı. Üstelik DeDRM plugin, PBDRM formatını zaten tanımıyordu — bu Adobe'nin standart ADEPT formatı değil, PocketBook'un özel bir implementasyonu.

---

Memu Emülatörü

Calibro Reader yalnızca Android'de çalışıyor ve güncel telefonlarda çalışmıyor. Çözüm: Memu — Windows'ta Android uygulamaları çalıştıran bir emülatör.

Memu → Android x86_64 emülatör
Calibro Reader APK → ARM binary

Uygulama kuruldu ve kitap açıldı. Bu aşamada kitabı sadece Memu altında okuyabilecektim, aradığım çözüm bu değildi elbette.

---

PBDRM Header Analizi

Kitap dosyasını Python ile incelemeye başladım:

data = open('kitap.lndrm', 'rb').read()
print(data[:32].hex())
# 5042 4452 4d00 0100 a896 3191 69d0 5969...
# P B D R M

Header yapısı:

Offset	Uzunluk	İçerik
0x00	5 byte	PBDRM magic
0x05	2 byte	0x0001 type
0x07	2 byte	0x00a8 = 168 (şifreli anahtar uzunluğu)
0x09	168 byte	RSA ile şifreli AES anahtarı
0x120	16 byte	IV (initialization vector)
0x130	~	AES ile şifreli içerik

168 byte ilginçti — RSA-1024 için 128 byte olması gerekir. Fazladan 40 byte'ta ne var? Bunun üzerinde saatlerce çalıştım: IV mi, salt mı, başka bir şey mi?

---

activation.xml

Uygulamanın data dizininde kritik dosyalar vardı:

adb shell "ls /data/data/com.calibro.reader/app_resources/"
# activation.xml
# device.xml

activation.xml Adobe ADEPT formatındaydı. İçinde iki önemli şey:

1. privateLicenseKey: RSA-1024 private key (base64 encoded)
2. pkcs12: Şifreli PKCS12 sertifikası

import base64, xml.etree.ElementTree as ET
from Crypto.PublicKey import RSA

tree = ET.parse('activation.xml')
pk_b64 = tree.find('.//{http://ns.adobe.com/adept}privateLicenseKey').text
pk_der = base64.b64decode(pk_b64)
rsa_key = RSA.import_key(pk_der)
print(f"Key boyutu: {rsa_key.size_in_bytes()} bytes")  # 128

privateLicenseKey ile .lndrm dosyasındaki 168 byte'lık bloğu çözmeye çalıştım. 168 byte içinde 128 byte'lık RSA bloğunun hangi offset'te olduğunu bulmak için brute force:

from Crypto.Cipher import PKCS1_v1_5

full_block = data[0x09:0x09+168]

for offset in range(0, 41):
    rsa_block = full_block[offset:offset+128]
    cipher = PKCS1_v1_5.new(rsa_key)
    result = cipher.decrypt(rsa_block, b'\xff' * 32)
    if result != b'\xff' * 32:
        print(f"[+] offset={offset}: {result.hex()}")

Hiçbir offset'te başarılı decrypt elde edemedim. Neden? Çünkü privateLicenseKey kullanıcı kimlik doğrulama anahtarıydı — kitap şifreleme anahtarı değildi. Gerçek şifre çözme anahtarı Calibro'nun sunucusundaydı.

PKCS12 sertifikasının şifresini kırmayı denedim — cihazın fingerprint'i, device ID, salt gibi değerleri şifre olarak denedim. Hepsi başarısız oldu.

---

Frida ile Hook Denemesi

Eğer anahtarı statik analiz ile bulamıyorsam, uygulama çalışırken dinamik olarak yakalamayı deneyebilirdim. Frida bunun için ideal araç — çalışan bir process'e JavaScript kodu enjekte etmeyi sağlıyor.

Plan: libpb_reader.so veya libadobe_rmsdk.so içindeki AES/RSA fonksiyonlarını hook'layıp şifre çözme anında anahtarı yakalamak.

Java.perform(function() {
    var EVP_DecryptInit_ex = Module.findExportByName(
        "libpb_reader.so",
        "EVP_DecryptInit_ex"
    );
    Interceptor.attach(EVP_DecryptInit_ex, {
        onEnter: function(args) {
            var key = args[3].readByteArray(16);
            console.log("[+] AES KEY: " + bytesToHex(key));
        }
    });
});

Ama Frida modülleri listelerken libpb_reader.so ve libadobe_rmsdk.so hiç görünmüyordu. Neden? Houdini.

Houdini Nedir?

Memu x86_64 tabanlı bir emülatör. Calibro Reader ise ARM binary. Intel'in Houdini katmanı ARM kodunu gerçek zamanlı olarak x86'ya çevirerek çalıştırıyor. Bu işlem Frida'nın göremediği ayrı bir memory space'de gerçekleşiyor.

Frida → x86_64 process görüyor
Houdini → ARM kütüphanelerini kendi içinde çalıştırıyor
libpb_reader.so (ARM) → Frida'ya görünmüyor

Memu'yu ARM moduna geçirdim (System Settings → Preferences → ABI → ARM). Fark etmedi — Android sistemi x86_64 kalmaya devam etti, Frida hala ARM kütüphanelerine ulaşamadı.

---

/proc/pid/mem — Memory Dump Denemesi

Belki şifresi çözülmüş veriyi doğrudan RAM'den okuyabilirdim. EPUB dosyaları ZIP formatındadır, magic bytes: PK\x03\x04. Uygulama kitabı render ettiğinde bu veri bir an için RAM'de olmalı.

frida-ps -U | grep calibro
# 5254  com.calibro.reader:viewer

adb shell "su 0 cat /proc/5254/maps" > maps.txt

maps.txt'e bakınca libpb_reader.so ve libadobe_rmsdk.so ARM binary olarak yüklenmiş görünüyordu. Heap bölgelerini dump etmeye çalıştım:

cmd = f'adb shell "su 0 dd if=/proc/5254/mem bs=4096 skip={start//4096} count={size//4096}"'
# Sonuç: boş

/proc/pid/mem okuma bu Memu kurulumunda root ile bile çalışmıyordu.

---

Sonuç: DRM Kırılamazdı.

Şifre çözme anahtarı Calibro'nun sunucusunda. Cihaza hiçbir zaman tam olarak gönderilmiyor. Native ARM kod (Houdini altında) onu alıp kullanıyor, dışarıya sızdırmıyor. Frida ARM kütüphanelerine erişemiyor.

Bu noktada stratejimi değiştirdim.

---

Plan B: Ekran Görüntüsü Otomasyonu

Uygulama kitabı ekranda gösteriyordu. Ekranda olan her şey yakalanabilir :)

İlk deneme:

adb shell screencap -p /sdcard/test.png

Sonuç: Tamamen beyaz, boş PNG. Neden? FLAG_SECURE. Bu Android flag'i ekran görüntüsü alınmasını engeller.

Ama Memu'nun kendi screenshot mekanizması bu flag'i atlıyordu. Peki bunu ADB ile tetikleyebilir miydim?

adb shell "input keyevent 120"
# 120 = KEYCODE_SYSRQ = screenshot keycode

Evet! Bu komut FLAG_SECURE'u atlıyordu. Sayfa çevirmek için de klavye ok tuşu çalışıyordu:

adb shell "input keyevent 22"
# 22 = KEYCODE_DPAD_RIGHT = sağ ok tuşu

Ekrana tap bazı sayfalarda dipnot linklerine denk geliyordu. Klavye tuşu bu sorunu çözdü.

---

Otomasyon Scripti

import subprocess, time, os

output_dir = r'C:\Users\hicbi\Downloads\kitap_pages'
os.makedirs(output_dir, exist_ok=True)

popup_wait = 10.0
page_turn_delay = 1.5

def adb(cmd):
    subprocess.run(f'adb shell {cmd}', shell=True, capture_output=True)

def get_latest_screenshot():
    result = subprocess.run(
        'adb shell "ls -t /sdcard/Pictures/Screenshots/"',
        shell=True, capture_output=True, text=True
    )
    files = [f.strip() for f in result.stdout.strip().split('\n') if f.strip()]
    return files[0] if files else None

def capture_page(page_num):
    local = os.path.join(output_dir, f'page_{page_num:04d}.png')
    adb('"input keyevent 120"')
    time.sleep(popup_wait)
    latest = get_latest_screenshot()
    subprocess.run(
        f'adb pull "/sdcard/Pictures/Screenshots/{latest}" "{local}"',
        shell=True, capture_output=True
    )

def next_page():
    adb('"input keyevent 22"')
    time.sleep(page_turn_delay)

for i in range(1, 283):
    capture_page(i)
    if i < 282:
        next_page()

Karşılaşılan Sorunlar ve Çözümleri

1. Screenshot popup'ı
Her screenshot sonrası "Screenshot saved" popup'ı çıkıyordu. ADB ile kapatmayı denedim (input tap, keyevent 4 vs.) — olmadı. Çözüm: Popup 7-10 saniye sonra otomatik kapanıyor, popup_wait = 10 yaptım.

2. Dipnot linkleri
input tap 1200 450 koordinatı bazı sayfalarda dipnot linkine denk geliyordu. Çözüm: input keyevent 22.

3. Screenshots klasörünün dolması
Yüzlerce PNG birikince ls -t yavaşladı, timing bozuldu. Çözüm: Her 50 sayfada bir temizle:

adb shell "rm /sdcard/Pictures/Screenshots/*"

4. Windows uyku modu
Uzun süre hareketsiz kalınca Memu dondu. Çözüm: Güç ayarlarından uyku modunu "Hiçbir zaman" yap. Android için:

adb shell "settings put system screen_off_timeout 3600000"

5. EPUB sayfa numarası tutarsızlığı
282 sayfalık kitap 413 ekran görüntüsüne çıktı. EPUB'da sayfa numarası font boyutuna ve ekran boyutuna göre değişiyor.

6. Performans şişmesi
Uzun süreli çalışmada Memu RAM'i doldu. Çözüm: 50'şer sayfa batch'ler halinde çalıştır.

---

OCR: Görüntüden Metne

413 ekran görüntüsü elimdeydi. Tesseract OCR ile metni çıkardım:

• github.com/UB-Mannheim/tesseract adresinden Windows installer
• Kurulum sırasında "Additional language data" → Turkish seçilmeli

pip install pytesseract pillow

import pytesseract
from PIL import Image
import os

pytesseract.pytesseract.tesseract_cmd = r'C:\Program Files\Tesseract-OCR\tesseract.exe'

folder = r'C:\Users\hicbi\Downloads\kitap_pages'
files = sorted([f for f in os.listdir(folder) if f.endswith('.png')])

with open('buyuk_tarih.txt', 'w', encoding='utf-8') as out:
    for i, filename in enumerate(files):
        img = Image.open(os.path.join(folder, filename))
        text = pytesseract.image_to_string(img, lang='tur')
        out.write(text)
        out.write(f'\n\n--- Sayfa {i+1} ---\n\n')

Türkçe karakter tanıma (ş, ğ, ü, ö, ı, ç) neredeyse hatasız çalıştı.

---

Sonuç Olarak

Bir kitap için 10+ saat harcadım. Sırasıyla şunları denedim:

1. ✗ Adobe Digital Editions + DeDRM plugin → PBDRM formatını tanımıyor
2. ✗ PBDRM header analizi + RSA brute force → Yanlış anahtar
3. ✗ PKCS12 şifre kırma → Şifre bulunamadı
4. ✗ Frida hook → Houdini ARM emülasyonu engel
5. ✗ /proc/pid/mem dump → İzin yok
6. ✓ ADB screenshot otomasyonu → Çalıştı

DRM sistemi beni değil, içerik üreticisini korudu. Ben yasal olarak satın aldığım bir içeriği okumak için bu kadar çaba harcadım. Korsanlık yapan biri bu adımların hiçbirini atmak zorunda kalmaz — DRM kırılmış versiyonunu internetten bulur.

DRM'in asıl kurbanları içeriğe para veren legal kullanıcılardır. Bunun Netflix gibi streaming servislerinde de örneği bol. Örneğin TV'niz eskiyse Netflix DRM zincirini (Widevine) beğenmeyip HD abonesi olduğunuz içeriği SD çözünürlükte ve düşük bitrate'le görüntüleyebiliyor. Fakat korsan izlerseniz aynı içerikler 4k olarak hemen her yerde mevcut.

---

Kullanılan Araçlar

Araç	Amaç
Memu	Android emülatör
ADB (Android Debug Bridge)	Cihaz kontrolü
Frida	Dynamic instrumentation
Python + pycryptodome	RSA/AES analizi
Tesseract OCR	Görüntüden metin
Hex editör	PBDRM format analizi

---

Bu yazı tamamen kişisel kullanım amacıyla yapılan bir deneyin belgesidir. Hiçbir içerik üçüncü şahıslarla paylaşılmamıştır.

How Hard Can It Be? — DirectX’in Doğuşu

James R. Hagerty

1990’ların başında, Microsoft’un Windows işletim sistemi ofis uygulamalarında baskındı ancak bilgisayar oyunları dünyasında zayıf kalıyordu. Windows, oyun programları ile bilgisayar donanımı arasına girerek grafik ve animasyonları yavaşlatıyordu. Oyun geliştiricileri, bu tür kısıtlamalar getirmeyen DOS işletim sistemini tercih ediyordu.

Bu durum, Microsoft içindeki üç “asi” mühendis için bir fırsat yarattı: Eric Engstrom, Alex St. John ve Craig Eisler.

1 Aralık’ta 55 yaşında hayatını kaybeden Engstrom ve arkadaşları, Microsoft içinde oyun problemini çözmeye çalışan küçük bir ekip kurdular. Başta meslektaşlarıyla fikirlerini paylaşmamışlardı çünkü o kadar rahatsız edici bulunuyorlardı ki Windows iş biriminin başındaki Brad Silverberg onlara “Beastie Boys” lakabını takmıştı. Silverberg sık sık onları işten kovma taleplerini geri çevirmek zorunda kalıyordu.

Ama geliştirdikleri çözüm, DirectX, Microsoft’un kaderini değiştirdi. DirectX, oyunları tanınan bir platform haline getirdi ve geliştiricilere bilgisayarın grafik yeteneklerine doğrudan erişim sağladı—böylece DOS’tan bile daha iyi oyun deneyimi sunabildi.

Silverberg, “Harikaydı” dedi. 1995’te piyasaya sürülen DirectX, oyun geliştiricileri için adeta bir patlama yarattı ve Windows’a büyük bir ivme kazandırdı. Microsoft daha sonra Xbox konsolunu geliştirerek bu alandaki başarısını sürdürdü.

Engstrom, Seattle’daki bir hastanede hayatını kaybetti. Eşi Cindy Engstrom, ağrıları için aldığı Tylenol’ün yanlışlıkla fazla doz alınması sonucu karaciğer hasarı oluştuğunu belirtti.

Son yıllarında danışmanlık yaptı ve çeşitli iş fikirleri üzerinde çalıştı. Ayrıca drone teknolojileri ve soğuk füzyondan enerji üretimi gibi konularla ilgileniyordu. Teknik bir problemle karşılaştığında genelde “Bunu ne kadar zor olabilir ki?” diye yaklaşırdı.

---

George Eric Engstrom

25 Ocak 1965’te doğdu ve Washington eyaletinin küçük Colville kasabasında büyüdü. Kanadalı olan annesi, bir süre önce ABD’ye taşınmıştı. Babası ise eyer, bot ve diğer kovboy ekipmanları satan bir dükkân işletiyordu.

Çocukken astronot kostümü giyer ve 1969’da Neil Armstrong’un Ay’a inişini aile televizyonundan izlerdi. Kısa sürede kendisinin de Mars’a giden ilk insan olma planını ilan etti.

Babasının dükkânında çalışmak onu hayal kırıklığına uğrattı. Küçük sohbetlerden hoşlanmaz, müşteriyle uğraşmayı sevmezdi. “Hayatımın büyük kısmını halkla ilişkiler içinde geçirdim ve bundan pek hoşlanmadım” demişti 2003’te.

Gençlik yıllarında bilgisayar programlama yaparak para kazandı. Washington State Üniversitesi’nde birkaç ders aldı ama mezun olmadı. Freelance programcı olarak çalıştıktan sonra önemli bir müşterisini kaybedince ailesinin evine geri döndü. Bir süre oto yıkamada çalıştı.

Sonra bir arkadaşı onu Microsoft’a başvurmaya ikna etti. Ekose gömlek ve ütülü kot pantolonla mülakata gitti. “Sanki taşradan yeni gelmiş gibiydim” diye anlatmıştı. Buna rağmen kısa süreli bir müşteri hizmetleri işi buldu ve bu süreçte kendi kendine Fortran öğrenmek zorunda kaldı.

Geçici işi bittikten sonra hem Microsoft’tan hem de Oracle’dan teklif aldı. Microsoft’ta daha düşük maaş almasına rağmen hisse opsiyonları nedeniyle orayı seçti. “Ekose gömlekli insanların beni karıştırmak için yaptığı bir şey sandım” demişti. “İlk 10 milyon dolarımı böyle kaybettim—ve son da olmadı.”

1991’de Microsoft’a geri döndü ve oyun teknolojileri üzerine çalışan bir ekipte yer aldı. Eisler ve St. John ile tanıştı; birlikte spor yaparken onu oyun teknolojileri üzerine çalışmaya ikna ettiler.

2000’de Microsoft’tan ayrıldı ve cep telefonlarına farklı görünümler ve grafik özellikler kazandıran Wildseed Ltd. şirketini kurdu. Ancak bu girişim başarılı olamadı.

Eşi Cindy Smith ile Wildseed’de tanıştı (o şirketin pazarlama başkanıydı). 2005’te Groundhog Day’de evlendiler çünkü Engstrom’un tarihi hatırlayabileceğini düşündüler—yine de ilk evlilik yıldönümlerini unuttu. Geride eşi ve dört çocuğu kaldı.

Nerd Canon: Zihin, Matematik ve Hacker Kültürü Üzerine 20 Kitap

Bazen bazı kitaplar vardır; sadece bilgi vermezler, dünyaya bakış şeklini değiştirirler. Matematik, bilgisayar bilimi, bilinç felsefesi ve teknoloji kültürü etrafında dönen bir “entelektüel hat” vardır.

Bu yazıda o hattın önemli kitaplarından oluşan küçük bir okuma listesi topladım. Liste popüler bilimden biraz farklı: daha çok büyük fikirler, bilgi teorisi, bilinç, computation ve hacker kültürü etrafında dönüyor.

---

Matematik, zihin ve gerçeklik

Bu kitaplar matematiksel düşünce, formal sistemler ve bilincin doğası gibi konulara giriyor.

Gödel, Escher, Bach — Douglas Hofstadter

Muhtemelen yazılmış en ilginç popüler bilim kitaplarından biri. Matematik, sanat, müzik ve zihin felsefesini tek bir yapı içinde birleştiriyor. Gödel teoremleri üzerinden bilinç ve formal sistemler tartışılıyor.

The Mind’s I — Hofstadter & Dennett

Bilinç ve yapay zekâ üzerine klasik metinlerin ve düşünce deneylerinin bir derlemesi.

The Emperor’s New Mind — Roger Penrose

Penrose burada insan zihninin salt algoritmik olmayabileceğini savunuyor ve Gödel teoremleri üzerinden güçlü bir tartışma kuruyor.

Shadows of the Mind — Roger Penrose

Penrose’un önceki kitabındaki argümanı daha da ileri götürdüğü eser.

Mind and Cosmos — Thomas Nagel

Materyalist doğa anlayışına radikal bir eleştiri. Bilinç ve aklın evrendeki yeri üzerine düşündürücü bir kitap.

The Recursive Universe — William Poundstone

Cellular automata ve basit kurallardan karmaşıklığın nasıl ortaya çıkabileceğini anlatan çok keyifli bir kitap.

The Black Hole War — Leonard Susskind

Kara delik bilgi paradoksu üzerinden modern fiziğin en ilginç tartışmalarından biri.

---

Bilim insanlarının hikâyeleri

Bilimin ve merakın arkasındaki insanları görmek için.

Surely You're Joking, Mr. Feynman! — Richard Feynman

Feynman’ın anıları. Bilimsel merakın neye benzediğini gösteren eğlenceli bir kitap.

The Man from the Future — Ananyo Bhattacharya

John von Neumann’ın biyografisi. Modern dünyanın matematiksel mimarlarından biri hakkında.

---

Hacker kültürü ve bilgisayar tarihi

Bilgisayar kültürünün doğuşunu anlatan klasik kitaplar.

Hackers: Heroes of the Computer Revolution — Steven Levy

MIT hackerlarından kişisel bilgisayar devrimine kadar hacker kültürünün tarihini anlatır.

Where Wizards Stay Up Late — Katie Hafner & Matthew Lyon

ARPANET ve internetin doğuşu.

The Soul of a New Machine — Tracy Kidder

Bir minicomputer geliştiren mühendis ekibin hikâyesi. Donanım mühendisliği kültürünü çok iyi anlatır.

Out of Their Minds — Dennis Shasha

Bilgisayar biliminin öncülerinin röportajlarından oluşan bir kitap.

The Cuckoo's Egg — Clifford Stoll

İlk hacker avlarından biri. Gerçek bir siber güvenlik hikâyesi.

---

Computer science klasiği

Structure and Interpretation of Computer Programs

MIT’de yıllarca okutulmuş efsane ders kitabı. Programlamayı düşünme biçimi olarak ele alır.

---

Neal Stephenson romanları

Stephenson’ın romanları teknoloji, kriptografi ve bilim kültürünü kurgu içinde anlatır.

Cryptonomicon

II. Dünya Savaşı kriptografisi ile modern hacker kültürünü birleştiren dev roman.

Snow Crash

Cyberpunk klasiği. Metaverse fikrinin erken örneklerinden biri.

Anathem

Matematik, felsefe ve paralel evrenler üzerine yazılmış ilginç bir bilimkurgu.

---

Baroque Cycle (Neal Stephenson)

Modern dünyanın doğuşunu anlatan büyük bir tarihsel seri.

Quicksilver 

The Confusion 

The System of the World

Bilim devrimi, finans sistemleri ve erken modern bilim kültürü üzerine.

---

Felsefi klasik

What Is It Like to Be a Bat? — Thomas Nagel

Bilinç felsefesinin en ünlü makalelerinden biri. Başka bir zihnin deneyimini bilmenin mümkün olup olmadığını tartışır.

---

Bonus: Okuma listesinin doğal devamı

Bu kitapları sevenlerin çoğu genellikle şu kitabı da keşfeder:

The Fabric of Reality — David Deutsch

Kuantum mekaniği, evrim, computation ve bilgi teorisini tek bir çerçevede açıklamaya çalışan iddialı bir eser.

---

Sonuçta bu liste aslında tek bir sorunun etrafında dönüyor: 
Zihin nedir ve evren bilgiyle nasıl ilişkilidir?

Matematik, bilgisayar bilimi, fizik ve felsefe bu sorunun farklı taraflarını aydınlatmaya çalışıyor.

Bu kitapların ortak noktası da şu:
hepsi dünyaya bakış biçimini biraz değiştirebilecek büyük fikirler içeriyor.

Sony PS3, CELL BE, IBM güvenlik mimarisi ve hack meselesi...

Sony PlayStation 3'ün hacklenme hikayesi meraklısı için oldukça ilginç teknik detaylarla doludur. Temelde PS3 hacklenmiş olması sistemin kök güvenlik anahtarlarının ele geçirilmiş olduğu anlamına gelmemekte, bu da konuyu oldukça ilginç kılmaktadır.

ps3’te güvenlik zinciri metldr ile başlar. metldr cpu’nun içinde, mask rom ya da efuse benzeri bir yapıya gömülü olarak bulunur. Yazılımla erişilemez, dump edilemez, ram’e kopyalanmaz. metldr’den sonra bootldr gelir, ardından lv0, lv1 yani hypervisor ve en üstte lv2 yani gameos çalışır. bu zincirin güvenliği aşağıdan yukarıya doğru kuruludur ve en alt halka olan metldr kırılmadığı sürece zincirin tamamı teknik olarak ayakta kalır.

metldr’nin kullandığı anahtarlar bir dosya değildir. flash bellekte durmazlar, ram’de değişken olarak bulunmazlar, register’dan okunamazlar. cpu bu anahtarları “bilmez”. anahtarlar cpu’nun içindeki güvenlik bloğuna gömülüdür ve cpu sadece bu anahtarlarla işlem yaptırır. imza doğrulama ve decrypt işlemleri bu güvenlik bloğunda yapılır. anahtar hiçbir zaman system bus’a çıkmaz.

ps3’ün hacklenme sebebi donanım değildir. donanım tarafında sony anahtarları doğru yere koymuştur. kırılma noktası kriptografi uygulamasında yapılan hatadır. sony ecdsa imzasında nonce’u tekrar eden ya da sabit şekilde kullanmıştır. bu hata sayesinde yeterince imzalanmış binary toplandığında private signing key matematiksel olarak hesaplanabilmiştir.

ele geçirilen bu anahtar root of trust anahtarı değildir. metldr’nin anahtarı değildir. decrypt anahtarı değildir. bu anahtar yalnızca imza kontrolünü kandırır. yani sistem artık “bu kod sony tarafından imzalanmış mı” sorusunu sormaz hâle gelir. bu durum fake signed eboot’ların çalışmasına ve custom firmware’in mümkün olmasına yol açar.

crack denilen şey tam olarak budur. ps3’te crack, çalıştırma izninin kaldırılmasıdır. sistem hangi kodun çalıştırılabileceğine karar verirken imzaya bakmaz hâle gelmiştir. ama bu, şifre çözme yetkisinin ele geçirildiği anlamına gelmez. decrypt işlemi hâlâ donanımın içindedir ve metldr zinciri tarafından kontrol edilir.

oyun çalıştırıldığında eboot.bin zaten runtime’da çözülür. bu çözme işlemi cpu içindeki güvenlik motorunda gerçekleşir. anahtar bu sırada da görünmez. anahtar ram’e yazılmaz, cache’te tutulmaz, register’da bulunmaz. plaintext kod execution pipeline’a girer ama anahtar ortada yoktur. multiman gibi araçların yaptığı şey şifre çözmek değildir. multiman, ps3’ün zaten çalışırken çözdüğü kodu hdd’ye kopyalayarak kalıcı hâle getirir. anahtar yine ortada yoktur, sadece çıktısı vardır.

bu yüzden pc tarafında aynı işlem yapılamaz. pc’de metldr yoktur. pc’de bootldr yoktur. pc’de lv0 anahtarları yoktur. ps3dec gibi araçlar yalnızca disc encryption katmanını açabilir. asıl yürütülebilir kodun şifresi hâlâ çözülemez. rpc s3 gibi emülatörler bu donanımsal davranışı taklit etmeye çalışır ama her oyunda birebir aynı sonucu veremez.

decap ve mikroskop saldırılarının işe yaramamasının sebebi de budur. çünkü ortada klasik anlamda okunacak bir rom tablosu yoktur. anahtar bir bit dizisi olarak saklanmaz. anahtar cpu logic’inin davranışına gömülüdür. transistörleri görebilirsin ama “bu bit 1, bu bit 0” diyemezsin. anahtar hiçbir zaman internal bus’tan geçmediği için logic analyzer, bus sniff veya ram dump gibi yöntemler sonuç vermez.

sonuç olarak ps3 hacklenmiştir ama root of trust zinciri kırılmamıştır. imza kontrolü bypass edilmiştir ama decrypt anahtarları ele geçirilmemiştir. sony kriptografi tarafında büyük hata yapmıştır ama anahtarları silikona gömerek sistemin tamamen çökmesini engellemiştir. bu yüzden bugün hâlâ pc’de ps3 gibi birebir decrypt eden bir sistem yoktur ve ps3 güvenliği akademik olarak hâlâ anlatılmaktadır.

bu mimarinin tesadüf olmadığını anlamak için cell işlemcinin nereden geldiğine bakmak gerekiyor. cell, sony’nin tek başına tasarladığı bir tüketici işlemcisi değildir. cell broadband engine, ibm, sony ve toshiba ortaklığında geliştirilmiştir ve mimarinin omurgası doğrudan ibm’in server dünyasından gelir.

özellikle cell’in ppe çekirdeği, ibm’in power mimarisinin bir türevidir. bu mimari, playstation’dan çok önce ibm’in kurumsal ve yüksek güvenlikli sistemlerinde kullanılıyordu. cell’de gördüğümüz güvenlik anlayışı, “oyun konsolu güvenliği” olarak tasarlanmadı. bu anlayış, ibm’in yıllardır bankacılık, finans ve kritik altyapılarda kullandığı server güvenliği yaklaşımının küçültülmüş ve uyarlanmış hâlidir.

ibm, bu tarz donanımsal root of trust ve izolasyon teknolojilerini özellikle mainframe ve yüksek güvenlikli power server’larda kullanıyordu. z serisi mainframe’ler, power systems server’lar ve hsm benzeri güvenli modüller bu mimarinin asıl doğduğu yerlerdir. bu sistemler bankalarda, finans kurumlarında, borsa altyapılarında, sigorta sistemlerinde ve devlet kurumlarında kullanılır. bu ortamlarda tehdit modeli, bir kullanıcının oyun kopyalaması değildir. tehdit modeli, içeriden saldırı, fiziksel erişim, yan kanal saldırısı ve devlet seviyesinde aktörlerdir.

bu yüzden ibm’in güvenlik yaklaşımı, anahtarların yazılımla korunmasına dayanmaz. anahtarlar cpu’nun içinde, ayrı clock domain’lerde, ayrı güvenlik bloklarında tutulur. anahtarın ram’e çıkmaması, bus’tan geçmemesi, register’da görünmemesi gibi kararlar, ps3 için “abartı” gibi görünse de finans ve mainframe dünyasında standarttır. çünkü bu sistemlerde ram dump alınabileceği, bus sniff yapılabileceği ve fiziksel erişimin mümkün olduğu varsayılır.

cell işlemcideki security engine ve metldr benzeri yapılar, bu server dünyasının doğrudan mirasıdır. sony bu teknolojiyi oyun konsoluna taşıyarak, tüketici elektroniğinde o güne kadar pek görülmeyen bir güvenlik seviyesini hedeflemiştir. ps3’ün pahalı, karmaşık ve “zor kırılan” bir cihaz olmasının sebebi de budur. sony oyun konsolu yaparken, ibm tarafı neredeyse banka server’ı gibi düşünmüştür.

burada ilginç olan nokta şudur. sony kriptografi uygulamasında hata yapmış olmasına rağmen, ibm kökenli donanım güvenliği yaklaşımı sayesinde sistem tamamen çökmedi. imza kontrolü bypass edildi ama anahtarlar ortalığa saçılmadı. bu durum, server dünyasında yıllardır bilinen bir gerçeği ps3 üzerinden tekrar gösterdi. yazılım hata yapar ama donanım doğru tasarlanmışsa hasar sınırlı kalır.

ps3 güvenliğinin bugün hâlâ ilginç bulunmasının sebebi de buradan gelir. ps3 bir oyun konsoludur ama güvenlik mimarisi bir finans server’ının tehdit modelinden türemiştir. bu yüzden hacklenmiş olmasına rağmen root of trust zinciri ayakta kalmıştır ve bu yüzden pc’de ps3 gibi decrypt eden bir sistem hâlâ yoktur.

FFmpeg ile fotoğraflardan slayt video yapmak.

FFmpeg ile fotoğraflardan fade geçişli bir slayt video yapmak istedim. Elimde farklı çözünürlüklerde, dikey ve yatay karışık bir sürü fotoğraf vardı. Üzerine bir de uzun bir müzik ekleyip, fotoğrafların yumuşak fade in ve fade out geçişlerle aktığı bir video klip üretmek istiyordum. Bunu herhangi bir grafik arayüzlü programa bulaşmadan, tamamen FFmpeg ve script kullanarak yapmayı hedefledim.

Temel problem şuydu: Fotoğraflar birbirinden tamamen farklı boyutlardaydı. Bazıları dikey, bazıları yataydı. Ayrıca müzik süresi slaytların toplam süresinden uzundu ve yeni foto eklemek istemiyordum. Video süresi müzik süresi kadar olmalıydı.

İlk adımda tüm fotoğrafları ortak bir video formatına zorladım. Bunun için her fotoğrafa aynı FFmpeg filtresini uyguladım. Bu filtre fotoğrafı 1920x1080 çözünürlüğe, oranı bozmadan sığdırıyor, boş kalan yerleri pad ile dolduruyor, fade işlemleri için gerekli olan rgba formatına çeviriyor ve fps değerini sabitliyordu. Böylece fotoğrafın dikey ya da yatay olması tamamen önemsiz hale geldi.

Asıl iş fade geçişlerinde başladı. FFmpeg’in xfade filtresini kullanarak fotoğrafları zincir halinde birbirine bağladım. Her fotoğraf ekranda dört saniye kalıyor, bunun bir saniyesi bir sonraki fotoğrafa fade ile geçiyordu. Offset değerlerini fotoğraf sırasına göre manuel olarak hesaplayıp zincirledim. Bu işlemin sonunda tek bir video çıkışı elde ettim.

Bu noktada bir hatayla karşılaştım. FFmpeg sürekli olarak “No such filter: ''” hatasını veriyordu. İlk başta insan otomatik olarak fotoğraflarda, xfade kullanımında ya da müzik dosyasında bir problem olduğunu düşünüyor. Oysa sorun bunların hiçbiri değildi.

Hatanın gerçek sebebi filter.txt dosyasının sonunda kalan tek bir noktalı virgüldü. Filtergraph satırı noktalı virgül ile bittiğinde FFmpeg bir filter daha geleceğini varsayıyor. Ama devamında bir şey olmadığı için boş bir filter algılıyor ve bu da “No such filter: ''” hatasına yol açıyor. Yani tek bir fazla karakter tüm işi bozabiliyor. Çözüm, filter dosyasının son satırının kesinlikle noktalı virgül ile bitmemesi.

Fade’li slayt sorunsuz çalışmaya başladıktan sonra bu sefer müzik süresi problemi ortaya çıktı. Slaytlar kısa, müzik uzundu. Yeni foto eklemek istemediğim için slaytı loop etmek gerekiyordu. Bunu doğrudan fotoğraflar üzerinde yapmak FFmpeg açısından oldukça kırılgan bir yöntem. En stabil çözüm iki aşamalı çalışmak oldu.

Önce slayt zincirini bir kere render edip tek bir video dosyası ürettim. Ardından bu video dosyasını stream_loop parametresi ile sonsuz döndürdüm ve üzerine müziği ekledim. shortest parametresi sayesinde müzik bittiği anda video otomatik olarak kesildi. Bu yöntemle video süresi birebir müzik süresi kadar oldu ve fade geçişleri bozulmadı.

Son aşamada videonun başından tam olarak iki saniye kesmek istedim. İlk refleks olarak re-encode yapmadan, kopyalama ile kesmeyi denedim. FFmpeg komutu hatasız çalıştı ve dosya oluştu ama video fiilen kesilmemiş gibiydi. Bunun sebebi FFmpeg’in keyframe mantığıydı. c copy kullanıldığında FFmpeg keyframe olmayan bir noktadan net kesme yapamıyor. Dosya oluşsa bile görüntü başı çoğu zaman aynı kalıyor.

Bu durumda kesin çözüm re-encode ederek kesmek oldu. Video yeniden encode edildiğinde FFmpeg tam olarak ikinci saniyeden başlatıyor ve sonuç birebir istenen gibi oluyor. Küçük bir kalite kaybı olsa da pratikte fark edilmiyor.

Bu süreçte FFmpeg’in inanılmaz güçlü ama aynı zamanda aşırı hassas bir araç olduğunu tekrara zevkle gözlemledim. Özellikle filtergraph söz dizimi tek bir karakter yüzünden tamamen çökmeye çok müsait. Sondaki bir noktalı virgül uzunca süre debug yapmak zorunda bırakabiliyor. Ayrıca loop işlemlerinin mümkün olduğunca final videoda yapılması, c copy kullanımının ise keyframe bağımlılığı nedeniyle dikkatli ele alınması gerekiyor.

FFmpeg bence GUI olmadan piyasadaki son kullanıcı programlarından daha pratik, esnek ve güçlü bir video üretim aracı. En iyisi de nerd işi olması :) 

# make_slides.ps1
# Aynı klasördeki jpg/png'leri alır, 1920x1080 yapar, fade geçişli slayt video üretir.
# Çıktı: out_slides.mp4

$ErrorActionPreference = "Stop"

$ffmpeg = "ffmpeg"
$here = (Get-Location).Path

# Ayarlar
$w = 1920
$h = 1080
$fps = 24
$still = 4          # her foto toplam kaç saniye görünsün
$xfade = 1          # geçiş süresi
$transition = "fade"
$outFile = Join-Path $here "out_slides.mp4"

# Görselleri topla (music.mp3 vs hariç)
$imgs = Get-ChildItem -LiteralPath $here -File |
  Where-Object { $_.Extension -match '^\.(jpg|jpeg|png)$' } |
  Sort-Object Name

if ($imgs.Count -lt 2) { throw "En az 2 foto lazım." }

Write-Host "Images:" $imgs.Count
Write-Host "Output:" $outFile

# Filtergraph üret
# Her input: scale+pad+format+setsar+fps -> [v0]..[vN]
$parts = New-Object System.Collections.Generic.List[string]

for ($i=0; $i -lt $imgs.Count; $i++) {
  $parts.Add("[$i:v]scale=$w`:$h`:force_original_aspect_ratio=decrease,pad=$w`:$h`:(ow-iw)/2`:(oh-ih)/2,format=rgba,setsar=1,fps=$fps[v$i]")
}

# xfade zinciri
# Offset mantığı: her yeni foto bir öncekinin (still - xfade) kadar ilerisine oturur
# i=0->1: offset = still - xfade
# i=1->2: offset = 2*(still - xfade)
$step = ($still - $xfade)
$offset = $step

if ($imgs.Count -ge 2) {
  $parts.Add("[v0][v1]xfade=transition=$transition:duration=$xfade:offset=$offset[x1]")
  for ($i=2; $i -lt $imgs.Count; $i++) {
    $offset = $step * $i
    $parts.Add("[x" + ($i-1) + "][v$i]xfade=transition=$transition:duration=$xfade:offset=$offset[x$i]")
  }
  $last = "x" + ($imgs.Count - 1)
  $parts.Add("[$last]format=yuv420p[vout]")
} else {
  # teoride buraya düşmez çünkü 2 foto şart dedik
  $parts.Add("[v0]format=yuv420p[vout]")
}

$filter = ($parts -join ";")

# Filter dosyasını temiz ASCII olarak yaz (BOM yok, sonda boş filter yok)
$filterPath = Join-Path $here "filter_slides.txt"
[System.IO.File]::WriteAllText($filterPath, $filter, (New-Object System.Text.ASCIIEncoding($false)))

# ffmpeg args
$args = New-Object System.Collections.Generic.List[string]

foreach ($img in $imgs) {
  $args.AddRange(@("-loop","1","-t",$still.ToString(),"-i",$img.FullName))
}

$args.AddRange(@(
  "-filter_complex_script", $filterPath,
  "-map","[vout]",
  "-c:v","libx264",
  "-preset","medium",
  "-crf","18",
  "-pix_fmt","yuv420p",
  "-y", $outFile
))

Write-Host "Running..."
& $ffmpeg @args
if ($LASTEXITCODE -ne 0) { throw "ffmpeg hata verdi." }

Write-Host "OK -> $outFile"

# loop_audio.ps1
# out_slides.mp4'ü müzik bitene kadar loop eder, çıktı: out_loop.mp4
# stream_loop -1 ile video sonsuz döner, shortest ile audio bitince durur.

$ErrorActionPreference = "Stop"

$ffmpeg = "ffmpeg"
$here = (Get-Location).Path

$slides = Join-Path $here "out_slides.mp4"
$music  = Join-Path $here "music.mp3"
$out    = Join-Path $here "out_loop.mp4"

if (!(Test-Path $slides)) { throw "out_slides.mp4 yok. Önce make_slides.ps1 çalıştır." }
if (!(Test-Path $music))  { throw "music.mp3 yok." }

Write-Host "Slides:" $slides
Write-Host "Music :" $music
Write-Host "Out   :" $out

# NOT: Burada filter yok. En sağlamı bu.
& $ffmpeg `
  -stream_loop -1 -i $slides `
  -i $music `
  -map 0:v:0 -map 1:a:0 `
  -c:v libx264 -preset medium -crf 18 -pix_fmt yuv420p `
  -c:a aac -b:a 192k `
  -shortest -y $out

if ($LASTEXITCODE -ne 0) { throw "ffmpeg hata verdi." }

Write-Host "OK -> $out"

# cut2s.ps1
# out_loop.mp4 başından 2 saniye keser.
# c copy bazen keyframe yüzünden kesmiyor gibi görünür, o yüzden re-encode garanti.

$ErrorActionPreference = "Stop"

$ffmpeg = "ffmpeg"
$here = (Get-Location).Path

$in  = Join-Path $here "out_loop.mp4"
$out = Join-Path $here "out_loop_cut.mp4"

if (!(Test-Path $in)) { throw "out_loop.mp4 yok. Önce loop_audio.ps1 çalıştır." }

Write-Host "Input :" $in
Write-Host "Output:" $out

# Garanti kesim: re-encode
& $ffmpeg -ss 2 -i $in `
  -c:v libx264 -preset medium -crf 18 -pix_fmt yuv420p `
  -c:a aac -b:a 192k `
  -movflags +faststart `
  -y $out

if ($LASTEXITCODE -ne 0) { throw "ffmpeg hata verdi." }

Write-Host "OK -> $out"

Panasonic Viera Remote Control app w/ Python.

Wiz Light akıllı ampüller gibi resmi mobil uygulaması olup resmi desktop uygulaması olmayan bir başka cihaz ekosistemi de Panasonic Viera serisi TV'ler. Bu TV'lerin LAN üzerinden kontrol edilebilmesini sağlayan uzaktan kumanda uygulaması için ekran görüntüsü ve Python çözümü aşağıda.

Panasonic Viera - UPnP discovery + simple remote control (CLI + Tkinter GUI)
Works without PIN (if your TV doesn't require pairing).
Discovery via SSDP -> fetch device description -> find remote control service.
If discovery fails, you can enter IP manually.

Dependencies:
    pip install requests

Run:
    python panasonic_remote.py        # opens GUI
    python panasonic_remote.py --cli  # example CLI mode

Author: kadir — lightweight and pragmatic.
"""
import sys
import socket
import time
import threading
import requests
import xml.etree.ElementTree as ET
from urllib.parse import urljoin, urlparse
import argparse

try:
    import tkinter as tk
    from tkinter import simpledialog, messagebox
    HAS_TK = True
except Exception:
    HAS_TK = False

SSDP_ADDR = "239.255.255.250"
SSDP_PORT = 1900
SSDP_MX = 2
# Some Panasonic TVs respond to urn:schemas-upnp-org:device:MediaRenderer:1
SSDP_STS = [
    "urn:schemas-upnp-org:device:MediaRenderer:1",
    "ssdp:all",
    "urn:schemas-sony-com:service:IRCC:1",  # sometimes other vendors, harmless
]

DISCOVERY_RETRIES = 3
DISCOVERY_TIMEOUT = 2.0  # seconds per SSDP recv
HTTP_TIMEOUT = 4.0

# Common Panasonic remote keys (NRC_* family). You can add more if needed.
COMMON_KEYS = [
    "NRC_POWER-ONOFF", "NRC_VOLUP-ONOFF", "NRC_VOLDOWN-ONOFF",
    "NRC_CH_UP-ONOFF", "NRC_CH_DOWN-ONOFF", "NRC_MUTE-ONOFF",
    "NRC_MENU-ONOFF", "NRC_EXIT-ONOFF", "NRC_HOME-ONOFF",
    "NRC_INFO-ONOFF", "NRC_EPG-ONOFF", "NRC_GUIDE-ONOFF",
]

def ssdp_search(st, timeout=DISCOVERY_TIMEOUT, mx=SSDP_MX):
    """Send a single SSDP M-SEARCH and collect responses (non-blocking)."""
    msg = "\r\n".join([
        'M-SEARCH * HTTP/1.1',
        f'HOST: {SSDP_ADDR}:{SSDP_PORT}',
        'MAN: "ssdp:discover"',
        f'ST: {st}',
        f'MX: {mx}',
        '', ''
    ]).encode('utf-8')

    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    sock.settimeout(timeout)
    # Set TTL to 2 so it stays in local net
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)

    try:
        sock.sendto(msg, (SSDP_ADDR, SSDP_PORT))
    except Exception as e:
        print("SSDP send error:", e)
        sock.close()
        return []

    responses = []
    t0 = time.time()
    while True:
        try:
            data, addr = sock.recvfrom(65507)
            text = data.decode('utf-8', errors='replace')
            responses.append((text, addr))
        except socket.timeout:
            break
        except Exception:
            break
        # small safety to not loop forever
        if time.time() - t0 > timeout + 0.5:
            break
    sock.close()
    return responses

def parse_ssdp_response(text):
    """Parse SSDP response into dict of headers (case-insensitive)."""
    lines = text.splitlines()
    headers = {}
    for line in lines[1:]:
        if ':' in line:
            k, v = line.split(':', 1)
            headers[k.strip().upper()] = v.strip()
    return headers

def discover_panasonic(timeout=DISCOVERY_TIMEOUT, retries=DISCOVERY_RETRIES):
    """Try multiple SSDP searches and return list of candidate device LOCATION URLs."""
    locations = {}
    for attempt in range(retries):
        for st in SSDP_STS:
            resps = ssdp_search(st, timeout=timeout)
            for text, addr in resps:
                hdr = parse_ssdp_response(text)
                loc = hdr.get('LOCATION') or hdr.get('LOCATION'.upper())
                st_hdr = hdr.get('ST') or hdr.get('NT')
                usn = hdr.get('USN', '')
                if loc:
                    # Use parsed netloc as key to reduce duplicates
                    try:
                        key = urlparse(loc).netloc
                    except Exception:
                        key = loc
                    locations[key] = loc
        # quick sleep between retries
        time.sleep(0.25)
        if locations:
            break
    return list(locations.values())

def fetch_device_description(location_url):
    """GET device description XML and parse services. Return base URL and XML root."""
    try:
        r = requests.get(location_url, timeout=HTTP_TIMEOUT)
        r.raise_for_status()
        xmltext = r.text
        root = ET.fromstring(xmltext)
        # Base URL: try to read  or use location origin
        base_elem = root.find('{urn:schemas-upnp-org:device-1-0}URLBase')
        if base_elem is not None and base_elem.text:
            base = base_elem.text.strip()
        else:
            # fallback to scheme+netloc
            p = urlparse(location_url)
            base = f"{p.scheme}://{p.netloc}"
        return base, root
    except Exception as e:
        # print("fetch description error:", e)
        return None, None

def find_remote_control_service(base_url, root):
    """
    Scan device description for a service that provides Panasonic remote control.
    Commonly RemoteControl or IRCC-like services. Return control URL (absolute).
    """
    # Namespaces might vary; map known ones
    ns = {'upnp': 'urn:schemas-upnp-org:device-1-0'}
    service_list = root.findall('.//upnp:service', namespaces=ns)
    for svc in service_list:
        svc_type = svc.find('upnp:serviceType', namespaces=ns)
        svc_control = svc.find('upnp:controlURL', namespaces=ns)
        svc_event = svc.find('upnp:eventSubURL', namespaces=ns)
        if svc_type is None or svc_control is None:
            continue
        st = svc_type.text or ''
        ctrl = svc_control.text or ''
        # heuristics: Panasonic IR/Remote often has "IRCC" or "NRC" or specific Panasonic service types
        if 'IRCC' in st or 'RenderingControl' in st or 'AVTransport' in st or 'panasonic' in st.lower() or 'nrc' in st.lower():
            ctrl_abs = urljoin(base_url, ctrl)
            return ctrl_abs
    # fallback: try first service controlURL
    first = root.find('.//upnp:service/upnp:controlURL', namespaces=ns)
    if first is not None and first.text:
        return urljoin(base_url, first.text)
    return None

def send_key_http(remote_control_url, key):
    """
    Send remote key via HTTP SOAP. Many Panasonic TVs accept POST to /nrc/control_0 or similar.
    This implementation uses common Panasonic IRCC SOAP format.
    """
    # Build simple SOAP message that many Panasonic TVs accept:
    soap_body = f"""
    
      
        
          {key}
        
      
    """

    headers = {
        "Content-Type": "text/xml; charset=utf-8",
        "SOAPACTION": '"urn:panasonic-com:service:p00NetworkControl:1#X_SendKey"',
        "Connection": "close"
    }

    # Try POST; some TVs expect different endpoint paths; we'll attempt variations if necessary.
    candidates = [remote_control_url]
    # common alternative endpoints:
    parsed = urlparse(remote_control_url)
    base = f"{parsed.scheme}://{parsed.netloc}"
    alt_paths = [
        "/nrc/control_0", "/dmr/control_0", "/upnp/control/remote", "/nrc/control_0/HTTP/1.1"
    ]
    for p in alt_paths:
        url = urljoin(base, p)
        if url not in candidates:
            candidates.append(url)

    last_err = None
    for url in candidates:
        try:
            r = requests.post(url, data=soap_body.encode('utf-8'), headers=headers, timeout=HTTP_TIMEOUT)
            # Accept success codes (200/202) and even 500 sometimes (some TVs respond weirdly)
            if r.status_code in (200, 202, 500, 404):
                return True, url, r.status_code
            else:
                last_err = (url, r.status_code, r.text[:200])
        except Exception as e:
            last_err = (url, str(e))
    return False, last_err, None

class PanasonicRemote:
    def __init__(self):
        self.control_url = None
        self.last_location = None
        self.cached_host = None

    def discover_and_setup(self):
        locations = discover_panasonic()
        if not locations:
            return False, "No devices discovered via SSDP."
        # try each location until we find a control URL
        for loc in locations:
            base, root = fetch_device_description(loc)
            if not base or not root:
                continue
            ctrl = find_remote_control_service(base, root)
            if ctrl:
                self.control_url = ctrl
                self.last_location = loc
                self.cached_host = urlparse(loc).netloc
                return True, ctrl
        return False, "No control service found in device descriptions."

    def set_manual_ip(self, ip_or_url):
        # Accept either bare IP or full URL; convert to likely control endpoint
        if ip_or_url.startswith("http://") or ip_or_url.startswith("https://"):
            base = ip_or_url
        else:
            base = f"http://{ip_or_url}"
        # try fetching device description at /description.xml or /dd.xml common endpoints
        candidates = [base, urljoin(base, "/description.xml"), urljoin(base, "/dd.xml")]
        for c in candidates:
            try:
                b, r = fetch_device_description(c)
                if b and r:
                    ctrl = find_remote_control_service(b, r)
                    if ctrl:
                        self.control_url = ctrl
                        self.last_location = c
                        self.cached_host = urlparse(c).netloc
                        return True, ctrl
            except Exception:
                continue
        # fallback: set a plausible control endpoint
        self.control_url = urljoin(base, "/nrc/control_0")
        self.last_location = base
        self.cached_host = urlparse(base).netloc
        return True, self.control_url

    def send_key(self, key, retries=2):
        if not self.control_url:
            return False, "No control URL configured."

        for attempt in range(retries):
            ok, info, status = send_key_http(self.control_url, key)
            if ok:
                return True, info
            # on failure, try rediscover once
            if attempt == 0:
                # try quick rediscover if SSDP available
                try:
                    found, detail = self.discover_and_setup()
                    # if rediscovered a different endpoint, try again
                except Exception:
                    pass
            time.sleep(0.3)
        return False, info

# --- Simple CLI ---
def cli_mode():
    pr = PanasonicRemote()
    print("Discovering Panasonic TVs via SSDP...")
    ok, info = pr.discover_and_setup()
    if ok:
        print("Found control URL:", info)
    else:
        print("Discovery failed:", info)
        manual = input("Manual IP or URL (or Enter to abort): ").strip()
        if not manual:
            print("Aborted.")
            return
        ok, info = pr.set_manual_ip(manual)
        if ok:
            print("Using control URL (manual):", info)
        else:
            print("Manual setup failed:", info)
            return

    print("Available keys (common):", ", ".join(COMMON_KEYS))
    print("Type key and Enter to send. 'exit' to quit.")
    while True:
        k = input("key> ").strip()
        if not k:
            continue
        if k.lower() in ("exit", "quit"):
            break
        ok, info = pr.send_key(k)
        if ok:
            print("OK ->", info)
        else:
            print("FAIL ->", info)

# --- Simple Tkinter GUI ---
def gui_mode():
    if not HAS_TK:
        print("Tkinter not available on this Python. Use --cli.")
        return
    pr = PanasonicRemote()

    root = tk.Tk()
    root.title("Panasonic Remote — kadir")
    root.geometry("420x360")

    status_var = tk.StringVar(value="Durum: keşfediliyor... (SSDP)")
    ip_var = tk.StringVar(value="")

    def discover_thread():
        status_var.set("Keşfediliyor...")
        ok, info = pr.discover_and_setup()
        if ok:
            status_var.set(f"Bulundu: {pr.cached_host}")
            ip_var.set(pr.cached_host)
        else:
            status_var.set("Keşif başarısız. IP gir veya Yeniden Dene.")
            ip_var.set("")

    def on_discover():
        threading.Thread(target=discover_thread, daemon=True).start()

    def on_manual():
        ip = simpledialog.askstring("Manual IP", "TV IP veya URL gir:", initialvalue=ip_var.get())
        if not ip:
            return
        ok, info = pr.set_manual_ip(ip)
        if ok:
            status_var.set(f"Manual set: {pr.cached_host}")
            ip_var.set(pr.cached_host)
        else:
            messagebox.showerror("Hata", "Manual kurulum başarısız.")

    def send_key_gui(key):
        status_var.set(f"Sending {key} ...")
        def work():
            ok, info = pr.send_key(key)
            if ok:
                status_var.set(f"Sent {key}")
            else:
                status_var.set(f"Failed {key}: {info}")
        threading.Thread(target=work, daemon=True).start()

    # Layout
    top = tk.Frame(root, pady=6)
    top.pack(fill=tk.X)
    tk.Label(top, textvariable=status_var, anchor='w').pack(fill=tk.X, padx=6)
    ctrl = tk.Frame(root)
    ctrl.pack(padx=6, pady=8, fill=tk.BOTH, expand=True)
    # Buttons grid
    btns = [
        ("Power", "NRC_POWER-ONOFF"),
        ("Vol+", "NRC_VOLUP-ONOFF"),
        ("Vol-", "NRC_VOLDOWN-ONOFF"),
        ("Mute", "NRC_MUTE-ONOFF"),
        ("CH+", "NRC_CH_UP-ONOFF"),
        ("CH-", "NRC_CH_DOWN-ONOFF"),
        ("Menu", "NRC_MENU-ONOFF"),
        ("Home", "NRC_HOME-ONOFF"),
        ("Info", "NRC_INFO-ONOFF"),
        ("Exit", "NRC_EXIT-ONOFF"),
        ("Return", "NRC_RETURN-ONOFF"),
    ]
    r = 0; c = 0
    for label, k in btns:
        b = tk.Button(ctrl, text=label, width=10, command=lambda kk=k: send_key_gui(kk))
        b.grid(row=r, column=c, padx=4, pady=4)
        c += 1
        if c >= 3:
            c = 0; r += 1

    bottom = tk.Frame(root, pady=4)
    bottom.pack(fill=tk.X)
    tk.Button(bottom, text="Discover", command=on_discover).pack(side=tk.LEFT, padx=6)
    tk.Button(bottom, text="Manual IP", command=on_manual).pack(side=tk.LEFT)
    tk.Button(bottom, text="Quit", command=root.quit).pack(side=tk.RIGHT, padx=6)

    # Start initial discovery
    threading.Thread(target=discover_thread, daemon=True).start()
    root.mainloop()

# --- main ---
def main():
    p = argparse.ArgumentParser()
    p.add_argument("--cli", action="store_true", help="run CLI mode")
    args = p.parse_args()
    if args.cli:
        cli_mode()
    else:
        gui_mode()

if __name__ == "__main__":
    main()
    

Osiloskop vs ucuz logic analyzer.

555'li basit bir devrenin çıkışını Çin üretimi ucuz USB logic analyzer ve Hantek osisloskopla ölçüp karşılaştırdım, sonuç aşağıdaki gibi. 

Tabii daha farklı ve hızlı sinyallerde sonuç değişebilir ama 3-5 dolar bandında satılan, 8 kanallı ve saleae Logic yazılımıyla uyumlu bir USB oyuncak için sonuç çok tatminkar.

WiZ Akıllı Ampulleri PC'den Kontrol - Part II IP SCANNER

Daha önce Philips Wiz ampülleri python kütüphanelerini kullanarak PC'den kontrol etmeyi yazmıştım.

Wiz PC Kontrol

Zamanla dinamik network ortamında DHCP veya başka sebeplerden ampül TCPIP konfigürasyonları ve IP adreslerinin değişmesi dolayısıyla ampüllere ulaşmak için daha dinamik bir çözüm üretmek gerekti. Böylece networkteki Wiz ampülleri tarayıp IP adreslerini listeleyen bir uygulama yazdım.

Taramadan önce.

Tarama ağda üç ampül bulmuş.

Kod:

# -*- coding: utf-8 -*-

import tkinter as tk
from tkinter import messagebox
import asyncio
from pywizlight import wizlight, PilotBuilder
import socket

# IP araligini buradan ayarla
ip_range_start = 100
ip_range_end = 120
network_prefix = "192.168.1."

# GUI icinden cagirmak icin asyncio loop wrapper
class WizController:
    def __init__(self):
        self.loop = asyncio.new_event_loop()

    def turn_on(self, ip):
        self.loop.run_until_complete(self._turn_on(ip))

    def turn_off(self, ip):
        self.loop.run_until_complete(self._turn_off(ip))

    async def _turn_on(self, ip):
        try:
            bulb = wizlight(ip)
            await bulb.turn_on(PilotBuilder())
        except Exception as e:
            messagebox.showerror("Baglanti Hatasi", f"{ip} icin hata: {e}")

    async def _turn_off(self, ip):
        try:
            bulb = wizlight(ip)
            await bulb.turn_off()
        except Exception as e:
            messagebox.showerror("Baglanti Hatasi", f"{ip} icin hata: {e}")

    async def is_wiz_bulb(self, ip):
        try:
            bulb = wizlight(ip)
            await bulb.getPilot()
            return True
        except:
            return False

# Arayuz
app = tk.Tk()
app.title("WiZ Ampul Kontrol Paneli")
app.geometry("350x400")

controller = WizController()
frames = []

found_ips = []

# Tarama butonu ve alani
def scan_for_bulbs():
    result_box.delete(0, tk.END)
    found_ips.clear()
    for i in range(ip_range_start, ip_range_end + 1):
        ip = f"{network_prefix}{i}"
        try:
            socket.setdefaulttimeout(0.3)
            s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
            s.sendto(b'{"method":"getPilot"}', (ip, 38899))
            data, addr = s.recvfrom(1024)
            if b"method" in data:
                found_ips.append(ip)
                result_box.insert(tk.END, ip)
        except:
            continue

# Ampul kontrol paneli
button_frame = tk.Frame(app)
button_frame.pack(pady=10)

scan_btn = tk.Button(button_frame, text="Ampul Tara", command=scan_for_bulbs)
scan_btn.pack()

result_box = tk.Listbox(app, height=6)
result_box.pack(padx=10, pady=5, fill="x")

control_frame = tk.LabelFrame(app, text="Secilen IP'ye Komut Gonder", padx=10, pady=10)
control_frame.pack(padx=10, pady=10, fill="x")

btn_on = tk.Button(control_frame, text="Ac", width=10, command=lambda: controller.turn_on(result_box.get(tk.ACTIVE)))
btn_on.pack(side="left", padx=5)

btn_off = tk.Button(control_frame, text="Kapat", width=10, command=lambda: controller.turn_off(result_box.get(tk.ACTIVE)))
btn_off.pack(side="left", padx=5)

app.mainloop()

Amiga 600 Tamir Notları Part 1 - Genel Kontroller ve Yeşil Video Sinyal Hattı Tamiri.

 

İkinci elden durumu bilinmeyen (bu piyasada bu bozuk demek oluyor) bir Amiga 600 aldım ve elimde RGB skart kablo olmadığı için composite çıkışa (sarı RCA jack) bağlayarak çalışıp çalışmadığını hızlıca görmek istedim. Gücü açtığımda TV ekranı siyah ve Amiga ölü gibiydi. İlk olarak voltajları kontrol ettim, CN12 FDD portundaki 5v eksikti. Power soketin yerine tam oturmaması gibi ufak bir mekanik sorunu çözdükten sonra FDD pin header 5v hattı yerine geldi. Düzgün çalışan bir Amiga’da (sadece 500 ve 600 için bundan eminim çünkü elimde sadece bu ikisi var) anakarttaki 4 pin FDD power soketinde 12v, GND, GND ve 5v olmalı. Burası bence Amigalarda düzgün ve sağlıklı bir voltaj dağıtımı olup olmadığını kontrol etmenin uygun noktalarından biri. Zaten sistemde 5v, 12v ve GND dışında bir de -12v var, o da ses katındaki opamplar için gerekli. -12v hattı olmayınca sistem çalışıyor ama sesi bozuluyor, bunu da daha önce 500’de deneyimlemiştim.

Makine power soket tam oturmazken ölü gibiydi, ne 68k CPU ne de custom çipler ısınmıyor, ayrı ayrı denediğim LCD TV ve Sony PVM monitörde en ufak parazitlenme olmuyordu. Hiçbir yaşam belirtisi yoktu. LED board’u da eksik olduğundan oradan da bir ipucu alamıyordum. Power’ı hallettikten ve 4 pin FDD soketinde tüm voltajları gördükten sonra nette A600 black screen olarak aradım ve bu durumun en kronik sebebinin Amiga 600’deki reset devresi olduğunu gördüm. Bu devre kabaca bir RC osilatör ve 555 timer’dan oluşuyor. Reset devresi makineye güç geldikten sonra RC zaman sabiti kadar bir sürede Amiga’yı resetleyip normal state’e çekiyor. Bulduğum kaynaklarda RC zamanlama devresindeki C kapasitörünün bozulmasıyla ilgili kronik bir sorundan bahsediliyor ve ilgili C değiştirilince sorunun düzeldiği söyleniyordu. (Zaten çoğu hata yaşlı kondansatörlerden ortaya çıkıyor.) Kendi makinemdeki 555’in ilgili pinleri [2 ve 3] osiloskopla kontrol ettiğimde kapasitör şarj-deşarj eğrisinin gözle yakalanabilecek kadar yavaş işleyen bir sinyal olduğunu gördüm. Devre kabaca 1 sn kadar bir sürede 555’in ilgili pinindeki voltaj eğrisini GND’ye çekerek makineye reset atıyordu. Benim sistemimde burada bir sorun yoktu.

Bu arada bende eksik olan LED board yerine 330 ohm’a seri bir LED bağlayarak klavye yakınındaki status LED çıkışını tek tek gözlemledim. Buna göre power sürekli yanık, FDD boot esnasında seek edip kapanıyor, HDD ise hiç yanmıyordu. Buradan edindiğim izlenim makinenin CPU ve ROM’unda bir problem olmadığı yönündeydi çünkü bu rutinlerin minimumda CPU ve ROM’un sağlam olmasını gerektirdiğini düşünüyorum.

Status LED devresi.

A600 Led Board - Credit: Amigastore.eu

Kompozitte dalgalı siyah ekran hariç hiçbir görüntü olmayınca RGB portuna A520 modülatör takarak görüntü almayı denedim. Bu sefer bozuk da olsa aşağıdaki ekranı gördüm. Amiga büyük oranda sağlamdı fakat video sinyalinde yeşil hattı yoktu. Composite çıkışta da bu yüzden hiçbir görüntü yoktu çünkü RGB’nin aksine composite sinyal üretiminde kanal eksikliği tolere edilemiyor olmalı. A520 bunu nasıl yapıyor bilmiyorum zira Denise’ten çıkan analog RGB, önce composite sinyali üreten Sony CDX encoder’e, oradan da RGB porta geliyor. Çıkışta 15khz analog display sürüyor veya modülatör varsa A520 üzerindeki kompozit ve RF görüntü sinyali yine aynı kaynaktan gelen bu analog RGB’den üretiliyor. Oysa digital RGB pinleri CDX encodere uğramadan RGB konnektöre direkt bağlı. Özetle CDX’in yeşil kanalı olmayınca yapamadığı analog red ve blue’dan composite sinyal üretimini A520 yapabiliyor. Veya aynı işi CDX de yapabiliyor ama CDX’ten composite RCA sokete giden hatta bozuk komponentler var. Bu bölgeyi henüz detaylı incelemiş değilim.

A520 modulator çıkışı. Yeşil renk eksik.

Olması gereken.

Pin 5-4-3 Sony CDX encoder entegresinden gelen analog sinyal hattı (AB, AG, AR) . Sorun pin 4'teki AG (analog yeşil) hattında. 7-8 ve 9 no'lu pinler dijital video çıkışı ve doğrudan Denise tarafından sürülüyorlar.

74HCT244 Buffer pinout.

Denise'den çıkan analog yeşil sinyali U31 buffer çipi pin 11'den girip  pin 9'den çıkıyor ve Sony CDX encoder green_in (G_IN) hattına ulaşamıyor. Sorun bu iki nokta arasında.

Video port 8,9 ve 7 numaralı pinlerden birindeki dijital RGB sinyali. Üçü sinyal da 15.6 khz gibi anlamlı bir frekansa sahip ve benzer dalgaformlarında, dolayısıyla sorunsuz görünüyorlar. Üç hattın üçünü de eklemeye gerek görmedim. Bu gözlemler neticesinde Denise'in sağlam olduğunu varsayabiliriz; yay 🥳

Bu sefer CDX'ten gelen analog video sinyallerini gözlüyoruz. Üstteki resim normal örnek, R ve B hatları böyle görünüyor.

CDX'ten gelen son sinyal böyle. Video out pin 4, analog yeşil hattı. Dalga şekli R ve B'deki diğer analog sinyallere benzemeli ama sadece düze yakın anormal bir DC offset var. CDX giriş ve çıkışlarını kontrole geçiyorum.

Sorunlu yeşil hattının şematik görünümü. 74HCT244 bufferdan çıkıp sağda görülen CDX'in R_IN, G_IN ve B_IN girişlerini besliyor.

Bu hattın PCB'deki yeri.

Burada yaptığım osiloskop ölçümünde Q212’nin base’inde R215’den gelen green sinyalinin var olduğunu, collector’de düzgün VCC gerilimi (~4v gibi) ve C212’ye çıkan emiterde DC ofset gözlemledim. Yani transistöre sinyal giriyor, beslemesi de düzgün fakat çıkışında olması gereken yeşil sinyali yok. Denise – CDX encoder hattında yeşil sinyali taşıyan arızalı eleman Q212 transistörü.

PCB

Pinout

1AM BC847B Sot-23 paket NPN tipi. Üretici Nxp, on semi vs. h: üretim kodu olabilir, önemsiz.

Q212 için elimdeki uyumlu alternatiflerden biri BC546, test amaçlı bozuk olanı söküp bunu lehimliyorum.

BC546 pinout

Tamir videosu:

https://youtu.be/BLDa1a9IHZ4

Sorunlu transistörü değiştirdikten sonra düzelen görüntü. 🥳