ELFLS(1)

πŸ’– ELFLS β€” the glow-up era πŸ’–

okay bestie, welcome to the General Commands Manual corner of the internet, where we're about to read ELF files like they're the group chat receipts πŸ’…

✨ NAME ✨

elfls β€” display the contents of an ELF file. that's it, that's the whole vibe, and she ate πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

elfls [OPTIONS] FILE ...

🌸 DESCRIPTION 🌸

so like, elfls takes an ELF file, right, and she examines it β€” reads the program header table and the section header table β€” and then displays a lil synopsis of the contents. no cap, that's the entire job description and she's iconic for it πŸ‘‘


πŸ’… OPTIONS πŸ’…

the flags, the queens, the main characters:

  • -c, --sources β€” include the listing of the source files. show me where you came from πŸ₯Ί
  • -d, --dependencies β€” include the listing of the program's dependencies. who do you rely on, bestie? 🫢
  • -i, --nostr β€” don't treat small entries specially. okay so by default, program and section header entries whose referenced contents are mainly or entirely short, null-terminated strings get listed by just displaying the string (namely interpreter, comment, and note sections). using this option makes those entries display the same as all the other entries. no special treatment, everyone's equal πŸ’€
  • -p, --nopos β€” suppress display of positions of entries within the file. we're not doxxing the offsets today πŸ™ˆ
  • -P, --nophdr β€” suppress the listing of the program header table. bye boo πŸ‘‹
  • -S, --noshdr β€” suppress the listing of the section header table. also bye boo πŸ‘‹
  • -w, --width=N β€” set the maximum width of the lines of the output to N. and get this, N can be zero, which displays each entry on a separate line with no maximum width. format chaos, but make it organized ✨
  • --help β€” display help and exit. she's helpful AND humble 🌈
  • --version β€” display version information and exit. birthday check πŸŽ‚

πŸ‘‘ PROGRAM OUTPUT πŸ‘‘

the output of the program, for each ELF file given on the command line, goes in this exact order:

  1. file name
  2. dependencies
  3. source files
  4. program header table
  5. section header table

The first line of the output shows the name of the file, and the architecture it was created for. The file name will be suffixed with an asterisk * if the file is a binary executable, an ampersand & if the file is a shared library, or a dollar sign $ if the file is a core file. Otherwise, the file is an object file. (This is the only line that is guaranteed to be output. The other information is not shown if the data is not applicable, not present in the file, or suppressed via the command-line options.) so like, that first line is the only one with main character energy that's contractually guaranteed. everything else is a maybe πŸ’–

After the file name is shown the list of shared-object libraries with which the file is dynamically linked, if any.

Next is shown the list of the source files which were used to build the file, presuming this information is available.

The list of entries in the program header table appears next. See below for a detailed description of the output. Binary executables and shared libraries always contain a program header table. always. no exceptions, periodt.

Finally, the entries in the section header table are displayed. See below for a detailed description of the output. ELF files almost always contain a section header table, although they are only required for object files.


🧚 PROGRAM HEADER TABLE 🧚

The entries in the program header table are displayed in following format:

    ind T rwx    pos  size address
  • ind β€” the index number of the entry in the program header table.
  • T β€” a letter indicating the entry's type. The possible types are:
    • B β€” Binary data: machine language instructions or data used by the program proper.
    • P β€” The program header table.
    • D β€” The dynamic linking information section.
    • I β€” The interpreter specification. Typically, this will be the pathname of the dynamic linker.
    • N β€” A note section, the details of which are unspecified.
    • U β€” Exception frame stack data, used by the code to unwind stacks.
  • rwx β€” flags indicating memory permissions for the contents of this entry. r indicates that the contents are to be loaded into readable memory, w indicates that the memory is to be writeable, and x indicates that the memory is to be executable. An s can also appear in the final position, which additionally indicates that this section contains the program's starting point. she starts here, respectfully 🫑
  • pos β€” a hexadecimal number indicating the position within the file of this entry's contents.
  • size β€” a hexadecimal number indicating the size of the entry's contents.
  • address β€” a hexadecimal number indicating the memory address at which to load this entry's contents.

A hexadecimal number at the end of the entry prefixed with a + indicates by how much the size of this entry should be larger in memory than it is in the file (with the extra bytes at the end to be initialized to zeroes). the + is basically the "and then there's more" of it all ✨

Note that, unless --nostr is specified, interpreter and note entries in the program header table are simply displayed as a string indicating their contents.

πŸ“ SECTION HEADER TABLE πŸ“

The entries in the section header table are displayed in the following format:

    ind T rwx    pos  size name
  • ind β€” the index number of the entry in the section header table.
  • T β€” a letter indicating the entry's type. The possible types are:
    • B β€” Program data: machine language instructions or data that are part of the program proper.
    • 0 β€” Zero-initialized program data: memory is to be allocated as usual for this entry, but no data is present in the file. The memory is instead initialized to all bits zero. zero girlies rise up πŸ’€
    • S β€” A table of the symbols used in the file.
    • $ β€” A string table.
    • H β€” A hash table of symbols used for dynamic linking.
    • D β€” The dynamic linking information section.
    • P β€” A procedure linking table.
    • O β€” The global offset table.
    • I β€” The interpreter specification. Typically, this will be the pathname of the dynamic linker.
    • R β€” A list of relocation records.
    • V β€” A section specifying version dependencies for the program.
    • G β€” A section providing debug information.
    • U β€” An exception header data section, used when unwinding the stack.
    • N β€” A note section, the contents of which are unspecified.
    • C β€” A comment section: auxiliary information, typically inserted by the program that created the file. receipts, basically 🧾
  • rwx β€” flags indicating the memory usage and permission for this entry. r indicates that the contents are to be loaded into memory during process execution, w indicates that the contents are to be writeable during process execution, and x indicates that the contents contain machine-executable instructions.
  • pos β€” a hexadecimal number indicating the position within the file of this entry's contents.
  • size β€” a hexadecimal number indicating the size of the entry's contents.
  • name β€” the name of this section. If the section is a list of relocation entries, then the name will be suffixed with a colon and a number, the number indicating the index of the section to which the relocation information applies. Furthermore, several sections types contain information that refer to strings and/or symbols, which are contained in a string table section and/or symbol hash table section. Such sections will have a number in square brackets after the name, indicating the index of this section. An S in square brackets appearing after the name of a string table section indicates the string table that contains the section names. so many brackets, so much lore, we're obsessed 😭
Note that, unless --nostr is specified, interpreter, comment and note entries in the program header table are simply displayed as a string indicating their contents.

Copyright Β© 1999,2011 Brian Rawriter <breadbox@muppetlabs.com>.

License GPLv2+: GNU GPL version 2 or later. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. (say it louder for the people in the back β€” no warranty bestie, fr fr 🚨)


πŸ’œ SEE ALSO πŸ’œ

their cousins, their sisters, their nepo babies, all valid πŸ’…


and that's the whole page, babe πŸ’– brought to you by ELF kickers 3.0, dated May 2011 β€” yeah she's vintage but she still slays, vintage is just pre-loved and we respect it πŸŽ€βœ¨πŸ¦‹

πŸ“¦ where this page comes from