Ape Escape 2 Pcsx2

[Louella Kammann]

Butas far as a fix I am running scripts for the PCSX2 games in Launchbox because of a lightgun I have that requires them for it to work. So the entire game is run through a script in Launchbox like it's a PC game .exe after I compile the autohotkey script. So I cannot add anything into the running scripts section or exit section. I would need a script that I also make outside of Launchbox that I can add to additional apps.

May I ask, does that script work with pause screens? Because it look a bit convoluted. In LaunchBox go to the Tools menu>Manage Emulators>PCSX2>Details. Add a "--nogui" command-line parameter (without quotes). Then open PCSX2 an make sure that under the Misc tab "Show Console" is unticked. That way PCSX2 only open one window, the game window and is very easy to exit.

I suppose I could even leave out "ahk_class wxWindowNR" and it would still work. I see a lot of people mindlessly copy ahk scripts without understanding what it does. For instance religiously using "Process, Close".

I don't mean to criticize you, but it can be more helpfull and quicker to look at the autohotkey documentation then to search for other peoples scripts. At least for me the challenge is to find out how things work and come up with a solution.

Also on another note, I personally rarely compile scripts to an .exe because of the reason you gave. But I admit, the endgoal is to get everyting working to your satisfaction and if it works... It works!

Thanks for the input. I am by no means a script expert, I'm pretty much the opposite. My problem is a little more difficult to solve though I know I didn't explain it in the first post. The reason is I'm not adding pcsx2 as an emulator in Launchbox because I have a Lightgun for Windows but it takes additional scripts. So I just load everything including pcsx2 and the iso and the script all in one and make it an exe and load it in Launchbox. But the problem was not exclusive to scripts though I tried launching a game directly through PCSX 2 and it was the same esc was not working. I will try your suggestion tomorow most likely.

Honestly everytime I read the autohotkey documentation it never helps me. Because there's always some quirk that I don't feel is explained good on their site. Even their examples for whatever reason rarely give me what I need to make the script.

It helps me to see someone make an actual script such as you did then I learn from that, I even keep examples in a document I have that I go back to. From other people's scripts I have been able to do things like get my lightgun to work in games, get my gaming steering wheel to work in games, change displays on my laptop/TV, make mouse cursors stop showing up in my games, turn off game controllers through keyboard shortcuts and even more than that.

But in this case I tried the scripts I know to exit using escape, and they weren't working but the one I posted from pcsx2 did work. Since these are lightgun games I'm using pcsx2 I'm not too concerned about not closing it correctly or losing saves. I don't really have a reason to pause the screens either. Just as long as it closes or the script does what I want I am happy.

No worries mate! As I said, I never ment to criticize you with my reply. I am not an expert myself, far from it. I myself started with messing with other peoples scripts too, but quikly jumped to the autohotkey documentation to understand why or why not. As you go along you learn. I actually hoped to encourage people to go a level further than they normally would. I feel the satisfaction of getting something to work and the way of thinking it would require to get you there would be beneficial to a person. But if you write things like that you know you are getting older. Anyway I see you have lots of things happening at once, so I totally understand that you're just glad it works. Let me know if I can help you!

It didn't exactly take me long to do, but having spent the time to do it for you, because of a problem you were having, and then to see you asking how to do it, makes me think that you didn't bother looking at that info.

In this article I will discuss how I successfully escaped the PS2 emulator developed for the PlayStation 4. See also Part 2, covering the next part of the exploit chain, and PlayStation's response to the research.

It's been a long time since I last worked on any modern PlayStation hacking, but with the release of the PS5 and the introduction of PlayStation's bug bounty program, I was motivated to attempt some kind of exploit chain that would work on the PS5.

This is particularly valuable because access to running just the subset of officially available PS2 games on these platforms is being charged at the highest tier of PlayStation's new subscription service.

Sony aggressively removed JIT privileged attack surface from the PS5, disabling JIT in both the web browser and the BluRay player. Since the PS2 emulator is really a PS4 title that runs due to backwards compatibility, they were unable to make changes to the software, and so its JIT privilege had to be spared.

Having JIT privilege means that fully compromising the emulator, including the compiler co-process, would grant the ability to run fully arbitrary native code (not just ROP) on the PS4/PS5 without the need for a kernel exploit. This would be especially convenient on the PS5 because the newly introduced hypervisor enforces that code pages (both userland and kernel) are not readable, and I don't have the patience to try to write a blind kernel exploit again as I did when I ported BadIRET to the PS4 without a kernel dump.

The console was designed to enforce required updates for the Operating System to play the latest games, but the Operating System was not designed with any mechanism to enforce the latest patches for games; ie: old versions of games can always be played on the latest version of the Operating System:

It was designed this way since PlayStation can't be held responsible for the security of third party games (particularly those that statically link to old versions of WebKit). Their security model instead focuses on securing higher privileged layers of the platform (kernel, and hypervisor on PS5), operating under the assumption that games are compromised.

It's my interpretation that the existence of games with special privileges, like the PS2 emulator's JIT, fundamentally violates their own security model because it leaves privileged code with no readily available mechanisms to patch potential future vulnerabilities.

Furthermore, in addition to the gap in their security model that prevents patching existing copies of the games, PlayStation has also decided to not even remove the identified known-exploitable PS2 games for purchase from the store. Because of these two reasons, I'm comfortable referring to this exploit chain as "unpatchable", even if it may not technically be fully accurate.

The kernel assigns each of these process different privileges, implemented by checking the result of the sceSblACMgrIsJitApplicationProcess and sceSblACMgrIsJitCompilerProcess functions (names taken from back when PS4 kernels still had symbols). The compiler can write code, and the application can execute code.

The check used to be implemented incorrectly, and the browser application process on PS4 firmware 1.76 could create both writeable mappings, and executable mappings, but nowadays we would need to control both processes in order to be able to produce fully arbitrary code, and so that will be the goal of this chain.

PS2 save game vulnerabilities are not hard to find; for example, see the GTA decompilations showing a copy from the memory card into a fixed-size buffer with size supplied by the save; exploiting these issues is relatively simple since the PS2 didn't have any exploit mitigations. With one of these exploits, a PS4 save file containing the crafted PS2 memory card can be encrypted and signed for any PSN-ID by anyone with a hacked PS4 on any firmware (or just a PC if they have the decapped SAMU keys), and then imported to the target PS4/PS5 using the USB save import feature in Settings.

A controller-input-triggered exploit would be less practical, except for having the ability to be used without requiring the USB save import feature, which depends on having signed into PSN (since saves are encrypted per-account), and times out on the PS5 after being offline for too long.

I did briefly search for PS2 games available on PS4 which could be exploitable this way, and discovered that Dark Cloud would be (there's a decades-old known bug whereby moving the cursor and pressing X on the same frame in the items menu allows you to pick up an item from out-of-bounds memory, which results in exploitable behaviour), but sadly it only received a digital PS4 release, not a physical PS4 disc release (so it doesn't help remove the PSN requirement).

Given PS2 code execution from any of the 3 identified exploitable PS2 games, I started reverse engineering the emulator itself. The very first thing I looked at was the memory read/write callbacks; you can see on ps2tek that some addresses control various PS2 hardware functionality, and so accessing them requires special code for the emulator to handle those requests.

For example, you can see how the PS2's Linux kernel port performs CDVD S commands using these IO registers. To pass arguments to an S command, they are written byte-by-byte into the SCMD_SEND / SCMD_STATUS register (0x1F402005), and there is a similar register used for supplying arguments to CDVD N commands (0x1f402017).

In other words, simply writing to either of these registers consecutively more than 16 times will lead to overflowing the status buffers with arbitrary bytes; we'll call this Primitive 1, and by submitting invalid commands to reset the index, we can use it repeatedly:

Note that other registers like 0x1f402016 (CDVD S Command), and 0x1f402004 (CDVD N Command), are also vulnerable to buffer overflows, so in total there are at least 4 variant vulnerabilities like this, but since the emulator is quasi-unpatchable, and PlayStation's bounty program stopped accepting PS2 emulator escape reports after the first one, there is no reason to find or analyse other bugs.

3a8082e126