Soru:
C ++ ikili dosyalarının statik analizi
user1354557
2013-03-20 23:09:55 UTC
view on stackexchange narkive permalink

Tersine mühendislik ikili dosyaları C ++ 'dan derlendiğinde, vtables' ta işlev işaretçilerine yönelik birçok dolaylı çağrının görülmesi yaygındır. Bu çağrıların nereye gittiğini belirlemek için, sanal işlevlerde this işaretçisinin beklediği nesne türlerinin her zaman bilinmesi ve bazen bir sınıf hiyerarşisinin haritasını çıkarması gerekir.

Statik analiz bağlamında, sökme işleminizde sanal işlevlerin izlenmesini kolaylaştırmak için hangi araçları veya açıklama tekniklerini kullanıyorsunuz? Tüm statik analiz araç kitlerine yönelik çözümlere açığız.

Bir cevap:
#1
+24
Igor Skochinsky
2013-03-21 00:49:02 UTC
view on stackexchange narkive permalink

2011'de Recon'da ("Practical C ++ Decompilation") tam da bu konu üzerine bir konuşma yaptım. Slaytlar ve video ( yansıtma) mevcuttur.

Temel yaklaşım basittir: sınıfları yapılar ve tablolar olarak temsil edin işlev işaretçilerinin yapıları olarak. Aynı hiyerarşideki sınıflar için kalıtımı ve farklı vtable'ları yönetmenize izin veren bazı püf noktaları var. Bu hileler bu blogda da açıklanmıştır; Konuşmama mı yoksa bağımsız bir çalışmaya mı dayandığından emin değilim.

Yaptığım bir diğer şey de uygulamanın adresiyle vtable yapısındaki her yuvaya tekrarlanabilir bir yorum eklemek. Bu, yapıyı vtable slot yüküne uyguladığınızda hızlı bir şekilde uygulamaya geçmenizi sağlar:

enter image description here

Bununla ilgili sorular: 1) Başvurulan vtable belirlenmemişse dolaylı çağrılara (kişisel olarak) nasıl açıklama eklersiniz? (daha spesifik olarak, çağrı için birden fazla olası hedef adres olduğunda?) 2) Sınıf yapılarınızı amaçlarını belirlemeden önce (kişisel olarak) nasıl adlandırırsınız ve bunları değiştirmeden önce geçici adlarının veritabanında ne kadar yayılmasına izin verirsiniz? ?
Ben (genellikle) gerçek vtable örneği başına bir vtable yapısı oluştururum, böylece adresler her zaman gerçek uygulamaya işaret eder. Ancak hiçbir şey, yoruma birkaç adres eklemenizi engellemez. İsimlendirmeye gelince, gerçekten sabit bir kural setim yok, Macarca, CamelCase ve undescored_words'ü tek bir veritabanında karıştırabilirim. Öğeleri yeniden adlandırmak can sıkıcıdır, bu nedenle sınıfın ne yaptığından (veya RTTI veya hata ayıklama bilgisine sahip oluncaya) makul ölçüde emin olana kadar genellikle sınıfları ve yöntemleri yeniden adlandırmayı ertelerim.
Mükemmel. İkinci soru ile ilgili olarak, geçici isimler üretmek ve kullanmak için sistematik bir yolunuz olup olmadığını soruyordum. Bağlamsal bilginin yokluğunda, yaptığım şey sınıf için "rastgele" üç karakterli bir fonetik isim seçmektir. Bu geçici ad yorumlara, işlev adlarına, yapı üyelerine, değişken adlarına vb. Yayıldığından, her zaman yeniden adlandırmakla uğraşmayacağım, ancak bunun yerine Not Defteri alt görünümünde sınıfın gerçekte ne olduğunu açıklayan bir not alacağım.


Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...