 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
atom0s
Moderator
 Reputation: 205
Joined: 25 Jan 2006
Posts: 8588
Location: 127.0.0.1
|
 Posted: Tue Sep 28, 2010 11:07 am Post subject: |
 |
|
| justa_dude wrote: | | The above suggestions work, but they're all kind of a pain to implement. Writing a native DLL for injection is just so much easier. |
Not really sure whats the pain of typing a few extra lines of code to make API calls, even more so when its the standard for C#
If you write a native DLL to do it, you are doing more work to get the same result, and in the end you will have to do the same thing as I did above with importing the functions.
| justa_dude wrote: | Otherwise, I'd probably look to inject a script engine (lua, underc, perl, python, ruby, whatever) if the target app is running on a system that either already has the script engine/libraries installed or can be made to install them. Then you can wrap the processes of creating remote memory for a script, writing the script to remote memory, asking the interpreter to execute the script and freeing the memory in a trivially simple function. All of the scripting languages I can think of include dynaloading and win32 api support.
Lastly, there are a few just-in-time compilers. If you go down the path you're heading, I /highly/ recommend looking into them. The process of writing and patching shell-code (i.e., the replace-strings in Wicca's btFunction) is ugly, error-prone, and very difficult code to maintain. |
Adding more then whats needed (eg. scripting engines) for something like this is a bit much. Not to mention the more you pack into your injected code, the higher risk of detection you have if the application monitors for code alterations. Overall it mainly depends on the end goal of what is being done. I'm sure this MessageBox example is just the start of something else that involves similar calling for other functions.
The point of my example was simply showing how to do what he requested. Nothing really error-prone once you have tested and adjusted as needed. I wouldn't suggest using the similar method with larger scale functions, of course either though.
| Burningmace wrote: | | Hadn't thought of the GetModuleHandle approach, I'll give it a go. I'm so glad ASLR doesn't switch the module load offset per-process Shocked |
System DLLs (ntdll, kernel32, etc.) are not reloaded per-application. They are loaded once and copied into each process when referenced, at the same base.
_________________
- Retired. |
|
| Back to top |
|
 |
justa_dude
Grandmaster Cheater
 Reputation: 23
Joined: 29 Jun 2010
Posts: 893
|
| Posted: Tue Sep 28, 2010 4:31 pm Post subject: |
|
|
The advantage of injecting a native dll is that you're operating in the process space of the target application so worries like trying to remap getprocaddress become nil. The system loader also handles fixups, so having to patch your shell-code for relative jumps and calls (save for the point of injection) is a non-issue.
Because of the prevelence of firewalls and av software and so forth, pretty much all software has to be tolerant of dll injection - you can't avoid it. That said, embedding a scripting engine to do the patching is not any more likely to cause detection than manually patching. CE uses underc, and I've /never/ seen a game that detects it without detecting auto-asm patches.
With regard to system dlls being loaded at the same virtual base within every application, I believe the list is very small (ntdll, kernel and perhaps user). Please correct me if I'm wrong.
Cheers,
adude
|
|
| Back to top |
|
|
TROLOLOLOLOLOLOLOLOLOLOLO
Expert Cheater
 Reputation: -1
Joined: 27 Dec 2009
Posts: 100
|
| Posted: Tue Sep 28, 2010 7:33 pm Post subject: |
|
|
Wow you guys are really smart 
Is that stuff you learn in college?
|
|
| Back to top |
|
|
atom0s
Moderator
Reputation: 205
Joined: 25 Jan 2006
Posts: 8588
Location: 127.0.0.1
|
| Posted: Tue Sep 28, 2010 8:02 pm Post subject: |
|
|
| justa_dude wrote: | | The advantage of injecting a native dll is that you're operating in the process space of the target application so worries like trying to remap getprocaddress become nil. The system loader also handles fixups, so having to patch your shell-code for relative jumps and calls (save for the point of injection) is a non-issue. |
Depends on how in-depth the injection is and what it does. If its a few small fixes it's not a real need to go out of you way to create a full other project/dll to inject. But again, really matters on what all you are doing.
Basing on the OPs question, a small injection of code itself is only needed, adding another whole module is a bit overkill when it isn't necessary.
| justa_dude wrote: | | Because of the prevelence of firewalls and av software and so forth, pretty much all software has to be tolerant of dll injection - you can't avoid it. That said, embedding a scripting engine to do the patching is not any more likely to cause detection than manually patching. CE uses underc, and I've /never/ seen a game that detects it without detecting auto-asm patches. |
Detection is based on the coder whom makes the protection. DLL injection is probably the easiest form of hacking that is detected. Simply because almost all injection is done via API so there are several layers an anti-cheat / protection coder can use to detect it happening. (This is just one form of injection though, someone could just use manual mapping to avoid a bunch of those layers. Or other methods.)
| justa_dude wrote: | | With regard to system dlls being loaded at the same virtual base within every application, I believe the list is very small (ntdll, kernel and perhaps user). Please correct me if I'm wrong. |
Nope, you are correct. It pertains to system dlls. Some more info if you are interested:
http://www.nynaeve.net/?p=198
| CometJack wrote: | Wow you guys are really smart Shocked
Is that stuff you learn in college? |
Never been to college. Waste of money in my opinion.
_________________
- Retired. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
