What about generating binary? about write_x86_64 HOT 7 OPEN

This feature is not fully implemented because to be able to generate a binary you also need to generate the OS specific header and my previous attempts to do this failed.

As such this feature is not documented because this crate does not have a satisfying implementation of binary generation

from write_x86_64.

Generating header is not necessary, users can do it themselves. If it's really important there is goblin. It's not easy to use it to write stuff, but for writing I found one crate for ELF files (also uses goblin, so we can look up how it's done): faerie.

from write_x86_64.

I've tried goblin, object and faerie.
The only thing I got is gimli-rs/object#577
I'm writing my own crate to write any ELF files including executables. Hopefully I'll make it. It will be quite low level through.

from write_x86_64.

Ok, I finally wrote some elfs. Here is the crate, still WIP, but already usable for generating executables: https://crates.io/crates/orecc-elf.
If I won't find such crate for PE, I'll write my own too. With windows PE I have at least some experience :)

from write_x86_64.

Your crate does not explain where the other segments are placed.
Most of the time you need at least 2 segments one that is executable and one that isn't (which thus should be on another memory page for security to work).
How can I know the address of the second segment ?

from write_x86_64.

For some reason, I've deleted this line off docs. It said that if you use ELF::new, segments will be loaded continuously into memory. With x86 first segment will be loaded into 0x08048000 (Not quite, also headers), with x86_64 into 0x400000. Here is why: https://stackoverflow.com/questions/2966426/why-do-virtual-memory-addresses-for-linux-binaries-start-at-0x8048000

from write_x86_64.

@samsa1 Maybe you could suggest a better way of placing a data segment?

from write_x86_64.