Another Tages blunder

Posted 01 March 2004 15:51 CET by Jan Willem Aldershoff


Article written by Michael Spath

Introduction

At CDFreaks we like TAGES protection a lot. We were the first to explain the protection method they used on Motoracer 3 (that we named 'twin sectors') and later we reused it to copy Securom. Recently, we even contributed to their promotion. Therefore, when after 2 years of silence we saw 3 new TAGES protected games coming in, it seemed natural for us to have a look at this new flavour.

The goal of this article is to give a detailed explanation of both old and new TAGES authentication schemes, as well as various methods for twin sectors injection. As an example, I will explain how I made a working backup of XIII CD2 and I will especially expose the reasoning behind the method, in the hope that some readers may benefit from it when investigating other protections. Note that this is not a step-by-step method to copy XIII, but a technical article about the inner workings of TAGES and the methods to circumvent it.

History of TAGES

The TAGES copy protection system has been developed between 1999 and 2001 by two french companies, THALES (a big electronics corporation, specialized in defence and aerospace) and MPO (a CD/DVD disc manufacturer). Since 2003, TAGES is managed by a brand new company called TAGES SA. At the time of writing, 4 games are protected by TAGES :

MotoRacer 3 by Delphine Software (2001) 
Robocop from Titus Interactive (2003)
Beyond Good & Evil and XIII from Ubi Soft (2003)

Although it is common practice for copy protection companies to exaggerate their merits on their websites, TAGES SA is truly setting new standards in marketing bluff. Not only are they pretending (in red capital letters) to be the toughest protection around, but they also picked up some quotes from various discussion forums to emphasize it. Of course, these quotes have been carefully chosen to convince potential customers that TAGES is truly unbeatable.

Reality is a bit different though. For instance Motoracer3 has been broken in every possible way : not only did we get the usual NoCD patch, but a working backup (ISOs) has been made by the Mojito group, using the twin sector method I will describe later. Also a free tool (T-Euro by MX450) is available to convert an MR3 Alcohol image into a working copy. Finally, a Motoracer3 emulator has been written by puzzo (even before the patched images were available).

Before looking if the new version is as unbeatable as the old one, let's first refresh our knowledge about these famous twin sectors.

Twin sectors

To prevent duplication of protected CDs, TAGES applies some physical modifications to the disc that we named 'twin sectors'. A twin sector is a sector which has the same number and subcode address as an already existing sector, but different data. Due to the inner workings of a drive, these twin sectors are not seen by copying programs ; therefore, by checking for the presence of such twin sectors, TAGES ensures that it is an original disc. Any drive can read twin sectors and, more interestingly, any RAW-16 compatible drive can write them.

Here's the sector layout of a typical TAGES protected disc :

After the original sector range 1400-1700 (A) another range of same size has been inserted, which contains different data (B). To access these two ranges, TAGES uses the fact that all CD drives use relative displacements for jumping to a given location. Indeed, when a drive is instructed to read a given sector, it calculates an approximate distance (based on the current and target addresses) where to move the laser, moves it and read addresses again. If the move was too short, the first decoded address will be smaller than the target one and the drive will seek forward. If the move was too long, the drive will seek back. This trial and error method goes on until the laser has reached a location close enough to the target address.

Based on these observations, the original TAGES method used seek-forward and seek-back tricks to access twin sectors, as described on the following picture :

If we read sector 1000, we obviously force the laser to go to location 1000. If we next ask for sector 1500, the drive will calculate and apply to the laser a forward move corresponding to +500 sectors, and will therefore reach sector 1500 in range A. On the other hand, if we ask sector 1500 just after having read sector 2000, then the drive will seek back of a distance corresponding to -500 sectors and will get data from sector 1500 in range B. TAGES has been able to read different data from the same sector number and therefore considers that this is an original disc. This method was used on Motoracer 3 and could be fooled by simply inserting the missing twin sectors in the image. The new method is a bit different, as we will see now.

Eight steps to success

First of all, a quick check of XIII CD2 shows that it contains about 260 twin sectors from address 281165 to 281424, so we can already dump them and keep the file for later. Now if we start the game a few times and look at the drive accesses, we see something different from the old method : each time TAGES has to authenticate the disc, a different number of sectors with different addresses is read. Obviously some randomness has been added to puzzle the casual observer. Nothing to fear though, since a trained eye can easily cut through this pseudo-random fog and recognize patterns in these sequences, and from them deduce the authentication strategy.

Each authentication of XIII CD2 is made of 8 sequences, each one preceded by a read of sector 10h and a read_capacity command. The disc authentication is successful if all 8 authentication sequences are successful. Each one of these sequences shows some constant operations :

  • a first reading of sector 281412. This is a twin sector, and therefore data from range A or range B can be read.
  • a series of single sector read accesses alternatively between the twin and the normal range.
  • a final reading of several consecutive sectors, whose last read sector number is always equal to the third read sector number. This authentication sequence is successful if the data read by the third and last sector accesses read belong to different ranges (range A then B or vice-versa).

The address of this 3rd and last sector is always fixed for a given sequence number :

1) check 281203       5) check 281402
2) check 281204 6) check 281402
3) empty sequence 7) check 281402
4) check 281402 8) check 281212

 

Note that there are actually only 4 different sector read during these 8 sequences. Here's now a sample log of sequence number 4 :

In this case, data from range A were read during the first access to sector 281402 and we see that only 3 attempts were needed to get data from range B. Note that after the 3rd read TAGES is not looking for the exact same sector number anymore, but for an address a bit before the target sector : in this case, the drive reached range B by reading sector 281397, and then sequentially read sectors until 281402. The idea is that looking for the precise target sector is not needed because we know that if we keep reading sectors sequentially the next ones will also belong to the same range thanks to the drive's cache.

On the other hand, here's what happens with a normal copy of the disc :

The drive seeks back and desperately tries to reach a sector in range B, before giving up after too many retries : authentication has failed, so the game will still start but TAGES will slowly cripple it. Note how the seek back distance continuously grows up, to increase the distance the drive has to travel forward just afterwards, and thus increase the probability of reaching range B.

First let's try the method that worked on Motoracer, i.e. inserting the twin range just after the normal one. The image after this modification looks like this :

Then we start the game and... voila! it doesn't work. Just like a standard bad copy, graphics are crappy, mouse sensitivity continuously decreases, and enemies get extremely hard to kill. When we look closer at what happened, we see that we passed checks 4, 5, 6 and 7 but failed the others : in other words, we were able to reach only twin sector 281402.

Post Mortem

So we tried the old method and it failed : we exhausted our theoretical knowledge of TAGES and, as chess players say, we are now out of the book. At this moment it might be tempting to randomly modify our CloneCD image and burn more CD-RWs, or even to fire SoftICE and IDA and tear the TAGES binaries apart. On the contrary, it is the perfect time to shut down the PC, take a drink, sit comfortably and ponder.

Why is the old method working for sector 281402 and not for the other sectors ? Alright, before trying to understand why it fails in some cases let's first make sure that we understand why it works for 281402 : when the drive seeks from 279xxx to 281402, the laser is moved forward and lands somewhere in range A :

Depending on where exactly the laser lands, we can distinguish 3 cases :

  • if it lands in sub-range 'a' (between the address corresponding to the maximum negative error and 281402), the address read will be lower than 281402, and therefore the drive will seek forward and eventually reach sector 281402 from range A.
  • if it lands in sub-range 'b' (from address 281402 to 281424), the drive will naturally seek back and again eventually reach sector 281402 from range A.
  • if it lands in sub-range 'c' (in the B zone, between 281165 and the address corresponding to the maximum positive error), the drive will consider that its move has been too short, and will therefore jump forward and get sector 281402 from range B.

So if the maximum positive seek error of the drive is larger than 22 sectors, then it has a chance to land in range B and therefore to reach our twin sector. Now if we think about what happened for sector 281203, the situation is very different :

Here we see only two sub-ranges, 'a' and 'b', which means that in all cases the drive will only get data from range A, either by seeking forward or seeking back. So we know why the sectors 2812xx fail the authentication : they are too far from the border of the B range, and therefore will never be reached by the laser.

Our goal is now clear : we should try to modify the image in such a way that the twin sectors stay close to the corresponding original sectors. But as said before, trial and error method with our CloneCD image and CD-RWs is both time and media consuming. However, we were able to explain why the previous image failed just by reasoning and without burning any disc. Therefore, it should be possible to write a software model of TAGES protection, which takes as input a CloneCD image and gives us probabilities that it will be successfully authenticated.

Back to the keyboard, we therefore code a simulator of XIII authentication scheme. If we use it on the previous image, it gives the following figures :

P(281203) = 0.00 % P(281204) = 0.00 % P(281212) = 0.00 % P(281402) = 56.00 % 

which confirms what we observed and explained just before. With this new weapon we should be able to beat TAGES.

Coup de grace

"It is a fact now and FOREVER, it is not just an opinion: we guarantee full immunity with 1:1 copy, since CD-Rs do not have our structural modifications, and a burner cannot do it!" - TAGES website, 2004.

"Perform a thoroughly zen_analyze before attempting deeper methods: do remember that you want to crack the protection scheme SOMEHOW, and not necessarily following the same line of thought that the programmer eventually WANTED YOU TO CRACK IT with." +ORC, 1996.

This fundamental of the zen-cracking philosophy may look like simple common sense, but it is actually a deadly pitfall in which protectionists keep falling into. It means that the strength of a CD copy protection based on physical modifications does not entirely depends on how difficult these modifications are to duplicate, but also on how well the software checks for their presence. In the past several companies claimed that backups of their games were impossible because the physical modifications of the original disc could not be duplicated by a burner. Such claims have already be been proven wrong for Safedisc (amplification vs weak sectors) and Securom (TwinPeak vs DPM) : we will now prove it wrong also for TAGES with twin sectors.

For XIII CD2, this means that we will not waste our time trying to duplicate the 260 twin sectors, but only focus on creating an image that will make the software watchdog happy. And all this lazy pet needs to be happy is 4 twin sectors, so these are the only ones we will focus on. However we must also plan some twin sectors before these magic 4, because the last burst access will only work if the first sector in the row is a twin one. Also since the first 3 sectors are quite close from each other and the last one is close to 281412 (which starts each sequence), we can group all our twin sectors in two ranges. For instance we will try to inject two groups of 50 twin sectors, one from 281165 to 281214 and the other from to 281372 to 281421. Here's our new image :

Now we fixed the problem of the previous layout, since our two regions each important sector in the A range is close to its counterpart in the B range. However, when looking at the results from our simulator, it seems that this is still not good enough :

P(281203) = 76.00 % P(281204) = 78.00 % P(281212) = 94.00 % P(281402) = 0.00 % 

We now have good figures for the first group but the second one is failing. A bit of debugging with the simulator gives the answer, as shown by the following picture :

Below our current sector layout you can see the theoretical sector addresses for the same physical locations on a normal disc. The forward seeks are always performed from a location far before the twin range (around 279500), and as explained before all moves are calculated as relative distances based on the current location. This means that when jumping from 279500 to 281402 the drive will move forward by a distance corresponding to 1902 sectors. But since we already injected 50 twin sectors, it will actually land around a sector whose number is 281353, so before the A range : the first group of 50 twin sectors we injected has increased the absolute location of the second one by 50, preventing the drive from accessing it.

To restore the absolute location of the second range, we will simply get rid of 50 sectors in between the two ranges, since we know sectors in this region are useless. After a bit of thinking, I decided to keep a 1/3 2/3 ratio of uniform regions between the two ranges, and therefore removed sectors 281249 to 281288 from the image. By deleting these 50 sectors we have compensated the injection of the first 50 twin sectors, and now theoretical addresses again match actual addresses on the disc for both ranges :

This is our final layout, and our simulator looks pretty happy with it :

P(281203) = 76.00 % P(281204) = 78.00 % P(281212) = 94.00 % P(281402) = 88.00 % 

And indeed we can now play XIII from our CD-RW backup. This modified image worked very reliably on various types of drives, including a Plextor 2410A burner, a Samsung SD-616 DVD drive, a Toshiba SD-C2402 DVD laptop drive and a Samsung SC-148C SCSI CD-ROM drive. Discs 3 and 4 use different ranges but can be copied with the same method. The tools used to make this backup are available here (54 Kb).

Conclusion

Physical protections all come down to a very simple question : can we read more than we can write ? In other words, can a drive reliably and accurately extract some information from a CD-ROM that a burner cannot write on a CD-R. So far protectionists have not been able to give a definitive answer to this question, and this makes physical protections an open, largely unexplored, and very interesting battlefield.

The weakness which allowed us to make a backup of XIII definitely resides in its implementation, but it is worth noticing that TAGES is inherently weaker than its competitors. Indeed, although it requires physical modifications of a disc, these only have an impact at logical level (i.e. data bytes of a few sectors) rather than at physical level (angle, density, DSV, etc). This makes TAGES very easy to emulate compared to Securom, CDCops or Starforce, and one can only wonder why Daemon Tools and Alcohol don't support it yet. If need be, we will release our own stand alone TAGES emulator.

All in all, this new TAGES release doesn't bring anything really new and still lazily relies on its original twin sector idea. After 2 years of development it seems that all the changes sum up to a new authentication method (as badly implemented as the original one) and a few awkward security improvements (pseudo-random accesses). TAGES requires some fundamental changes to become a really effective protection, especially against emulation. Will the newly created TAGES SA be able to bring these changes ? We shall know soon enough.

Acknowledgements

I would like to thank G., who first introduced me to TAGES and, as usual, CD Freaks.com for hosting this article. Also I want to thank a TAGES employee going by the nickname of Lilith, who convinced me to publish my tools. Articles has been checked for possible legal conflicts.

Contact

Interesting questions, comments and corrections can be sent to spath at cdfreaks dot kom. The accent on the 'E' of TAGES is not an interesting comment and 'how do I copy game xxx ?' is not an interesting question, so both will be ignored. For general discussions about TAGES, please visit this forum and post your technical questions to this one.