1

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.

process explorer string dump

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.

  1. Executable is encrypted (a packer is used?)
  2. Executable is compressed
  3. Strings are encrypted/obfuscated
  4. 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:

  1. Check which packer is being used: https://www.aldeid.com/wiki/PEiD
  2. 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 014ebbf5. To figure out what kind of memory this address is present in, I used WinDbg's !address command.

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?

4
  • Run strings.exe anydesk.exe > foo.txt to find the visible strings belonging to a executable or find the module basevand size and provide that as range not 0 to 80000000
    – blabb
    Feb 4 at 3:30
  • @blabb I have already tried that, and that is the point of contention. strings command doesn't give me enough strings. Feb 4 at 10:03
  • 1
    If you have a string you have an address if you have an address you have a raw byte which is either transformed or a clean slate where it is wriiten to so you alwAys have the option of breaking on read access , write access, memory access , use hardware breakpoints and look and your assumptions that read onlyarea cant a be written is not correct you can use virtual protect to even execute from there
    – blabb
    Feb 4 at 11:49
  • 1
    It turns out that strings are constructed on the fly. At that time the memory is PAGE_EXECUTE_READWRITE. Later the permission is changed to read-only. Feb 8 at 12:41
1

During my analysis I use Floss!, it is an excellent tool and super simple to use, on several occasions I can find the strings I am looking for, you used PEID to check for packers please use a more up-to-date tool like DIE (Detect it Easy), if it is an .EXE file consider analyzing with a professional and updated debbuger like x96DBG(x64dbg/x32dbg), I believe you get better results that way.

1
  • I had used Floss earlier without success, and also DIE. Thanks a lot for suggesting x64dbg/x32dbg. They are amazing. Feb 8 at 11:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.