PS2 DVD Player modifications

Here comes le necro-post-edit.

Original post with old and br0ken stuff in this spoiler :

Spoiler

Wanted to share that stuff in the hope someone finds it useful...

PS2 DVD Player RPC Patcher Version 0.04
Finds and patches the Regional Playback Control system in unpacked DVD Player ELFs. It also defeats the "sabotage" thing which is responsible of the fatal crash (on v2.13 and higher). No fix for the green screen or Macr0vision, just allows to bypass the DVD-Video region check.

2 DVD Player Launchers
One for unpacked DVDELFs, the other one for unpacked DVDPLXes. Written for embedding patched DVD Players as they're vomited by my above patch tool. Launchers require the IOP replacement image to be rebuilt. No GEC copyrighted code included. Put your hacked binaries and compile your test ELF.


And logs of scans made upon DESR DVD Players:wink-new:
DVD Player from the update disc 1.10
DVD Player from the update disc 1.20
DVD Player from the update disc 1.31
DVD Player from the update disc 2.11
Not sure patches produce expected effects to PSX. I did test 1.10 and 2.11 on PCSX2, they gone to the error message "Play halted due to malfunction" (relative to DVR modules messup) and haven't crashed, so I assume the "sabotage" thing is properly pwned (otherwise the EE RAM would have been wiped out).

And to finish, something on Pastie #5866345...

Quick jump to some better stuff :
DVD Player 3.11J, For European Consoles, Russian Resource Files, FMCB 1.95 Signature (no Progressive Scan)
DVD Player 3.11J, For North American Consoles, English Resource Files, FMCB 1.95 Signature (no Progressive Scan)
DVD Player 3.11J, For Japanese Consoles, English and Japanese Resource Files, FMCB 1.95 Signature (no Progressive Scan)
DVD Player 3.11J, complete multi-lingual/region bundle, with Progressive scan <- LATEST PACKAGE

KELFTwinSigner

First ELF/KELF with RGB fix + 480p for testing
Second ELF/KELF with RGB fix + 480p for testing
Third ELF/KELF with RGB fix + 480p for testing

DIY dvdplayer.id and BREXEC-DVDPLAYER folder (picture on the spoiler) :

Spoiler

ROM = the letter of your console built-in DVD player version. Go to the "Version Information" screen to see it (press triangle at the main screen of OSDSYS/HOSDSYS).

 

I've reviewed and understood what you are doing to the old DVD Players (Below v2.13), and I have a few comments to make: Why not just scan for the GetDVDVZone() function itself and patch it to just return 0 (e.g. addu $v0, $zero, $zero)? Then you don't even have to scan for jumps to that function.

Also, from what I'm understanding here: by getting that function to return zero, you are making the DVD Player believe that the disc is a region-free disc (No regions excluded). The region-locking mechanism still seems to be there.

Unless, I've misunderstood the functionality of the GetDVDVzone() function.

The function which loads "mc:\BIEXEC-DVDPLAYER\DVDPLAYER.IRX" is SifIopReset(). It's reseting the IOP with the KIRX, since it doesn't contain an embedded IOPRP image like the other newer Sony Playstation 2 software.

Sorry, but what is the "Allowed DVD-Video Zone" method for, if patching all calls to GetDVDVzone() already tricks the DVD Player into thinking that the disc is a region-free disc?

As for the "TV SYSTEM DOESN'T MATCH" fix, the load instruction in the DVD Player of my SCPH-77006 (v3.11G) loads a variable alright... but another function already saves 3 to it (So patching that will probably have no effect). D:

(So, does this mean that the TV system check only applies to certain versions of the DVD Player?)

 

Hmm. It could be something to do with 60hz vs 50hz. If NTSC PS2 is like what I've heard about the NTSC PS3, then it will not playback 50hz encoded discs. Regardless of region.

 

The Playstation 2 can have it's video output adjusted to either NTSC or PAL, using software.

My question to krHacken was about the applicability of that fix. Since it seemed like my DVD Player doesn't need it (But it's version 3.11). :S

Neither do I know how to test for "TV system does not match" lock. D:

 

For games yes. Try to obtain a DVD whose actual video is played in PAL, you might need one to get much further.

 

I don't remember exactly how that function behaves, but I think you are right. Replacing the instruction which get the buffered value (4 bytes before the search pattern, inside of the function) should work too. I did a small change to the code :
DVD Player RPC Patcher 0.02.7z

Still rookie coding...

Are you sure it isn't SifLoadModuleEncrypted ? That KIRX isn't a raw IOP replacement IMG, but an IRX module which performs the IOP reset with its embedded (packed) IOP replacement image. More or less like the imgdrv does.

It's the method used by first GameShark versions and Cheat Code Demon. Useless as that piece of code doesn't exist on 1.00, 1.01 and all v3s. I've included that scanner in the "This disc cannot be played due to regional restrictions" in all DVD Player versions.

I verified 2.12G. It plays both PAL and NTSC movies natively, so it explains why your 3.11G stores 0x03. PAL European #.##E firmwares also play PAL and NTSC.
All 3.1# DVD Players (from Slims) play NTSC and PAL if they're hacked, because they all use the same CMN0# files (it's "cross-regional"), so they have the capability of decoding MP2 audio tracks (NTSC firmwares from Fat units cannot decode MP2 natively I guess, because it's not standard compliant).
Regarding how 3.1# firmwares (DVDPLX) determine the TV-System ID before they store it, I have no idea. The area where it's stored also receives other "cross-regional" variables, like O/X buttons assignment if I remember correctly....

EDIT about the way my patcher fixes the TV-System value :
The patcher hardcodes the TV-System value to the function which loads it from where it's stored, so even if that value is somehow stored, it is no longer read by the function which is responsible of the "TV System does not match" error.


EDIT 2, I did a quick analysis of the TV system value stuff...
3.10U : Stored by 0022306c [sw v1, $33d4(t1)] to 002233d4, then read by 002230a4 [lw v0, $33d4(v1)]
Other 3.10# : Stored by 00223070 [sw t2, $33dc(t4)] to 002233dc, then read by 002230ac [lw v0, $33dc(v1)]
3.11G : Stored by 00223094 [sw t0, $34ac(t3)] to 002234ac, then read by 0022317c [lw v0, $34ac(v1)]
3.11J : Stored by 0022306c [sw v1, $33cc(a2)] to 002233cc, then read by 002230a4 [lw v0, $33cc(v1)]
3.11M : Stored by 0022306c [sw t2, $33dc(t3)] to 002233dc, then read by 002230ac [lw v0, $33dc(v1)]
3.11U : Stored by 0022306c [sw v1, $33d4(t1)] to 002233d4, then read by 002230a4 [lw v0, $33d4(v1)]
Other 3.11# : Stored by 00223070 [sw t2, $33dc(t4)] to 002233dc, then read by 002230ac [lw v0, $33dc(v1)]

 

Hey, it'll just a suggestion. @_@

There are many ways to do things, it's just that I wanted to know whether you did so otherwise for some reason.

I'm quite sure about it.

I believe that there were originally only 3 devices which the Playstation 2 supports loading IOPRP images from (Based on the modules listed in rom0:IOPBTCON2 of my SCPH-10000, while newer consoles have support for rom1 as well):
1. The boot ROM (rom0.
2. Memory Card (KIRX-protected updaters only, and they contain an embedded IOPRP image).
3. CD/DVD-ROM

Loading an IOPRP image from a buffer probably wasn't intended from the start, as the old LOADFILE RPC service doesn't support LoadModuleBuffer(). The newer Sony software all patch this old module to support LoadModuleBuffer(), before they begin reseting the IOP with their buffered IOPRP image.

However, it seems like they intended to allow the EE to intervene with the IOP reset procedure (e.g. performing the first and second IOP reset phases manually, like when using the IMGDRV method), hence the SIF modules are loaded during the first IOP reset phase too.

This early DVD player is using the 2nd boot method, as you notice that it's determining where it's being booted from (With a huge number of thorough checks... lol) and is passing the KIRX path to SifIopReset() and 0x100 as the mode value (Tells MODLOAD to use Magicgate to decrypt the updater program).

SifIopReset() will indirectly pass all these arguments to MODLOAD (After it ges passed around several modules, at least through rom0:IOPBOOT and rom0:LOADCORE), after the first IOP reset phase. MODLOAD will then decrypt and load the updater program (mcX:\BIEXEC-DVDPLAYER\dvdplayer.irx), which will reset the IOP again with it's own payload IOPRP image.

If you disassembled rom0:UDNL, you'll notice that even it'll check it's DATA section too for an embedded IOPRP image (Which doesn't exist in the boot ROMs of any Playstation 2 unit, but it still does that anyway).

Later versions of all Sony Playstation 2 software don't seem to use this method of transporting IOPRP images anymore.

EDIT: Forgot to explain the most important part here: The IOP reset string is actually a command. As written by a user (tiamo, I believe) on PSX-scene a couple of years back, it's a command line argument which supports arguments and multiple IOPRP images.

Rules:
1. The command line string is optional. If NULL is specified, only one reset will be performed since there is no updater program to load.
2. Unencrypted IOPRP images and modules can only be loaded from certain devices (due to a blacklist in MODLOAD), among the devices supported internally by the Playstation 2's boot ROM (As specified in IOPBTCON2, for the middle of the soft-reset process).
3. All "unsecured" devices are not supported by rom0:UDNL, and will trigger a breakpoint exception if you attempt to load an IOPRP image from it. This blacklist is probably the same as in rom0:MODLOAD.
4. To reset the IOP with an IOPRP image from an "unsecure" device, a new updater program is required (Now, you still have to obey rule #2. So if it's stored on the memory card, it has to be a KIRX).
5. Multiple IOPRP images can be specified on the command line.
6. The updater will first attempt to locate a copy of IOPBTCONF, which contains the list of modules to load during the 2nd IOP reset phase.
7. The updater will then attempt to locate and store copies of all modules listed in IOPBTCONF, bearing the highest version number.
8. The updater will complete #6 and #7 by accessing the list of IOPRP images, starting from the leftmost and moving to the right, before looking in the boot ROM.
9. While specifying an invalid IOPRP image will not cause problems on a SCPH-10000 and SCPH-15000, it'll cause a breakpoint exception on newer consoles.
10. Certain versions of UDNL require the IOPBTCONF file to be stored in a separate IOPRP image from the IOPRP image containing the replacement modules. If such an updater finds IOPBTCONF in an IOPRP image, any IRX modules there are ignored.
11. Unsecured devices are the memory card, HDD unit and network (Not "host:" I think, but another Sony-ish name which I forgot). Secured devices are the boot ROM and CD/DVD drive.

I think that this is basically everything. @_@
See, Sony made it damn complicated. It's not a dumb machine, but is actually highly programmable.

#10 is interesting, as you can see some newer Sony software having two IOPRP images (One containing the IOPBTCONF file and another containing the modules).

Ah, a nice diagram should be drawn up to make this less confusing.
And then we can still talk about the intrics of the reboot process, like how the boot modes are set up and how the SIF status flags are adjusted.... so this topic is actually quite long. D:

Your loader seems to not clear all the SIF register flags properly, by the way.

Ah, that makes sense now, thanks.

Thanks for clearing that up.

There are many ways to determine the region code of the console:
1. Checking the region field of the OSD configuration.
2. Manually accessing the MECHACON EEPROM (Unlikely, this is console model-specific).
3. Loading the OSD configuration from the console configuration (Stored in MECHACON EEPROM). It'll usually load the data into the OSD configuration function in the kernel too (related to #1).
4. Checking ROMVER with file I/O routines.
5. Checking the ROMVER via the EE <-> IOP memory map (0xBC000000).

I believe that #1 , #3 and #4 are most likely here, as the OSD already does that.

As for whether the console supports progressive scanning or not, the GS chip revision number in the GS CSR register is one extra target since the SCPH-50000 had a new GS chip (Thanks to l_Oliveira for telling me this!).

Yup, and it does it's job pretty well.

I was just checking with you, since I wanted to understand how this thing works and why.

 

LOL, that's not what I meant. For some season my mouse did underline extra text when I inserted the link to imagebam and it messed up my message. I wanted to say : I've included that pattern in the proggy for research purposes and forgot to disable before compiling the EXE.
GetDVDVZone() is present in all firmwares I did scan, so it's a generic and working fix for [and here's the other part of my message] "This disc cannot be played due to regional restrictions" in all DVD Player versions.

Your idea of patching the function rather than calls is the most appropriate, especially if the patch gets ported to the PS2 as a softmod (less searches, less patches).
I noticed that strangely some versions have more than one call to that function.


Thanks very much for detailing the SifIopReset process with a KIRX:smile-new:. When cracking Utility Disc v1.00 and v1.01, I did some voodoo with the function which resets the IOP with the KIRX "PS294.VOB" so it can be done with the decrypted IRX. Then I tested the backup, the installation crashed. I thought it was caused by the SecrDiskBootFile failure upon the firmware package (because my console is PAL), but now that you explained me how SifIopReset() works, I think I wrongly modified the function:dejection:.
EDIT : Mmmmm, "PS294.VOB" isn't a KIRX but a raw IOPRP. What the hell have I done:stupid:.
EDIT2 : Ah, OK, the KIRX I'm talking about is "PS292.VOB". It's like a dvdplayer KIRX but flagged like a KELF (0x022C)... WTF Sony, WTF.

 

I believe dnasload checks the console region through the DVD DSP registers interface by using it to talk to the mechacon.

Once dnasload.elf KELF container is patched for region free, the embedded ELF still forbids the title from playing if the region bitmask mismatches.
I am almost sure the DISC region is based on a bitmask, similar to how KELF exclusion works.

The TEST consoles are programmed to report themselves as compatible with all regions so the KELF will allow the title to start regardless. That is valid only for TEST units with KELF facility enabled on the mechacon (DTL-Hx010x).


Regarding the chips versions here's a quick'n dirty breakdown:


GH-015 (1-683-434-31) NTSC/UC (USA) >

CDDSP CXD1886Q
MECHACON CXP103940 FW ver: -102GG
ROM: D110 040 048
(apparently these three numbers refer to region and version of each component of the ROM being ROM0, ROM1 and EROM
First number is the region and you know, 1 = USA, 6 = HK)

IOP CXD9732GP
SPU CXD2950R
DEV9 CXD9611BR

EE CXD9708GB
GS CXD2949GB

---
GH-015 (1-683-434-41) NTSC/J (HK) >

CDDSP CXD1886Q
MECHACON CXP103940 FW ver: -401GG
ROM: D630 050 048

IOP CXD9732GP
SPU CXD2950R
DEV9 CXD9686R

EE CXD9708GB
GS CXD2949GB

---

GH-023 (1-688-757-41) NTSC/UC (USA) >

CDDSP CXD3098Q
MECHACON CXR607080 (DRAGON chip, new mechacon has syscon and RTC built in hence the name DRAGON) FW ver: -103GG
ROM: D110110 M64 (64Mbit chip)

IOP CXD9783GP (New IOP)
SPU CXD2947R (Embedded SPU RAM)
DEV9 CXD9611BR (Same as one of the GH-015s)

EE CXD9708GB
GS CXD2949CGB (New GS)

So you see, there's a LOT of different stuff on the 50k ... lol

 

Also I didn't think of this before but the CD DSP type/HW version and MECHACON FW version can be used as a detection method as well since the same MECHA/DSP combo was used on the PS2 SLIMs through the line lifetime.

 

One thing I noticed, is that the MECHACON doesn't care at all at the header. All it will do is check if the hash matches. If the hash matches it will "vomit" (or "@#%T") whatever digest it's supposed to output.

The KELF files used by the PS3 PS2 emulator for playing PS2 HDD games have "W" (as SCEW) on their header just for fun. They work fine on a real PS2, too. Also they happen to be the only original files which actually had all region flags set.

Also if you look the early KELFs from the SCPH-10000 utility discs (and MC installed files) you will see the header there is completely different, as well ...

So yes I suppose SONY had all the freedom to put the checks on the EE or IOP code if they wanted to ... lol

 

Oh, indeed, thanks for pointing that out. My proggy had a variable with no effect : if(kelfheader[24] == 0x1c), pass "1" as arg 5 of beepEncrypt (content) and beepDecrypt (content); else (ie 0x2c for KELF) pass "2". Of course that variable doesn't change anyting, because beep is specified as IV (arg 6). Removed that.

Yep, those first 16 bytes of the header looking like trash...
What about DISK sigs ? Got a dictionary of decrypted Kb/Kc pairs for my signature recovery needs, and some KELFs (can't remember which ones) have funny crap on their Kb, like "Revocati" and "onLists\0":witless:.

 

Interessting.

Any example title? FF?



Rgds.

 

Your example: IP9100-NPIA00001_00-PS2HDDSYSDAT0001.pkg

 

:smile-new:


I meant game titles...



Rgds.


UPDATE:
Okay, i found i was looking for...
Thanks.

 

http://www.ps3devwiki.com/wiki/Talk:Emulation#PS2_HDD < this ?

 

Yeepp, this is what i've found.
I'd like to test such an image on a real ps2 and wanna take a look at the (k)elfs...



Rgds.

 

PS2 DVD Player RPC Patcher Version 0.03

v0.03 is here :
DVD Player RPC Patcher 0.03.7z

Yeah, I realised that I miswrote the patched instruction for the GetDVDVzone fnc (on printf). The hacked output file was correctly patched though. Fixed.
The log files are v0.03, I've included scan logs of DESRs... and the scanlog of the freshly decrypted 3.04J.


3.04J : my initial SUD Wobble Finder cannot find PSBBN 0.32 wobbles. Mainly because DecSet(0x33) is not implemented, and one of the wobbles breaks detection criterias.

OSD update package @ LBA 214562
DVD Player update + Kernel patch package @ LBA 229796
Possible BitSet : 0x03
Possible DecSet : 0x33
Possible cdvdKey : 03 22 46 03 00 00 01

Been able to deobfuscate and MG decrypt packages. However, I'm waiting for the disc dumper to leech the cdvdKey with SUD Mutilator before I confirm my theories and recode the Wooble Finder carefully.
EDIT : The dumper has confirmed the cdvdKey, it's 03 22 46 03 00 00 01. He also told me that PSBBN 0.30 cdvdKey is 07 22 46 03 00 00 01. According to my list (which I'm currently rewriting), 0.10, 0.20, 0.30 and 0.32 have a ## 22 46 03 00 00 01 cdvdKey (1st wobble at sector 214562). Still don't know how the installer determines the location of the 2nd wobble. Its LBA differs in every discs.

Does anyone own a pressed PSBBN 0.31 disc ?

 

Apparently Sony did build the PS2 3.04J IOPRP and the PSX IOPRPs the same day.
IOPRP of the DVD Player version 3.04J which is obfuscated in the PSBBN 0.32 disc :
20040115-211720,dvd_cex_remocon.conf,dvd_cex_remocon.bin,xiguchi@iguchi-linux.rd.scei.sony.co.jp/module/dvd/lib280/UDF0302/dvd2801_test
IOPRP of the DVD Player which is PAKed in DESR 1.20, 1.31 and 2.11 update discs :
20040115-220414,dvd_cex_xrom.conf,dvd_cex_xrom.bin,xiguchi@iguchi-linux.rd.scei.sony.co.jp/module/dvd/lib280/UDF0302/tlib031201
Obviously MODLOAD, FILEIO, CDVDMAN, CDVDFSV and UDFIO don't match, but if you reset the IOP with the PS2 3.04J IOP replacement image then execute the PSX DVD Player in your PS2, it will run and freeze after passing the TV system related check(s). Put a PAL DVD-Video and you'll see the infamous "TV system doesn't match" message.

By the way, what version are PSX DVD Players ? Are they 3.04 ?
The IOPRP of the DVD Player which is PAKed in the update disc 1.10 is also made of lib280 modules :
20031201-135742,dvd_cex_xrom.conf,dvd_cex_xrom.bin,xiguchi@iguchi-linux.rd.scei.sony.co.jp/module/dvd/lib280/UDF0302/tlib031201
The only difference with 1.20/1.31/2.11 is the UDFIO.

PS2 3.02U IOPRP was made of lib250 mods :
20030422-165134,dvd_cex_remocon.conf,dvd_cex_remocon.bin,xiguchi@iguchi-linux.rd.scei.sony.co.jp/module/dvd/lib250/DeleteFlgTaiou/lib2501

 

3.00J scan log here : 3.00J.TXT
And the updated SUD wobble table : WOBBLES.TXT
Thanks to PS2Guy, Segment_Fault, sp193 and bb_neo for dumping their discs.
I'm gonna have to double check wobble lengths later, just to make sure it's all good but now I need a decent sleep:sleeping:.