I'd like to override some hardcoded paths stored in pre-compiled executables like "/usr/share/nmap/" and redirect them to another dir.

My ideal solution should not require root priviledges, so creating a symlink is not ok.

(Also recompiling it's not an option)

  • Another option is to override desired functions using LD_PRELOAD. – Chris Down Mar 31 '14 at 7:52
  • @Chris Down could you suggest me any ready-to-use tool? – eadmaster Mar 31 '14 at 8:03
  • No, but I can recommend you go and take a look at libetc, which has a similar goal (the source code is fairly easy to look at, all you need to do is override some file handling functions). ordiluc.net/fs/libetc – Chris Down Mar 31 '14 at 8:13
perl -pe 's:/usr/share/nmap/:/other/dir/nmap/:g
  ' /path/to/executable > new-executable

/other/dir/nmap should be the same length as /usr/share/nmap. You can pad with / characters if not:

perl -pe 's:/usr/share/nmap/:/other//////dir/:g
  ' /path/to/executable > new-executable

The new path cannot be longer. You always have the option to create symlinks in /tmp if that's an issue.


Reference @slm's answer ...

A third way to do this might be to create a chrooted sandbox environment for running the executable in which everything other than the executables you want to remap are directed to the real thing. But it would be complicated.

But I would advise getting hold of the source code and recompiling. (Or if this is proprietary code, paying the supplier to spin you some custom executables ...)

  • Recompiling can be a pain sometimes due to dependencies hell, so i'm more inclined to a sandbox solution... – eadmaster Mar 30 '14 at 3:49

What I did in a previous life was to carefully edit an executable to replace strings (the replacement must be shorter, fill up with zero characters!), using a binary editor (e.g. hexl-mode in emacs/xemacs).

If an executable contains fixed paths, they can often be overridden with environment variables (like TMPDIR, EDITOR/VISUAL, or similar) or by giving appropiate arguments. When the path is truly fixed, I'd ask for the reason behind it. There might be security or configuration explanations, that just shouldn't be overridden. Sure, it might be just lazyness, but that is unlikely with software packaged by your distribution, and presumably vetted...

  • can i replace absolute with relative paths this way? Otherwise i was thinking about some sandboxing solution... – eadmaster Mar 30 '14 at 1:46
  • btw this method it's a bit time-wasting and has not 100% compatibility as the executable could have ascii strings obfuscated, integrity checks, etc., so i'm keeping this as a last resort... – eadmaster Mar 30 '14 at 1:55
  • It should work. But sticking your fingers in the executable already voids it's warranty, and my comments are just from a (semi)anonimous account on a social website, so it is just words in the wind... – vonbrand Mar 30 '14 at 1:56

There are only 2 methods I'm aware of where you'll be able to accomplish something like this.

The 1st involves creating a link in the location that has been hardcoded into the executable. So in your example a link would need to be created at /usr/share/nmap/ re-pointing to whatever other location you want. This approach will require root privileges and will necessitate the use of symbolic links at this location.

The 2nd method would involve the use of a hex editor where you'd go into the pre-compiled executables and surgically alter the binaries adding in your own paths instead of the ones pre-compiled ones.


I've just found this ptrace-based chroot reimplementation: PRoot.

The bind function is just what i was looking for!

This is more reliable than replacing strings in the executable + can be easily used in scripts...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.