Interprocess memory editing

This is a discussion on Interprocess memory editing within the Windows Programming forums, part of the Platform Specific Boards category; Originally Posted by Viper187 and why must programmers waste time trying to make games unfriendly to hackers? I never understood ...

  1. #16
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Viper187 View Post
    and why must programmers waste time trying to make games unfriendly to hackers? I never understood that BS. Nothing is hacker-proof. Quit wasting your time and ours. I remember hacking so many N64 games that had completely screwy programming. There are still certain games with timers I can't bloody freeze using a gameshark and it annoys the hell out of me.
    Noone said im trying to make games hacker proof. Only that im using games as the sandbox.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  2. #17
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    There are many forms of hacking/modding. The first, the easiest one, is usually by editing data files. This is easy to block - doing CRC check on files, but protecting your CRC check code itself is much more difficult.

    The next way is through modifying the executable, either while it's running (in memory) or on the hard drive. Protecting data this way can be achieved by using clever duplicates or sums. But the problems occur when the executable code is modified. Of course, you can try to CRC this again, but how can you guarantee someone doesn't block that either?

    There are easy ways to protect your code, and more difficult ones. Easy ways are to make different parts of code depend on eachother by setting different variables. Maybe even use function pointers which only get a value in the middle of a CRC check, or check the CRC result in many places, make the code a little self-modifying etc. There are many ways. You may wonder why I said this is the easy way. That's because...

    ... the hard way is to start modifying other processes or use drivers. I wouldn't suggest anyone to use these methods, but I'll explain them anyway. You can inject a piece of code into other processes which reroutes or modifies the OpenProcess and CreateProcess functions. On CreateProcess call you make sure the new process gets injected, and on OpenProcess call you block the calls trying to open your process. If something is messed in this stage, you can cause a system crash. The other way is to make a driver (all games installing drivers usually get a bad reputation though). Driver hooks calls to OpenProcess and/or WriteProcessMemory. If you mess something up here, you're doomed (BSOD).

    There are plenty of ways to get some code injected into a process. The most popular ones except modifying the executable are modifying the game's DLLs or copying a modified system DLL into the game directory. These are not easy to detect.

    Trainers usually modify the data/code in memory by finding the process with FindWindow or EnumProcesses, opening the game with OpenProcess, and then using WriteProcessMemory and ReadProcessMemory. Sometimes applications use their own API functions instead of these functions (usually a straight copy of the API function) to avoid game protection systems. This helps against injecting protection, but not against drivers.

    When a memory scanner or a trainer has accessed the application, they can inject their code into the executable or inject a DLL. One simple example of DLL injection is ArtMoney (memory scanner & editor).

    Nowadays there are quite few protection systems that have stayed unhacked or at least a workaround hasn't been published for them. These include the huge protection systems like StarForce. Personally I hate these systems, but if a multiplayer game needs protection, there aren't many other choices.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  3. #18
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,594
    It's quite possible to hook API calls such as OpenProcess, ReadProcessMemory/WriteProcessMemory at user level simply by overwriting the import table in memory and injecting a DLL via CreateRemoteThread.

    Many good firewalls also protect from this kind of behavior, as well, by asking.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #19
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by Elysia View Post
    It's quite possible to hook API calls such as OpenProcess, ReadProcessMemory/WriteProcessMemory at user level simply by overwriting the import table in memory and injecting a DLL via CreateRemoteThread.

    Many good firewalls also protect from this kind of behavior, as well, by asking.
    Like I mentioned, from user mode it means injecting some code into every process. Bypassing import address table hooks is very simple though (pseudocode):
    Code:
    fnWriteProcessMemory=GetProcAddress(GetModuleHandle("kernel32"),"WriteProcessMemory");
    //this call bypasses the hook
    fnWriteProcessMemory(x, x, x, x, x);
    So I think the more reliable way is to hook the function itself, not only the IAT.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 10:22 AM
  2. Suggestions on this C style code
    By Joelito in forum C Programming
    Replies: 11
    Last Post: 06-07-2007, 03:22 AM
  3. Relate memory allocation in struct->variable
    By Niara in forum C Programming
    Replies: 4
    Last Post: 03-23-2007, 03:06 PM
  4. Copying memory, pointers and the like.
    By psychopath in forum C++ Programming
    Replies: 34
    Last Post: 12-12-2006, 12:37 PM
  5. Memory Editing
    By Denethor2000 in forum C++ Programming
    Replies: 6
    Last Post: 11-02-2005, 07:19 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21