Nix / NixOS

2216 readers

7 users here now

Main links

Videos

founded 2 years ago

MODERATORS

erlingur@programming.dev

ballmerpeaking@programming.dev

WhiteBlackGoose@programming.dev

Patch interpreter path in embedded binary? (leminal.space)

submitted 3 weeks ago by hallettj@leminal.space to c/nix@programming.dev

3 comments fedilink hide all child comments

I'm trying to write a Nix package for a closed-source, precompiled binary with an unusual twist. The binary is statically-linked, but it contains an embedded binary that is dynamically-linked. Is there some way I can use patchelf or another tool to path the interpreter path in the embedded binary?

The embedded binary does not have any runtime library dependencies, but it does need an interpreter which it expects at the hard-coded path /lib64/ld-linux-x86-64.so.2. It is embedded using the golang "embed" library.

I have a workaround that wraps the binary using buildFHSEnv. That works, but the resulting closure is about 300 MB bigger than it needs to be.

top 3 comments

sorted by: hot top controversial new old

[–] Boomkop3@reddthat.com 3 points 3 weeks ago (1 children)

If you're lucky and the binary is uncompressed, that string might just be in there raw

[–] hallettj@leminal.space 1 points 3 weeks ago (1 children)

That's a good point! The string is in there, and I can see it with strings. But in my research so far it's looking like making a simple string substitution might not be an option. The replacement string would be a Nix store path which would be longer. That would shift over subsequent bytes in the binary which it sounds like would produce alignment issues that would break things.

Apparently it's ok to change the length of the ELF header, which is what patchelf does. But shifting bytes in the ELF body is a problem.

Now what I haven't verified yet is whether the embedded binary is in the body or in the header. If it's in the header - or even if just the interpreter string is in the header then I might be good to go.

[–] refalo@programming.dev 1 points 2 days ago

You could just change the path in the binary to a string that's smaller than what's in there now (or the same length), and pad any unused bytes with \0, then symlink that path to your real binary.