I am trying to reverse engineer an executable.
I am using Process explorer to dump all strings present in the exe image, and from the process's RAM when it is running.
The two dumps return a different number of strings, with the latter (from RAM) returning a much greater number of them. This discrepancy could mean one of the following.
- Executable is encrypted (a packer is used?)
- Executable is compressed
- Strings are encrypted/obfuscated
- Strings are coming from a DLL loaded by the process, or a file opened by it.
I used various tools to rule out 1, and 2. These tools check file entropy and do other statistical checks to figure this out.
Some of the tools I used:
- Check which packer is being used: https://www.aldeid.com/wiki/PEiD
- Statistical analysis for enccryption/compression -
binwalk -EJ <exe-name>, https://github.com/kiathan/Encryption-Detector
To rule out 4 I used process explorer to check each open file handle and loaded DLL. Found nothing suspicious.
For 3, I proceeded as follows.
I attached process to WinDbg, and tried to search for a string from RAM string dump obtained from process explorer.
eg. searching for string "--control".
s -a 0 L?80000000 "--control"
This string was present at location
To figure out what kind of memory this address is present in, I used WinDbg's
Here is the output I got.
Usage: Image Base Address: 01165000 End Address: 01560000 Region Size: 003fb000 ( 3.980 MB) State: 00001000 MEM_COMMIT Protect: 00000002 PAGE_READONLY Type: 01000000 MEM_IMAGE Allocation Base: 00c70000 Allocation Protect: 00000080 PAGE_EXECUTE_WRITECOPY Image Path: C:\Program Files (x86)\<exe-path>.exe Module Name: <exe-name> Loaded Image Name: C:\Program Files (x86)\<exe-path>.exe Mapped Image Name: More info: lmv m <exe-name> More info: !lmi <exe-name> More info: ln 0x14ecbf5 More info: !dh 0xc70000 Content source: 1 (target), length: 7340b
I was expecting this to be an address from
stack or from
heap, but it is instead from the process's
READ ONLY area where memory-mapped file of the executable is present. A read only area cannot store decoded string since you would have to read encoded strings, decode it, and then write them somewhere.
At this point I feel that neither the exe is encrypted, nor compressed, and neither the strings are encoded/encrypted. Still, somehow a lot of strings are not present in the exe, but present in the RAM. How can this be possible?