source: branches/samhain-2_2-branch/docs/README.sstrip@ 248

Last change on this file since 248 was 1, checked in by katerina, 19 years ago

Initial import

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