[C#][Source][Copy/Pasta] Getting started with out of process botting

[skiiippp]

After reading msdn and some tutorials on ReadIntPtr I found that out too. That was a bit silly on my behalf, lol. So I wrote some console test app that uses ReadProcessMemory and that works. Thanks for the patience and input so far ^^

Seems like the project in the opening post was intended to be attached to the wow process (somehow) instead of the demo in the included test project. I could modify the memory read classes to use ReadProcessMemory, but I think I'll try to find out how the DLL injection thing works instead. It looks interesting and I'm eager to learn.

So I'll do more research and see how I can attach a DLL to the wow process such that I can use Marshal.Read from my DLL and access wow data. Since I'm set to learn stuff I don't want to use a library like BlackIce (Except for looking at the source to learn things).

[skiiippp]

So I'm trying to use easyhook to hook to notepad atm, but I can't get a basic example to work. I made a really basic DLL that just reports back the processID of the application it is in. The code is self explaining;

C# console app;

namespace ConsoleGUI
{
    public class RemoteGUIInterface : MarshalByRefObject
    {
        public void GUICallback(String msg)
        {
            Console.WriteLine("msg=" + msg);
        }
        public void ReportException(Exception InInfo)
        {
            Console.WriteLine("ReportException:\r\n" + InInfo.ToString());
        }
    }

    class Program
    {
        static String ChannelName = null;

        static void Main(string[] args)
        {
            Int32 TargetPID = Process.GetProcessesByName("notepad")[0].Id;
            Console.WriteLine("*** TargetPID:" + TargetPID);
            Config.Register("ConsoleGUI.exe", "WoWInject.dll");
            RemoteHooking.IpcCreateServer<RemoteGUIInterface>(ref ChannelName, WellKnownObjectMode.SingleCall);
            Console.WriteLine("*** inject @ ChannelName:" + ChannelName);
            RemoteHooking.Inject(TargetPID, "WoWInject.dll", "WoWInject.dll", ChannelName);

            Console.ReadLine();
        }
    }
}

C# dll;

namespace WoWInject
{
    public class Main : EasyHook.IEntryPoint
    {
        ConsoleGUI.RemoteGUIInterface Interface;

        public Main(RemoteHooking.IContext InContext, String InChannelName)
        {
            Interface = RemoteHooking.IpcConnectClient<ConsoleGUI.RemoteGUIInterface>(InChannelName);
            Interface.GUICallback("RemoteHooking.IpcConnectClient done");
        }

        public void Run(RemoteHooking.IContext InContext, String InChannelName)
        {
            Interface.GUICallback("CurrentProcessId=" + RemoteHooking.GetCurrentProcessId());
        }
    }
}

However, I just can't get past the following error. I'm running winxp 32 bit, all EasyHook files are in place. It's a bit tough since I have little experience with C# and visual studio, I have no idea what the problem is... It's complaining that it cannot find the the already running application ??

System.Reflection.TargetInvocationException was unhandled
  Message="Exception has been thrown by the target of an invocation."
  Source="mscorlib"
  StackTrace:
       at EasyHook.HelperServiceInterface.WaitForInjection(Int32 InTargetPID)
       at EasyHook.RemoteHooking.InjectEx(Int32 InHostPID, Int32 InTargetPID, Int32 InWakeUpTID, Int32 InNativeOptions, String InLibraryPath_x86, String InLibraryPath_x64, Boolean InCanBypassWOW64, Boolean InCanCreateService, Object[] InPassThruArgs)
       at EasyHook.RemoteHooking.Inject(Int32 InTargetPID, String InLibraryPath_x86, String InLibraryPath_x64, Object[] InPassThruArgs)
       at ConsoleGUI.Program.Main(String[] args) in E:\Documents and Settings\test\My Documents\Visual Studio 2008\Projects\BobBot\ConsoleGUI\Program.cs:line 35
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: System.IO.FileNotFoundException
       Message="Could not load file or assembly 'ConsoleGUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=984bf1c17d0d5735' or one of its dependencies. The system cannot find the file specified."
       Source="WoWInject"
       FileName="ConsoleGUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=984bf1c17d0d5735"
       FusionLog=""
       StackTrace:
            at WoWInject.Main..ctor(IContext InContext, String InChannelName)
       InnerException:

[amadmonk]

Try putting the assembly you're trying to inject into the same directory as the executable you're injecting into.

Also note that injecting .Net into a remote target is much more complex than injecting a C++ DLL. You're not just trying to map a piece of code into the remote process; you're mapping in a piece of code that loads the .Net runtime, which then in turn loads an assembly, and runs it. I would try to compile a working C++ DLL and inject it first, then tackle .Net.

Finally, you cannot just write to console in a GUI app without extra work. Most GUI apps don't have a console to write to; look at AllocConsole and other (native) methods for pointers. If I were you I'd try doing something like DebugPrint instead (then attach your debugger to the target process and look for the prints as you inject).

Injection is much more powerful than out-of-process, but with great power comes great complexity

[skiiippp]

Try putting the assembly you're trying to inject into the same directory as the executable you're injecting into.

Everything's in the same dir already

Also note that injecting .Net into a remote target is much more complex than injecting a C++ DLL. You're not just trying to map a piece of code into the remote process; you're mapping in a piece of code that loads the .Net runtime, which then in turn loads an assembly, and runs it. I would try to compile a working C++ DLL and inject it first, then tackle .Net.

I understand that, I started out by looking at how-to-inject-a-managed-assembly-dll and hoped that easyhook would make my life easier. I'd be happy to learn all that as well, but one step a time please

Finally, you cannot just write to console in a GUI app without extra work. Most GUI apps don't have a console to write to; look at AllocConsole and other (native) methods for pointers. If I were you I'd try doing something like DebugPrint instead (then attach your debugger to the target process and look for the prints as you inject).

I intend to turn it into a GUI app later, for now it's a console app like I said. Just keeping it really simple so I can get easyhook to work first... I hope xD

I've been fiddling with the code I just linked for hours now, I really don't see what's wrong and why it crashes on "RemoteHooking.Inject(...)".

[amadmonk]

Everything's in the same dir already

So, you have the assembly you're injecting copied into System32 (or wherever notepad.exe lives)? Or did you copy notepad.exe into the bin directory?

I understand that, I started out by looking at how-to-inject-a-managed-assembly-dll and hoped that easyhook would make my life easier. I'd be happy to learn all that as well, but one step a time please

Well, that's good. I made the comment because you didn't mention anything about a managed trampoline, or calling the COM interface for the runtime binding, or anything. It's non-trivial.

I intend to turn it into a GUI app later, for now it's a console app like I said. Just keeping it really simple so I can get easyhook to work first... I hope xD

I've been fiddling with the code I just linked for hours now, I really don't see what's wrong and why it crashes on "RemoteHooking.Inject(...)".

Well, assuming you're bootstrapping the .Net runtime correctly, note that you can't handle assembly references the way you normally would. Those assemblies you reference, also, have to be in the same directory as the binary you're injecting into, or in the GAC. Note that something like BlackMagic (or whatever) wouldn't be in the GAC, so it too would have to be in the same directory as the executable. Well, technically, in the app's working dir, but for most apps this defaults to the bin dir.

If I sound like a broken record it's because when I first got started injecting the runtime, this bit me numerous times. You can't just add references and automagically "have everything work" like it does in Visual Studio. You have to very carefully manage your reference paths, and remember that when you load most references in an injected app, you're looking at the file system from the context of the injected app -- NOT from the context of the injector (or from VS).

If all else fails and you're still getting assembly load failures, google 'Fusion logging' and log assembly binds. These will tell you exactly what assembly the runtime is trying to load, and where it's trying to load it from.

There is a way around this -- you can write a custom assembly resolver -- but it adds even more complexity to the system.

[skiiippp]

Thanks for all the input mate, really appreciate it

I've tried putting all files in the System32 as well, I guess there's no easyhook for me. I'll start reading up on the C++ stuff in the article I just linked.

ps. Do you think the cause could be in using visual studio express? Do you think it's worthwhile to pick up the full version visual studio at a mate's house and try that?

[amadmonk]

Thanks for all the input mate, really appreciate it

I've tried putting all files in the System32 as well, I guess there's no easyhook for me. I'll start reading up on the C++ stuff in the article I just linked.

ps. Do you think the cause could be in using visual studio express? Do you think it's worthwhile to pick up the full version visual studio at a mate's house and try that?

No, this shouldn't make a difference. For what you're doing, there's no real benefit to the full version over the express version.

If it is an assembly load failure, do google fusion logging and find out exactly what's happening. Along with potentially solving your problem, it will give you a much greater insight into how to troubleshoot assembly resolution errors.

[skiiippp]

So I check out Assembly Binding Log Viewer (Fuslogvw.exe), apparently I had to install the dotnet2.0 SDK first to get it. Anyway, have it up and running and played around with it. If set to log errors only, it's not logging anything. If I log everything, I only see successful logs.

Meanwhile I double checked the easyhook api docs and found that I should pass a description string first @ Config.Register(...), did that but it's not helping. Also tried to add absolute paths for all exe/dll parameters into easyhook (api docs say that's allowed) but i'm still getting the same ol' stacktrace... meh.

Is there anyone out there with a working mini project (like mine above) where easyhook is working? I don't want to leech copy/paste code, but having easyhook work on notepad at least on my system would be nice. Or could anyone put my snippet of code in a new solution and try it out?

edit: maayyybe there's something in this log. even though it says successful, there's some jibberish about not finding consolegui.exe as well;

*** Assembly Binder Log Entry  (3/4/2010 @ 1:17:05 AM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  e:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  E:\Documents and Settings\test\My Documents\Visual Studio 2008\Projects\BobBot\ConsoleGUI\bin\Debug\ConsoleGUI.vshost.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = TEST-489E0F609A\test
LOG: DisplayName = ConsoleGUI
 (Partial)
LOG: Appbase = file:///E:/Documents and Settings/test/My Documents/Visual Studio 2008/Projects/BobBot/ConsoleGUI/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ConsoleGUI.vshost.exe
Calling assembly : Microsoft.VisualStudio.HostingProcess.Utilities, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from e:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///E:/Documents and Settings/test/My Documents/Visual Studio 2008/Projects/BobBot/ConsoleGUI/bin/Debug/ConsoleGUI.DLL.
LOG: Attempting download of new URL file:///E:/Documents and Settings/test/My Documents/Visual Studio 2008/Projects/BobBot/ConsoleGUI/bin/Debug/ConsoleGUI/ConsoleGUI.DLL.
LOG: Attempting download of new URL file:///E:/Documents and Settings/test/My Documents/Visual Studio 2008/Projects/BobBot/ConsoleGUI/bin/Debug/ConsoleGUI.EXE.
LOG: Assembly download was successful. Attempting setup of file: E:\Documents and Settings\test\My Documents\Visual Studio 2008\Projects\BobBot\ConsoleGUI\bin\Debug\ConsoleGUI.exe
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: ConsoleGUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=984bf1c17d0d5735
LOG: A partially-specified assembly bind succeeded from the application directory. Need to re-apply policy.
LOG: No application configuration file found.
LOG: Using machine configuration file from e:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: ConsoleGUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=984bf1c17d0d5735
LOG: GAC Lookup was unsuccessful.
LOG: Binding succeeds. Returns assembly from E:\Documents and Settings\test\My Documents\Visual Studio 2008\Projects\BobBot\ConsoleGUI\bin\Debug\ConsoleGUI.exe.
LOG: Assembly is loaded in default load context.

edit2: I get a feeling there's something wrong with the whole deployment/project setup. It's kinda like the old DLL hell atm... isn't the whole GAC thing supposed to fix just this? jebus, MSDN doesn't even have an article (that I can find) on deploying an executable and x DLLs from one solution such that they can all "find" each other.

[SinnerG]

skiiippp, I know you want to learn how to do it on your own, but you should look at the Babbot source

I'm trying to make my own bot ('specially' for windows 7) based on it (I give back to BabBot if I got something to give back though)

[skiiippp]

Problem solved, I guess it was some visual studio problem. I have put my code inside the easyhook FileMon example application project and it works.

So now I've been checking ida tutorial and dumpthread to figure out the addresses for ClientConnection and ObjectManager. In the info-dump-thread I saw various results for both, and I found another one using IDA. working on sorting that out now

btw, from the OP's sourcecode, I'm using this code to find the player's guid (doesn't work atm, I guess the offsets need work);

            
ObjectManagerAddress = Memory.Read<IntPtr>(Addresses.ClientConnection, Addresses.ObjectManager);
//nothing found, yet !
var localPlayerGuid = Memory.Read<ulong>((IntPtr) (ObjectManagerAddress.ToInt64() + 0x40));

with adresses;
public static readonly IntPtr ClientConnection = new IntPtr(0x12705B0);
public static readonly IntPtr ObjectManager = new IntPtr(0x2d94);

addresses as provided by dumpthread.
When I checked IDA (first time user, so I may be wrong) I found; 0xC93410 and 0x2E04.

How can I verify these which pointers are correct (perhaps using CheatEngine)? Also, is the offset used for localplayerguid (0x40) correct?


Edit: I've got the pointers I found with IDA working after all, jeej. The problem was I was not using the Pulsator in the sample code and Memory.ReadBytes() made a call to Native.ReadBytes(), which uses ReadProcessMemory... and there was no process id/handle set since I don't use the Pulsator. So I Changed Memory.readbytes to;

public static byte[] ReadBytes(IntPtr address, int count)
        {
            byte[] bytes = new byte[count];
            for (int i = 0; i < count; i++)
                bytes[i] = Marshal.ReadByte(address, i);
            return bytes;
            //return Native.ReadBytes(address, count);
        }

Now I'm up and running, happily hacking away I have my DLL injected, hooked up to EndScene and from there on call an objectmanager.pulse(), which is inspired by Apoc's "Better Object Managment" topic.

A big thanks to Amadmonk for all the feedback, and to Apoc for posting some inspiring code !

[skiiippp]

Since I kinda hijacked this thread already, I'll just post this brief question here.
I've successfully made a call to the GetName function using a delegate and now I want to make a call to UnitReaction to find out if I can attack a given WoWUnit/guid.

        [UnmanagedFunctionPointer(CallingConvention.ThisCall)]
        private delegate uint UnitReactionDelegate(ulong a, ulong b);
        private UnitReactionDelegate _UnitReaction;
        public String UnitReaction(WoWUnit u)        //returns a string for now for testing purpose
        {
            if (!IsValid)
                return "<invalid>";

            if (_UnitReaction == null)
                _UnitReaction = Magic.Instance.RegisterDelegate<UnitReactionDelegate>(new IntPtr(0x006B8990));

            try {
                ulong a = Guid, b = u.Guid;
                return "a=" + a + " b=" + b + " res:" + _UnitReaction(a, b);
            }
            catch (System.Exception ex) {
                return ex.ToString();
            }
        }

However, a big fat exception is thrown;

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at WoWStarter.WoWUnit.UnitReactionDelegate.Invoke(UInt64 a, UInt64 b)
   at WoWStarter.WoWUnit.UnitReaction(WoWUnit u)

I got the pointer from the 3.3.2 dump topic, and double checked it points to (something) valid using cheatengine. What's wrong with the call I created?
Seems like my delegate does not have the right signature, but I can't find what it should be. Tried to fuss with IDA a bit but all I can find is "Usage: UnitReaction(\"unit\", \"otherUnit\")".

edit: sorry I misplaced the question mate. Still learning the reversing, still have a hard time finding the function signatures. But It's working now, thanks to your tip !

[Apoc]

Since I kinda hijacked this thread already, I'll just post this brief question here.
I've successfully made a call to the GetName function using a delegate and now I want to make a call to UnitReaction to find out if I can attack a given WoWUnit/guid.

        [UnmanagedFunctionPointer(CallingConvention.ThisCall)]
        private delegate uint UnitReactionDelegate(ulong a, ulong b);
        private UnitReactionDelegate _UnitReaction;
        public String UnitReaction(WoWUnit u)        //returns a string for now for testing purpose
        {
            if (!IsValid)
                return "<invalid>";

            if (_UnitReaction == null)
                _UnitReaction = Magic.Instance.RegisterDelegate<UnitReactionDelegate>(new IntPtr(0x006B8990));

            try {
                ulong a = Guid, b = u.Guid;
                return "a=" + a + " b=" + b + " res:" + _UnitReaction(a, b);
            }
            catch (System.Exception ex) {
                return ex.ToString();
            }
        }

However, a big fat exception is thrown;

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at WoWStarter.WoWUnit.UnitReactionDelegate.Invoke(UInt64 a, UInt64 b)
   at WoWStarter.WoWUnit.UnitReaction(WoWUnit u)

I got the pointer from the 3.3.2 dump topic, and double checked it points to (something) valid using cheatengine. What's wrong with the call I created?
Seems like my delegate does not have the right signature, but I can't find what it should be. Tried to fuss with IDA a bit but all I can find is "Usage: UnitReaction(\"unit\", \"otherUnit\")".

You really should do some reversing before asking questions.

int __thiscall CGUnit_C__UnitReaction(WoWUnit *this, WoWUnit *other)

Also, this thread is for OUT OF PROCESS botting. You're in process. (Totally different)

[SinnerG]

True that Apoc, but the example code attached to this thread only works IF in process botting :P

So you could say that either that the 1st post is 'off topic' (and so is skiiipp), or that skiiipp is on topic :P

Maybe the title of this topic should be modified?

[Rombus]

Yes, that I found out already :P

But then I ask this : can ANYONE run this app? (the one attached to the 1st post)

I'm using ReadProcessMemory now - is this valid for this kind of usage?

edit: Sure worked for IsInGame (byte '0' if not, byte '1' if so)

hi!
i'm also struggeling around with that, could you please give a hint how you changed the marshal parts to use ReadProcessMemory?

anyway the project itself is great, good structured and nice to read. thanks!

[adaephon]

Read MSDN: ReadProcessMemory Function (Windows)
Read up on PInvoke, and look at PInvoke.net implementation of RPM: pinvoke.net: ReadProcessMemory (kernel32)
Replace any Marshal.Read* methods with a call to RPM, or a wrapped Read method that internally calls RPM. There are plenty of examples posted around this forum, search through the pages of its history.