._TEXT

This points to the text segment (not the .text section). This makes locating the text segment possible without having to parse the program headers.

._DATA

This points to the data segment (not the .data section). This makes locating the data segment possible without having to parse the program headers.

.stack

This points to one of several possible stack segments depending on the number of threads. Without a section named .stack, it would be far more difficult to know where the actual stack of the process is. You would have to look at the value of the %rsp register and then see which program header segments contain address ranges that match the stack pointer value.

.heap

Similar to the .stack section, this points to the heap segment, also making identification of the heap much easier, especially on systems where ASLR moves the heap to random locations. On older systems, it was always extended from the data segment.

.bss

This section is not new with ECFS. The only reason it is mentioned here is that with an executable or shared library, the .bss section contains nothing, since uninitialized data takes up no space on disk. ECFS represents the memory, however, and the .bss section is not actually created until runtime. The ECFS files have a .bss section that actually reflects the uninitialized data variables being used by the process.

.vdso

This points to the [vdso] segment that is mapped into every Linux process containing code that is necessary for certain glibc system call wrappers to invoke the real system call.

.vsyscall

Similar to the .vdso code, the .vsyscall page contains code for invoking only a handful of virtual system calls. It has been kept around for backwards compatibility. It may prove useful to know this location during reverse engineering.

.procfs.tgz

This section contains the entire directory structure and files for the /proc/$pid of the process that was captured by the ECFS handler. If you are an avid forensic analyst or programmer, then you probably already know how useful the information contained in the proc filesystem is. There are well over 300 files within /proc/$pid for a single process.

.prstatus

This section contains an array of struct elf_prstatus structures. Very important information pertaining to the state of the process and its registers is stored in these structures:

struct elf_prstatus
  {
    struct elf_siginfo pr_info;         /* Info associated with signal.  */
    short int pr_cursig;                /* Current signal.  */
    unsigned long int pr_sigpend;       /* Set of pending signals.  */
    unsigned long int pr_sighold;       /* Set of held signals.  */
    __pid_t pr_pid;
    __pid_t pr_ppid;
    __pid_t pr_pgrp;
    __pid_t pr_sid;
    struct timeval pr_utime;            /* User time.  */
    struct timeval pr_stime;            /* System time.  */
    struct timeval pr_cutime;           /* Cumulative user time.  */
    struct timeval pr_cstime;           /* Cumulative system time.  */
    elf_gregset_t pr_reg;               /* GP registers.  */
    int pr_fpvalid;                     /* True if math copro being used.  */
  };

.fdinfo

This section contains ECFS custom data that describes the file descriptors, sockets, and pipes being used for the processes' open files, network connections, and inter-process communication. The header file, ecfs.h, defines the fdinfo_t type:

typedef struct fdinfo {
        int fd;
        char path[MAX_PATH];
        loff_t pos;
        unsigned int perms;
        struct {
                struct in_addr src_addr;
                struct in_addr dst_addr;
                uint16_t src_port;
                uint16_t dst_port;
        } socket;
        char net;
} fd_info_t;

The readecfs utility parses and displays the file descriptor information nicely, as shown when looking at an ECFS snapshot for sshd:

        [fd: 0:0] perms: 8002 path: /dev/null
        [fd: 1:0] perms: 8002 path: /dev/null
        [fd: 2:0] perms: 8002 path: /dev/null
        [fd: 3:0] perms: 802 path: socket:[10161]
        PROTOCOL: TCP
        SRC: 0.0.0.0:22
        DST: 0.0.0.0:0

        [fd: 4:0] perms: 802 path: socket:[10163]
        PROTOCOL: TCP
        SRC: 0.0.0.0:22
        DST: 0.0.0.0:0

.siginfo

This section contains signal-specific information, such as what signal killed the process, or what the last signal code was before the snapshot was taken. The siginfo_t struct is stored in this section. The format of this struct can be seen in /usr/include/bits/siginfo.h.

.auxvector

This contains the actual auxiliary vector from the bottom of the stack (the highest memory address). The auxiliary vector is set up by the kernel at runtime, and it contains information that is passed to the dynamic linker at runtime. This information may prove valuable in a number of ways to the advanced forensic analyst.

.exepath

This holds the string of the original executable path that was invoked for this process, that is, /usr/sbin/sshd.

.personality

This contains personality information, that is, ECFS personality information. An 8-byte unsigned integer can be set with any number of personality flags:

#define ELF_STATIC (1 << 1) // if it's statically linked (instead of dynamically)
#define ELF_PIE (1 << 2)    // if it's a PIE executable
#define ELF_LOCSYM (1 << 3) // was a .symtab symbol table created by ecfs?
#define ELF_HEURISTICS (1 << 4) // were detection heuristics used by ecfs?
#define ELF_STRIPPED_SHDRS (1 << 8) // did the binary have section headers?

.arglist

Contains the original 'char **argv' stored as an array in this section.