Hidden String Hunt
A small binary contains an obscured string that reveals its true purpose. Use static analysis to locate and extract it.
Investigate
Hints
Hint 1
Check e_lfanew at offset 0x3C first — is it where you'd expect for a normal PE?
Hint 2
Strings are not always in a dedicated section.
Hint 3
This file's DOS stub is unusually large. A bloated stub is itself a red flag worth noticing before you even start scanning it.
Hint 4
Scan the bytes between the MZ header and the PE signature — the whole region, not just the first screen of it.
Submit Findings
Solution
Hidden String Hunt — Solution
The hidden string WEAPON{first_flag} is stored at file offset 0x300, inside the DOS stub region — well past the "This program cannot be run in DOS mode" message, in the padding between the DOS header and the NT headers.
Why it's obscured: Most strings tools with default settings only look for ASCII runs inside mapped sections. The DOS stub is often skipped because it's before the PE signature. Just as importantly here, the stub itself is far bigger than a normal one — real PE files have e_lfanew around 0x80–0xF0; this file's e_lfanew is 0x640. That's not decoration, it's the actual hiding mechanism: a bloated DOS stub gives an attacker room to bury a whole payload before the real header even starts, and most people never think to check whether e_lfanew looks abnormally large in the first place.
How to find it:
- Open the file in a hex editor.
- The
e_lfanewfield at offset0x3Cpoints to the PE signature. Read it — here it's0x640, not the usual~0x80. That size discrepancy is the tell. - Everything between
0x40ande_lfanewis the DOS stub — in this file, over 1.5KB of it, not the usual few dozen bytes. - Use Find to search for the
WEAPON{prefix rather than eyeballing the whole region.
Prerequisites
- f1-binary-anatomy
- Hex editor basics
- PE file structure (DOS header, NT headers)
Methodology
Investigation Methodology
1. Initial Triage
- Load the binary in a hex editor (Ghidra, HxD, ImHex, or the built-in viewer)
- Verify the
MZsignature at offset0x0— confirms PE format - Read
e_lfanewat offset0x3C(little-endian) to locate NT Headers
2. Identify Search Regions
- Standard
stringstools scan mapped sections (.text,.rdata,.data) - The DOS stub (between offset
0x40ande_lfanew) is not a mapped section - This region is commonly used to hide strings, shellcode, or configuration
3. Targeted Search
- Navigate to the DOS stub region in the hex editor
- Search for ASCII strings or the
WEAPON{prefix - Note the file offset of any findings
4. Verification
- Confirm the string is complete and properly formatted
- Cross-reference: does the offset fall within the DOS stub range?
- Document the finding with offset and context
Common Pitfalls
- Running `strings` with default settings and missing the DOS stub region
- Assuming all strings are in `.rdata` or `.data` sections
- Not reading `e_lfanew` correctly (remember: little-endian)
- Confusing file offset with RVA (Relative Virtual Address)
Tools
- Hex editor (HxD, ImHex, 010 Editor, Ghidra)
- Built-in Hex Viewer
- strings command (with -a flag to scan entire file)
References
- Lesson F1: Binary Anatomy — PE header structure
- Microsoft PE/COFF Specification — DOS Header
- Malware Analysis: Hiding data in DOS stub
Extensions & Challenges
- Modify the binary to hide a second string in a different location
- Write a script to automatically scan the DOS stub for ASCII strings
- Research: How do packers abuse the DOS stub region?