[llvm-dev] Relinking (syscall-free) ELF executable into Mach-O and PE executables
ardi via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 23 02:07:01 PDT 2018
On Fri, Jul 20, 2018 at 10:59 PM, Matt P. Dziubinski via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> On 7/20/2018 09:46, ardi via llvm-dev wrote:
>>
>> Would this be possible with just LLVM tools, or would other
>> libraries/tools also be needed?
>
> I'd expect you'd run into the issues mentioned by Reid.
>
> That being said, in terms of building blocks -- i.e., executables
> manipulation per se -- I'd recommend LIEF (Library to Instrument Executable
> Formats):
> https://github.com/lief-project/LIEF
As Reid mentioned, using a loader is the straightforward option, but I
have some concern that some "app stores" (ie: Apple, Google, or any
other) might reject apps if they see a "loader that loads some
binary". So, before opting for a loader, I want to discard other
possibilities.
Looking at the LIEF tutorials, I saw one for transforming an ELF
executable into a dynamic library:
https://lief.quarkslab.com/doc/latest/tutorials/08_elf_bin2lib.html
Maybe that path could be used. If I can find some way for turning an
ELF DSO into either a PE static library, or a Mach-O static library,
then the process would be
ELF_exec->ELF_dso->Target_static->Target_exec (where Target is either
PE or Mach-O).
Another possibility perhaps, would be to map the ELF executable, do a
binary dump of the mapping, and then embed such mapping into an
executable, but I guess that the mapping depends on the address being
given by the OS for the process, so maybe this path wouldn't be
possible (also, I guess those "app stores" would also see a big
suspecting binary area if they "nm" the executable).
Is there any other alternative before opting for a loader?
@Zachary: As probably can be deduced from my comments, I'm not an
expert in low-level executable formats, so I'm not really sure about
you are implying to do, nor if it would be feasible for my scenario.
Thanks!
ardi
More information about the llvm-dev
mailing list