what is the windows api? What are these kernel 32 user32 dlls? What is windows.h and where do all of these things come from? All right, so before we can talk about the windows api, we need to know what an api is. An api allows for two pieces of software to interact with one another. In this case, it allows your code to interact with the windows operating system. Obviously, your operating system is responsible for a wide variety of tasks, and so this api is defined across hundreds of different files. Now, one thing that might be confusing about these files is the relation between the dot h and the dll files. The dot h files, or header files, contain definitions of functions that make up the api, like read process memory, but they don't contain the code that makes these functions work. The code that makes these functions work is located inside the dll files, which stands for dynamic link library. Note that one dll may implement multiple header files. To utilize the windows api, you can download the windows sdk from Microsoft's website or as I'm sure most

of you are going to do, you can download this through Visual Studio. While it has no inherent structure on your file system, the documentation categorizes each header that makes up the Windows API based upon functionality. These categories include UI, windows environment, user input, data diagnostics, graphics devices, system services, security installation, system administration, and networking. Most of this is not actually useful for our purposes, but it helps to give you a clearer picture of what you're actually working with. Now, the two things that throw everybody off about the Windows API are variable types and naming conventions. So what's the deal with these special types like double words, handles, and wide chars? These are actually just type defs that boil down to primitive C types. They're byproducts of Microsoft supporting the same API through so many generations of hardware. For example, there are types that specify far and near pointers, but nowadays there is no distinction. Some of these are just helpful abstractions from the days before online documentation and modern development tools. For example, a handle is much easier to conceptualize than a void pointer. Now, these function naming

conventions are a little less straightforward, but stem from some of the same reasons. Prefixes like cm, nt, and zw correspond to the components to which the function belongs. Sometimes you'll come across functions that have three different variations: one generic, one ending with an a, and another ending with a w. The variation ending with a is a relic from the past, the a indicating ANSI encoding. The variation ending with a w indicates Unicode encoding, and the generic is compatible with both encodings. You'll also come across functions having another variation with the suffix ex, and this ex stands for extended. So, a function that ends with ex provides extended control over the execution of a specific task. Alright, so I'm in Visual Studio looking at a project that you're going to create very early on in the Game Hacking Bible, and I haven't yet explained what windows.h is. Now, before I do that, I want to show you something. We can see here that read process memory is defined in memory api.h, but I don't actually include that anywhere in this project.

how is it that I can build this project successfully? Well, if we look over here on the right, we can see that we actually do have memory API included. Why is this? Well, we can have a look at what windows.h actually is by either right-clicking it and pressing go to document or pressing and holding control and clicking it. Now, if we scroll down, we can see that windows.h is just a wrapper for more includes. It includes all of these base headers. These make up the most common components used from the Windows API, and that encompasses a good chunk of what we do, including read and write process memory. But if something isn't included with the base Windows API, you can just manually include it, just like if we wanted to, we could include only memoryapi.h. Now, if you remember earlier, we talked about Windows API typedefs, and we can see where they're defined by pressing control and clicking on one of them. Now, you can do this with anything in the Windows API, and it's immensely helpful when you don't really understand what's

happening. If we look, we can see that a double word is just an unsigned long. Now I'm going to build this project and open it up in a debugger. We can see that ReadProcessMemory exists within kernel32. So when our program requires ReadProcessMemory, it's going to load the kernel32 module and call the function from within it. And we can see this by setting a breakpoint on ReadProcessMemory and continuing to it. As you can see, the instruction pointer is now within kernel32.dll. So hopefully now you can see that you don't need to be intimidated by the Windows API, and you don't need to remember it either. You can always reference Microsoft's developer documentation, and I very much encourage you to do so because not only is everything very clearly laid out and explained, but it's also accompanied by code examples. If you enjoyed this video, a like would be much appreciated, and subscribe to be notified of future uploads. If you haven't already, check out guidedhacking.com for a step-by-step introduction to game hacking.

Ever-growing catalog of content. Thanks for watching, and I'll see you next time.

What is the Windows API?  What is Windows.h?

Guided Hacking makes educational reverse engineering content with a focus on game hacking, malware analysis & exploit development.  Our tutorials teach you everything about reverse engineering and game hacking.  We have 460+ video tutorials and a very thorough Game Hacking Bible with 70+ chapters.  We have 10 complete game hacking courses and 1300+ total tutorials.