PWI - Guide for finding chat message offsets - C# code included

[dumbfck]

[amineurin]

i start payling with this:

uint dwItemId // 0x0C ID of an item linked in chat

but the numer 9742236 i get, is no item in pw database.
is this number only for a item list inside pwi or did i miss something on the description ?
since reading chat text works fine, i use the same way be useing C then 8.

[dumbfck]

Yeah I had originally incorrectly marked that offset as itemID, when in fact it is actually a pointer to the item object / struct. I have figured that stuff out but it's not for the feint hearted lol. Also, it will be one of the features I intend to utilise in my upcoming program I shall be releasing in the future, so I don't want to give too much away just yet
I'll send you some info via PM later though as I trust you won't publish it

[amineurin]

ah thanks dumbfck, i just wonder myself here about the number and the pw database number
and u cooking again on something, i can swear i smell something wonderfull

[Shopko]

You guys are amazing. Thanks so much for this thread! As far as actually chatting, I know it's a lame way to do it but you can send keystroke messages to the elementclient window directly. I'm playing around with sending WM_KEYDOWN and WM_KEYUP to the window now. I just need to figure out how to put keyboard focus on the chat area. I'll post again if I get it working.

Originally Posted by Shopko

You guys are amazing. Thanks so much for this thread! As far as actually chatting, I know it's a lame way to do it but you can send keystroke messages to the elementclient window directly. I'm playing around with sending WM_KEYDOWN and WM_KEYUP to the window now. I just need to figure out how to put keyboard focus on the chat area. I'll post again if I get it working.

Well, **** that was surprising. Ctrl + D clears the chat window but also has the side effect of putting focus on the chat entry area. So, since the program on the first page already has a copy of the chat log in memory, we don't care if it gets cleared in elementclient.

My hope is to leave elementclient minimized and yet be able to send chat messages. If I get that working then I'll post the total project.

[amineurin]

Originally Posted by Shopko

My hope is to leave elementclient minimized and yet be able to send chat messages. If I get that working then I'll post the total project.

take a look on this autoit function:

Global $APP_BASE_ADDRESSFZ=10825500


;repeat this call every second or so...
unFreeze()


; the function...
Func unFreeze()
$FZ = _MemoryRead($APP_BASE_ADDRESSFZ, $PROCESS_INFORMATION)
If $FZ <> 1 Then
_MemoryWrite($APP_BASE_ADDRESSFZ, $PROCESS_INFORMATION, "1")
EndIf
EndFunc

now your window can be minimized

[Shopko]

That's pretty cool. I always anyway, but the unfreeze bit is a neat trick. Thanks!

I think I ran into a show-stopper with the Windows messages though. Windows keyboard input is stupid. First, your bot either has to run as Administrator or you have to turn User Account Control (UAC) off to be able to send messages to arbitrary windows, like elementclient. Second, when you press a key on the keyboard the following messages are sent to whatever program is in the foreground:

WM_KEYDOWN
WM_CHAR
WM_KEYUP

When the program gets the WM_CHAR message, it looks up the current "shift state" of the keyboard to figure out whether or not any of the Control, Alt, or Shift keys are down. There's no way to force that shift state just by sending messages. The result is that everything that gets typed in to elementclient is all uppercase, which is really annoying.

There is another Win32 call named "SendInput". This call *does* force the shift state, but it doesn't send keystrokes to any application you tell it to; instead, it sends keystrokes to whatever program is currently in the foreground. The equivalent wrapper call in .NET is System.Windows.Forms.SendKeys.

So, my hack solution goes something like this (the code below is C#):

[DllImport("user32.dll")]
public static extern bool SetForegroundWindow(IntPtr hWnd);

public void LocalChatMessage(string message)
{
    // Give elementclient focus
    SetForegroundWindow(m_hWnd);

    // Send the Control-D key sequence to give the chat area focus
    SendKeys.SendWait("^d");

    // Press backspace a bunch of times to get rid of any whisper names
    // or PWI chat identifiers (!@, !~, !!, etc.)
    SendKeys.SendWait("{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}{BS}");

    // Type the message in local chat
    SendKeys.SendWait(message + "\n");
}

It just really sucks that the elementclient has to be in the foreground to send simulated keystrokes to it. Ideally, we will eventually be able to figure out the parameters for the chat calls built in to elementclient...

[amineurin]

hehe this reminds me at my first bot, a mats farmer.
were i use the wasd keys to move the bot

maybe take a look at the prophet bot source, he send keys to the minimized client window and a lot more.
im sure if u take a look inside and check some ways to work, u get it all.

after u use the unfreeze, take a look at this:
send a key, to a minimized window too without nerving other open programms goes like this:

_SendMessage($HANDLE, 256, KEYCODE("{F1}"))

more explained here:

were handle is the handle of the client window.
theres another function KEYCODE, since u need for the sendmessage the keycode and not the key.

like:

Func Keycode($key)
If $key == "{F1}" Then
Return 112
endif
EndFunc

so just expand the keycode function with all keys and there codes...or grab them from this udf:

here are some more keycodes, like ur control and more:


since its fast, u dont need to send the whole stroke.
just send the stroke, char by char.

have fun

[Shopko]

LOL!

I wonder if dumbfck has been sitting back waiting for this moment with a smile on his face...

The question on how to actually send chat messages has already been answered in these forums . ROFL.

I feel so fail now.

Thanks again guys for all the work you're doing. And dumbfck, check out my reply in your other thread about AIMLbot.

[Interest07]

Another option is using the function closer to the packet sending level. Sending normal / party / trade / world chat messages is done with the function located at 0x63ab50 for example.

In c++ you can call it as follows:

sendText(0x774E00, L"I'm talking in normal chat");
sendText(0x774E01, L"I'm talking in world chat"); //requires a teleacoustic
sendText(0x774E02, L"I'm talking in party chat");
sendText(0x774E07, L"I'm talking in trade chat");

with the following declarations necessary for an injected dll:

class RealBase
{
public:
	Base* base; //0x0000 base 
};//Size=0x0004(4)

class Base
{
public:
		char unknown0[28]; //0x0000
	Structures* structures; //0x001C  
	void* packetPtr;//0x0020
		char unknown32[592]; 
	HWND hWnd; //0x0274  
		char unknown632[12]; //0x0278
	char serverAddress[100]; //0x0284  
		char unknown744[160]; //0x02E8
	char serverName[100]; //0x0388  
		char unknown1004[176]; //0x03EC
	float FPS; //0x049C  
		char unknown1184[96]; //0x04A0
};//Size=0x0500(1280)

static RealBase* realBase = (RealBase*)0xA521C0;

typedef char (__fastcall* __sendTextPacket)(void* pThis, int extra, int msgType, wchar_t* text, int int3, int int4);
static __sendTextPacket sendTextPacket = (__sendPacketFunction)0x63ab50;
static char sendText(int msgType, wchar_t* text)
{
	return sendTextPacket(realBase->base->packetPtr, 0, msgType, text, -1, -1);
}

When I was looking at the function at the time it was called with msgtypes of 0x774E00 etc, but as far as I know only the last byte matters, so 0, 1, 2, should work I think. For guild chat a different function is used (0x6477e0) but I doubt that one is really useful

[dumbfck]

Hrm... that looks cleaner than my method - I shall have to give that a try later
Cheers.

[Interest07]

Keep in mind that it won't show the stuff you say on your own client

So have to check if it works on a second client.

[dumbfck]

Hrm that rings a bell... I think I may have found a similar function to that one when I started doing the chat sending stuff then

For anyone wondering why that would happen, it's because when you send a message, it doesn't bounce back from the server, i.e., you don't receive your own message back - The client just echoes your message locally in the chat window.
Anyone who's played with the receiving messages stuff might have also noticed that names of items that you link in a message actually show up, whereas when someone else links an item, it just shows up as <><1>.
You need a bit more magical trickery to get those item names.

[Shopko]

I've been tracing through the code for a couple of days, looking at what accesses the chat area memory in Cheat Engine and then tracing the code in Oly Debug or IDA. I don't know how you guys found these offsets, I'm very impressed. Tracing through the assembly from procedure to procedure is so painful and time-consuming. I keep feeling like there has to be a better way... Care to share any tips to speed up this process in the future (like when they update the client again)?

Thanks again for all of this information, you guys are great for sharing it with all of us.

------------------------------
INSERT MORE HOURS HERE LOL
------------------------------

Okay, I finally traced through the assembly far enough to find where the chat is actually being done. To update the original project on the first page, here are the offsets for the current elementclient (v624):

public static uint baseCall = 0xA521C0;                         // v624
public static uint playerBase = 0;                              // Calculated later
public static uint nameOffset = 0x664;                          // v624
public static uint chatObjectsBase = 0xA57A98;                  // v624
public static uint lastChatObject = 0xA57AA4;                   // v624
public static uint sendChatCall = 0x00540630;                   // v624 sendChat function address

And here is the updated sendChat op-code (only thing that changed is the address of the "speak" ASCII text):

private int sendChatOpcodeAddress;
private byte[] sendChatOpcode = new byte[]
{
    0x60,                                   // PUSHAD
    
    0xB8, 0x9C, 0x47, 0x95, 0x00,           // MOV EAX,ElementC.0095479C    ;  ASCII "speak"
    0x50,                                   // PUSH EAX
    0xBB, 0x01, 0x01, 0x00, 0x00,           // MOV EBX, 101
    0xBE, 0x00, 0x00, 0x00, 0x00,           // MOV ESI,chatSystemClassPtr   ;  [[[[[[baseCall]+1C]+18]+8]+C4]+20]
    0x8B, 0x16,                             // MOV EDX,DWORD PTR DS:[ESI]
    0x8B, 0xCE,                             // MOV ECX,ESI
    0xE8, 0x00, 0x00, 0x00, 0x00,	        // CALL sendChat()

    0x61,                                   // POPAD
    0xC3                                    // RETN
};

With these changes, it's working beautifully. Thanks so much guys!

[dumbfck]

Nicely done, sir thanks for saving me the trouble of updating it hehe.
I'll add some finishing touches and update the first post a bit later today... well the first post in the other thread
Nice to see someone new here with the enthusiasm to really get stuck in and figure this stuff out ^_^

One thing I never got around to checking last time because I wasn't familiar with the technique... I'm hoping that this call can be somehow derived from one of the function pointers in the chatbox's vTable (not sure if that's even the correct term, but that's what I'm gonna call it lol) in a similar way that the setChatText is. E.g., the setChatText() address can simply be found at [[[chatBoxBase]+0]+0x44]
I don't think the sendChat() function is directly referenced in that table, but I suspect that there's something else there that calls it
As another example, when I was fiddling with this last week, I think I found that the setWhisperName() func pointer is in that table, e.g., the function that inserts someone's name in the chat entry box when you click their name etc, which in turn calls the setChatText() function.

Been finding lots of cool stuff in the client ever since I found out about those tables hehe.