History of Ragnarok Emulation

From RO Wiki

The History of Ragnarok Emulation is a page that has been waiting to be written for a long time. Original efforts to chart the history of Ragnarok Emulation were done via scripter and web developer Evera of the eAthena project, but the history of emulation began much before that. For much of the history, there can only be small amounts written based entirely off evidence and this is because of various Ragnarok and emulation sites slowly shutting down over the years, and so for this reason, this article is written as a story.

Beginnings[edit | edit source]

How it began[edit | edit source]

In the beginning, there was Ragnarok Online, which was released for the PC in May 2001 with the Beta test. As of the current time of writing, this early history of Ragnarok Online emulation, not much is known about if there were people writing specifically about reverse engineering the Beta Ragnarok Online client in 2001 or early 2002. The earliest discussions around emulating the Ragnarok Online server protocol that we can currently find date back to late 2002 or early 2003 on the EmuServer Of Ragnarok (EOR) BBS, but in fact, there are hacking tools such as trainers, which were released as early as May 2002. This indicates that there were plenty of early software authors who were listening to the communication between the Ragnarok Online desktop client and the Ragnarok Online servers in Japan or Korea.

This process, known as "Packet Sniffing" is one where a programmer listens to traffic for a specific process running on a computer, and is the process that cheaters will have used while logging into the server to figure out which packets were used for various purposes, and the most common used program available for this process was WinSock Packet Editor.

An aside on basic networking[edit | edit source]

As a quick aside, "packets" are segments of data that are sent back and forth between applications which communicate via the internet, and have a reliable structure to them. This is so that when the "client" (in this context the Ragnarok Online game) sends a request with data saying "I hit this monster", the server is expecting this in a specific format, explaining the detail of the action of hitting the monster. A common issue with applications communicating in this way is that, people who want to modify the "client" or reverse engineer it, could attempt to modify the data that was sent back, or send 20 packets saying "I hit 20 monsters" or "I was in Prontera a second ago, now I'm in Morrocc".

In this world of networking, the client (the thing connecting) and the server (the thing being connected to) have a state, and the ideal is that the client state is something the server is expecting. Let's say we're in Prontera, and we move 2 cells up, and we tell the server we were at position X, but now we're moving to position X1, this is something that the developers of AEGIS would have expected. But what happens if instead of saying I moved 2 cells up, I said I moved 20, or 30? Or to a different map? This is where the server basically has to do heavy lifting -- if the client is modified, or a fake client is used in its place (e.g. a bot that emulates the client), then that client could start to do things like say "I just picked up 99 Balmungs" even if that never occurred -- and in this sense, the server program always has to assume -- even if the client is expected to be the official one and the user of the client is a well-behaved user and not cheating -- that the client could be lying, or wrong.

This assumption wasn't quite what the original Ragnarok Online Server had. A lot of the expectations were that the user would behave and not do naughty things with the client or network traffic, and as a result, this was the reason why a large number of hacking tools, trainers, speed hacks, duplication glitches, and so on, proliferated in those early years. These packets being sent back and forth were "sniffed", revealing the protocol (a set of rules governing the exchange or transmission of data between devices) of Ragnarok, and revealing its weaknesses.

Cheating and botting[edit | edit source]

Now we know the background of what a packet sniffer is, it's needless to say that -- because the packets being sent using the Ragnarok protocol were not encrypted (i.e. not sent securely), cheaters quickly found out which packets were the juicy ones that could be exploited and began to create programs (commonly known as trainers) which were able to do various interesting things such as teleport you back to your save point without using an item, attack at an insanely fast rate, impersonate GMs or other players, walk at a very fast speed, or send profane text. These all occurred because the server broke a relatively well-known principle: always validate what the user is sending to you. If you send a packet saying your name is "god-poing", but the name of the character linked to you is called "jimbob" then you probably shouldn't send a response to everyone else in the game saying "god-poing said X" because.. they didn't.

Nevertheless, it's thought the very origins of server emulation and cheating had some overlap. Many of the authors of the cheat programs also published readme files and other information on forums detailing which packets did what, and it's very likely that in the early days of Ragnarok Online development that some of these were reused.

In addition to the cheaters, there were also the early botters like those who wrote bot programs like RagEmu, Chaos-LokiBot, Kyne Bot, ApezBot, ROE and various others likely lost to history. These groups immediately set about making a Ragnarok Online bot client which would pretend to be a regular Ragnarok Online desktop client, but would automate out various tasks, ranging from farming items or experience, to just harassing users or spamming profanity or other users for whatever reason. In trying to get cool stuff without having to put in the work manually, many of the authors of bot programs most likely uncovered the protocol before server reverse engineers as they would have had to know what format the server would send various packets in, and how to respond to those packets.

Either way, because so much of these activities had so much overlap - there were groups developing bots, and cheats, and likely server emulators at the same time, it is a possibility they all independently arrived at the same protocol since it was relatively easy to reproduce, but it is also more likely that there was some sharing between groups, either implicit or explicit in, which likely proliferated the development of each in turn.

Clients aplenty[edit | edit source]

An important prerequisite to the development of server emulators was the reverse engineering of the Ragnarok Online client, and from all hacking tools that we have seen, this happened very quickly. Various authors figured out quite quickly that the early Ragnarok client could be made to bypass Gravity’s own GRF file and read directly from a folder In the same location as the Ragnarok EXE. This was due to the fact that the EXE itself had an option which could be passed, or the EXE could be "hexed" (edited with a hex editor) and made to load from the data folder first -- there were some clients which existed which by default read from the data folder.

Then came deconstruction of the GRF file itself, which is essentially a ZIP file but with extra steps. People competent and understanding of how file formats work, quickly deconstructed the format of the GRF. This was done by going from the assumption that, if all the files for a game are inside a single file, that then, within that file, the binary for other files must also be stored within that file, and there also must be a header, which describes which files are stored where in the file, and at which position. The common source of this information was provided by a person with the name of "The Raven", who detailed the header format for the GRF files.

At the time, even in 2002 before emulators had made an appearance in any major way, there was GrfWiz created by ArtForz and grfextractor written by wdb. These proved to be crucial in being able to extract the contents of GRF files and then either recreate the GRF files, or create data folders which were used to override the contents of the GRF. The most crucial among these was overriding the sclientinfo.xml or clientinfo.xml file, which contained the XML structure which detailed the IP address of the server to connect to, the name of the servers, IDs of GM users, and so on. With these then overridden, this meant that writing a server emulator and being able to test it became possible.

Enter Emulators[edit | edit source]

In the beginning was the packet, and the packet was with Ragnarok, and the packet was Ragnarok. Everything with emulation began with these sniffed packets. It’s likely they came from various different backgrounds - 0001.txt was the source that most emulators based on the 0052.lzh emulator were based on, but it’s likely some of the earlier emulators like ROSE either sniffed their own packets or got them from forums and other sources like from bots or various cheat programs.

At first, the process of reverse engineering would have almost certainly been a slow one of trial and error, building software and then testing it against the existing Ragnarok client to see how the client reacted. When the client then reacted by requesting another packet, then the emulator developers would then need to figure out what that packet contained and where, and then implement code to respond accordingly. In the beginning of the development of the predecessor of 0052.lzh, progress was somewhat back-and-forth, with smaller revisions and changes to previous snippets of C code being passed back and forth until something resembling a working program appeared.