I'm not sure if this is even possible, but given an executable file (foo.exe), with has many libraries which has been linked statically.
Is there any software that extract from this file the .lib ( or .a ) that lay inside the executable ?
Thanks.
When your application links against a static library, the library's code becomes part of the resulting executable. This is performed only once at linking time, and these static libraries usually end with a . a extension. A static library is an archive (ar) of object files.
Statically-linked files are 'locked' to the executable at link time so they never change. A dynamically linked file referenced by an executable can change just by replacing the file on the disk. This allows updates to functionality without having to re-link the code; the loader re-links every time you run it.
I just discovered that you can use readelf -a to display the contents of all the object files in a static library. Invoke the readelf command like this: $ readelf -a mystaticlib.
Incredibly unlikely since, typically, you don't get the entire contents of the library injected into your executable.
You only get enough to satisfy all the undefined symbols. This may actually only be a small part of the library. A library generally consists of a set of object files of which only those that are required are linked into your executable.
For example, if the only thing you called in the C runtime library was exit()
, you would be very unlikely to have the printf()
family of functions in your executable.
If you linked with the object files directly, you may have a chance, since they would be included whether used or not (unless your linker is a smart one).
But even that would be a Herculean task as there may be no information in the executable as to what code sections came from specific object files. It's potentially doable but, if there's another way, I'd be looking at that first.
Let me clarify the typical process:
a.o
, b.o
, c.o
and d.o
contain the functions a()
, b()
, c()
and d()
respectively. They are all added to the abcd.a
archive.b()
calls c()
.a()
and b()
and you compile it then link it with the abcd.a
library.a.o
and b.o
out of the library and into your executable, satisfying the need for a()
and b()
but introducing a need for c()
, because b()
needs it.c.o
out of the library and into your executable, satisfying the need for c()
. Now all undefined symbols are satisfied, the executable is done and dusted, you can run it when ready.At no stage in that process was d.o
dragged into your executable so you have zero hope of getting it out.
Update: Re the "if there's another way, I'd be looking at that first" comment I made above, you have just stated in a comment to one of the other answers that you have the source code that made the libraries you want extracted. I need to ask: why can you not rebuild the libraries with that source? That seems to me a much easier solution than trying to recreate the libraries from a morass of executable code.
Imagine having 10 books in language you don't understand, without covers, title pages, page numbers and chapters. Some of the books can be incomplete. All pages are shuffled together so it is impossible to find out where is the beginning and end of each book.(each page is a function call) Now try to find page 123 of book 5 (let's say it is mentioned above function Exit()).
Well, IT IS possible...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With