RE: Unvaluable help to port SqlHierarchyId to .Net Core (Adam Milazzo on how the SQL Server hierarchyid data type works (kind of))
Unvaluable help to port SqlHierarchyId to .Net Core (anonymous on how the SQL Server hierarchyid data type works (kind of))
.: Reverse engineering Trepia | 2003-06-18 06:02PM :.
Trepia is a cool idea. It's an IM client that finds other people and sorts them by their proximity to you. But while it's a great idea, the client sucks, and it's not open source, so I can't fix its annoying problems myself. So, I decided to take some time to reverse engineer the protocol in hopes that somebody will write a better Trepia client. Maybe we'll be able to run it on *nix soon!
If you discover anything else, please post the additional information in a comment.
I coded up a simple proxy server that would write out the packets as hex dumps, but most of that work turned out to be unnecessary, because Trepia actually uses uncompressed, unencrypted XML to communicate with the server. So I spent a bit of time reverse engineering the Trepia protocol. I've only put about 2 hours into it, but I'm hoping other people will take this information and run with it.
To create a new account in Trepia, the NEWACCT packet is used. After that, when you connect to Trepia, the client sends the CONNECT packet, to which the server replies with the LOGIN packet. From there, it's a loop that simply processes incoming packets. I believe it doesn't need to store any state about packets seen/expected for its basic operation. The exceptions are when logging in, creating a new account, or downloading the current user's profile.
The default trepia server is located at 188.8.131.52 and runs a Trepia server on ports 8201 through 8210.
Data TypesTrepia uses the following data types:
Each packet is an XML block. The root tag specifies the packet type. Inside the root tag are immediate children, usually labeled 'a', 'b', 'c', 'd', etc. These children make up the parameters for the packet. So far, most children have been in a consistent order. However, the ones dealing with profiles or user data (ie DATAREPLY) have not always been in a consistent order. So, it's best not to rely on the order of the child nodes.
In the tables below, parameters are listed in the order the are generally sent/received by the official client.
Incoming Packets (packets from server to client)Index: LOGIN | MEMBER | LOCATION | QUERY | DATAREPLY | NIX | PROFILE | RATED
Packet: LOGIN, Node: L, Parameters: 3
The LOGIN packet is sent in response to a CONNECT packet or a NEWACCT packet.
<L> <a>0</a> <b>1055973014</b> <c>2</c> </L>Packet: MEMBER, Node: M, Parameters: 4
The MEMBER packet is sent to add/update users in the user list.
<M> <a>12592</a> <b>1055792857</b> <c>2</c> <d>1738</d> </M>Packet: LOCATION, Node: R, Parameters: 2
The LOCATION packet is sent to update the location/insta-blog note for a user.
<R> <a>1004</a> <b>Memory Leaks Fixed: NEW TREPIA</b> </R>Packet: QUERY, Node: Q, Parameters: 2
The QUERY packet is sent when a user sends a message to you.
<Q> <a>12592</a> <b>test message</b> </Q>Packet: DATAREPLY, Node: O, Parameters: variable, 2+
The DATAREPLY packet is sent by the server in response to DATAREQ packets sent by the client.
Many of these fields can be missing or empty.
<O> <a>11263</a> <p>georgia</p> <b>1055298503</b> <d>USERNAME</d> <m>25</m> <n>M</n> <g>First</g> <h>Last</h> <o>Network & Systems engineer (Cisco, Solaris, Linux, FreeBSD)</o> <e>firstname.lastname@example.org</e> <i>164494238</i> <j>aaronkclark</j> <k>email@example.com</k> <l>aaronkclark</l> <f>http://www.taoknights.org/aaronkclark</f> <r>United States</r> <s>TX</s> <t>San Antonio</t> <u>English</u> <v>School</v> <w>Company</w> <x>US -> Georgia -> Atlanta</x> </O>example 2 - photo data
<O> <a>7510</a> <c>1</c> <q>/9j/4AAQSkZJRgAB...kZJR</q> </O>Packet: NIX, Node: N, Parameters: 1
The NIX packet is sent by the server when a user has logged off.
<N><a>5272</a></N>Packet: PROFILE, Node: P, Parameters: 2
The PROFILE packet is sent by the server in response to the PROFREQ packet. The client can send an UPDPROF packet to alter the profile.
<P> <a>Adam</a> <b>PASSWORD</b> <k>21</k> <l>M</l> <e>Adam</e> <f>M</f> <m>this is my profile</m> <c>firstname.lastname@example.org</c> <g>27630686</g> <h></h> <i></i> <j></j> <d>http://www.adammil.net/</d> <o>USA</o> <p>CA</p> <q>San Diego</q> <r>English, Japanese</r> <s></s> <t></t> <u>US -> California -> San Diego</u> <n>/9j/4AAQ...qS5tz//Z</n> </P>Packet: RATED, Node: V, Parameters: 2
The RATED packet is sent when another user has rated you.
Outgoing Packets (packets from client to server)Index: CONNECT | DATAREQ | MSG | PROFREQ | UPDPROF | UPDNOTE | RATEUSER | NEWACCT
Packet: CONNECT, Node: C, Parameters: 5
The CONNECT packet is sent as soon as the client connects to the server. The server replies with the LOGIN packet.
<C> <a>00-07-95-EA-E1-CE</a> <b1>00-50-BA-75-10-F7</b1> <c>AdamM</c> <d>bfad699370b9c64abd7ec844813fc4e1</d> <e>2.51</e> </C>Packet: DATAREQ, Node: D, Parameters: 2
The DATAREQ packet is sent by the client to request data about a particular user. The server will respond with corresponding DATAREPLY packets.
<D> <a>7965</a> <b>1</b> </D>Packet: PROFREQ, Node: I, Parameters: 0
The PROFREQ packet is sent when the client wants to request its own profile. The server replies with a PROFILE packet.
<I></I>Packet: MSG, Node: F, Parameters: 2
The MSG packet is sent by the client when the client wants to send a message to another user.
<F> <a>12592</a> <b>send message to pf</b> </F>Packet: UPDPROF, Node: K, Parameters: variable
The UPDPROF packet is sent when the client wants to update its profile.
The parameters consist of the items to change and the new values.
<K> <a>password</a> <f>27630686</f> <m/> <t>US -> California -> San Jose</t> </K>Packet: UPDNOTE, Node: G, Parameters: 1
The UPDNOTE packet is sent when the client wants to update its location/insta-blog note.
<G><a>change my blog note</a></G>Packet: RATEUSER, Node: U, Parameters: 2
The RATEUSER packet is sent when the client wants to rate another user.
<U><a>12592</a><b>1</U>Packet: NEWACCT, Node: J, Parameters: 14
The NEWACCT packet is sent to create a new Trepia account. The server will reply with a LOGIN packet.
Many of these fields may be empty, but I think none can be omitted.
<J> <a>00-07-95-EA-E1-CE</a> <b1>00-50-BA-75-10-F7</b1> <c>2.51</c> <d>Adam</d> <e>password</e> <f>email@example.com</f> <g>http://www.adammil.net/</g> <h>Adam</h> <i>Foo</i> <j>21</j> <k>M</k> <l>my profile</l> <m>/9j/4AAQ...+Jpgf//Z</m> <n>US -> California -> San Diego</n> </J>
No comments yet.