Come aprire un file EXE che è fatto con la programmazione C in VS Code

Cosa intendi per "aprire".
Dove è fatto il file exe non importa. Ciò che importa è il compilatore o lo strumento per generare l'exe.
Ad ogni modo, sotto Windows il file exe ha i seguenti dati incorporati:

• Codice eseguibile
• Data - dati personalizzati usati dall'eseguibile
• Risorse - icone, bitmap, ecc
• Informazioni di debug - le informazioni di debug sono incorporate solo nella build di debug e rimosse (spostate nel file pdb) nelle build di rilascio

Partiamo dal basso. Le informazioni di debug sono usate per il debug e contengono varie informazioni come simboli (posizione di funzioni, variabili), connessione tra il numero di linea del file sorgente e il codice eseguibile, ecc. Esistono diversi formati e sono leggibili dai debugger. Per esempio WinDbg (debugger gratuito di Windows e molto potente) leggerà queste informazioni e vi permetterà il debugging a livello di sorgente, ecc. Ogni compilatore ha anche strumenti CLI per esportare le informazioni di debug in vari formati testuali.

Le risorse possono essere aperte usando ResourceHacker. È un bello strumento e più che raccomandato. Anche le risorse Exe potrebbero essere visualizzate/modificate utilizzando Visual Studio. In fondo le risorse sono un file di testo che dice al compilatore di risorse come e cosa combinare in un formato binario ben definito.

Data e Executable sono difficili. Avere informazioni di debug aiuta molto a trovare gli indirizzi dove sono memorizzati i dati. Alcune informazioni sono anche disponibili dall'intestazione dell'exe, ma non molto. Qui dipende dal compilatore usato. Per esempio C/C++ e altri compilatori nativi genereranno codice eseguibile rilocabile e WinDgb o qualsiasi altro debugger di Windows è sufficiente per vedere, eseguire e passare attraverso il codice. Ma altri linguaggi, come C#, la storia è completamente diversa. Anche i "compilatori" per gli script esistono, ad esempio prompt dei comandi o script Python incorporati nel file exe.

Di solito non è semplice analizzare il codice compilato. L'exe quando viene rilasciato è per lo più costruito utilizzando le opzioni di rilascio che comportano l'ottimizzazione del codice. Il codice dopo essere stato ottimizzato è quasi illeggibile. One stupid example:

1. for(int a = 0; a < 10; a++); 

Debug build, no optimizations will keep above loop in code where a will be incremented 10 times. But when built using even lowest optimizations compiler will generate code like:

1. a = 10; 

In some cases, like above, code will be completely removed.
I ran some compiler testing comparing ARM old and new compiler and Visual Studio. Non ricordo i numeri esatti ma il vecchio ARM ha prodotto 100 byte, il nuovo 50 e VS circa 10 byte! VS eseguiva semplicemente funzioni di classe in fase di compilazione (non constexpr) e dopo aver forzato la memorizzazione del codice del risultato finale finiva per memorizzare il risultato finale in una variabile.

Le cose diventano ancora più difficili quando si usa AVX. I compilatori riconoscono vari cicli e li sostituiscono con istruzioni AVX. Analizzare tale codice è un incubo e impossibile senza conoscere la CPU nei dettagli.

Modificare l'exe è possibile ma difficile. Le risorse non sono un problema, ma il codice sì. E la modifica del codice è fatta da vari crack, anche modificando a mano alcune istruzioni per saltare qualche controllo di licenza. Questo richiede un sacco di pratica, trucchi per trovare i punti critici.