Issue with windows.strings plugin

[crocodile-on-the-nile]

Describe the bug
windows.strings plugin does not display a message when a specific string is identified in the memory of a process

Context
Volatility Version: Volatility 3 Framework 2.4.1
Operating System: Windows 10
Python Version: 3.9.9
Suspected Operating System: Windows 10 Build 1809
Command: python vol.py -f ..\DESKTOP-N81KBM0-20221121-235651.dmp windows.strings --strings-file=..\extracted_strings.txt

Details of experiment

Step 1: Acquiring the memory dump

On a Windows 10 computer, a text file was opened in notepad.exe. The text file contained the target string mysupersecretfancypassword. The process ID of notepad.exe is 6896. Another text file opened in wordpad.exe contained the same target string. For now, the focus is only on notepad.

Memory was acquired from this computer as DESKTOP-N81KBM0-20221121-235651.dmp using DumpIt.exe.

Step 2: Extracting target string with offset from the memory dump

Strings.exe was used to extract all the strings from this memory dump into a text file. The command used was:

strings64.exe -o DESKTOP-N81KBM0-20221121-235651.dmp > strings_from_dump.txt

Four lines from strings_from_dump.txt that contained the target string and its offset were copied into extracted_strings.txt

The contents of extracted_strings.txt is as follows:

type ..\extracted_strings.txt
2065948033:mysupersecretfancypassword\par
2201153780:mysupersecretfancypassword
2443052438:mysupersecretfancypassword
2444601355:mysupersecretfancypassword

Step 3: Attempting to find context for strings in extracted_strings.txt

The goal was to use windows.strings plugin to prove that the strings in extracted_strings.txt can be found within the memory of notepad.exe with PID 6896.

Since the following command took a long time to complete,

python vol.py -f ..\DESKTOP-N81KBM0-20221121-235651.dmp windows.strings --strings-file=..\extracted_strings.txt

The PID of notepad was included in the previous command, as:

python vol.py -f ..\DESKTOP-N81KBM0-20221121-235651.dmp windows.strings --pid 6896 --strings-file=..\extracted_strings.txt

Expected behavior

The expected output was a message like 'String found'. However, there was only a message indicating that the string search is progressing.

Example output

Output 1:

python vol.py -f ..\DESKTOP-N81KBM0-20221121-235651.dmp windows.strings --pid 6896 --strings-file=..\extracted_strings.txt
Volatility 3 Framework 2.4.1
Progress:  100.00               PDB scanning finished
String  Physical Address        Result
Progress:    0.00               Creating mapping for task 6896
mysupersecretfancypassword\par
Progress:   25.00               Matching strings in memory
mysupersecretfancypassword
Progress:   50.00               Matching strings in memory
mysupersecretfancypassword
Progress:   75.00               Matching strings in memory
Progress:  100.00               Matching strings in memory

Output 2:

python vol.py -vv -f ..\DESKTOP-N81KBM0-20221121-235651.dmp windows.strings --pid 6896 --strings-file=..\extracted_strings.txt

Volatility 3 Framework 2.4.1
INFO     volatility3.cli: Volatility plugins path: ['C:\Users\ten\Documents\volatility3\volatility3\plugins', 'C:\Users\ten\Documents\volatility3\volatility3\framework\plugins']
INFO     volatility3.cli: Volatility symbols path: ['C:\Users\ten\Documents\volatility3\volatility3\symbols', 'C:\Users\ten\Documents\volatility3\volatility3\framework\symbols']
INFO     volatility3.framework.automagic: Detected a windows category plugin
INFO     volatility3.framework.automagic: Running automagic: ConstructionMagic
INFO     volatility3.framework.automagic: Running automagic: SymbolCacheMagic
INFO     volatility3.framework.automagic: Running automagic: LayerStacker
INFO     volatility3.schemas: Dependency for validation unavailable: jsonschema
DEBUG    volatility3.schemas: All validations will report success, even with malformed input
INFO     volatility3.schemas: Dependency for validation unavailable: jsonschema
DEBUG    volatility3.schemas: All validations will report success, even with malformed input
DEBUG    volatility3.framework.automagic.windows: Detecting Self-referential pointer for recent windows
DEBUG    volatility3.framework.automagic.windows: DtbSelfRef64bit test succeeded at 0x1aa000
DEBUG    volatility3.framework.automagic.windows: DTB was found at: 0x1aa000
INFO     volatility3.schemas: Dependency for validation unavailable: jsonschema
DEBUG    volatility3.schemas: All validations will report success, even with malformed input
INFO     volatility3.schemas: Dependency for validation unavailable: jsonschema
DEBUG    volatility3.schemas: All validations will report success, even with malformed input
DEBUG    volatility3.framework.automagic.stacker: Stacked layers: ['IntelLayer', 'WindowsCrashDump64Layer', 'FileLayer']
INFO     volatility3.framework.automagic: Running automagic: WinSwapLayers
INFO     volatility3.framework.automagic: Running automagic: KernelPDBScanner
DEBUG    volatility3.framework.automagic.pdbscan: Kernel base determination - searching layer module list structure
DEBUG    volatility3.framework.automagic.pdbscan: Setting kernel_virtual_offset to 0xf80767a1f000
DEBUG    volatility3.framework.symbols.windows.pdbutil: Using symbol library: ntkrnlmp.pdb\99DE394F56795BA4DDAEBA33444A9F1A-1
INFO     volatility3.schemas: Dependency for validation unavailable: jsonschema
DEBUG    volatility3.schemas: All validations will report success, even with malformed input
INFO     volatility3.framework.automagic: Running automagic: SymbolFinder
INFO     volatility3.framework.automagic: Running automagic: KernelModule

String  Physical Address        Result
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_PO_PROCESS_ENERGY_CONTEXT
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_EPROCESS_QUOTA_BLOCK
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_PAGEFAULT_HISTORY
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_JOB_ACCESS_STATE
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_JOB_CPU_RATE_CONTROL
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_JOB_NET_RATE_CONTROL
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_JOB_NOTIFICATION_INFORMATION
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_PSP_STORAGE
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_ACTIVATION_CONTEXT_DATA
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_FLS_CALLBACK_INFO
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_ASSEMBLY_STORAGE_MAP
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_DBGKP_ERROR_PORT
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_CI_NGEN_PATHS
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_WNF_SCOPE_MAP
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_EX_WNF_SUBSCRIPTION
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_ETW_EVENT_CALLBACK_CONTEXT
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_EX_TIMER
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_ETW_SOFT_RESTART_CONTEXT
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_ETW_STACK_CACHE
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_ETW_PERFECT_HASH_FUNCTION
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_HAL_PMC_COUNTERS
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_DEVICE_NODE_IOMMU_EXTENSION
DEBUG    volatility3.framework.symbols: Unresolved reference: symbol_table_name1!_SCSI_REQUEST_BLOCK
Progress:    0.00               Creating mapping for task 6896
mysupersecretfancypassword\par
Progress:   25.00               Matching strings in memory
mysupersecretfancypassword
Progress:   50.00               Matching strings in memory
mysupersecretfancypassword
Progress:   75.00               Matching strings in memory
Progress:  100.00               Matching strings in memory

Additional information

All the pages in memory associated with notepad.exe were dumped using windows.memmap:

python vol.py -f ..\DESKTOP-N81KBM0-20221121-235651.dmp windows.memmap --pid 6896 --dump

Strings.exe was used against the dumped process memory, and the extracted strings were stored in strings_from_dumped_process.txt

strings64.exe pid.6896.dmp > strings_from_dumped_process.txt

Within strings_from_dumped_process.txt, when a simple find operation was performed in Notepad++, it is possible to find the instance of mysupersecretfancypassword.

The target string mysupersecretfancypassword is present within the memory of notepad.exe, but is not identified by windows.strings plugin.

Could you please look into this?

[ikelos]

Your expected output doesn't match what the plugin does. All plugins within volatility 3 return a table of the results data, usually that could be used by another tool. The plugin found three hits at three of the four offsets (as you can see in example 1, they're interspersed between the progress callbacks, one is directly after Creating mapping for task 6896), what's strange is that there are no offsets or processes output alongside them, which I can't explain.

The plugin yields these values here and offset is part of the loop it's traversing so I can't see how that value isn't being output, but we can investigate further, thanks for letting us know...

[kookiecrack]

Hi,
On a related topic, can i suggest that the progress status doesn't interrupt the results? I piped std error to a separate file as a workaround. Thanks!

[ikelos]

Hi @kookiecrack, since the default output renderer is the quick output, which doesn't gather the data, but returns it as quickly as possible, it may return it whilst the scans are still ongoing. If you wish the output to be uninterrupted you can choose a different renderer (such as the pretty output) you can use -r pretty to get the output after all searching has happened or use --quiet or -q to silence the progress output. If this isn't sufficient please feel free to file a new ticket to discuss the issue... 5:)

[kookiecrack]

thank you! That's useful to know, i will test them out.

[gitter-sudo]

hi, I'm experiencing an issue related to the windows.strings plugin.
on a virtual box VM (OS W10) I captured RAM using both
FTK tool
and
VBoxManage debugvm dumpvmcore command
strings sysinternal tool finds the string I search for but windows.strings plugin doesn't indicate which process(es) this string belongs to.

here command I used
python3 vol.py -f mem_file -r pretty windows.strings.Strings --strings-file 'strings_file' > output_file

output always shows FREE MEMORY instead PID of related precess(es)

any idea?
thanks

[ikelos]

Hiya, probably worth checking the output of pslist to make sure volatility can see the processes (if there's no list there, volatility won't be able to figure it out). Other than that I'd suggest checking the debugging information, but really the filter option is the only thing that could interfere with it, and that has code to explicitly not filter if the pid list is empty?

[gitter-sudo]

thanks @ikelos , I tried using pslist and I confirm it recognizes pid of processes.
about your tip: how can I check the debugging information to throubleshoot the issue?

[ikelos]

Hiya, given that pslist does return, you'd probably need to modify the python to see why pidlist is empty or not being hit in the filter... The debugging information I mentioned was by running vol.py -vvvvvvv rather than just vol.py. I don't think that'll provide anything useful extra though.

Theoretically you could change this line to just return filter_func, which should essentially disable all pid filtering (but that's kinda what should be happening already). If you give those a try and let us know how you get on, we can try to figure out what's going on?

[gitter-sudo]

hi,this is how I changed pslist.py by your tip:

    ...
    filter_func = lambda _: False
    return filter_func
    # FIXME: mypy #4973 or #2608
    pid_list = pid_list or []
    ...

then I used the command

python3 vol.py -f mem_file -r pretty windows.strings.Strings --strings-file 'strings_file' > output_file

same result: output always shows FREE MEMORY instead PID of related precess(es) and nothing else

[ikelos]

Hmmm, then it gets more tricky... Since we basically disabled the filter function (or made it always return False) then this line should mean that the process list is traversed completely. And you're not even getting a process id of unknown, which suggests that the list of process entries isn't getting doesn't contain anything, or an exception happens before it gets there I suppose?

Could you please attach the output from running your command without the redirect (or making sure to redirect stderr as well) and with vol.py -vvvvvvv instead of just vol.py?

[gitter-sudo]

volatility-debug.txt
here the output; I hope it'll help

[gitter-sudo]

hi @ikelos,did you find any useful information?

[ikelos]

I'm afraid not, there's nothing unusual in the debug output, so it's possible the contents of the strings file don't accurately reflect the correct offsets?

It might also be worth checking that the offsets in the strings text file and in decimal?

[gitter-sudo]

before using the command:
python3 vol.py -f mem_file -r pretty windows.strings.Strings --strings-file 'strings_file' > output_file

in 'string_file' I put the output of the strings sysinternal tool in the form
offset:string

I checked on strings tool docs for useful option to achieve the result you suggested but there is no way to change for decimal or other offset formats.
could be I don't get what you are suggesting to me (?)