Quote:
Originally Posted by gap
In my opinion its best feature was not to change any executable: it was changing the code of the game after it was loaded in memory, allowing full configuration by the player. Furthermore, the patch was enabling third parties custom extensions to be loaded and executed within the game. For what I can understand, he was "injecting" his code in the game as you did with dll's with your dll injector.
Knowing your love for neat solutions, and seeing the you are moving in the same direction, I wonder if the same can be done with a future release of your patcher.
|
You want the patcher to be able to inject code into an active process? I wrote a piece of software than can do that already. But you want that functionality included in the patcher?
Let me ask you this: why inject code into an active process when you can take it's .exe or .dll file, add a section or multiple new sections to it, dump your code into the new section (or sections) in the file, and let the Windows loader do the loading for you? With the adding new sections your code is guaranteed to be where you want it thus making it very easy to get to the other sections. With code injection you have Windows create a new pool of memory for you and you dump your code into that pool. Where that pool of memory ends up being located you have no control over. The only reason I can see for not adding new sections and dumping your code into them in the .exe or .dll file is if the .exe or .dll checks itself when loaded to see if anything is different. But then again one can remove this check from ever happening.
If the process is already active (loaded) and you don't have access to the .exe or .dll files then code injection is necessary if one wants to add anything new to it.
Looking at GPxPatch I wouldn't like that you have to launch the app wanting to patch from the patch app itself. There's no reason to do this. You can easily get a list of all active processes from Windows and 'attach' to any of them very easily.
The patcher has been morphing into something I've been wanting to do for a long time: take an active process and grab all of it's in memory data. Since the PE header is in the process's memory one can theoretically read this PE header and construct an .exe or .dll from the memory read in (a reverse Windows loader). For self-modifying exes this would be one way to 'capture' the image of it in it's modified state thus removing the obfuscation. That's the theory anyway. I'm slowly making my way to see if this theory is correct or not
The only real hole in this theory is if a section was marked as discardable and the Windows loader didn't load that section into memory...
I can dump memory from any active process, modify it, and inject it back in and the process has no idea anything happened. The patcher is heading in that direction as another way to patch (basically taking functionality from another app I wrote).
I've been really ambitious lately and have been trying to modify the sections already defined in an .exe or .dll file. The new version of the patcher allows you to add new sections. These sections are added to the end of the .exe or .dll file. That's cool and all but I want to be able to extend sections already defined
The problem with extending sections already defined is relocations, fix-ups, and the likes. While not an impossible task to do it's not for the faint of heart. I'm learning about relocations, fix-ups, and all the other things I need to know (data structures) to be able to pull this off. I've searched for tools that already do this and haven't found any. When I've posed this question in some forums the response back was impossible or you need the source code...well I always love to prove that nothing is impossible
Another thing I've been working on is being able to 'add' a process to another process. You may ask why would one want/need something like this? Well I have one reason: the Enigma app. The app is perfect replica of an Enigma machine. It works great as a stand-alone process. It cannot be used in any app that does full screen rendering. I've written an app that can 'steal' the main window away from another process and modify it so that it thinks it's the child of the 'stealing' process. Works beautifully. You minimize the 'stealing' process and the other process minimizes also. Now I just have to modify it (Enigma) so that it renders it's window over the full screen app. This is where I need to be able to attach the Enigma process to the full screen process.