Soru:
Gcc kullanarak tersine mühendislik uygulanamayan bir nesne dosyası oluşturabilir miyim?
asheeshr
2013-03-20 14:43:12 UTC
view on stackexchange narkive permalink

gcc kullanarak kaynak koduna tersine mühendislik uygulanamayan bir nesne dosyası oluşturmak mümkün müdür?

bir makine okuyabiliyorsa ... insan da okuyabilir. bunu insan için daha zor hale getirebilirsiniz ... ama sonunda, okuyabilirler / okuyacaklar.
http://stackoverflow.com/questions/4111808/c-c-compiler-generating-obfuscated-code , http://stackoverflow.com/questions/1025494/obfuscating-c-c-code
üç yanıtlar:
#1
+25
Mike
2013-03-20 17:42:14 UTC
view on stackexchange narkive permalink

AFAIK bu mümkün değil. Ancak aklınızda tutabileceğiniz başka şeyler de var:

GCC optimizasyon bayraklarının kullanılması, kodun bir insan için çok daha az okunabilir görünmesine yardımcı olacaktır. En yüksek düzeyde optimizasyon gcc -O3 ile derlediğinizde, derleyici her şeyi "akış" beklediğiniz gibi olmayacak şekilde hareket ettirecektir.

Ayrıca gcc'yi küçük işlevler almaya ve bunları satır içi yapmaya zorlayacak -static bayrağını da kullanabilirsiniz. Bu onları işlev çağrıları olarak göstermek yerine kodunuza yerleştirir .. ayırt etmelerini zorlaştırır.

Unutulmaması gereken bir şey de gereksiz sembollerden kurtulmanın çok önemli olduğudur. Gcc, bu konuda yardımcı olmak için -fvisibility = hidden ve -fvisibility-inlines-hidden seçeneklerini sunar. Simgeleri ortadan kaldırmak için -s bayrağını gcc'ye de iletebilirsiniz.

Tersini önlemeye yardımcı olmak için gcc ile yapabileceğiniz tek şey bu kadar. mühendislik. Ek olarak, kod gizlemeyi de kullanabilirsiniz, ancak bunu kendiniz uygulamadığınız sürece orada da sorunlar vardır, tersine mühendisliği önlemek için hazır bir yöntem veya araç kullanıyorsanız, muhtemelen buna karşı koyacak bir araç vardır.

Son çalıştırılabilir dosyanın içinde olduğu gibi gcc'nin hangi sürümüyle derlendiği gibi bilgiler içereceğini unutmayın. Bu da strip komutuyla kaldırılabilir.

Çalıştırılabilir bir dosyam varsa ( myprog ), bazı bilgileri kontrol etmek için objdump çalıştırabilirim:

  mike @ mike-VirtualBox: ~ / C $ objdump --tam içerik --section = .comment myprog | headmyprog: dosya formatı elf64-x86-64 

Hay aksi, hangi sürümü / derleyiciyi kullandığımı görebilirsiniz. Bunu düzeltebiliriz:

  mike @ mike-VirtualBox: ~ / C $ strip -R .comment -R .note myprogmike @ mike-VirtualBox: ~ / C $ objdump --full-content --section = .comment myprog | headobjdump: -j seçeneğinde belirtilen, ancak herhangi bir girişte bulunmayan '.comment' bölümü filemyprog: file format elf64-x86-64  

Çıkarabileceğiniz başka kısımlar da vardır, .note.ABI-tag gibi ancak taşınabilirliği kaybedersiniz

Çalıştırılabilir dosyanın FreeBSD veya Linux öykünme desteği olan başka bir işletim sisteminde çalıştırılmasını engelleyeceği için ".note.ABI-tag" 'in çıkarılmasını önermem.
@IgorSkochinsky - taşınabilirlik için iyi bir not, o zamanlar bunu düşünmüyordum, ama şimdi güncelledim. Teşekkürler.
Çıkarma, GCC sürümünü obj dosyasından kaldırmaz ...
@Mellowcandle - Yaptığını söylemedim. Çalıştırılabilir dosyadan kaldırdığını söyledim.
BTW, değişken isimleriyle ilgili tavsiyenin neden olduğundan emin değilim. Eğer bunu düzgün bir şekilde yaparsanız, son ikili dosyada muhtemelen herkese açık olarak dışa aktarılanlar dışında * hiç * değişken adı olmamalıdır ve bunların genellikle uygun, okunabilir adlara sahip olması gerekir.
Igor haklı. İkili nesne oluşturulduğunda bu isimler derleyici tarafından yok edilmelidir. Bu durumda hiçbir fark yoktur. İkilileri içinde ağır hizmet hata ayıklama sembolleri ile gönderdiğiniz durumda, değişkenlerinize adlandırdığınızdan çok daha büyük sorunlarınız var.
Değişken isimleriyle ilgili cevabınızı güncellemelisiniz çünkü bu, soyulmuş bir ikili dosyada bir fark yaratmaz.
#2
+21
perror
2013-03-20 14:56:04 UTC
view on stackexchange narkive permalink

Kısa cevap : Hayır.

Uzun cevap : Programların (Im) Şaşırtma Olasılığı Üzerine Boaz Barak, Oded Goldreich, Rusell Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan ve Ke Yang.

Orta yanıt : Programınızı platformu kontrol eden bir kullanıcıya verirseniz programınızın yürütüleceği yerde, onun tersine mühendisliğini engellemenin bir yolu yoktur. Umut edebileceğiniz tek şey, kullanıcıyı yazılımınızın kara kutu analizi yaklaşımına zorlamaktır (bu, kullanıcının programınızın çıktısını yalnızca seçilen girdi üzerinde gözlemleyebileceği anlamına gelir).

Ancak, bu kara kutu analizini bile ek bir donanım parçası (örn. Akıllı kart) olmadan uygulamak son derece zordur, çünkü kullanıcının programınızın yürütülmesi sırasında belleğin ara anlık görüntülerini alabilmesi gerekir.

Ek olarak Donanım Güvenliği ile ilgili: Google "Silikonda sır yoktur"
Unutma ki bir noktada lanet olası şeyde de hata ayıklaman gerekecek. İkilinizi ne kadar çok şaşırtır ve yeniden düzenlerseniz, sahada bir şeyler ters giderse analiz etmek o kadar zor olacaktır. Örtülü olmayan bir sürüm mükemmel çalışıyorsa, ancak öngörülemeyen zamanlama veya gizlemenin kendisi tarafından sunulan diğer etkileşimler nedeniyle gizlenmiş sürüm BSOD'leri özellikle trixy olur.
#3
+8
Igor Skochinsky
2013-03-20 15:13:15 UTC
view on stackexchange narkive permalink

Dosyayı tam olarak orijinal kaynak koduna RE yapmak imkansız olabilir (örneğin, yorumları veya önişlemci makrolarını kurtarmanın bir yolu yoktur), ancak muhtemelen sormak istediğiniz şey bu değildir.

Derlenen kodla aynı şekilde davranan eşdeğer bir kaynak kodu üretmek kesinlikle her zaman mümkündür (bazen zor olsa da). Biraz fazladan çalışmayla, tam olarak aynı bayt kodunu derleyen kod üretmek bile mümkün olabilir (derlenmiş ikili için ek bir son işlem olmadığı sürece). Bu sunum bunun için bazı yaklaşımları açıkladı, ancak slaytları bulamıyorum.



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