SiLo.dev

Network Encryption Algorithm

2010-05-11T05:59:00.000-04:00

I've started up a wiki of Dark Ages reverse engineering information so that the developer community can benefit from the more organized and centralized location of documentation. Right now it's only hosting this single page, but I'll be adding them as I go along so I too have a good reference as well as everyone else.

Dark Ages Developer Wiki

The funny part is I started out typing the documentation in normal text and soon became quite frustrated when it constantly removed my formatting or didn't take it properly. It was really annoying when it came down to the sequences and C# code, until I found out I could use LaTeX for math and a code tag for C#. Doh! Needless to say, I was went from very annoyed to quite pleased within a matter of minutes. There are a few odd issues with formatting that required me "reformatting" some sections so they would properly render but the major issues were resolved.

As the wiki develops more pages I'll go back and add links to the newer pages (for example dialog encryption, packet formats, etc).

Feel free to bookmark the site and leave me any comments/suggestions.

DALoader v1.0.0 Released -- The first of many to come!

2010-04-15T03:51:00.005-04:00

As I've made a good amount of progress on the server and patch 7.27 rolling around, I feel the need for a good, flexible tool for launching Dark Ages without having to hard-edit the file. I really only needed host/port redirect along with multiple instances. Since I plan on integrating a basic version of the server as part of the map editor for loopback testing, I figured "no wall" would be a decent addition for testing some maps.

Like I said, the main feature is that the loader should not modify the executable on disk so that the patcher doesn't complain and also in case Dark Ages tries to be funny with hash checks on itself someday (doubtful). That and it's just more programatically elegant. I also wanted something that could work with various file versions just in case I needed to use a previous client version.

Thus, DALoader was born as you can see below:

Download Link (MegaUpload) ~ 91.1 KB (7.26 & 7.27 profiles included)

Requires .NET 3.5 Runtime (pre-installed in Windows 7)

Now, I had originally posted this over at PlanetDA, mostly because I figured people were looking for a multiple instance tool that worked with 7.27. It was soon removed due to the "no wall" part making it a hack tool and possibly giving players an unfair advantage over others. While I can see the rationale to a point, this is not the first tool to do so and furthermore not the first tool hosted/advertised on PlanetDA to do so. What is even funnier to me is that while this tool requires you to close the "no walled" DA instance and run it again with walls, several other tools allow it changed at runtime and (at one time) hosted on PDA quite recently. So somehow, my "test feature" hack is not allowed while other very convenient and single-purpose tools are.

I'll just say, you use what you use at your own risk and you be the judge. You've been warned, even though no one is going to know you're doing it anyways. Just for emphasis, you can not toggle the "no walls" portion at runtime (though that may become a feature if needed with the map editor integration later).

I'm pretty sure the usage of this program is straightforward. You select where your DA executable is, which client version you want to use, and then what options you go. The nice part is that the profiles include file size and MD5 hashes so it will attempt to automatically chose the right client version based on your file. If this is incorrect or you want to manually set it, you can do so. Since it uses MD5 hashes, if you have modified your executable, this feature more than likely will not work in detecting the version.

The settings are saved so when you open the program it should be just like when you left it. Do be sure that you extract the profiles directory to the application path. If you don't (or don't have any profiles) you won't be able to use it as it has no idea where to apply the changes.

So how does it work? The program creates a suspended process of DA. That means it loads the process into memory and is immediately frozen indefinitely. The changes are then made in memory and the program is resumed, of course this all happens in a matter of milliseconds. Since the changes are made in memory and not on the actual file itself, your DA executable is left untouched. Each client version has a profile which lists where each change should be made in memory so that it doesn't have to be hard-coded for a single version in the program itself.

Anyhow, feel free to report any bugs or possible suggestions! Do keep in mind that this project was intended to be a quick utility to serve a small but important purpose so I am quite reluctant to add any more functionality to it.

P.S. For the curious, the profile XML files refer to the address in process memory, in decimal (base 10). If you plan on making your own profiles, be sure to use the process address (file address + 0x400000).

So Close, Yet So Far

2010-03-11T06:37:00.001-05:00

That's the feeling I get every single time I use the next Ubuntu release. It's closer and closer each time to becoming everything I need with app support and whatnot, but always falls short of one or two critical things. Previously, I had converted to 9.10 and dual booting Windows 7 for any purposes requiring it (read: games). For a while I was really happy with Ubuntu and it did everything I needed, and I was ok with some of the differences in programs.

And then I just couldn't do it. Now, I won't dog Linux or Ubuntu in particular, it's not their fault in this case. The problem is with MonoDevelop. While I commend their efforts greatly, it still falls too short of Visual Studio for me to switch, mainly in the debugger. The IDE itself is nice and offers most of the features I'd want in an IDE, including code folding and code completion (though auto-formatting would be nice for the OCD/lazy me). However, the debugger still has a ways to go. It does work much, much better and fluid than the last time I tried it, it doesn't quite make it in my books for my impatient self. Long(er) wait times for program execution to hit the debugger, flaky edit and continue support, slow/unhelpful mouseovers while breaking, and odd stepping at times made me miss VS too much.

Another slight issue which again isn't Ubuntu's fault is the fact that some of my programs require native DLLs invoked via C#'s platform invoke. This works fine under Windows but trying to do so in Mono with Win32 DLL's and Wine is a nightmare. I looked at the Mono documentation if it was possible to do so but it seemed like it was not, and I had figured as much as the Win32 subsystem is indeed not running on Ubuntu! Like I said, slight issue and easy enough for me to work around it by developing the programs under the Windows 7 boot.

The issue comes down to what am I getting out of developing under Ubuntu? Cross-platform is the real main answer. That and the self-satisfaction of running Linux and enjoying breaking from Windows, but that's more a personal preference. What I would be losing is time, as it takes me much more time to get used to MonoDevelop, deal with its issues in the debugger, and work in an environment that I'm less familiar with. Is it worth it? That's the harder question to answer. Obviously, the first and third issues would go away with time, hopefully the second as well with newer releases, but not a true guarantee. I figured C# code is almost by-nature, very portable. Not too much of the code is Win32-specific, I could easily compile it under Mono in Windows under VS.

It seems, at this point, I have very little reason to break away from the Windows platform at this time. Sticking to it does not mean I believe it's the only operating system in use and I can respect (and develop for) other platforms as well. Dark Ages is a Windows game so with that slight bias, I do realize that some hackery may be best under Windows though that could be virtualized under other OS's too.

So really this is about me developing under Windows again on Visual Studio. However, when I do release binaries, there will be ones for Windows/Mono side-by-side (where applicable). For example, the 2D isometric engine that I develop to be used in the map editor and then a possible standalone client will be coded in SDL.NET which uses OpenGL, not DirectX. This makes it much easier to port to other platforms as Ubuntu and Mac OS X both support OpenGL and SDL.NET has ports for both of them as well.

The good news is that I have gotten a good bit of the core done for the server. Network code is done, encryption/security code is done, and packet formats are on their way. I'm really liking how this is turning out and I can't wait to see the fledgling server up and running (again). I won't be releasing source code (at first) but I will be releasing the libraries that all my projects are using so that other developers can work on DA-related projects with great ease. Of course, the libraries will be released as I develop them too, so don't expect the 2D engine out just yet!

A Good Start is Half the Battle

2010-02-25T14:41:00.001-05:00

At least that's what they say right? Anecdotes aside, one of the reasons for the delay since the last posting is deciding how the project should be developed and maintained. Whether it should be open or closed source, C# or C++, Mono or Microsoft, cross-platform or Windows-based, and the list goes on.

Another issue I have been debating is whether or not to allow others to help me work on it at the same time. The reasons I am for it should be obvious, though the reasons for me being against it maybe not so much. The issue truly comes down to having code that complies with the standards I would like. This is a huge project and I know it will only grow even larger as times goes on. I want the code to be a certain way and I don't want to waste time trying to enforce that on others and go back 'checking' code and such. It's much easier if I do it myself and then I have no one else to blame except myself if it isn't as I wanted it. That, and setting up source control, relying on people using it correctly, and whatnot creates more overhead that I don't want at this moment.

Going forward, if I decide to allow others it will be much easier as I can just throw the code I have in a repository and then others can look from my work and see how it should be when they code their additions. It's much easier to learn from example rather than lengthy documentation.

In the past I have been mostly Windows-based. For most, this is not a problem as Dark Ages runs on Windows and most users run that OS. That, and Dark Ages runs fairly well on Wine/Parallels, so there's not too big of an issue on that either. However, I would like to make the transition to cross-platform using Mono. Previously, I was hesitant on this due to Mono-Develop's debugger not working properly for me, but it seems they have fixed these issues since 2.2. Of course, Windows users can still run the program but now Mac OS X and Linux users also have an option without having to rely on other compatibility and emulation layers.

I see no reason to use C++ over C#, as the latter offers outstanding performance and I am very familiar with it. Not to mention development time is far less with C#. Honestly, I see few reasons to use C++ anymore in most situations unless you really need some interop layer or low-level access, but that is just my opinion!

The main project itself is the server, but that requires a lot of tools development as well. I plan on using custom maps, so that means a map editor is required. I also will use custom metadata for items, so that means a metafile editor too. Debugging network packets is no fun, so that's going to be another tool I'll need to get data from the server for reverse engineering as well as testing my own server. As you can imagine, this list just grows and grows. For this, I plan on making a base library which will contain code for interacting with various Dark Ages-related types and functionality, one of which will be a rendering engine for the map editor. The engine will also be recycled in a stand-alone client to be released later but that's very tentative.

So no, the project is not dead by any means! It is true that real life duties get in the way of things, but I am trying to devote a large amount of time into this project when I can. Keep checking back for updates!

A New Year's Resolution for a New Decade

2010-01-22T05:31:00.011-05:00

2010. Why this year stands out as more important than the last nine may remain a mystery. Perhaps it is the turn of a decade or the fact that we're one step closer to the ominous 2012 doomsday predictions. What I do know is that it marks another year of the Capricorn project bearing no real fruit. This always comes as a depressing reminder and this year I have decided to do something about that.

While I have many projects, both related to Dark Ages and others not, the Capricorn project is by the far the most ambitious and rewarding of them all. It is one project that I have always wanted to see realized and working as I had envisioned. There have been other private servers in the works by other individuals and such, which have been admirable efforts as well but seem to have eventually suffered the same fate as Capricorn.

The current state of the US server also worries me. How long Dark Ages will continue to go on? Many years ago the Malaysian Dark Ages (Legends) was shut down and the Japanese version (Yami) soon followed. The US Dark Ages server is still up and running but for how long it will continue remains unknown. While I do not speculate it going down permanently anytime soon, the current game and how it is run does not bode well.

One main goal of the Capricorn project was a completely customizable game down to the classes, items, maps, mundanes and monsters -- a server emulator, not the server emulated. The greatest part about Dark Ages is that even though it is over a decade old, it still has so much potential. Unfortunately, that potential does not lie in its current form and will require a good bit of tweaking but the potential is there nonetheless. That same potential is what keeps this project going.

So to end this post, I welcome 2010 and look forward to a lot of exciting milestones being reached for the Capricorn project this year!