paulo1205
(usa Ubuntu)
Enviado em 20/05/2016 - 09:41h
Achei muito interessante a descompilação do “Hello, World!”, listado entre os exemplos do Snowman.
Tudo bem que boa parte do monstro inclui a descompilação do código de inicialização que executa antes de
main () ser chamada e também do código de finalização que executa após o seu retorno. Será que precisaria mostrar isso? Já que mostra, poderia tentar acertar mais pelo menos os tipos dos dados. Destaco aqui algumas das coisas que eu achei mais exóticas:
void frame_dummy() {
if (__JCR_END__ == 0 || 1) { // <-- Condição sempre verdadeira. Para que o if?
return;
} else {
goto 0; // <-- Hein?!!
}
}
int64_t __gmon_start__ = 0;
void call_gmon_start() {
int64_t rax1; // <-- O tipo deveria ser “void (*)(void)”, não inteiro.
rax1 = __gmon_start__;
if (rax1 != 0) {
rax1(); // <-- Chama um inteiro? Não vai compilar...
}
return; // <-- Comando inócuo.
}
void __do_global_dtors_aux() {
uint64_t rax1; // <-- Note que é unsigned.
uint64_t rax2;
if (completed_6341 == 0) {
rax1 = dtor_idx_6343;
if (0 > rax1) { // <-- Se rax1 é unisgned, zero nunca será maior que ela.
do {
rax2 = rax1 + 1;
dtor_idx_6343 = rax2;
*(int64_t*)(rax2 * 8 + 0x6006b0)(); // <-- Invoca inteiro? E para que o cast no valor retornado?
rax1 = dtor_idx_6343;
} while (rax1 < 0); // <-- De novo: essa condição será sempre falsa.
}
completed_6341 = 1;
}
return;
}
Não me entendam mal, contudo. Os absurdos acima, reitero, aconteceram com código que não estava “dentro” do programa original em C. Se você precisa realmente reconstruir o algoritmo original a partir do executável e não é capaz de entender o Assembly por conta própria, um descompilador como esse pode ser sua melhor opção.
Mas prepare-se para filtrar e reinterpretar tudo o que ele lhe mostrar -- especialmente se o executável que você submeter a ele tiver sido compilado com otimização ligada.