Akıllı ev cihazlarına yıllardır denk geliyoruz ama çoğu zaman perde arkasında neler olup bittiğini pek düşünmüyoruz. Benim merakım da tam burada devreye girdi. Philips Hue'nun BLE ile çalışan akıllı lambasını elime alıp "Bu şey telefonla nasıl konuşuyor?" diye sorgulamaya başladım. Ham HCI loglarını açtım, frame'leri tek tek inceledim ve bağlantı ile güvenlik sürecinin nasıl ilerlediğini adım adım çıkarmaya çalıştım. Bu yazıda, o küçük merak yolculuğunun teknik tarafını paylaşıyorum.
Reklam Aşaması, Cihaz Kendini Tanıtır
Hue lambanın BLE tarafındaki ilk adımı, çevreye periyodik olarak advertising paketleri göndermek. Bu paketler aslında "ben buradayım, bana bağlanmak serbest" diyen küçük anonslar gibi çalışıyor. Wireshark'ta gördüğümüz LE Advertising Report (Event Code 0x3E, Subevent 0x02) tam olarak bu anı temsil ediyor.
İncelediğimiz örnek frame'de (Frame 221) lamba, Connectable Undirected Advertising (ADV_IND) tipi bir paketle yayın yapıyor. Adres tipi Random Device Address olarak işaretli; yani cihaz sabit bir public MAC kullanmak yerine, gizlilik için rastgele (ama genelde statik) bir adresle görünüyor. Bu paket, uygulamanın "yakında bağlanılabilir bir Hue/Signify cihazı var" bilgisini almasını sağlıyor.
Reklam verisinin içinde klasik Flags (0x01) alanı ve ardından 16-bit Service Class UUIDs (0x02) bulunuyor. Burada görülen UUID 0xFE0F, resmi olarak Signify Netherlands B.V. (Philips Lighting) için ayrılmış bir alan. Bunun hemen altında yine 0xFE0F UUID'siyle etiketlenmiş bir Service Data bloğu yer alıyor; bu blokta Philips'e ait üretici/veri formatına uygun, cihazın ekosistem içinde tanımlanmasına yarayan ham baytlar taşınıyor. Yani bu ilk reklam paketinde henüz cihaz adı veya model string'i yok; bunlar çoğunlukla ya ayrı bir Scan Response paketinde, ya da bağlantı sonrası GATT Device Information Service üzerinden ortaya çıkıyor.
Bu tek frame bile, Hue lambanın kendisini BLE dünyasında nasıl konumlandırdığını gösteriyor.
Bağlantı Kurulumu ve MTU Pazarlığı
Hue lambaya bağlantı sağlandıktan sonra BLE iletişiminin ilk aşamalarından biri MTU (Maximum Transmission Unit) pazarlığıdır. Bu aşama, iki cihazın birbirine "en fazla kaç baytlık veri paketleriyle konuşalım?" sorusunu sorduğu bir kapasite anlaşmasıdır. MTU değeri ne kadar yüksek olursa, özellikle renk/efekt gibi büyük veri bloklarının iletimi o kadar verimli gerçekleşir.
Aşağıdaki ilk karede tablet (central), lambaya Exchange MTU Request (0x02) göndererek kendi desteklediği maksimum paket boyutunu bildiriyor: 247 byte.
İkinci karede ise lamba (peripheral), Exchange MTU Response (0x03) paketiyle kendi kapasitesini bildiriyor. Philips Hue lamba, BLE katmanında oldukça geniş bir MTU desteği sunuyor ve 517 byte'lık bir değer geri döndürüyor. Bu, özellikle geniş renk/scene parametrelerinin aktarımında performansı belirgin şekilde artırıyor.
Bu iki paket birlikte değerlendirildiğinde bağlantının toplam etkin MTU değeri 247 oluyor (BLE'de etkin MTU, iki tarafın bildirdiği değerlerin en küçüğüdür). Bu aşamanın ardından tüm GATT trafiği artık bu MTU limitlerine göre optimize edilmiş şekilde ilerliyor.
Pairing Süreci ve LE Secure Connections ECDH Anahtar Değişimi
Hue lambanın BLE tarafında en çok merak ettiğim şey aslında pairing sürecinin nasıl çalıştığıydı. Çünkü bu aşama hem güvenliğin temelini oluşturuyor, hem de cihazın gerçekten "ne kadar modern bir stack kullanıyor?" sorusunun cevabını veriyor. Logları incelemeye başladığımda ilk karşıma çıkan şey Pairing Request / Pairing Response paketleriydi. Bu ikili aslında iki cihazın "benim kabiliyetim bu, seninki ne?" diye konuştuğu yer.
Tablet tarafı oldukça iddialı geliyor: MITM koruması istiyor, Secure Connections aktif, bonding yapalım diyor. Hue lamba ise tam tersi; "benim input–output yeteneğim yok, MITM yapamam, sadece Just Works modunda pairing yapabiliriz" diyor. Bu, yapısı gereği çoğu IoT cihazda gördüğüm bir durum, küçük ekran yok, tuş yok, o yüzden daha güçlü doğrulama mekanizmaları devre dışı kalıyor.
Beni şaşırtan şey şu oldu: IO tarafında bu kadar sınırlı olmasına rağmen Hue lamba LE Secure Connections (ECDH P-256) protokolünü tamamen destekliyor. Görselde de var, iki taraf karşılıklı olarak 64 baytlık public key'lerini gönderiyor. Bu, cihazın aslında güvenlik tarafında eski BLE Legacy Pairing'i değil, modern kripto altyapısını kullandığını kanıtlıyor. Açıkçası bu kısmı görmek hoşuma gitti; birçok ucuz IoT cihaz hâlâ Legacy Pairing'de takılı kalmış durumda.
Public key aşamasından sonra gelen Confirm ve Random mesajları pairing'in challenge–response bölümünü oluşturuyor. Burada iki cihaz da birbirine "ben doğru hesap yaptım mı?" diye kendini ispatlıyor. Bunu incelerken akışın textbook gibi ilerlediğini gördüm; herhangi bir hata, eksik alan, garip vendor davranışı yok.
Pairing akışında en sevdiğim an her zaman DHKey Check kısmıdır. Çünkü burada iki tarafın gerçekten aynı ortak anahtarı hesaplayıp hesaplamadığı belli olur. Logda iki yönde de DHKey Check'in başarılı geçtiğini görünce "tamam, secure connections zinciri doğru kurulmuş" diyebiliyorum.
Pairing bittikten sonra karşımıza Identity Information ve Identity Address Information paketleri çıkıyor. Bu kısım, cihazların birbirlerine IRK (Identity Resolving Key) gibi uzun vadeli kimlik bilgilerini vermesi demek. Yani bundan sonra tekrar bağlandıklarında yeniden pairing yapmaları gerekmiyor, doğrudan şifreli moda geçebiliyorlar. Buradaki akış da tamamen beklediğim gibi ilerliyor.
Bu bölümün sonunda Hue lambanın pairing yapısını şöyle özetleyebilirim:
- IO tarafında sınırlı → Just Works zorunlu
- Kripto tarafında modern → ECDH aktif
- Tüm SMP adımları eksiksiz → Confirm, Random, DHKey Check hepsi textbook
- Bonding süreçleri düzgün → IRK ve Address Info karşılıklı gönderiliyor
Kısacası, lambanın fiziksel doğrulama kapasitesi olmasa da arkada çalışan güvenlik protokolü oldukça temiz ve güncel. Bu benim açımdan pozitif bir keşif oldu çünkü birçok IoT cihazda pairing adımları çok daha dağınık olabiliyor.
GATT Trafiği ve Hue Lambanın Gerçek Kontrol Akışı, Keşif Vakti
Pairing ve şifreleme tamamlandıktan sonra iletişimin artık "esas" kısmına geçiliyor: cihazın gerçekten nasıl kontrol edildiği. Bu aşama BLE dünyasında GATT üzerinden yürüyor. Hue lamba da istisna değil; tüm ışık ayarları, renk komutları, parlaklık değişiklikleri bu GATT karakteristiklerine yapılan Write işlemleriyle gerçekleşiyor.
Bu bölüm benim için en merak ettiğim kısımdı çünkü gerçek kontrol akışı burada ortaya çıkıyor: "Uygulama ışığı açmak istediğinde hangi handle'a ne gönderiyor?" sorusunun cevabı burada saklı.
İlk dikkatimi çeken şey şu oldu: pairing tamamlanır tamamlanmaz lamba çok hızlı bir şekilde birkaç karakteristik hakkında bilgi gönderiyor ve uygulama da bunları sorgulamaya başlıyor. Bu, pek çok Bluetooth cihazda gördüğüm klasik "servis keşfi" aşaması.
Daha sonra işin ilginç kısmı ortaya çıkıyor: Hue'nun ışık kontrolü belirli handle'lar üzerinden yapılıyor ama bunlar standart GATT servisleri değil. Yani "0x2A56 = Light Control" gibi bir şey yok. Philips tamamen vendor-specific bir protokol kullanıyor ve komutlar belirli handle adreslerine yazılıyor.
Örneğin analiz sırasında şunu fark ettim:
- Bazı handle'lara yapılan küçük Write Command'lar (0x12) → büyük ihtimalle aç/kapa gibi basit durum değişiklikleri.
- Bazı handle'lara daha büyük payload'lı write komutları gidiyor, bunlar renk/efekt parametreleri olabilir.
- 0x0032 ve 0x006A civarı handle'ların düzenli olarak kullanıldığını gördüm → muhtemelen ana kontrol dizisinin parçası.
Doğrusu, Hue'nun bu vendor-specific formatı şifreleme bittikten sonra bile kolayca anlaşılabilir değil; veriler şifreli olduğu için ham payload'ları Wireshark'ta göremiyoruz. Bu da demek oluyor ki pairing sırasında kurulan AES-CCM bağlantısı görevini başarıyla yapıyor. GATT katmanında gönderilen komutlar decode edilemiyor, sadece handle numarasına, paket boyutuna ve opcode'a bakarak davranışı tahmin edebiliyorum.
Bu bana iki şeyi gösterdi:
- 1. Hue tarafında ciddi bir güvenlik farkındalığı var. Şifreleme sadece pairing için değil, tüm veri akışı için zorunlu.
- 2. Vendor protokolü gizli tutulmuş durumda. Paket formatı açık dokümantasyonda yok; tersine mühendislik olmadan anlamak kolay değil.
Burada hoşuma giden bir detay var: bazı BLE cihazları pairing yapsa bile kontrol komutlarını şifrelemez (inanılmaz ama hâlâ böyle ürünler var). Hue bunu düzgün yapıyor; bu da potansiyel saldırı yüzeyini ciddi anlamda azaltıyor. Wireshark'ta sadece:
- "Write Request / Write Command, Handle 0xXXXX"
- "Encrypted Payload (XX bytes)"
görüyorsun. Bu, güvenlik açısından doğru davranış.
GATT akışı incelerken şunu fark ettim: uygulama renk veya parlaklık değiştirirken tek bir komut değil, arka arkaya birkaç write gönderiyor. Bu küçük paketler muhtemelen:
- renk profilini,
- efekt parametrelerini,
- transition hızını,
tek bir API çağrısından parçalı biçimde lambaya işliyor.
Kısacası GATT trafiği bize şunu kanıtladı:
- Hue görünürde sade bir cihaz gibi duruyor ama
- arkada çalışan protokol oldukça detaylı,
- ve her şey sıkı şifreleme altında gidiyor.
Bu aşamada cihazın nasıl konuştuğuna dair güzel bir fikir edindim: hangi handle'lar kritik, hangileri sadece durum bildiriyor, hangileri sürekli aktif. Bu bilgiler sonraki analizlerde ,özellikle "kontrol protokolünü modelleme" kısmında, işimize yarayacak.
Hue Lambanın Notification Davranışı ve Durum Güncellemeleri
Hue lambanın BLE iletişimini incelerken en ilginç bulduğum noktalardan biri, cihazın kontrol komutlarını sadece almakla kalmayıp düzenli olarak aktif şekilde geri bildirim göndermesi oldu. Bu geri dönüşler BLE'nin "notification" mekanizmasıyla yapılıyor ve GATT seviyesinde 0x006A adlı karakteristik üzerinden akıyor.
Örneğin yakaladığım bir pakette, lamba işlem yaptıktan sonra telefona küçük ama düzenli bir hex blob gönderiyor; içerik tamamen şifreli olduğu için, Wireshark bu paketin içinde sadece "Value: 80000800…" gibi bir veri gösteriyor ama ne anlama geldiğini çözemiyoruz. Bu da Hue'nun sadece komut tarafını değil, durum güncellemelerini de şifrelediğini kanıtlıyor.
Buradaki güzel detay şu: aynı handle, 0x006A, hem telefondan cihaza giden küçük kontrol komutlarında kullanılıyor, hem de cihazdan telefona dönen durum bildirimlerinin çıkış noktası. Yani bu karakteristik adeta sistemin "kalp atışı" gibi çalışıyor; komut gidiyor, çok kısa bir süre sonra lamba bir notification gönderiyor, ardından tekrar komut ve tekrar notification… Böyle bir ritim var. Bu model bana lambanın bir "state machine" mantığıyla çalıştığını düşündürdü: uygulama bir şey söylüyor, lamba yanıt veriyor, uygulama başka bir şey söylüyor, lamba yeniden durumu bildiriyor. BLE tabanlı cihazların çoğu bu kadar düzenli geri bildirim akışı sağlamıyor; Hue burada daha sofistike bir yaklaşım kullanıyor.
Trafik üzerinde biraz zaman geçirdikçe 0x0032 ve 0x006A'nın rollerinin yavaş yavaş netleştiğini fark ettim. 0x0032 daha büyük, daha karmaşık komutların geçtiği yer gibi duruyor; muhtemelen renk, efekt veya sahne ayarları burada işleniyor. 0x006A ise çok daha sık ve çok daha küçük paketlerle dolu. Bu yüzden 0x006A bana hızlı durum kontrolü, aç/kapa, transition gibi küçük fakat kritik ayarların işlendiği yer izlenimini verdi. İşin daha da güzeli, bu kanalın hem komut hem de durum trafiğini taşıması, Hue'nun protokolünü daha kompakt fakat aynı zamanda daha güvenli hale getiriyor.
Notification paketlerinin hepsinin şifreli olması önemli bir güvenlik avantajı. Bazı BLE cihazlarının hâlâ pairing sonrası bile şifreli olmayan state paketleri gönderdiğini düşününce, Hue'nun bu konuda iyi bir iş çıkardığını söylemek gerekiyor. Neyin değiştiğini veya lambanın hangi durumda olduğunu dışarıdan sadece paketlere bakarak anlamak imkânsız; tek görebildiğiniz şey "şifreli bir blob geliyor" olması. Bu da saldırı yüzeyini ciddi anlamda daraltıyor.
Kısacası, Hue'nun BLE notification akışı hem temiz, hem düzenli, hem de güvenli. 0x006A'nın çift yönlü trafik merkezi olması da protokolün nasıl tasarlandığına dair güzel bir ipucu veriyor. Lamba, herhangi bir komuta sadece sessizce uymak yerine, arka planda sürekli olarak kendi durumunu raporluyor ve bu geri bildirim döngüsü, cihazı beklenmeyen durumlara karşı daha kontrollü hale getiriyor.
Manipülasyon Testleri
Elbette bu inceleme sırasında sadece pasif analiz yapmadım; cihazın davranışını anlamak için birkaç küçük manipülasyon testi de denedim. Örneğin:
- Uygulama bir komut gönderdikten hemen sonra aynı handle'a farklı bir değer yazmayı denedim
- Notification paketlerini yakalayıp zamanlamalarını bozmayı test ettim
- Bazı handle'lara beklenmedik büyüklükte yazmalar göndermeye çalıştım
- Normalde kullanılmayan handle'lara sahte paketler yazmayı denedim
Tüm bu denemelerde ortak sonuç ortaya çıktı: Hue'nun şifreleme ve bağlantı güvenliği buna izin vermiyor.
Şifreli kanal kurulduktan sonra cihaz, uygulama dışında bir kaynaktan gelen ham BLE yazmalarını kabul etmiyor. Payload seviyesinde müdahale etmek ise mümkün değil, çünkü tüm anlamlı içerik bağlantı anahtarları ile AES-CCM altında taşındığı için decode etmek veya sahte bir komut üretmek mümkün olmadı. Ayrıca Hue'nun firmware tarafında muhtemel rate limit veya bütünlük kontrol mekanizmaları da var; hızlı ya da eşzamansız yazma denemeleri sonuç vermedi.
Sonuç olarak, bu çalışmada Hue'nun BLE protokolündeki davranışların tamamını anlamış olsam da, şifrelemenin güçlü uygulanması nedeniyle komut manipülasyonu, paket yeniden üretme (replay), sahte komut yazımı veya uygulama dışı kontrol gibi testlerin hiçbiri başarılı olmadı. Bu da aslında cihazın güvenlik tarafında ne kadar doğru kararlar verdiğini gösteriyor. Hue'nun BLE iletişimi, "genel IoT BLE cihazları" seviyesinin üzerinde bir güvenlik kalitesine sahip; hem trafik düzeni hem de şifreleme tutarlılığı açısından iyi tasarlanmış.
Kısacası: Protokolü anlamak mümkün, ancak manipüle etmek kolay değil, çünkü Hue çoğu IoT cihazının aksine BLE güvenliğini gerçekten uygulamış.
Bazen gereksizse söndürmek lazım :)
// RAPOR SONU, MUCAHIC / OP-0042 / 2025.12.08