Project: Discovering out how PSX HDDs are married to the PSX units.

Happy new year to you too.

Wow. @_@
Sounds interesting.

I took at look at the ATAD module in the boot ROM of a PSX, and it doesn't look any different from the ATAD module from a retail Playstation 2 game... which was why I suggested that maybe the marriage between a PSX and the HDD is done on the HDD's controller PCB.

The HDDs of retail Playstation 2 consoles are married to them by the Sony setup disc setting the console's i.Link ID as the password, but I cannot tell whether the contents are obfuscated or not as the HDD will reject commands until it's unlocked with the right i.Link ID (After which, the disk will act like a normal ATA disk until it's powered-off or reset).

Could you please share the extracted ATAD.IRX and bcertifyH.irx modules with me? I'll like to have a look at them.
(If you don't already have my e-mail address, please PM me)

It works if you remove that dummy CDVDMAN module from its IOPRP image, but like you said: It stops with an error saying that the disc is for a PSX.

I should be the one apologizing to you, since I didn't read your post and files properly. :S
(The paths in the install.txt should have told me that it was installing the KELF to the HDD unit)

Thank you for explaining all that.
It's good for completeness.

About the MBR KELF: If you follow Sony's "specification", it looks like it must fit between 0x00100000 and 0x00200000, as the OSD will be running at 0x00200000. The entry point is expected to be at 0x00100000 exactly.

And then we have those IOP updater KELFs, which are essentially UDNL modules with an IOPRP image embedded in their data sections.

 

@krHACKen: I found that the IRX modules are encrypted (Not Magicgate encrypted, but just obfuscased). If you figured out how to decrypt them, that would be interesting...

I'm just not at that level of breaking encryption.
I thought that when you said "crypted modules", I thought that you either referred to the encryption used by the PAK archive format or the Sony KELF encryption.

But thanks for sharing anyway.

I think that the "bCertify.irx" module may stand for "Boot certify"... which was used to determine whether the boot ROM of the console belongs to the console. This may be interesting...

 

More information from my end...

After digging through the PSX update disc v2.10 today, I found that:

1. The PSX... has more than one HDD interfaces (!).
2. The second HDD interface is on the DVR unit itself, and it looks like the Sony drivers have 48-bit LBA support for it.
3. The filesystem partitioning scheme used may not be APA (No mention of the partitioning scheme at all).
4. There is debugging information in the DVR HDD driver.
5. The DVR (Or more specifically, some lower-level part of it) is known as the "DVRP".

Module dependency structure: DEV9 interface driver (DEV9.irx) -> DVR low-level device support driver (dvrdrv.irx/"DVR_Basic_driver") -> DVR HDD unit I/O driver and filesystem driver (dvrfile.irx/"HDD Driver for DVR"/"PFS Driver for DVR") + dvrmisc.drv ("Digital Video Recorder MISC task") + dvr.irx ("Digital Video Recorder DVR task")

It looks like the I/O operations are all done on the hardware side of the DVR's HDD unit (Including the formatting), so we cannot see what partitioning scheme it uses and whether it verifies that the disk is a "SCE Genuine HDD".

So it's probably better to believe that the HDD connected to the DVR must be a Sony disk... although just maybe it doesn't have to (We haven't proven whether the HDD unit connected to the DVR must be a Sony disk or not).

While the full retail ATAD drivers have such a check, the bootstrapping ATAD drivers in the boot ROMs of newer retail consoles (SCPH-30000 to SCPH-55000) do not.

Although the bootstrapping ATAD drivers have code for unlocking the HDD unit, the function does not run if the disk is not locked. But if the disk was bound to another Playstation 2 unit and the i.Link IDs don't match, the HDD cannot be accessed and bootup will fail.

My point here is, unless the DVR does check for a "SCE Genuine HDD" specifically, sticking a normal ATA disk may still work.

Just how many physical HDD units does the PSX have? If it has only one unit which is connected via the DVR, I wonder how the normal ATAD interface is being emulated (Hardware emulations perhaps)... :S

rom0:OSDSYS of the DESR-5000 may be just a bootstrapping OSD program because of its small size, like rom0:HDDOSD of "modern" PS2 consoles (SCPH-18000 to SCPH-55000).

We may be able to test for whether the DVR checks for a "SCE Genuine HDD" by either:

1. Building a test application which will load the PSX drivers and attempts to access the HDD unit (Which is a normal ATA disk).
2. Launching the PSX update disc itself manually on a PSX console with a normal ATA disk connected, after ATAD-patching patching the disc.

The DVRP seems to have a Fujitsu microcontroller running a "Softune REALOS/FR" OS. It looks like the update in the DVR update disc v1.10 shows that this microcontroller indeed does handles the partitioning of the HDD unit, judging by the strings present in the file.

---
For those interested to know: The PSX update discs checks for rom0SXVER, so retail consoles fail that check. Patching out that check causes it to go further, but it'll still lock up further on (Probably because the PCSX2 cannot emulate the DVR and/or some part of the PSX).

 

1, I remember seeing a teardown thread a while back. It's an IDE 3.5" HDD. Lemme see if I can find that

Also, I still don't have my 1.8c (confirmed 1.8c) mem card. Do you even still need me to have it?


EDIT- Found it. FULL of useful info, even hints at a MODCHIP for the PSX, so-called the "ghost chip" (there's also a ghost chip for the PS2)

Anyways, the import thing is that there are massive photos of the complete system, board scans, internals, etc. I am going to DL all the photos before they disappear.

http://www.assemblergames.com/forums/archive/index.php/t-16340.html

 

Firstly, thank you for sharing the link!

If you can get your hands on the FMCB v1.8c card, that will be great if you are willing to continue with the experiments (Finding out whether FMCB works on that platform, and discovering what Sony places in the flash storage device).

I gave the facts I've gathered some thinking, and just maybe... even the response to the "SCE Genuine HDD" check might have been emulated by the DVRP.

One sure way would be to extract the HDD unit (Even a damaged one that can still be detected, at least) from a PSX unit and connect it to a retail Playstation 2 console, and running a test program that checks for the custom Sony firmware.

Is anyone willing to do that for science?

Although, if Sony changed the checks, then such a test probably won't have any effect. :X

If the HDD does not even have custom Sony firmware, sticking a regular ATA disk in the DVR will probably just work out of the box if it was filled with the right data.

EDIT: To cut the chase short, it's easier for someone to just do try this here: http://www.assemblergames.com/forum...R-5100-queries&p=579629&viewfull=1#post579629
But instead of swapping in another Sony disk, swap in a normal ATA disk.

 

That'd be interesting.

I'll see how I feel about ripping open my PSX.

 

If yours wasn't already opened before, just maybe it isn't actually worth it opening it. We don't know whether anything can really be gained from such an experiment, especially after what other people have said in the past about the PSX (Although whatever they said wasn't supported with evidence either).

As for when to make a swap, maybe just right before the upgrade disc is booted up. Alternatively, I could try to write a small application that boots the upgrade disc manually, which you can launch via FMCB v1.8C with the normal ATA disk already connected before power-on (Eliminating the need for a hot-swap of the HDD unit).

EDIT: For those willing to try the above method (Using the program which boots the disc manually):

Downloads/links
cdBoot: http://www.mediafire.com/?9hcs1rdw33vjohw
Source code: http://www.mediafire.com/?tcml9bz9exqygh5

This program opens SYSTEM.CNF on the inserted disc, parses it and loads the main executable mentioned in it's BOOT2 parameter field.

Basically to say, insert the PSX Update disc and wait for the drive to finish recognizing the disc first, before launching this program with uLaunchELF.

 

By the way is there is any progress with capturing xml channel urls?

 

Who ever get run FMCB? I was not successful. The console just hangs and shows a black SCREEN. Which opinion?
(DESR-5000, FMCB-1.8c(PS3MCA installer method),xosdmain.elf.

 

Wow, thank you for attempting to boot FMCB on your PSX.

Although the results were not what we all probably wanted to hear, thank you.

Now, as for why it froze up, I believe that it's either because:
1. FMCB may be incompatible with the PSX's kernel and/or hardware.
2. The PSX cannot decrypt the FMCB KELF, which means... we're screwed because FMCB will never ever work on that system.

If someone else can double-confirm that FMCB isn't working on the PSX, that will be great.

Meanwhile, I am busy with life right now. Therefore, I cannot inspect FMCB and the PSX's kernel, to see whether there are any problems with using FMCB on a PSX. When I get a chance to and the motivation to hack away at the PSX again, I'll work on it.

 

I was glad to try it. Console freezes it: if a memory card not inserted it is all right, if a card is inserted with FCMB-black screen. To get out of this state (off console) have to hold the power button 20-25 seconds.
And somebody tried Memor32 (with Memmento), or it will not work?

 

i wonder if it might just be incompatibility because the XMB is a " newer version " of the OSD
what might really help confirm this is if the DVD update was tried to be used on the PSX

the PSX checks for that file on the memory card for some purpose we just have to figure it out and exploit it

 

The fact that the PSX froze up means that it had really attempted to boot FMCB, but got stuck somewhere. We don't know whether it froze up in it's OSD or in FMCB.

FMCB does attempt to patch the OSD, so just maybe... it froze up there. I don't know whether FMCB can patch the PSX's OSD properly or not (It most likely cannot do that).

There are too many unknowns here, since FMCB v1.8c is closed-source. I've tried to unpack FMCB for studying, but it looks like ps2-unpacker has trouble unpacking the decrypted FMCB KELF. -_-"

The DVD Player updates work in the same way as these OSD updates, but gets launched only if a DVD video disc is inserted. I don't know if the PSX will boot the DVD Player update on it's own, without the XMB installed on its HDD unit (Or if the HDD unit is defunct).

 

Does the PSX use a recovery system like the PS3?

EDIT: Let me clarify, as in is there any sort of service recovery options like what the PS3 uses to recover HDD's.

 

AFAIK, no. When the HDD goes dead, it is dead. While it appears that some files are stored in its flash storage, it seems like some importand parts OS itself is stored on the HDD.

 

Conclusion - endgame (?)

Over these two days, I've been disecting my PSX for various experiments and making several dumps of its storage devices.

It doesn't seem possible to even stick a non-Sony ATA disk into the unit at all, as the DVRP seems to be expecting a Sony disk that supports the Sony DRM commands.

I've written up a page that concludes all my findings, and I hope that you guys would read through it and give me some comments like whether I'm missing stuff or if things can be elaborated on in a better way: http://ichiba.geocities.jp/ysai187/PS2/PSX.htm

I cannot really comment on the Magicgate stuff due to the red tape surrounding that matter. The HDD might be replaceable only if the DVRP's firmware was modified/replaced and flashed.

I don't have experience with tweaking with Fujitsu CPUs, so I'm not going to do that.

Thank you all!

EDIT: To answer the original question in this thread, the HDD isn't married to the PSX. I read in another thread here that swapping disks between PSX units will work, although it isn't possible to replace the disk with a non-Sony disk.

The data might be encrypted by the drive itself since the drive supports the Sony DRM command set, which I think includes a unused (unused on retail PlayStation 2 consoles) read and write command...

 

I gave it a quick read - if the disk is a standard OEM seagate drive - couldnt you dump the firmware from the hard drive and flash to a identical PC drive with the same capacity etc?

While obviously this isnt a great way to do things (cant use larger disks, must use the same brand/model) - it would open up the possibility to replace dead disks in PSX's that are otherwise useless?

On the older hard drives, the firmware is usually in a eeprom thats easy enough to dump and reprogram with external hardware.

Do you have some pictures of the hard disk? do you know the model?

 

I'm not an expert on this, but from my understanding of how these drives work, one cannot simply dump and flash the firmware as the method of doing so is manufacturer-dependent.

But yes, if that can be done, we should see those dead PSX units being revived. l_Oliveira once told me that he flashed a retail Maxtor 4D040H2 with the firmware dumped from a Sony SCPH-20401 (Maxtor 4D040H2), and the retail PS2s all accepted it (other than those DNAS checks, it was accepted by games).

Here is the disk:

The disk is a Seagate ST3160022ACE (U Series 9, 160GB), FW 7.09, Date code: 04261, config: VED-03, Site code: WU (Made in China).

I didn't take a photograph of the entire thing as the label looks exactly like an OEM disks's.

Thank you for your input!

 

Got a pic of the drive PCB too?

While I imagine there may be some drive specific information in the eeprom (calibration? or other madness) - it may be possible to replace just the firmware by editing the dump and inserting the firmware from the sony drive?

If the eeprom is easily accessible on the board - that sounds like a promising route to at least revive some psx's.

While its unfortunate its not easy to upgrade the drive, at least reviving some dead machines would be a decent secondary achievement.

Edit:

eBay shows drives are readily available. Google shows eeprom is easy to access:

http://www.donordrives.com/seagate-160gb-st3160022ace-fw-9-51-100282770-g-ide-3-5-pcb.html

So basically, we need a dump from a PSX drive to make a start.

 

No, I don't. Sorry.

I could rip open my PSX again, but I don't feel like doing it now as I have taking that poor beast apart about 4 times over the past 2 days, and it's getting really tiring since the screws and fragile ribbon cables are scaring me. D:

But anyways, I think that it should be physically similar to a normal ST3160022ACE.

We actually have two options from my point of view:
1. Hack the DVRP's firmware to accept normal disks, which means that the owner will have to boot up the unit using a modified copy of FMCB to flash that processor's ROM.
2. Hack the firmware of a substitute disk, which is what we're discussing now.