$npx -y skills add meltedinhex/analyst-ai-pack --skill analyzing-pe-imports-and-exportsAnalyzes a PE file''s import and export tables to infer capability: mapping imported
| 1 | # Analyzing PE Imports and Exports |
| 2 | |
| 3 | ## When to Use |
| 4 | |
| 5 | - You have a Windows PE and want a fast capability read from its imported APIs. |
| 6 | - You need to identify suspicious API clusters (injection, crypto, anti-analysis) before deeper |
| 7 | reversing. |
| 8 | - You are inspecting a malicious DLL's exports to find its callable entry points. |
| 9 | |
| 10 | **Do not use** the import table alone as a verdict — packers stub imports and malware resolves |
| 11 | APIs dynamically; a thin IAT can hide real capability. |
| 12 | |
| 13 | ## Prerequisites |
| 14 | |
| 15 | - `pefile` (`pip install pefile`); the sample handled inertly in the lab. |
| 16 | |
| 17 | ## Safety & Handling |
| 18 | |
| 19 | - Parse the PE statically; never run it during import analysis. |
| 20 | - Keep the sample password-protected at rest and reference it by hash. |
| 21 | |
| 22 | ## Workflow |
| 23 | |
| 24 | ### Step 1: Parse imports |
| 25 | |
| 26 | Enumerate imported DLLs and functions from the import directory (IAT). A sparse IAT plus a |
| 27 | `GetProcAddress`/`LoadLibrary` pair suggests dynamic resolution. |
| 28 | |
| 29 | ```bash |
| 30 | python scripts/analyst.py imports sample.exe |
| 31 | ``` |
| 32 | |
| 33 | ### Step 2: Map APIs to behaviors |
| 34 | |
| 35 | Cluster imports into behavior buckets: networking (`Ws2_32`, `WinINet`), process/injection |
| 36 | (`VirtualAllocEx`, `WriteProcessMemory`, `CreateRemoteThread`), crypto (`Crypt*`, `bcrypt`), |
| 37 | persistence (`Reg*`, service APIs), and anti-analysis (`IsDebuggerPresent`). |
| 38 | |
| 39 | ### Step 3: Inspect exports |
| 40 | |
| 41 | For DLLs, list exports (by name and ordinal). Unusual export names or a single exported |
| 42 | `DllRegisterServer`/ordinal hint at how the module is invoked. |
| 43 | |
| 44 | ### Step 4: Flag dynamic resolution |
| 45 | |
| 46 | Note `LoadLibrary`/`GetProcAddress`, ordinal-only imports, and tiny IATs as signs that the real |
| 47 | capability is resolved at runtime — escalate to dynamic/RE workflows. |
| 48 | |
| 49 | ## Validation |
| 50 | |
| 51 | - Import behavior buckets are consistent with other static signals (strings, sections). |
| 52 | - A thin or stubbed IAT is recognized as a packing/dynamic-resolution indicator, not "benign". |
| 53 | - Exports of a malicious DLL are enumerated with their invocation method identified. |
| 54 | |
| 55 | ## Pitfalls |
| 56 | |
| 57 | - Trusting a small IAT as low-capability when imports are resolved dynamically. |
| 58 | - Ignoring delay-load and bound imports. |
| 59 | - Reading ordinal-only imports without resolving them to function names. |
| 60 | |
| 61 | ## References |
| 62 | |
| 63 | - See [`references/api-reference.md`](references/api-reference.md) for the import/export parser. |
| 64 | - Microsoft PE/COFF spec and pefile (linked in frontmatter). |