Bytesfox641

1. Ftbucket ふたば の ログ ダウンロード サイト ⭐ P10lite romをダウンロード. けものフレンズ minecraft texture pack. Lucky patcher ios 下載. Retroarch rom入れ方ps3. 高橋幸宏 once a fool album. Ds rom ポケモン不思議な.
2. ISO file is your PS2 game). Burning may take some time, this is normal. Iso files you will need The ESR patcher located in the link below NTSC to PAL is also in the. Rar- In case you have a ps. Go here to download the ESR disk patcher and any other PS2 softmod app you might need Go here to DL games.

Sony PlayStation 2 Information. Download PS2 ROMs and play free games on your computer or phone. Get an emulator to be able to load the games from your computer or phone or play the online unblocked versions instead. There are Sony PlayStation 2 games from a variety of different genres and categories, so the entertainment is guaranteed.

I've previously discussed how the PlayStation 2 doesn't have any good entry-point software exploits for launching homebrew. You need to either purchase a memory card with an exploit pre-installed (or a memory card to USB adapter), a HDD expansion bay (not available to slim consoles), open up the console to block the disc tray sensors, or install a modchip. For the best selling console of all time, it deserves better hacks.

My initial attempt to solve this problem was to exploit the BASIC interpreter that came bundeld with early PAL region PS2s. Although I was successful at producing the first software based entry-point exploit that can be triggered using only hardware that came with the console, the attack was largely criticized due to the requirement of having to enter the payload manually through the controller or keyboard, and limitation of being PAL only. I decided to write-off that exploit as being impractical, and so the hunt continued for a better attack scenario for the PlayStation 2.

The PlayStation 2 has other sources of untrusted input that we could attack; games which support online multiplayer or USB storage could almost definitely be exploited. But unlike say the Nintendo 64, where we don't really have any other choice but to resort to exploiting games over interfaces like modems, the PlayStation 2 has one key difference: its primary input is optical media (CD / DVD discs), a format which anyone can easily burn with readily available consumer hardware. This leaves an interesting question which I've wanted to solve since I was a child:

Ultimately, I was successfully able to achieve my goal by exploiting the console's DVD player functionality. This blog post will describe the technical details and process of reversing and exploiting the DVD player. Loading backups of commercial games is also possible. All of my code is available on GitHub.

DVD video player attack surface

Obviously we can't just burn a disc containing an ELF file and expect the PS2 to boot it; we'll need to exploit some kind of software vulnerability related to parsing of controlled data. The console supports playing burned DVD video discs, which exposes significant attack surface we could potentially exploit to achieve our goal.

If we think about what a DVD Video consists of there are quite a few main components, each with the potential for vulnerabilities:

• UDF filesystem
• DVD Video metadata / subtitles
• Audio and video decoding
• Interaction machine

Whilst the complete DVD Video specification is unfortunately behind a paywall, it is comprised largely of open formats like MPEG, just bundled together in a proprietary container format (VOB). For the proprietary aspects there are some freely accessible unofficial references.

The IFO file format is probably the simplest format used, and is responsible for storing the metadata that links the video files together.

The interaction machine is what allows for interactive menus and games in DVD Videos. It has 32 groups of instructions, and is interesting because it could potentially be used to dynamically manipulate internal memory state to prime an exploit, or it could be used to create a universal DVD with a menu which allows you to select your firmware version and trigger the appropriate exploit.

Esr Disc Patcher Ps2 Download

Setup

Clearly it's not practical to do most of our testing on the real hardware since burning hundreds of test discs would be wasteful and time inefficient. We need an emulator with some debugger support, which is where we hit our first roadblock: the most popular emulator for PlayStation 2, PCSX2, does not support playing DVD Videos, and no one is interested in adding support.

I'd like to thank krHacken for helping me out with that first roadblock. It turns out that PCSX2 does support the DVD player; it just can't load it automatically since it's located in encrypted storage and PCSX2 does not support the decryption. There are public tools which can decrypt and extract the DVD player from EROM storage. It can then be repacked into an ELF for easy loading into PCSX2.

Due to the large number of different PlayStation 2 models released, each with slightly different DVD player firmwares (> 50...), I will focus on a single DVD player for the duration of this article: 3.10E (configured with English language in PS2 settings), as it happens to be the firmware for the console I own.

I will continue to use Ghidra for decompilation as I've been using throughout my previous articles. The DVD player does not contain any symbols so all names in code snippets were assigned by me through reverse engineering.

Disc controlled data

The first file a DVD player will attempt to read is VIDEO_TS.IFO. Searching memory for contents of the file and then setting memory write breakpoints there to track back where it was written we quickly locate the API that reads disc contents used by the IFO parsing code, getDiscByte at 0x25c920. It's a stream reader which caches a number of sectors into a RAM buffer, and then automatically seeks more data once needed:

From searching calls to this, we can also quickly find wrappers that fetch data of larger sizes: getDiscU16 (0x25c980), getDiscU32 (0x25c9b8), and getDiscData (0x25c9f0), which is the most interesting as it reads an arbitrary length of data:

Large reads

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 16-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:

This one is the most interesting because it allows the largest possible copy size (0xffff * 3 * 8 = 0x17FFE8 bytes) of all the getDiscData buffer overflows. It copies into the statically allocated buffer at 0x0140bdd4, and so by specifying the maximum possible copy size we gain control over the address space from 0x140bdd4 to 0x158BDBC (0x140bdd4 + 0x17FFE8).

Corruption from the large reads

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.

OOB call

Esr Disc Patcher Ps2

At 0x25e388 we have this call to an entry in a function pointer array, where we can control the 16-bit fpIndex at 0x141284a from the overflow:

This allows us to jump to the address stored anywhere from 0x5b9d40 up to 0x5b9d40 + 0xffff * 4 = 0x5F9D3C.

Exploiting OOB call

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 switchcase 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 0x1500014, 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.

OOB write

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.

There's a possible OOB write at 0x25c718 (inside getDiscByteInternal):

Since indexForOOBW is a 32-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.

When I briefly experimented with this primitive, it failed at the call to getBuffer because earlier on in the function it generated the filename via sprintf(filename, 'VTS_%02d_0.IFO', indexForOOBW), and the file 'VTS_1364283729_0.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:

ESR patcher will add two files, VIDEO_TS.IFO and VIDEO_TS.BUP, to the disc's UDF filesystem. Our exploit requires two files named VIDEO_TS.IFO and VTS_01_0.IFO, so just replace the VIDEO_TS.BUP string it writes with VTS_01_0.IFO to create the filesystem structure we need.

Attributes we care about for those files are size (4-bytes) and LBA position (2-bytes). In the UDF specification these fields are adjacent, with LBA being stored as an offset from the directory descriptor containing these fields (VIDEO_TS at LBA 134 in our case). The tool creates these files with size 2032 bytes, and LBAs 138 and 139, so the byte patterns we are interested in are:

Contents of the ISO 9660 filesystem used by games generally seem to start at around 260, which I believe is a requirement by Sony. This is great for us since it means that we have roughly 250KB ((262-137) * 0x800) of space to place the exploit files and loader, and we only need a fraction of that. 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.

Keeping VIDEO_TS.IFO at LBA 138, we just need to extend its size to 14336, and copy the file contents to 138 * 0x800 = 0x45000 in the ISO. Our next free space is 7 sectors later at LBA 145, and will store the contents of our 12288 byte VTS_01_0.IFO file. Finally, the ESR loader program can be copied to the next available sector at 151; 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:

Optimisation

As previously mentioned, the exploit could probably be optimised to boot a fraction of a second faster by reducing the size of the overflow. Also worth noting is that part of the reason the screen flickers whilst triggering the exploit is because I happened to encode my base DVD video as NTSC, and so some of that flickering is an artifact of switching from PAL to NTSC back to PAL. There is almost no video corruption when booted on an NTSC region console. If this bothers you, you could re-make the exploit based on a PAL base DVD instead.

Porting to other firmware versions

Initially I had only planned to release the exploit for my firmware version, as a proof-of-concept, since I cannot really justify investing the time to exploit and support other people's firmware versions. However, I have since done several other ports, and have documented all of the addresses / offsets / techniques here.

Hybrid discs

The first firmware I ported the 3.10 exploit to was 3.11. Collectively, all PS2 slim consoles have either 3.10 or 3.11, which makes these firmware versions an attractive target to merge together into a single exploit since it would allow all PS2 slim owners to just burn a single disc, without even having to check their firmware version first!

These two exploits merged into a single easily, since the offsets in the IFO file to corrupt things like currentDiscBytePointer and fpIndex don't overlap at all, so we can specify different corruption values for each firmware. However, there are still potentially some options if some things in the IFO do overlap between two different versions (mentioned in more detail in porting notes):

If fpIndex did overlap in the IFO file, but currentDiscBytePointer didn't, we could offset the currentDiscBytePointer corruption value for one of the firmwares so that fpIndex is copied from different regions.

Esr Patcher Ps2 Download

If currentDiscBytePointer does overlap, as long as there's an address which happens to have controlled contents in both versions, we can specify a common address.

As a final resort, if it turns out not to be possible to merge support for two firmware versions into a single IFO exploit, we could trade the automatic booting with a DVD menu that let's you select a different chapter manually to match your DVD player version, in order to produce a single disc with compatibility against all firmware versions. I'm optimistic that eventually such a disc will be available.

Game Patcher Download

Conclusion

I was successfully able to exploit the PlayStation 2 DVD Player to allow me to run my own burned homebrew discs simply by inserting them and booting, just as you would launch an official disc.

Although I only exploited version 3.10, as its the version on the console I happen to own, I was later able to extend support to all slim consoles too. If these same vulnerabilities and techniques prove to be difficult to exploit on earlier firmware versions used by phat consoles, I'm also confident that there probably exist more generically exploitable bugs like stack buffer overflows if you reverse deeper, after all, I only got as far as reverse engineering the initial IFO parsing before I identified sufficient vulnerabilities for my exploit. I hope this article and these demos inspire others to have a crack at hacking their own console's firmware versions and share their methods in a centralised repo for the community to share.

Freedvdboot Esr Patcher Gui Download

As a final thought, there's really no reason this general attack scenario is specific to the PlayStation 2 as all generations support some combination of burned media: from the PlayStation 1's CD support, to the PlayStation 3 and 4's Blu-ray support, with the PlayStation 4 having only removed CD support. Hacking the PS4 through Blu-ray BD-J functionality has long been discussed as an idea for an entry point. This may be something I would be interested in looking into for a long-term future project: imagine being able to burn your own PlayStation games for all generations; 1 down, 3 to go...

Playstation 2 Esr Disc Patcher Download Games Torrent

With thanks to krHacken, uyjulian, 'Howling Wolf & Chelsea', and ffgriver.