SH5 DLL Injection

[h.sie]

@TDW: Very interesting and promising thread.

Until now I directly injected Hex Code into sh3.exe and some .act files in order to do some realism changes and additions. See this thread for details:

http://www.subsim.com/radioroom/showthread.php?t=174225

I still stick on direct HexCode Injection because I am not very familiar to DLL based code injection.

My question to you is: Does DLL code injection also work for .act files, which are loaded into different memory locations every time a game is started because of address space layout randomization (ASLR) in newer 64 Bit systems?

By the way: In SH3, DLL code injection seems to be very easy, just place your .act file into the sh3 install directory and it will be loaded automatically by sh3.exe when it starts, regardless of it's name.

Thanks very much and good luck!
h.sie

[TheDarkWraith]

Originally Posted by h.sie

My question to you is: Does DLL code injection also work for .act files, which are loaded into different memory locations every time a game is started because of address space layout randomization (ASLR) in newer 64 Bit systems?

By the way: In SH3, DLL code injection seems to be very easy, just place your .act file into the sh3 install directory and it will be loaded automatically by sh3.exe when it starts, regardless of it's name.

Thanks very much and good luck!
h.sie

Every Silent Hunter game will load ANY .act file it finds in it's root directory. What I'm not sure is whether those .act files have a DLLMain function in them (or something similar) and if they do whether it gets called or not by the game or the Windows loader. When the Windows loader adds a library (module) to a process it calls DLLMain on the module when it's loaded. DLLMain is used to initialize the dll (can be used to do other things also).

Your question about DLL code injection for .act files I don't understand. Maybe you're asking if DLL code injection places the loaded module at random memory locations everytime it's injected? If so, the answer is yes. The Windows loader determines where the module will be placed in memory. Now some will say well how can you inject new code if the memory address is always changing? The answer is simple. You hook into the main game code and point it to your code. You have DLLMain do the hook into the main game code (suspend the main game thread - add hook - resume main game thread).

[TheDarkWraith]

The 32bit version of SH5 injector has a flaw in it. For those who have downloaded it please do not use! The problem with it is the incorrect RVA is given for the LoadLibrary and FreeLibrary functions in kernel32.dll.

Normally one calls the Win32 API function GetProcAddress to get the address of the function they want to call in a dll. I had problems getting that working correctly with 64bit OS so I found another way to do it. Since I know the base address of kernel32.dll I just add an offset to that base to get to the function(s) I want (I know this offset from using dumpbin on kernel32.dll). Now here's the problem: Win7 64bit uses WoW (Windows 32 on Windows 64) to enable 32bit apps to run in the 64bit environment. When in WoW mode, kernel32.dll is different from the 32bit version of kernel32.dll (there are two versions of it on 64bit). This means the offsets are also different for the functions I need I'll be revising the 32bit version with the correct offsets here soon.

EDIT:

problem has been corrected. Now if someone can verify that the 32bit version works I would greatly appreciate it I know the 64bit version works correctly as I run a 64bit OS.

[Beltza]

All that sounds great!!!!

[marleymen]

Please moderators, this post should be moved to "SH5 Guru Programming" subforum.

Excellent Tool for breaking OSI.exe

As I don't want to be brigged nor banned?
That's all I'll say on OSI

[reaper7]

Originally Posted by TheDarkWraith

EDIT:

problem has been corrected. Now if someone can verify that the 32bit version works I would greatly appreciate it I know the 64bit version works correctly as I run a 64bit OS.

Keep getting an "SH5 Process not found!" error
Is there an SH3 version

Sh5 is up and running. SH5Injector32.exe is in SH5 Directory.

[vanjast]

Originally Posted by TheDarkWraith

You have DLLMain do the hook into the main game code (suspend the main game thread - add hook - resume main game thread).

oooo... naughty boy I thought you were doing this when I saw you on the Asm websites sometime ago. I wouldn't call it DLL injection, but DLL hijack/detour.

Maybe UBI's copyright infringement never went so far into these 'dynamics', then that's their problem....and I don't think they have the expertise to cover all windows's 'gaps'.

[TheDarkWraith]

Originally Posted by vanjast

oooo... naughty boy I thought you were doing this when I saw you on the Asm websites sometime ago. I wouldn't call it DLL injection, but DLL hijack/detour.

Maybe UBI's copyright infringement never went so far into these 'dynamics', then that's their problem....and I don't think they have the expertise to cover all windows's 'gaps'.

Windows itself is flawed. Any DLL that comes with a piece of software can be hijacked quite easily. There are mutliple ways to do it but the most common ones are:
- having the software create a memory space for you. You then dump your code you want to run into that memory pool. You suspend the app, redirect it's EIP to the start of your code, ensure your code 'calls back' to where the app originally was when it's done, delete the memory pool it created for you, and you leave no footprints behind of what happened/who was there
- This is Window's biggest flaw: just because an app needs to use 'system' DLLs doesn't mean you can't intercept them. You can do it quite easily too. Windows first looks for any DLLs the file calls for in the local folder the app was started from. So if you make a DLL that has the same name as the DLL it's looking for it will load your DLL. You in turn have to ensure your DLL maps all the functions that the app needs. Then when the app calls out for a function in the DLL control is handed over to your DLL, you decide what you want to do with it, then call the original DLL passing the same parameters it passed you. The system and the app have no idea that you hijacked a DLL of it or that you may of intercepted some data that wasn't meant to be 'seen'.

I don't care how secure you think any piece of software is, it's not if it's running on Windows. Even if you inline every function call the app is still susceptible to 'detouring'. If you try and be sneaky and create another thread that tried to monitor something like this (by using a watchdog timer or the likes) I can suspend that thread too. You can't win in Windows. If there's some data that someone wants and they have the knowledge they will get it.

There are many other ways you can exploit software. Windows just makes it very easy to do

You can call it DLL injection, code injection, whatever. As one does not physically modify a binary image there's no law being broken. There is also no evidence left behind saying how the code got into the app in memory. Besides the app did it for you and it did it without any complaints. What a bargain

There are those that use these methods for malicious intents (worms, trojans, etc.). I am just naturally curious and do it just to see if I can. I especially like dumping PE headers just to see if the app in question is using any of the crypto classes. If it is well it's game on. I just gotta know what they are trying to hide. It's like a game. A game where it's hard not to always win.

[vanjast]

Ja, I know....

[kethon]

no need DLL inject, just rename your dll file to *.act

[Viktor_Prien]

Sorry TDW this post is just to let you know that links in post #1 aren't working anymore...could you provide new ones?
Thanks in advance!