PlayStation Development Network

I saw in no$cash’s CD documentation some interesting things that gave me an idea to attain arbitrary code execution on the Mechacon.

19h,74h,index,len,databytes --> INT3(stat) ;Write multiple registers (bugged)

Same as read/write single register, but trying to transfer multiple registers at once. BUG: The transfer should range from 00h to len-1, but the loop counter is left uninitialized (set to X=48h aka "command number 19h-minus-1-mul-2" instead of X=00h). Causing to the function to read/write garbage at index 48h..FFh, it does then wrap to 00h and do the correct intended transfer, but the preceeding bugged part may have smashed RAM or I/O ports.

In the memory map, 0000-003F are I/O ports and 0040-023F are RAM. The stack is 00C0-00FF. Could we use command 19 74 to blow away the stack and overwrite some return address with a pointer to memory that we control? We can write to RAM in 01E1-023F by using too many parameter bytes; this could be used to upload a payload.

I haven’t looked at a disassembly of the Mechacon to see whether this would work. It’s also been 20 years since I’ve had the tools to compile and execute PS1 code to try something like this out.

This would only work on vC1 and later.

Never mind; my mistake here was that the documentation is referring to DSP registers, not 68HC05 registers at 0000-003F.

The idea of ??exploiting the multiple register writes in instructions 19h,74h is very creative — if you can control the data written to the stack to overwrite the return address,Retro Bowl make sure you clearly define a safe RAM area to place the payload in, and carefully test the wrap-around behavior to avoid crashing the system too early.

Ariel19 wrote: ↑May 5th, 2025, 2:08 pm The idea of ??exploiting the multiple register writes in instructions 19h,74h is very creative — if you can control the data written to the stack to overwrite the return address,Retro Bowl make sure you clearly define a safe RAM area to place the payload in, and carefully test the wrap-around behavior to avoid crashing the system too early.

Since I misinterpreted the 19 74 command's nocash documentation, I don't think it's possible to do that, but I'll look it over again.

I did find some "interesting" code in the table of contents parser. The routine has bugs in it that cause memory overwrites, but so far I haven't seen anything useful that could be done with it.

Specifically, the handler for the sub-Q codes in lead-in--the table of contents--has bad handling of some TOC data:

• Track numbers have to be less than 0xA0, but there's nothing stopping using 0x9A...0x9F. When these illegal track numbers are in the TOC, it causes an overwrite of RAM addresses past the end of the TOC. This allows a disk to potentially cause arbitrary overwrites of RAM bytes 0x01C6-0x01D1 through its track minute and second values. If we could've overwritten 0x01D5 with the value 0x07, I think that would've allowed making self-booting CD-Rs, but alas, 0x01D1 is as far as we can go.
• An illegal track number of 0x00 causes an integer underflow; in this case, the minute and second values get written to 0x01FE and 0x01FF.
• Illegal track numbers 0xYA-0xYF for Y = 0...8 work but just overlap memory addresses of normal tracks.
• Using a bad 0xA0 point (first track number) or 0xA1 point (last track number) can cause the code to zero 0x01C6-0x01FF due to underflow or overflow.

I'd really love a dump of the SPC970 PS2 Mechacons to see what it'd do with a corrupted CD TOC, but so far getting dumps of those is elusive. Dragon (ARM7TDMI) PS2 Mechacons seem to validate this, but Dragons already have arbitrary code execution exploits ("MechaPwn").