(Help) How to add Icons to HDLoader/KERMIT Games on PS2 HDD-OSD

I found that:
1. The (OSD? Sony seems to call it the "OSD Configuration" part) configuration part of the MECHACON EEPROM is read into IOP RAM and pointed to by the system configuration pointer (0x3C0).
2. The first 4 blocks are stored (at offset 0), plus a copy of the 2 blocks after the 2nd block (At offset 60).
3. No bytes are reordered.
4. Setting bit 2 of byte 0 at block 0 really makes my SCPH-39006 keep the HDD unit powered up after a KELF has been loaded. O_O
(Note: I can't tell if it's actually frozen up or not since I don't have a screen connected to it, but it's probably not frozen)
5. (EDIT 2) Setting bit 1 really disables ATAD support on my SCPH-39006. It's definitely impacting the functionality of my console.

Each block is 15 bytes. The 16th byte is a checksum byte that is maintained by the MECHACON.

This is based on the assumption that Sony didn't change how they stored the configuration data in IOP RAM, which I doubt that they did. I believe that they only change the hardware as much as they can, but seem to not change the software-part too much to avoid conflicts.

Well, I think that it's a bit early for a formal release, but I think that I'll reveal this page that has been on my website for a long time: http://ichiba.geocities.jp/ysai187/PS2/OSDConfig.htm

The configuration starts at offset 0x300 of the EEPROM in all early consoles, up to the v8 (SCPH-39000 series). Newer consoles have this region moved to a different offset.

The OSD settings (Accessible via the EE kernel syscalls) are recorded in two blocks starting from block 1, while the DEV9 settings are stored in block 0.

On the webpage, the OSD data shown there start from block 1 (Offset 0x310 in the EEPROM).

So to add on to the table (Based on what we have observed here), bit 1 of byte 0 of block 0 is for enabling/disabling ATA support, while bit 2 is for toggling whether the DEV9 interface should be powered-off or not, after the KELF has been read.

I don't know, but just maybe... the HDDOSD setup disc might adjust some of this values. I don't remember when I toyed with the EEPROM of my SCPH-39006, but it might have been after I ran the HDD Utility disc on it. That might explain why I remembered that my SCPH-39006 once booted the hacked HDDOSD off the internal Seagate 80GB HDD without power-cycling the disk at all. (And it also explains why it now does - I restored the EEPROM back to a backup made in 2010)

Maybe I'll run it again someday. Who knows, maybe it does automatically set bit 2...
(If it does, then it's probably safe to assume that this behaviour we are observing is typical of freshly-unboxed consoles that were never setup with the HDD Utility disc)

EDIT: Forgot to mention: Special thanks to "[RO]man, Herben, others" for the pseudo code of rom0:EECONF, which I studied.

 

Thanks very much for the precious info:love-struck:.

The HDDOSD of the Jap utility disc is English/Japanese only. Western texts aren't definied. I think it might be possible to hardcode the 'JapLanguage' flag in the HDDOSD instead of writing a loader that plays with the SetOsdConfigParam syscall; to make Japanese language selectable on US/Euro/RUS units. I'll certainly verify this theory as soon as SUDC2 is released.
Do western units have Japanese FNTIMAGE and TEXIMAGE components in their BIOS ?

 

The HDD OSD specifically checks ROM0:ROMVERSION to determine if it's running on a Japanese console. Messing up with the osd language flags will have no direct effect.

Edit: Running the Japanese OSD on a non Japanese console enables the other languages to be selectable as what happen with the USA OSD. But the Japanese OSD lacks some data for the European languages which result on odd glitches when setting it that way. It only has data for English and Japanese.

 

Pfff, my silliness. I've signed the KELF with the wrong Bit Key. It caused a HDDLOAD->MBR->FSCK loop. Fixed.
The problem with the PSBBN 0.20 installer is solved too. The main program couldn't pass args to HDDINST.ELF because of the way the auto VMODE switcher was coded.
Sad... I've no more MCC 03RG20. I'm forced to burn my test discs to trashy UME02, which do retarded Star Wars sound effects on the PS2 CDVD drive due to MASSIVE read errors. Even worse, see my poor Swap Magic 3.6 DVD. RIP.

rom0:ROMVER ? I always thought it was open by the OSD/HDDOSD to determine the PAL 50Hz/NTSC 60Hz video mode and X/O buttons assignment from its 6th byte. Then later I bought an European SCPH-75004 console that has a 0220JC20050620 ROMVER.
I'll try to make the HDDOSD read a custom ROMVER from mc0:/ROMVER and see what it does...

Yep. That's why I'd like to turn the Multi 7 language selector into a Japanese Multi 2 language selector, with English as default if the language value of the NVRAM is "out of bounds".

 

If you look around the offset 0x8280 in the hosdsys.elf (1.10) decrypted payload there's the code that check the OSD byte on the ROM for figuring out button mapping and languages to set. I'd bet the older OSD uses the same code pattern to achieve that effect.


Edit: I'm very interested on you guys work on the DVD players. I would love to have a region free DVD player installed on my memory card.

Any possibility of arranging that ? I don't like the idea of having them on the HDD.

 

It's more elaborate than that. If it's a Japanese console, it can only be English/Japanese. Other consoles (Only Asian, American and European consoles) can have any language other than Japanese.

Summary of the language check in all OSD versions (Excluding the Protokernel's OSD):
The OSD will determine (based on the region character in rom0:ROMVER, must be either "E", "H", "A" or "J" - anything else will fail) the region that the console is from (J = 0, A and H = 1, E = 2).

It'll then determine the languages available. 0 = English and Japanese only (Checks for only 0 or 1 in the language field). Otherwise, all languages but Japanese can be chosen (It has to be not Japanese).

If the EEPROM contained an invalid language setting (i.e. not listed in the table on the page I linked to) or the console is not a supported console (Not "E", "H", "A" nor "J), it'll default to English.

By the way, config.region seems to be hardcoded into the OSD, and that value gets set into the kernel with SetOsdConfigParam(). By right, it seems like PAL consoles have it set to 2, while all NTSC consoles other than Japanese should have it set to 1. I think that Japanese consoles have this set to 0.

It could have been a nice way to determine the video mode to be used (Other than just calling SetGsCrt() with mode 0), but using the wrong OSD version on a console will make such a check invalid.

Me too! The DVDs I have here are occasionally out of my region.

I don't know, as I don't even know what those folders are for.

I know that the OSD has been using rom0:FONTM, which contains the Japanese characters. The first literation of the OSD, which came in the Protokernel boot ROM, doesn't have the FNTIMAGE and TEXIMAGE folders.

 

On all "fat" consoles, the letter on the ROMVER string determines the region and will cause the OSD to decide if it will behave as "Domestic" or "Export" OSD.

For SP193: Because you only have access to Chinese recent consoles to study, you have a wrong reference as these units have CUSTOM BIOS (due to having Simplified Chinese as language instead of Japanese). \


All PS2 System Software (Rom or HDD software, regardless of type) fully support Japanese and have the required fonts for proper display of that language.

Newer consoles (starting at 7500x) use a new mechanism to determine the region so the ROM will be "generic" and the ROMVER string cannot be trusted if read directly from ROM. You're supposed to use the currently loaded ROMDIR driver to read it or else you will have whatever is on the ROM (remember, the ROM is generic and it aways defaults to Region 0 aka Japan) instead of the properly patched ROMVER string. The Region is defined by a signed chunk of data at the footer of the MECHACOM eeprom on these newer consoles.

edit: This is the reason why "Green DOT" Matrix infinity modchip was required to mod consoles after 7500x series.

 

This is how I crack DVD Players and how I make them stand alone :

- FROM MC BASED FIRMWARES -
I decrypt and unpack dvdplayer.elf and dvdplayer.irx
From the IRX I obtain a ready to use IOP replacement image.
I do some hackery on the unpacked dvdplayer.elf (described later)
I write a simple loader which embed everything.

- FROM EROM BASED FIRMWARES -
I dump, decrypt and unpack erom0VDELF
With rom1 modules I build an IOP replacement image.
I do some hackery on the unpacked DVDELF (described later)
I write a simple loader which embed everything.

The loader does an IOP reset with the embedded IMG, loads the embedded DVD Player executable at 0x00200000 and executes it from its Entrypoint (0x00200008) with the "erom0:" arg. If no "erom0:" arg, the Memory Card is checked for BxEXEC-DVDPLAYER/dvdplayer.irx and the DVD Player can't start.

- THE REGION FREE HACK -
DVD Players lower than 2.16 are very easy to crack.
Just search for :
18 00 07 B5 20 00 22 8D 20 00 02 AD ## 00 02 24
Replace ## value with 09.
In this function, ## is the DVDV Zone the DVD Player allows to play. 0x09 = Zone "ALL" (or Zone Free)
I kept a note of a few RAM addresses...
1.20A
0024D6DC 240200##
1.20E
0024D6DC 240200##
1.20U
0024D6AC 240200##
1.30E
00249FCC 240200##
1.30U
0025416C 240200##
2.00 (Jap)
00256ECC 240200##
2.01 (Jap)
002597FC 240200##
2.02 (Jap)
00259F5C 240200##
2.10A
0025A454 240200##
2.10E
0025A454 240200##
2.10J
00259F5C 240200##
2.10U
0025A3E4 240200##
2.12J
0024C65C 240200##
2.12U
0024C99C 240200##
2.13E
00249FCC 240200##
2.14 (Jap)
0024A40C 240200##

That routine does not exist on 2.16 and higher. $ony also added a nasty protection that breaks the execution and wipes the memory if a code modification is found. Probably for stopping the production of "DVD zone unlocking" softwares. Search for "A5 A5 C6 34" or "A5 A5 A5 34" to find things to NOP.
RPC hack now. Search for "01 00 05 3C 04 28 85 00", it will take you to the function that reads the DVD zone from the buffered VIDEO_TS.IFO.
Follow the ld, mark the DWORD, search for its relative STORE instruction and NOP it.
Now go back to the Get_DVDVzone function, mark its start, find its JAL and replace it with "00 00 02 24".

Hope I didn't break forum rules by posting this tuto...

I'll send a PM to you both as soon as possible, with a pack of 42 hacked DVD Player versions...

 

Thanks for sharing that very detailed information ! m(_ _)m

 

Really, really, really impressive!

I took a quick look at the spreaded hdd ps2 image.
Let's talk about the "res" folders inside the partitions.
Seems to be brilliant because it's shorten the way to get the needed result.
Where are the needed tools for that?
;D

The dvdplayer thing would become interesting when it disables the f***ing green via rgb.
Sorry of...


Greets and have a nice day!

 

The dump as is, is a piece of sh*t. It is only useful for "educational purposes" and gives a physical example of how to put a valid partition icon, in combination with richi902's tutorial. I recommend everyone to do a proper installation using the hacked Utility Disc (mine, not Hackchips') when it's possible, instead of writing that ugly "HDD Snapshot" to the HDD.

I personally use no tool for that. Resources are just a UTF-8 text file (info.sys) and regular 32 bits PNG images. Image resolutions must comply the PSBBN specification, described in "About PlayStation BB Navigator Game Channel Icons" documentation (from $ony PS2 SDK).

Agreed. And enabling the Progressive Scan on < SCPH-500xx too.
I reverse engineered Dat£l's DVD Region X a while ago. It uses the SetOsdConfigParam to force the Y Cb/Pb Cr/Pr video output, so it pwns the green screen thing. After that, I guess the DVD Player vomits the signal thru composite pins of the SCART (I didn't test it myself).
As for Progressive Scan, I didn't investigate but I'll not be surprised if it's a matter of ROMVER or GSrev.
My current goal is to gather as much DVD Player versions as possible, analyse them and put them a RPC hack. Macrovision and Progressive Scan is not for tomorrow, unless someone with required knowledge does advanced DVDPFW disassemblies.
Versions I've RPC hacked are 1.00J, 1.01J, 1.20A, 1.20E, 1.20U, 1.30E, 1.30U, 2.00J, 2.01J, 2.02J, 2.10A, 2.10E, 2.10J, 2.10U, 2.12G, 2.12J, 2.12U, 2.13A, 2.13E, 2.14J, 3.00E, 3.00U, 3.02C, 3.02D, 3.02E, 3.02U and all 3.1x slimline based versions. (3.1# versions use a USB MASS launch method for now).


@Segment_Fault. Can you do me a favour and add me to the blackbone ? My net connection sux. Thanks in advance.

 

I guess it's some sort of chip ID being used to enable progressive. Taking 3.11 (from a slim) from your kit to a 5000x causes progressive scan to be available. Putting it on a 3000x causes it to disappear.

It could have to do with the version of the Digital video encoder (yeah that chip is setup through the SPI port at the DEV9 interface so finding anything related to that without know where to look will be a tad complex).

Another comment, the SCPH-10000 and 15000 will only work properly with Japanese drivers (the Japanese drivers are coded to be compatible with the PROTOKERNEL ROM0) while DVD drivers of other regions will boot, load and play discs, the playback will be horribly choppy.

 

Thanks for the quick reply!

Yes and no.
Okay, currently i have definitely no time but that was so interesting i took the time to have a closer look at that images.
I earned the atad patched files. Quite enough to say that was good to take the time...
;D
And i wink where to get your util-disc for testing would be great...

I know all the things about the ps2 icon file format.
As i remember the icons are in the final state 16 bit color depth.
So, for me there must be a sense to generate these folders.
I thought one option for that could had been a new (own) filesystem that writes automatically the datas at the correct partitions positions...

First at all chapeau for the work. I tested the newer one players (3+) at a v7 with no probs at all. But all in green.
One big question is still there for me: How to use them in "harmony" with fmcb?

Yeah, the green-rgb-fix is really needed.
I could not understand why this is so hard to make.
All mod chips had been hacked and these data have the key to rock the ps2 world.



So finally i must go back in my 19" cage to check the systems,
all have a nice day!

 

Thanks for the idea.
Yep it's gonna be hard for me to hunt for and defeat such a function, as I'm not familiar with hardware identification powered things...

Thanks for the tests and feedback. If I remember well, there's no code difference between Jap and US DVD IRXes of a same DVD Player version, except the UDFIO driver. I'll check that later but I guess a "fix" for that issue would resides on EE side (in the DVDELF itself).

You are welcome.

ATAD patched files are the same on my hacked Util Discs. They weren't "pasted" to the HDDIMG with an hex editor but installed by the Utility Disc itself.
Maybe later I'll compare those patched files with originals and post a list of differences and a few explanations about the "corruption point" concept, in case someone is interested...

My bad, you are right.
Filename: jkt_001.png
Format: PNG 24 bits (no alpha channel)
Size: 256 × 256 pixels
32 bit is the copyright banner.
Filename: jkt_cp.png
Format: PNG 32 bits (with alpha channel)
Size: 290 (w) × 46 ~ 300 (h) pixels

You mean for the "special" HDLoader partition type right ? Yep, or a Filesystem hack that could handle a standard PFS TOC and a small room for the "res" files/folder storage, within the parent HDL partition. Kinda complex.

I have no idea, I don't use FMCB. FMCB is an ELF launcher right ? If so, it can't launch them as they come out from the HDD because they are KELFs.
I'll send you the pack of DVD Players as ELF in a few minutes...
One other thing you can do is to bind one of the DVD Player KELFs for use with your MC. There might be a signing tool somewhere, or maybe the FMCB installer allows to CARD sign KELFs, I don't know...

Mustn't be that hard, but there might be a better method than the "known trick" to hack that thing. What I call "known trick" is the method used in most (or all) softmods to screw the green screen. It forces composite video output in the OSD.
As for modchips, I don't know what's their Macrovision sabotage scheme... I shall take a good look.

I'm stuck with stone age swap discs . But have no regrets when I see how a Matrix/ModBo causes MG decryption to f**k up. My buddies reported tons of false-positive bugs during pre-release tests of my shit, because of modchip interferences.

SUDC2 pre-release tests are over. I'm gonna pump it out somewhere and PM you a link. These utils don't install custom apps, additional partitions, special icons, make your console waterproof at 20 Ft. They just do what original discs do, HDDOSD/PSBBN installations, but with ATAD prepatched files. It saves you some file replacement and MBR hexedit. Then it's up to you to arrange your setup.

Regards.


EDIT : If needed, ATAD patches for HDDOSD KELFs...
HDDOSD100U_ATADPATCHES.zip
HDDOSD110U_ATADPATCHES.zip
Hope the PPFs are correct. Contain no $ony code btw
Jap HDDOSD and PSBBN 0.32 later...

 

ATAD patches for the Japanese HDDOSD (whch is installed to the HDD by Utility Disc v1.00 PBPX-95211).
I couldn't test these for technical reasons. In the worst case scenario, it may result in data loss. If someone wants to give it a try, the use of an empty HDD is more than recommended, just in case I didn't crack those things properly and a format/erase/delete cmd is issued:wink-new:.

EDIT : Removed (Patched the wrong JAL, my dumbness..., sorry)

Please post a feedback if you've tested patched files.


PSBBN is harder to patch. The ATA driver is packed twice, first time in the modrt IOP updater (an IRX which looks like a dvdplayer.irx and does pretty much the same job), second time in the MG crypted ELF. To patch this raw KELF with the "corruption point" method is almost impossible.
On my SUDC2 and PSBBN 0.32 A2 discs releases, osdboot.elf is patched from its unpacked state and reinjected into a DVD Player KELF.
Anyway, I'm gonna try to patch the RAW KELF just for the fun of the challenge, but if I succeed, I'm sure that the unpacked code will be mutilated as f*ck:wink-new:.

EDIT 2 :

You were right. Thank you. I messed up with switches that follow the rom0:ROMVER parser and managed to turn the Japanese HDDOSD Multi2 when run in my European unit. Buttons are swapped, OSD is restricted to English/Japanese... and the VMODE is PAL 60 Hz:moody:.

 

Hi, krHACKen!

Thank you for your work.

Is this forced? Could make probs for others...

Have you modded the mbr, too?
I noticed a different double byte. Maybe i am wrong.


Rgds.

 

The video mode setting is derived from the OSD configuration, if I'm not mistaken. The rom0:ROMVER check is only there to restrict the available language options.

In fact, if you disable that check, you should be able to set any language in the OSD configuration without using the OSD, and save it to the EEPROM (Although, it'll be reset again if you boot an unmodified Sony OSD).

 

Ahh, that makes sense. I was wondering that the HDOSD was at the first time in 4:3, not in fullscreen mode.
So, we have to live with the "presets" of the given files!?!


Rgds.

 

Yes, forced but "conditional". It depends on the ROMVER region (A/E/J). I don't get why it's shown in 60 Hz in my European console. Video standard of European unit is PAL 50 Hz, not PAL_60. When the HDD OSD is run without that hack, it is shown in PAL 50 Hz. Anyway, I'll build a PPF if that thing can be patched straight to the KELF with the "corruption point" method:biggrin-new:.

On my HDD OSD 1.00J hacked discs, the MBR comes from the HDD OSD 1.00U if I remember correctly. fsck and hosdsys are reinjected ELFs so they don't match original HDD OSD 1.00J KELFs.
The "corruption point" method used to patch packed ATADs is not "generic". I mean changed bytes/values are not the same from an ATAD patched KELF to another. Hard to explain. I tried to write a documentation about it, but my English sucks so bad that it doesn't make sense.
If you see header differences between files from hacked discs and PPF patched files, it's just because my PPFs don't have MG zone/hashes patches, just the ATA driver patch.

There are at least two ROMVER checks in the uncompressed hosdsys. The one responsible of the language option also affects the VMODE in a "strange" way.
I played with presets of cases "A" and "E" (can only test the case "E"), and it turned the display to PAL 60 Hz instead of PAL 50 Hz or NTSC. Maybe I misunderstood the function...

I also tried to completely "disable" that ROMVER check. It made garbage. The OSD is restricted to English/Japanese, but the display is slowed down, does frame skips and glitches.

I made ATAD patches for the Japanese HDD OSD. I'm testing them with some launchers before I post "trusted" PPFs...

 

Just letting you know, "A" is a designation for SCEA consoles (United Stated) but for some reason God only knows, SONY also uses "A" for certain Asian consoles. The HK consoles I have on my collection read KELFs from BAEXEC-SYSTEM and BAEXEC-DVDPLAYER.

And the video system that is popular in HK happens to be PAL60 (their TVs can do either most times so they stick to 60hz due to NTSC-J being their disc region...)