0

I want to test my idea, wherein I execute some code in the context of another process at some interval. What API call or kernel functionality or l technique should I look into to execute code in another process at some interval?

Seems like I need to halt the process and modify the instruction pointer value before continuing it, if that’s remotely possible. Alternatively, I could hook into the kernel code which schedules time on the CPU for each process, and run the code each time the next time slot happens for a process. But PatchGuard probably prevents that. This time interval doesn’t need to be precise.

J.Todd
  • 707
  • 1
  • 12
  • 34
  • https://stackoverflow.com/questions/57429160/can-you-change-the-instruction-pointer-register-of-child-processes some similar question and other similar topics linked to it – pptaszni Sep 19 '22 at 14:20

1 Answers1

2

The wording of the question tells me you're fairly new to programming. A remote process doesn't have AN instruction pointer, it typically has many - one per executing thread. That's why the normal approach would be to not mess with any of those instruction pointers. Instead, you create a new thread in the remote process CreateRemoteThreadEx.

Since this thread is under your control, it can just run an infinite loop alternating between Sleep and the function you want to call.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • Not new to programming - a decade, but we don’t typically deal very much with the IP in JavaScript and Python lol! – J.Todd Sep 19 '22 at 14:41
  • But wait, doesn’t each thread maintain its own register context? I think I recall learning that the CPU remembers the register states of each thread before switching contexts. Edit: Oh I think I see the idea. Each thread can then easily read memory of the other threads. This is easier than I imagined. – J.Todd Sep 19 '22 at 14:42
  • Thanks for answering my question even though I seem to have forgotten my fundamentals :) – J.Todd Sep 19 '22 at 14:44
  • @J.Todd: It's usually the OS which remembers register states. HyperThreading is the exception to the rule, where the CPU does it, and the result is that the OS thinks there's a (virtual) processor so the OS doesn't save the same context again. – MSalters Sep 19 '22 at 14:45
  • Ok ok, it was hyper-threading I was recalling. – J.Todd Sep 19 '22 at 14:46
  • @MSalters: The CPU stores the register states before switching to interrupt (or syscall) context. The OS can then fiddle with the stored values before the interrupt (or syscall) returns, resulting in resuming a different thread. So both the CPU and the OS are deeply involved, saying it's just the OS is equally partially correct as saying it's just the CPU. – Ben Voigt Sep 19 '22 at 15:49