When tAmMo did his initial analysis of the packets he figured that headers during setup were 22 bytes long while the ones afterwards are only 20 bytes long. Until recently we went on with this scheme. When I was dumping the traffic between the server and my client I sometimes got very strange packets. These packets seemed to have the 22 bytes header! This did not make sense because only the unencrypted packets have 22 bytes in the header. Also these packets failed to make sense after decryption. Then it struck xbadc0de and myself: The server sometime decides zu send unencrypted packets!
So what does this mean: We don't have to figure out encryption. My dummy test server (which is just able to replay captured data) just sends out unencrypted packets and the clients just uses them. As easy as is. This saves us lots of time figuring out encryption, saves us compution time on our server and also means we don't harm the productive servers.
But how does the client detect an unencrypted packet coming in: Well, it's pretty easy. The third byte in the packet header is set to 0x00. It took me long hours to figure that out (and xbadc0de gave me the necessary hints, thanks!). I patched our decryption logic to deal with this fact.
https://gitorious.org/lotro/lotro-server/commit/52d3120caf0413e395549ba68f395cf88568ebe9
perfect ^^!
AntwortenLöschenMaybe you ment it that way: only add 0x00 0x00 before the packet (like the first three unencrypted packets) [0x00 0x00] + [0x00 0xF1 01 C2 ...] = 0x00 0xF1 is the server id, 0x01 0xC2 is data length of 0x1C2. But very nice. It works. I think there must be also an instruction in 1st server packet to force the client to send unencrypted packets, too.
AntwortenLöschenThere is another interesting thing i found out:
In the first server packet, there is this constant: DA 82 CF 61 ... 62 BB
You can't change that value, client won't run else. Where is this value from? I found it inside the "client_general.dat". Also the bytes, the client sends inside his 2snd packet. The serverbytes are somehow reversed in cl_gen.dat. "61 CF 82 DA 12 37 85 45 9C 4E 1C 6D 01 F1 62 BB 01" This seems to be an entry point for loading the data segements?
That were the good news, now the bad news: I ran into difficulties for parsing the data packets, when they are seperated over more packets. I haven't figured out the logic yet. For the beginning, i will take constants to parse them out, but that's no option for further implemenations. I want it generic, so that later on actions could easyly be added, without modifying thebase server and packet objects.
What i can say: (example on the shop data, which is large...)
1st.
[01 12 01 (00) | {07} 08 09 04 | 00 00 00 00 00 06 81 4A]
07 shows that the data is seperated over 7 packets. This is the last one (when you merge them). It's length is 0x14A bytes.
2nd.
01 12 01 00 {00} 08 09 04 00 00 00 00 00 06 80 FE 81 B0
These are the real first bytes (len: 0x1b0). The indicator, that this must be shop data is the 0xFE. Charadata is for example 0x6C.
last.
01 12 01 00 {06} 08 09 04 00 00 00 00 00 06 81 B0
So, parsing this can be managed, but the data inside the merged packet is difficult to gain or objectize. And the hell, i don't know what 01 12 01 (04) or (00) means and the other values 08 09 04. When client sends his split data, this is 01 10 01 00 {04} 05 03 04...
And inside world there are only 3 leading bytes, like: 02 40 02 00 or 02 50 02 00.
If someone got a good idea, please let me know.
-T-
I meant the following:
AntwortenLöschenI got this packet sent by the server (no encryption performed, just the raw packet:
000d 0001 ba00 0000 0600 0000 241a 64b4
5aff e032 9402 5001 00f9 0013 1b81 b000
...
The communication-ID is 000d (first 2 bytes). This is followed by a 0x00. This third byte indicates that the packet isn't encrypted. So sending a plain packet is:
[communication-id][0x00][header+data]
I uploaded the multipart packte 0x0110 which is sent during startup. Take a look it at http://bwgypyth.appspot.com/packet.jsp?packet=26001 (and other packets in that group). Everything that isn't highlighted in the packet is the data. This data got concatenated to http://bwgypyth.appspot.com/packet.jsp?packet=32001. I verified with xbadc0de that this is actually correct. You basically have to skip the first 0x12 bytes in the first packet and 0x10 bytes in the following.
The subcommand header should show how to build up the packet. Sadly for 0x0250 multipart packets I haven't yet figured why the header has a different length: http://bwgypyth.appspot.com/packet.jsp?packet=25002
Oh, another sidenote for the multipart packets: The server likes to send the packets in the following order:
AntwortenLöschenLast, 1st, 2nd, 3rd, ...
I my observations the logically last packet of a multipart packet was often sent at first.
Are you sure that this 01 10 01 has to do with char data? the client sends this order during joining character creation server. The chara data is never stored local, so why should he send this order? After that, the server sends the shop golden coin data.
AntwortenLöschenIn my opinion the indicator is followed after the 0x06. At splitted data it will only be send once(in the 2nd packet). So this would be the 0x90 in your case (and in mine too when i look at my packets). If you look at a single instruction:
(IP-Adress) 01 02 02 04 00 00 00 00 00 06 81 49
(Serv Name) 01 02 02 04 00 00 00 00 00 06 43
So how could the client guess whats meant? The beginning is every time the same. But the followed byte after 0x06 differs. (I left the following length bytes). So indicator for IP is 0x149 and Server name is 0x43.
One last example: Username + Charaname(s)
01 02 02 04 00 00 00 00 00 06 54
Again the same start, this time a 0x54 exists there.
Could you upload one or two packets, which your server sends unencrypted? Am i right, your packet looks like:
00 F2 (00) 01 03 00 00 00 06 00 00 00 02 ...
where 00 F2 is server/session id
00 the byte indicator that it's not encrypted
01 03 (0x103) length of packet
00 00 00 06 indicator for "action"...
This doesn't make a sense in my mind. Did you know that the client can go til chara creation when packets, like shop data are missing or wrong?
I think a leading double 00 will show that the packet isn't encrypted, like it's done at first packets. Look at client packet 2:
00 00 2E 9C 00 1C 00 08 00 00
The third byte is a 2E, because the session id, which is given from server is 0x2E9C. But this packet is... unencrypted...
Maybe you will run into trouble, when you add the third byte with zero value.
If you add a 00 00 each time you generate a respond in front of the packet it's working like charme with unencrypted data.
Look at the client output, if there are a lot of packets with action/root command [XX 00 10 XX], then the client missed someting.
-T-
If I'm not mistaken the logic you described as "does not make sense" is what I was actually observing. I'll retest this tomorrow.
LöschenNext to that the 0x0110 packet as found on the packet analyzer isn't sent by the client to the server but by the server to the client. Same goes for the 0x0250 packet.
I hope you keep going with this, I enjoy reading this technical stuff!
AntwortenLöschenIt would be so awesome to get something playable running someday.
they are, just join efnet #lotroemu
Löschensomething playable has been achieved but it's too early and bwgy's lack of updates is beginning to scare me
and there's been no git updates since the 24th of march.
Löschenperhaps something has happened?
From what i've seen in the irc channel so far there are a few people around and there seem to be two 'main'-programmers (tA and xbadcode) working on this project. But they dont seem to use the same codebase, more likely it seems they dont even work together and on different approaches to gather informations. I may be wrong but it seems one of them (tA) is digging deep into the client while the other one (xbadcode) deeply analyzes the packet streams. And it seems one is programming in C-Sharp while the other one is using C or C++ with a complete different codebase.
LöschenThere are a few other people hanging around in that irc channel, i dont know what they are doing, i guess they help out both programmers with informations or tests. So far there doesnt seem to be a playable version, tA states that he is able to enter the character selection screen while xbadcode seem to be able to "run around in the world as a chicken" (i assume he is refering to the chicken from the shire quest sessiongame), but i dont have seen anything working yet.
I dont know if there will ever be a real playable version and it looks like a lot of work needs to be done. Seeing the complexity of the original gameplay i bow down to all of them for their effort of trying to rewrite such things ...
I guess that describes the actual state of the project so far quite well ...
they're working hard (btw if you ever see a n00b### in irc that's me, i can't be bothered to make a name for myself) and I respect them.
Löschenbwgy told me that either he (and/or) badcode had a 'chicken party in rohan' so that proves they have session play working in some form.
still very anxious about the silence, this site was stone dead not too long ago but bwgy's recent stream of updates got my hopes up. one day there will be a lotro emulator and it will form from these guys
we need an update...
AntwortenLöschenI concur
LöschenStill waiting for that update Bwgy. Hope whatever's in your life thats occupying you right now will end soon so you can get back to being awesome with a lotro-emu :)
LöschenYet another blog corpse within the wilderness of the internet. Quite sad.
AntwortenLöschenyeah, they're all on irc though
LöschenDo you mean #lotroemu on EF ? Hmm, haven't seen any performing person in there for a long time ...
Löscheni usually see badc0de or rarely bwgy on efnet
Löschenbut yeah it looks like they've given up on this, wish they'd just put their work on git and move on
Borgata Hotel Casino & Spa Launches In Atlantic City
AntwortenLöschenThe Borgata Hotel Casino & 동해 출장안마 Spa, the first major Atlantic City 시흥 출장안마 casino to 문경 출장샵 receive the the Borgata Hotel Casino & 영천 출장샵 Spa in Atlantic City, a massive hotel tower, 포항 출장샵