SWTOR packets

Hey guys,

Has anyone been able to get on top of the datastream in this game? I'd be willing to compensate anyone who may be able to share this information ( assuming you've figured it out ). I'm having more difficulty that usual creating a helper tool with this particular client. Btw I'm NOT asking for anyone to show me how to code, inject a dll, or dissassemble, or use a debugger or anything fundamental like that. I just need some help understanding this client.

In an ideal world, I'd like to find a function in the client that when called, takes a parameter value which gets appended to the stream, either a pointer to a buffer with a full blown packet inside, or an individual data element ( that would work fine too ). If anyone can help me identify a line of code where this is happening, I should be able to put a breakpoint on it with a debugger, edit the data, and then let the client do the rest and send it out the door without having to mess with encryption - that information I'd be willing to pay for. Then I should be able to take it the rest of the way myself after that.

PM me if interested, thanks!

- Mithra

Like any online game that use a binary client:
Start with the base packet functions like "send()" and "recv()" and work your way backward.

For "recv()" breakpoint it, then put a memory breakpoint on the buffer to see what accesses it. Work your way backward to the receive handler et al.

For "send()" step it back, and, or, look at the call stack and look for the main receive queue handler function. And then perhaps the packet parser and main handler(s).

Pretty much guaranteed all modern games will be using some kind of network queue mechanism, maybe in their own thread to step packets out on send, and to load and parse them on receive when data comes in, etc.

The raw packet streams will be encrypted, and, or, packed.
But you can pretty much ignore these things as it sound like you want to do things from the client.
You will issue your own packets at a level above the send encryption routine(s) (ideally there will be one main "add packet to send queue" function), and then for receive you just pick up the packets after they been decrypted (ideally after they have been parsed and separated just before handling).

Be advised though SW:TOR currently does have a basic anti-cheat system that will catch foreign/unknown DLLs and some of those exact socket functions (like "send" and "recv") they do look for hooks and break points on their entry points, etc.

Also some debugger detection.
Still might get detected but use OllyDBG with plugins like "Phantom" to hide common debugger detections and use HWBP so Olly won't place int3's were you want to break.

Been some reports of people getting banned while messing with the game. But then others that had injected DLLs and such for a long time with not even a warning.
Do any of this at your own risk..

Thank you for the robust reply!

I understand what you have said - I've actually spent the last hour stepping upward from the WSASend call that is constantly spamming status updates to the server. This has usually been my method of last resort haha. It's typically easier for me to find a value in memory, like the quantity on an item stack, put a memory breakpoint on it, and then locate the code that sends a "split stack" packet. Or work with currency values in the trade window, etc. My experience with many games has been that the packet handler is looping and possibly in its own thread, which is initialized when the client starts up, and may not actually connect back to that higher level function I'm looking for. Not saying this is the case with SWTOR btw. I will work more on it tomorrow.

What I HAVE been able to do is scrape strings out of the client as they are presented, so I can pick up names of directx textures, players in the social window, chat text, and any entered text.

I've also figured out what my actual coordinates are LOL; I have an active detour in the code that reads and displays them as I run around. The coordinates they show on the map are actually multiplied by a value to obscure the internal xyz of the 3D objects, no doubt to prevent teleports and speedhacks, among other things. I've not been able to teleport my toon yet, but I was able to accidentally teleport some objects in the zone while trying. Local to just my client I'm sure. :)

As far as bannings go, I guess I've been lucky because I've not had a problem. I inject a dll and I run a debugger ( though an obscure debugger that no longer works on MOST hardware configurations HAH ). I actually didn't start working on it until early access though, so maybe they have other concerns atm. One thing I wouldn't mind learning how to do in the future is mask a module so that it cannot be enumerated after its injected.

Anyway, yes, the higher level function that takes a buffer and maybe a packet length as a parameter is the holy grail here, but I can't say many games have it all so neat. The games which are a bitch are the ones that encrypt each piece of data AS its being appended to the buffer. I don't know which kind of game this is yet.

Another technique is to find a function that does something relatively infrequent, call it, and just hijack the packet on the way out. This is what I did for WoW. There is a function for looting an item and it takes a single parameter, which is the slot number of the thing you want to loot. I'd call it from my dll and pass it slot 250, which is absurd, no container would have that many items, detect that in a separate hook thats looking at the outgoing packets, and then overwrite the buffer with whatever data I had queued. That works pretty well too, and you don't have to worry about gumming anything up or screwing up a counter, as the native function should clean up after itself.

Either no one is working on this or no one wants to collaborate :)