Function Hooks (x86)

Atlanta traffic simulator

Hey again. Guess what, if you loved the post on dynamic patching, you’re definitely gonna love this one. Think of it as part 2 of this lovely little chapter of nitty gritty low-level memory manipulation.

Once again, I highly encourage you to follow along even though you will definitely get lost unless you have an inkling of what I’m about to talk about. Keep in mind that most of my (paid) posts are a bit technically oriented. But since you’re already here, you may as well keep reading.

Function Hooking

As per the subtitle, function hooks are, well, hooks. Imagine yourself going through Atlanta’s God-awful freeway system. You look and see a bunch of flashing lights and a guy getting paid by the hour standing with a sign that says “detour” with an arrow pointing to the next exit. After about 3 minutes of continuous cursing, you follow the rest of the traffic into a sketchy part of town that you’ve never been to. As you go along, you witness a lot of strange occurrences that you aren’t exactly familiar with, but you finally make it out in one piece and hopefully with your wallet.

This is a pretty good summation of what it’s like for a program to go through a function hook. An anomaly (an attacker) forces it to leaves its usual execution sequence and go somewhere else that it’s unfamiliar with. And, hopefully, it returns in one piece to continue its normal execution, perhaps with something a little extra being carried along with it.

You most often see function hooks (often called inline hooks) with video game plugins and mods where they overwrite game logic with their own, custom logic. For example, say there’s a function called GetRocketSpeed(). If you want rockets to move faster (or slower), you can just detour this function and return the speed that you want.

You also see this with malware. However, malware most often uses the built-in Windows API detours. We will most likely cover that in a future Substack post.

Why?

Say there’s a function that is called frequently across multiple, separate subroutines. It would be extremely difficult to manually patch every cross-reference, so why not hook the function and modify its return value? Sounds easy enough.

Secondly, you may want to change the execution of the function depending on something. Maybe you want your rockets to shoot super fast, or maybe you want your enemies’ rockets to shoot super slow. You can hook the function and distinguish what return value you want to use, then execute that logic.