Feature: implement `Timers` plugin.

[digitalisx]

Description

Hello, everyone in the community! 😃 There are some plugins that have not been implemented as they are updated from Volatility 2 to 3. After reviewing this #118, I found that Timers plugin has not yet migrated to 3. So I will be implement (or porting) of Timers plugin according to the Volatility 3 structure.

It will be implement so that the same results as Volatility 2 can be obtained by referring to the existing code.

The difference is that this plugin does not support older operating systems (less than Windows 7). Over time, I think don't need it's worth it to support the under versions.

Command

Help Command

> python3 vol.py -h
windows.timers.Timers Print kernel timers and associated module DPCs.

Run Command

python3 vol.py -f case.vmem windows.timers

Expect Result

• timers plugin migration.
• The cornerstone of developing various plugins that require timers plugin results.

Tasks

• [x] Initialize skeleton code for plugin development.
• [ ] Modify or develop new KDBG and KPCR methods to supply and demand timers-related data.
• [ ] Renderers patch.
• [ ] Testing
• [ ] Code refactoring and lint for review

And this time, I decided to use Draft PR. It's a good idea to request a full version of the Fork Repository and review it right away, but it seems to have the advantage of being able to open a full request from the start of work and anyone can talk to you anytime. (This is one of the great philosophies described in Github.)

Unfortunately, the contribution guide for Volatility 3 has not been documented, but please let us know the organizers' opinions! I'll follow it. 🙂

[paulkermann]

I would wait untill #694 is merged so that the get_kdbg_structure function will actually work. Also, I would get the KPCRs from the KiProcessorBlock and not the kdbg

[digitalisx]

Hello @paulkermann,

Thank you for your opinion. After reviewing the PR you mentioned, I checked that there were some changes in the KDBG function. If necessary, I will test or develop only the corresponding commit by cherry pick.

If possible, could you explain the difference between get_kdbg_structure and get_raw_kdbg_structure functions? I think it will be of great help to me.

Also, in order to access the KiProcessorBlock, it seems that I need to access the KDBG structure first.

If I am mistaken or if there is any improvement, please leave an additional thread.

[paulkermann]

The get_raw_kdbg_structure function just returns the pointer to the kdbg function and does not check whether it is encoded or not. On newer windows versions the KDBG is encoded and only decoded on crashdump writing. Therefore accessing it the way it was would yield invalid pointers.

the get_kdbg_structure function is an abstraction to return the KDBG as if it was always decoded (similar to how volatility2 does).

the KiProcessorBlock symbol is just a global array in the kernel. You don't need the KDBG or something like that

[digitalisx]

@paulkermann, Thank you for your detailed explanation. I understood the current situation and the issue. I will think again about how to obtain _KPCR data and write the code.

[digitalisx]

I tried to access the first block of _KPRCB with the address of the KiProcessorBlock listed in Symbol, but it didn't work well. I'm going to check directly through volshell or windbg within next week.. 🙂 If there is good news, I will update the code or comment.

[paulkermann]

@Digitalisx I kinda tricked you. The KiProcessorBlock is an array of _KPRCB and not _KPCR. You can get the _KPRCB via a call to relative_child_offset of the member Prcb in the _KPCR. In 32 bits it is called PrcbData. In newer windows versions the _KPCR does not contain the Prcb member. In those newer versions you need to subtract the _KPCR size plus a pointer size from the _KPRCB address to get the _KPCR.

[digitalisx]

I've received a lot of feedback and help with the PR, but I think it's going to take some time for it to develop into a testable form (in fact, we need to check the data in the structure and convert it into code..)

I can imagine in my head what structure to follow, but it doesn't seem to work when I try to code it and get it. (I probably need a little bit more understanding of libraries and functions.) 🧐

It's good to be able to exchange opinions and show what's going on through Draft PR, but if there's no progress, I'd like to close it for a while so that other members of the community can contribute.

Perhaps the PR will be closed soon, I will open it again whenever I have the basis or clear preparation to discuss the proposal again. 😊

[ikelos]

Fair enough, you're welcome to keep this PR open if you'd like advice on it as you go? I'm not sure where other people would help to contribute to this plugin other than on here, but if you'd like to close that will be ok too.

[digitalisx]

@ikelos All right, I'll keep that PR.

There are a lot of challenges before I solve this myself, but if we have any members who want to help or participate, please feel free to leave a thread. The new completed PR is good, too! 🙌

It may take a long time, but let's take a leisurely look.

[digitalisx]

It's been a year since Draft PR, but I think I found a key code to fix this while watching closely. (#976)