Analyzing pe imports and exports
Skill meltedinhex/analyst-ai-pack/skills/analyzing-pe-imports-and-exports
An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.
npx -y skills add meltedinhex/analyst-ai-pack --skill analyzing-pe-imports-and-exportsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Analyzes a PE file's import and export tables to infer capability: mapping imported APIs to behaviors (networking, crypto, injection, persistence), spotting dynamic-resolution stubs, and reading exports of malicious DLLs. Activates for requests to analyze PE imports, inspect the IAT/exports, or infer capability from API usage.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.1 KB, as published. Nobody here has run it
Analyzing PE Imports and Exports
When to Use
- You have a Windows PE and want a fast capability read from its imported APIs.
- You need to identify suspicious API clusters (injection, crypto, anti-analysis) before deeper reversing.
- You are inspecting a malicious DLL's exports to find its callable entry points.
Do not use the import table alone as a verdict — packers stub imports and malware resolves APIs dynamically; a thin IAT can hide real capability.
Prerequisites
pefile(pip install pefile); the sample handled inertly in the lab.
Safety & Handling
- Parse the PE statically; never run it during import analysis.
- Keep the sample password-protected at rest and reference it by hash.
Workflow
Step 1: Parse imports
Enumerate imported DLLs and functions from the import directory (IAT). A sparse IAT plus a
GetProcAddress/LoadLibrary pair suggests dynamic resolution.
python scripts/analyst.py imports sample.exe
Step 2: Map APIs to behaviors
Cluster imports into behavior buckets: networking (Ws2_32, WinINet), process/injection
(VirtualAllocEx, WriteProcessMemory, CreateRemoteThread), crypto (Crypt*, bcrypt),
persistence (Reg*, service APIs), and anti-analysis (IsDebuggerPresent).
Step 3: Inspect exports
For DLLs, list exports (by name and ordinal). Unusual export names or a single exported
DllRegisterServer/ordinal hint at how the module is invoked.
Step 4: Flag dynamic resolution
Note LoadLibrary/GetProcAddress, ordinal-only imports, and tiny IATs as signs that the real
capability is resolved at runtime — escalate to dynamic/RE workflows.
Validation
- Import behavior buckets are consistent with other static signals (strings, sections).
- A thin or stubbed IAT is recognized as a packing/dynamic-resolution indicator, not "benign".
- Exports of a malicious DLL are enumerated with their invocation method identified.
Pitfalls
- Trusting a small IAT as low-capability when imports are resolved dynamically.
- Ignoring delay-load and bound imports.
- Reading ordinal-only imports without resolving them to function names.
References
- See
references/api-reference.mdfor the import/export parser. - Microsoft PE/COFF spec and pefile (linked in frontmatter).