4 ms·

Could someone explain in what kind of situations this could be useful?

tiddlydum 10y ago
I imagine in any situation you have an ELF binary you need to analyse but have no source for it. Reverse-engineering and forensics come to mind.
joeyrideout 10y ago
The primary use of wcc is to "unlink" (undo the work of a linker) ELF binaries, either executables or shared libraries, back into relocatable shared objects. If I understand correctly, this is a novel way of speeding up reverse engineering by creating the missing middle step of compiling a binary - object code. Normal decompilers go from machine code to source code, which is difficult to work with. Going from machine code back to object code is not supposed to be easy or even possible. (ELF is only supported right now because reverse-engineering the linking process for different architectures takes a lot of work.) WCC unlinks machine code into a library, allowing you to interact with the object code and reliably include and call its functions from your own code, as if it were a shared system library rather than a black box.
- throwaway76543 10y ago
  I wonder how many folks are aware that ELF shared libraries and ELF executables are the exact same thing? There's no substantial compiling or decompiling necessary to go from shared object to executable and back. One need only add or remove the appropriate symbols from the object and (perhaps even optionally) change the object type. Have you ever tried to directly execute your libc.so.6 on a linux system? You can. There's nothing at all novel about this process, other than making it easy for folks who've never read the manual for their linker. Edit: Someone downvoted this observation; I imagine they think I'm unfairly trivializing this so I'll add: Read the source code. This tool we're discussing is a simple ~100 line program. It's not complicated: https://github.com/endrazine/wcc/blob/master/src/wld/wld.c https://github.com/endrazine/wcc/blob/master/src/wld/wld.c
  - colanderman 10y ago
    I don't get it. Isn't there a missing step of making the objects relocatable (i.e. what -fPIC does)? That requires rewriting branches and stuff. But clearly wcc isn't doing this?
    - vidarh 10y ago
      PIC makes the code position independent. That is, the code can be moved without relocation fixups. ELF executables typically use relocatable code (with relocation sections) rather than PIC because especially on i386 it has performance and size implications to use -fPIC. But on x86_64 it's actively discouraged, but not actually prevented if you generate an ELF file that the linker is satisfied with. The main issue with that latter part is that 64 bit code can contain 32 bit relocation fixups, and such addresses will be impossible for the linker to relocate outside the 32 bit memory space, and your mileage may vary whether your load time linker will be able to even try to handle that or not on a 64 bit platform. If your code is free of 32 bit relocations, there "shouldn't" be any reasons for them not to be usable as shared objects even if they contain relocations instead of use PIC (whether any specific load time linkers unnecessarily enforce restrictions on this is another matter).
- zvrba 10y ago
  > WCC unlinks machine code into a library, allowing you to interact with the object code and reliably include and call its functions from your own code, as if it were a shared system library rather than a black box. Shared library is as much of a black box as an executable.
  - spacemanmatt 10y ago
    Pretty sure access to internal APIs not exposed through the executable's CLI/GUI/config/etc interfaces is typically superior to no access.
    - zvrba 10y ago
      You're too optimistic about what it can do, here's a sample output: https://github.com/endrazine/wcc/wiki/wcch https://github.com/endrazine/wcc/wiki/wcch This is not what I'd call an "API dump"; all prototypes return void pointers and allow any arguments. Hence, it's just as much of a blackbox as the original executable is because you have no idea what the functions do, what arguments they take and what values they return.
      - spacemanmatt 10y ago
        I don't know, having the ability to compile your own test driver against it rather than manipulating the executable is what I'd be after with the tool. You may be reading too much assumption into my comment.
Annatar 10y ago
Suppose you have an executable compiled for /usr/local on a SVR4 UNIX system, or on GNU/Linux (this is a severe violation of SVR4 and LSB FHS standards [1][2]). With these tools, you could theoretically unlink the application, then re-link it with $ORIGIN linker keyword, and install it into /opt, where the standards say it belongs. (Same for 3rd party unbundled applications which were linked to use their own shared libraries residing in /usr/lib[64] or /usr/lib[/64], another very serious architectural offense.) Let's build upon the author's example in order to demonstrate the above (imagine for a moment that ls(1) is a third party, unbundled application which clashes with vendor's own ls(1) as delivered with the operating system): % wcc -c /bin/ls -o /tmp/ls.o (GCC) % gcc -shared -Wl,-R'$ORIGIN:$ORIGIN/../../lib:$ORIGIN/../../lib:/opt/local/lib' /tmp/ls.o -o /tmp/ls (Sun Studio) % cc -G -Wl,-R'$ORIGIN:$ORIGIN/../../lib:$ORIGIN/../../lib:/opt/local/lib' /tmp/ls.o -o /tmp/ls [1] https://docs.oracle.com/cd/E19455-01/817-5431/6mksv3nvi/index.html https://docs.oracle.com/cd/E19455-01/817-5431/6mksv3nvi/inde... [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcoptConfigurationFilesForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varoptVariableDataForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var...

I imagine in any situation you have an ELF binary you need to analyse but have no source for it. Reverse-engineering and forensics come to mind.

joeyrideout 10y ago

The primary use of wcc is to "unlink" (undo the work of a linker) ELF binaries, either executables or shared libraries, back into relocatable shared objects. If I understand correctly, this is a novel way of speeding up reverse engineering by creating the missing middle step of compiling a binary - object code. Normal decompilers go from machine code to source code, which is difficult to work with. Going from machine code back to object code is not supposed to be easy or even possible. (ELF is only supported right now because reverse-engineering the linking process for different architectures takes a lot of work.) WCC unlinks machine code into a library, allowing you to interact with the object code and reliably include and call its functions from your own code, as if it were a shared system library rather than a black box.

throwaway76543 10y ago
I wonder how many folks are aware that ELF shared libraries and ELF executables are the exact same thing? There's no substantial compiling or decompiling necessary to go from shared object to executable and back. One need only add or remove the appropriate symbols from the object and (perhaps even optionally) change the object type. Have you ever tried to directly execute your libc.so.6 on a linux system? You can. There's nothing at all novel about this process, other than making it easy for folks who've never read the manual for their linker. Edit: Someone downvoted this observation; I imagine they think I'm unfairly trivializing this so I'll add: Read the source code. This tool we're discussing is a simple ~100 line program. It's not complicated: https://github.com/endrazine/wcc/blob/master/src/wld/wld.c https://github.com/endrazine/wcc/blob/master/src/wld/wld.c
- colanderman 10y ago
  I don't get it. Isn't there a missing step of making the objects relocatable (i.e. what -fPIC does)? That requires rewriting branches and stuff. But clearly wcc isn't doing this?
  - vidarh 10y ago
    PIC makes the code position independent. That is, the code can be moved without relocation fixups. ELF executables typically use relocatable code (with relocation sections) rather than PIC because especially on i386 it has performance and size implications to use -fPIC. But on x86_64 it's actively discouraged, but not actually prevented if you generate an ELF file that the linker is satisfied with. The main issue with that latter part is that 64 bit code can contain 32 bit relocation fixups, and such addresses will be impossible for the linker to relocate outside the 32 bit memory space, and your mileage may vary whether your load time linker will be able to even try to handle that or not on a 64 bit platform. If your code is free of 32 bit relocations, there "shouldn't" be any reasons for them not to be usable as shared objects even if they contain relocations instead of use PIC (whether any specific load time linkers unnecessarily enforce restrictions on this is another matter).
zvrba 10y ago
> WCC unlinks machine code into a library, allowing you to interact with the object code and reliably include and call its functions from your own code, as if it were a shared system library rather than a black box. Shared library is as much of a black box as an executable.
- spacemanmatt 10y ago
  Pretty sure access to internal APIs not exposed through the executable's CLI/GUI/config/etc interfaces is typically superior to no access.
  - zvrba 10y ago
    You're too optimistic about what it can do, here's a sample output: https://github.com/endrazine/wcc/wiki/wcch https://github.com/endrazine/wcc/wiki/wcch This is not what I'd call an "API dump"; all prototypes return void pointers and allow any arguments. Hence, it's just as much of a blackbox as the original executable is because you have no idea what the functions do, what arguments they take and what values they return.
    - spacemanmatt 10y ago
      I don't know, having the ability to compile your own test driver against it rather than manipulating the executable is what I'd be after with the tool. You may be reading too much assumption into my comment.

Annatar 10y ago

Suppose you have an executable compiled for /usr/local on a SVR4 UNIX system, or on GNU/Linux (this is a severe violation of SVR4 and LSB FHS standards [1][2]). With these tools, you could theoretically unlink the application, then re-link it with $ORIGIN linker keyword, and install it into /opt, where the standards say it belongs. (Same for 3rd party unbundled applications which were linked to use their own shared libraries residing in /usr/lib[64] or /usr/lib[/64], another very serious architectural offense.) Let's build upon the author's example in order to demonstrate the above (imagine for a moment that ls(1) is a third party, unbundled application which clashes with vendor's own ls(1) as delivered with the operating system): % wcc -c /bin/ls -o /tmp/ls.o (GCC) % gcc -shared -Wl,-R'$ORIGIN:$ORIGIN/../../lib:$ORIGIN/../../lib:/opt/local/lib' /tmp/ls.o -o /tmp/ls (Sun Studio) % cc -G -Wl,-R'$ORIGIN:$ORIGIN/../../lib:$ORIGIN/../../lib:/opt/local/lib' /tmp/ls.o -o /tmp/ls [1] https://docs.oracle.com/cd/E19455-01/817-5431/6mksv3nvi/index.html https://docs.oracle.com/cd/E19455-01/817-5431/6mksv3nvi/inde... [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcoptConfigurationFilesForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varoptVariableDataForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var...