I've taken an interest to disassembling binaries and attempting to recreate 1:1 source code (logic) in C and C++ compiled with GCC. I say "logic" because this question does not pertain to recovering variable names or chronological lines of C code. My aim is to compile C code that generates the same disassembly as a function in a proprietary library. I am not trying to match offsets unless they are a relative to structures. I am not concerned with timestamps or build directories either.

One might be able to look at the .comment section in a linux elf binary to determine the compiler version. Let's assume this section was never included or stripped out. Let's also assume we have a large binary (or several binaries compiled with the same compiler version and options -- lots to analyze). Are there tells to determine specific GCC versions? Tells to determine above or below a specific GCC version? Indicators of GCC options used?


I'm looking at a proprietary linux elf binary compiled by a 3rd party. The prologue looks like this:

        00018c04 55              PUSH       EBP
        00018c05 e8 e1 67        CALL       __i686.get_pc_thunk.ax
                 00 00
        00018c0a 05 f6 93        ADD        EAX,0x93f6
                 00 00
        00018c0f 89 e5           MOV        EBP,ESP

The prologue in my attempt to recreate looks like this:

        00011212 55              PUSH       EBP
        00011213 89 e5           MOV        EBP,ESP
        00011215 e8 6b ff        CALL       __x86.get_pc_thunk.dx
                 ff ff
        0001121a 81 c2 e6        ADD        EDX,0x2de6
                 2d 00 00

I know that __i686.get_pc_thunk.ax and __x86.get_pc_thunk.dx are the same apart from the register used.

I know that ADD EAX,0x93f6 and ADD EDX,0x2de6 only vary in offset length and register used.

Is there a discernible version (range) or option that can be determined by the differences in registers used?

Is there a discernible version (range) or option that can be determined by the ordering of instructions?

  • 1
    An interesting question, but based on your description I have not understood why you want to know the GCC version. For recreating the source code (logic) the used GCC version should be irrelevant. Or are you trying to not only recreate the source code but also compare the recreated compiled binary with the original one? Note that this is leading to reproducible or deterministic builds and this is already complicated if you have the original source code and the build files with all the build parameters.
    – Robert
    Commented May 29, 2022 at 12:15
  • My reason for wanting to know the exact GCC version comes from a desire to analyze a binary, look at a function, attempt to recreate that function in C. For now, I'd like to recreate a single function of a proprietary library in C, not a whole binary. I'm reasonably confident that I've been able to recreate specific functions at a C logic level, but the disassembly slightly differs between the the binaries I have compiled and the binaries I am analyzing. My thought is that 1:1 disassembly is a reasonable indicator of correctness. I'm not to interested in matching timestamps and build dirs. Commented May 31, 2022 at 3:31
  • Offsets to .rodata, .bss, etc. aren't really important to the question I'm trying to ask either. I'm aware that these offsets will be relatively difficult to match up. Commented May 31, 2022 at 3:34
  • Updated the original question to include information from the last two comments. Commented May 31, 2022 at 3:44
  • @MatthewTingum the way I saw Robert's remark was that there isn't typically much of a difference from knowing the exact toolchain details and parameters. If you have a disassembly you can use that as the naked truth to get back to pseudo-code or use a decompiler to do the same and then go from there. The only advantage tools have from knowing the toolchain that generated a binary is usually something like finding common patterns or applying the correct set of signatures to detect compiler and runtime library functions ....
    – 0xC0000022L
    Commented May 31, 2022 at 7:29


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.