eveofdarkness.org

Which client can talk to an OpenDAoC server?

Our client now logs in, enters the world and logs out cleanly against our OpenDAoC test server. So far everything we know about the protocol comes from server source code and one recorded session someone else made. The next step is recording our own sessions from a real client, and that raised a basic question: which client?

The official installer is just a patcher

The installer from the official site is a 15 MB self-extracting archive from 2009. It holds the EA Mythic patcher, DirectX redistributables and help pages, and no game files at all. On first run the patcher downloads the whole client from the official patch server.

That server's file lists are public. The current game.dll, the core of the client, is version 1.130, built on 2026-09-10. (We read its version information; we didn't run it.)

OpenDAoC stops at 1.129

An OpenDAoC server has one packet-writing class per client version, from 1.68 to 1.129. Each version inherits from the one before and overrides only what changed. When a client connects, the server reads the version from the first packet and picks the matching class. A version it doesn't know is disconnected.

1.128 and 1.129 are there; the 1.129 class, added in September 2025, is empty, meaning the server treats 1.129 exactly like 1.128. 1.130 isn't there yet. Supporting it means finding out what changed in its packets and writing a new class, and that needs someone with recordings of a 1.130 client. So a fully patched official client can't connect to an OpenDAoC server today. We've added this to our open questions (L10).

So shards ship a 1.127 client

OpenDAoC's client page says any client with a 1.127 game.dll works, and offers a full installer of its own: "a modified version of the official client" with classic towns, capitals, Darkness Falls and Old Frontiers, which doesn't work on the official servers. Other groups re-host that installer for their own private servers.

As far as we can tell, the modifications are content and connection, not protocol. OpenDAoC only implements the official packet layouts, so a client it accepts has to speak plain 1.127. And "doesn't work on the official servers" would be true of any 1.127 client now that live requires 1.130.

The older route is still around too. Shard launchers start a separate copy of the old game.dll through a small connect.exe that points the client at the shard and switches encryption off: connect.exe game1127.dll <server> <account> <password>. Years ago Dawn of Light setups did the same with a 1.109 game.dll and a tool called DAoC Portal.

1.127 seems to be where the community settled: the encryption-off tooling supports it, OpenDAoC's own client uses it, and UI packs like Ghost UI are built for "1.127E". That's our reading; nobody has written down the reason.

How the encryption works

The official servers encrypt the traffic; OpenDAoC runs without encryption, and so does our client. Still, we wanted to know what's being switched off. OpenDAoC's source has the whole scheme:

  • A modified RC4 cipher. The key is a 256-byte block, expanded with RC4's standard key schedule. Then three changes: every packet starts from a fresh copy of the cipher state, the second half of each packet is encrypted before the first, and each plaintext byte is mixed into the cipher state as it goes.
  • An RSA key exchange. The server's first reply carries its RSA public key. The client picks a random 256-byte session key, encrypts it with that public key, and sends it back. OpenDAoC sends an empty key instead. In the recorded session we work from, the client still sends a 256-byte block, which the server ignores. One of our open questions turned out to be this key.

So there is no secret key hidden in the client. The session key is random for every connection, and the private RSA key never leaves the server. Recorded official traffic can't be decrypted from the recording alone; the old packet loggers read the session key out of the running client's memory instead. We won't take apart the client ourselves. If we ever need to read official traffic, we'll use tools others have published.

Next

  • Record sessions from OpenDAoC's 1.127 client against our server, and compare them with what our client sends: packet order, how often it sends position updates, how it logs out.
  • Keep the official 1.130 client for comparisons with the official servers later.
  • Write up any differences in our protocol notes.