How to determine if an ELF file is a Go ELF file?-CodePudding

I need to determine whether a given ELF file originated from Go. According to this link:

$ readelf -a traefik.stripped | grep "\.note\.go\.buildid"

Is this in any way inferior to go's native way:

$ go tool buildid traefik.stripped
oPIWoPjqt1P3rttpA3ee/ByNXPhvgS37nIoJY-HYB/8b25JYXrgktA-FYgU5MU/0Posfq41xZW9BEPEG4Ub

Are both methods guaranteed to work on stripped binaries?

CodePudding user response：

The mentioned section is a NOTE section:

$ readelf -a traefik.stripped | grep "\.note\.go\.buildid" | sed -n "1,1p"
  [11] .note.go.buildid  NOTE             0000000000400f9c  00000f9c

And apparently NOTE sections might sometimes be removed for size reductions (related):

objcopy --remove-section=.note.go.buildid traefik.stripped traefik.super.stripped

Removing the mentioned section does not seem to harm the integrity of the whole binary

CodePudding user response：

As for using standard go tools the section should be there, but there is a way that the go nature of a binary can be hidden without any malicious intent. Using upx to reduce the size of the binary will completely hide the go nature of the binary as upx works with binaries from any language.

CodePudding user response：

I need to determine whether a given ELF file originated from Go

That is impossible to do in general. What is and isn't a Go binary is not well defined, and a sufficiently optimized Go binary may end up containing just a few instructions. E.g. on x86_64, you may end up with a single HLT instruction.

how come strip itself doesn't remove this section?

This section (indeed every section) is not necessary for execution -- you can remove all sections, and the binary will still work.

This section is present only to help developers identify a particular build. strip doesn't remove it by default because that would defeat the purpose of this section, but it certainly can do so.

can an innocent go developer build a golang ELF and accidentally remove this (redundant??) section

Sure. The developer can run a broken version of strip, or he can have aliased strip with strip --strip-all, or he could have used some other ELF post-processing tool, or he could have used UPX, or ...