Ters mühendislik protokolleri hem eğlenceli hem de göz korkutucu bir görev olabilir. Herhangi bir özel ayrıntıya girmeden önce, yeni başlamanız için önereceğim birkaç işaret var.
Yapılacak şeyler:
- İyi bir paket dinleyicisi al.
Bağlantıları görmek için lütfen Giriş Yaptavsiye ederim, ancak aralarından seçim yapabileceğiniz birçok kişi var.
- Zaten belgelenmiş bir protokolu tersine mühendislik.
- Seçtiğiniz bir programlama dilinde soket kullanma alışkanlığı kazanın
- Şifreli protokoller. Bunlar yeni başlayanlar için oldukça zor olabilir ve bazı durumlarda bir süper bilgisayara erişmeden kırılması imkansız olabilir.
Bağlantıları görmek için lütfen
Giriş Yap
).Başlarken
İstemci ve sunucu arasındaki paket değişimlerini kaydederek başlayın. Burada aradığınız şey büyük ölçüde protokole ters mühendislik yapmak için gerçek amacınıza bağlıdır. Bu durumda, mevcut istemci yazılımının işlevlerini tamamen kopyalayan kendi istemci kitaplığınızı oluşturmak istediğinizi varsayarım. Belgelenmemiş protokollerle çalışırken çok fazla tahminle sonuçlanırsınız. Tahmin edilen bazı çalışmaların hafifletilmesine yardımcı olmak için yapılacak iyi bir adım, müşterinizin analiz edip kontrol edebileceğiniz tekrar verileri oluşturmasını sağlamaktır. Başka bir deyişle: Aynı eylemi tekrar tekrar gerçekleştirin ve verilerdeki bir deseni veya benzerlikleri tanımlayıp tanımlayamayacağınızı görmek için paket günlüğüne bakın.
Bu eğitimin amacı için IRC protokolünü kullanacağım.
IRC protokolü durumunda, bir kanala mesaj göndermenin sadece paket içerisindeki içeriği değil, aynı zamanda gönderildiği frekansı da kontrol edebileceğinizden başlamak için iyi bir yer olacağını düşünüyorum.
Veri
İşte, Quakenet'teki #sometestchannel kanalında birkaç kez "bu bir test mesajı" gönderdiğim örnek bir paket günlüğü. Aşağıda baktığınız, istemcinin sunucuya karşılık gelen "ham" eşdeğerini gönderen baytların onaltılık bir temsilidir. Çoğu özel protokolde, veriler ASCII'ye (veya başka bir metin kodlamasına) gönderildiğinde genellikle bir çöp dizisinde olduğu gibi bir dizi bayt olarak kodlanır. Neyse ki IRC protokolü, verileri analiz etmeyi çok daha kolay hale getiren düz metindir. Not ^ 1'e bakınız.
Verilerin Kalıplarını Belirleme
Yukarıdaki paket dökümünden gelen hex veya raw verilerine baktığımızda bir model belirleyebiliriz. Desen aşağıdaki gibi yapılabilir:
PRIVMSG [channel_name] :[message]
Türkçe Çeviri: Bir kanala gönderilen her mesaj PRIVMSG ve ardından bir boşluk ile başlar. Bunu kanalın adı takip eder, ardından bir boşluk izler ve ardından bir kolonun önlediği kanala mesaj takip eder.
Ancak, bizim "desen "imizde tam olarak temsil etmediğimizi gördüğümüz başka bir bilgi parçası var. Hex çıktısına veya "ham" çıktıya baktığımızda ".." ile biten her bir mesajı görürüz. Bunun anlamı ne olabilir? . karakter, paket editörü tarafından karşılık gelen bir "ham" görüntü karakterine sahip olmayan karakterler için bir yer tutucu olarak kullanılır (bu durumda ASCII kodlamasını kullanıyorum). Bu durumda, 0x0D ve 0x0A karakterleri, paket editörünün mesajın bir parçası olduklarını göstermek için orada bir yer tutucuyu yapıştırmadığı takdirde "boş" görünecektir. 0x0D 0x0A nedir ve kalıbımız için nasıl önemlidir?
Üstbilgiler ve Sonlandırıcılar
Çoğu protokoller kolay ayrılması için kullanılabilecek bir şekilde ya da başka bir başlık, terminatör, ya da her ikisi de sahip olma eğilimi / diğer şeylerin yanı sıra paket ayrıştırma Bkz Not 2. İngilizce dil gibi bir şey olarak düşünmek. Hepimiz, İngilizce dilinin kalıbının şu şekilde çalıştığına karar verdik:
[Captial Letter][Sentence Body][Punctuation]
Bir anlamda, her bir cümlenin başlayacağı “Büyük harf”, “başlık” olarak düşünülebilir. Bu durumda her 'başlık' birbirinden farklı olsa da, bir cümlenin başlangıcını bulmayı kolaylaştıran bir tür standartlaşmanın izlenmesidir. Diğer taraftan bir 'sonlandırma', isminin ima ettiği gibi bir şeydir: Bir şeyin nerede bittiğini gösterir. İngilizce dilinde noktalama işaretleri. ! ve ? "terminatör" olarak kabul edilebilir.
Bir başlık veya sonlandırıcı ararken, tüm paketlerin başlangıçta veya sonda ortak bir şey paylaşıp paylaşmadığını görmek gerekir. IRC "chat send" paketinin sonunda 0x0D 0x0A'da yukarıda bakıyorduk. Bu bir çeşit pakete özgü anormallik olabilir mi? Yoksa bu daha mı? İstemcimizin sunucuya birkaç farklı paket paketi göndermesini ve bulduğumuz şeyi görelim:
4a 4f 49 4e 20 23 61 6e 6f 74 68 65 72 74 65 73 JOIN #anothertes
74 63 68 61 6e 6e 65 6c 0d 0a tchannel..
4d 4f 44 45 20 23 61 6e 6f 74 68 65 72 74 65 73 MODE #anothertes
74 63 68 61 6e 6e 65 6c 0d 0a tchannel..
57 48 4f 20 23 61 6e 6f 74 68 65 72 74 65 73 74 WHO #anothertest
63 68 61 6e 6e 65 6c 0d 0a channel..
Yukarıdaki paketler hakkında fazla ayrıntıya girmeden (tahmin edebileceğinize eminim) bir trend fark edebiliriz: 0x0D 0x0A modeli bu paketlerin sonunda da ortaya çıkıyor. Bu muhtemelen, en azından bir IRC istemcisinden gönderilen paketlerin 0x0D 0x0A ile sonlandırılması gerektiği anlamına gelir.
Bildiklerimizi yeniden gözden geçirme
Sohbet paketimize geri dönecek olursak orjinal olarak paketin modelini şöyle belirttik:
PRIVMSG [channel_name] :[message]
Başlangıçtaki fikrimiz neredeyse doğru olsa da, önemli bir parça eksikti: Terminatör. Baktığımız diğer paketlere dayanarak, artık istemciden sunucuya gönderilen paketlerin 0x0D 0x0A ile sonlandırılması gerektiğini biliyoruz. Bu nedenle yukarıdaki paketi aşağıdaki gibi gözden geçirebiliriz:
PRIVMSG [channel_name] :[message][client_terminator]
Şimdi IRC protokolüne aşina olduğunuz bazılarınız "Peki neden 0x0D 0x0A'yı bir istemci sonlandırıcısını değil, bir paket sonlandırıcısını çağırıyoruz?" Diyebilir. Bu haliyle, sadece istemciden sunucuya gönderilen verilere baktık. Sunucudan istemciye gönderilen verilere henüz bakmadık. Bir kere baktığımızda, ya tüm IRC paketleri için standart bir sonlandırıcı (ya da sadece [terminatör] olarak adlandırılabilir) ya da sadece müşteriye özgü bir şey olabilir.
Neyse. Yorgunum. Saat 06:30 EDT. Muhtemelen yukarıdaki yazılarda bazı küçük yanlışlıklar ve yazım hataları vardır, ama umarım sizi veya başkasını ters mühendislik protokollerinde başlatmaya yetecek kadardır. Bu eğiticiye devam edecekseniz ve IRC protokolü ile çalışıyor olsaydınız esasen yukarıdaki adımları tekrarlamanız gerekirdi (hem istemci hem de sunucu paketleri için). Eninde sonunda, paketlerdeki kalıpları, gelecekte olabilecek paketleri, içinde bulundukları biçim açısından tahmin edilebilir kılacak şekilde fark etmeye başlayacaksınız. Her paketin işlevselliğini anlamanın ötesinde (ve sunucunun buna nasıl tepki verdiği) gerçekten hepsi sol, söz konusu protokolü bir tür kullanılabilir kütüphaneye uygulamak için kod yazıyor. Yıllardır bunu yapan biri olarak, yazılımınızı bazı özel şeytan sunucu (evet, şeytan) ile çalışırken görmek hem heyecan verici hem de eğlenceli olabilir. Kuşkusuz ki, ülkenizdeki yasaları tersine mühendislik özel protokolleri olarak kontrol etmeme rağmen, söz konusu protokollerle çalışan yazılımlar her türlü hukuki soruna yol açabilir. Sadece BnetD veya OdinMS'ye sorun.
Notlar:
- Tüm protokollerle aynı eylemleri yapmaktan her zaman aynı sonuçları garanti etmeyeceksiniz. Bazı protokoller, birbirine benzemeyen paketler oluşturmak için% 100 aynı eylemlere neden olacak çeşitli kodlama veya şifreleme biçimlerini kullanırlar.
- Başlıklar ve sonlandırıcılar her zaman sabit bir şey olmak zorunda değildir. Paketlerin farklı "türleri" nin farklı bir başlık ile başladığı pek çok protokol görmüştüm ve standart bir üstbilgiye sahip olan ve ardından paket tipi, uzunluk vb. Gibi bilgileri izleyen başkaları da görüyorum. Sonlandırıcılar da bazı durumlarda değişiklik gösterebilir. Tüm paketlerin birkaç seçim paketi dışında bir sonlandırıcı tarafından sonlandırılması gerektiği durumlar gördüm. Ne yazık ki çoğu durumda, deneme ve hata, belgesiz / özel protokollerle çalışmaya geldiğinde sahip olduğunuz en iyi yaklaşımdır.
- (Yukarıda belirtilen not 3 yok) Ben soket tabanlı herhangi bir kod girmedim. Bunu nasıl yapacağınızı biliyorsunuz varsayımım var ve eğer değilse de okuyucu için bir egzersiz olarak bırakılacak.
Kaynak : Forum kuralları gereği kaynak belirtilememektedir. Kaynakta emeği geçen ve Tecrübelerini bizimle paylaştığı için teşekkürler.
Son düzenleme:
