Clientless

Is clientless still possible? Anyone have one working?

Yes possible. Not sure what bots still use it but clientless is and always will be 'possible'.

It may become incredibly difficult if tq ever became intelligent in their bot checks or bothered to change encryption... but it will always be 'possible'



A clientless is simply just a proxy with the forwarding functionality removed and instead imitates an actual client... this means you have to add in MANY, MANY more packets and make them structured properly and add in a few bot protection things but the theory behind it is not at all complex.

It's actually something I was interested in attempting at one point but I don't really see the use as bots (paid and free) were simply overloading in supply at the time.

Thanks. Do you know who maintains the fusion origins wiki? I would like to consult them on how they determine packet structures. I have a working proxy (same one from a year ago, apparently TQ is still using DHExchange with no signatures lol) I just don't really know how to analyze packet structures.

Quote:

Originally Posted by princeofpain Thanks. Do you know who maintains the fusion origins wiki? I would like to consult them on how they determine packet structures. I have a working proxy (same one from a year ago, apparently TQ is still using DHExchange with no signatures lol) I just don't really know how to analyze packet structures.

[Only registered and activated users can see links. Click Here To Register...]

Structuring packets is pretty easy though. Just look at the values in a packet, see if you find something that you recognize, it could be a map ID, character coordinates, a string (like a name, chat message, etc.), a number that increases every time you repeat the action - timestamp, etc.

So I guess recording a bunch of packets of the same ID and figuring out the structure by inspection is the best approach?

there has been some changes to some of the packets that were documented. Besides character info and another 1 (i dont remember atm), i did not notice other changes. Again dont hold me on what i said since i am not using all the packet structures.

The general strategy in understanding packets is as hawtness has mentioned.

1. read packet type, that will quickly let you have an understanding of the kind of packet you are dealing with.
2. cross reference to current documentation available to you. grasp an understanding of what is currently present in the packet (usually more data will be added, existing wont be removed).
3. If an unknown value is found, assess if that value is important to you, if no, you can always leave it be (i did, lol) or, make an intelligent guess what values might be potentially associated with this packet type and compare with game values.

Very good rundown on how packets works.

I generally like to sniff a few seconds worth of packets at a time relating to a certain feature.


For example if I was trying to code my own custom clientless bot I'd be VERY interested in the initial requests for login.

So... I'd sniff the authentication section of packets (not sure why you'd want to do this as it's documented to death but w/e).


I'd then take the 4-5 packets logged (login sequence, pre game server) and try to figure out what each packet does.

To do that I'd...

#1: Check existing resources. Public private server sources are a GREAT resource as they contain a shit ton of packet structures (the wiki is nice but it's out of date and doesn't contain 'everything', nor does it really need to). This will let you know what the packet does just by how it's named usually (IE: Auth response packet)

#2: Check for known values such as... account information in this case. The more you can structure of the packet the better. Yes you may end up with some unknown values but it takes a large amount of the packet out of the guessing game. If you cannot figure out what the remaining values are... try logging the same packet (with as similar conditions as possible. This helps find values which are either encrypted (spell attacks for example) or are related to non character values (such as timestamp, date time, OTHER characters/entities, etc). Then try logging the same packets with different conditions... say different account or w/e.


Keep in mind when structuring things (gets easier in time) that there are common ranges or w/e.

For example if I see...

E0 93 04 00

I can tell you almost instantly we are dealing with the UID of a monster (300k-400k)


But say I see...

60 E3 16 00

I can say it's most likely a player uid (1 mill++)

Simple knowledge such as this helps you structure packets MUCH faster and determine what they are being used for (lots of unknowns + a monster uid... means something involving a monster... narrow it down by sniffing small time periods of packets while you/mob do different actions... feel free to 'narate' inside your packet log by using the chat system (such as "I'm depositing meteor in tc wh" or w/e so you know what's happening inside the packet log and aren't looking in the completely wrong section.

Yeah, i did miss out on the internal encoding of packets, and the login phase. :)

try erlang language.. erlang is best suit for it