pdbconv cant create proper profile for win7 kernel(8199e3319bc8404581e451b565d048b81)

[kaganisildak]

After installing KB5039289 and KB5039339 into Win7 machine, pdbconv cant create proper profile for it.

    Version: 64-bit Windows 7
    PE GUID: 66483bb65de000
    PDB GUID: 8199e3319bc8404581e451b565d048b81

I tried to debug but I couldn't go into much detail. From what I understand it cannot read TPI. The maximum address and offset are equal to each other and it gets blocked here. https://github.com/volatilityfoundation/volatility3/blob/351db0e5730f1d1017141d57ee937d3f3d1fbc94/volatility3/framework/symbols/windows/pdbconv.py#L277

[Abyss-W4tcher]

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

[kaganisildak]

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

[Abyss-W4tcher]

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 ?

[kaganisildak]

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

ntkrnlmp.pdb.zip

[Abyss-W4tcher]

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

[kaganisildak]

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.

[Abyss-W4tcher]

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.

[kaganisildak]

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

[Abyss-W4tcher]

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. 👍

[kaganisildak]

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

[Abyss-W4tcher]

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 ?

[ikelos]

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...