pdbconv cant create proper profile for win7 kernel(8199e3319bc8404581e451b565d048b81) about volatility3 HOT 12 OPEN

We've found that some pdb we've retrieved in the past couple of years for old systems (win7) no longer contain all the necessary type information. This can be checked by download the win.zip symbol table pack, and recreating the files using pdbconv. It's likely several of them will no longer produce the symbols that they should. This seems to be because Microsoft no longer publishes the necessary complete pdb files, and the information simply isn't present any more. It's not known why this is, or what can be done about it, but I'll leave this open for a bit so other people with the same problem can stumble upon it...

from volatility3.

Hello, could you provide a run with -vvvvvvv after vol.py ?

from volatility3.

How can i trigger pdbconv over vol.py
I just execute below command
python3 volatility3/framework/symbols/windows/pdbconv.py -g 8199e3319bc8404581e451b565d048b81 -p ntkrnlmp.pdb -o ntkrnlmp.json

from volatility3.

Sorry, I misread and thought it had issue from an automatic vol.py symbols creation.

Could you provide the pdb file, and from where it originates ?

from volatility3.

Base Image : Windows 7 SP1
Installed Updates : KB5039289 and KB5039339

ntkrnlmp.pdb.zip

from volatility3.

Have you tried running the memory sample directly against Volatility, to see if the automatic symbols downloader worked ?

I suppose you got the pdb from here : http://msdl.microsoft.com/download/symbols/ntkrnlmp.pdb/8199e3319bc8404581e451b565d048b81/ntkrnlmp.pdb ?

edit : thanks for the file

from volatility3.

Actually, my goal is different. I need to convert the relevant kernel profile to json to use it with libvmi. But interestingly, something is wrong specifically with this version. My goal is to find the reason.

I couldn't understand the main reason why the maximum address and offset are equal and it cannot read the tpi.

from volatility3.

I just tested with the one acquired here : http://msdl.microsoft.com/download/symbols/ntkrnlmp.pdb/8199e3319bc8404581e451b565d048b81/ntkrnlmp.pdb, and it gave me the 8199e3319bc8404581e451b565d048b8-1.json.xz file.

edit : python3 volatility3/framework/symbols/windows/pdbconv.py -f ntkrnlmp.pdb -g 8199e3319bc8404581e451b565d048b81. I am not familiar with this plugin particularly, but I didn't get any error with this pdb.

from volatility3.

Yes , pdbconv can create json but there's no tpi data that necessary for libvmi
For example, you can compare both output for different kernel
ece191a20cff4465ae46df96c22638451.json

8199e3319bc8404581e451b565d048b81.json

from volatility3.

Ok, I see, I thought it wasn't generating anything, and crashing when reading the TPI layer. I'll investigate rn, but I'm not familiar with this plugin, maybe you'll have to wait for someone else to help you precisely. 👍

from volatility3.

A bug that's been giving me a headache for two nights. I'm just trying to satisfy my curiosity :) Thank you

from volatility3.

I read the TPI layer content (located after the header with a size of 56) :

diff --git a/volatility3/framework/symbols/windows/pdbconv.py b/volatility3/framework/symbols/windows/pdbconv.py
index 82ec31cc..e04fd536 100644
--- a/volatility3/framework/symbols/windows/pdbconv.py
+++ b/volatility3/framework/symbols/windows/pdbconv.py
@@ -274,6 +274,8 @@ class PdbReader:
         length_type = "unsigned short"
         length_len = module.get_type(length_type).size
         info_index = 1
+        print(self._context.layers[info_layer.name].read(0, 512).hex())
+        exit()
         while info_layer.maximum_address - offset > 0:
             self._progress_callback(
                 offset * 100 / info_layer.maximum_address, "Reading TPI layer"

With a "working" pdb :

foo@bar:~$ python3 volatility3/framework/symbols/windows/pdbconv.py -f ntkrnlmp_working.pdb -g 00625D7D36754CBEBA4533BA9A0F3FE22 
0bca3101380000000010000072230000b04005001300ffff040000000380000000000000c84d0000c84d000058010000204f0000000000000a000110030000000100f2f10a000210001000000a8000000a000210001000000c000100320005150000800200000000000000000000000000004c4953545f454e545259363400554c4953545f454e5452593634404000f10a000210031000000a800000220003120d150300230000000000466c696e6b000d150300230000000800426c696e6b00320005150200000205100000000000000000000010004c4953545f454e545259363400554c4953545f454e5452593634404000f1320005150000800200000000000000000000000000004c4953545f454e545259333200554c4953545f454e5452593332404000f10a000210071000000a800000220003120d150300220000000000466c696e6b000d150300220000000400426c696e6b00320005150200000209100000000000000000000008004c4953545f454e545259333200554c4953545f454e5452593332404000f10a000110700000000100f2f10a0002100b1000000a8000000e000112020000000c100000750000000e00081075000000000002000d1000000a0002100e1000000a8000000a000110710000000100f2f10a000210101000000a8000000e0001120200000011100000750000000e00081075000000

With the "non-working" pdb :

foo@bar:~$ python3 volatility3/framework/symbols/windows/pdbconv.py -f ntkrnlmp.pdb -g 8199e3319bc8404581e451b565d048b81
0bca310138000000001000000010000000000000ffffffff04000000ffff030000000000ffffffff00000000ffffffff00000000ffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

As this pdb is quite recent, there may have been some moving parts. However, it looks to me as everything is correctly detected (header), but there are no data to read ?

from volatility3.