This started out as the introduction to the next post I was planning to write, about some interesting connections between servers that have come to light, but ended up being worthy of its own post. As I’ve mentioned previously, on a semi-regular basis I scour the internet for any new LUNA private servers that may have popped up. This is done primarily with the goal of archiving any potentially unique assets they might contain, to preserve them for potential reuse or future study, as most private servers are quite short lived, and when they’re gone they tend to be gone forever. This post serves as a rough walkthrough of that process, with a focus on archiving patches.

Archiving a client usually consists of downloading the client installer, examining it for any potential malware, and extracting its contents. This is followed by checking to see if they are using a non standard PAK file layout, or custom AES keys on their BIN files, and if so, reverse engineering the specifications for each to enable easy future access to the archived copies. The details on how to determine whether either of those cases is true, and if so how to reverse engineer them, have been covered in earlier blog posts (PAK and BIN).

If the server is still up and running properly, I then try to archive their patch history, this typically consists of obtaining the launcher / patchers patch URL, sometimes via a settings INI file, but usually either via FLOSS (a tool designed to retrieve potentially obfuscated strings from binaries), or by running the launcher (inside a sandboxed environment for safety) and using WireShark (a tool that allows monitoring of network traffic) to see what IP the launcher attempted to reach out to for its version file and patch(es). In most cases, this ends up being a subdomain or directory of whatever URL their website is at, or an ftp server at the same location as either the website, or the game server itself in the case of LUNA Classics older FTP based patcher.

A word of caution while we are on the topic of patch serving, for any LUNA private server developers who might someday read this. The risks involved with running a potentially misconfigured FTP or HTTP server should not be understated, as described previously in our post about RALUNA. I have not seen anyone mess up an HTTP based patching server badly enough to leak privileged information yet, while I have now seen two different private servers with poorly configured FileZilla FTP servers, that allowed unlimited read and write access to their entire game server hard drives. This would suggest that the FTP based launcher is probably not the best idea unless you’re sure about what you are doing.

After obtaining the address or URL that the patcher is fetching patches from, we can attempt to download the entire back history of patches. Usually this is made easy by poorly configured web servers that have directory listing enabled, allowing us to just browse through all the patches and download whatever ones we want, however that isn’t always the case. When directory listing isn’t enabled, we have to know the URL of each patch in order to download it. Luckily, this isn’t usually too hard to figure out, as both the LUNA Plus and older LUNA Classic EyaSoft patchers, which almost all the private servers end up using, both store the current version on disk in in a file typically named either LunaVerInfo.ver or MHVerInfo.ver, although this name is changeable should the server have decided to do so. This version file contains nothing but the current version tag of the client and is updated every time a patch is applied.

This helps us, because knowing what the current version tag is will give us the format that the other versions are likely to be in on the patch server. Official EyaSoft servers use a format consisting of a four letter publisher / locale tag, followed by a date string, and then two additional digits that are typically 00, but can be incremented to allow more than one patch to be issued on the same date when needed. For example, the official USA server used USMC as its version tag, and and PlayPark used MYLC for their Southeast Asia server. This, combined with the date and differentiation digits gives a version format of XXXXYYMMDD00 or as an example from a USA client, USMC10123101, indicating a tag of USMC, date of 2010-12-31, and differentiation digit of 01.

The majority of private servers follow this official layout, despite it technically not being required, and either reuse the tag of whatever official server they based their client on originally, or make up their own, typically based on their servers name, for example, Arch LUNA unsurprisingly used ARCH as their tag. Some private servers however, use a simpler layout, without any date code at all, with the format of XXXX00000000 instead, meaning a tag, followed by numbers, which are incremented each patch. This means the first version might be MEOW00000001 and the second version would be MEOW00000002, etc. This is easier to wrap your head around at first glance as to what order patches are applied in, and is simpler to deal with from a code standpoint.

Once we have figured out what format our patches are in, whether that is MEOW25122401 or MEOW00000027, we now have a valid pattern to attempt to bulk download. Every server using the official patchers uses ZIP file based patches, which means we can now bulk download MEOW000000[00:27].zip (indicating 00 to 27) or MEOW[24:25][01:12][01:31][00:01].zip (indicating 2024-01-01 to 2025-12-31), depending on the patch tags format. Those selectors are in the format used by the download manager I use for bulk downloading, and whatever tool you choose to make use of might require a different format.

Now that all the patches have been downloaded, I give them a quick virus / malware scan, and archive them away alongside the clients installer, along with a text file detailing the website URL, patch URL and tag format, and any precautions necessary when dealing with the files. For example, this might mean a warning about some of the patches having (likely) false positive virus scan results, typically due to private server developers trying to use various EXE packing tools as an obfuscation measure. Sadly those same tools are an almost guaranteed virus scan flag, due to their now widespread use to obfuscate malware payloads. Luckily, their use in private servers has been declining in recent years, as people realize the obfuscation isn’t worth all your users getting the client eaten by their virus scanners on a regular basis.

In days past, I also used to scrape through each servers websites for unique image assets, in particular any official EyaSoft assets that they may have obtained somehow and made use of, as sadly much of the original marketing artwork for LUNA has been lost to time and evaded being archived anywhere. Sadly, wide spread usage of AI image generation by private servers means all of their websites are full of what looks like real artwork in the style of the original EyaSoft artists, but is really just AI generated garbage. This has made archival of image assets from any server released after AI image generation became widely available, to be of very suspect value, at best.

The end result of all this is a client, and if you’re lucky its entire change history, archived away for all eternity, saved from disappearing into the void. At least until the hard drive they are on fails. Hope you made backups…

In the future I will discuss a tool I have been working on, specifically for handling these archived clients, to make working with them more reasonable. Because at current, we have just over 400GiB of clients and patches saved, and if you wanted to try and find a particular iteration of any given file, it could take days or weeks of sifting through clients and patches. However, despite each client weighing in at anywhere from 700MiB to 4GiB, depending on the compression used in their installers, most clients contain relatively few unique files. When comparing any two given LUNA Plus clients, with their PAK files extracted to enable comparing the individual files within, you can expect to see anywhere from 70%-90% identical files

That is because every single client tends to consist of the following things: All of EyaSoft’s original assets, models, textures, scripts, etc. Followed by whatever few dozen files the private server has tweaked or added in for whatever cash grab “features” they have added or ripped off from another server. This makes LUNA clients a prime candidate for being stored in some sort of deduplicated format. And this is what I have been working on as of late, a tool for storing entire clients and their patch sets in a deduplicated, heavily compressed state, while keeping them organized and allowing for any given client to be extracted in exactly the state it was in when stored, optionally with some or all of its patches already applied to it. This is still in its early stages, so stay tuned for a future post if that is something you’re interested in.