support archives/static libraries

[SSE4]

I found it useful for my needs to parse also archives/static libraries, as well as corresponding object files (e.g. in COFF or ELF formats). at very least, to obtain list of exported and imported symbols.
does it sound as useful addition for this project?
if yes, I may try to prototype this.

[romainthomas]

Yes It's completely in the scope of this project so feel free to make a PR for these features

[mingwandroid]

So glad to hear this is in-scope!

[mingwandroid]

Hello @romainthomas and @SSE4, do either of you know if anyone has done any work on this yet? I may take a go at it if not, hopefully I can figure it out.

[SSE4]

@mingwandroid I have started any work yet, feel free to take it

[romainthomas]

Nice! I'm quite busy with other stuff but feel free to ask questions if you have some

[mingwandroid]

Hi @romainthomas, I have been hacking about with some Python code to handle archives (I hope to convert it to C++ and make a PR at some point). I can give you a URL if you wish, the code is currently in a branch in my own fork of conda-build.

It works to a degree on Linux. Since an .ar is just an archive of .elf files (with some indexes), to get the final symbols (and rich information about them) I use lief.elf.parse(raw=ar_file[elf_start_index:elf_end_index]).

On Windows, calling lief.PE.parse(raw=ar_file[coff_start_index:coff_end_index]) does not work since a COFF file isn't the same as a PE file. I get the following error:

'C:\Users\rdonnelly\conda\conda-build\mingw-w64-libz.dll.a\d000103.o' is not an PE

Do you have any recommendations for how to proceed at this point? Would the code that deals with COFF be callable here?

Many thanks!

[romainthomas]

Hi @mingwandroid
Thank you very much for your contribution! I'm interested in your code (I didn't find the branch in conda-build)

Regarding COFF file, I think it would require to refactor some part of the PE module of LIEF since PE format is
a specialization of COFF.
One way to do to would be to have a LIEF::COFF::Binary object and LIEF::PE::Binary would inherit this class. There is a similar example with OAT format and ELF file:

LIEF/include/LIEF/ELF/Binary.hpp

Line 57 in 13ad81e

class LIEF_API Binary : public LIEF::Binary {

LIEF/include/LIEF/OAT/Binary.hpp

Line 39 in 13ad81e

class LIEF_API Binary : public LIEF::ELF::Binary {

[mingwandroid]

Hi @romainthomas, thanks. Hopefully I can get this done!

My (very WIP) python code can be seen here. These line numbers may change today though as I'll be trying to fix/add macOS/BSD support. The function in question is get_static_lib_exports. You can see for the non-COFF case that I just let LIEF do the heavy lifting and that's working well.

Thank you for your recommendation. I was under the impression that a COFF file is essentially embedded in a PE file, given what you said, I guess that's not correct?

[mingwandroid]

Hey @romainthomas, I'm starting to look into some LIEF issues now. Are there any channels (gitter/IRC) where hacking on LIEF gets discussed?

[romainthomas]

Hi @mingwandroid,
Sorry I mess your latest message.

Thank you for your recommendation. I was under the impression that a COFF file is essentially embedded in a PE
file, given what you said, I guess that's not correct?
PE files implement COFF spec so that a PE file should be COFF file (If I'm not wrong)

Are there any channels (gitter/IRC) where hacking on LIEF gets discussed?

Yes there is a Gitter Channel here: https://gitter.im/lief-project

[SSE4]

PE and COFF share the same specification, that's true, but COFF is not embedded in PE or vice versa. they have different set of headers, and headers have different set of fields depending if it's COFF or PE file, also some fields may have different meaning.

[aeflores]

Is this still being worked on?

[romainthomas]

@aeflores not from my side