La mia risposta qui è specifica per i comuni compilatori C / C ++, ma i principi alla base della risposta si generalizzano ad altri scenari.

Le differenze tra i compilatori si manifestano in molti modi, alcuni dei quali molto sottili. Se fosse strettamente una questione di attributi nell'intestazione dell'eseguibile, allora potremmo facilmente immaginare di riscrivere tale intestazione. Tuttavia, ogni compilatore ha il suo sapore unico di codice generato (e che varia a seconda del livello di ottimizzazione). Ogni compilatore ha la propria libreria standard predefinita (che spesso include stringhe rivelatrici) e un codice boilerplate predefinito diverso nel punto di ingresso dell'eseguibile. Ci sono altre differenze come: ottimizzazioni utilizzate in un compilatore che non vengono utilizzate in un altro; la convenzione di chiamata predefinita potrebbe differire; il codice generato per i prologhi delle funzioni è notevolmente diverso su gcc e MSVC (ad esempio); compilatori differenti hanno sequenze di codice e strutture dati differenti per la gestione delle eccezioni; e molti altri esempi. Direi che è praticamente impossibile camuffare quale compilatore ha prodotto un dato eseguibile.

Per rispondere alla tua prima domanda: No, non credo che ci siano opzioni del compilatore per compilatori popolari che ti consentono di impedire che aggiunga i suoi artefatti del compilatore.

Parte del problema in questo è esplorato dalla risposta di @ Syzygy: i compilatori generano, a volte, istruzioni molto diverse.

Più di questo, però, conoscere gli artefatti lasciati dai diversi compilatori ti consente di rendere difficile distinguere quale compilatore è stato utilizzato. Ad esempio, immagina di compilare il tuo eseguibile di Windows con mingw, ma poi aggiungervi un'intestazione RICH. Questo è un esempio artificioso, ma l'aggiunta di questo artefatto del compilatore MSVC all'output di mingw probabilmente confonderebbe alcuni strumenti automatici.

Molte delle risposte precedenti hanno notato che questo è impossibile perché il compilatore lascerà sempre artefatti. Ho deciso di fare un piccolo caso di studio utilizzando un programma su Linux, anche se l'idea è trasferibile.

Ad esempio, ho creato un piccolo "Hello World!" file in C:

  #include <stdio.h>int main (void) {put ("Hello World!"); return 0;}  

Poi l'ho compilato e ho usato hexdump -C sui risultati. Il seguente tranne identifica abbastanza chiaramente il compilatore!

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

In esecuzione strip -R .comment aiuta parzialmente e rimuove completamente la menzione esplicita di GCC, ma ci sono ancora alcuni segnali rivelatori:

  00000260 47 4e 55 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 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 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 | inizio __. Libc.so. | 00000330 36 00 70 75 74 73 00 5f 5f 6c 69 62 63 5f 73 74 | 6.puts .__ 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 | .bss ............ |  

Ho deciso di vedere cosa sarebbe succede se ho sostituito l'ultima parte di questo codice con byte nulli. Il programma funzionava ancora bene, ma questo riduce la portabilità ad altri sistemi operativi.

Se provi a sostituire GNU con un altro compilatore, ad esempio clang , funziona ancora bene. Sebbene possa confondere il reverse engineering, non è certo così difficile notarlo.

Infine, ho provato a vedere cosa succede se ho rimosso qualsiasi traccia di GLIBC...

  ./a.out: ./ a.out: nessuna informazione sulla versione disponibile (richiesta da ./a.out)./a.out: errore di rilocazione: ./a.out: simbolo, versione non definita nel file con riferimento all'ora del collegamento  

Risposta breve: no. Non conosco nessun compilatore che abbia un'opzione "modalità invisibile" e se avesse il risultato finale IMO sarebbe solo un'altra firma per lo stesso compilatore.

Come suggerisce @ omghai2u puoi modificare manualmente il binario e testarlo con strumenti automatici, ma non credo che sarà di grande aiuto.

Un approccio migliore sarebbe forse quello di utilizzare un packer / protector exe. Sebbene un RE esperto possa probabilmente decomprimerlo, significa comunque molto lavoro e conoscenza. Quindi almeno è una prima linea di difesa.

Puoi provare:

• Usare il strip e il comando sstrip per rimuovere alcune tracce.
• Per usare strane opzioni di compilation
• Per usare strane (come tcc) o vecchi compilatori
• Per usare alcuni pacchetti

Ma non esiste un proiettile d'argento. Forse dovresti interrogarti sull'aspetto perché della tua domanda invece che sul come