A TAGES dialog

I think Debro is still thinking of pit = 0, land = 1, in binary.

Nah.

Hi,

I just browed a well known site about copying games and its forum and erm there you can download a proggie which asks for the motoracer3 ccd image, and patches it so you can burn it to cd and it is said and verified to work by several ppl!
It even works when you apply the patch which has proven to be so difficult to crack.

But, I think this proggie beats tages! so if you own motoracer and want a copy just download this file !

Perhaps this program is like twinpeaks, it inserts double sectorranges on the cd, which tages checks.

But this can then also be done with more games, if there were any more games with tages

Well, greets, just wanted to share this with y'all !

And this site is FileForums You forgot to say.

@Gr:
You haven't read this thread.

> Perhaps this program is like twinpeaks, it
> inserts double sectorranges on the cd, which
> tages checks.

Yes nothing new there, except it took this guy
500+kB of delphi crap to read 3 files and write
one, with a few bugs and spelling errors.

> But this can then also be done with more
> games, if there were any more games with
> tages

Isn't that obvious since the first post ?

Well, okay, read the entire thread, but I must say ....

It begins with a chatlog, then goes to theory explaining tages, then to pits and lands, then back to theory, then again to pits and lands.
All these peeps in here claim to know/understand tages and explain how it can be beaten.
BUT ... noone does .... therefore I posted this proggie, I havent tested it, but againt all theory in this thread it seemed nice to actually have someone who can do it !

Yeah like you say, It is obvious that it would work on all games but this is the first major step towards actually making all this talking theory work !

Seemed important to me, sorry if you feel otherwise !

cheers

This very sentence showed that you haven't understood how Tagès works Well, it is not comprehensible within 5 minutes if you don't know how seeking on a CD works. Take the time you need...

Nah....it *thinks* that it is an original

> All these peeps in here claim to know/understand tages and explain how it
> can be beaten. BUT ... noone does .... therefore I posted this proggie,
> I havent tested it, but againt all theory in this thread it seemed nice
> to actually have someone who can do it !

How naive you are...

The fact that you haven't heard about something does not mean that this
thing does not exist. There are very smart people out there who don't bother
distributing their work on the internet and don't care about virtual fame.
What I posted was not a theory but an explanation I have been given by one
such person, and as an explanation it had been validated by making a working
MR3 copy.

At the time of your first post I already knew of 2 tools able to rebuild
a MR3 image (and, more important, to extract the twin sectors from the original
disc). Another reason why these tools are not public is that some of these
smart people believe that the tages guys are just testing their protection,
and therefore that distributing them before tages is widely deployed is just
wasting them.

Exactly.

But not at all related efm codes.

Everything seems like a great idea at 3:00 AM in the morning and you're practically delirious!

Alot like drunken cooking.

It makes sense at the time. Although you'd never do it normally.

Maybe I was just rambling on.

Now that it's the end of 2003 soon to be 2004, might it now be time to release some of these tools to defete Tages? It seems some more titles have been released with Tages, XIII being one of them.

Just curious.

Beyond good & evil , also has Tages

actually, there was a tages patcher that was released for motorcross madness 3, from what i read it takes in a image and modifys it so it works, its not 1:1 but its not cra***d either and the game data isnt modified. unfortunatley its a bit harder to come by these days but im curious to see if it can work with XIII and beyond good&evil...

tages has been beaten b4, im sure it can be done again

I've found reading the disc forwards then backwards and checking
against the first image never gives me 100% results, although
its quite clear when the double range starts, i get results like

CloneCD Sector 0x00040609 differs
CloneCD Sector 0x00040607 differs
CloneCD Sector 0x00040606 differs
CloneCD Sector 0x00040603 differs

but when after readin sectors 0x40608/5/4 several times
with cdrwin they are twin. anyone else had this problem?
I was wondering if its drive cache or something but im not
sure, i would of thought surely i should get these sectors
returned differently every time.



this is how tages requests a sector from the secure zone,
target sector is what its after, and the data will differe at
the end. Seems a little odd, maybe someone else can make
more sense of it than me oh and before it does all those
reads, it always starts with one read of sector 0x10.

yates.

> and before it does all those reads, it always starts with one read of sector 0x10

Is there any clue to this behaviour in the contents of sector 0x10, or is it just a predetermined start point for the seeking.

It really sounds like the end-point (target) is all that matters. Have you compared results, when a different path to the endpoint is taken?

0x10 is just the header, it starts here so its before all the
ranges i suppose, the 2nd read is always the same, its
sector value is stored and encrypted in 0x10, its probably
the end of the first range or something.

i think its quite clear from the pictures it seeks back then
starts to read a double range but i dont know why i cant
see this 100% by scannin back and forth,

yates.

---

Last edited by [yAtEs]; 13-12-2003 at 20:33.

[yAtEs]

There appears to be a repeating pattern in your data.

The sectors with data starting with 00 00 02 00 appear to be the double sectors,

i.e. the range 263904-264906

you have successfully read the two different sectors of 263906


Similarly the sectors 263926-263928 are doubles again.

How do we deliberately read version 1 or version 2 of the double?

The answer could be in the seek before (perhaps call it the starting point) The drive knows roughly how far to move the read head to get to the next seek position. The twin data must be close together, probably within 150-250 sectors.

i.e.
seek to 261982 then seek to 263928 gives version 1 of data
seek to 262166 then seek to 263928 gives version 2 of data

difference between starting points - 184 sectors.


I guess it would be too much to expect that 1 set of the double data would always start with 00 00 02 00 ?

I also guess that it would be too convenient if the doubled sectors only occurred in runs of 3 at a time.

I guess we need a little routine that starts about 150-180 sectors before the secure zone, seeks something less than 184 forward, reads a certain number of sectors (perhaps say 100) then repeats this from a second start point 184 sectors forward and repeats this process over and over until the secure zone is cleared.

It certainly doesn't look like you need to read the CD backwards.

(I hope I haven't misinterpreted your data)

>There appears to be a repeating pattern in your data.

>The sectors with data starting with 00 00 02 00 appear to be >the double sectors,

>i.e. the range 263904-264906


I would also like to point out that there is a quadruple sector in there.

263929 occurs 4 times, and the data all starts with 17 6d 00 00

could there possibly be 4 occurences of this sector or is this just a fluke?

If it isn't a fluke how are you going to differentiate between the four sectors if it will only be reading twice?

What needs to be found is how the tages system requests the correct sector, and then all that has to be replicated is the proper sector.

>If it isn't a fluke how are you going to differentiate between the >four sectors if it will only be reading twice?

theres only 2 sectors, the data differs only once, the yellow
markers indicate a zone change, any same sectors read after and
before zones you can see the data changes.

Im still scratchin my head thou
I cant simulate the read outs 100% using cdrwins sector
read, for example,
i can quite happily read sector 16 then 263929 and repeat
this several times and sometimes the data will change, and
sometimes it wont but not in any pattern, i cant get stable
results, hrmpf maybe i need to use scsi passthrough like the
drivers instead of aspi, i dont see why it would make any
difference thou.

yates.

[yAtEs]

To allow for differences in CD drives, there may well be multiple runs of double sectors, interspaced at various intervals.

Our difficulty is that monovular twin sectors aren't detectable. (although in another part of CDFreaks someone says differently).

It could well be time to make a "best guess"

You know approximately the bounds of the secure area.
Concentrate on reading it (I wish I could program), from staggered starting points, make a copy of the known double sectors, write out an approximation, maybe err on the side of safety, making triple or quadruple copies.

I know, not very scientific, but it might just work?

yates

Is there an easy way to find the Secure region, via reading the disc, or have you reverse engineered what Tages does?

Does it vary from title to title?

I'll try and put some code together (using the SPTI interface) over the Christmas break, and see if I can help.

>Is there an easy way to find the Secure region, via reading the disc, or have you reverse engineered what Tages does?

yup, read sector 0x10, take the dword from offset 0x383
then xor with 0x70C963C6, add about 5 or 6 to it and thats
the area twin sectors exist for.

>Does it vary from title to title?

latest 3 titles it doesnt, however the first old edition used
on mr3 stores the range start is in its driver, i should probably
also mention that reading the range on this disc is very easy
so i suspect the later versions have changed the structuring
and layout.

yates.

Merry Christmas all.

The Tages Santa will be delivering presents a few days late this year!!

Yates (and other interested onlookers)

I have written a little utility to read the duplicated sectors from the Secure region. It actually reads the sectors in raw mode.

I've been experimenting with CD2 from the recent Title XIII

Using your method, I've calculated the secure zone to be starting at about sector 281163 (add 5 or 6 to this as you said).


Using my utility I have found an almost complete set of duplicated sectors from 281170 to 281424. There are a few "holes", but I expect that when I fine tune the program, these holes will be filled.

It is indeed good to confirm what the very first posting in this thread said.