Our biggest issue right now is to understand how the packets are assembled when they are tranfered from and to the server. Our previous attempt was to document the packets within an LibreOffice document hosted in our git repository. Sadly this does not work very well and especially does not scale. Only one developer can work on the document at a time.
Starting today we are working on a small web based packet analyzer. Right now it is capable of displaying a single annotated packet taken from our current documentation, which is a rather limited functionality. We are working on creating a server backend to store annotated packets so everyone can collaborate and either annotate packets or give feedback to annotated packets. You can take a very brief preview at the following URL:
https://gitorious.org/lotro/lotro-analyzer/blobs/raw/92df3298baa914602354df7501ea493e305851ca/packet.html
Note: The code is currently tested in Google Chrome, Firefox and Internet Explorer.
colorful :D
AntwortenLöschenVery well, this is a good idea. But there is a little mistake: 0x00 0x61 is length/size of payload data. The first 0x00 0x00 will fall apart, when session with server is inizialized, so that every header's length is 20 bytes. So the green part 0x00 0x01 0x00 0x00 is the "action"-indicator, where 0x00 0x01 0x00 0x00 means session init request from client side, 0x00 0x04 0x00 0x00 then the server response on this and finally the client confirms with 0x00 0x08 0x00 0x00.
AntwortenLöschenNow, only more people have to look at this blog ;-)
Just sent you the latest .exe version of the server. Client no keeps running the whole time. No patched client needed. You'll get til chara selection screen. Feel free to release it.
AntwortenLöschengood progress!
LöschenI got the server. Sadly my virus scanner didn't like it and I had a hard time getting it to my system. That's also the reason I haven't run it yet and I'm currently unsure if I'll release it. But it might as well be a false alarm of my virus scanner. I'll find out during this weekend.
LöschenNext to that you can always dump your current code on me. Most people just want a binary to run the server, but to me code is much better because I want to understand how it works :-)
Anyway thanks for your help! It is really appreciated!
Mhmhm, thats strange. I only modified the helper.dll, that it couldn't be reversed easily (because of the checksum parts) Does the scanner complians about the .exe? Inside the exe there are only the routines to start server from server.dll, nothing more. I don't know if the "unsecure" anon mail service changes files inside .zip's. They could inject a virus with ease.
AntwortenLöschen-T-
So my reason for the .exe release is that everyone, especially non-programmers can figure out things on character creation. A source code which isn't a .exe can't be compiled from people who have no understanding in programming without installing the developer environment and so on...
I'm self not 100% shure how the original server could work. I'm only guessing, so my source code would not be optimal.
Call the .exe in a virtual host environment, than you can be shure that no virus will harm your system. The server runs without changes on mono/linux when i compile the source with sharp developer.
But ok, will send you the source in the next days. I'm modifying it, so that it loads an default chara from file, where you can change the values and see what happens.
-T-
I guess my virus scanner just was scared of an exe within a zip file. I tried the server last night and I was able to dump some packets. Then I was able to simply copy content of the packet file into the upload of my analyzer and play with it. Worked like a charm :-)
LöschenNext to that: Don't worry about your source code. First of all we are prototyping right now. Almost everything is a hack when you start to write something that will become a large program. That's just a fact. If you are doing reverse engineering (or doing anything where you don't know where you are heading) it will just be more chaos. It's the nature of coding :-)
I'm a professional programmer for 15 years for different companies. I've seen code that has been in production for years that was so horrifying you get nightmares of :-D The code I've seen from you is totally fine. It works great, doesn't crash randomly and produces reproducible results. That's all I'd expect at this early stage :-) So your code is nothing to be ashamed of. Just don't worry about it's quality.
If you are adding stuff you can look at the modifications I made to your source code. I added a few things that might be needed for loading the character from an XML file.
The crc32 from LOTROServer.zip is 19c87504. If it's not so, than it's definitly modified. Boah, i have to learn to write better in english, just took a look at my previous post...
AntwortenLöschenSo again, i will send you the source when i have rewritten some of the packet parsing parts. i am not happy with this kind of object parsing. My last runs showed me, that packets could drop to fast, even if i'm in a local network. if you would run it over internet, than there would be more loss. It happened to me that only one packet was missing and the client crashed with an exception. If the homebrew server has resend it like requested from client, this fatal mistake wouldn't happen. It's a long way before the "architecture" is working like it should.
-T-
The CRC32 is fine. Next to that: Wenn Englisch zu kompliziert ist, können wir uns auch auf Deutsch unterhalten. Ich bevorzuge nur Englisch, damit alle es verstehen.
LöschenRegarding the crashes: I haven't seen one of them so far. No idea why. I tested the latest lotro-client on Windows 7 x64 and didn't get it to crash it. Strange.
I'll think it's because of threading sometimes. I've made some static classes (as singleton pattern, helper and sessionhandler), they maybe not thread safe. Yesterday i took a look at the joining world packets. They are a little bit complicater than the charagen packets.
AntwortenLöschenI also wrote down some answer packets, when you use an illegal character name. There are many different cases, where only one byte changes. I tried to find equalities between them and the client_locale.dat, but no success. The worst case will be, run the client for 256 times and write down what happens... :-/