1337 paint skillz lol keep it coming

themabus wrote:

Vigi, you were right about offset difference on sega logo.
from 6 cds i've checked 4 offsets match with datatrack offset but 2 doesn't.

You were right about the 6 sectors, so I guess the write offset after the ring is 6x588 + (180-30) = +3678 vs +222 before (+3678 - 222 = +3456, a funny number tongue).

Anyway, it's weird that the offsets differ on some discs.. maybe they used a separate device to add the logo?...

and maybe all discs start at the same sector after combined offset correction? if so, then it would be easy to convert a redump dump to a complete one: just insert zeroes after the original dump data up to sector 297143, then 550 sectors of 55's and then the logo data (if this data is always the same, including the RAW bytes?).

Also, I'm a bit confused.. the 'logo' area, is it the same area that is visible at the end of the disc when you hold it in the light? It has the same Sega logo written on there.

thanks! big_smile

Also, I'm a bit confused.. the 'logo' area, is it the same area that is visible at the end of the disc when you hold it in the light? It has the same Sega logo written on there.

when console boots up saturn will drive laser to this area and do few readings and if it's a backup - will fail.
so this final protection, it's very likely to be somewhere there.
i'm now very sure it's actually this logo, like RPS and few other people said (years ago smile ). because it's in CAV, this area is unlike the rest of cd.
every track consists of the same amount of frames (tracks do not get longer, closer to outer edge)

Console: SS
FPT=2058 (2058/98=21 sec.) <|Frames Per Track

Console: DC
FPT=1078 (1078/98=11 sec.)

so on backup this logo will never show up. it washes along the tracks and becomes garbage.
so i guess it doesn't matter how you pad it - to get logo, whole data would have to be recreated anyway, based on cd geometry.
would that work? - i don't know, it's unlikely, original is very precise (as can be seen in microscope,
i don't belive anyone could do that without proper hardaware)
maybe offset affects this whole process as well - i'm not sure. if it does, ther's 6 possible ways to pass data to circ
(one is correct, on four other ring will shuffle, like in those images i posted earlier).
and probably contrast on recorded media is too low to see anythig, anyway.
and maybe protection is something else after all...

also what's strange, sector count per track seems very low, compared to what i estimated from empty area. but maybe i made a mistake there.

i only had one DC ring, from European ChuChu Rocket. and it looks to be 1sample off. so you must remove 4bytes from the start of data
to get correct logo. but likely it's also my fault could be a bad dump.

Vigi, could you, please, check your DC rings?

i've uploaded the program here that will do circ delay lines and output ring to ASCII.

syntax is:
ring2ascii.bat s 2058 10 RING_data.raw >SSRing
ring2ascii.bat s 1078 10 RING_data.raw >DCRing

i'll try to write something to reconfigure this data depending on cd in next few days,
maybe something shows up, some blured franken-image...

also, maybe new burners could write this logo easy, if you could specify CAV mode and speed,
i think, that's pretty much all there is.

Ok, here's a package from Sonic Adventure:


You should explain me how to open the ascii output (which tool are you using in those logo screenshots?) big_smile

thank you very much, Vigi!

i used Notepad++
it should have monospace font set by default, i think
ther's option to zoom out, under 'View', so you can go all way
it's slow tho, but good for overview

also you can just hit F4 in FAR Manager

..it's stupid, i know, but less coding... smile

Dremora already helped me identify the tool tongue


anyway, aren't we just extracting the printed ring text on the CD in bytes and turning it back into readable ASCII text? lol because both texts are identical:


I guess we should start looking at the pregap instead? neutral

anyway, aren't we just extracting the printed ring text on the CD in bytes and turning it back into readable ASCII text? lol because both texts are identical:

yeah, that's what we do big_smile

maybe it's not there, maybe CAV is used only because it's easier to write logo this way
but many people talked about it being logo.
so i want to be sure smile if we can not draw it - it's ok, but let's check and see.
in a few days we will know, i think

i recalculated sectors per track, and it looks pretty close to CLV. on Saturn logo takes ~3mm (height)
it's about 2..3 sectors per track difference @CLV from top / bottom of logo. for 1400 tracks it's not that bad, i guess.
i'll make circ encoder and i want to to try to draw some cubes and rays and such on cd firs
if it's possible, maybe logo is too.

oh, sonic's logo start at the same MSF, where ChuChu Rocket, when leading sectors are removed.
and my rocket dump was desynchronized in middle, so thanks. if i can draw those cubes i'll try dc 1st, because it's closer to centre - can do faster.

it's too dark to take good photo today, but i pretty much have it on 700mb cd-rw
it's distorted, but not as bad as i've thought it would be
it's on 1st try, after probing cd for characteristics with rays
so very possible to improve
tho i went through cdfreaks again and pinchy's page and don't expect it to boot now,
but it was fun smile

i'll post tools soon

better picture

And why don't you expect it to boot? tongue

Amazing !!!

thanks, p_star! smile

it would be too simple...
on those forums ther's at least two people, who knew how this ring is made: Bexster/RPS (i think it's same person) @cdfreaks and HI_Ricky @segaxtreme/assemblergames.
they would have figured it out, i guess.
only way i can now imagine this to pass is if saturn rotates cd at some speed and checks laser wave, e.g. time for how long ther's short/long waves from pit/land blocks assambling logo pattern. but if it does something more - it would not. and i think it does more. pinchy said his cds pass all checks except the last one. and he's very determined it's before ring, maybe it is gap, like you said, after all. like absence of efm in there.
but anyway i won't give up on this until i try 650mb cd with corrected MSF/subchannel, skipped sectors before ring and ring done in several possible ways (scaled/padded etc.)

here i've redone 1st of those programs:
it interleaves/deinterleaves binary data.

i hope to do rest soon.

what is the difference in burning it on CD-650 or CD-700 ?
pit/land blocks must be of same size if you burning data on this media.

it would interest me, can Sega Saturn read CD-RW's properly? not that you waste your time with CD-RW's

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

track pitch is different: ~1600nm on 650; ~1480nm on 700mb cd.
so ther's more 'tracks' (spiral revolutions) on 700. this makes all data compressed.
if logo is made on the same number of tracks it would be more narrow,
positioned @the same LBA as on 650mb cd, physically, on the surface, it will end up closer to the center .
assuming that properties of this area are verified, and we strive to simulate them,
ther's too much uncertainty with 700mb imho.
saturn will read RWs after laser is adjusted. on factory settings they wouldn't even spin up.

You've right with track pitch, and I understand your thought and intentions what concerns the logo zone. You believe also the hardware would read the discs, independent of the contents, at exactly logo ring position!? Indeed, this would be crazy!

I have seen that Saturn discs have 2 rings (inner and outer). Or is this inner ring simply the lead-in area?

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

it might, the thing is - i don't know tongue, closer it is to original the better

honestly, i haven't noticed, but yeah, looks like ring.
it's d ~44 mm..~46 mm for 'inner buffer zone' and ~46 mm..~50 mm for lead in, i think.
but what makes this thin stripe, i don't know. maybe you can compare it with other pressed cds - pc, audio... (better older)?
i only have those few from saturn atm.

got my saturn now, tried swapping and it can be done so, that only outer part from the original cd is read.
whatever there is @center, it doesn't matter.

ther's another guy: ProgrammingAce @SegaKatana forum
the site is dead now, so i'll repost here, what he wrote:

ProgrammingAce          Post subject:
Posted: Sat Apr 21, 2007 12:12 am
Joined: Thu Jul 20, 2006 1:14 am
Posts: 14        

Grr... my RSS feed here was damaged (i forgot to update, even though mark specifically warned me).

I know quite a bit about copy protections (and saturn specifically). I can tell you that not only is it possible to burned self booting Saturn games, but that it has already been done.

It looks like you're on the right track. If you have any questions, let me know.

ProgrammingAce          Post subject:
Posted: Sat Apr 21, 2007 12:53 am
Joined: Thu Jul 20, 2006 1:14 am
Posts: 14        

Alright, to be a bit more helpful i read through what pinchy said on the cd forums.

Although they're arrogant, they're also right. The pre-ring data is irrelevant, or to be more accurate, non existant. The CD-ROM drive in the saturn isn't any more advanced then what you use in your PC. If you can't force a drive to do a raw read of the sectors, chances are they're no good.

I tried to test the counter that is supposed to increment when reading actaul ring data by moving it down to the pre ring area but it still didnt increment.

This confuses me. The check is hard coded to the address location. You're missing the cause and effect. The seek doesn't start the check, the check is a result of the copy protection function.

Save the cheerleader, save the world.

ProgrammingAce          Post subject:
Posted: Fri Apr 27, 2007 5:00 am
Joined: Thu Jul 20, 2006 1:14 am
Posts: 14        

-=FamilyGuy=- wrote:

I noticed that the data seems to be audio, and I don't think it as something to do with any knid of refraction like some are saying .. it makes no sense.

The ring, to me, looks like this : weird sector + a8 59 pattern + weird sectors

The ring data is audio, it's a tone.

The weird sectors are markers, not readable data. Reproducing them would be futile (if even possible without stamping equipment).

it's about the same what Bexster/RPS wrote @cdfreaks

here, he says more @gamerhistory forum

my pc died today... sad
it was having problems for about last half month.
would not start often and when it did, was going on defaults only - cmos would hang on save.
the week i didn't wrote 15..24 i was replacing cpu, i thought it was l2 cache, but it didn't help.
so finaly today it's stone cold. even bios doesn't beep.
and i can't afford repair or a new one now.

so i won't be able to do anything for a while.
i'm sorry i couldn't finish those programs.

i was writing simulation on pc. the ray, when you supply wrong parameters form curve what's essentially archimedean spiral.
so i thought that would be interesting to experiment with it on pc screen, rather than reburn cds all the time.

to form a ray - it's not hard. all you need is to take start / end radius, track pitch and channel bit size as variables
(width of ray optionally - it's better to start with at least one sector wide and decrease it gradually, as it gets straighter)
and calc rings with incremental circumference from 2*Pi*r. that's what i did, but maybe ther's a better way.

when parameters of given cd are determined you can draw whatever you like in this model, (or realign data / pad / add headers...)
and then run it through deinterleave routine to form an image,
thogh it will always be distorted by some amount, i guess, because it's an approximation after all
and because of the nature how cds work.

i never tested those images on saturn, myself... i sincerely hope somebody will.

i finally rewrote those programs. i'm glad i could keep the promise but i'm very sorry it took me so long.

everything is combined in 2 exes: one for interleaving and the other one for recalculating CAV->CLV
(please let me know it ther's any problems - still havent tested them much, but i think their fine.)

previously i've tried doing visualisation (on 486 dos machine in vesa smile ) but it's inaccurate.
either you see very small section of cd close or about 4% approximation. neither is very useful imho.
so instead i've changed algorithm for how spiral is broken into tracks from circles to smaller Archimedes' spirals.
this way parameters tie together much better and deviation on whole spiral length is only few bytes.
so generally no visualisation is required. to calculate arc length i use 1st formula given below,
but it's also possible to use 2nd, it's much smaller and very precise also - only differs by 1..2 bytes from 1st one.

s(r₂) - s(r₁)
              _________                 _________
s = ½ r √1 + (r/a)² + ½ a ln (√1 + (r/a)² + r/a)

s ≈ π (r₂² - r₁² ) / ε

ε = pitch

i've tested about 20 patterns on console (different scaling, sector headers on/off, different sector sizes by headers and so on),
with no results. they all act the same: check boot code, go to ring, return to center, return to ring, fail.
altrough they all were written to same 650mb rw @10x and subcode were not modified, i don't think it would change anything.
it's either just too rough or will not work at all because of different sector amount.

also what's interesting, to do more precise scaling, i've tried to clean up ring data by mapping everything to $59/$a8 patterns,
and it's not possible actually. the thing is - every character in copyright message, it's little different.  similar letters - they just look the same
but are not. so when you have eg. byte $ff right between $59 and $a8: ..$59 $59 $ff $a8 $a8.. you can not tell, should it be $59 or $a8.

OO     OO    OO      O?
OO     OO    OO      O?
OO     OO    OO      O?
OO     OO    OO      O?

this adds yet more variables to the equation...
still i've uploaded it anyway here:
(all non dual pattern bytes were mapped to $ff)

so i think only rational way to recreate this data would be by actually writting it in CAV with constant RPM.
but i don't know is this possible at all. i think it should be, by modding firmware or connecting to spindle motor controller probably.

i'll post on cdfreaks what we have, and will try to ask there. somebody should know.

i've changed one program a little today. and added brief tutorial.
so now it's very easy to output basic shapes and forms to cd. eg it's possible to draw something simple, like this even in notepad.


and you just need to specify how many times to repeat pattern.
but still you need to know parameters of given CD - it's a huge drawback.


hello, RPS! i'm very glad you're here
actually every tidbit of information would be welcome smile

but so, to be more specific:
basically as i understand this ring with copyright/logo essentially is an area recorded in CAV.
so, how i see it, on ordinary CLV CD pit/land length (T) would stay fixed (with insignificant deviations)
and hence every revolution, from center to outside, would increase in data capacity (by ~35 channel bits).
in CAV on the other hand T is variable that changes so all revolutions hold same amount of data
and pit/land length increases in direction from center to outside.
is this what you meant when you referred to an area with no EFM?
or was it perhaps this transition area (empty zone on microscope image) from ordinary data to ring?
this is what i'm most puzzled about.
also from my understanding, to simulate this CAV layout one would need to keep spindle motor @fixed RPM
(or RPS smile i can't stop to think your nick actually being a tongue in cheek like humor, excue me if i'm wrong)
maybe you have performed such experiments before?
i'm currently reading book on cd circuits but it's probably years until i get there.
so the plan is to hack drive and get this ring on CD-R in CAV. and in case of positive result proceed further
from there. this ability to recreate ring at will would allow necessary flexibility for experimentation
and improving method and making it more user friendly and possibly simplify it to level
where drive hacking would not be required at all.
other possible outcome - ring recreated in CAV would not work. then i guess nothing would.
but we would have done all we could, at least.

as i understand you have a lot of experience with hardware hacking, maybe you are interested in this yourself?
but if not, could you, please, point in direction, where to look to get it done eg. from firmware, circuit?...

thank you very, very much, RPS!

after seeing your reply, to actually grasp what you said, i had to read through whole book i had. smile
though, i have to admit, i'm still not exactly sure about fully reflective area,
i think i do have basic understanding now of how this would work in regard of CAV area.
those signals, that could possibly be used for authentication, they can originate in these stages:
1.Focusing - but it's unlikely, i guess. there is no relief changes.
and would there be, they'd have to be distinguished from disc vibration.
2.Autotracking - could be used for reflective area. for CAV it's less feasible,
though a lot would depend on exact implementation.
3.High-Frequency Information Signal decoding - on this stage, when it's being transformed into binary signal,
certain frequency would directly depend on channel bit size, making CAV/CLV differentce unambiguous.
4.EFM demodulation - drive rotation speed is constantly corrected depending on subccode block frequency.
so again CAV/CLV difference manifests in a very blatant way.

so thank you again. though yet lacking confidence to experiment with a hardware,
(still have to read much more...) i do have a clear vision of what to do now smile

ther's an easy way to tell CAV/CLV data aligment apart by measuring time it takes for optics to position from one sector to another.
i guess this is about what Alcohol does with DPM on. maybe it could be used to get characteristics of spiral from CD-Rs
but probably it's too rough. i haven't got much time to test it myself and i'll be away for about 2 weeks, so i've included sources too:

for example Dreamcast GD-ROM: (didn't know much about it but being described as CAV on wiki, i thought it's curious)

1st area - regular CLV
linear decrease in delay is clearly visible here (jump @7000, it's drive dropping speed)
this happens, because same amount of sectors in CLV take more revolutions at the center and less towards the outside of CD,
so less mechanical movement is involved to skip same distance (measured in sectors) as radius increases.

2nd area - logo
for CAV it's constant.

3rd area - high density
here change of delay is a lot less obvious than in 1st area, but still present.

it's possible to keep one of sectors fixed instead of distance, so now revolutions become visible:
@the beginning of  3rd area

towards the end

from last two images it's apparent, that sectors per track in this area aren't nowhere close to being constant.
so even though pitch or T is modified, essentially it's CLV.

fixed download link

on system discs KD01 & KD02

so what matters is valid System ID record in System Area and particularly -
special identifier in it's Product Number field: *EGASYSTEM
everything else - does not.
it can be any track layout, any content - as long as it's valid for Saturn it will function.

Product Number field is where serial usually goes,
so it's possible to change it with hex editor to value mentioned above for any Saturn CD
and it will disable repeated ring checks after 1st validation - just like system disc does - even after reboot.

difference between KD01 and KD02 lies in Maker ID field
it's '*EGA ENTERPRISES' in 1st case - 1st party and '*EGA TP' in 2nd - 3rd party
this is not different from all normal CDs and this value is kept somewhere in memory after 1st validation,
so would you make system disc out of CD with serial T-????? (3rd party) it would function as KD02
system disc made from GS-????? CDs (1st party) would work like KD01
(except that game will still boot - actual system disc does nothing after execution of AIP - cease to function)
there appears to be no further distinction between manufacturers based on company code for 3rd party CDs
so one should work for all.

after System ID record ther's Security Code. it's like always and also Area Code group is unmodified.

and then ther's Application Initial Program for about 2 sectors, i'm not sure what it does
well it displays message on screen and appears to modify fonts, i think, but that's all i could figure
maybe it sets up some additional functions for system disc,
but it appears to play no role in boot process modification whatsoever.

so this special value for Product Number field is interesting.
maybe ther's others? maybe ther's one, that would bypass ring completely?
i'd guess it isn't stored directly for comparation but rather something like checksum would be used.
(as an example: Dreamcast has CRC16 calculated on Product Number+Version stored as an field of System ID)
so if one could figure where this validation takes place,
it should be possible then to determine whether there are any more such magic numbers.

* = S

Do you have them? I've read on segaxtreme, that KD01 and KD02 won't work on a non-dev console.

only images from UG.
they work but since ring can't be reproduced on CD-R as of yet, you'd need to do swap once - for the 1st time.
i have Japanese console though - i don't know about the others, maybe there is an difference.

there appears to be another value: '*EGAVIEWER' for Photo CDs
though maybe just syntax is alike

identifier '*EGASYSTEM' is also present in DC System Disc replacing CRC16 & Device Information

boot process roughly:
- check for 1st instance of '*EGA *EGASATURN ' identifier at user data offset 0 in first 15 sectors
- if present check ring
- if pass carry on with Security Code, Area Code verification

minimum to disable further ring checks (like SD does) appears to be pass on 1st two checks
and additionaly properly filled Maker ID & Product Number fields
all the rest can be blank dat - 0x00

also i've tried to replace identifiers with various strings that would yield same CRCs for most common models
and few other things and they wouldn't pass so i'd guess they're actually byte compared for exact match

i wrote summary in 1st post

maybe somebody feels like experimenting with 90 or 99 min CDs?
in a way, depending on which characteristics are evaluated,
they would replicate protection ring with less distortions than 74 or 80 min ones
e.g. 74min CD would gain ~52645 channel bits per 1460 revolutions, while 99min only ~39884 (25% less)
though i don't think Saturn would read 99 at all, maybe 90

i haven't tried any of those myself since there aren't such RWs