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

I know someone knows how to do this but I've tried to do this myself and all I get is the blue cube for Corrupted Data on my HDD.
I'm trying to do this for Mini-OPL/KERMIT, I try in winhex (Hex Editer) to add the save icon from the game to the Partition icon but I mast be doing it wong.
I know I'm not doing it to the MBR of the HDD. If someone knows how to just edit the icon on KERMIT, that be great.

 

The install menu has a option which installs the icon. Even if you don't have a boot KELF to install, it should still work and add the icon and game name.

 

Does that work for the Icons from the game saves, I'll try looking for this option in Kermit. Thanks

Also I'll like to try to add the real Bishi Bashi Special 3 game to Bishi Bashi Special 3 demo, can it be done? The real game is lass then 128Mb
and I have the demo working in my hdd (Non-Sony 120GB)

 

Kermit puts a fixed icon there. It uses the icon from HD Loader as placeholder. It has no option for customizing . (it's a good idea though, you could try to suggest that to the author, he posts here...)

Now, I am curious about how you made it work on a non sony HDD. That's something I was never able to do.

 

Well it form http://www.pspx.ru/forum/showthread.php?t=101273 site is not in English
It's in the HDD image download of the PSBBN 0.32 in English but it boots HDD-OSD, It hack to work on all HDD and I’m not sure how but they add 5 PSOne game to the HDD image
Bishi Bashi Special 3
Yaroze Rally(Net Yaroze)
Naunted Maze(Net Yaroze)
Blitter Boy(Net Yaroze)
Alien Looter

I try Bishi Bashi Special 3, at 1[SUP]st[/SUP] and it was not working at all. I looking in game dir (PP. SLBB-00001) and no “disc” folder or “disc0” I looked in the other 4 PSOne games and they all have a “disc” and “disc0” I copy that to it and now it works. (disc0 is like the PSOne BIOS?)

Hope this helps

 

Can't it have the ATAD driver patched or replaced?

 

That dump is broken as hell. Missing files, missing partitions, crap loaders and tons of bugs. I don't get why guys spread the same test dump when a "stable" release is available.
disc0 is the disc image of BBS 3 (hence the name). Other games need it to boot because emu hacks are POC. The PSone BIOS is embedded in the emulator KELF.

kHn used a dirty trick for patching the ATA driver. He took original KELFs and corrupted a packed block so when the executable data is unpacked by the stub, the AtaSecIdentify JAL is NOPed:congratulatory:. Zony was kind enough to not encrypt this crutial portion. The region value is changed and the header is rehashed as well.
The BB Navi 32 has an extra firmware check on EE side, making modchip patchwork fail.

EDIT : I'm doing SUDC2 prerelease tests. It seems that kHn messed up the ATAD patch on Filesystem Checkers. Clicking noises (reboot ?) and black screen of death.

 

Clicking noise is normal and happens on ANY PS2 with BIOS revisions newer than 160 (3000xR) because it's HDDLOAD module does ATAD check twice instead of just once.

First check it checks if the HDD is SONY. And if that fails the PS2 power cycle the HDD then tries the old method from SCPH-3000x and if that succeeds it boots the MBR.

So anything never than SCPH-3000x will have the HDD spinning up twice on boot.

Finally be careful with the disk wipe utility on the PSBBN. You don't want to include that anywhere lol.

 

What's the "stable" release? I'll like to try it.
I'm not seeing the bugs in it, well the only bug in it I can see that ESR does not work but i can use the .ELF.

 

Really? I should re-check my work then. When I reverse-engineered rom0:HDDLOAD of my SCPH-39006, it didn't have any ATAD checks at all.
And I am quite sure that my SCPH-39006 was once booting the hacked HDDOSD without power-cycling the Seagate HDD unit I have, but I don't remember whether I did anything else to it. It is now power-cycling the HDD unit though (Ever since I reformatted the disk and reinstalled the files on it - although I am not sure whether they are the exact same files). :/

I saw that the ATAD checks begun at the Sony MBR, and goes on in the HDDOSD too.

 

Well one thing I tell you.

My old 10 screw US PS2s run any HDD I put on them and the console only powers off the drive if it can't find APA headers and the MBR.

That behavior is proven true to all motherboards from B-Chassis until D-Chassis (GH-004 through GH-013) excluding AB-Chassis, which is a PCMCIA type unit.

Starting on E-Chassis (GH-015) the BIOS first checks the HDD for security then checks without security if the first check fails. The exact underlying mechanism I am unable to explain because I never disassembled the modules in question. This behavior is on par with the behavior the loaders residing on memory cards have, exception being that the MC based OSD HDD loader doesn't run the second check, completely refusing to check the MBR if the drive does not respond to the SCE specific commands.

 

Not only ESR, but a section for music PSBBN (5 GB) is not working. Partition is created, the music is copied, but the choice hangs. ESR you can install yourself (see tutorial Richie).
By the way, subscribe to the issue: where to get a stable release?

 

Amazing work on this for whomever is doing it.

But PSBBN is slow to a crawl and honestly I like the normal SONY OSD better.

I would like to help (not that I can think of anything I could do to help besides testing with several console types) and maybe giving him my already hacked loaders for PCMCIA consoles.

 

Alright, I took another look at the part of HDDLOAD (From my SCPH-39006, boot ROM v1.60, HDDLOAD v1.00) that I couldn't understand the last time, and it might be some black magic by Sony.

Like I thought - there are really no security checks, and the OSD will only try to boot the HDD's boot loader only once (Yes, I took a quick look as OSDSYS as well).

I found that the funny code loads a value at 0x3C0, and logically ANDs it with 2. If that bit isn't set, it switches off the DEV9 interface. I don't know what the purpose of that is, but it's there in HDDLOAD of a SCPH-50009 (boot ROM v1.90, HDDLOAD v1.01) as well.

EDIT: Most importantly: This can happen, even if a valid Sony KELF was loaded and decrypted!

There are no store instructions to that address.

I don't know what's at 0x3C0 - it could be because:
1. That is part of a system that involves self-modifying code to screw hackers.
2. A bug.
3. Something stored in the IOP kernel, and undocumented.

The reason why you notice the HDD being power-cycled is because the MBR will power-up the DEV9 interface again, when it tries to access the disk.

I know that this is true because I stuck uLaunchELF as the boot loader on my HDD, and the HDD just gets switched off just right before uLaunchELF boots up (And stays off).

I'll work on disassembling a HDDLOAD module from an older console, to see whether this funny check is there too.

 

That could be the KELF header for the MBR being checked ? It relies on specific values being set on the "free" region of the KELF header ...

 

I'm not sure, but most likely not. The KELF is stored in a buffer allocated with AllocSysMemory(), so there is no way it could reside at 0x3C0.

I'll double-check my findings with IDA Pro too, just in-case it's ps2dis that actually bugged-out.

EDIT: Oh, I'm sorry: It doesn't check the value at 0x3C0, but it loads a 32-bit word from 0x3C0 before loading a byte from it (Which will then be checked for 0x2). But nothing writes to 0x3C0, so the content of 0x3C0 is unknown - or at least, we don't know how it's derived.

EDIT 2: It's possible to prevent the console from switching off the disk by NOP'ing out the call the poweroff function in rom0:ATAD.

If anyone here wants to know how to load rom0:HDDLOAD of your console for experiments, assuming that it can boot it:

Syntax: -osd<null><address><null>-stat<null><Address to store load status at><null>

Load rom0:ATAD before loading rom0:HDDLOAD with the arguments mentioned above.

 

That's the system configuration record, initialized by rom0:EECONF. That module allocates the buffer via AllocSysMemory, fills it with various configuration data by using sceCdOpenConfig/sceCdReadConfig multiple times, then stores the address of the allocated buffer at absolute address 0x3C0.

I would assume the buffer is read during bootup from the EE, using the memory-mapped IOP range, by either the kernel or OSDSYS. I have seen code in a certain "special" file (that's not publicly available) that reformats the data to provide initial values for SetOsdConfigParam(2).

You may also want to have a look at the first routine invoked by ATAD's _start. It also reads from that buffer, and aborts ATAD initialization if bit 0 (mask 0x01) is set.

Do we have some kind of map of the PS2's NVRAM, and how addresses in their map to parameters of sceCdOpenConfig? That should also tell, after having disassembled EECONF, how the configuration buffer looks like.

 

Wow! Thanks.

Ah, alright. I saw the code in the OSDSYS, but I don't know whether we are talking about the same files.

EDIT: Ah, no. I don't think that we are talking about the same file. I saw that the OSD gathered data from the EEPROM, converted the data and stored in in the EE kernel with SetOsdConfigParam() and SetOsdConfigParam2().

Alright, thank you.

sceCdOpenConfig() provides access to the OSD settings part of the MECHACON EEPROM, when accessed by the OSD.

After reverse-engineering the kernels and OSDSYS programs of several boot ROMs and the HDDOSD, I got an understanding of some of the fields (All used for the OSD, so I don't know about the fields used by EECONF). I don't remember whether I wrote out a table though. :/
(But yes, I intended to publish my findings someday when I find the motivation and time to do it!)

I probably didn't find anything too special, and the data I can retrieve from the EEPROM is exactly as what one can also retrieve through GetOsdConfigParam() and GetOsdConfigParam2(). Some fields were used exclusively by the HDDOSD and protokernel boot ROMs, but I think that they are just for the OSD.

So yea, I probably have no idea what the fields loaded by EECONF are for. D:

Thank you for your input!

 

That HDD snapshot again ? Hmmm, well the proper maintenance on that one would be to delete anything but __system and __common patitions. Nevermind, standard release (BBN or HDDOSD without the BS) is the way to go.
HDD_SNAPSHOT.IMG or whatever it's called was internally published for those wanting to test modified emulators then got accidentally leaked.

Probably because the dump is not documented and people don't know where it originally comes from. "Available" is a way too big word, don't forget that the forum where it's posted is private and... Russian.

A sceCdGetToc type of TOC as header, and a raw disc image if I remember correctly.

Modified emulators still perform virtual CD drive mount, VMC creation/mounting and disc image integrity check(s). I didn't have the time to study the whole thing...

And Net Yaroze EXEs are embedded into the PS BIOS as PlayStation OSD repacement.^^

The corruption point method produces 0 effect on DNAS Loaders, for 2 obvious reasons I can't explain because my English sucks. BBS 3 as I published it is a reassembled pile of RAM scratches. The payload is similar to the one I've coded for DVD Player firmwares. The ATAD is patched following PHSyKoTiK's method (the same method used for retail games), not the corruption point method. The corruption method applies to Master Boot Records and OSD replacements.

I did . trouduculteur reported the same problem. I'm gonna investigate on that but right now I'm facing another damn problem with the PSBBN 0.20 installer. Ffffuuuuuuuuu.

That's old and odd stuff so I can't remember exactly how many bugs there are and what they affect. One sure thing is that some PSBBN partitions (including the swap partition !) have been removed. From this point, you can imagine how unstable the OS is.
A bunch of resource files are missing due to copy failures.
PSBBN scripts were horribly modified my 4 different hackers for testing purpose (better say crashtest).
Netfront can't be launched.
ESR lacks partition icons.
One of the apps can't start because it's launcher is broken.

I will not publish files nor promote the release thread here because it's ©Giant Enemy Crab. Such thing is bad for the survival of a forum, I know what I'm talking about.
Google "PSX Planet - SONY PlayStation Community", register, ask the admin the permission to access the PS2 section if you aren't authorized to browse it.
The thread itself contains all you have to know about the project and technical informations. Sharing just a compressed dump is pointless if the end user does not know how to fully use it.

 

I feel a bit jaded now ... I gave away decrypted dumps of Bishi Bashi 3 demo for some people yet I'll be the last person on the world to play a decrypted copy of it. Funny world. lol

If only I knew the codding needed to make a loader for it I could be playing it since 2010. (no I'm not claiming it was me who decrypted it, it was decrypted from my harddrive, that's all I am saying...)