That said, piracy prevention and countermeasures usually focusing on finding out whether or not a user has something (usually an object) which can only be obtained if a copy of the game was purchased, and make that difficult to duplicate. There are tons of ways to do this, each one with advantages as well as flaws. I'll mention a few:

• Early games asked users to input a word from the game manual, which you should only get if you bought a game box. A photocopier or a scanner easily defeats this technique though.

• More recently, media checks are more common. The idea is that you require the game CD to be in the drive for the game to run. To implement this, you can for example access critical data files from the CD without which the game cannot run, or simply check for the existence of a file in the CD. This worked pretty well when CDs were difficult to duplicate, but CD copiers, and more recently drive emulators can be used to easily defeat these technique.

• However, CD copies are not perfect, so many other techniques focus on detecting whether the CD is the original pressed CD, or a copy. To implement this, a game can check for non-standard elements that are inserted on the game disc during press time, but cannot be easily and reliably replicated by a CD burner, on a CD-R. Some common ways to do this are:

  • Creating dummy "ghost" files in the CD during mastering, which are not accessible from the CD filesystem, but do exist, and can be read if you know where to find them. This data is absent on file-by-file disc copies. Copying the entire disc image will copy these files though.

  • Another way is to intentionally insert errors in the disc. CDs contain error correction codes. By inserting errors in the data, which can be transparently corrected by a disc reader, the disc will work normally, but the errors won't be copied to the CD-R. By looking for these intentional errors, a game can consider a CD to be an original pressed copy. RAW disc image copies defeat this though.

  • Inserting twin sectors, with the same address but different data will yield different results when seeking data forward and backward. Checking for the existence of this is possible, and duplicating a CD with these twin sectors is very difficult.

  • Measuring the actual position of the pits in the CD. Once again, duplicating a CD with the pits in the same positions is very difficult to replicate.

  However, many CD emulators, like Daemon Tools, or Alcohol 120% can actually emulate these features. Because of this, many publishers choose to include a CD emulator detection step, and prevent the game from running if an emulator is detected. The implementation of an emulator detector is outside of the scope of this answer though.

• Instead of, or in addition to checking for a physical CD, a game can request the user to input some data, like a product key. Some ways to use product keys are:

  • Checking for mathematical features in the key. However, this doesn't prevent key duplication, and if the checking algorithm is discovered or reverse-engineered, a pirate may be able to create new keys at will which will appear to be legitimate to the game. Software that creates keys at will are called "keygens".

  • Generating a hash based on the user's hardware, send this hash and the product key (usually a combination, called the "installation key") to a server owned by the game company, and based on the hash and serial, create an activation key. Using one-way numeric methods (like modular arithmetic, or some methods with elliptic curves), a game can see if the activation key matches the hash and serial code, and only run if they match. This technique is called "activation".

    With activation, a server may refuse to provide activation keys for multiple hardware hashes with the same serial code. Because of this, even if the serial code, and activation key are copied, the activation key won't match and the game won't run on other computers.

That said, piracy prevention and countermeasures usually focus on finding out whether or not a user has something (usually an object) which can only be obtained if a copy of the game was purchased, and make that difficult to duplicate. There are tons of ways to do this, each one with advantages as well as flaws. I'll mention a few:

• Early games asked users to input a word from the game manual, which you should only get if you bought a game box. A photocopier or a scanner easily defeats this technique though.

• More recently, media checks are more common. The idea is that you require the game CD to be in the drive for the game to run. To implement this, you can for example access critical data files from the CD without which the game cannot run, or simply check for the existence of a file in the CD. This worked pretty well when CDs were difficult to duplicate, but CD copiers, and more recently drive emulators can be used to easily defeat these technique.

• However, CD copies are not perfect, so many other techniques focus on detecting whether the CD is the original pressed CD, or a copy. To implement this, a game can check for non-standard elements that are inserted on the game disc during press time, but cannot be easily and reliably replicated by a CD burner, on a CD-R. Some common ways to do this are:

  • Creating dummy "ghost" files in the CD during mastering, which are not accessible from the CD filesystem, but do exist, and can be read if you know where to find them. This data is absent on file-by-file disc copies. Copying the entire disc image will copy these files though.

  • Another way is to intentionally insert errors in the disc. CDs contain error correction codes. By inserting errors in the data, which can be transparently corrected by a disc reader, the disc will work normally, but the errors won't be copied to the CD-R. By looking for these intentional errors, a game can consider a CD to be an original pressed copy. RAW disc image copies defeat this though.

  • Inserting twin sectors, with the same address but different data will yield different results when seeking data forward and backward. Checking for the existence of this is possible, and duplicating a CD with these twin sectors is very difficult.

  • Measuring the actual position of the pits in the CD. Once again, duplicating a CD with the pits in the same positions is very difficult.

  However, many CD emulators, like Daemon Tools, or Alcohol 120% can actually emulate these features. Because of this, many publishers choose to include a CD emulator detection step, and prevent the game from running if an emulator is detected. The implementation of an emulator detector is outside of the scope of this answer though.

• Instead of, or in addition to checking for a physical CD, a game can request the user to input some data, like a product key. Some ways to use product keys are:

  • Checking for mathematical features in the key. However, this doesn't prevent key duplication, and if the checking algorithm is discovered or reverse-engineered, a pirate may be able to create new keys at will which will appear to be legitimate to the game. Software that creates keys at will are called "keygens".

  • Generating a hash based on the user's hardware, send this hash and the product key (usually a combination, called the "installation key") to a server owned by the game company, and based on the hash and serial, create an activation key. Using one-way numeric methods (like modular arithmetic, or some methods with elliptic curves), a game can see if the activation key matches the hash and serial code, and only run if they match. This technique is called "activation".

    With activation, a server may refuse to provide activation keys for multiple hardware hashes with the same serial code. Because of this, even if the serial code, and activation key are copied, the activation key won't match and the game won't run on other computers.

First thing first: there is (generally) no way for a computer to know whether a file is pirated or not. Piracy is a legal/moral term, and since a file consists only of ones and zeroes, there are no technical ways to know if a copy of a file is legitimate or not.

That said, piracy prevention and countermeasures usually involve checking whether or not a user has something which can only be obtained if a copy of the game was purchased, and do something if the check fails. There are tons of ways to do this, each one with advantages as well as flaws. I'll mention a few:

• Early games asked users to input a word from the game manual, which you should only get if you bought a game box. A photocopier or a scanner easily defeats this technique though.

• More recently, media checks are more common. The idea is that you require the game CD to be in the drive to run the game. With this technique, you can either access critical data files from the CD without which the game cannot run, or simply check for the existence of a file in the CD. CD copiers, and more recently drive emulators like Daemon Tools easily defeat this technique.

• To prevent CD copying, the game can check for non-standard elements that were inserted on the game disc during press time, but cannot be easily and reliably replicated in a CD burner, or on CD-R discs. Some common ways to do this are:

  • Writing dummy "ghost" files in the CD, which are not accessible from the CD filesystem, but do exist if you know where to find them. This data is absent on CDs which are copied file-by-file. Disc image copies easily defeat this.

  • Intentional errors: CDs can detect and correct some data errors using error correction codes available on each sector. By intentionally inserting errors during press time, and checking for the existence of these errors, a disc can be judged original. RAW disc image copies defeat this though.

  • Inserting twin sectors, with the same address but different data will yield different results when seeking data forward and backward. Checking for the existence of this is possible, and replicating a CD with these twin sectors is very difficult.

  • Measuring the actual position of the pits in the CD. This is very difficult to replicate.

  However, many CD emulators can actually emulate the same features a physical CD has. Because of this, many publishers choose to include a CD emulator detection step, and prevent the game from running if an emulator is detected. The implementation of an emulator detector is outside of the scope of this answer though.

• Instead of, or in addition to checking for a physical CD, a game can request the user to input some data, like a serial code. Some ways to use serial codes are:

  • Checking for mathematical features in the key. However, this doesn't prevent key duplication, and if the features are discovered, can allow pirates to create new keys, which have the same features. Software that does this are usually called "keygens".

  • Generating a hash based on the user's hardware, send this hash and the serial code to a server owned by the game company, to get a third key. Then use some mathematical methods (modular arithmetic and elliptic curves are common) to check whether the third key is correct. This technique is called "activation". An additional advantage to this method is that the game company can refuse to give third keys based on serials that have already been used. However, if the user's hardware changes (either because of a hardware change, or a resale), the hardware hash will change, and the third key won't match anymore. Some companies allow for de-activation of keys for this purpose.

All of these measures are meant to find whether or not the user owns a purchased copy of the game. However, implementing them requires program code that checks for this. The act of modifying game binaries to disable checks is called "cracking".

• Checking the binary with some hash. However, there must be a program that checks the hash, which can in turn be cracked as well.

• Encrypting the program, or simply the check routine, and decrypting it in runtime. This makes disassembly more difficult, as it involves one or more additional decryption steps. IF the decryption key is included in the program (as it must be, because without it, the game cannot be decrypted), then the pirate can reverse engineer the decryption, find the routine, and crack the copy protection. As a game publisher, you want to make the key hard to find, and optionally make the decryption algorithm hard to understand. Some ways to make the key hard to find are:

  • Obscure it by creating it in strange ways. This simply slows the cracking process.

  • Create per-machine master keys similar to the serial protection mentioned above.

  However, regardless of the method you use to create your keys, the keys itself will be in memory when the decryption step takes place. Memory inspectors, debuggers and emulators can help a pirate find and copy the key while it is in memory. You can prevent memory peeking by:

  • Having a privileged service that detects memory accesses in the specified region, and redirect the addressing somewhere else. This requires ring 0 access, and programs that do this are akin to rootkits. Writing them is extremely difficult, and can easily compromise the stability and security of the host OS. Search for the XCP scandal for a related story.

  • Modern hardware and operating systems allow for much more secure and stable techniques, like memory curtains, secure media paths and TP modules, to make it easier to make programs that decrypt data while being resistant to memory inspection.

There are many many more techniques to attack piracy, ranging from the trivial to the esoteric. However, remember that detecting copied binaries is not possible, so any technique implemented that tries to detect if the user has something which can only be obtainable when a copy is purchased, will invariably create the possibility of false positives.

Also, remember that all techniques -can- be cracked. The intent of piracy protection usually consists in the selection of a variety of techniques, to slow the creation of a cracked copy for enough time to get a large amount of profits for the game developer/publisher.

Regarding Game Dev Tycoon, they did not use any anti-piracy technologies. They simply created a "broken" build, and distributed it over BitTorrent.

First thing first: there is no way for a computer to know whether a file is pirated or not. Piracy is a legal/moral term, and as so, it has no meaning on a file, which is only composed of ones and zeroes.

That said, piracy prevention and countermeasures usually focusing on finding out whether or not a user has something (usually an object) which can only be obtained if a copy of the game was purchased, and make that difficult to duplicate. There are tons of ways to do this, each one with advantages as well as flaws. I'll mention a few:

• Early games asked users to input a word from the game manual, which you should only get if you bought a game box. A photocopier or a scanner easily defeats this technique though.

• More recently, media checks are more common. The idea is that you require the game CD to be in the drive for the game to run. To implement this, you can for example access critical data files from the CD without which the game cannot run, or simply check for the existence of a file in the CD. This worked pretty well when CDs were difficult to duplicate, but CD copiers, and more recently drive emulators can be used to easily defeat these technique.

• However, CD copies are not perfect, so many other techniques focus on detecting whether the CD is the original pressed CD, or a copy. To implement this, a game can check for non-standard elements that are inserted on the game disc during press time, but cannot be easily and reliably replicated by a CD burner, on a CD-R. Some common ways to do this are:

  • Creating dummy "ghost" files in the CD during mastering, which are not accessible from the CD filesystem, but do exist, and can be read if you know where to find them. This data is absent on file-by-file disc copies. Copying the entire disc image will copy these files though.

  • Another way is to intentionally insert errors in the disc. CDs contain error correction codes. By inserting errors in the data, which can be transparently corrected by a disc reader, the disc will work normally, but the errors won't be copied to the CD-R. By looking for these intentional errors, a game can consider a CD to be an original pressed copy. RAW disc image copies defeat this though.

  • Inserting twin sectors, with the same address but different data will yield different results when seeking data forward and backward. Checking for the existence of this is possible, and duplicating a CD with these twin sectors is very difficult.

  • Measuring the actual position of the pits in the CD. Once again, duplicating a CD with the pits in the same positions is very difficult to replicate.

  However, many CD emulators, like Daemon Tools, or Alcohol 120% can actually emulate these features. Because of this, many publishers choose to include a CD emulator detection step, and prevent the game from running if an emulator is detected. The implementation of an emulator detector is outside of the scope of this answer though.

• Instead of, or in addition to checking for a physical CD, a game can request the user to input some data, like a product key. Some ways to use product keys are:

  • Checking for mathematical features in the key. However, this doesn't prevent key duplication, and if the checking algorithm is discovered or reverse-engineered, a pirate may be able to create new keys at will which will appear to be legitimate to the game. Software that creates keys at will are called "keygens".

  • Generating a hash based on the user's hardware, send this hash and the product key (usually a combination, called the "installation key") to a server owned by the game company, and based on the hash and serial, create an activation key. Using one-way numeric methods (like modular arithmetic, or some methods with elliptic curves), a game can see if the activation key matches the hash and serial code, and only run if they match. This technique is called "activation".

    With activation, a server may refuse to provide activation keys for multiple hardware hashes with the same serial code. Because of this, even if the serial code, and activation key are copied, the activation key won't match and the game won't run on other computers.

All of these measures are meant to find whether or not the user owns a purchased copy of the game. However, implementing them requires program code that checks for this. It is possible for a pirate to modify the game code to disable or bypass the checks instead of attacking the copy protection mechanisms themselves. The act of modifying game binaries to remove anti-piracy checks is called "cracking".

• Checking the binary with some hash. However, there must be a program that checks the hash, which can in turn be cracked as well.

• Encrypting the program, or simply the check routine, and decrypting it in runtime. This makes disassembly more difficult, as it involves one or more additional decryption steps. IF the decryption key is included in the program (as it must be, because without it, the game cannot be decrypted), then the pirate can reverse engineer the decryption, find the routine, and crack the copy protection.

  Because of this, as a game publisher, you want to make the key as hard to find as possible, and optionally make the decryption algorithm hard to understand. Some ways to make the key hard to find are:

  • Obscure it by creating it in strange ways. This simply slows the cracking process.

  • Create per-machine master keys similar to the serial protection mentioned above.

  However, regardless of the method you use to create your keys, the keys themselves will be in memory while decryption is in progress. Memory inspectors, debuggers and emulators can help a pirate find and copy the key while it is in memory. Memory peeking can be attacked in several ways:

  • Having a privileged service that detects memory accesses in the specified region, and redirect the addressing somewhere else. As this requires ring 0 access, and programs that do this are more commonly used for not-so-legitimate purposes, antivirus software usually block them. (this is why many games and other software ask to turn off virus protection when running). Writing software that correctly does this is extremely difficult, and can easily compromise the stability and security of the host OS. The XCP scandal is a good example of an implementation of this method gone wrong.

  • Modern hardware and operating systems provide some tools, like memory curtains, secure media paths and TP modules, to make it easier to make a program that decrypts data, while being resistant to memory inspection.

There are many many more techniques to attack piracy, ranging from the trivial to the esoteric. Unfortunately, it is possible for all of these techniques to fail to recognize a genuine copy, and it's usually the more aggressive techniques that have higher false positive ratios.

As a game publisher, you usually want to choose a set of techniques whose cost of implementation, expected cracking time, and false positive ratio are in line with your expectations.

It is a common misconception that piracy protection is meant to be completely unbreakable. Most game sales happen in the first few months after release, so a piracy protection scheme is usually considered effective if breaking it consumes enough time for the game publisher to collect a large amount of profits before it gets broken.

Regarding Game Dev Tycoon, they did not use any anti-piracy technologies. They simply created a "broken" build, and distributed it over BitTorrent, as is stated in the beginning of the article you mentioned.