Free mcboot ps2 download iso

Changelog for FMCB v1. Added button hints to FSCK. Changelog for the installer v0. Once again, all files in the BOOT folder will be copied. Removed unused file flag bits. Added new Portuguese, French and Spanish localizations.

Button legend will be dynamically positioned, to cater for the varying lengths of labels in various languages. Users can now cancel at the memory card selection and installation type screens. Last edited: May 21, Skippyz , Apr 7, Last edited: May 3, You must log in or sign up to reply here. Show Ignored Content. Share This Page Tweet. New Posts dump. Latest: littlebalup, Nov 22, at PM. General PS3 Discussion. XMB Modifications.

PS3 4. Latest: alexparrado, Nov 22, at PM. Any solution for the weird ps3 controller sync issue? Latest: solomonbyte, Nov 22, at PM. From searching calls to this, we can also quickly find wrappers that fetch data of larger sizes: getDiscU16 0x25c , getDiscU32 0x25c9b8 , and getDiscData 0x25c9f0 , which is the most interesting as it reads an arbitrary length of data:.

The first thing I did was search for calls to getDiscData in the hope of finding one with controllable size, and no bounds checking. Sure enough, we very quickly identify about 4 blatant buffer overflow vulnerabilities of this nature. Relating back to the IFO file format, we can see that there are numerous bit array lengths which are needed to parse the variably sized data structures in the file.

The DVD player mistakenly only ever expects the maximum lengths allowed by the DVD specification, and so it is missing checks to reject discs with larger lengths.

Since all of the copies are done on statically allocated memory buffers, specifying larger than allowed lengths will cause buffer overflows. For example, below is decompilation for the one at 0x25b3bc :.

As you can see, we can control quite a large region of memory using the above vulnerability. However, scanning through that memory is initially very disappointing; there are very few pointers, and none of them look particularly interesting to corrupt!

Although there are no interesting pointers in this region, there are some indexes, which if corrupted could lead to further out of bounds memory corruption. Note that large reads like this won't always copy contiguous data from the IFO file, as sectors will start repeating once we exceed the file size, but generally assume that all data written by a getDiscData call can be controlled as it originates from somewhere on the disc.

Also, after writing a certain amount, we may overflow into internal state used by getDiscByte functions, but we will get to this later. At 0x25e we have this call to an entry in a function pointer array, where we can control the bit fpIndex at 0xa from the overflow:. This primitive is not quite ideal, as none of our overflow bugs allow us to control the memory where the jump targets are read from.

Worse still, most of this memory region is mapped from a read-only section of the DVD Player, so it's unlikely that we can influence the contents of this memory region without another bug. After the function pointers, we do some see some addresses for switch case labels, which is slightly interesting because that allows us to jump into the middle of a function and execute its epilogue without having executed its prologue, allowing us to misalign the stack pointer and return to an unexpected value on the stack.

I went through all of these and unfortunately I was only ever able to use that to jump to 0. Finally after the code pointers, we see read only string data.

Interestingly, this data can be changed by switching languages in the PS2 menu, which gives greater hope for finding at least 1 usable jump target in every firmware version, however it unfortunately comes at the cost of forcing the user to reconfigure their language.

I decided to dump the entire region of possible jump targets, group them into 4-bytes and see if any of them would point to memory that we control via the overflow vulnerability Amazingly, there is a result: index 0xe07e address 0x5f1f38 points to 0x , which is within our controlled range! This isn't perfect, since it's the cached virtual address, and so we might run into cache coherency problems, but it could work.

It's amazingly lucky that there happens to be a valid jump target we can use which already points to memory we can control. Since other DVD Player versions with different address spaces probably won't have this same luxury, I'll briefly talk about one other corruption primitive, in case it turns out to be useful for anyone trying to exploit their own console's version. Since indexForOOBW is a bit value, corrupting it via the large overflow could potentially allow writing to an arbitrary address in this path.

There's the constraint that the value must be 0 before you write it per the first line in that snippet , but that shouldn't make exploitation significantly more difficult. You could easily overwrite a NOP in a delay-slot somewhere into a jump to a register which happens to be controlled at time of execution. Alternatively, a better approach would be chaining this OOB write with the OOB call mentioned above; you overwrite one of the addresses we can use as a jump target which happens to be 0 into an arbitrary new jump target.

IFO' didn't exist. We can't create this file normally because the code has a maximum filename length which we run into when we try large indexes like this I think it's either 15 or 16 bytes.

You could work around the length limitation, and still use this bug to corrupt quite a large region of memory, or it might be possible to corrupt enough internal.

Chaining together this new exploit with that ESR loader would allow you to patch your backups so that they could just be burned and run on your console from boot as though they were official discs. I don't really want to be responsible for maintaining a tool that does this, so I'm not including any of the code to do this in the repo, but the gist of it can be explained pretty quickly, so I'll just provide some notes explaining how I did it:.

IFO to create the filesystem structure we need. Attributes we care about for those files are size 4-bytes and LBA position 2-bytes. The tool creates these files with size bytes, and LBAs and , so the byte patterns we are interested in are:.

Contents of the ISO filesystem used by games generally seem to start at around , which I believe is a requirement by Sony. Given this amount of space, it would even be possible to include some kind of Action Replay cheat menu or something on the disc, which could be a fun future project.

IFO file. Finally, the ESR loader program can be copied to the next available sector at ; we won't bother creating an entry in the UDF filesystem for it since we've already had to manually modify the ISO anyway. In summary, the patches we need to make to the UDF data to add our exploit to a patched game are:. I only did this once, manually, but it should be pretty straight forward to modify the tool to change these patches. The result is a pretty cool demo showing total defeat of the PlayStation 2 copy-protection security model:.

As previously mentioned, the exploit could probably be optimised to boot a fraction of a second faster by reducing the size of the overflow.