Half a CO Client?

03/05/2013 22:53 -Shunsui-#1
So for some odd reason, When running Conquer Client on a Windows XP,
The client would have missing stuff, Such as the F' Keys and such.

I got it to work once, Which was when i copied the CO Folder, and moved it to a different Directory, from C: to Desktop, but after the first time that it worked it stopped working. Copied>Repasted same thing kept happening it would work the first time but not again. (WEIRD!)

[Only registered and activated users can see links. Click Here To Register...]
Any help/Tips?
03/05/2013 23:15 abdoumatrix#2
use this injector
03/05/2013 23:55 -Shunsui-#3
Quote:
Originally Posted by abdoumatrix View Post
use this injector
Do you happen to know what's causing it ? or what fixes it in the injector? Because i already got a "working injector" but noticed no difference from mines.
03/06/2013 22:02 ShittyMod#4
Quote:
Originally Posted by -Shunsui- View Post
Do you happen to know what's causing it ? or what fixes it in the injector? Because i already got a "working injector" but noticed no difference from mines.
I suggest you use this way of injecting your DLL:

1. CreateProcess with the CREATE_SUSPENDED flag.
2. Get the main thread's context by using GetThreadContext and the hThread of the PROCESS_INFORMATION structure.
3. Get the address of Kernel32.LoadLibraryA (or LoadLibraryW, whatever)
4. Allocate memory in the target process using VirtualAllocEx and write the path of the DLL you want to inject to the allocated memory
5. Create your custom DLL loading asm code inside the process using VirtualAllocEx + WriteProcessMemory. The custom DLL injecting code should look something like

Code:
push entryPoint // Get this using GetThreadContext - the CONTEXT structure contains the value of the EIP register

pushfd // To preserve the flags

pushad // To preserve the registers

push dllPathAddress // The one you allocated and wrote into memory earlier in step 4

mov eax, loadLibraryAddress // LoadLibraryA/W address from step 3

call eax // Loads the LoadLibrary function -> Your DLL

popad // Restore registers

popfd // Restore flags

ret // Return to the entry point (the first thing you pushed on to the stack)
6. Wait for the injection to be done (I usually just wait 5 seconds, but you could have a variable set inside the target program that you set to a specific value or whatever when done loading)

7. Clean up - Close handles, free the memory you allocated, etc.

Edit:
I forgot step 8. Obviously you'd need to resume the main thread again after everything is done using ResumeThread on the hThread you got from the PROCESS_INFORMATION returned by the CreateProcess function :o
03/06/2013 22:19 shadowman123#5
@Shitty Mod : that seems too hard .... what language should i use for this and is there any good tutorials for this ?
03/06/2013 22:26 ShittyMod#6
Quote:
Originally Posted by shadowman123 View Post
@Shitty Mod : that seems too hard .... what language should i use for this and is there any good tutorials for this ?
Uhm, yeah, it's probably one of the "harder" DLL injection methods, but it's also safer as there's no race conditions and shit. If you use the CreateRemoteThread method you don't really have any control over when your hooks are getting installed, I mean, you could be installing your OpenMutex hook or whatever right in the middle of a call to the OpenMutex function. One of the many drawbacks of multi-threading.

You can use any language to create this kind of loader, as long as you to have direct access to the Windows API.
03/07/2013 06:12 lostsolder05#7
We had this same issue in Element when I was using CreateRemoteThread.
03/07/2013 08:32 ShittyMod#8
Quote:
Originally Posted by lostsolder05 View Post
We had this same issue in Element when I was using CreateRemoteThread.
Yeah, I remember that some of the paid bots had similar issues too. What are you using now then?