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

Exactly!

Ah. Now it makes more sense. Thank you.

My tool was based on someone else's... but I honestly just don't remember whose code it was. :S

Wow!

Ah. I can't wait to see how this turns out.

Yes, thank you.

I understand. Personally, I always run into that issue... which is why a lot of my projects have been progressing really slowly (If they are still being worked on at all).

Thank you!

Personally, I will be more interested in knowing how the LBA numbers are calculated, since the function that does that within the MECHACON is not replicated in the source code of PCSX2 (Command 0x1096).

 

Funny. It seems i was wrong and yes, i think the game saves are stored there, too.
Normally i know this kind of parts as firmware storage.

And thank you krHACKen to have a closer look at your brilliant work.
:applause:


I don't want to break the current very interesting discussion, but we are light years away from the title of this thread.
Hope here's enough space for hdd icon ideas/discussion, too.


Rgds.

 

If you are so interested in finding out, go find a copy of the Sony PS2SDK and look at their documents for making HDD software installations. It's not a deep secret like signing stuff, so it's still documented.

 

Done. The new dump isn't 2.01, but 2.12. It matches the SCPN-60101 package. For some reason his disc didn't overwrite old ver and id files. Even more confusing, the KELF header has 2.01 version instead of 2.12... Thanks to the dumper for his time and the effort anyway.

I don't know how it's calculated. PCSX2 has been coded to return a static CDVDkey because physical data of pressed discs that is used to compute the key (input data for MechaCon voodoo) can not be copied/replicated/burn (same for the "DNAS ID"). I bet the PCSX2 dev who wrote that static key for cmd 0x1096 also played with Utility Discs (the comment says all, "// 0x0001F2F707 = sector 0x0001F2F7 dec 0x07
", LOL). sceCdReadKey 0x1096 is a part of the SUD copy protection stuff and isn't used on retail games as far as I know.
The only thing I know is sceCdReadKey is CDVDMAN #35. The command is passed like that : sceCdReadKey(int unk_arg1, int unk_arg2, u32 cmd, char *output).
cmd is 0x1096, output is returned data (16 byte long CDVDkey IIRC).
1st byte of the CDVDkey is "transformed" by the Utility Disc sub-program and passed to sceCdDecSet (CDVDMAN #35). Referring to the PCSX2 src, the 5th byte of the CDVDkey may also be used by sceCdDecSet. Bytes 2, 3 and 4 of the CDVDkey combined together is the LBA of the scrambled wobble, passed to sceCdRead (CDVDMAN #6).
The wobble is unscrambled in the same time it's read and buffered by sceCdRead, because sceCdDecSet was previously called.
Not over yet with $ony's gadgets. After sceCdRead is over, the sub-program deobfuscates a part of the unscrambled firmware package header with its own algorithm. The algo of PBPX-95201 and PBPX-95202 is quite simple :
unscrambled[44] ^= unscrambled[0];
unscrambled[45] ^= unscrambled[1];
unscrambled[46] ^= unscrambled[2];
unscrambled[47] ^= unscrambled[3];
unscrambled[40] ^= unscrambled[4];
unscrambled[41] ^= unscrambled[5];
unscrambled[42] ^= unscrambled[6];
unscrambled[43] ^= unscrambled[7];
unscrambled[36] ^= unscrambled[8];
unscrambled[37] ^= unscrambled[9];
unscrambled[38] ^= unscrambled[10];
unscrambled[39] ^= unscrambled[11];
unscrambled[32] ^= unscrambled[12];
unscrambled[33] ^= unscrambled[13];
unscrambled[34] ^= unscrambled[14];
unscrambled[35] ^= unscrambled[15];
BUT, the algo used by most Utility Discs is more badass than this n00b thing. I didn't reverse it yet. For now I'm stuck with my hacked Utility Discs (old A1 Hacked Builds) that do the deobfuscation job by themselves. I just run the installer and take a RAM dump @ 0x01800010 when the job is done. Then I inject the clear KELF package into a Hacked Build A2 (A2 builds have all unscrambling/deobfuscation functions deactivated), and voilà.
However I'll have to face that algo if I want to finish my PC proggy and refrain from using $ony copyrighted programs.

An overview of how an Utility Disc operates :
The ELF linked to SYSTEM.CNF is executed, and it executes a KELF (one of the VOBs).
The KELF does sceCdRead from sector 200000 to 202048, buffers read data to 0x00200000, XORs the buffer 0x00400000-0x00600000 against 0x00200000-0x00400000, and executes what I call the "main program" (resulting from the XOR operation) @ 0x00200000.
At this stage, you see the main screen (or eventually an error message if the main program did SifExecModuleBuffer of an ATA Driver and sh*t happened).
Select the DVD Player upgrade option and the main program runs a KELF as a thread. This KELF is what I call the "sub-program". It is loaded at 0x00100000 and opens hell's MagicGate.
Sub-program does :
- SecrAuthCard (Authentificates MC Hardware for pre-CARD signing operations. Bad Chinese clones say good night)
- sceCdReadKey 0x1096 (Gets the CDVDKey. CDR/DVD-R backups have none, here they fail)
- Transforms the first byte of the CDVDkey for use with sceCdDecSet (0x05 to 0x53, 0x07 to 0x72... Hmmmm.... How ?)
- sceCdDecSet 0x53 or 0x72 (Initialyze the MechaDecryption of the scrambled data, with the above "transformed" byte)
- sceCdRead (Reads from the sector defined by the CDVDkey. Does the MechaDecryption simultaneously. Data buffered to 0x01800010. Length is the value defined by the 4 first bytes of the wobble, divided by the sector size)
- sceCdDecSet 0x00 (Terminates the MechaDecryption, so files of the disc can be read without garbage)
- CdStop (And maybe Sync too, to restore the CDVD drive to a good state afer all this mess)
- Deobfuscation of the unscrambled data (It concerns bytes from 0x01800020 to 0x01800040 on most Utility Discs)
- sceSecrDiskBootFile and stuff... (Here it MG decrypts the "final" firmware package, as KELF of course)
- Unpacking (The MG decrypted firmware package is unpacked by the sub-program's internal function)
- SecrDownloadFile and stuff (Here it CARD-sign KELFs and IRXes of the unpacked firmware package. See FMCB for moar info hehehe)
- Returns success or failure.

Here's a purified version of S.U.D Mutilator : MUTILITE.7z
The old proto was full of hazardous functions that caused unwanted effects and contained a bunch of.... disturbing MG features. So I wiped everything out, left the sceCdReadKey call, updated the disc labed database and commented the src.
And a demo : http://youtu.be/e6awEZLIOHk
Sorry for the bad quality. YT ruined it and I'm too tired to record another one.

EDIT : Ffuuuu, I forgot to include the source code before I sent it to the trash bin:dejection:.

 

Hi!
You are joking, aren't you?

That works for me since years and i made a video of my work years ago.

Reading the title of the thread i though maybe a tool for everyone could be a result of the discussion.
Okay, i am quiet and don't want to disturb.


Rgds.

 

No, he's not joking. It's docummented on the SONY official SDK. The only thing that isn't documented there (and it was discovered by SilverBull after some reverse engineering on the HDD OSD main KELF after unpacking) is the fact that the HDD OSD and PSBBN accept an KELF (Krypto ELF) and a KIRX (Krypto IRX) embedded into the Partition Information (PATINFO) region of the partition. That is the bit of information that isn't documented anywhere.

And really it's just two extra numbers with a sector offset and length in the same format as the previous values. I know you're familiar with the size and offset values for icon and user message datas on the PATINFO region ...


Again as I replied to the OP, currently Kermit has a option specific to install the OSD data on installed files. While HD Loader and other scene tools perform the install automatically, on KERMIT you're expected to give the command yourself. Also it will use the standard HD Loader icon but will insert a "KERMIT ODEM" text on the title name for identifying the partition accordingly. Also it will install the it's bootable STUB or my MINI OPL (as a DISC signed KELF named HDDLOAD.KELF) if it's put on the same directory it's launched from.

What is missing at this point is a tool to make icon and OSD description editing/injecting automated. -_-;


And I don't think you're disturbing ...
You're just a tad vocal on your interests. There's nothing wrong with that, but I'll defend my positions as well.

 

Yeep, your screenshot is here in the hall of fame.
:friendly_wink:
And please show me anyone who is working on this and don't have multiple sdks for the ps2.

I know. Not useful if you wanna the complete possibilities.

As stated before we are talking about of an ~2MB data block at the beginning of a partition.
A tool with the ability to inject/embed icons and (k)elfs at the right place with auto fix values would help the normal user a lot.

Wrong. I don't have probs to modify a ps2 hdd for my needs. That costs me a day.
I am working on that for such a long time so i only need to have a look at the servers...
And i am not willing to discuss our different positions of special themes.



Have a nice day.

 

@krHACKen: Thank you for sharing! Sorry to hear about your source code though. :/

Have you tried recovering the deleted files with an undelete program?

@l_oliveira: Thanks.

@fresh: I would have built something like that, but I cannot promise anything now... hence why I kept quiet. If you have the means to complete such a tool, just go ahead and do it.

As for the KELF installation specifics, it's obtainable if you reverse-engineer the HDDOSD. It's not even obfuscated.
Sony made their HDDOSD so that it's not mandatory to have a KIRX.

Once you make a basic program for installing/updating the icons, we may help you with the KELF installation stuff. No binding is required as it's a DISK KELF.

But what's the point in making a KELF installer? You still need to be able to create KELFs...

 

All this talk ultimately leads to the following argument:


What's the point of using SONY OSD when you're stuck with a 120GB HDD ?

 

@sp193
Unfortunalely I couldn't recover it. It has been physically overwritten by another file. Oh, not a problem. It's easy to code, I'll rewrite another one.

@l_oliveira
I made a 48bit mod of the HDD OSD 110U in 2010. It was unstable and slow (a DMA issue) but I'll share a PPF for the decrypted/unpacked ELF if I find it. Of course "retail" games that are installed upper the 28bit limit will not work.

 

Was the ATAD IRX module replaced, or was it just patched to not require a "Genuine SCE HDD"?

If it was replaced, can the whole disk be seen? l_oliveira was saying that the HDDOSD can only show 128GB at most, but I personally believe that it's related to the ATAD module that is used.

I don't remember what he did to "ATAD-patch" the HDDOSD, so I don't know exactly what is responsible for that limitation actually.

 

Funny enough, the XBOX (the olive-green 2001 one) also had 28 bit IDE hard coded in it's kernel ... MS had the XBOX kernel sources leaked somehow in 2003 and then things like Xecuter and such happened... lol We don't have the source code for SONY stuff, for starters.

Also, I don't think SONY software engineers were bothered with the prospect of the PS2 getting more than 137GB of harddrive anytime on it's lifetime. I bet even the PSX DRV do limit what is visible to PS2 games from it's internal harddrive to something around 40GB. By this I mean the code on other parts of the program (not only the low level access drivers) will not deal with 48 bit LBAs correctly.

My point is, we should cease attempting to hack the OSD to support more than 120GB drives and focus on making it usable as it is. For people who desire larger drives, something like uLE/FMCB but staying at the MBR sector.

Hacking the OSD beyond making it work with any harddrives is waste of time in my humble opinion. Time that could be used into making a proper launcher for apps which could be installed on the HDD MBR.

 

There were 2 different hacks. One was the injection of a patched HDL ATAD. The other was an injection of an ATAD that has been wrote and compiled with the official SDK. In both hacks, the HDDOSD "supported" 48-Bit LBA HDDs.

I didn't fill the entire HDD to see if all partitions can be accessed. However the HDDOSD reported the correct available size and didn't hang/freeze/crash. Display of partition icons was slow (like when you browse a Datel GateCrasher Memory Card). I may be wrong but I guess the limitation is due to the ATA driver and perhaps another module and not to EE side code.

I agree. I stopped attempting to properly add a 48-bit mod because I've no interest in eating 128 MB for each bootable thing or scrolling down the slow ass HDD browser for booting the 1st installed game on a 124GB+ HDD. I don't even know where I did put my hacked binaries. Anyone can replace the hosdsys with another hacked KELF to boot their favorite homebrew at console startup. A fine thing would be a user-friendly tool to automate the installation of apps to the HDD OSD. I know many people were whining for such an installer. I definately don't want to put more pressure on devs or add my 2 cents in the "gimme your hard work" list. Just saying why adding more icons/partitions to the HDD OSD (with a 48bit "patch") seems worthless to me.

 

Ahoy!

Currently the hardcore freaks put a 2TB HDDs in their xbox. The key is here 64k sector sizes and to have 2 big partitions plus the standard ones.


Okay, 120GB. How many games is this?
For me it's enough for the most game highlights and the needed tools. But a 128MB partition for a simple tool is a bitter pill.
And the rest of the games could be played via samba and the nice opl.

Are there any results of the psx research? I read the hdd recovery threads.

So if i understand we have to test these with a game filled hdd?



Rgds.

 

Greetz !

Smells more like a W4rezer sextoy rather than looking like a mediacenter of family movies, hihihi.

The thing is that a 48 bit patched HDD OSD loads data way slower than an unmodified HDD OSD. Something like 3 or 4 seconds for displaying one partition icon. So slow that you can drink a beer and watch a pr0n magazine while you press the down button before you launch a game. Even if someone fixes it, OPL would always list games faster than the HDD OSD does.

Well, such a hack should be fully tested before it's released. Not only for the hacker to learn how things operate, but also to make sure it's 100% working. It would be a disgrace for me and a real pain for end-users if my stuff has not been verified prior the release and is causing data loss:concern:. Actually I'm not certain that patching the HDD OSD's ATA Driver allows it to reach last sectors of high drives, so yes I'll have to fill a large HDD >137 GB and see how it reacts.
All I can envisage now is worst cases (data loss of read error), until I eliminate all my assumptions.


Going off topic again for great justice.

kHn's SUD wobble finder v0.01
A "decent" (crappy but works) initial build. A log here : http://pastebin.com/289eJpc5
Hope someone find it useful. Please don't laugh at the source.

It would be very much appreciated if owners of DVD Player discs and PSBBN 0.3x could PM me dumps of these. For educational and preservation purposes. Thanks in advance.

 

Hi!

These words saves my day!
:biggrin-new:



Is there any way to get/rip the original osd/hddosd icons?
MC, HDD, etc. pp.


Thanks and have a nice day.

 

Easy stuff ....

But really there are different icons depending on the version of the OSD you extract them from. Only the HDD OSD have the HDD related ones, of course ...

Some of them: (I didn't rip all of them and that was a while ago, too)
View attachment 5006

 

Thanks a lot!
Does it mean they're native in an unpacked osd?


Rgds.

 

You mean, they're in the same format as the icons games use on MC saves ? Yes they are.

 

Yes, i meant in the native ps2-icon format.


Here's an evil-ule icon i made a few month ago.
Have fun.
View attachment EVIL-ULE-FINAL.ZIP

BTW: I have a strange effect.
When booting the krHACKen hdd-osd and entering the browser,
i can't select and enter the icon on the mc via the x-button.
Have i missed something?



Rgds.