0

Previously when I thought of hooking I was thinking at a bit too high of a level, perhaps. I was thinking of an OS's debugging API which I assumed added a flag to some kernel or OS process responsible for handling for that event, so if a certain process we add a hook to triggers that syscall, or that exception, or higher level API call we're hooking, our hook would execute.

But now I'm seeing examples of what looks like actual instructions patched into the process as hooks. Clearly I need to study this a bit more but it seems like it could be done a number of ways, whether that be patching/injection, debugging APIs, etc. I want to understand all the ways hooks are applied at the lowest level.

How can this be done (in terms of low-level methods, CPU capabilities, kernel APIs, etc)? If it's highly OS API specific, or highly CPU specific, then I'd just like to know that.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
J.Todd
  • 707
  • 1
  • 12
  • 34
  • At the very lowest level, you can load modified microcode, now that researches have found the keys (https://arstechnica.com/gadgets/2020/10/in-a-first-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/ for Goldmont, and https://arstechnica.com/gadgets/2021/11/intel-releases-patch-for-high-severity-bug-that-exposes-a-cpus-master-key/ recently for later Silvermont-series CPUs; IDK if that's possible for any mainstream CPUs like Skylake.) IDK why there'd be sufficient key material inside the CPU to sign stuff for it; I'd have expected a public key system, but here we are. – Peter Cordes Nov 20 '21 at 00:45
  • @PeterCordes Well I did say "lowest" but I mean something more mainstream, however, that's very interesting. I didn't even imagine there would be code signing on microcode, I thought it was sort of "hardwired" into the silicon circuits honestly. Will be giving this a read. – J.Todd Nov 20 '21 at 02:35
  • @PeterCordes Also if what Alex answered is representative of the lowest level "main stream" way of applying a hook, wouldn't hooks be very susceptible to evasion via hiding control flow with a dynamic jump destination? Is there any feature in x86/-64 to do something "real-time" for hooking as in some CPU feature to let us execute a hook any time a certain instruction or syscall executes, (with main-stream applicability)? – J.Todd Nov 20 '21 at 02:43
  • 1
    *evasion via hiding control flow with a dynamic jump destination* - no, you modify the machine code of the function you want to hook, not of code that jumps to it. So it doesn't matter how execution reaches it, the first instruction is a jump to your hook. Re: modifying microcode: what you could actually do is probably introduce new behaviour for some instructions that decode to more than 4 uops with the MS-ROM. In theory; IDK if anyone's reverse-engineered Intel's microcode enough to actually do anything like that. Yeah, simple single-uop instructions are probably more or less hard-wired. – Peter Cordes Nov 20 '21 at 03:09
  • @PeterCordes I see. However, it occurs to me that an attacker probably does not need to package a "function" in any standard location, or as an actual "function", but could rather just be some piece buried in the control flow that only the attacker knows. Even more interestingly, perhaps, the attacker could just ROP through their own code to achieve their desired functions starting with some dynamically decided control flow entrypoint. Hooking sounds much less reliable than I'd previously realized. – J.Todd Nov 20 '21 at 11:16
  • Attacker? When did this turn into malicious uses for hooking functions? I thought we were talking about obfuscated programs that took steps to make reverse-engineering and "cheats" for games harder. It hardly seems like an attack when you're just for example running another process under GDB and modifying it. Not an attacker in the same sense as a normal ROP attack via buffer overflow or something. – Peter Cordes Nov 20 '21 at 11:43
  • @PeterCordes I'm sorry, I'm training in cybersec, I didn't think of hooks outside the context of an endpoint security product or reverse engineering tool trying to analyze a potentially bad program. Only in the responses to this question do I realize hooking isn't just a term for that. But re:ROP, it occurs to me that it isn't limited to exploiting the execution permission on some standard library after a buffer overflow, but rather it could also be used to jump through a malicious sequence of instructions in a program that otherwise seems benign. – J.Todd Nov 20 '21 at 11:51

1 Answers1

2

I think you mean those "hooks" that are able to override some functions. They are implemented with either of the following methods:

  • Rewrite function body with a jump instruction, saving overwritten instructions somewhere to be able to call the original function.
  • Know where the target function is called by pointer and change that pointer, saving the original pointer to be able to call the original function.
Alex Guteniev
  • 12,039
  • 2
  • 34
  • 79
  • What about "real-time" hooks, is that possible? Because to do the kind of hook you're talking about the attacker [can just prevent the defender from accessing the control flow](https://stackoverflow.com/questions/69968121/how-are-control-flow-graphs-built-in-cases-where-the-jump-destination-is-based-o) of the malicious code, which would be needed in order to do what you suggest I think, assuming the functions weren't just statically located. Right? Is there any way to tell the CPU "when X instruction executes, throw an exception to my hook handler" or something like that for the kernel? – J.Todd Nov 20 '21 at 02:39
  • @J.Todd, I was not realizing that this is a question about security (hooks don't necessarily mean malicious intent, sometimes it is just "we can't recompile / access source, but we want to change behavior", especially in Windows). Anyway, I think techniques I mention may be used by attackers too. Regarding CPU features to alter execution, the CPU has (hardware) breakpoints, but I'm not sure if they are useful this way. – Alex Guteniev Nov 20 '21 at 05:09