The above video goes away if you are a member and logged in, so log in now!
PS2 Disc Security explanations?
PS2 Disc Security explanations? –
Hello, I'm curious on primarily the differences between the PS2 disc security compared to psx, and how that difference is related to the standard modchips we see, with a DVD controller hack, a bios hack, and SCEX signal input.
I don't have an extremely technical understanding of optical disc technology, but my understanding is that the PSX discs contain data in the wobble area that standard cd drives can't read. The psx decodes this information as a string of 4 characters, "S,C,E,A" for ntsc US, for instance. A psx modchip inputs this signal. For instance, a simple 4 wire mod consists of a wire for ground, power, SCEX input, and the final wire blocks the real result being read from the disc. For instance, a copy or import would not return "S,C,E,A".
Now, the PS2 is obviously more complicated. Not only is a simple 4, or 8 for that matter, wire mod sufficient, we also have two kinds of optical discs with apparently different security features. However, both systems have had pressed boot discs created by various sources. Of course there is Datel, who produced bootable psx, ps2 cd and dvd. Then there are companies like success (I realize there's probably a good deal of dislike towards them here. I understand why, but trying not to focus on that aspect of them if possible) who seem to have stolen the methods directly from datel. For instance, they seem to use crazy taxi for ps2 cdr, or at least they did.
I've heard it said that the PS2 protection differs from PSX in that different discs have different data in the usually unreadable sectors of the disc. It was said that the boot data is dependant on the SLxS (elf) filename on the disc. No more information was provided. But, it would make sense of the fact that the crazy taxi slus number was reused by datel a number of times, and even success. There's the theory that maybe it would help prevent the blocking of that specific title, but why not use a different SLUS shared by sony in that case?
(There was once a website up with images of the gameshark disc as it was worn down, showing the splicing of the boot sector area and the normal disc. This website disappeared quickly, and I've never seen it since. Anyone got a mirror?)
So, where do the modchips come in to play? I've browsed through the ICE source, and grasped a bit of it, but I'm no asm expert. There are read routines manipulated by bios patching, and control of so much of the boot process. And of course its clear where the SCEx data is determined and sent.
But what about the DVD controller? That seems to be where the action is at. After all, there was never the booting of an import or direct booting of a dvdr before origa came up with the dvd controller code. For so long it seemed to just be ripped right from them. But by this point there is clearly understanding, and replication of the coding itself. If I recall the ICE code, a block of data (hexidecimal in the code, I believe) is sent to the dvd controller. The only faint guess my noninformed mind can come up with is that if indeed the elf filename issue is true, the controller is sent this same block of code no matter what the disc, and the bios patching will ensure that it succeeds despite the differences of the file name on the disc.
I had a conversation with raptor quite a few years back, when the neo4 was just starting to fade out. He explained the neo4 boot process (and reason for it not working with dvd-r discs) as a process which via bios patching tricked the ps2 into authenticating a ps2 cdr in the way that it would authenticate a psx cdr. So, the SCEx input should qualify if this is true. The evidence he offered of this fact was that the ps2 browser would show a black disc if you inserted a ps2 cdr. I couldn't verify this, as I sold my neo4 before installing it.... for a messiah. (which surprisingly works to this day... I should upgrade though).
And finally: Why on earth does (or did, in the early days at least) a constant stream of SCEx input allow the disc tray to be ejected without a complete disc security check when the next disc is inserted??? The old neo2 swap trick, is what I'm asking about. Whatever this more elaborate data on ps2 discs (as opposed to psx discs) seems to be needed only to boot into ps2 mode that first single time. After that, (unless a media type change occurs) they don't bother checking this mysterious elite security, and only look for the simple string known to the "public" for years.
Sorry for all the questions and possible informational errors. Just trying to make some sense of this old system before it reaches farther into its golden years.
way over my head, but I would be interested to know as well. i didn't even know about the wobble area
Hmmm... seems no one really knows around here. Not surprised, they're not easily answered hehe. Figured maybe one of the few people with such knowledge would happen by. Anyone know of another place with perhaps better luck in which I could ask?
This is more or less how it was explained to me (the guy who explained this to me has an account here but I don't know how often he visits). This is also from memory so I could be messing some things up:
- PS2 and PSX both use the same basic "wobble code" scheme, from a physical standpoint
- PS2 games contain the "PlayStation 2" logo you see at boot in an encrypted form (in the standard bootstrap area I think, but not sure)
- The key to decrypt this is stored in the "wobble code area", itself encrypted with a key generated from the product number (SLUS/SLES/SLPS number) which is encoded into the name of the boot ELF.
- The mechacon can't readily distinguish between CD-R and CD-ROM, but can distinguish among the various types of DVD media
So when booting a PSX game, all you have to do is inject the appropriate SCEX stream into the wobble decoder output, and you're done. With a PS2 game, you have to:
- Inject SCEX into the wobble decoder output (wobble decoder output; only needed for CD?)
- Patch the media type reported by the mechacon (mechacon bus; only needed for DVD)
- Bypass/fix the logo decryption process (BIOS; needed for PS2 games but not PSX)
Chips such as the Neo2 only inject the SCEX stream and open/close the tray; the media type and logo decoding is bypassed by using the real thing.
In other words, to have a non-swap solution you have to patch three different processes implemented in three different chips. This is why mods suddenly went from 6 wires to 20+ wires.
I've only skimmed some sources, so I can't directly vouch for the details of the above process, but it does explain several things that had puzzled me, such as:
- As you mention, virtually all unauthorized PS2 CDs use the product number for Crazy Taxi, presumably because the encrypted key/logo data used was originally ripped directly from a Crazy Taxi disc and used as-is.
- Some of the less polished modchips caused a corrupted PS2 logo at boot.
- The discrepancies between PSX/PS2 mode support and CD/DVD support in various chips.
- There's a version of the Ice code that requires no mechacon connections, but can't boot DVD copies.
As for why the full authentication is not done on a disc swap, it's probably because the mechacon can't decrypt the logo on its own (lack of program space and/or processing power perhaps).
Great post. Flaws or not, it helps make things quite a bit clearer.
I do vaguely recall the logo patching tool requiring the elf filename. So, the same image would be different data on two discs with different SLxS filenames?
I'll have to take a look at the ice code with the logo stuff in mind. I really hadn't even considered it as being anything important. I remember patching PSX logos, and figured it was simillar. The first patched logos I've seen on either system were Paradox ones, when using a trainer, etc. In fact, when the ps2 first came out, paradox had a patcher to use UT or gameshark. It would be another year until we'd see direct bootup (and hence the boot image). When I got my messiah, I put the paradox patched game in, and saw their logo instead of Playstation 2. Heh, they knew no one would see it booting with a gameshark, but they put it in anyway, having obviously used dev hardware to view it.
It must be a relatively simple encryption if it is done by all mods and these patching programs.
This makes sense. So, the origa patched the disc details, simillarly to a modded 360 reporting the wrong disc type back to the console. It told the system, "hey, this here is a japanese disc", or whatever. So, the origa surely had an scex wire? Didn't remember that.
And yes, the gameshark hack worked because none of the logo stuff mattered after the initial booting.
"- Some of the less polished modchips caused a corrupted PS2 logo at boot."
Perhaps instead of correctly working out the encryption algorithm to be compatible with any disc, they simply patched the bios to make the ps2 satisfied with any result? So, you get either garbage on the screen, or perhaps the actual encrypted image.
And my final mystery: Does anyone have any understanding of how the FFXI harddrive patches the system? I have a messiah, and when booting with the HD in, it (after taking about 8 seconds longer to boot) patches my console to act as if it were retail, not booting DVD-R or CD-R games. It clearly loads up a different dashboard as well, which is capable of showing the hdd memory. So, does it essentially load up a new bios from the harddrive? Has this been looked into for exploitability? As in, custom ROM on the harddrive that is actually loaded up instead of the system rom? PSX copies work, so it's probably just the bios indeed. Running an original import would probably further confirm this.
I also have a little trick to boot ps2 CD-R discs for when I want to use ps2link, and am too lazy to unscrew the network adapter and remove the harddrive. All you need to do is boot up a psx game. the blue screen comes in, and it zooms in and fades away as normal. Right after this (and before it would give the PSX logo) you press eject. If timed properly, you'll end up at the unpatched dashboard, with the HD having not been initialized. This is because it was ejected after the disc was recognized as PS1 (which obviously requires no HD use) but before the psx exe could be loaded up. At this time you can put any copy in, and it will be recognized.
And yes, I realize the simpler method: Stop using that modchip made almost 5 years ago!
PS1 protection(SCEx) does use the wobble, PS2 does not. This can be verified by injecting the SCEx signal while a PS2 original is being authenticated. If both used the wobble, the SCEx signal would interfere with the disc authentication or authenticate the disc as PS1, but it doesn't. How the key *is* actually encoded in the disc, I don't know.
The logo stuff is similar in PS1 and PS2. The logo is embedded in the first 16 sectors of the disc. For PS2, it's also encrypted using a combination of "Rotate Left 5" and XOR of the 5th byte of the key with each byte of the logo. Since backups do not contain key information(and mods can't truly inject the key data) the decryption will fail to generate the true logo. Once decrypted, a checksum is performed on the data. For US consoles, the checksum is ignored. For E/J consoles, if the sums don't match, the disc will not be booted. Some mods simply patch the checksum comparison. Other mods guess the 5th byte of the key based on the fact that the first byte(pixel) of the logo is always black(0x00). 0x00 XOR key5 = key5. Thus a small patch can be applied which performs the actual XOR decryption.
Origa did have an SCEx wire.
Here's a little bit of C(semi-pseudo) to show how the decryption patches work:
assuming key5 is an 8-bit integer and that logo is an array of "n_bytes" 8-bit integers...
key5 = logo;
for(i = 0; i < n_bytes; i++)
logo[i] ^= key5;
"If both used the wobble, the SCEx signal would interfere with the disc authentication or authenticate the disc as PS1"
Doesn't it though? I don't think it will attempt to boot it as a ps1 game unless the system.cnf suggests to do so, but it will interfere with the booting, right? I recall the neokey (the most 'senseless' of all scex injecting ps2 mods) needed to be removed from the usb port when booting the gameshark, but inserted after the gameshark boots.
I'm again confused as to why the SCEx signal allows ejecting with the gameshark, though, without complete authentication, while obviously without an SCEx signal, it will do the complete check.
Bad SCEx generation can cause inteference with reading of the actual disc which is why that neokey crap needed to be removed.
Originally Posted by ebob
The system software determines disc type based solely on the "disk type" the CD/DVD hardware says the disc is. "autoboot" mods work by determining the disc type based on contents(if the disc has no SYSTEM.CNF, it's assumed DVD movie. if it has system.cnf and that contains a "BOOT2 =" line, assume PS2 else PS1.
I don't understand what you mean there...
Originally Posted by ebob
I'm speaking of the neo2 generation mods, or the neokey crap for that matter.
If you boot up a gameshark, and eject the disc (without a modded system) and put your copy in, the system will attempt to authenticate the disc, and fail. And, in the case of a dvd-r, fail a media type check as well it seems.
But, sending copious amounts of constant SCEx signal into the ps2, an eject can be performed, and the next disc loaded in no problem. Even the LBA limitation of the gameshark doesn't matter, unlike a modless swap trick. The media type check seems to be performed as well, as in order to boot a dvd-r, one needs to put in a dvd by pressing eject and inserting an original (large capacity) dvd, and using a forced eject method to open the drive without the ps2 knowing.
Basically I'm just wondering why the SCEx signal, of all things, is allowing this magic to happen. Is it just like you said? "Bad SCEx generation can cause inteference with reading of the actual disc..." Does the system just get garbage in response, and not qualify it as a failed authentication?
Obviously, once the noswap mods came around, no one used the gameshark/neo2 combination on new consoles. Would it even be possible on the later ps2's? People seem to spend money on fliptop crap, but if I were going to swap, I'd prefer a proper eject, and a ridiculously easy-to-install modchip to a fugly cheap plastic case.
aaaahhh, ok now I get what you mean and the answer is kinda simple.
Since the OSDSYS "browser" software needs to be able to access PS1 and PS2 discs for reading to parse the SYSTEM.CNF file and determine the BOOT file the CD/DVD hardware will allow you to perform all the same commands on a PS1 disc as you can on a PS2 disc. What the Neo chips did was to authenticate PS2 CD games as PS1 discs. So you'd eject the disc and insert your CD backup. The chip sends the SCEx signal and causes the CD/DVD hardware to authenticate as a PS1 disc. GS/AR assumed that the disc inserted was PS2 regardless of the disc type. As long as the disc authenticates, AR can read it and boot it. The dreaded "EA protection" in some games was the game itself checking what type of disc was inserted in the drive. Since the disc was authenticated as PS1 CD, if the game expected PS2 CD/DVD it would choke. And regarding the LBA thing, this doesn't apply since you're letting the PS2 see that the disc was ejected so it will redetect the media and LBAs and such.
Now about DVD.. The CD/DVD hardware seems to be smart enough to know that there is no such thing as an official PS1 DVD. It will NOT allow you to authenticate a DVD disc as PS1, it ignores the SCEx signal when DVD medias are inserted. That was why you had to use a lame eject thing for DVD discs.
The DVD-R check was introduced in v8. It's a check done by the Mechacon(one of the 2 main CD/DVD ICs) where it will forbid the disc if the "Book Type" is different than DVD-ROM. Chips work around this by forcing all DVD medias to return a DVD-ROM booktype. You can actually get around the need to connect the additional wires needed for patching booktype by using medias that you can "bitset" to DVD-ROM booktype such as DVD+R and DVD+RW and doing so when burning the disc.