re-imports

Analyze import and export tables to fingerprint linked libraries and flag suspicious APIs.

64|9|Updated Aug 17, 2026
One-click install
npx skills add https://github.com/dslsdzc/rev-skills --skill re-imports-dslsdzc
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: re-imports
Source: https://github.com/dslsdzc/rev-skills/tree/main/.claude/skills/re-imports
Command: npx skills add https://github.com/dslsdzc/rev-skills --skill re-imports-dslsdzc

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires pefile.

What problem does it solve? Reverse engineers need to quickly determine which libraries and APIs a binary links against, identify the compiler and runtime versions used, and spot suspicious imports (injection, networking, crypto, anti-debugging) without running the sample. This Skill provides a structured workflow for IAT/EAT analysis across PE, ELF, and Mach-O binaries. ## Core Features & Use Cases - Import/Export Enumeration: List imported and exported functions using objdump, readelf, otool, pefile, and rz-bin across PE, ELF, and Mach-O formats. - Library & Compiler Fingerprinting: Apply FLIRT signatures, GLIBC version strings, language markers (Go, Rust, C++, Delphi, .NET), and imphash to identify toolchains and cluster malware families. - Suspicious API Detection: Flag import patterns for process injection, network callbacks, credential theft, and anti-debugging, then hand off to decompilation or memory-dump workflows. - Use Case: Given an unknown Windows executable, extract its IAT with pefile, compute the imphash for family clustering, and flag CreateRemoteThread-style injection imports before deeper analysis. ## Quick Start Analyze the import table of sample.exe and tell me which libraries it links and whether any imports look suspicious.

Frequently Asked Questions about re-imports

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I list the imported functions of a PE file?▼

Use objdump -p sample.exe and grep for DLL Name entries, or use the Python pefile library to iterate DIRECTORY_ENTRY_IMPORT and print each DLL with its imported function names. For ELF binaries, objdump -T or readelf -s shows undefined symbols as imports.

What is imphash and how is it used for malware clustering?▼

Imphash is a hash of a PE file's normalized import function list, computed via pefile, used to cluster malware variants of the same family. It is more robust than raw import name lists, but packed samples distort it, so unpack first before computing.

Why are some imported APIs missing from the import table?▼

APIs resolved at runtime via GetProcAddress or dlopen/dlsym never appear in the static IAT. Packed binaries also encrypt or redirect the IAT, so you must dump memory after execution or trace the process to recover the real imports.

How do I identify which compiler or language built a binary?▼

Check language-specific markers: Go binaries contain runtime.main and go1.x strings, Rust uses _ZN or __rust_ symbols, C++ uses _Z mangling, and .NET references mscoree. FLIRT signatures in IDA or the ghidra_flirt plugin automate library function matching.

Which imports indicate process injection or malicious behavior?▼

Classic injection chains combine OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. Network exfiltration shows WSAStartup, socket, connect, or WinHttp APIs, while IsDebuggerPresent and NtQueryInformationProcess signal anti-debugging intent.

When should I not rely on static import table analysis?▼

Avoid relying on it when the binary is packed, since the visible IAT is a stub or encrypted placeholder, or when constructors and TLS callbacks overwrite GOT/IAT entries at runtime. In those cases, combine memory dumping and API tracing instead.