any reason why this is crashin wow?

[Nokia5800]

Hey guys Im trying this method...

6A00 PUSH 0
6808214000 PUSH String_OFFSET 
6808214000 PUSH String_OFFSET
B8B0AA4900 MOV EAX,49AAB0
FFD0 CALL EAX

But wow is only processes the first letter of the string... anyone know what I could be doing wrong?

Im injecting it in Opcodes... whats the best way to process a string using opcodes like below...

                        "0x" & _
			"6A00" & _
			"68" & SwapEndian(RemoteData) & _
			"68" & SwapEndian(RemoteData) & _
			"B8B0AA4900" & _
			"FFD0" & _
			"83C40C" & _
			"C3")

[peterwurst]

im using pipes atm but calling functions with pInvoke seems interesting.
Is there any special requirements to do that?

You can do this via a shared memory section (look at the wowsharp source).
But using shared memory limits the usage to only one instance at once.

Lanman92, how are you doing the P/Invoke calls?

[lanman92]

In-Process. Didn't I say that? Lol. I'm just loading the DLL into my C#(P/Invoke loads it when you reference a function with it). Then I call my init function and it hooks/whatever I would like to do. I could put this in the DLLMain function, but...eh.

I meant I'm going to start looking at dll loading in shared memory. I know you can load an exe/dll from memory(reflective injection). Gonna hit the books.

[Shynd]

You guys are all stupid and confusing. Holy shit.

One of the better ways to do it would be to use a memory-mapped file and some synchronization events. Inject a DLL that detours EndScene and check for the synchronization event to be signaled every frame; if it's signaled, access the memory-mapped file for what action(s) to take and data to expect, etc. It has the speed (almost) of a shared memory segment in a DLL and the usability (multiple possible instances) of sockets or pipes. Do some research and you should be able to figure it out.

[amadmonk]

You guys are all stupid and confusing. Holy shit.

One of the better ways to do it would be to use a memory-mapped file and some synchronization events. Inject a DLL that detours EndScene and check for the synchronization event to be signaled every frame; if it's signaled, access the memory-mapped file for what action(s) to take and data to expect, etc. It has the speed (almost) of a shared memory segment in a DLL and the usability (multiple possible instances) of sockets or pipes. Do some research and you should be able to figure it out.

Actually, a memory mapped file IS a shared memory segment (that's how it's implemented in the kernel). So the speed is maxxo profundo -- you don't get much faster than that short of perhaps nonpaged pool access.

And yeah, I laughed too at how much folks are overcomplicating stuff. Of course you can use shared memory from multiple processes; you just have to manage synchronization (just like in any multithreaded/multiprocess situation).

Still, though, I'd use pipes for IPC. They're nearly as fast as memory maps, and they take care of a lot of the message boundary/message interleaving issues for you. Shared memory is a tiny bit faster (edit: maybe not, something is tickling my brain about how local pipes simply USE shared memory for their implementation), but you have to manage your message protocol and synchronization very carefully. Sockets have the possible benefit of being more "cross platform", but they are marginally slower than pipes esp. for local access, and again you have to do all the message management yourself (unless you want to limit yourself to always fitting inside a packet, in which case you could just use UDP). So pipes are probably the best injected IPC mechanism, really. And since 3.5, using pipes is just stupid simple in .Net...

Edit: I'm still waiting for someone to get all tech and use MSMQ for IPC... Heh...