New PSX/PS2 selfboot thread

additional info here:

PS @rwarrin :

I doubt the’ll sell selfbooting equipment. Imagine they are IN Japan and the mighty influence of Sony in that country.

Anyone pay attention to the CD/DVD Laminator story from yesterday on the homepage? Could possibly be the way to put the SCE* onto the CD physically, like the felt tip method. If the Felt tip method turns out to work, it could be made into an image to be printed onto the laminate, then the laminate placed on the CD! :bigsmile:

Cool! Perhaps the copy protection will be broken by the most unlikely product. It’d be really funny to see Sony try to get them machines banned due to violations of the DRM. :bigsmile:

Yeah its still a long shot at getting the felt tip pattern correct, but once its worked out this may be the ticket. :o

Thoughts? Sam? Blame?


Sounds too expensive except for commercial pirating. This is not a thing to worry about. If the felt tip trick works, there are lots of ways to implement it. The big problem is making it work.

Sam’s experiments show that felt tipping can fake a part of a SCEx signal. However we can’t fake a SCEx signal of more than 1 revolution of the track. At the current radius of the SCEx track, that is 1/8 of a second. Unfortunately SCEx signals are spaced at one every 1/4 second. Even if we removed the gap between SCEx repetitions, it wont fit. This is the current state of play. It would be best if we concentrated on solving this problem.

Current proposed solutions:

  1. Fool the PSX into slowing down while reading the SCEx track (It currently reads at 1X speed). Frankly I have no idea how this can be achieved A Very long shot.

  2. Compress the SCEx signal. Sam has recently posted ideas on this. There is some chance He may be right. I have proposed ideas myself, but I consider them long shots. The good thing about this solution is it’s easily checked.

  3. Create a second SCEx track at a larger radius, and fool the psx into using it. This will require a real expert on low level CD writing, but I feel it’s the most likely solution.

Please people, if you want backups using the felt tip trick, this is the problem that needs a solution.

Another long time without any new reactions or ideas!

But thats understandable:
That protection lead us to our own farest borders of motivation and the will for keep holding on.

Its much more now a battle against our own mental frustration and against all happend stagnations on our way to beat that protection so long.

This challenge now has changed into some kind of mind-war / nerve-racking and only the strongest will survive all the disappointments, all kind of “usual logic leveled” spreaded No Way! statements and all our formerly ways which leads us as good as almost in wrong directions.

I guess, for the moment just 4 people out of many many at the beginning still remain and who are interrested, motivated and tough enough in keeping on fighting for a final victory against that almost 10 years old protection:

BlameTheEx, Truman, AndrewM and me.

Everyone of us has different skills and different possibilities, almost like in a RPG! :wink:

I’m pretty shure we’re a great & competent team, and if we just would have some new and promising ideas, impulses and motivating information, which enables us for bundling and concentrating our knowledge and powers, we can and will finally finishing this enormous complex task successful!

Its almost winter now, a good time for inventing new ideas and working further on one if not THE toughest CD protection breakthrough ever! So I’d like to suggest we should create a new brain-pool with the ideas and results we got from all our old experiences.

I wanna start with a few own new ideas:

As everybody is aware of, our biggest problem after all success with semi-transparent felt-tip pattern or dot/stripes pattern still is the reliable in recreating those pattern. Compared with ISO9660 and other formats which even have error-correction structures, our paint-pattern has nothing!

So I thought about that problem and got following new idea:

Perhaps we really have to break the protection after all by burning! Burning of identic pattern is much more reliable than painting or sticking stuff onto the CD-Rs leadin region. With the knowledge and fitting software everybody with RAW-DAO-96 writer would be easily able beating the protection also without big affords!

By burning we have the chance for slowing down the PSXs CD speed, which still is essential important if we wanna paint the whole SCEx string into just one single revolution!

And I guess its very simple:

We just have to know from which indicators the PSX recognises the speedsettings for the motor. I’m almost shure the PSX uses the Lead-in subchannels at SCEx search, simply because there isnt anything else for orientation!

With Trumans great CD-analysing and burning program we already (at first time ever!) have the possibility in hands for burning whatever we like at the leadin track as good as completly RAW!

All we need to do is to burn a track with a different subcode “frequency”! Not every 2352 bytes, but as example every 1224 bytes!

2352 + 96 = 2448 (1 normal physical sector)
2448 / 2 = 1224 incl. 96 subcode

This must make the PSX spin at 1/2 CD speed and gives us whole 250 milli seconds scex painting time!

The PSX thinks its still on 1x speed, but the physical speed in fact really is 1/2! I’m shure the PSX must use the subchannel values for “speed-analysing” and setting because on pressed CDs there are no other indicators (like on CD-Rs its the ATIP wobble).

btw if the physical speed is slowed down, we have the chance the laser no longer can misinterpret the CD-R ATIP as wobble on signals!

I havent thought yet through the complete possibilitys of that new method, but eventually we even could create skips if the PSX already has slowed down the speed on a constant level, perhaps at 1/4 CD speed. So we eventually even could reach the range when the laser starts to interpret “sector” skips as wobble on-off pulses.

For the moment all we need is a 2448 form lead-in file binary and the possibility to delete all unwanted zeroes!

Better if we have a little program which deletes 1224! zeroed bytes (0x00) before every subchannel sequence. This will shift the remaining sector incl. subcodes into the formerly space of the zeroed 1224 place, and after deleting also the 1224 bytes of this next sector, we have exactly 2 recognised sectors at the space of the earlier just single sector. so on through the whole file.

This way we still have the correct numbered subcodes. But because manually thats an impossible big work to do, even by hexeditor with batchpossibilities, we urgently need a good idea or a little program for deleting those unwanted bytes after every subcode-sequence in the whole 30MB large binary! Best with changeable byte-deletion-input, if we wanna the speed like how we need it. The rest like burning then is very simple!

For the moment I havent the possibilities to code such program, but it shouldnt be that hard:
We need the open/load possibility of our Truman-Tool compatible 2448 RAW lead-in iso. Next a space for inputting the amount of bytes has to be deleted after every subcodes-sequence.
Now all what the program has to do is loading the original file into memory on the fly or complete nowadays, deletes the amount of (mostly zeroed) bytes we put into the prompt before or after the RAW subcode sequence, and saves the new file with slightly different name or extension.

I hope I’ll have the time, but for the moment I’m motivated for porting the modchip code over to the Goldwaver smartcard for making experiments with different SCEx input strings! I think I will solder my smart-card slot into the PSX, I always wanted to have a “smartcard” protected PSX! ;-)) If Im successful, we have another big access for tracking and checking out what the PSX hardware really does and how it reacts on different kinds of “interventions”!!

If somebody has info in programming the 16f84, compilers etc. please tell.

But first, much more important, I believe we need to make those tests with new “speedbreaking” Lead-in tracks!

finally I checked out the new leadin file format Trumans CD-Reader v1.2 beta creates:

  • The format is already 2448 RAW, which is already very good!

  • The Lead-in sectors do start with 00 FF FF FF FF FF FF FF FF FF FF 00
    followed by A7 46 50 02 etc. the identic 46 50 values also can be seen later in the deinterleaved subcodes of the same sector; this remains so and just raises in each following sector by value plus 1 (46 51, 46 52, 46 53 etc)

This means, the 1224 bytes deletion process must happen after that:
00 FF FF FF FF FF FF FF FF FF FF 00 A7 46 50 02 etc. string.

  • The subcodes of the RAW 2448 leadin file are created in 1.2 beta8 always! in deinterleaved form, no matter if option: deinterleave subs is switched on or off. This only affects the data area subcodes.

Now the big question whats better - use “RAW” interleaved subs at the leadin.2448.iso or let Trumans CD-Reader parse deinterleaved subs through the writer?! I suggest we use the “original” interleaved subcode form at the leadin, because otherwise it can became to irritating for the software and could interprets our special compressed “sector” formats subchannel as data bytes. What do you think, Truman? If we really wanna edit the leadin subcodes in a very new form we need a special software for that anyway, so it doesnt matter for the moment in what form we can see them.

btw a little “bug?” feedback:
I found out: It wasnt possible to “read CD to image file” with my Samsung DVD drive if the >generate full lead-in/out< option was set to on! With the Liteon it was no problem. It seems the program sends some kind of special command to the drive, but if theres no “Liteon” reaction it aborts the whole process! Now I wonder why this happens, because the lead-in ISO is written by software and the values like lenght or leadin format gets manually inputted. So what the heck the program wants to know before generating leadin.iso and doesnt get and then halts the complete process?

I write this, because it would be much better if we can circumvent that “Liteon limitation”, so alot more drives are supported for the complete “CD to image file Job” incl. Leadin generation. Just as info, because first I thought already the CD to image file wont work at all. Would be great if you could bypass that limitations. thx.

CU, Sam

It maybe a long shot, but you can ask “Aaron Giles” he invented the PSX emulator CVGS for PC & MAC.

All I know is nowadays his hobby is cracking the CHD image protections for use in the MAME project - it couldn’t hurt to ask him.

His CVGS patent is:

@sam, great you found some more bugs. I think the Samsung DVD doesn’t support MMC read full toc command. I will add the ability to use normal read toc command for the leadin generator in the next version. I’ll also fix interleave option and also allow it for writing. Can you confirm a test for me? In TOC viewer is it able to read the TOC of a CD?

About the leadin generation, it isn’t fully generated by software. It needs the user entered info + information read by the TOC command. All those info within the table you see in ‘TOC viewer’ are needed to build the RAW 2448 byte TOC.

@djmcclintick. Good to have someone from inside on board. I would like to ask some questions:

  1. Does the backup CDR boot on normal PSX (without modifications of course) - I mean you have special ones and these don’t count.
  2. If yes to above, are the CDRs special or just off the shelf like what we have. It’s conceivable that they use special CDRs with special ATIP wobble at the beginning of the disk.
  3. What is ACSINE - is it part of the SCEx protection? I mean the only obstacle we can’t pass is this SCEx - all others are copiable.

Yes, the v1.2beta8’s View CD TOC window works with the
DVD drive @ pressed PC Game CD:

2:0:0 / SAMSUNG / DVD-ROM SD-608 / BT01
including read ISRC [yes] (works), read CD mode [yes] (works); (MCN wasnt encoded)

Read ATIP didnt worked, same with CD-R.

Suggestion for the leadin 2448 ISO creation:
Is it possible to split and merge that 2448 structured file into at least one part which is 2352 (perhaps you could include a little program directly?)
This would have the advantage, that we could build in either data or wav files into the leadin.
If the whole TOC info is coded into the subchannels, the data area could be used anyway (are the leadin sector headers very important or can we substitute them with data sector headers?)
However, 2448 ISO files are very hard to edit, especially if we wanna experiment with special leadin layouts.

Its great you support us!! thx!

I have the same questions like Truman… :wink:

Please tell us more about that burning software topic.

Did you mention that CD-DVD-Generator 1.20 (1.30) which perhaps had been compiled secretly for other CD-writer brands too?
Do you work with the glass-fathers at the “add protection machines”?
As you know, we wanna try methods >X<porting that SCEx wobble protection onto CD-R.
That technique has nothing to do with cloning the PSX CDs data area apap. (as perfect as possible)

Anyway, its super you found us and you joined our developments.

CU, Sam

@djmcclintick, sorry to say this but you’ve made a mistake with SR_CDW.exe. It is a program for creating a firmware CDR only. The hex files you sent me are the firmware files for the copy station enclosure - not for the rewriters.

The CDR is then for updating the firmware of the ‘HOEI SANGYO Co.,Ltd.’ copy stations. A copy station is an enclosed case of cd rewriters/dvd rewriters and has it’s own controller with firmware.

Someone already tried cdvdgen/cdvdrec and it didn’t make a working bootable CDR (without modchip).

I think the situation is like this, these programs are for the developers for taking their files to build a CDR that conforms to PSX standard layout (CDROM MODE2 XA data format wise) CDR, which you can then send to sony duplication centres for producing real PSX CDs. The centre most likely makes a copy of the CDR onto another CDR (one which has special SCEX track). Also to be more flexible, the developers are given a special PSX console (so called special blue PSX) that has the country code protection disabled for testing - equivalent to a modchip version.

Are u misleading us???

Or you are keeping some thing secret from us?

@sam, I noticed the program is already too complicated (interface wise), I think I’ll make a separate program to split/merge 2448 byte file.

OK. I didn’t meant it in that way. Its just that we heard a lot claims by people, but none has shown evidence.

I’m not saying I don’t beleive - maybe its just some bytes written in the normal way to create those SCEx codes. But listen…

Its very difficult to believe when we already have evidence from Sam and osc results of error tracking coils. So you see, the burners with our using MMC commands can’t create tracking errors.

Originally posted by djmcclintick

there is no pressed discs sony buys the BLUE BOOK CDR from a manufacturer that makes memorex BLUE BOOK CDR so i think people need to do a little reaserch on what the differences are because there is a difference in blue book,red book,black book, and silver so it is not my fault if someone cannot us the right media.

‘Blue book’ refers to CD-Extra discs (Audio+Data), commonly referred to as “enhanced CD’s”. It is nonsensical that Sony purchase ‘blue book CDR’ as the actual disc is the same as any other blank CDR.

A disc can only be referred to as being ‘blue book’ after it has had data and audio written to it.

At least, AFAIK :cool:

Not trying to be argumentative - just wanted to clear up any misconception other readers of this thread may have…

If it’s true about special firmware, editing the program will not help. The special commands (if any) will only work on those burners with special firmware.

Anyway, using ‘Spying on ASPI traffic’ article from

For educational purposes only (and it’s not a crack)…

I made a modified version that will compile under Visual Studio 7/VS C++. It intercepts the SCSI device inquiry command and modifies the strings so that a LiteOn drive will appear to be a Sony CDU920S. The dll is named iqaspi32.dll.

I tried it and the cdvdrec v1.20 program does not complain about no devices anymore. But it still has the device combo list inactive. Apparently it is also checking for something else.

If anyone wishes to download it:

**Note: Please abide by the CD Freaks forum regulations. We cannot discuss about modifying exe programs. So please don’t ask me how to edit exe program to make this work.

Using PE Explorer I noticed some features within CD/DVDGen that are not easily accessible. When setting the file type, there is SubHeader XA and STR (PS1), When changing File#, an option to keep SubHeader, Test Dialog 1+2 +3 with “Checks, Static, Radio” and Target PS1 or PS2. How does one “unlock” these options? Also what excactly is the “AddOn” tool for cdvdrec?

Resource Hacker is a slighty better (in my opinion) FreeWare EXE,Dll editor wich gives more info than what PE Explorer does
(See screenshot “system area file”)

i played with cdvdgen,cdvdrec,and master disc checker

ive tested them on 6 diff cdroms/burners

i used an old sony cd rom (cdu311) didnt work with mdcheck or cdvdrec

i used a “hypermedia” burner also didnot work with either prog

i used a generic cd rom also didnt work

i used a plextor burner and mdcheck works!
i used a sont dvd-/+r/rw burner and it works too.

i used a generic dvd rom and neither worked

cdvdrec doesnt seem to work with any

i checked a real(pressed)psx ps2cd and ps2 disc and it said it wasnt a master on all of them

im tryin to find one of those old ass burners that the program was supposedly made for.

hope this helps

ill let u guys know if i fugure out how or if i get any breaking news

see ya

I’m kinda a n00b when it comes to all this, i just recently started reading all these kind of forums on this psx protection stuff, and i’ve sorta been taking it all in and i find it very intriguing and would like to learn more about it its almost becoming an obsession and i want to contribute to the effort to solve the puzzle. ~peace~

well i tested out diff things and no success

they had an old sony cdu920s on ebay but someone outbid me:a

owell anyways untill i get one of the required burners im not gonna mess wit it anymore. appearantly this site does sell suplicators to developers in japan. i dont know why they would make this up.

as for burning games on any burner well as all of u know it basically wont work unless u can decrypt the scex code on the disc which only a select few burners can do(with the right firmware) .

unless u can get special software that can change the burner so it can decode the scex code… if thats even possible. just an idea

the reason i think its possible is because my friend was able to get an old cdrom to read an unfinalized multisession disc. and btw it couldnt b4.

well hope this helps
keep up the good work sam

oh and if … when i get into the s*ny site that has the info we need ill let u all know the secret.

“The page cannot be found”

Intresting Site djmcclintick

This doc has refrences to alot of the equipment on that site
plus some other usefull info


hmm, strange

seems ok now,

btw, nice to see that youre all still highly motivated (been a while since i visted the board)


Yep working now.
Downloading the doc.

I found (I think I found…):slight_smile: that
psx laser block (16 lines) has one extra line for which I suspect that is a 7th photo-diode G (besides A,B,C,D,E,F) which reads
that famous wobble,not the E-F photo-diode pair…

Thoughts on that?


Yes - there is an extra photo diode in PSX laser unit.

It is used to read wobble in


in the later models namely


The wobble is read from the error signal of the DSP.

This extra photo diode is on pin 5 of the laser ribbon. It is still present on later models - just unused.

If you look at some of the photos of my frankenstein 7002 you will see pin 5 lifted so I could more easily inject the different amplitude/freq signals to test the parameters of the AM demodulator.