Burnout Online - PlayStation 2

Thanks to /dev/ghostline’s server emulator it is now possible to use online functionalities of the game again.

The server emulator is currently reachable through the following URL: bosrv.org.

Table of Contents

• Evolution of Patching Methods
  • The Classic Way
  • On-ThEE-Fly
  • Leaving Alone the IOP
• Patches Contents
  • Burnout 3: Takedown
  • Burnout Revenge
• Downloads
  • Burnout 3: Takedown
  • Burnout Revenge

Evolution of Patching Methods

Three steps are mandatory to properly connect to the server emulator:

• Replace the original server URL
• Bypass Sony’s DNAS
• Bypass the validation of the server emulator SSL certificate

The original server URL and the DNAS logic are located in the game executable (SLXX_XXX.XX) which is to be loaded in the EE (Emotion Engine) memory aka the “main” memory. Tampering with the EE memory is widely supported both on the emulation side (PNACH, Cheat Engine, etc.) or real hardware side (Action Replay, ps2rd, etc.).

However the certificate validation is located in an IRX file (DRTYSCKF.IRX, EA’s “DirtySock” library handling all the network communications while playing online) which is to be loaded in the IOP (I/O Processor) memory. Tampering with the IOP memory is pretty uncommon and can’t be achieved easily on real consoles. On the emulation side, PNACH patches can target the IOP but using fixed memory addresses tends to be unreliable.

The Classic Way

At first, the preferred method for connecting to the server emulator was to apply xdelta patches to the game disc image. This method doesn’t involve any memory tampering but requires the ability to run modified disc images, implying for real hardware owners to rely on homebrews/swapping tricks/etc. Two downsides in my opinon.

On the emulation side, PNACH patches targeting both EE and IOP were also available, but as said earlier, IOP memory patches (patch=1,IOP,[...]) aren’t reliable, these patches weren’t working for everyone.

On-ThEE-Fly

I didn’t want to look further into the PNACH IOP issue and wanted to investigate onto something guaranteed to work on both sides, and I ended up finding an alternative method (now outdated) to patch and load DRTYSCKF.IRX while only using the EE.

Knowing that the action of telling the IOP to load an IRX file is initiated from the EE by calling a function named sceSifLoadModule, I looked around “sceSif” functions and noticed a very interesting one called sceSifLoadModuleBuffer. As its name describes, it can load an IRX file from a buffer residing in the EE memory, exactly what I needed.

This approach consists of mapping DRTYSCKF.IRX from the disc into an EE memory buffer (using sceOpen, sceRead, etc.), patch it as we wish and then make the game call sceSifLoadModuleBuffer instead of sceSifLoadModule when DRTYSCKF.IRX gets loaded. This will prevent the IRX file to be retrieved directly from the game files and use our buffer instead.

Leaving Alone the IOP

While working on some network patches for Revenge, I got curious about a ProtoSSL bug which has been briefly discussed in the Burnout Online Discord server, opinions were mixed regarding its existence in PS2 Burnout games but it didn’t went a lot further.

I decided to give it a shot and noticed that the bug was indeed present in DRTYSCKF.IRX for both Takedown and Revenge. After some tweaking, I managed to make the server emulator certificate reach and trigger the bug. I made a merge request which has been accepted and now we can access the server emulator without patching anything IOP-wise!

Patches Contents

RED = Mandatory
ORANGE = Recommended

Burnout 3: Takedown

Burnout Revenge

Coming soon.

Downloads

Burnout 3: Takedown

Burnout Revenge