PrintKey not displaying all registry key values

[nate-ray]

Describe the bug windows.registry.printkey.PrintKey does not correctly display the value of all registry keys. Specific example below is for a Win7PS1x64 host infected with Kotver malware. When using PrintKey module the Data value is not displayed for all registry keys.

Context Volatility Version: Volatility 3 Framework 1.0.0-beta.1 Operating System: Window 10 Enterprise 1903 build 18362.778 Python Version: Python 3.7 Suspected Operating System: Windows 7 SP1 x64 Command: windows.registry.printkey.PrintKey --offset 0xf8a002747410 --key Software\vaoju

To Reproduce Steps to reproduce the behavior: Behavior may be limited to the keys greater than a certain length or due to expected encoding. Kotver stores obfuscated JS and powershell in registry values.

Volatility 3 Framework 1.0.0-beta.1 returns the following

Expected behavior When using Volatility2.6 registry values are properly parsed and displayed using the following command --profile=Win7SP1x64 printkey -o 0xfffff8a002747410 -K Software\vaoju Volatility2.6 returns the following result

[ikelos]

@nate-ray Would you be able to export those registry keys, so we could recreate the issue on a clean image? I don't know what kind of data's stored in the key, but you can change it as long as it still recreates the issue...

[ikelos]

You could also try rerunning the plugin with -vvvv (or more) to get the debug output, which should include any exceptions that occur which would result in the hyphen that you're seeing. That might also help us distinguish what's going wrong...

[nate-ray]

Command C:\Program Files\Python37\python.exe" C:\Users\DFIR\tools\volatility3\vol.py -f G:\NCI9Ul8WAC11CB0916qLYe -vvv windows.registry.printkey.PrintKey --offset 0xf8a002747410 --key Software\vaoju

Debug output

DEBUG    volatility.framework.automagic.pdbscan: Kernel base determination - using KDBG structure for kernel offset
DEBUG    volatility.framework.automagic.pdbscan: Using symbol library: ntkrnlmp.pdb\C609226E66184ADE9F0149850730578C-2
INFO     volatility.schemas: Dependency for validation unavailable: jsonschema
DEBUG    volatility.schemas: All validations will report success, even with malformed input
DEBUG    volatility.framework.automagic.pdbscan: Setting kernel_virtual_offset to 0xf80003262000

Last Write Time Hive Offset     Type    Key     Name    Data    Volatile
INFO     volatility.schemas: Dependency for validation unavailable: jsonschema
DEBUG    volatility.schemas: All validations will report success, even with malformed input
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_KTMNOTIFICATION_PACKET
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_EPROCESS_QUOTA_BLOCK
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_PAGEFAULT_HISTORY
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_PSP_CPU_QUOTA_APC
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_JOB_ACCESS_STATE
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_ACTIVATION_CONTEXT_DATA
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_FLS_CALLBACK_INFO
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_ASSEMBLY_STORAGE_MAP
DEBUG    volatility.framework.symbols: Unresolved reference: nt_symbols1!_SCSI_REQUEST_BLOCK
DEBUG    volatility.framework.symbols.windows.extensions.registry: Unexpected node type encountered when traversing subkeys: nt_symbols1!_CM_KEY_INDEX, signature: n
DEBUG    volatility.framework.symbols.windows.extensions.registry: Unexpected node type encountered when traversing subkeys: nt_symbols1!_CM_KEY_INDEX, signature: n
DEBUG    volatility.plugins.windows.registry.printkey: Layer hive0xf8a002747410 cannot map offset: 3133439

2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     plgpdrzgpl      -       FalseDEBUG    volatility.plugins.windows.registry.printkey: Layer hive0xf8a002747410 cannot map offset: 4186111

2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     fusn    -       False
2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     rpoprksu        QfELyIvLbUG1lA==        False
2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     qhvj    SvRew9zMZZ/TdswTyC0il5nS+x9+eRI=        False
2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     bwaruzkdbw      SvEKwN2bMA8MJUs08H2eHY8=        False
2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     nbwe    FqFax4mZZLzhDgVxCKDcvYPIJ11x2Ekdy64A661ANvSieXi9g16nMYcTR5ABjvIRJniwC/er9mARnsgfHrpwV35FeYm6x7EyRY60    FalseDEBUG    volatility.plugins.windows.registry.printkey: Layer hive0xf8a002747410 cannot map offset: 2191359

2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     qgpfrp  -       False
2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     minwuzvum       FPFalYmbN+71oR3own2QhwbhYuwWRWZQrkfLUvOeBzU8KNghUZ+KTTOqcyP7iITplA==    FalseDEBUG    volatility.plugins.windows.registry.printkey: Layer hive0xf8a002747410 cannot map offset: 1945599

2017-07-19 13:29:40.000000      0xf8a002747410  REG_SZ  CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     leuta   -       FalseDEBUG    volatility.plugins.windows.registry.printkey: Layer hive0xf8a002747410 cannot map offset: 2322431

2017-07-19 13:29:40.000000      0xf8a002747410  REG_BINARY      CMI-CreateHive{D43B12B8-09B5-40DB-B4F6-F6DFEB78DAEC}\Software\vaoju     0d5a1b0914      -       False

[ikelos]

Hmmm, so it's trying to read the data but it can't map the offset, and yet vol2 can read it fine (assuming the data recovered is valid)? 5:S The implementations shouldn't be too different, but it does feel like we'd have a hard time replicating it with just the registry values... 5:S @superponible Any thoughts on this? Are the unexpected signatures something important?

[superponible]

There's at least one bug in the registry mapping. I ran a kovter sample in a VM and reproduced the issue. Have it partially fixed, but I think there may be a little more to do, but wanted to let you know I'm working on it.