|
Ummm...Why try and piss on a spark plug when you could just run multiple virtual machines, each with its own copy of the game running?
|
|
|
|
|
Easy, the final product is going to be released (for free of course).
I can't release virtual machines, and they would take longer to set up then the current solutions. I am going for simplicity.
|
|
|
|
|
I wouldn't come here and ask for advice on hacking a MMORPG client, even if you have noble intent (which you didn't specify, so we can't assume either way.) Other people here probably play the game and don't want people interfering with whatever integrity the game still has.
That's kind of like going to an auto mechanics' forum and asking how to circumvent your car's ODB-II system so your car would pass inspection without repairing some problem, or going to a gun enthusiasts' forum and asking how you can manufacture parts that are illegal in your area.
No hate from me here. Just saying you probably shouldn't do this, nor should you ask here. Why run multiple instances, anyway? You can only control one instance of a game at a time.
|
|
|
|
|
While I would agree with you if I were doing anything that would gain an upper hand, in this case I do have to disagree.
There has never been a moral dillema with the end result I am trying to achieve. It can easily be replicated by having two computers next to each other.
The only part of the EULA that is being bent is not exercised against this type of third party program. Mind you that doesn't give users the go ahead, but there have been many non automated approaches that have been released without issue for years (Non automated meaning you have to load the game through the programs themselves)
There are also legit reasons for this, such as AFKing certain events with multiple accounts, trading between accounts without having to trust a middle man, and you can theoretically multibox.
modified 8-Nov-11 15:35pm.
|
|
|
|
|
I don't see anything in that which isn't just a rationalization.
|
|
|
|
|
Then I have to ask, what could I gain from having more then one client open at a time? I have five accounts, I like to AFK them for events and I trade between them.
My wife plays the game but is horrible at picking what items to keep from a farming run so she likes me to do it for her. Why close my current game to do the same thing with another account when I can have two open at once? I like to run two of those accounts in a way that they are in my party just sitting there for quests.
Again, all I can do with this modification is exactly what I can do with the four computers in the house (minus one account obviously), but that is a lot of extra electricity, room, and other members of the family like to use the computers.
Anyway, this has been done many times before, I'm just making it more convenient and easier for the end user. And I'm learning how to do something new in a programming language I love. Sure I could use things already made but why not improve it instead of settling?
|
|
|
|
|
Again all of that is just your attempt to rationalize your actions.
Seems rather pointless to defend it by trying to come up with reasons why it 'should' be ok.
Your responses indicate that you know that you are violating something but then you attempt to justify it by suggesting that it doesn't actually hurt anything. There might be merit to the later but it doesn't eliminate the former.
|
|
|
|
|
Seems rather pointless to try to convince someone of something when they are obviously ok with what they are doing. Call it what you like, I have no problems with what I am doing, and know that the gamers who play the game along with the developers of the game will have no problem with it. If they did, this type of modification would not be available on the forums associated with the game who have close ties with the games community managers, not to mention that there would be hundreds of bannings.
I'm not going to continue this conversation. If you have issues with what I am doing, that is your prerogative and you have a right to it. Just as I have a right to mine.
|
|
|
|
|
KairuByte wrote: If you have issues with what I am doing
I suggest you read my responses again because I didn't say that.
You are the one that is attempting th justify your actions by producing a number of different reasons why it 'should' be ok. If you (not me) didn't have a problem with the process in the first place then you wouldn't need to come up with alternative reasoning to explain why it was ok.
|
|
|
|
|
The reasoning was because this is a gray area, and I don't want someone who happens to read the thread over to think that I am doing this will ill intentions.
|
|
|
|
|
Update: Well, I started the process suspended and I hooked it soon enough, I'm just going to have to find a way to suspend the process as soon as it is created.... I'll have to look into that...
I'm not familiar with flags... It comes in with a desired access of 3221225472. I assume it is the result of the flags hex values being translated into a single int. Anyway, I just return 1 for both desired access and share mode. Well, 0x00000001, but same diff really.
Question: Does anyone have any idea how the heck to automatically cause all instances of a specific process to start suspended? I don't want to try to figure out drivers and such.... But I already covered DLL injection so why the heck not, right? I would just really prefer to not....
modified 8-Nov-11 21:39pm.
|
|
|
|
|
In order to make the program open the file in shared mode, you need to modify the "dwShareMode" parameter, it's the third parameter.
For instance:
PresentValue |= (FILE_SHARE_READ | FILE_SHARE_WRITE);
This tells the program to add the values of the SHARE flags to the existing flag value.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
You replied just before I edited. I had forgot to mention that I just requested read access and allowed read access. Both are 0x00000001 or 1, so it wasn't difficult.
Now I only have two issues. One being suspending the process as soon as it starts (Edit: The process will not be started from within any of my own code. I want to be able to suspend it when opened through any user initiated method), and the second is how to make the injected DLL call ReOpenFile if the original file isn't in share read mode.... I haven't been able to call a method from within the Run() code with EasyHook yet...
|
|
|
|
|
Without getting into drivers and things, the best way to have the program start suspended is to create your own launcher process.
Write a small program that calls CreateProcess with the CREATE_SUSPENDED flag.
Then, after you inject the DLL, call ResumeThread on the process's main thread.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Which means that I need to create a driver.... Bah!
A launcher process isn't really an option.... While it would be easily possible, it defeats the purpose of the entire program, unfortunately....
/sigh I suppose it's time to learn how to make a driver?
Will Anti-Virus detect this as a threat? It's going to have DLL injection and a driver that I assume will be loaded when the process starts and unloaded when the process ends..... And no real way to sign it apart from self signing....
Edit: I'll work on this more tomorrow. Maybe someone will have an idea for running something when I first hook the process?
Basically I need to find a handle within the process pointing at gw.dat, test it's file shared options, and if they are not read only shared, I will need to call ReOpenFile... Anyone have any ideas on that one?
modified 8-Nov-11 22:56pm.
|
|
|
|
|
I do have one more idea for you. Go to MSDN, and look up ShellExecuteHook.
EDIT-------------
This has been deprecated as of Vista. Sorry.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Would hooking ShellExecute(), ShellExecuteEx() and IsUserAnAdmin() work? I found it while looking for an alternative.
|
|
|
|
|
Well, yes, you could hook those functions in explorer.exe. Then, when the shell launches the specified program, you have your chance to modify the call so that it gets launched suspended.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hah, this is getting so frustrating.... It's too bad IShellExecuteHook was depreciated...
It's even more annoying that Microsoft didn't bother with an alternative...
Would hooking those functions globally work? Or.... I could attempt a driver, but I don't think kernel level drivers are possible in C#, and I would have to wing it in C or C++.....
And to make it worse, the only tutorial on making a driver doesn't work on my system. Something about not allowing unsigned drivers into kernel level....
|
|
|
|
|
Wait, don't be mistaken. It's true that IShellExecuteHook was deprecated, but the functions you mentioned before are still in use: ShellExecute, ShellExecuteEx
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Oh, I know that. The only issue I see is that to effectively make sure that I catch every single possible execution of the client, I would need to hook every single process, right? Just in case they open the client?
Or would hooking just explorer.exe work for every file run from any program?
|
|
|
|
|
Yes, I agree. You would have to hook every process.
Have you considered a system-wide hook to get your hooking dll into every process?
Global System Hooks in .NET[^]
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Wow, very nice article there. I'm surprised I missed it..... Thanks!
I'll definitely check that out! This way I can either hook the process creation, or even just hook CreateFile(). Though at this point I have another question I'm going to move down the thread line...
Edit: Looks like I could muddle my way into making that work... Might just hook CreateFile globally and look specifically for gw.dat openings.
I can see advantages for both. If I globally hook CreateFile and look for gw.dat, no matter what the process is named it would open read only. Which would be fine except when the user needs to update... If I globaly hook process creation I would be able to avoid issues with updating.... Maybe I'll implement both as options.
modified 9-Nov-11 21:56pm.
|
|
|
|
|
Ok, one last issue...
I may have figured out a way to call code from the Run() command, but I wont be able to tell until I actually try to run ReOpenFile.
I need help getting ReOpenFile to apply to a pre-existing handle, that I have no idea what the variable is. I don't know how to do something like this.... From Run() I need to find the existing gw.dat handle, run ReOpenFile to gw.dat to change user permissions, and have that handle still be callable from the rest of the program.
Ideas?
|
|
|
|
|
Okay, so I thought I had figured how to draw my own title bar, by painting the non-client area. For the most part I have it working. Currently I catch WM_NCCALCSIZE and I resize the frame. Then I paint the custom title bar and handle mouse events and such on my own. Now, when I add something such as a ToolStrip it overlays the title bar. Because the title bar is not painted outside of the client area. Do I need to adjust the client area of the form somehow?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
