Idea for getting ACE on Mechacon

[Myria]

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.

[Myria]

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

[Myria]

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

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").

[MottZilla]

That would be quite a discovery if you could gain some control over the cd controller and do something useful to it with a burned disc. I suppose if you wanted a disc that booted you'd need to somehow write the memory so the disc would appear as "licensed" as while setting the unlocked state is nice the Shell program still wouldn't let the disc boot.

When you say writing 0x01D5 with the value 0x07 would make self booting CD-Rs, why do you say that?

If I recall, 09Fh is the Unlocked State, so that is not in that range. But where is the licensed/not licensed state stored? Definitely share whatever you might discover.

Edit: I poked around to refresh my memory. So if you could manage to write to 090h, you could perhaps clear the top bit so the disc would no longer be identified as unlicensed. Infact if there was a test command that allowed poking the memory from the MIPS side that would be pretty awesome. Sadly you can only read it though. Test Command 60h lets you read but according to No$PSX documentation there is no write command.