Qdb x86-64 support & Windows kernel structures

[HackingFrogWithSunglasses]

This PR adds x86-x64 support to QDB and adds limited implementation of additional Windows kernel structures such as _KTHREAD, _KPROCESS, _KPCR, _KPCRB and _KNODE. As well as adding their pointers to the correct offset in GS.

Checklist

Which kind of PR do you create?

• This PR only contains minor fixes.
• This PR contains major feature update.
• [*] This PR introduces a new function/api for Qiling Framework.

Coding convention?

• [*] The new code conforms to Qiling Framework naming convention.
• [*] The imports are arranged properly.
• [*] Essential comments are added.
• The reference of the new code is pointed out.

Extra tests?

• No extra tests are needed for this PR.
• I have added enough tests for this PR.
• [*] Tests will be added after some discussion and review.

Changelog?

• This PR doesn't need to update Changelog.
• [*] Changelog will be updated after some proper review.
• Changelog has been updated in my PR.

Target branch?

• [*] The target branch is dev branch.

One last thing

• [*] I have read the contribution guide

---

[elicn]

Hi @HackingFrogWithSunglasses, welcome to Qiling and thanks for the contribution.
The modifications around the Windows kernel structures are problematic since they shadow user structures [both are on GS, but kernel and user do not share the same GS]. Also, the new structures use native ctypes types (e.g. c_void_p) which make the structure defined according to the hosting system rather than the one that should be emulated.

My suggestion is that we take that step by step, and first incorporate the changes for QDB (given a review from its owner), and then move on to the changes in Windows. Would you be able to split the PR into two different PRs, so we can review and merge them separately?

[HackingFrogWithSunglasses]

Hi @HackingFrogWithSunglasses, welcome to Qiling and thanks for the contribution. The modifications around the Windows kernel structures are problematic since they shadow user structures [both are on GS, but kernel and user do not share the same GS]. Also, the new structures use native ctypes types (e.g. c_void_p) which make the structure defined according to the hosting system rather than the one that should be emulated.

My suggestion is that we take that step by step, and first incorporate the changes for QDB (given a review from its owner), and then move on to the changes in Windows. Would you be able to split the PR into two different PRs, so we can review and merge them separately?

Hi, thanks. You are welcome.

As of present the initializer for those additional structures only gets called when IsDriver() is true in the loader. From my understanding of the code flow, that means that the pointers should not be mapped into the GS register unless we're loading a driver.

Nonetheless, I am more than happy to split this PR out certainly. I only submitted a PR because I needed this for my own project and saw it was not present.

I'll split the PRs out and we can go from there!

[HackingFrogWithSunglasses]

I have submitted - #1218 and #1219

Apologies if the code is a bit hacky... As I say, I needed to implement this myself and I figured I might as well contribute it back.