What are the risks with DLL injection? menu

User Tag List

Results 1 to 15 of 15
  1. #1
    object's Avatar Member
    Reputation
    5
    Join Date
    Aug 2008
    Posts
    13
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    What are the risks with DLL injection?

    I've seen a few people arguing for/against out-of-process & DLL Injection.

    I have a lot of experience w/ SW RE, but I've just started poking around with WoW.

    Over the past few days, I wrote a waypoint/anti-afk system using out-of-process methods. Using out-of-process, I'm sort of bound to using PostMessage(). To interact with NPC's, I have to screw with the mouse and pass the Right-Click-Down message. I dont like it. It does not provide an easy approach for future features.

    I would much rather hook into the in-game "API" but I am a bit concerned with causing a lot of process faults while debugging a DLL. Most of my work with DLL injections have been pretty straight foward that just get over a simple hurdle. Writing an anti-afk/waypoint system to grind honor is a bit more complicated.

    How are you guys interfacing to your injected DLL's while debugging, and not? If there are things that I need to be aware of, please give me a heads up. For this thread, I'm more interested in a top-level discussion of what is being done, rather than how it's being done.

    Here's what I'm thinking... feel free to give your advise/comments/criticism:

    Create a DLL that is capable of reading memory locations, calling in-game API functions and providing information back to me (perhaps via a log file or GUI). Queing up for BG's...running around from point to point... maybe spamming random BG garbage (dont cap frostwolf before relief hut.... anal [Rupture] ) .

    Inject said DLL into WoW.

    Go to the bar and get a few drinks.

    Come back and buy S2 gear.

    What are the risks with DLL injection?
  2. #2
    Shynd's Avatar Contributor
    Reputation
    97
    Join Date
    May 2008
    Posts
    393
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, there's kinda two schools of thought on what to do once you decide to inject a DLL, each of which has its own subdivisions of preference (or ease of development?).


    1) You inject a DLL and that DLL takes care of everything. It either silently runs a scripted bot with no GUI, or generates an in-game GUI by either hooking DirectX (CEGUI) or hooking the lua script engine and accepting user inputs from a particular addon. I'm sure there's other ways of doing it, but those seem to be the most prevalent ways of creating an in-game GUI and, when I go that route, those are the two that I'll decide between.




    2) You inject a DLL that simply communicates with an external application, either feeding that application data or receiving input from the external application and taking action inside the game's process context. The big headache, here, is IPC, or inter-process communication.

    Probably the easiest, most portable, and most well-documented way to do this is simple socket communication. The external application would act as the server, listening for incoming connections, and the DLL would simply connect to localhost:whatever_port. Once the connection has been established, data can be moved back and forth between the two with great ease.

    One of my favorite, for OTHER uses (games that != WoW), is Named Pipes. Look up the Windows API CreateNamedPipe if you want to really go into depth, here. Basically, however, you create a file handle to a file that does not actually exist on disk. Another program (your DLL, for instance) can then open that file and write data to it or read data from it, thus passing information back and forth across the pipe. This is quite portable, as well, because it uses the very common CreateFile API to connect to the pipe. Hell, even AutoIt can open an existing file in shared mode. Not quite as good as a socket, but interesting nonetheless.

    You could also make a shared segment of memory in your injected DLL, one that all processes that load the DLL can access. This allows you to call a function that will fill a data structure with the object at address 0xWHATEVER and then you have direct access to that object in memory, since you have the DLL loaded as well. It's not really that portable, seeing as you can only have one instance of WoW open on the same computer (remember, injecting the DLL into another process shares that data segment between the two Warcraft clients, too, causing all sorts of problems). This is how WoW!Sharp handled telling its injected DLL what actions to take: it detoured the game's RenderWorld routine and checked a value in the shared segment for an action to take. It's not exactly what I'd call elegant, but it works if that's what you want to do.

    And, lastly, the really, really newbie way of inter-process communication: sending or posting Windows messages between windows. Don't ****ing do this. Even using WM_COPYDATA is a bigger pain than some of the more elegant methods of IPC. Just, really, don't do this.



    Anyway, once you decide whether you're going to let the DLL handle all of the botting logic or if you're just going to issue commands from an external process via IPC, all you really have left to do is to decide how you want to gather information and/or take actions. Are you comfortable detouring certain functions for an event-driven method of gathering information, hopeful that Warden won't detect it? Would it be safer, albeit slightly less efficient, to simply poll for data? And, once you figure out WHAT you want to do, take a look at bobbysing's WoWX hack over on gamedeception.net. All the classes you would ever need, all the virtual functions, all the patterns, everything.



    Anyway, I get the feeling that I rambled on longer than I kinda expected to from the outset, and Cypher is going to call me a newbie for even considering SendMessage a viable--albeit NEWBIE--version of IPC, so this is where I'm going to stop Hope it helped, at least somewhat, or gave soem food for thought / topics for further learning.
    Last edited by Shynd; 08-20-2008 at 08:27 PM. Reason: added whitespace

  3. #3
    object's Avatar Member
    Reputation
    5
    Join Date
    Aug 2008
    Posts
    13
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you for taking the time to write that up. I appreciate your input. +Rep

    I ultimately plan to have the DLL silently run everything, but while I am debugging, and trying new things I need some kind of feedback as a sanity check.

    I am against using SendMessage/PostMessage for passing user input to WoW. I would use it for updating controls in a GUI from a thread...polling x,y,z and updating a debug GUI (in the DLL) which is displaying real-time coordinates (amongst other things).

    This project is for personal use, so I have absolutely no plans of making it fancy (or public). In-game GUI is out of the question, however I really like the idea. I would consider implementing it after I get the bot working (while I'm afking honor)

    I'd like to get a few more responses to see how others are doing it.

  4. #4
    Shynd's Avatar Contributor
    Reputation
    97
    Join Date
    May 2008
    Posts
    393
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You can always use OutputDebugString and check output via WinDbg. That plus stepping through with OLLY has always done me right even without any kind of debug GUI.

  5. #5
    object's Avatar Member
    Reputation
    5
    Join Date
    Aug 2008
    Posts
    13
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well... here's some shit...

    PRB: Cannot Create an MFC Thread During DLL Startup

    SYMPTOMS
    An MFC DLL that creates a new MFC thread during startup hangs when loaded by an application. This includes whenever a thread is created by calling AfxBeginThread or CWinThread::CreateThread inside:

    • the InitInstance of a CWinApp-derived object in a Regular DLL.
    • a supplied DllMain or RawDllMain function in a Regular DLL.
    • a supplied DllMain or RawDllMain function in an Extension DLL.

    STATUS
    This behavior is by design.
    The in-game GUI is sounding better and better...

    --EDIT---

    So, I had to make a Post_Init function for the DLL...

    I inject the DLL into Wow.exe, then inject the DLL into my App to find the Post_Init procedure address [GetProcAddress()]. Get the proc offset from the inject location... add this to the Wow inject offset and I can now CreateRemoteThread(... Post_Init_Proc_Address... ) to create a god damn MFC dialog, running inside WoW space.

    I got to say... this is MUCH easier than calling ReadProcessMemory() and WriteProcessMemory() all the time.
    Last edited by object; 08-21-2008 at 01:59 AM.

  6. #6
    Cypher's Avatar Kynox's Sister's Pimp
    Reputation
    1356
    Join Date
    Apr 2006
    Posts
    5,368
    Thanks G/R
    0/4
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There are no 'risks' inherent in DLL injection. The risks come from modifications you make to the game (eg hooks, memory mods, etc). But that has the same risk level as out of process changes.

    Also, while you're debugging you could always use WoWs console. That's what I do, I hook into the console and use it to recieve commands and print debug information. The offsets you need should be in the 2.4.3 release thread, if not let me know in this thread and I'll post some code for you.

    If you're going for injection you have several choices as to how you do your UI. I personally hook WoW's LUA engine and Console and then do a UI via an addon. But you could also use a 3rd party GUI kit such as CEGUI (which works great) and which would very easy to port across games.

    CEGUI would be the easiest to set up too for someone who's new to reversing WoW. I personally prefer using the console, but it's all just personal preference.

    Also, whenever your DLL causes and unhandled exception you'll get a popup window which will let you debug it, if you feed your debugger the PDB file generated by your compiler you'll be good to go and debugging is very easy.

    If you're causing faults inside WoW itself through passing malformed intput to a function I suggest launching WoW through a debugger so that any exceptions can be caught before being handed to WoW's unhadled exception filter.

    Anyway, this post has terrible structure and was written up really quickly caus I'm in a rush atm, if you need more info post here and I'll be glad to help out.

    Good luck.


  7. #7
    Shynd's Avatar Contributor
    Reputation
    97
    Join Date
    May 2008
    Posts
    393
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is the console currently scanned by Warden? I wouldn't think so but you never know.

  8. #8
    Cypher's Avatar Kynox's Sister's Pimp
    Reputation
    1356
    Join Date
    Apr 2006
    Posts
    5,368
    Thanks G/R
    0/4
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No. IsFuncPointerInScope is (to which a patch is required to get your callback funcs registering), but you can get around that extremely easily.

  9. #9
    lanman92's Avatar Active Member
    Reputation
    50
    Join Date
    Mar 2007
    Posts
    1,033
    Thanks G/R
    0/1
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey cypher, could you explain more on how you use CEGUI inside of the program? I would like to do this, but it doesnt seem...available?... for c#.

  10. #10
    Cypher's Avatar Kynox's Sister's Pimp
    Reputation
    1356
    Join Date
    Apr 2006
    Posts
    5,368
    Thanks G/R
    0/4
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by lanman92 View Post
    Hey cypher, could you explain more on how you use CEGUI inside of the program? I would like to do this, but it doesnt seem...available?... for c#.

    Unless you do a whole bunch of work to make a managed<->unmanaged bridge its not available to you in C#. To use CEGUI you need to be injected inside the process and you cannot inject managed code into an unmanaged process without a lot of work.

    In short: You can't. Use C++.

  11. #11
    Apoc's Avatar Angry Penguin
    Reputation
    1387
    Join Date
    Jan 2008
    Posts
    2,750
    Thanks G/R
    0/12
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cypher, you fail again!

    SourceForge.net: CEGUI#

    The C# port of CEGUI. (Pulled from the official CEGUI site) I've used it a few times, and it works. Just not quite as easily as the C++ end.

  12. #12
    Cypher's Avatar Kynox's Sister's Pimp
    Reputation
    1356
    Join Date
    Apr 2006
    Posts
    5,368
    Thanks G/R
    0/4
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by Apoc View Post
    Cypher, you fail again!

    SourceForge.net: CEGUI#

    The C# port of CEGUI. (Pulled from the official CEGUI site) I've used it a few times, and it works. Just not quite as easily as the C++ end.

    Ohhh! I knew you had a C# implementation but I thought you wrote it yourself.

    Also, my point on injection still stands, it would be a huge pain to get it running inside WoW, you'd have to inject code manually all over the place and create remote threads to manage it all. Right??

  13. #13
    Shynd's Avatar Contributor
    Reputation
    97
    Join Date
    May 2008
    Posts
    393
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cypher: I did a little bit of reverse-engineering and I seem to have found ConsoleExec (executes console input) at 0x0063DB10 and ConsoleWrite (output's text to console) at 0x0063BEE0. Would I be correct in assuming that ConsoleExec is not scanned by Warden and detouring it so as to grab input--until in-game GUI becomes something I want to work on--would be acceptable?

    When you're talking about IsFuncPointerInScope, you're talking about adding console commands, right? The callback you specify won't be added unless it's within WoW's scope, or you patch it? That makes sense to me. I originally thought about just appending all of my commands with "//" (double forward-slash), detouring ConsoleExec, and parsing out anything that starts with those two chars. Registering console commands seems so much more elegant, though, now that I know what is needed. I'm going to reverse a little more to see if I can find IsFuncPointerInScope on my own, but, as always, I'm open to input or links with more information

    Sorry for hijacking your thread, object =p

  14. #14
    object's Avatar Member
    Reputation
    5
    Join Date
    Aug 2008
    Posts
    13
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by Cypher View Post
    No. IsFuncPointerInScope is (to which a patch is required to get your callback funcs registering), but you can get around that extremely easily.

    Can't you make temporary patches as you need to run things, and put them back when you're done? Enter the critical section to lock "the" resouce... do as you please...clean up and exit the critical section.

    Would this work?

  15. #15
    kynox's Avatar Account not activated by Email
    Reputation
    830
    Join Date
    Dec 2006
    Posts
    888
    Thanks G/R
    0/0
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In this specific case, no. When you enter a command into the console, the Input Processor finds the callback (if any) to the command entered and passes it to this function which determines if its in the .text section of WoW. If its not, you get a nice little error message. Otherwise your callback is called successfully.

Similar Threads

  1. what are the risks of gold scamming
    By Liquid Malfunction in forum WoW Scams Help
    Replies: 1
    Last Post: 10-22-2008, 03:16 PM
  2. [HELP!] What are the Value's in this LUA?
    By Creepfold in forum World of Warcraft Emulator Servers
    Replies: 4
    Last Post: 02-27-2008, 11:28 AM
  3. Flying mounts in Azeroth: wat are the risks?
    By Zoned08 in forum World of Warcraft General
    Replies: 5
    Last Post: 01-31-2008, 05:45 AM
  4. What's the matter with denmark?
    By Zoidberg in forum Screenshot & Video Showoff
    Replies: 12
    Last Post: 12-28-2007, 04:41 PM
  5. What are the Ascent commands???`
    By zerohero in forum World of Warcraft Emulator Servers
    Replies: 9
    Last Post: 10-13-2007, 10:38 PM
All times are GMT -5. The time now is 08:25 PM. Powered by vBulletin® Version 4.2.3
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. User Alert System provided by Advanced User Tagging (Pro) - vBulletin Mods & Addons Copyright © 2024 DragonByte Technologies Ltd.
Digital Point modules: Sphinx-based search