Making a static exe from a dynamic one?
Ron House
libraries dynamically into one that contains the libraries statically
linked? I studied the ld info with no success. I want to do this with an
exe that I have no sources for, so I can upgrade without keeping
compatibility libraries around - RedHat's compatibility rpms are sloppy
and don't always work.
(Sorry this is in the gcc ng, but no other gnu group seems to be exactly
appropriate for the question.)
--
Ron House ho...@usq.edu.au
http://www.sci.usq.edu.au/staff/house
Paul Pluzhnikov
> Does anyone know if it is possible to convert an exe that loads its
> libraries dynamically into one that contains the libraries statically
> linked?
In practice this is impossible: 'ld' considers an executable or
a shared library a "finished" product (on all UNIX systems except
AIX), and much of the information needed to take executable apart
and reconstruct it in a different way is gone.
Cheers,
--
In order to understand recursion you must first understand recursion.
Sebastian Nowozin
Hi folks,
On Wed, 22 Jan 2003 05:03:38 +0000, Paul Pluzhnikov wrote:
>> Does anyone know if it is possible to convert an exe that loads its
>> libraries dynamically into one that contains the libraries statically
>> linked?
> In practice this is impossible: 'ld' considers an executable or a shared
> library a "finished" product (on all UNIX systems except AIX), and much of
> the information needed to take executable apart and reconstruct it in a
> different way is gone.
Ouch. I strongly disagree here.
It may not be possible to build a "clean" static binary like one that
would result if compiled with -static. But it is possible to attach all the
needed libraries into the binary and add a small loading stub to the new
binary.
With this approach, he gets exactly what he wants: a binary that behaves
like a static one (no external deps) and runs on any system.
But even if you consider this "cheating" ;-) I think it should be possible to
hardwire a real library into a dynamic executeable (with ELF at least).
Basic approach would be:
1. add all PT_LOAD segments to the dynamic executeable
2. load all segments into memory
3. run the dynamic linker once with some options similar to (LD_BIND_NOW)
4. dump all segments to the executeable
5. convert all PT_DYN headers to PT_NULL
That should be it. I once planned to write such tool, unfortunatly it
never turned real.
> Cheers,
bye,
Sebastian
Paul Pluzhnikov
> Ouch. I strongly disagree here.
I did say "in practice", didn't I?
It was fairly clear from the original message that the OP was not
willing to spend too much time on this.
> I once planned to write such tool, unfortunatly it
> never turned real.
How much time do you estimate this would take?
> Basic approach would be:
> 1. add all PT_LOAD segments to the dynamic executeable
> 2. load all segments into memory
> 3. run the dynamic linker once with some options similar to (LD_BIND_NOW)
> 4. dump all segments to the executeable
> 5. convert all PT_DYN headers to PT_NULL
Hmm, I don't think this will work:
- Since you don't say anything about changing the ELF header
or the .interp section, presumably they stay as they are
(with e_type == ET_EXEC and .interp == "/lib/ld-linux.so.2")
- The kernel will then start ld-linux.so.2 with proper arguments,
which will find that there are no PT_LOAD segments at all,
and will crash or give up immediately thereafter.
I guess we wouldn't know until you do try it, will we ;-?
Sebastian Nowozin
Hey folks,
On Fri, 24 Jan 2003 06:04:48 +0000, Paul Pluzhnikov wrote:
> I did say "in practice", didn't I?
Yes, but impossible is still impossible ;) If you would have said "its
hard to do", I would agree.
>> I once planned to write such tool, unfortunatly it never turned real.
> How much time do you estimate this would take?
Not that much, two days or less.
>> Basic approach would be:
>> 1. add all PT_LOAD segments to the dynamic executeable 2. load all
>> segments into memory
>> 3. run the dynamic linker once with some options similar to
>> (LD_BIND_NOW) 4. dump all segments to the executeable 5. convert all
>> PT_DYN headers to PT_NULL
> Hmm, I don't think this will work:
> - Since you don't say anything about changing the ELF header
> or the .interp section, presumably they stay as they are (with e_type ==
> ET_EXEC and .interp == "/lib/ld-linux.so.2")
PT_INTERP can stay as it is, but sure its better to PT_NULL that out, too.
In case there is a /lib/ld-linux.so.2 on the system that has the Linux
ABI, it will still work, though.
> - The kernel will then start ld-linux.so.2 with proper arguments,
> which will find that there are no PT_LOAD segments at all, and will
> crash or give up immediately thereafter.
As there is no PT_DYN segment anymore, I do not think it will do any harm,
but pass control to the normal entry point. All the library segments are
already there, as they have been attached to the binary.
> I guess we wouldn't know until you do try it, will we ;-?
True... ;-)
> Cheers,
bye,
Sebastian
Rolf Magnus
>> In practice this is impossible: 'ld' considers an executable or a
>> shared library a "finished" product (on all UNIX systems except AIX),
>> and much of the information needed to take executable apart and
>> reconstruct it in a different way is gone.
>
> Ouch. I strongly disagree here.
>
> It may not be possible to build a "clean" static binary like one that
> would result if compiled with -static.
I have to admit that I don't know much about linker internals, but I
wonder what information is missing to do this.
Sebastian Nowozin
Hi.
On Sat, 25 Jan 2003 15:08:07 +0100, Rolf Magnus wrote:
>> It may not be possible to build a "clean" static binary like one that
>> would result if compiled with -static.
> I have to admit that I don't know much about linker internals, but I
> wonder what information is missing to do this.
I do not know exactly what could miss, either ;-)
The problem with processing ET_EXEC ELF binaries is that you have no
relocation information left in the binary. So whenever you have to move
around anything, be it data or code within the binary, you basically have
to do a complete code- and dataflow analysis (which is impossible for the
generic case).
But being realistic, even if you leave the old segments where they are,
some things inbetween, like the program header table have to be extended.
This will most likely be a space problem, so you have to move the program
header table out of the way (at least to a place after already existing
segments).
Basically, you have to worry about anything an ELF virus has to worry
about ;-)
So, there may not be missing any information, but the information thats
there is fixed in place and you can only work around it, not with it. The
resulting binary will work, but still its no "clean" link, but will look
like some virus-infected binary, with tables patched up and paddings
shoved around.
bye,
Sebastian
Sebastian Nowozin
Hi.
On Wed, 22 Jan 2003 00:11:06 +0000, Ron House wrote:
> Does anyone know if it is possible to convert an exe that loads its
> libraries dynamically into one that contains the libraries statically
> linked? I studied the ld info with no success. I want to do this with an
> exe that I have no sources for, so I can upgrade without keeping
> compatibility libraries around - RedHat's compatibility rpms are sloppy
> and don't always work.
Just found this on the net ;-)
http://www.team-teso.net/releases/reducebind.c
Does exactly what you want, but only for Linux IA32. Let me know if you
are having trouble with it, I think I can help you then ;)
bye,
Sebastian