KiSelectNextThread equivalent function needed

Hello all. I’m new to kernel mode development and was reading Windows Internals 6th Edition Part 1 book where I discovered the KiSelectNextThread function. However it appears that this function is not exported by the kernel or is it ? Assuming that it’s not exported I would like to find an equivalent for my purpose. I need a kernel mode API that can access/return the
_KTHREAD structure. I’m not certain but I believe this _KTHREAD structure directly or indirectly allows me to access address space of the thread before a context switch is performed. Hope the above details are clear. Thanks for reading.

The KTHREAD structure is considered internal and changes on (it seems) a daily basis, and it’s contents will change at times you’re not able to know about, so it’s generally considered opaque …

What problem are you attempting to solve with this solution?

1 Like

craig thanks. I’m not able to share those details but what I can say is that I need access to the address space of the thread that is to be executed next.

Ah, another “if only I could tell you, but it’s a secret of the universe which cannot be revealed …” …

If I only had a dollar for every “I could tell you, but it’s a secret of the universe which cannot be revealed” tidbit of knowledge but which turns out to be stirring the coffee once clockwise, then once counter-clockwise rather than the traditional “twice clockwise” secret of the universe I’d be a lot closer to retirement!

Let me take a guess … you want to discern the next thread that will be executed by the scheduler to inject a code segment/ determine if someone has injected a code segment/ prevent someone else from injecting a code segment … probably for some groundbreaking anti-malware technology that will revolutionize the industry and render all of the competing products obsolete overnight that you can patent and sell to the highest bidder for a tidy nine digit sum, yes?

Well, aside from the fact that the “next thread scheduled” changes every femtosecond based on what APC/ DPC is coming up or what ISR/ IPI event is arriving off the PCIe bus or processor cache line bus and is highly processor specific based on the NUMA mapping tree, the only way to really “use” that kind of information would be to halt the entire machine with an HPC memory barrier like KeIpiGenericCall, then dig out your “who is next info” which can start getting convoluted because you’re now running at IPI level which has REALLY limited resources … and now what will you do?

Remember, the KTHREAD structure is opaque and changes almost daily and everyone and his uncle and his dog will attempt to read/ modify the KTHREAD structure which is why it’s a modify protected resource [https://www.microsoft.com/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/] and is a bit more complex to decode than a simple structure off the thread [https://medium.com/@Achilles8284/windows-kernel-exploitation-the-saga-hevd-writeup-part-2-payloads-and-processes-5f783ff58812] …

Whatever secret of the universe you’re trying to accomplish I will guarantee that someone (likely even on this list reading this very thread) had already done that/ tried that and I would encourage you again to share the problem that you’re going to try to solve, as someone here has likely run into/ tried that and can save you running in circles …

Or not, and best of luck in your endeavour!

1 Like

Ah, another “if only I could tell you, but it’s a secret of the universe which cannot be revealed …” …

Well, I guess that the default assumption in such case should lie somewhere along the lines of “the poster’s overall goals and purposes are
rather nefarious so that he does not really want to disclose them”, at least if the question is all about “monitoring” the userland from the kernel. More on it below…

Let me take a guess … you want to discern the next thread that will be executed by the scheduler to inject
a code segment/ determine if someone has injected a code segment/ prevent someone else from injecting
a code segment … probably for some groundbreaking anti-malware technology that will revolutionize the industry
and render all of the competing products obsolete overnight that you can patent and sell to the highest bidder for a tidy
nine digit sum, yes?

…or,alternatively, just to muck around with unsuspecting random processes, trying to capture some sensitive userland data. On the balance of probabilities, which scenario do you think is more likely?

Anton Bassov

1 Like

Yeah… OP: Describe what you want to do in general terms – I never accept “I can’t do that” – There are always general ways to describe what you want to accomplish without revealing proprietary or secret details. The only reason for total secrecy is that you’re doing something nefarious. And if that’s the case, we’re not helping you do it.

So… it’s up to you: Describe what you’re trying to accomplish or figure it out some other way other than asking here.

Peter

@“Peter_Viscarola_(OSR)” , @anton_bassov @craig_howard thank you. Sorry for the late post. The reason behind why I’m unable to share further details is because I have an idea for a personal project which I’m presently researching and I really don’t know of anyway of describing it without sharing too much details with the viewership of this forum. I hope that all of you will understand.

I hope that all of you will understand

Nope. I don’t understand at all.

So, guess you’ll have to find your answers elsewhere. Sorry we can’t help you more. It’s not that we don’t want to. But you’ve made it impossible.

Peter

Agreed … yours will be a journey undertaken alone and the issues you find will be will be yours to explore … best of luck in whatever you’re doing! :slight_smile: