Introduction to Server Side Emulation

!"#$ &'("$)(* +),)-.)/ 012 0345

Introduction to Server-side Emulation Welcome to the Introduction to Server-side Emulation (SSE). This paper is intended to be used as a guide to starting an emulator project. If you’re having trouble figuring out where to begin - this guide is for you! Prerequisites Developing a server-side emulator is a difficult task and not for people without programming knowledge. It is recommended that you’re proficient with several different programming languages such as C++, C#, Java, Python, MySQL, etc. It is essential to have an understanding of hexadecimal, binary and different kinds of encryption. If you have difficulty in understanding the topics mentioned above, it is recommended that you master those skills before you continue. History of Server-side Emulation One of the earliest MMORPGs, Ultima Online  (UO),  (UO), did not initially have language in its terms of service that prohibited gameplay on emulators. As a result, an active emulation community developed around UO. In contrast, other game operators have been more effective in addressing the emulator issue. In 2005, Sony Online Entertainment sent a cease-and-desist letter to the hosting company of Winter’s Roar , one of the more popular emulators of its EverQuest  game,  game, which had “allowed players to play for free as long as they owned the original EverQuest client” program. The hosting company, rather than face the threatened legal action, chose to shut down their server. History of Reverse Engineering Blizzard Entertainment faced a situation in which outside programmers had reverse engineered software used with its StarCraft , Warcraft , and Diablo  games  games (predecessors to its World of Warcraft  MMORPG).  MMORPG). In 1997, Blizzard launched “Battle.net,” a 24-hour online-gaming service for purchasers of its video games. Unfortunately, Battle.net suffered from several programming flaws. As a result, a group of nonprofit volunteer game hobbyist, programmers, and other individuals formed a group called the “bnetd project,” the purpose of which was to emulate the Battle.net service and create an improved game based thereon. The bnetd project emulator mirrored all of the features of Battle.net that were visible to users and was made available to the public for free. In order to be a functional game alternative, bnetd had to be compatible with Blizzard’s games. Accordingly, the group reversed engineered Blizzard’s software. Blizzard sued to stop the bnetd project. In Davidson & Associates v. Jung , the Eighth Circuit Court of Appeals upheld a grant of summary judgement in favor of Blizzard on a

!"#$ &'("$)(* +),)-.)/ 012 0345

variety of grounds, including defendants’ violations of Blizzard’s EULA prohibition on reverse engineering and of the anti-circumvention and anti-trafficking provisions of the DMCA. As a result, the parties entered a consent decree whereby Blizzard was assigned the bnetd.org domain name, the website host for the project. Nevertheless, distribution of the code and creation of derivative projects based on the work done in the bnetd project continue to this day. Legalities Upon the closure of a game, the Terms of Service or Terms of Use and End User License Agreement (EULA) are no longer valid. If you never accepted the terms and/or the agreement, then it is not legally binding. However, the Digital Millennium Copyright Act (DMCA) still applies. Where do I begin? Before you begin to develop a server-side emulator, you have to make sure you have the correct tools. There are many useful free applications that are available for download online. I highly recommend that you download Process Monitor and Process Explorer. There are also many other tools that are useful on the Windows Sysinternals website, so browse through them. You will need to disassemble the game client into machine code to crack the encryption and packets. IDA Pro and x64dbg are considered to be the best applications for disassembling the client and machine-level debugging. There are more applications that I’ve suggested to download on the references page. How do I get the community involved? The community is your single largest asset. It will make you or it will break you. Do not expend on community management. You will need to pay attention to all members of the community, even the ones that can’t have enough. Emulator development is a massive commitment of time and resources. I can’t think of a successful emulation project that doesn't measure its existence in years. When you’re actively developing a game emulator, you're in it for the long haul. If nobody uses your game emulator, then there’s no point in continuing to develop it. Most of the time, the community wants to help you in anyway it can. It is in your best interest to use this to your advantage. You should release your packet sniffer to the community and provide them with a way to work with you to crack the packet structures. This helps you out in a big way and it gets the community involved. It also keeps people within the community interested and motivated. Order of operations Most massively multiplayer online games (MMOG) use a series of applications that give the appearance that the game is one single game. The order generally consists of the patcher, the login application and the game client. The one you're going to be most interested in is the game client. Unless you’re going to emulate the patch server and the

!"#$ &'("$)(* +),)-.)/ 012 0345

login server as well (you may be able to write custom protocols for these), it would be great to figure out how to force the game client to start up on its own. Also, you can force it to connect to a server of your choice. This is good if you decide to write a proxy sniffer for your packet sniffer. Creating a packet sniffer The very first thing you should do after you have all the tools you need is to write a packet sniffer. Many people will try to cheat and use something like Wireshark or Microsoft Message Analyzer. I highly recommend you avoid this temptation and write your own. The reason you should write your own packet sniffer is because most games use encrypted socket communications. At some point, you’re going to crack the encryption algorithm and put it into your packet sniffer, so that you understand what directions the client and server are giving to each other. Here are some different methods in writing a packet sniffer: •

•

•

Wedge Method: Tricking the client to connect to a proxy server, which forwards all the data received from the client to the server and vice versa. As the data is transferred, it is copied into a log file. Hooking Method: Loading a dynamic link library (DLL) into the client address space and hooking the Winsock API (specifically recv(), send(), sendto() and recvfrom() functions.) WinPcap Method: This is a kernel mode driver for capturing packets over a network adapter. However, this method may not work for you.

All of the methods mentioned above will accomplish the same goal, so choose whichever method that you’re most comfortable. It is in your best interest to put a lot of time into writing a quality packet sniffer. Cracking packets Packet sniffers capture packets in blocks of binary data. They are usually written to a file as hexadecimal with a header that states the source, destination, and the size in bytes. Packet cracking is taking one of these generic chunks of binary and trying to make sense out of it. This is a very long and tedious process that most people dislike. Once you get good at cracking packets, you can solicit members of the community to help you. Maybe provide them a way to directly put new packet structures into it via scripting or similar. Here is an example of a hex dump: Protocol: TCP | Direction: Server to Client | Size: 8 bytes 0x00 0x06 0x00 0x0a 0x00 0x00 0x00 0x0b ........

!"#$ &'("$)(* +),)-.)/ 012 0345

Hex dumps are usually formatted as individual bytes. If you do not understand hexadecimal and/or how to work with binary and binary operators, you should take a look at the links listed on the references page. How do we determine what the line of binary is? Every packet starts with a packet header. Most packet headers tend to contain standard information such as the packet ID and the size of the payload. Packet ID and size are usually formatted in bytes or 2byte shorts. The first byte or set of bytes is the packet ID or its size. The rest of the header will contain the sequence, checksums, etc. In the example provided, the first set of bytes is the packet size. The entire length of binary is the same as the first set of bytes (minus the size of the length value, which is 2). The packet length value is a 2byte short because there’s a leading 0 before we get to the actual number. Here is another example of a hex dump: 0x00 + 0x06 = 0x0006 | 6 decimals Keep in mind that the game can change the byte ordering of its packets to prevent unauthorized usage. If the above example used a different order of bytes, it could look something like: Protocol: TCP | Direction: Server to Client | Size: 8 bytes 0x06 0x00 0x0a 0x00 0x0b 0x00 0x00 0x00 ........ A game can only do byte ordering on certain bytes. Always pay attention to leading and trailing 0s. It will give you an idea of how the game is ordering bytes. Look at the next 6 bytes: 0x00 0x0a 0x00 0x00 0x00 0x0b Are those six individual bytes? Maybe they're three 2-byte shorts? What about one 4byte integer and one 2-byte short. It could even be a single 8-byte integer or an 8-byte double. You have no idea by just looking at it. Packet cracking is all about changing something in the game and seeing how it affects a packet. There's a lot of guess work. If pattern recognition is something that comes easily to you, then packet cracking will be a breeze. If you see that there's a packet that gets sent every time you move your character, then that is the movement packet. Some of the things that are contained in a movement packet are the player’s x, y and z coordinates and heading. There's a high probability that the movement packet are 4-byte values and are integers or floats. Packet cracking can be done using a disassembler or debugger. If you can find where the packet handlers are in the game binary, then this is a superior approach. Reading

!"#$ &'("$)(* +),)-.)/ 012 0345

actual packet structures in assembly consumes far less time than the trial and error of trying to make sense out of raw binary. Keep in mind that this method may tell you the format of packet, but not what each value is used for. Some things to keep in mind when you're first starting out are: • • • •

• • •

Most packets have a header that contains a bare minimum of size and ID. Packet headers can include sequence for guaranteeing packets arrive in order, session IDs, and checksums. Sometimes checksums are appended to the end of a packet. If you see a string in a packet, check if its null terminated. If not terminated, there should be a value in the packet that contains the string length. There could be a length value even if its null terminated. If you see a string where each character has a leading and trailing 0 that means that it’s a Unicode string. Test all 4 byte values to see if they're integers or floats. The value of one will look like it makes more sense than the other. The same applies to 8-byte values. If you see a byte that constantly changes when you change something in-game, but the value makes no sense, it might be a bit field. Bit fields are commonly associated with flags for player appearance, race and many more.

It's easy to get frustrated, bored, and burnt out with packet cracking. I can’t stress enough the importance of soliciting the help of your community. Packet structures generally don't change that much, so once you crack them, you shouldn’t have to do it again. Once again, look on the reference page for information on packet cracking. What kind of encryption does the game use? Your sniffing sessions have generated hex dumps that don’t contain any string literals such as the player’s name. This means the data is encrypted. In fact, most modern MMOGs use encryption, so it’s valid to assume that encryption is used in some form. Encryption has multiple volumes of information written on it. I could spend the entire rest of this paper talking about it and not even scratch the surface. To sum it up really quick, here's how encryption could work with a game. The first one or two packets may not be encrypted because they are key transfer packets. This is only with the assumption that the game doesn't use a private key symmetric algorithm with the key hard-coded in the client binary. If that's the case, then all of it will look like junk straight from the beginning. How do you figure out if that's the case? It is specific to the game you’re trying to emulate, so all I can say is good luck. Here are some encryption schemes I've seen in MMOGs: •

Public-key encryption (also known as, asymmetric encryption) such as SSL or

!"#$ &'("$)(* +),)-.)/ 012 0345

•

•

• •

•

RSA using the diffie-hellman key exchange. A SSL Main-in-the-middle proxy can be used to intercept traffic that is secured over SSL. Hybrid algorithm where public key encryption is used to encrypt a private symmetric key that is then used after it has been received. The reason for this is because symmetric algorithms are faster than asymmetric algorithms, but are not as secure. An example would be a private RC4 key encrypted by RSA. Private-key encryption (also known as, symmetric encryption) such as blowfish and RC4. These are generally much faster though less secure than asymmetric algorithms like RSA. If you’re skilled in reverse engineering and the game doesn’t use rotating keys, you should be able to pull the symmetric key(s) out of the game binary. XOR is the easy to crack with the repeated sequences method, so hope that the game uses this encryption scheme. Sometimes packets will contain hashes to make sure a packet hasn’t been tampered with during transmission. Common algorithms for this are CRC32, MD5, and SHA1. Any combination of the algorithms that were mentioned previously.

There are many ways to crack encryption, but I suggest that you disassemble the client. This is where IDA Pro or similar comes in. Encryption is the single largest thing in your way to beginning to develop an emulator. If you can crack the encryption, you're on the right track. Coding the emulator The number one biggest mistake beginners make is features, features, and more features. The community is going to be screaming for new features and you shouldn’t oblige them. It is a very bad idea. It is important that you go at your own pace and develop a solid platform to build your emulator on. Multi-threaded programming has a bit of a steeper learning curve, but it's definitely worth it. Asynchronous socket IO, using the system thread pool (on Windows), makes for a very scalable and solid network layer. Don't go crazy with synchronizing everything. You only need to synchronize access to objects that’ll be concurrently read from and written to. Read about semaphores, critical sections, and mutexes on the references page. They all have subtle differences and it's good to know what is good for certain situations. Thoroughly test everything at every step. In the beginning, you're all going to be pumped by the amount of progress you're making. You're going to want to see what you can do. There's also pressure to prove that you have something to show. Do not sacrifice the integrity of your software by speeding things up. A bug that you've spent a week trying to nail down to no avail is not fun at all. Bugs are the kinds of things that'll expedite burnout within the project. What programming language(s) should I use?

!"#$ &'("$)(* +),)-.)/ 012 0345

All programming languages have strengths and weaknesses. Things you have to look at when choosing a language are:  • • •

The skill level of your team with various languages. Target platform Power versus productivity

A language like C or C++ is great if you want maximum control over your server. It works on multiple platforms and is extremely powerful. However, it also has a high learning curve and has lower productivity than other languages. Java is an excellent choice if you're extremely concerned about targeting multiple platforms. However, Java is slower than other languages and suffers from a horrible socket library (from an asynchronous IO standpoint). Java will provide you with higher productivity than something like C or C++ and many people are familiar with it. C# is good if you want high productivity and your target platform is primarily Windows. It can be used on multiple platforms due to projects like Mono, but it runs best on Windows. It also has an excellent socket library. C#, through unsafe code and PInvoke, allows many of the lower level things available to C or C++, while writing safe code is similar to Java. Ultimately, C# is the middle ground between C or C++ and Java with a sacrifice to platform interoperability. Should the emulator be open or closed source? Most emulators tend to be open source though some are not. Unless you're writing the emulator in C or C++, it's pointless to make your emulator closed source. Anyone that has enough skills to write an emulator from scratch is most likely going to have enough skill to disassemble C#'s IL or Java's byte code and reverse engineer a server. Here are the pros and cons in having the emulator open source or closed source:  Open Source: Pros: • • • • •

Allows people to help you by submitting bug fixes and spotting errors in the code. People can easily make small changes to the source that'll help them to customize the emulator to their needs. Many people don't trust closed source projects and sometimes because the emulator is open source, it can generate interest. Free repository hosting: GitHub The source is available for everybody to critique and as such constructive

!"#$ &'("$)(* +),)-.)/ 012 0345

criticism can be an invaluable tool. Cons: • •

It's easier for people to steal the code and call it their own or use it for malicious intentions. People can more easily spot and exploit bugs in the code.

Closed Source: Pros: •

• •

People can’t steal and rip off your code. If you produce a good product, the quality of your product will stand for itself. Most people automatically attach a negative stigma to an emulator that has been ripped off from a well written piece of software. People with malicious intentions will have a harder time finding exploits. People with malicious intentions can’t use the code as a basis for writing applications that allow players to hack and cheat on the live servers.

Cons: • • •

You can’t leverage the facilities provided by the open source community. People are more likely to attach an unfriendly stigma to you and your emulator because you won’t release the source. You may have a harder time attracting talented developers to help you.

It's good to open source the emulator, but close source some things that you consider sensitive such as the packet sniffer, the encryption algorithm, etc. Just because the emulator is open source, doesn't mean all of its associated tools and every single part of it has to be open source as well. If there are no security concerns, then it’s great to be open source (as much as you can.) How should data be stored? The very first rule of data storage is that XML is a poor choice. The only thing it's good for is configuration files, web page generation, and possibly as an augment to your scripting language. SQL is definitely the way to go. Both MySQL and Microsoft SQL Server 2017 are freely available and are excellent solutions to data storage for emulators. Another thing that SQL works well with is clustering. To date, no emulators that I’ve seen support clustering, but I see that as the next evolution in SSE. The second rule of data storage is that you don't need to store everything in a database. In fact, you want to store as little as possible in the database. This is because your

!"#$ &'("$)(* +),)-.)/ 012 0345

database could grow to be very large, very quickly with thousands of items, player characters, accounts, and NPCs. The more things you store in the database, the more things there are that may require a schema change down the road. Schema changes can be very problematic when there are serious differences between one version and the next version. A good rule of thumb is to store only account information, player character information, guilds, and anything else that is required to maintain the persistent state of the world in the database. This information is very important and must be updated in real-time. Your entire world can be nuked and people will be sad, but will probably continue playing once you rebuild it. If they lose their characters, which translates into hours of work, they are probably going to hate you and quit. It is absolutely essential that character data is always as secure as possible. Account information, character data, and guild data needs to be shared amongst servers in a clustering (or even multi-function server) setup. This makes them excellent candidates for being stored in a database. One thing to keep in mind is the player's position doesn't need to be updated in the database every time it moves. If you do set it up that way, it's going to be a serious performance bottleneck. Things like statistics and character states should be saved immediately. Things like current health, mana, and positions are still important, but it's not the end of the world if you login again and you're in a totally different area from when you logged out. Periodic saves of player position, health, mana, etc. are all that's required. I would like to touch on the topic of password storage really quick. Though most server administrators are honest, it’s a good idea to not store passwords in a database as plain text. I personally like to store passwords as SHA1 hashes or as raw binaries encrypted with DES. Many people use the same passwords for every service without any consideration for how the passwords are stored. There’s no reason to tempt an otherwise honest administrator. This also better protects your players in the event your database is compromised by a hacker. World Data World data saves generally should be at X interval (or at startup and shutdown or both) and should only contain static data. Static data can be defined as anything that needs to be persistent between server startups. Vendors, quest dependent NPCs, quest dependent items, spawn points, etc. are all examples of static data. The majority of NPCs and items are going to be considered dynamic. This means that they exist purely to be killed or interacted within a generic manner. For dynamic NPCs, try to store spawn points, which you can plug into scripts to control the types of creatures spawned and possibly limit where they can travel. Items are slightly more complicated. Items on the ground should be dynamic. Once a player picks it up and it becomes a part of their inventory, the item should become static and stored in the database. Player inventory is important information.

!"#$ &'("$)(* +),)-.)/ 012 0345

Your world file should be a binary flat file format that is sequentially read from or written to. On world startup, your server will just read the entire world into memory. Read and write access to memory is considerably faster than it is to a database file or a file on disk. Since static data generally doesn't change much between world saves, if your server crashes, you will more than likely only lose a minimal amount of non-critical information. On world saves, you should set it up to take everything that's in memory and sequentially write it to disk. The only information about an object that should be stored is anything that's required to maintain its persistent state. This way only the minimum amount of storage will be used. Anything that defines behavior should be put into scripts. What scripting language should I use and how should I use it? Scripting is one of the most important subsystems in an emulator. A quality scripting solution will be what sets you apart from everybody else or what leaves a bad taste in an administrator’s mouth after trying out the software. There are so many different scripting languages out there, you should put a lot of time in seeing which one will work best for you. Download them and try them out. Write little examples of what you think you may need your scripting solution to do and run them through it. You can't spend enough time on choosing the right scripting language. As I have previously stated, anything that defines behavior in relation to logic or command handling should be put into scripts. You should also put NPC and item definitions in scripts. For example, you could write a generic dog script. From that script, an administrator could see how to create a script for a hell hound. The scripts would contain information about how the entity will look in the game and how it will behave towards other entities. Anything that can interact with the environment is an entity. Maybe hell hounds don’t attack humans, but they attack elves. If a hell hound is hit by a certain type of weapon, will it take more or less damage or perform an action? These are all things that define behavior and should be put into your scripts. You may want to expose certain aspects of core functionality, such as web page generation and various server statistics to your scripts as well. The following is an example of a scripting solution using a pretend scripting language and XML. Notice that XML describes attributes (data and interface) while scripts only define behavior. 1. 2. 3. 4. 5. 6. 7. 8.

Brown

!"#$ &'("$)(* +),)-.)/ 012 0345

9. 10. dog.script 11. dog.script 12. dog.script 13. 14. 15. 16. 17. Red 18. 19. dog.script 20. hellhound.script 21. dog.script 22. 23. 24. 25. 26. 27. 28. 29. 100 30. 31. 32. 33. 34. 35. The following is an example of pretend dog script that is similar in syntax to JavaScript. 1. function OnCreate(var dog) 2.  { 3. } 4. function OnDie(var dog, var killer) 5.  { 6. //don't do anything special 7. //don't do anything special 8. 9. } 10. function OnSeeEntity(var dog, var entity) 11. { 12. if(entity.IsPlayer) 13.  { 14. if(entity != dog.Owner) 15.  {

!"#$ &'("$)(* +),)-.)/ 012 0345

16. 17. } } 18. }

dog.Attack(entity);

The following is an example of pretend hell hound script that is also similar in syntax to JavaScript. 1. 2. 3. 4. 5. 6.

function OnDie(var hound, var killer)  { //hell hounds do 50 fire damage to their killers //when they die killer.Damage(DamageType.Fire, 50); }

Programming languages are not scripting languages. Using languages such as C# for scripting purposes is a poor decision. Most programming languages are far more powerful and have steeper learning curves than anything a well-designed scripting solution needs. Another problem is most programming languages have to be compiled into some form of module. Scripting languages allow you to dynamically recompile or simply execute a single file during runtime, which is infinitely more helpful in an environment where application downtime is a big issue. For example, while using C# and DOL, please consider the following: C# like Java uses a garbage collector to manage its memory. In the case of DOL, when the server starts up, it compiles all of the C# script files into a single script assembly. As the server runs the scripts, it inevitably allocates objects and hands them off to the server. These objects belong to the script assembly. If you need to recompile one script, you have to recompile the whole thing. Since there are still references to objects allocated in the original script assembly running rampant, the new assembly has to be loaded alongside it. Furthermore, you have no idea when those objects will be deallocated by the game compiler. Maybe you can try to beat the system by loading the script assembly in a separate domain and unloading the domain before recompiling, but the most likely outcome of this action is the death of your application. All of the script allocated objects become invalid references when the game compiler is forced to collect them. Inevitably something will make a call to one of those references and throw a NullReferenceException. The only other alternative is to keep track of every single object that’s allocated, which is largely impractical. Thus you must shutdown and restart DOL every time you need to recompile a script. As you can see, it’ll save you a lot of time and grief to do scripting right the first time around. Team Management Team management is one of the hardest and yet most essential parts of emulator development. Your team members are going to be from all different nationalities and

!"#$ &'("$)(* +),)-.)/ 012 0345

you're most likely only going to know each other over the internet. Someone who's good at coordinating all these diverse backgrounds into focusing on one thing is worth their weight. However, if you’re not a programmer and you’re the project lead for an emulator keep in mind that it is impossible for you to effectively manage programmers. If your project leader is someone with tremendous management and people skills, but is not a programmer, I recommend creating a lead programmer who works in tandem with the project leader. If your project lead is a programmer with less than desirable management and people skills, then it may be desirable to bring someone who does have those skills as an equal or assistant lead. Everyone is going to want to join your team to get in on the fun. One of the biggest mistakes startup projects make is: 1. Too many people are on the developer team. 2. Too many people that can’t program. A good startup size is 3-4 programmers and 1-2 people that can’t program at the very most. Make sure that there are people on the developer team that have alternate skills such as database programming and/or web development. Unskilled people on the developer team are just going to annoy your skilled people and too many people in general are going to cause confusion. Releases at defined intervals with set feature lists go a long way towards staying organized and focused. Having a public developer meeting after every release is a good way to not only keep the community involved, but to make sure all of your developers are on the same page. If you let your developers just work on whatever they want without any clear direction, you're going to end up with a lot of unnecessary code with many problems later on. • •

• • • • •

Don't bloat your developer team with too many people. If someone doesn't have the skill level to write an emulator, don't let them join. Instead, you can answer their questions and maybe direct their energy in a different direction, such as packet cracking. It's always a good idea to be polite and helpful, it contributes to a happy community. If a person that can’t program is your project leader, you should create a lead programmer that works closely with the project leader. Have clearly defined goals and tasks. Do not be a slave driver, people have lives outside the project. The real world comes first. Keep people informed of the big picture. Use a compiler that documents all of your code. If the compiler you’re using doesn’t support this feature, use Doxygen or similar.

Community Management

!"#$ &'("$)(* +),)-.)/ 012 0345

Managing the community requires some different skills than managing your team. A part of community management is advertising and marketing. If nobody knows your emulator exists, then you’re not going to have a community to manage. Once you've got a couple of releases behind your belt and you've acquired a sizeable community, you should provide ways (other than forums) for members of the community to communicate amongst themselves. A chat room is an excellent way to do this. IRC chat provides you with a way to see who the most active members of your community are. Not only is there IRC chat, but much newer ways of communication that are specific to the gaming community such as Slack or Discord. Chat rooms keep members of the community interested and alleviates the burden on yourself. It’s a good practice to recruit people in the community as technical or support team members for the project. A lot of the time, community members will have extensive knowledge on the usage end of the software. They are more than happy to pass this knowledge onto the rest of the world. Another way to utilize this resource is by having them write documentation for the software. One of the most helpful things someone can do for new administrators is provide quality documentation on how to get a server up and running and address common problems. Regular updates on the progress of the emulator is good for keeping people informed and interested. This seems like a no-brainer but it's something that overtime falls by the wayside. Providing ways for people to submit feature requests and see the progress being made on them lets them know that their efforts count. The same thing can be said for a bug tracking system. Keep the developer team involved with certain aspects of the community, such as technical help, bug tracking and feature requests. If a core developer tells an administrator that a bug that was reported is being fixed, it'll let the administrator know that the core developer takes him seriously. If the developer team becomes too distant from the community, the developers can start to run into problems. Many things that seem intuitive to your developer team may not be for the average user. Keeping your developer team involved with the community will make them more aware of what type of people are using the software. To sum up community management: •

•

• •

Advertise your project. Try to be as professional as possible. Just because your software is in a gray area of the law doesn't mean that it can't be of professional quality. Recruit people that are active in your community to become technical help personnel. This should be something outside of the core developer team but it should work closely with it. Get the developer team involved with certain aspects of the community. This is beneficial for both parties. Use a private developer chat room on an IRC or similar in order to establish communication between team members.

!"#$ &'("$)(* +),)-.)/ 012 0345

• • • •

•

Keep people updated of your progress. Let people know when their feature requests and bug reports are being worked on. If you reject a feature request, let them know why. Maybe they're missing something or maybe you're missing something. Don't expend on documentation. It is extremely helpful to novice users. Since programmers typically hate writing documentation, utilize the knowledgeable members of the community to write the document. Search for organizational tools on the internet. A good bug tracker is MantisBT.

Proliferation of Information According to Dictionary.com, the definition of reverse engineering is “The process of analyzing an existing system to identify its components and their interrelationships and create representations of the system in another form or at a higher level of abstraction. Reverse engineering is usually undertaken in order to redesign the system for better maintainability or to produce a copy of a system without access to the design from which it was originally produced.” In the traditional sense of the word, if you’re a reverse engineer, then you’re also a hacker. The definition of hacker is “A person, as an artist or writer, who exploits, for money, his or her creative ability or training in the production of dull, unimaginative, and trite work; one who produces banal and mediocre work in the hope of gaining commercial success in the arts.” Some things that apply to the hacker community, also apply to the emulation community. Sharing information is one of those things. It takes many people hours of hours to fully crack and document the inner workings of something as complicated as an MMO. Nothing is more hurtful to an emulation community than trying to hoard information to boost your own ego. Here are some examples as to why it’s actually beneficial when you share information: 1st Scenario: Soon after packet information for a game became public knowledge, versions of the game started to pop up all over the internet. Was this good? As long as your version of the game is the one that ends up being the most successful, then yes. Competition is good, it helps push people to produce the most innovative and quality emulators. In the end, only the best emulator will claim victorious. The server administrators and community will benefit from this the most. 2nd Scenario: A developer team decided to make their game emulator closed source in fear of prosecution. Development of the game emulator progressed at a very slow pace. They were unable to crack packets quickly without the community’s help. The emulator was the only emulator available for the game because the source code wasn’t shared. They wanted to have a monopoly on the game’s emulator community. If someone tried

!"#$ &'("$)(* +),)-.)/ 012 0345

to accuse them of such a thing, they would deny it without thinking about it. Sometime later, the game emulator ceased development. 3rd Scenario: A developer team decided to go a different route and made their game emulator open source. The game’s community forums was dedicated to packet information. They made a packet sniffer publicly available for free. It took a year to crack the whole game and the game was a success. The point that I’m trying to make is that by sharing your information, you’re helping yourself and everybody else. History has shown that most emulators that are open source have done better than those that are closed source. If you make the emulator available to everyone from the beginning and you get shut down by the copyright holder, you can begin again. “You may stop this individual, but you can't stop us all... after all, we're all alike.” ~ A quote from \/\The Conscience of a Hacker/\/ written by +++The Mentor+++ Conclusion I hope you find this guide helpful. If you find any errors or if you would like to add onto this paper, please contact me.

!"#$ &'("$)(* +),)-.)/ 012 0345

References Learn about hexadecimal, binary and encryption: Lean about hexadecimal - https://learn.sparkfun.com/tutorials/hexadecimal Learn about binary - https://learn.sparkfun.com/tutorials/binary Learn the difference between mutexes and semaphores http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore Learn about semaphores - http://pages.cs.wisc.edu/~remzi/OSTEP/threads-sema.pdf Book on cryptography - https://www.cs.umd.edu/~waa/414-F11/IntroToCrypto.pdf Learn about general encryption - https://blog.vrypan.net/2013/08/28/public-keycryptography-for-non-geeks/ | https://en.wikipedia.org/wiki/Encryption Learn about algorithms and cryptography https://www.khanacademy.org/computing/computer-science Learn about RC4 Encryption: https://www.math.washington.edu/~nichifor/310_2008_Spring/Pres_RC4%20Encryption .pdf Lean about the Blowfish algorithm: http://www.splashdata.com/splashid/blowfish.htm Learn about the Symmetric-key algorithm http://www.iusmentis.com/technology/encryption/crashcourse/secretkeycrypto/  Learn about the Asymmetric-key algorithm http://www.cs.cornell.edu/courses/cs5430/2013sp/TL04.asymmetric.html Watch a video on encryption - http://mashable.com/2015/10/15/how-encryptionworks/#T832nko7tGqV Watch a video on the Diffie-Hellman key exchange https://www.youtube.com/watch?v=YEBfamv-_do Watch a video on Cyclic redundancy check calculation https://www.youtube.com/watch?v=0apqZ4jsGmI Watch a video on MD5, SHA-1 and SHA-2 - https://www.youtube.com/watch?v=YV-7NIdZoM Watch a video on XOR cipher - https://www.youtube.com/watch?v=buiFZG-Fq_k

!"#$ &'("$)(* +),)-.)/ 012 0345

Playlist on cryptography - https://www.youtube.com/watch?v=ATJxUYEACg&list=PLAwxTw4SYaPnCeih6BPvJ5GdqqThGcWlX Learn about reverse engineering: Reverse Engineering in General - https://www.lumendatabase.org/topics/15 Reverse Engineering with IDA Pro - https://www.youtube.com/watch?v=fgMl0Uqiey8 X86 Opcode and Instruction Reference - http://ref.x86asm.net/index.html Reverse Engineering a Game - https://www.youtube.com/watch?v=DumXgoFrMdU | https://media.ccc.de/v/32c3-7493-how_hackers_grind_an_mmorpg_by_taking_it_apart | https://www.erlang-factory.com/upload/presentations/596/reverse-engineering_LC.pdf HOWTO-Reverse Engineering - http://wiki.scummvm.org/index.php/HOWTOReverse_Engineering “Reverse Engineering for Beginners” book - https://beginners.re/RE4B-EN-real.pdf | https://github.com/DennisYurichev/RE-for-beginners Intel 64 and IA-32 Architectures Software Developer’s Manual - https://wwwssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architecturessoftware-developer-manual-325462.pdf Reverse Engineering Dead Protocols - https://media.ccc.de/v/31c3_-_5956_-_en__saal_2_-_201412281400_-_cyber_necromancy_-_joseph_tartaro__matthew_halchyshak Reverse Engineering and Program Understanding http://ptgmedia.pearsoncmg.com/images/0201786958/samplechapter/hoglundch03.pdf Reverse Engineering tutorial - http://www.rohitab.com/discuss/topic/35537-cc-reverseengineering-tutorial-for-newbies/ Presentation of MMO Networking - https://www.youtube.com/watch?v=Hjes3Gkw94c Reversing C++ - https://www.blackhat.com/presentations/bh-dc07/Sabanal_Yason/Paper/bh-dc-07-Sabanal_Yason-WP.pdf Reverse Engineering a (M)MORPG https://www.slideshare.net/AntoninBeaujeant/reverse-engineering-a-mmorpg Reversing the League of Legends Client - https://nickcano.com/reversing-league-oflegends-client/  Hooking LuaJIT - https://nickcano.com/hooking-luajit/ 

!"#$ &'("$)(* +),)-.)/ 012 0345

Exploiting Game Engines for Fun & Profit http://revuln.com/files/Ferrante_Auriemma_Exploiting_Game_Engines.pdf Game Engines: A 0-Day’s Tale http://revuln.com/files/ReVuln_Game_Engines_0days_tale.pdf Reverse Engineering Visual Novels 101 - https://hackernoon.com/reverse-engineeringvisual-novels-101-d0bc3bf7ab8 | https://hackernoon.com/reverse-engineering-visualnovels-101-part-2-9258f547262a Researcher Cracks Elder Scrolls Online, Dark Age of Camelot, and Wildstar https://www.youtube.com/watch?v=iYTCBPUn98c Start programming today: Learn how to program in C++ - http://www.learncpp.com/  C++ Tutorials - http://www.cprogramming.com/tutorial/c++-tutorial.html | http://www.cplusplus.com/doc/tutorial/  C# Tutorials - http://www.learncs.org/  | http://www.tutorialspoint.com/csharp/ Learn about Network Programming https://www.scribd.com/document/360223249/bgnet-USLetter-pdf Learn Java - https://www.codecademy.com/learn/learn-java Java Tutorials - http://www.learnjavaonline.org/  | https://www.udemy.com/java-tutorial/  Interactive Python tutorial - http://www.learnpython.org/  Learn Python the hard way - http://learnpythonthehardway.org/book/  MySQL Tutorials - http://www.tutorialspoint.com/mysql/  | http://www.w3schools.com/sql/ Get the best software: Browse through the Sysinternals Utilities index - https://docs.microsoft.com/enus/sysinternals/downloads/ Download for Process Monitor - https://docs.microsoft.com/enus/sysinternals/downloads/procmon Download for Process Explorer - https://docs.microsoft.com/enus/sysinternals/downloads/process-explorer Download for Process Hacker - https://wj32.org/processhacker/index.php

!"#$ &'("$)(* +),)-.)/ 012 0345

Download for IDA Pro - https://www.hex-rays.com/products/ida/support/download.shtml Download for x64dbg - https://x64dbg.com/  Download for Hopper - https://www.hopperapp.com/  Download for WinPcap - https://www.winpcap.org/install/default.htm Download for Microsoft Message Analyzer - https://www.microsoft.com/enus/download/details.aspx?id=44226 Download for Wireshark - https://www.wireshark.org/  Download Doxygen - http://www.stack.nl/~dimitri/doxygen/download.html Download MantisBT - https://www.mantisbt.org/download.php Download for Visual Studio - https://www.visualstudio.com/downloads/  Download for Visual Studio Code - https://code.visualstudio.com/  Download for MySQL Server 2017 - https://www.microsoft.com/en-us/sql-server/sqlserver-downloads Download for Atom - https://atom.io/  Download for Discord - https://discordapp.com/  Download for Gitter - https://gitter.im/  Introduce yourself to the game emulator community: EvilZone - https://evilzone.org/index.php SWGEmu - http://www.swgemu.com/forums/forum.php RageZone MMO Development - http://forum.ragezone.com/ OpenRCE - http://www.openrce.org/articles/ OwnedCore - https://www.ownedcore.com/forums/  MPGH - http://www.mpgh.net/forum/index.php The ByteCode Club - https://the.bytecode.club/ Tuts4You RE - https://forum.tuts4you.com/

!"#$ &'("$)(* +),)-.)/ 012 0345

StackExchange RE - http://reverseengineering.stackexchange.com/ Reddit ReverseEngineering - https://www.reddit.com/r/ReverseEngineering/  Reddit REGames - https://www.reddit.com/r/REGames/  Legalities: Coders’ Rights Project Reverse Engineering FAQ https://www.eff.org/issues/coders/reverse-engineering-faq What is a DMCA Takedown? - https://www.dmca.com/FAQ/What-is-a-DMCA-Takedown Digital Millennium Copyright Act of 1998 - http://www.copyright.gov/legislation/dmca.pdf Violating Terms of Service Is Not a Crime https://www.eff.org/deeplinks/2010/07/court-violating-terms-service-not-crime-bypassing

!"#$ &'("$)(* +),)-.)/ 012 0345

Sources Corillian. Introduction to Server Side Emulation  (2006): 1-19. 2 Apr. 2006. Web. 31 Aug. 2016. Dannenberg, Ross A. "Enforcement." Computer Games and Virtual Worlds: A New Frontier in Intellectual Property Law . Chicago, IL: American Bar Association, Section of Intellectual Property Law, 2010. 99-101. Print. Chapman, S. (2017, December 10). The Ultimate Game Hacking Resource. Retrieved December 25, 2017, from https://github.com/dsasmblr/game-hacking/