3 ms·

https://derevenets.com/examples.html https://derevenets.com/examples.html So, a decompiler is cool and all, but...a five-line "Hello World" program turned into

https://derevenets.com/examples.html https://derevenets.com/examples.html So, a decompiler is cool and all, but...a five-line "Hello World" program turned into a 144-line decompiled program. Is that an accomplishment? I'm pretty sure the "reconstructed" C from that is longer than the assembly. EDIT: Just to confirm, this is what I got when I put the Hello World code into "hello.c" and ran GCC against it: gcc -O2 -S -c hello.c hello.s: .file "hello.c" .section .rodata.str1.1,"aMS",@progbits,1 .LC0: .string "Hello, World!" .text .p2align 4,,15 .globl main .type main, @function main: .LFB11: .cfi_startproc subq $8, %rsp .cfi_def_cfa_offset 16 movl $.LC0, %edi call puts xorl %eax, %eax addq $8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE11: .size main, .-main .ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-18)" .section .note.GNU-stack,"",@progbits

moyix 9y ago
You haven't linked the program in your assembly example. All the extra code you see there is a result of the libc startup code. Decompilers work starting from then entry point (not your program's main), which is why there's so much extra code. If you look at just the code starting from main, you get something much simpler: int64_t puts = 0x4003e6; void func_4003e0(int64_t rdi) { goto puts; } int64_t main() { func_4003e0("Hello, World!"); return 0; }
- AdmiralAsshat 9y ago
  Alright, that makes much more sense. Thanks!
kiwidrew 9y ago
> So, a decompiler is cool and all, but...a five-line "Hello World" program turned into a 144-line decompiled program. Is that an accomplishment? I'm pretty sure the "reconstructed" C from that is longer than the assembly. Yeah, as you've discovered, there's a lot of "magic" going on behind the scenes to establish the standard C runtime environment that executes your main() function. Here's a great writeup that illustrates the, uh, extensive amount of work that happens after spawning a new process but before main() is called: http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html http://dbp-consulting.com/tutorials/debugging/linuxProgramSt...

moyix 9y ago

You haven't linked the program in your assembly example. All the extra code you see there is a result of the libc startup code. Decompilers work starting from then entry point (not your program's main), which is why there's so much extra code. If you look at just the code starting from main, you get something much simpler: int64_t puts = 0x4003e6; void func_4003e0(int64_t rdi) { goto puts; } int64_t main() { func_4003e0("Hello, World!"); return 0; }

AdmiralAsshat 9y ago
Alright, that makes much more sense. Thanks!

kiwidrew 9y ago

> So, a decompiler is cool and all, but...a five-line "Hello World" program turned into a 144-line decompiled program. Is that an accomplishment? I'm pretty sure the "reconstructed" C from that is longer than the assembly. Yeah, as you've discovered, there's a lot of "magic" going on behind the scenes to establish the standard C runtime environment that executes your main() function. Here's a great writeup that illustrates the, uh, extensive amount of work that happens after spawning a new process but before main() is called: http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html http://dbp-consulting.com/tutorials/debugging/linuxProgramSt...