Using this URL's disk, http://forum.redump.org/topic/4991/...psx-bios-directly-on-console-control-cd-unit/ , I found that undocumented command 0x19 sub command 0x60 means "read byte of CD controller RAM". On my SCPH-7501 (modded), I got the following results: 19 60 D0 01 -> 53 19 60 D1 01 -> 43 19 60 D2 01 -> 45 19 60 D3 01 -> 41 53 43 45 41 = "SCEA". It isn't being cleared by 19 05, though, so maybe it's the actual string returned by the drive as it's being constructed. 19 60 returns a single byte of RAM at the specified address. The address is 16-bit, represented in the command as little-endian. The address space appears to wrap mod 0x0400. I don't see ROM anywhere. Another address I found is 0x01E0, which contains the command the R3000 just executed. If you read 0x01E0-0x01E3, you get the bytes 19 60 E2 01. (Think about why E2, hehe.)
Looks like you're having fun with this tool Have a look at the guy's webpage, there are also interesting stuff
Yeah, his description of the Saturn protection was pretty crazy. He seems to know a lot about CD-ROM, far more than me =) It's too bad that the PS1 CD controller's command set is probably too simple to have an exploitable bug in it. I didn't find anything in the test command set that could *write* the controller's RAM. Also, I think that the 19 60 command is intentionally masking the address by 0xFC00 just so that you can't use it to dump the controller's firmware. The 0x0400 bytes repeat for the whole 64k space accessible with that command. I think PS2's Mechacon is more interesting, though. It has a lot more commands than the PS1 CD controller. It would be quite hilarious to find an exploit to get inside its address space. MagicGate would be understood completely, for one thing. Also, Free McBoot could be turned into an import loader. There is precedent for abusing RAM overwrite exploits in order to break into the optical disk controller's address space: that's how GameCube and Wii drivechips work.
Anyone who knows a little about how the PlayStation2 works are sure it goes through the Mechanics Controller. Yes. Also, that's why the PS3 isolated SPU module was called me_iso_module ... (mechacon isolated module)
I suppose it was cheaper and safer for them to "isolate" all the security inside of a SoC type of chip. The BIOS rely on the mecha for anything security related.
Since that isoself file is easily decrypted these days, is there anything interesting that can be learned from the PS3's Mechacon Emulator?
As for working with the PS2's mechacon, would brute forcing commands help at all? Or maybe decapping and scanning the chip?
Possibly either one =) Or, at the software level, trying things like messing with the parameters to DMA and MagicGate requests, like passing invalid offsets and sizes. Basically fuzzing. =)
