Motosikletinizin Bluetooth özellikli dijital gösterge paneline Google Haritalar’dan navigasyon eklemek istediniz mi? Bu, sıradan bir kullanıcı için neredeyse imkânsız gibi görünse de, aslında sadece bir protokolün ardındaki gizemi çözmeye bağlıydı. Geçtiğimiz haftalarda, bir geliştirici, motosikletinin Bluetooth arayüzünü reverse engineer ederek, üreticiye ait uygulamaya bağımlı kalmadan, doğrudan gösterge paneline Google Haritalar navigasyonunu entegre etmeyi başardı. Peki, bu süreç nasıl başladı ve hangi adımlardan geçti?
Bluetooth arayüzünde gizli kapılar açıldı
Motosikletinizin Bluetooth ile bağlı dijital gösterge paneli, üreticinin kendi uygulamasıyla eşleşiyor ve navigasyonu doğrudan ekranda gösteriyor. Ancak bu özellik, birçok kullanıcı için hayal kırıklığı yaratabiliyor: harita sağlayıcısı tercih edilebilir değil, uygulama kullanıcı dostu değil ve sistem genişletilebilir değil. Peki, bu iletişim sadece basit bir Bluetooth bağlantısından ibaretse, ne kadar kilitli olabilir ki?
İşte tam da bu soru, bir hafta sonunu reverse engineering’e adamaya karar veren geliştiriciyi harekete geçirdi. Birkaç haftalık yoğun çalışmanın ardından, artık motosikletinin gösterge paneline Google Haritalar’dan navigasyon verisini aktarmayı başardı. Peki, bu süreç nasıl başladı?
Belgeler yerine gerçek trafiğin peşinde
Üreticinin protokolüne dair herhangi bir dökümantasyon bulunmuyordu. Var olan tek referans, derlenmiş haliyle üreticinin kendi uygulamasıydı. Bu nedenle, ilk adım olarak Bluetooth arayüzünü incelemeye karar verildi. GATT taraması yapılarak, canlı motosiklet üzerindeki tüm olası iletişim kanalları incelendi. Sonuç? Tek bir üreticiye ait servis ve iki karakteristik: biri telefondan gönderilen veriler için, diğeri motosikletin geri bildirimleri için. Tüm iletişim bu iki nokta arasında gerçekleşiyordu.
Ardından, gerçek veri trafiğini yakalamak için Android’in HCI snoop log özelliği kullanıldı. Telefon ve motosiklet eşleştirildikten sonra yapılan kısa bir sürüş sırasında tüm Bluetooth paketleri kaydedildi. Ancak elde edilen veriler sadece hexadecimal dizilerden ibaretti — hangi baytın ne anlama geldiği hakkında hiçbir fikir yoktu.
Uygulamanın kodunu deşifre etmek
Hexadecimal verileri saatlerce incelemek, çözümü bulmanın en verimli yolu değildi. Bunun yerine, üreticinin uygulamasına odaklanıldı. APK dosyası çıkarıldı ve JADX kullanılarak dekompilasyon işlemi gerçekleştirildi. Sonuç? Uygulamanın kaynak koduna oldukça yakın bir biçimde ulaşılmıştı — sınıf isimlerinin bile çoğu zaman obfuscate edilmediği görülüyordu.
Bu noktada, her bir mesajın içeriğini anlamak için kod incelemesi ve gerçek trafik verileri karşılaştırıldı. Örneğin, "200 metre sonra sola dön" gibi bir navigasyon bilgisi, telefondan motosiklete nasıl aktarılıyordu? Frida adlı araç, bu süreci daha da netleştirdi. Uygulamanın çalışırken gerçek verilerle nasıl etkileşimde bulunduğunu doğrudan izlemeye ve kaydetmeye imkân sağladı.
Yavaş yavaş, mesaj yapısı ortaya çıkmaya başladı. Tüm mesajların 30 bayt uzunluğunda olduğu anlaşıldı: sabit bir başlık baytı, mesaj türünü belirten bir ASCII karakter, bir gövde, bir checksum ve bir sonlandırıcı. Checksum algoritması, dekompilasyon sonucu bulunan fonksiyon tarafından hesaplanıyordu — bu, tahmin etmek yerine doğrudan koddan doğrulanabilen bir gerçekti.
Ayrıca, motosikletin yanıt odaklı bir cihaz olduğu ortaya çıktı. Telefon, veri gönderene kadar motosiklet sessiz kalıyordu. Bu durum, ilk başta pasif dinleyicilerin hiçbir veri yakalayamamasına ve cihazın çalışmadığı yanılgısına yol açmıştı.
Hataların kaydedilmesi: reverse engineering’in en önemli dersi
Bu projenin en önemli kazanımı, protokolün kendisinden çok, yapılan varsayımların ne kadar sık sorgulanması gerektiği oldu. Örneğin, erken bir aşamada bir Bluetooth analizörü, motosikletin karakteristiklerini bilinen bir dijital anahtar güvenlik spesifikasyonu olarak tanımladı. Bu, hemen not alınabilecek bir gerçek gibi görünse de, aslında sadece aracınUUID’ye dayalı tahmininden ibaretti. Gerçeklikse, basit bir üretici servisiydi.
Başka bir yanılgı da, motosikletin kendi SIM kartına sahip olduğu ve telemetri verilerini üretici bulutuna gönderdiği yönündeydi. Bu varsayım, veri kaynakları hakkında aylar boyunca yanlış bir yönlendirme yarattı. Ancak donanım incelemesiyle birlikte, motosiklette hiçbir SIM kartının olmadığı, tüm verilerin sadece eşleştirilmiş telefona aktarıldığı anlaşıldı.
Bu deneyim, reverse engineering sürecinin büyük ölçüde, erken varsayımlara karşı kendini sürekli sorgulama disiplininden geçtiğini gösterdi. Her varsayımın kaydedilmesi, yanlış çıkarımların tekrarlanmasını engelledi.
Kendi uygulamayı inşa etmek: REDLINE projesi
Protokol anlaşıldıktan sonra, sıra uygulamayı hayata geçirmeye geldi. REDLINE adlı bu uygulama, Kotlin ve Jetpack Compose kullanılarak geliştirildi. Temel işlevi, Google Haritalar’dan gelen navigasyon verilerini yakalayıp, bunları motosikletin gösterge paneline uygun formatta göndermekti. Böylece, kullanıcılar doğrudan Google Haritalar’ın navigasyonunu gösterge panelinde görüntüleyebiliyorlardı.
Uygulama ayrıca, motosikletten gelen telemetri verilerini okuyarak gerçek zamanlı bir gösterge paneli sunuyor, her sürüşü istatistikleriyle birlikte kaydediyor, hız grafikleri oluşturuyor, yolculukları dışa aktarabiliyor ve navigasyon aktif olmadığında dijital saati gösterge paneline aktarabiliyordu. Tüm bu özellikler, üreticiye ait herhangi bir bulut hizmetine veya kullanıcı hesabına ihtiyaç duymadan, sadece telefonda çalışıyordu.
Toplamda 14 bin satır kod, 205 test ve sürekli iyileştirmeyle geliştirilen REDLINE, protokol tersine mühendisliği sürecinin bir parçası olarak geliştirilen bir çerçeve de içeriyor. Bu sayede, protokolün sürekli olarak izlenmesi ve güncellenmesi mümkün hale geliyor.
Gerçek öğrenme: reverse engineering’in ötesinde
Protokolü çözmek, aslında projenin en basit kısmıydı. Asıl zorluk, yapılan tüm varsayımları sorgulamak ve sürekli olarak kendini doğruya yönlendirmekti. Bu disiplin, sadece reverse engineering için değil, günlük yazılım geliştirme süreçlerinde de hataların nerede olduğunu doğru tahmin etmek açısından son derece değerliydi.
Eğer bu projenin detaylarına, mesaj formatlarına, kullanılan araçlara ve yapılan varsayımlara dair daha fazla bilgi edinmek isterseniz, tüm süreci kapsayan ayrıntılı dökümantasyonu Arjun P’nin kişisel sitesinde bulabilirsiniz.
Geliştiriciler için, bu tür projeler sadece teknik bir merakın ötesine geçiyor. Aynı zamanda, donanım ve yazılım arasındaki sınırları zorlamanın, üreticilerin sunduğu sınırlı seçeneklerin ötesine geçmenin ve nihayetinde kullanıcı deneyimini kişiselleştirmenin bir yolu haline geliyor. Gelecekte, benzer yaklaşımların daha fazla cihazda ve daha geniş kullanım alanlarında karşımıza çıkmasını beklemek hiç de yanlış olmayacaktır.
Yapay zeka özeti
Motosikletinizin dijital gösterge panelini Google Haritalar’a bağlamak için Bluetooth protokolünü nasıl reverse engineer ettik? Adım adım reverse engineering süreci ve REDLINE uygulaması hakkında detaylar.
