Nix / NixOS

2205 readers

55 users here now

Main links

Videos

founded 2 years ago

MODERATORS

erlingur

ballmerpeaking

WhiteBlackGoose

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

submitted 2 weeks ago by [email protected] to c/nix

2 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.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 2 weeks ago (1 children)

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

[–] [email protected] 1 points 2 weeks ago

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.