-
Notifications
You must be signed in to change notification settings - Fork 461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Displays the Windows Interrupt Descriptor Table #974
Comments
Hello, This is likely because when you made the object you specifically created a pointer type. I don't have a windows sample to hand to double check, but if you do this i think you'll get the result you are after.
(On mobile, please forgive any typos!) Edit: also I don't think you'll need to build the module yourself, you should be able to grab it directly from the context by name. Here's a simple example from the Linux pslist plugin as an example, you should be able to do the same with your windows plugin. |
Thank you for your reply. I tried the solution you mentioned before, but it produced an error:
|
Ah okay, in the ISF this symbol doesn't have a type. This is where my lack of windows knowledge won't help. If "cpu_array" is a special type in windows you should be able to create that type at the address for KiProcessorBlock. (Like you did with the pointer at first) Otherwise if it's more of a basic list you can likely do the same as the windows plugin here. If it is just an array of pointers there is another option, but I can't find an example on my phone. I'll be able to give you some better ideas when i get a windows sample in front of me, in the meantime hopefully someone with more windows knowledge can jump in. |
volatility 2:
output:
volatility 3
output:
As you can see, I've been able to get the first element of the cpu_array array in volatility 2. Edit: I see that volatility 3 uses Edit: I tried to set |
I can currently get the first IDT record from the first CPU, and I'm not sure how I can get all of them. def _generator(self):
kernel = self.context.modules[self.config["kernel"]]
layer_name = kernel.layer_name
symbol_table = kernel.symbol_table_name
kvo = self.context.layers[layer_name].config["kernel_virtual_offset"]
ntkrnlmp = self.context.module(symbol_table, layer_name=layer_name, offset=kvo)
KiProcessorBlock = ntkrnlmp.object(
object_type="pointer",
layer_name=layer_name,
offset=ntkrnlmp.get_symbol("KiProcessorBlock").address)
kpcrb_offset = KiProcessorBlock.dereference().vol.offset
kpcr_offset = ntkrnlmp.get_type("_KPCR").relative_child_offset("PrcbData")
kpcr = ntkrnlmp.object(
object_type="_KPCR",
layer_name=layer_name,
offset=kpcrb_offset - kpcr_offset,
absolute=True)
idt_struct = kpcr.IDT.dereference()
idt = _KIDTENTRY(idt_struct)
module = self.get_module(self.context, layer_name, symbol_table, idt.Address)
yield (0, (format_hints.Hex(idt.Selector), format_hints.Hex(idt.Address), module)) Output:
Its output is the same as the first output I got in volatility 2. |
I got all the IDT entries in the first CPU by adding an offset to the address of the first IDT entry. Now maybe I should try to get all the IDT entries in the CPU.🥳 |
I solved the problem. |
Great stuff @Ma1icious - glad you managed to make something that works for you. You beat me to getting a Windows sample to test with! If you do make a plugin that you are happy with, do consider making a pull request to share your knowledge with everyone. I'd also recommend taking a look at the volatility slack channel, it's sometimes easier to ask a quick question there. |
I tested it and it was able to output the same results as in volatility 2 (x86 only, of course). I'm going to submit the code to share with everyone, although I didn't write it elegantly. |
That's great, making a pull request allows everyone to take a look at the code and offer suggestions. For example, I think yiu can get your e.g. These provide the same output:
|
Oh, right! They are the same! Thank you for pointing out, I will make corresponding modifications. |
Sorry it took me so long to get round to this, @eve-mem is right, it should be possible to just construct the type from its name. Sadly the link between the name and the type isn't present in windows PDBs (as far as I'm aware), and we haven't allowed the convenience function to specify a type, but that's something I think we can add without too much trouble, so eventually it would look something like ntkrnlmp.object_from_symbol("KiProcessorBlock", object_type = "<NAME_OF_OBJECT_TYPE>")...
Here, you're only getting one response, because you asked volatility to make pointer at the position of the first element of the array (so you only got one item). To make an array (which you should then be able to iterate over) should be able to specify "array" as the
Which should turn your single pointer into a full array that you can iterate over. Sadly it needs to act an existing object of some kind, because it's essentially a call to Hope all that helps! Feel free to ask more here, or catch us on slack if you'd like more interactive answers... 5:) |
There is a plugin showing windows IDT in volatility 2, but not in volatility 3.
I tried to analyze the code in volatility 2 and migrate it to volatility 3. But I have a problem.
In volatility 2, we can use in _KDDEBUGGER_DATA64 class "self.KiProcessorBlock.Dereference()" to get the cpu_array, but returned in the volatility of 3 different results.
In volatility 2:
In volatility 3:
Does anyone know how to solve this problem? Or does anyone know how to get IDT content?
The text was updated successfully, but these errors were encountered: