Como abrir um arquivo EXE que é feito com programação C em código VS

O que você quer dizer com "abrir".
Onde o arquivo exe é feito não importa. O que importa é compilador ou ferramenta para gerar o exe.
Anyway, sob o arquivo exe do Windows tem os seguintes dados embutidos:

• código executável
• Data - dados personalizados usados pelo executávelli>li>Resources - ícones, bitmaps, etc>li>Debug info - debug info só é embutido no build debug e removido (movido para o arquivo pdb) nos builds de release

>p>Let's start from bottom. As informações de depuração são usadas para depuração e contêm várias informações como símbolos (localização de funções, variáveis), conexão entre o número da linha do arquivo fonte e o código executável, etc. Vários formatos existem e são legíveis pelos depuradores. Por exemplo, o WinDbg (depurador gratuito do Windows e muito poderoso) lê esta informação e permite a depuração ao nível do código-fonte, etc. Todo compilador também vem com ferramentas CLI para exportar informações de depuração para vários formatos de texto.

Recursos podem ser abertos usando ResourceHacker. É uma boa ferramenta e mais do que recomendada. O recurso Exe também pode ser visualizado/alterado usando o Visual Studio. Na parte inferior dos recursos há um arquivo texto dizendo ao compilador de recursos como e o que combinar em formato binário bem definido.

Dados e Executáveis são difíceis. Ter informações de debug ajuda muito a encontrar endereços onde os dados são armazenados. Algumas informações também estão disponíveis no cabeçalho do exe, mas não muito. Aqui depende do compilador utilizado. Ex. C/C++ e outros compiladores nativos irão gerar código executável relocável e WinDgb ou qualquer outro debugger do Windows é suficiente para ver, executar e passar pelo código. Mas outras linguagens, como C#, a história é completamente diferente. Mesmo "compiladores" para scripts existem, por exemplo, prompt de comando ou scripts Python embutidos no arquivo exe.

Usualmente não é simples analisar o código compilado. O Exe quando lançado é compilado principalmente usando opções de lançamento, o que envolve otimizações de código. O código após ser otimizado é quase ilegível. 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. Não me lembro de números exatos, mas o ARM antigo produziu 100 bytes, o novo 50 e o VS cerca de 10 bytes! VS simplesmente executou funções de classe em tempo de compilação (não constexpr) e depois de forçar o armazenamento do código do resultado final acabou armazenando o resultado final em uma variável.

As coisas se tornam ainda mais difíceis quando se usa AVX. Compiladores reconhecem vários loops e os substituem por instruções AVX. Analisar tal código é um pesadelo e impossível sem conhecer a CPU em detalhes.

Modificar o exe é possível mas difícil. Recursos não são problema, mas código é. E a modificação do código é feita por várias rachaduras, mesmo modificando manualmente poucas instruções para pular alguma verificação de licença. Isto requer muitos praxes, truques para encontrar lugares críticos.