Soru:
Bir montaj kodundan değişkenler nasıl kurtarılır?
perror
2013-03-26 21:31:58 UTC
view on stackexchange narkive permalink

Bir montaj kodumuz olduğunu varsayarsak, orijinal üst düzey kodda kullanılan değişkenleri kurtarmak için kullanılabilecek bilinen teknikler nelerdir?

Düzenle : değişkenleri kurtarmak , değişken adlarını kurtarmayı kastetmiyorum, ancak yüksek seviyeli kodda bir değişkenle değiştirilebilecek geçici sonuçları depolamak için kullanılan bellek konumlarını belirlemeye çalışmak . Ayrıca, bayt kodlardan değil, tür bilgisi içermeyen gerçek ikili koddan veya içinde gömülü tam adlardan bahsetmiyorum.

Dört yanıtlar:
#1
+15
Igor Skochinsky
2013-03-27 05:49:06 UTC
view on stackexchange narkive permalink

(Bir yorum yapmayı planlıyordum ama oldukça uzun sürdü ve kendi kendine bir cevap veriyor)

Yorumlardan bazıları Hex-Rays kod çözücüsünden bahsetti. Temel fikirleri ticari bir sır değildir ve aslında Ilfak Guilfanov'un 2008'de sunumuna eşlik eden teknik incelemesinde açıklanmıştır.

İlgili kısmı buraya yapıştıracağım:

Yerel değişken tahsisi

Bu aşama, farklı temel bloklardan kayıtları yerel olarak dönüştürmek için veri akışı analizini kullanır. değişkenler. Bir kayıt bir blok tarafından tanımlanmışsa ve bir başkası tarafından kullanılıyorsa, hem tanımı hem de kullanımı kapsayan yerel bir değişken oluşturacağız. Başka bir deyişle, yerel bir değişken, tüm tanımlardan ve birbirine bağlanabilen tüm kullanımlardan oluşur. Temel fikir basit olsa da, bayt / kelime / dword kayıtları nedeniyle işler karmaşıklaşıyor.

Yüzeysel olarak basit ama tabii ki uygulama birçok ayrıntıyı hesaba katmalıdır. Ve her zaman iyileştirme için yer vardır. Şu pasaj var:

Şu an için canlı yığın değişken aralıklarını analiz etmiyoruz (bu öncelikle iyi bir takma ad analizi gerektirir: bir yığın değişkeninin olmadığını kanıtlayabilmeliyiz iki konum arasında değiştirildi). Yakın gelecekte yığın değişkenleri için tam teşekküllü bir canlı aralık analizinin mevcut olacağından şüpheliyim.

Dolayısıyla, yığın değişkenleri için şu anda yaklaşım basit: her yığın yuvası tek bir tüm işlev için değişken (bazı küçük istisnalar dışında). Derleyici, burada demontaj sırasında IDA tarafından yapılan işe dayanır; burada her erişim için bir komutla bir yığın yuvası oluşturulur.

Güncel sorunlardan biri, aynı değişken için birden çok isimdir. Örneğin, derleyici yığın varlığını bir kayıtta önbelleğe alabilir, onu bir işleve aktarabilir ve daha sonra başka bir kayda yeniden yükleyebilir. Derleyicinin burada karamsar olması gerekir. Aynı konumun aynı anda iki noktada aynı değeri içerdiğini kanıtlayamazsak, değişkenleri birleştiremeyiz. Örneğin, kod bir değişkenin adresini bir çağrıya ilettiğinde, kod çözücünün çağrının bu adresten sonraki her şeyi bozabileceğini varsayması gerekir. Bu nedenle, yazmaç hala yığın değişkeniyle aynı değeri içerse bile,% 100 emin olamayız. Böylece değişken isimlerin fazlası. Bununla birlikte, kullanıcı manuel haritalama ile bunu geçersiz kılabilir.

Bir işlevin argümanlarını tam olarak nasıl kullandığını ve / veya değiştirdiğini (Microsoft'un SAL'a benzer şekilde) belirleyen ve bu sorunu hafifletecek olan işlev ek açıklamalarının tanıtılması hakkında bazı fikirler vardır. , ancak orada bazı teknik uygulama sorunları var.

Tam da aradığım cevap türü, teşekkürler!
Yorumlar uzun tartışmalar için değildir; bu konuşma [sohbete taşındı] (https://chat.stackexchange.com/rooms/93469/discussion-on-answer-by-igor-skochinsky-how-to-recover-variables-from-an-assembl) .
#2
+9
Rolf Rolles
2013-03-27 04:33:39 UTC
view on stackexchange narkive permalink

Tarif ettiğiniz şey, Gogul Balakrishnan'ın değer-kümesi analizi üzerine yaptığı doktora çalışmasında [1] ele aldığı problemdir. Özellikle, x86 için "soyut konumlar" gibi kavramlar açısından bir bellek modeli tanımlar. İşte bu kavram için açıklaması:

Daha önce belirtildiği gibi, yürütülebilir dosyalar, analiz için kullanılabilen kaynak kod değişkenleri gibi içsel varlıklara sahip değildir; bu nedenle, sonraki adım değişken benzeri varlıkları yürütülebilir dosyadan kurtarmaktır. Bu tür değişken benzeri varlıklara a-loc'lar ("soyut konumlar" için) diyoruz.

Sorunuza tanıdık geliyor mu? Soyut yorumlamayla ilgili çoğu belge gibi, kısa ve dostça olmayan bir okuma olduğu konusunda uyarılmanıza rağmen bu tezi okumalısınız.

[1] http: //pages.cs.wisc. edu / ~ bgogul / Research / Thesis / thesis.html

#3
+8
endeavor
2013-03-26 22:00:06 UTC
view on stackexchange narkive permalink

Soo ..... bu, ikili analizin zor olmasının nedenlerinden biridir, anlamsal bilgi kaybı. Değişken bilgisayar mimarisinde bilinen bir kavram değildir, daha yüksek bir anlayış düzeyini anımsatır.

Size verebileceğim en iyi cevap, Derleyici Çıktı Analizi (ki sizsiniz), bu derleyici tarafından değişkenleri depolamak için kullanılan kuralları, muhtemelen yığın çerçevesindeki konumlara kayıtların ve değişken "dökülmenin" bir kombinasyonu olarak arayabilirsiniz.

Kötü haber şu ki derleyiciye bağlıdır. İyi haber şu ki, çoğu derleyicinin aşağı yukarı benzer olması.

Bir değeri oluşturan koşullu işlemleri gözlemleyerek imzalılığı belirlemeye çalışabilirsiniz (geliştiricinin böyle bir hata yapmadığını varsayarak işaretli ve işaretsiz bir değeri karşılaştırarak).

Güzel araştırma yolları veriyorsunuz, ancak bazı mevcut 'geçici' teknikler olmalı. Örneğin, [hex-rays Decompiler] (https://www.hex-rays.com/products/decompiler/) veya [boomerang] (http://boomerang.sourceforge.net/) 'de kullanılan teknikler nelerdir? Yığın çerçevesi içindeki değişkenleri tanımlıyor mu?
Hex-Rays decompiler değişken sınırlarını anlamakta oldukça zayıf. Basitçe, değişken olabilecek herhangi bir şeyin olduğunu varsayıyor gibi görünüyor. Bu, değişkenlerin sayısının çok fazla tahmin edilmesine yol açabilir. Temiz bir derleme ayrıştırması elde etmek için genellikle pek çok değişkeni takma ad olarak eşlemeniz gerekir. Yine de harika bir ürün. Igor muhtemelen çok daha fazlasını biliyor ama bu ticari sırlarla veya başka bir şeyle sınırlanabilir.
çaba: sadece derleyiciye bağlı değil. Çağrı kurallarını düşünün, bunlar mimari veya platform tarafından belirlenir.
@PeterAndersson: muhtemelen ifşa edecekleri bir şey olmayacaktır. Sanırım, herhangi birimizin bulabileceği şeylere ek olarak, Hex-Rays (şirket) muhtemelen her şeyi şu ya da bu olarak tanımlamak için bir sürü sezgisel tarama geliştirdi. Ve aynı fikirdeyim, derleyici eklentisinin betasını test ettikten sonra, hiç ikna olmadım. IDA'nın hiç olmadığı yerde beni çok yanılttı. Yine de, birkaç yıl oldu, ancak özel bir kişi olarak şu anda buna param yetmez;)
@0xC0000022L, decompiler harika. Bize çok zaman kazandırır. Sadece her şeyi yazarken ve haritalandırmada oldukça titiz olmalısın. Hala hatalar yapıyor ve bazen yanlış yönlendiriyor ama net bir pozitif.
#4
-2
samuirai
2013-03-26 22:02:40 UTC
view on stackexchange narkive permalink

Bir ikilinin içindeki dizelerle ilgili tatlı bir numara, dizeler komut satırı aracıdır. "Değişkenleri" aramadığını belirtmek önemli olabilir. Yalnızca sürekli geçerli karakterleri arar ve bunları yazdırır. Dolayısıyla bu, herhangi bir tür dosyadan dizeleri çıkarmak için de yararlıdır (açık metin olarak saklandığında).

Örnek program:

  int main (int argc, char * argv [ ]) {char pw [] = "GizliPW"; eğer (! strcmp (pw, argv [1])) {printf ("Doğru! \ n"); } else {printf ("Yanlış ... \ n"); } return 0;}  

Dizeleri çıkarmak için dize kullanma:

  $ ./test FalsePWFalse ... $ dizeler testSecretPWCorrect! False ... $ ./test SecretPW 139 ↵Doğru!  


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...