/usr/share/doc/samhain/README.sstrip is in samhain 3.1.0-5ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | sstrip is a small utility that removes the contents at the end of an
ELF file that are not part of the program's memory image.
Most ELF executables are built with both a program header table and a
section header table. However, only the former is required in order
for the OS to load, link and execute a program. sstrip attempts to
extract the ELF header, the program header table, and its contents,
leaving everything else in the bit bucket. It can only remove parts of
the file that occur at the end, after the parts to be saved. However,
this almost always includes the section header table, and occasionally
a few random sections that are not used when running a program.
It should be noted that the GNU bfd library is (understandably)
dependent on the section header table as an index to the file's
contents. Thus, an executable file that has no section header table
cannot be used with gdb, objdump, or any other program based upon the
bfd library, at all. In fact, the program will not even recognize the
file as a valid executable. (This limitation is noted in the source
code comments for bfd, and is marked "FIXME", so this may change at
some future date. However, I would imagine that it is a pretty
low-priority item, as executables without a section header table are
rare in the extreme.) This probably also explains why strip doesn't
offer the option to do this.
Shared library files may also have their section header table removed.
Such a library will still function; however, it will no longer be
possible for a compiler to link a new program against it.
As an added bonus, sstrip also tries to removes trailing zero bytes
from the end of the file. (This normally cannot be done with an
executable that has a section header table.)
sstrip is a very simplistic program. It depends upon the common
practice of putting the parts of the file that contribute to the
memory image at the front, and the remaining material at the end. This
permits it to discard the latter material without affecting file
offsets and memory addresses in what remains. However, the ELF
standard permits files to be organized in almost any order. So
although this procedure usually works in practice, it is not meant to
be taken too seriously.
|