readme

ELFkickers是一组elf工具

elftoc reads an ELF file and outputs the file as C code. That is, the
program generates the C source for an initialization of a structure
that should have the same memory image as the original ELF file.

The various parts of the file are mapped to fields of a structure
which is defined at the top of the output. The contents of the program
proper, namely the text and data segments, translate into mere arrays
of bytes (elftoc is not a disassembler), but the ELF-specific
structures are decoded as much as possible. The program tries to
replace hardcoded numbers with preprocessor symbols and compile-time
calculations based on sizeof and offsetof(). Section indices and
memory addresses are identified and given symbolic names.

If the program is successful, one should be able to append the
following to the output:

  #include <unistd.h>
  int main(void) { return write(1, &foo, sizeof foo); }

to produce a valid C program that will output a copy of the original
file.

If the output is not identical to the original, it is typically due to
problems with structure padding and alignment. The most common cause
is when the file as a whole is not an even multiple of 4 bytes in
size. The C structure, using gcc with the 32-bit Intel architecture,
will have one to three bytes of padding at the end to align its size.
In this situation, elftoc inserts an extra field, called _end, to make
this padding explicitly visible. Thus one could append the following
code instead:

  #include <unistd.h>
  int main(void) { return write(1, &foo, offsetof(elf, _out)); }

and still get an exact replica (although the presence of padding at
the end of a file should not cause an ELF file to work any differently
than before).

A more problematic situation is when a field that is itself an array
of structures is not aligned on a 4-byte boundary. The various
substructures of an ELF file are supposed to be aligned within the
file. But if any such structures aren't, then the C code will not be
an exact replica of the original file, and the output of such code may
or may not operate correctly. elftoc will issue a warning in this
situation. (The program could still produce valid output in this case
by representing the misaligned section in the structure as a simple
byte array. However, the whole purpose of elftoc is to expose the ELF
structures within it, so it seems better to proceed and hope for the
best.)

elftoc will also issue warnings if the file appears to be corrupt, or
appears to be created for a completely different architecture.
However, unless the file lacks the ELF magic-number signature, or
contains seriously pathological information, elftoc will always
attempt to produce valid output.