[Injection] Selecting/customizing functionality to inject

[Bananenbrot]

Hi,

I recently 'finished' my .NET injector and I'm wondering what functionality should actually reside out of process and which functionality I should inject with my dll. The search for an elegant solution in dll structuring gives me a headache.

For those of you I haven't lost so far because of my bad explanation (sry for that^^), take for example a traditional (in my case static) Memory-reading class. I feel comfortable in being able to use it like

Memory.Read<int>((IntPtr)0x12345678);

regardless if I'm in or out of process.
What I hoped so far is that I somehow would be able to use the same dll in both the out of process GUI (for simple reads before starting the actual botting) and the injected process. But if I wanted to take advantage of being injected in the target process, the Read-Method should have quite different functionality if I'm in-process.
Sure, I could clutter each method with if()'s, but I hope that there a better ways to do that, for example something like a preprocesser directive at runtime (which is an if()... damn) or one-time-initializing to use the right method (i.e. compare the current process with the target process in the static constructor and based on that execute the right methods).

I believe that there are more elegant solutions than copy/paste most of the out of process code into an 'in-process version'.
I would like to avoid to have 30+ dll's with similar names in the bot directory, so I like to know how you solved these management problems. This is essentially a design question (design the classes in a way that you are able to use two times the same dll), I think.

[Apoc]

The only solution would be a global bool for whether or not you're in process or not.

The if statements will still be there, but if you write your funcs properly (e.g. more or less create them the exact same, with 2 'main' functions being different) then you shouldn't have any real issue.

[Bananenbrot]

Ok... then it seems I have to go that way. Probably I'm too much of a pessimist and simply have to get started.
Thanks for your reply!

For the more or less hidden part of my question... how do you structure your modules? What abstract purpose do they serve? What is loaded into the process and what is used exclusively out of process?
In case of Onyx I got to smell something in your blog, but what about the others?

[adaephon]

You don't need a global bool as such. I started doing this in my own library but haven't really worked on the OOP side yet, or tidied up my in process memory reading. Or really used it... Anyway, use object oriented programming, I hear it's great :-P.

What I've done is I have an abstract Memory class that has all the method signatures I need such as Read<T> or ReadBytes or whatever I want (and Write etc etc). I then have two subclasses one for in process and one for out of process. The in process can implement the methods using Marshal.Read, or native pointers, and the out of process using ReadProcessMemory. You can then use a static factory pattern to get the appropriate reader (I don't do this, I have it all encapsulated in a different class - more later). I.e.

abstract class Memory {
    ....
    public static Memory CreateForPID(int pid) {
        if (pid == Process.GetCurrentProcess().ID) // we're in process
        {
            return new InProcessMemory(pid);
        } else {
            return new OutProcessMemory(pid);
        }
}

As for the 'hidden' part of your question: In my work, I have a class I've called ExtendedProcess that provides all my extended functionality for a Process (memory reading/writing, injection etc). This internally manages all the sub classes such as Memory and Injector and determines whether they are appropriate for the situation, or what kind is appropriate. I.e. I have a Memory property that returns a Memory reader. If the ExtendedProcess object is for the current process, it returns an internal reader, otherwise an out of process reader.

In terms of what is injected and what isn't, that often seems to be a matter of preference. I remember Apoc saying at one stage that everything for Onyx was injected (I think, but I may be wrong). This of course makes some things a bit more difficult (like debugging - but logging comes in handy there). I believe I remember another member, amadmonk, once saying that he had injected parts that communicated with an external process to facilitate communication between multiple bots. Effectively it comes down to there being more than one way to skin a cat. Try to work out what you want to achieve from your bot and whether those features will be easier internal or external. If you're injecting already, it's another headache to set up communication between processes, so you need to be sure that your reasons for doing that are worthwhile.

That said, if you design your modules with future extensibility in mind then it is often easier to add features later without drastic rewrites. Just be careful not to make it harder to design features for right now at the expense of possibly wanting to do something in the future.

[Apoc]

You don't need a global bool as such. I started doing this in my own library but haven't really worked on the OOP side yet, or tidied up my in process memory reading. Or really used it... Anyway, use object oriented programming, I hear it's great :-P.

What I've done is I have an abstract Memory class that has all the method signatures I need such as Read<T> or ReadBytes or whatever I want (and Write etc etc). I then have two subclasses one for in process and one for out of process. The in process can implement the methods using Marshal.Read, or native pointers, and the out of process using ReadProcessMemory. You can then use a static factory pattern to get the appropriate reader (I don't do this, I have it all encapsulated in a different class - more later). I.e.

abstract class Memory {
    ....
    public static Memory CreateForPID(int pid) {
        if (pid == Process.GetCurrentProcess().ID) // we're in process
        {
            return new InProcessMemory(pid);
        } else {
            return new OutProcessMemory(pid);
        }
}

As for the 'hidden' part of your question: In my work, I have a class I've called ExtendedProcess that provides all my extended functionality for a Process (memory reading/writing, injection etc). This internally manages all the sub classes such as Memory and Injector and determines whether they are appropriate for the situation, or what kind is appropriate. I.e. I have a Memory property that returns a Memory reader. If the ExtendedProcess object is for the current process, it returns an internal reader, otherwise an out of process reader.

In terms of what is injected and what isn't, that often seems to be a matter of preference. I remember Apoc saying at one stage that everything for Onyx was injected (I think, but I may be wrong). This of course makes some things a bit more difficult (like debugging - but logging comes in handy there). I believe I remember another member, amadmonk, once saying that he had injected parts that communicated with an external process to facilitate communication between multiple bots. Effectively it comes down to there being more than one way to skin a cat. Try to work out what you want to achieve from your bot and whether those features will be easier internal or external. If you're injecting already, it's another headache to set up communication between processes, so you need to be sure that your reasons for doing that are worthwhile.

That said, if you design your modules with future extensibility in mind then it is often easier to add features later without drastic rewrites. Just be careful not to make it harder to design features for right now at the expense of possibly wanting to do something in the future.

You're essentially doing the exact same thing as a global bool.

Also; debugging when in-process is no harder than debugging when out of process. Only requires 2 'extra' clicks. (Tools -> Attach to process [hotkeyed] -> WoW)

[Bananenbrot]

Very helpful replies, thanks.
I'm currently going with most classes being static, which of course doesn't allow me to use inheritance.
While this certainly is an advantage in syntactics (f.e. no _memory = Memory.Instance stuff in constructors) and for me personally in appearance (I like blue highlighted classes :P),
I already figured out the cons, one major drawback being inheritance, the other being the lack of static destructors.
I started to make singletons, but it's not how I want to use the classes in every single Method (Memory.Instance.Read<IntPtr>((IntPtr)0x12654879), so for syntactical equal Usage I need to track a reference in every class.
How big is the performance hit of deriving your memory class (which should actually be fast like hell) from an abstract class? AFAIK, all methods (except those defined in the abstract class) have to be accessed through the VFTable... Is the difference noticeable? I guess it would be easier (though uglier) to check a static bool in the Memory.Read method.

Seems like I have to read up on some OOP design concepts for some inspiration.

[Apoc]

Very helpful replies, thanks.
I'm currently going with most classes being static, which of course doesn't allow me to use inheritance.
While this certainly is an advantage in syntactics (f.e. no _memory = Memory.Instance stuff in constructors) and for me personally in appearance (I like blue highlighted classes :P),
I already figured out the cons, one major drawback being inheritance, the other being the lack of static destructors.
I started to make singletons, but it's not how I want to use the classes in every single Method (Memory.Instance.Read<IntPtr>((IntPtr)0x12654879), so for syntactical equal Usage I need to track a reference in every class.
How big is the performance hit of deriving your memory class (which should actually be fast like hell) from an abstract class? AFAIK, all methods (except those defined in the abstract class) have to be accessed through the VFTable... Is the difference noticeable? I guess it would be easier (though uglier) to check a static bool in the Memory.Read method.

Seems like I have to read up on some OOP design concepts for some inspiration.

You could always hide the fact that you're using instanced classes.

Eg; you expose static funcs from 'Reader' and those just call the instanced functions for the selected 'Memory' class you instantiated in the static ctor. (Assuming you use the class names above)

[Bananenbrot]

:facepalm: Could have thought of that myself -.- Well, thanks, I'll go and try a little.

[adaephon]

You're essentially doing the exact same thing as a global bool.

Also; debugging when in-process is no harder than debugging when out of process. Only requires 2 'extra' clicks. (Tools -> Attach to process [hotkeyed] -> WoW)

The difference is you only need to check a bool once - when you said global bool I assumed you meant having if (IsInProcess) { blah } else {blah } in every situation where it was applicable (i.e. each read/write method etc) rather than just once for class initialisation. If I misunderstood then mibad :P.

I know you can debug like that too. However, I've had a few situations where the debugger attaches only to my C++ launcher and refuses to step into .NET code (never looked into why; it stopped happening). Also, running your code inside another process does complicate the debugging somewhat - you have all of that process' complexities to deal with (timing, external communications etc)... i.e. a whole lot of non user code which is no where near as much of a problem with out of process solutions. It's generally easier to crash WoW hard from inside than out .

Anyway, I wasn't saying they were deal breakers or anything just things to be aware of. I.e. if you're not familiar with debugging, then it's easier to start in your own process/code than someone else's.

Also, @Bananenbrot on the performance hit of using vfuncs from inherited members vs static classes: completely negligible (especially with the usage you're talking about). Also, don't optimise your code before you know whether it's slow!

As an alternative to what Apoc said, if you're using something like Singleton but don't want to do StaticClass.Instance.SomeMethod() everywhere, you can always wrap it in a property in any class that needs it i.e.:

class SomeClass {
    public MemoryReader Memory { get { return StaticMemoryReader.Instance; } }
}

[!@^^@!]

Another thing you could do is to make an interface with the methodes you need for your reader/write class, then create 2 different classes implementing it, one that does the internal reading and one for external reading and simply initialize the singleton with either class depending on a flag or bool describing whether you're in or our of process

pesudo code:

using System;

namespace Solution
{
    public static class Memory
    {
        private static IMemory _memory;
        public static IMemory Memory 
        { 
            get    
            {
                if(_memory == null)
                {
                    if(InProcess)
                        _memory = new IPMemory();
                    else
                        _memory = new OOPMemory();
                }

                return _memory;
            } 
        }

        public static bool InProcess { get; set; }

    }

    private class IPMemory : IMemory
    {
        T Read<T>(IntPtr pointer)
        {
            return defualt(T);
        }

        T Write<T>(IntPtr pointer)
        {
            return defualt(T);
        }
    }


    private class OOPMemory : IMemory
    {
        T Read<T>(IntPtr pointer)
        {
            return defualt(T);
        }

        T Write<T>(IntPtr pointer)
        {
            return defualt(T);
        }
    }

    public interface IMemory
    {
        T Read<T>(IntPtr pointer);
        T Write<T>(IntPtr pointer);
    }

}