Fact: You have no realistic means to stop all methods of client side "hacking". At best you can raise the bar and make it harder for the novice hacker or you can stop a couple common generic hacking tools dead in their tracks (or at least detect their use server side). There are simply put way too many ways you can:
- inject dll's into code
- inject code that isn't even in a dll
- execute code that influences a running program without even ever running any code in the addres space of your game.

Fact 2: It takes considerably more effort AND expertise to devise ways against a hack than it is to make a hack. If you aren't experienced at how "hacking a game" works in practice, you have zero chance of achieving anything.

Fact 3: Nomatter how good you are, there are a lot of hackers out there that are either a lot smarter than you, or a lot more creative than you, or a lot more devious/evil than your are.

Fact 4: A hacker will go to extremes in effort for even minimal gains. They will gladly spend weeks/months of effort on their cheat apps. Either because the minimal gains are significant enough to make a difference, or even just because it's a challenge to succeed at what they do. Even if you have a lot of paying customers, you cannot possibly match every hacker with an appropriately matching investment in time/effort/money to stop them.

----

Listing all the DLL's is easy enough. This is achieved with EnumProcessModules(). This returns handles, you can know which dll it is with GetModuleName or GetModuleBaseName. note that a LOT of dll's can get loaded in your application process space for a wide assortment of reasons, these can be perfectly legitimate and blocking them could be anything from mildly annoying to the user, to potentially harmfull (as in preventing the PC from operation properly and even destroying data and preventing it from booting anymore).

Listing all the memory that is marked as executable is also easy enough. Just use VirtualQueryEx to walk over the entire memory range and obtain the Access flag to see if it's executable.
You can then match this up with the loaded modules (dll's) and pick out any sections of code that are marked executable but aren't part of a DLL's image. This could be suspect, but it's also used in legitimate ways by for example JIT compilers, scripts, and even some Windows DLL's use this for code-overrides on specific hardware, or for obfuscating some security related code.


-----

What you can do are:

1) for local games. don't bother, the player is only hurting himself by using cheats. Cheat prevention is only a real issue for online/multiplayer games.

1) Don't send ANY data to the client that it can't know about (such as sending it information about what opponents are doing). This was abused in a cheat for a RTS game. The clients got information about buildings opponents were doing, so a cheat could be devised that basically removed the "fog of war" and you could perfectly see at all time what your opponent was doing and building.
In a "patch" this was fixed, but they were still sending information about how much resources everyone had gathered. By watching changes to the resources a cheat could infer what buildings/units were being built.

2) Don't allow the client to send/submit any information that isn't verifiable on the server.
If a user has X resources. and 2 seconds later he has Y. Then the server should have a means to verify that the transition from X to Y was indeed possible. The simplest way to do that is of course to do all resource management server side, but that isn't always fully feasible.

3) Even with the above 2 in place there's still plenty ways to cheat.
Autotargetters in FPS games. Any sort of automated play could be an issue. Detecting those is harder, this boils down to detecting 'unhuman' behavioural playing patterns.


GL. you have a very ungrateful job ahead of you. But it has it's rewards