Now Playing: Sun Devoured Earth
Topic: PSX PS1 PS
Shattered Memories / History of Violence
Following is an compilation from numerous posts i made @redump.org concerning PSX dating from 2008 till 2011, which i tried, to best of my abilities, dress in somewhat coherent narration. The thing is, i did some interesting stuff during last few years, but it's all scattered across this electronic wasteland. I kinda do regreat it now, should have noted those things in one place. So, what i'll do now, i will try to bring it over here, what i still remember, and write guides and shit. Reason behind this is - currently i'm working on some PSX JPN->ENG translations, a project of a sort. You'll see. I just wanted to give a kind of a background to that - how things got started and what could be interesting to other people relating to those translations.
I was messing around Saturn's protection at that time but weren't really interested that much in this system itself. And so, as time passes, i realize, that i actually know little about PSX, which on the other hand i used and liked a lot. Even though this was the system that startet redump.org and we worked with it for quite some time there still were many questions left without answers. So i started looking for information on it and eventually stumbled into this thread, where some of redump.org members were dumping and cataloguing PSX BIOSes, which was neat, i though. But i didn't have hardware to do this, and was low on cash then. But thing is, i was really into CRCs, since i was doing algorithm reversing on LiteOn's firmware (i'll probably write a guide on CRC reversing too, sometime, when i'll take a break from those translations). So, even though i haven't previously done any programming for consoles, i was programming in assembler and thought maybe i could write a program that would just calculate CRCs on the flight, without a necessity to physically transfer BIOS to PC. And so i did. I found SDK and some guides and i did. But what i also found was this, this and this. CDINFO.TXT described undocumented service commands one can access in PSX CD unit. And that was so interesting i hand to try it, so i expanded this PSX program to have ability to send those commands.
3rd page (Japanese) was for relatively new PSX emulator XEBRA, where it's author Dr.Hell would document results of his research. Now, with this program i could test PSX CD unit on quite low level and compare results between hardware & emulators. And what i noticed was, how XEBRA was different from rest of the emulators. It acts really close to hardware, whereas usually emulators would go for simplest solution, e.g. just return some constants and such - skipping a lot of processing. And i thought at first this was issue with plugins. So i decide to make my own CD plugin. And i did. Though, i had quite some plans for it, but as i made it, i came to understanding how limited those plugins really are. Issue was with emulator architecture. They are hackish - made of shortcuts - layers upon layers of shortcuts. And with this realization i lost interest in developing it further. I did quite a lot of fine-tuning for it, though, and it might be, it's the best for certain situations: it's the only one that works with physical drives connected to my motherboard (IDE2USB); overall catching strategy is good, comparable to cdrsapu and it gave best results reading scratched CDs on PCs i tested. So, you could give it a try, maybe, if you use plugin-based emulators. What i would suggest, though, is: stick with XEBRA. It's the best PSX emulator there is, hands down.
What i did with this plugin, though, since i could recompile it as i liked, i made it so it would ease examination of LibCrypt protected titles. I disassembled / modified them and ran through this plugin to log certain routines. And what i found was, how this protection really works. It turns out actual subchannel content doesn't matter at all - it can't even be read fully. There just have to be error in frame, so it would get replaced with previous frame - that's how this system is built. Always same 16 pairs of addresses are read. From those pairs 16bit key is formed. If both frames from pair are moded, bit is set.
Reading sector 13955... original sector \ bitF = 0
Reading sector 13960... original sector /
Reading sector 14081... original sector \ bitE = 0
Reading sector 14086... original sector /
Reading sector 14335... LibCrypt, LC1 sector \ bitD = 1
Reading sector 14340... LibCrypt, LC1 sector /
Reading sector 14429... LibCrypt, LC1 sector \ bitC = 1
Reading sector 14434... LibCrypt, LC1 sector /
Reading sector 14499... LibCrypt, LC1 sector \ bitB = 1
Reading sector 14504... LibCrypt, LC1 sector /
Reading sector 14749... original sector \ bitA = 0
Reading sector 14754... original sector /
Reading sector 14906... LibCrypt, LC1 sector \ 1
Reading sector 14911... LibCrypt, LC1 sector /
Reading sector 14980... original sector \ 0
Reading sector 14985... original sector /
Reading sector 15092... original sector \ 0
Reading sector 15097... original sector /
Reading sector 15162... LibCrypt, LC1 sector \ 1
Reading sector 15167... LibCrypt, LC1 sector /
Reading sector 15228... LibCrypt, LC1 sector \ 1
Reading sector 15233... LibCrypt, LC1 sector /
Reading sector 15478... original sector \ 0
Reading sector 15483... unknown /
Reading sector 15769... LibCrypt, LC1 sector \ 1
Reading sector 15774... LibCrypt, LC1 sector /
Reading sector 15881... LibCrypt, LC1 sector \ 1
Reading sector 15886... LibCrypt, LC1 sector /
Reading sector 15951... original sector \ 0
Reading sector 15956... original sector /
Reading sector 16017... original sector \ bit0 = 0
Reading sector 16022... original sector /
So for given example key would be: 0011 1010 0110 1100 = 0x3a6c (it's PAL 'Dino Crisis' btw). Also it's pretty easy to derive those values from redump.org DB: those kept would be ones and missing sectors would be 0, e.g. it's cec1 for 'Ape Escape', 89ea for 'Mulan', 096f for 'Speed Freaks', e728 - 'Crash Bash', 90af - 'Italian Job', and so on.
Also it became apperant that there is a problem with .sbi files. They work but this format, it's clumsy - not thought out well. They store only part of Q channel frame. So it's not good for preservation. Data gets lost in DB to .sbi file transfer.
Another interesting thing to note is that some anti-mod chip protections would branch depending on console region. For example this routine checks letter @ BIOS offset 0x7ff52 and bails out from following checks if it's 'E' (Europe).
It's curious. Haven't explored it further though.