Binary Format Support#

Stringy supports the three major executable formats across different platforms. Each format has unique characteristics that influence string extraction strategies.

ELF (Executable and Linkable Format)#

Used primarily on Linux and other Unix-like systems.

Key Sections for String Extraction#

ELF-Specific Features#

• Symbol Tables: Extract import/export names from .dynsym and .symtab
• Dynamic Strings: Process .dynstr for library names and symbols
• Section Flags: Use SHF_EXECINSTR and SHF_WRITE for classification
• Virtual Addresses: Map file offsets to runtime addresses
• Dynamic Linking: Parse DT_NEEDED entries to extract library dependencies
• Symbol Types: Support for functions (STT_FUNC), objects (STT_OBJECT), TLS variables (STT_TLS), and indirect functions (STT_GNU_IFUNC)
• Symbol Visibility: Filter hidden and internal symbols from exports (STV_HIDDEN, STV_INTERNAL)

Enhanced Symbol Extraction#

The ELF parser now provides comprehensive symbol extraction with:

1. Import Detection: Identifies all undefined symbols (SHN_UNDEF) that need runtime resolution

   • Supports multiple symbol types: functions, objects, TLS variables, and indirect functions
   • Handles both global and weak bindings
   • Maps symbols to their providing libraries using version information

2. Export Detection: Extracts all globally visible defined symbols

   • Filters out hidden (STV_HIDDEN) and internal (STV_INTERNAL) symbols
   • Includes both strong and weak symbols
   • Supports all relevant symbol types

3. Library Dependencies: Extracts DT_NEEDED entries from the dynamic section

   • Provides list of required shared libraries
   • Used in conjunction with version information for symbol-to-library mapping

4. Symbol-to-Library Mapping: Maps imported symbols to their providing libraries

   • Uses ELF version tables (versym and verneed) for best-effort attribution
   • Process: versym index → verneed entry → library filename
   • Falls back to heuristics for unversioned symbols (e.g., common libc symbols)
   • Returns None when version information is unavailable or ambiguous

Implementation Details#

impl ElfParser {
    fn classify_section(section: &SectionHeader, name: &str) -> SectionType {
        // Check executable flag first
        if section.sh_flags & SHF_EXECINSTR != 0 {
            return SectionType::Code;
        }

        // Classify by name patterns
        match name {
            ".rodata" | ".rodata.str1.1" => SectionType::StringData,
            ".data.rel.ro" => SectionType::ReadOnlyData,
            // ... more classifications
        }
    }

    fn extract_imports(&self, elf: &Elf, libraries: &[String]) -> Vec<ImportInfo> {
        // Extract undefined symbols from dynamic symbol table
        // Supports STT_FUNC, STT_OBJECT, STT_TLS, STT_GNU_IFUNC, STT_NOTYPE
        // Handles both STB_GLOBAL and STB_WEAK bindings
        // Maps symbols to libraries using version information
    }

    fn extract_exports(&self, elf: &Elf) -> Vec<ExportInfo> {
        // Extract defined symbols with global/weak binding
        // Filters out STV_HIDDEN and STV_INTERNAL symbols
        // Includes all relevant symbol types
    }

    fn extract_needed_libraries(&self, elf: &Elf) -> Vec<String> {
        // Parse DT_NEEDED entries from dynamic section
        // Returns list of required shared library names
    }

    fn get_symbol_providing_library(
        &self,
        elf: &Elf,
        sym_index: usize,
        libraries: &[String],
    ) -> Option<String> {
        // 1. Get version index from versym table for this symbol
        // 2. Look up version in verneed to find library name
        // 3. Match with DT_NEEDED entries
        // 4. Fallback to heuristics for unversioned symbols
    }
}

Library Dependency Mapping#

The ELF parser implements symbol-to-library mapping using ELF version information:

1. Version Symbol Table (versym): Maps each dynamic symbol to a version index

   • Index 0 (VER_NDX_LOCAL): Local symbol, not available externally
   • Index 1 (VER_NDX_GLOBAL): Global symbol, no specific version
   • Index ≥ 2: Versioned symbol, references verneed entry

2. Version Needed Table (verneed): Lists library dependencies with version requirements

   • Each entry contains a library filename (from DT_NEEDED)
   • Auxiliary entries specify version names and indices
   • Links version indices to specific libraries

3. Mapping Process:

   Copy

   Symbol → versym[sym_index] → version_index → verneed lookup → library_name
   

4. Fallback Strategies:

   • For unversioned symbols: Attempt to match common symbols (e.g., printf, malloc) to libc
   • If only one library is needed: Attribute to that library (least accurate)
   • Otherwise: Return None to avoid false positives

Limitations#

ELF's indirect linking model means symbol-to-library mapping is best-effort:

• Accuracy: Version-based mapping is accurate when version information is present, but many binaries lack version info
• Unversioned Symbols: Symbols without version information cannot be definitively mapped without relocation analysis
• Relocation Tables: PLT/GOT relocations would provide definitive mapping but require complex analysis
• Static Linking: Statically linked binaries have no dynamic section, so all imports have library: None
• Stripped Binaries: Stripped binaries may lack symbol tables entirely

The current implementation is sufficient for most string classification use cases where approximate library attribution is acceptable.

PE (Portable Executable)#

Used on Windows for executables, DLLs, and drivers.

Key Sections for String Extraction#

PE-Specific Features#

• Resources: Extract from VERSIONINFO, STRINGTABLE, and manifest resources
• Import/Export Tables: Process IAT and EAT for symbol names
• UTF-16 Prevalence: Windows APIs favor wide strings
• Section Characteristics: Use IMAGE_SCN_* flags for classification

Enhanced Import/Export Extraction#

The PE parser provides comprehensive import/export extraction:

1. Import Extraction: Extracts from PE import directory using goblin's pe.imports

   • Each import includes: function name, DLL name, and RVA
   • Example: printf from msvcrt.dll
   • Iterates through pe.imports to create ImportInfo with name, library (DLL), and address (RVA)

2. Export Extraction: Extracts from PE export directory using goblin's pe.exports

   • Each export includes: function name, address, and ordinal
   • Note: PE executables typically don't export symbols (only DLLs do)
   • Ordinal is derived from index since goblin doesn't expose it directly
   • Handles unnamed exports with "ordinal_{i}" naming

Resource Extraction (Phase 2 Complete)#

PE resources are particularly rich sources of strings. The PE parser now provides comprehensive resource string extraction:

VERSIONINFO Extraction#

• Extracts all StringFileInfo key-value pairs from VS_VERSIONINFO structures
• Supports multiple language variants via translation table
• Common extracted fields:
  • CompanyName: Company or organization name
  • FileDescription: File purpose and description
  • FileVersion: File version string (e.g., "1.0.0.0")
  • ProductName: Product name
  • ProductVersion: Product version string
  • LegalCopyright: Copyright information
  • InternalName: Internal file identifier
  • OriginalFilename: Original filename
• Uses pelite's high-level version_info() API for reliable parsing
• All strings are UTF-16LE encoded in the resource
• Tagged with Tag::Version and Tag::Resource

STRINGTABLE Extraction#

• Parses RT_STRING resources (type 6) containing localized UI strings
• Handles block structure: strings grouped in blocks of 16
• Block ID calculation: (StringID >> 4) + 1
• String format: u16 length (in UTF-16 code units) + UTF-16LE string data
• Supports multiple language variants
• Extracts all non-empty strings from all blocks
• Tagged with Tag::Resource
• Common use cases: UI labels, error messages, dialog text

MANIFEST Extraction#

• Extracts RT_MANIFEST resources (type 24) containing application manifests
• Automatic encoding detection:
  • UTF-8 with BOM (EF BB BF)
  • UTF-16LE with BOM (FF FE)
  • UTF-16BE with BOM (FE FF)
  • Fallback: byte pattern analysis
• Returns full XML manifest content
• Tagged with Tag::Manifest and Tag::Resource
• Manifest contains:
  • Assembly identity (name, version, architecture)
  • Dependency information
  • Compatibility settings
  • Security settings (requestedExecutionLevel)

Usage Example#

use stringy::extraction::extract_resource_strings;
use stringy::types::Tag;

let pe_data = std::fs::read("example.exe")?;
let strings = extract_resource_strings(&pe_data);

// Filter version info strings
let version_strings: Vec<_> = strings.iter()
    .filter(|s| s.tags.contains(&Tag::Version))
    .collect();

// Filter string table entries
let ui_strings: Vec<_> = strings.iter()
    .filter(|s| s.tags.contains(&Tag::Resource) && !s.tags.contains(&Tag::Version))
    .collect();

Implementation Details#

impl PeParser {
    fn classify_section(section: &SectionTable) -> SectionType {
        let name = String::from_utf8_lossy(&section.name);

        // Check characteristics
        if section.characteristics & IMAGE_SCN_CNT_CODE != 0 {
            return SectionType::Code;
        }

        match name.trim_end_matches('\0') {
            ".rdata" => SectionType::StringData,
            ".rsrc" => SectionType::Resources,
            // ... more classifications
        }
    }

    fn extract_imports(&self, pe: &PE) -> Vec<ImportInfo> {
        // Iterates through pe.imports
        // Creates ImportInfo with name, library (DLL), and address (RVA)
    }

    fn extract_exports(&self, pe: &PE) -> Vec<ExportInfo> {
        // Iterates through pe.exports
        // Creates ExportInfo with name, address, and ordinal
        // Handles unnamed exports with "ordinal_{i}" naming
    }

    fn calculate_section_weight(section_type: SectionType, name: &str) -> f32 {
        // Returns weight values based on section type and name
        // Higher weights indicate higher string likelihood
    }
}

Section Weight Calculation#

The PE parser uses a weight-based system to prioritize sections for string extraction:

Limitations#

The current PE parser implementation provides comprehensive resource string extraction:

• ✅ VERSIONINFO: Complete extraction of all StringFileInfo fields
• ✅ STRINGTABLE: Full parsing of RT_STRING blocks with language support
• ✅ MANIFEST: Encoding detection and XML extraction
• ⚠️ Dialog Resources: RT_DIALOG parsing not yet implemented (future enhancement)
• ⚠️ Menu Resources: RT_MENU parsing not yet implemented (future enhancement)
• ⚠️ Icon Strings: RT_ICON metadata extraction not yet implemented

Future Enhancements:

• Dialog resource parsing for control text and window titles
• Menu resource parsing for menu item text
• Icon and cursor resource metadata
• Accelerator table string extraction

Mach-O (Mach Object)#

Used on macOS and iOS for executables, frameworks, and libraries.

Key Sections for String Extraction#

Mach-O-Specific Features#

• Load Commands: Extract strings from LC_* commands
• Segment/Section Model: Two-level naming scheme
• Fat Binaries: Multi-architecture support
• String Pools: Centralized string storage in __cstring

Load Command Processing#

Mach-O load commands contain valuable strings:

• LC_LOAD_DYLIB: Library paths and names
• LC_RPATH: Runtime search paths
• LC_ID_DYLIB: Library identification
• LC_BUILD_VERSION: Build tool information

Implementation Details#

impl MachoParser {
    fn classify_section(segment_name: &str, section_name: &str) -> SectionType {
        match (segment_name, section_name) {
            ("__TEXT", "__cstring") => SectionType::StringData,
            ("__DATA_CONST", _) => SectionType::ReadOnlyData,
            ("__DATA", _) => SectionType::WritableData,
            // ... more classifications
        }
    }
}

Cross-Platform Considerations#

Encoding Differences#

String Storage Patterns#

• ELF: Strings often in .rodata with null terminators
• PE: Mix of ANSI and Unicode APIs, resources use UTF-16
• Mach-O: Centralized in __cstring, mostly UTF-8

Section Weight Calculation#

Different formats require different weighting strategies:

fn calculate_section_weight(format: BinaryFormat, section_type: SectionType) -> i32 {
    match (format, section_type) {
        (BinaryFormat::Elf, SectionType::StringData) => 10, // .rodata
        (BinaryFormat::Pe, SectionType::Resources) => 9, // .rsrc
        (BinaryFormat::MachO, SectionType::StringData) => 10, // __cstring
                                                             // ... more weights
    }
}

Format Detection#

Stringy uses goblin for robust format detection:

pub fn detect_format(data: &[u8]) -> BinaryFormat {
    match Object::parse(data) {
        Ok(Object::Elf(_)) => BinaryFormat::Elf,
        Ok(Object::PE(_)) => BinaryFormat::Pe,
        Ok(Object::Mach(_)) => BinaryFormat::MachO,
        _ => BinaryFormat::Unknown,
    }
}

Future Enhancements#

Planned Format Extensions#

• WebAssembly (WASM): Growing importance in web and edge computing
• Java Class Files: JVM bytecode analysis
• Android APK/DEX: Mobile application analysis

Enhanced Resource Support#

• PE: Dialog resources, icon strings, version blocks
• Mach-O: Plist resources, framework bundles
• ELF: Note sections, build IDs, GNU attributes

Architecture-Specific Features#

• ARM64: Pointer authentication, tagged pointers
• x86-64: RIP-relative addressing hints
• RISC-V: Emerging architecture support

This comprehensive format support ensures Stringy can effectively analyze binaries across all major platforms while respecting the unique characteristics of each format.