Soru:
Hangi derleyicinin kullanıldığının ayrıntılarını gizlemek mümkün müdür?
asheeshr
2013-03-23 08:47:10 UTC
view on stackexchange narkive permalink

Derleyici, derlemede oluşturulan çıktı / nesne dosyasına sistem bilgilerini ekler.

  • Bu bilgilerin eklenmesini engelleyebilecek herhangi bir derleyici seçeneği var mı?
  • Kullanılan derleyicinin tespitini zor / olanaksız kılmak için derleyici imzası tamamen kaldırılabilir mi?
Ben ayrılıyorum. [Bu sorunun] * tam * bir kopyası değil (http://reverseengineering.stackexchange.com/questions/11) ama pek çok ortak zemin var ve cevaplar neredeyse aynı olacak ...
@IgorSkochinsky,, yanılıyorsam beni düzeltir, ancak başvurduğunuz sorudaki yanıtların hiçbiri derleyici özelliklerinin nasıl kaldırılacağını veya gizleneceğini tartışmaz, bunun yerine var olduklarını tartışmaz.
Beş yanıtlar:
#1
+8
Rolf Rolles
2013-03-23 12:34:21 UTC
view on stackexchange narkive permalink

Buradaki cevabım genel C / C ++ derleyicilerine özeldir, ancak cevabın arkasındaki ilkeler diğer senaryolara genelleşir.

Derleyici farklılıkları, bazıları çok ince olmak üzere birçok şekilde kendini gösterir. Yürütülebilir başlıktaki bir öznitelik meselesi olsaydı, söz konusu başlığı yeniden yazdığımızı kolayca hayal edebilirdik. Bununla birlikte, her derleyicinin kendi benzersiz ürettiği kod çeşidi vardır (ve bu, optimizasyon düzeyine bağlı olarak değişir). Her derleyicinin kendi varsayılan standart kitaplığı (genellikle anlatılan dizeleri içerir) ve yürütülebilir dosyanın giriş noktasında farklı varsayılan ortak kodlar vardır. Aşağıdakiler gibi başka farklılıklar da vardır: bir derleyicide kullanılan, diğerinde kullanılmayan optimizasyonlar; varsayılan arama kuralı farklı olabilir; işlev prologları için oluşturulan kod, gcc ve MSVC'de belirgin şekilde farklıdır (örneğin); farklı derleyiciler, istisna işleme için farklı kod dizilerine ve veri yapılarına sahiptir; ve daha birçok örnek. Belirli bir yürütülebilir dosyayı hangi derleyicinin ürettiğini gizlemenin neredeyse imkansız olduğunu söyleyebilirim.

#2
+4
omghai2u
2013-03-23 14:04:30 UTC
view on stackexchange narkive permalink

İlk sorunuza cevap vermek gerekirse: Hayır, popüler derleyiciler için derleyici yapılarını eklemenizi engelleyebilecek herhangi bir derleyici seçeneği olduğunu sanmıyorum.

Buradaki sorunun bir kısmı @ Syzygy'nin cevabı ile keşfedildi: derleyiciler bazen çok farklı talimatlar üretir.

Bundan daha fazlası, farklı derleyiciler tarafından geride bırakılan yapıları bilmek, hangi derleyicinin kullanıldığını ayırt etmeyi zorlaştırmanıza yardımcı olur. Örneğin, Windows çalıştırılabilir dosyanızı mingw ile derlediğinizi, ancak daha sonra ona bir RICH başlığı eklediğinizi hayal edin. Bu uydurma bir örnektir, ancak MSVC derleyicisinin bu yapıtını mingw çıktısına eklemek muhtemelen bazı otomatik araçların kafasını karıştıracaktır.

#3
+4
George V. Williams
2013-03-29 23:06:40 UTC
view on stackexchange narkive permalink

Önceki yanıtların çoğu, derleyicinin her zaman yapıları geride bırakacağı için bunun imkansız olduğunu belirtmiştir. Fikir aktarılabilir olsa da, Linux'ta bir program kullanarak küçük bir vaka çalışması yapmaya karar verdim.

Örneğin, küçük bir "Merhaba Dünya!" C dosyasında:

  #include <stdio.h>int main (void) {puts ("Merhaba Dünya!"); return 0;}  

Sonra onu derledim ve sonuçlarda hexdump -C kullandım. Aşağıdakiler hariç, derleyiciyi oldukça açık bir şekilde tanımlar!

  00001020 47 43 43 3a 20 28 55 62 75 6e 74 75 2f 4c 69 6e | GCC: (Ubuntu / Lin | 00001030 61 72 6f 20 34 2e 36 2e 33 2d 31 75 62 75 6e 74 | aro 4.6.3-1ubunt | 00001040 75 35 29 20 34 2e 36 2e 33 00 00 2e 73 79 6d 74 | u5) 4.6.3 ... symt | 00001050 61 62 00 2e 73 74 72 74 61 62 00 2e 73 68 73 74 | ab..strtab..shst | 00001060 72 74 61 62 00 2e 69 6e 74 65 72 70 00 2e 6e 6f | rtab..interp..no | 00001070 74 65 2e 41 42 49 2d 74 61 67 00 2e 6e 6f 74 65 | te.ABI-tag..note | 00001080 2e 67 6e 75 2e 62 75 69 6c 64 2d 69 64 00 2e 67 | .gnu.build-id ..g | 00001090 6e 75 2e 68 61 73 68 00 2e 64 79 6e 73 79 6d 00 | nu.hash..dynsym. | 000010a0 2e 64 79 6e 73 74 72 00 2e 67 6e 75 2e 76 65 72 | .dynstr ..gnu.ver | 000010b0 73 69 6f 6e 00 2e 67 6e 75 2e 76 65 72 73 69 6f | sion..gnu.versio | 000010c0 6e 5f 72 00 2e 72 65 6c 61 2e 64 79 6e 00 2e 72 | n_r ..rela.dyn..r | 000010d0 65 6c 61 2e 70 6c 74 00 2e 69 6e 69 74 00 2e 74 | ela.pl t..init..t | 000010e0 65 78 74 00 2e 66 69 6e 69 00 2e 72 6f 64 61 74 | ext..fini..rodat | 000010f0 61 00 2e 65 68 5f 66 72 61 6d 65 5f 68 64 72 00 | a..eh_frame_hdr. | 00001100 2e 65 68 5f 66 72 61 6d 65 00 2e 63 74 6f 72 73 | .eh_frame..ctors | 00001110 00 2e 64 74 6f 72 73 00 2e 6a 63 72 00 2e 64 79 | ..dtors..jcr..dy | 00001120 6e 61 6d 69 63 00 2e 67 6f 74 00 2e 67 6f 74 2e | namic..got..got. | 00001130 70 6c 74 00 2e 64 61 74 61 00 2e 62 73 73 00 2e | plt..data..bss .. |
00001140 63 6f 6d 6d 65 6e 74 00 00 00 00 00 00 00 00 00 | comment ......... |  

strip -R .comment kısmen yardımcı olur ve GCC'nin açıkça belirtilmesini tamamen ortadan kaldırır, ancak yine de bazı anlatım işaretleri vardır:

  00000260 47 4e 55 00 00 00 00 00 00 02 00 00 00 06 00 00 00 | GNU ............. | 00000270 18 00 00 00 04 00 00 00 14 00 00 00 00 03 00 00 00 | ............... . | 00000280 47 4e 55 00 5f 8a 1b 97 01 5a ac d7 93 fb 96 29 | GNU ._.... Z .....) | * * * 00000310 00 00 00 00 00 00 00 00 00 00 5f 5f 67 6d 6f 6e 5f | .........__ gmon_ | 00000320 73 74 61 72 74 5f 5f 00 6c 69 62 63 2e 73 6f 2e | start __. Libc.so. | 00000330 36 00 70 75 74 73 00 5f 5f 6c 69 62 63 5f 73 74 | 6. çıktılar .__ libc_st | 00000340 61 72 74 5f 6d 61 69 6e 00 47 4c 49 42 43 5f 32 | art_main.GLIBC_2 | 00000350 2e 32 2e 35 00 00 00 00 02 00 02 00 00 00 00 00 | .2.5 ............ | * * * 00001020 00 2e 73 68 73 74 72 74 61 62 00 2e 69 6e 74 65 | ..shstrtab..inte | 00001030 72 70 00 2e 6e 6f 74 65 2e 41 42 49 2d 74 61 67 | rp..note.ABI-tag | 00001040 00 2e 6e 6f 74 65 2e 67 6e 75 2e 62 75 69 6c 64 | ..note.gnu.build | 00001050 2d 69 64 00 2e 67 6e 75 2e 68 61 73 68 00 2e 64 | -id..gnu.hash..d | 00001060 79 6e 73 79 6d 00 2e 64 79 6e 73 74 72 00 2e 67 | ynsym..dynstr..g | 00001070 6e 75 2e 76 65 72 73 69 6f 6e 00 2e 67 6e 75 2e | nu.version..gnu. | 00001080 76 65 72 73 69 6f 6e 5f 72 00 2e 72 65 6c 61 2e | version_r..rela. | 00001090 64 79 6e 00 2e 72 65 6c 61 2e 70 6c 74 00 2e 69 | dyn..rela.plt..i | 000010a0 6e 69 74 00 2e 74 65 78 74 00 2e 66 69 6e 69 00 | nit..text. .fini. | 000010b0 2e 72 6f 64 61 74 61 00 2e 65 68 5f 66 72 61 6d | .rodata..eh_fram | 000010c0 65 5f 68 64 72 00 2e 65 68 5f 66 72 61 6d 65 00 | e_hdr..eh_frame . | 000010d0 2e 63 74 6f 72 73 00 2e 64 74 6f 72 73 00 2e 6a | .ctors..dtors..j | 000010e0 63 72 00 2e 64 79 6e 61 6d 69 63 00 2e 67 6f 74 | cr .. dynamic..got | 000010f0 00 2e 67 6f 74 2e 70 6c 74 00 2e 64 61 74 61 00 | ..got.plt..data. |
00001100 2e 62 73 73 00 00 00 00 00 00 00 00 00 00 00 00 00 | .bss ............ |  

Ne olacağını görmeye karar verdim bu kodun son bölümünü boş baytlarla değiştirirsem olur. Program hala iyi çalıştı, ancak bu diğer işletim sistemlerine taşınabilirliği azaltır.

GNU 'u başka bir derleyiciyle değiştirmeye çalışırsanız, örneğin clang , hala iyi çalışıyor. Tersine mühendisi karıştırsa da, fark etmesi kesinlikle o kadar da zor değil.

Son olarak, herhangi bir GLIBC...

  ./a.out: ./ izini kaldırırsam ne olacağını görmeye çalıştım. a.out: sürüm bilgisi mevcut değil (./a.out tarafından gerekli) ./a.out: yeniden konumlandırma hatası: ./a.out: sembol, bağlantı süresi referanslı dosyada tanımlanmamış sürüm  
"yapılar" yalnızca dizeleri içermez. Tüm dizeleri kaldırsanız bile, kod kalır ve çoğu zaman kesinlikle kullanılan derleyiciye işaret edebilir.
Bulguların ilginç olsa da Igor haklı. Bu sadece dizelerle ilgili değil, aynı zamanda derleyicinin son ikilinize eklediği kod bölümleri. Tersine mühendislik yapmalı ve tüm özellikleri tamamen kaldırana kadar talimatları talimatla yeniden tanımlamalısınız. Programınızın başka bir sürümünü oluşturmaya çalışın, ancak puts () use yani scanf () yerine, ortak bazı özellikleri olduğunu fark edeceksiniz.
#4
+2
Remko
2013-03-23 14:58:18 UTC
view on stackexchange narkive permalink

Kısa cevap: hayır. "Gizli kip" anahtarına sahip herhangi bir derleyici bilmiyorum ve eğer son sonuca sahip olsaydı, IMO aynı derleyici için başka bir imza olurdu.

@ omghai2u'nun manuel olarak değiştirmenizi önerdiği gibi ikiliyi kullanın ve otomatik araçlara karşı test edin, ancak bunun pek yardımcı olacağını düşünmüyorum.

Daha iyi bir yaklaşım, bir exe paketleyici / koruyucu kullanmak olabilir. Deneyimli bir RE muhtemelen paketini açabilse de, yine de çok fazla çalışma ve bilgi demektir. Yani en azından bu bir birinci savunma hattı.

Böylece o exe'yi paketler, paketini açarsınız ve çoğu durumda orijinal derleyici eserleriyle kalırsınız. Yanlış derleyici yapılarını ekleyerek, yeterince ve doğru yapılırsa, hangi derleyicinin gerçekten kullanıldığını belirlemeyi imkansız hale getirmelidir. RE savunmasının ilk hattı toparlanmaktır, elbette belki (kişisel olarak katılmıyorum); ama kesinlikle derleyici imzasını analizden saklamayın.
#5
+1
jvoisin
2013-07-16 01:06:45 UTC
view on stackexchange narkive permalink

Şunları deneyebilirsiniz:

  • Bazı izleri kaldırmak için strip ve sstrip komutunu kullanmak.
  • Tuhaf derleme seçeneklerini kullanmak için
  • Tuhaf ( tcc gibi) veya eski derleyiciler kullanmak
  • Bazı paketleyicileri kullanmak

Ama gümüş kurşun yok. Belki de sorunuzun nasıl

yerine neden yönü hakkında kendinizi sorgulamalısınız.
Bahsettiğiniz [ElfKickers] 'dan (https://github.com/BR903/ELFkickers) "sstrip" mi? (Debian'ım için bir paket bulamadığım için)
Evet öyle. Ancak Debian'a dahil edilmesini sağlamak için bir bilet açabilirsiniz;)
Bunu kendim için derleyebilirim, paket gerekmez. ;-)


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