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

Since PSX units are quite rare and I don't own one, it's only possible to discover how Sony marries the HDD units to the PSX itself if someone helps me.

From a boot ROM dump of a DESR-5000 unit I got from AssemblerGames (Sorry, but I honestly can't find that post now D, it seems like the boot ROM does not have any special HDD modules related to marrying the HDD to the PSX unit. It has newer versions of HDDLOAD and PFLSLOAD than my SCPH-39006 (Probably the same as a SCPH-50000 series), but the ATAD module in it doesn't seem to issue any special commands. :/

From the first 1GB of data dumped and sent to me as a sample, it appears to have been totally obfuscated (Not just XOR'ed, but really brutally mutilated). But why? I think that it's because the PSX's HDD units have a custom firmware that encrypts the data as it gets written onto the HDD unit (By the HDD controller PCB).

But I have no evidence that this is exactly the case, unless someone helps me to prove or disprove this theory.

If the data is protected with such a method, I believe that it's possible to access the data properly using the PSX that the drive was married to (Using the standard ATAD module) and to copy the data out onto another disk to be used with yet another PSX (After patching the files to not require a "genuine' SCE HDD").

The target PSX will have to either have some modified boot files installed into it's flash chip or on a memory card (FMCB style), to facilitate booting onto the non-Sony HDD unit.

Then of course, we have to live with the assumption that the PSX has Magicgate keys like a retail Playstation 2 console, or it will be impossible to create such a patch (Think: TOOL vs retail PS2). -_-"

Is there anyone here who won't mind working slowly with me to try to solve this?
Personally, I don't think that I can go very far due to my lack of resources to make this a really large project with priority, but I would like to try to increase the spread of knowledge and understanding of this rare and unique system.

Basically, you only have to try to get FMCB to boot on your PSX to run the tools I give you. You don't have to remove your HDD unit at all.

 

I will be a test subject. As long as sometime in the future the PSX will be in English. Maybe.

Anyways, let me know what needs to be done. I'm not seriously into coding, so I can only carry out the experiments.

I can say I've tried running a pre-hacked FMCB mem card on it. Obviously nothing happened.

 

Hello!
Sorry, I didn't check this post first. As you already know I have a PSX ready for any test, in the state it is now is useless.
Just keep in mind I'm really a newbie at these things! : )
Please let me know what I should do.

 

Hi, thank you all.

Firstly, we need to verify whether a modified FMCB v1.8C installation (See: http://www.assemblergames.com/forum...X-DVR-consoles&p=625320&viewfull=1#post625320) will boot on a PSX. If it doesn't, Swapmagic is the only way to go.

I can't promise you that, but I can say that figuring out how Sony stores the system files on the HDD and internal flash storage will open up a path to that goal (Since other developers can modify and stick whatever they want into the OSD).

I'll assume that your FMCB installation is either a multi-install of FMCB v1.8C or it's an installation made for a Japanese console (Region 00).

Have you tried copying mc:\BIEXEC-SYSTEM\osdmain.elf (Or the mc:\BIEXEC-SYSTEM\osdXXX.elf file if you don't have osdmain.elf) as mc:\BIEXEC-SYSTEM\xosdmain.elf?

 

The FMCB install I used was a multi install- the one used to hack other mem cards, right?

Not sure what you mean in the second line. Like I said, I'll need a bit of explanation to get it.

I also need to find m PS2 and FMCB mem card in the first place. I put it somewhere and I'm hoping I didn't lend it to a friend.

 

Yes, but it has to be FMCB v1.8c. FMCB v1.8b is not region free.

But to be precise, a multi-install doesn't make the FMCB installation transferrable.

Traditionally, it used to be for allowing the FMCB installation to be supported on all Playstation 2 models (All models, except for the SCPH-90000 series).

In my unofficial FMCB v1.8c installer, a multi-install does that... and it's also multi-region (So it's region free for real).

Of course, I only wrote the installer. FMCB v1.8c was built to be region-free by the original author.

Alright. Simply put, I need you to try copying one file in your FMCB installation as another file, since the PSX looks for a different update file.

If you use any Playstation 2 console (Running the uLaunchELF file manager) to browse your memory card containing FMCB, you will notice a BIEXEC-SYSTEM folder on your card.

In that folder, there should be several files. Copy osdmain.elf as xosdmain.elf, before trying FMCB on the PSX again. That's all you need to do in preparation of this experiment.

By the way, Merry Christmas!

EDIT: If FMCB does boot up on your PSX and you are able to launch uLaunchELF on it, could you please start its HDD Manager and tell us whether you can get a list of partitions on the PSX's HDD unit?

(If you can, it shows that the HDD unit is unlocked and the HDD unit is accessible by the PSX it was installed into at the factory)

 

Not quite Christmas yet. But yes, Merry Christmas

I'm still have issues finding my hacked mem card, chances are I'll just make a new one. I'll PM you with some of the issues I'm having with installation...

 

My video on youtube has just received a comment:

skater24481 2 hours ago
press the X button on the controller. O=X / X=O In japan. mine did the same thing, but you have to wait a minuit first

 

Sorry guys but I didn't notice this thread until now. I own a desr-5000 unit so if I could be of any help....

The only problem is that I don't have a NTSC-J PS2 to create a Jap FMCB (BIEXEC)... but I know Swap Magic works perfectly fine on PSX. It can launch any .elf (except HDL) on USB or MC.

 

I have a jap ps2 but don't swap magic and no idea where to find it in Japan : )

 

If you have access to any other Playstation 2 console, use it to make a multi-install of FMCB v1.8C with the latest version of my unofficial FMCB v1.8C installer.

That installation will be compatible with all Playstation 2 models of all regions.

 

And if you put through your computer? Using a Memory Card Adapter?

 

If you want to go by that route, you might as well use the original FMCB v1.8C installer package (PS3MCA installer method) to install FMCB onto your memory card directly.

 

Is this OK for our purpose?

http://www.amazon.co.jp/SwapMagic-3-8-%E6%97%A5%E6%9C%AC%E7%89%88/dp/B0011TYAEG/ref=sr_1_1?ie=UTF8&qid=1356843847&sr=8-1

 

Thought it'd be worth mentioning I've gotten a hacked mem card sent to me. I really hope it's 1.8c...

 

It will be useful if you use it to install FMCB v1.8C.

Or if FMCB v1.8C can't be used to boot up the PSX, it can be used for launching some testing programs that will be used to collect more data about the system.

Please take note that while it seems like I can get everyone somewhere... I cannot promise anyone that something good and usable will come out of all these experiments.

These experiments will be for gathering more data about the PSX, like how the HDD units are different from a retail Playstation 2 HDD unit (SCPH-20401).

A multi-install of FMCB v1.8C will have the BIEXEC-SYSTEM, BAEXEC-SYSTEM and BEEXEC-SYSTEM folders on the card at the same time.

An installation of FMCB v1.8b will most likely do as well... if it was made for a Japanese Japanese (NTSC-J) console (Magicgate region 00).

But you still have to copy the file like I've described before (Copied as mc:/BIEXEC-SYSTEM/xosdmain.elf), as part of this test.

@all, like I've told DefectX11 in a private message, the roadmap of this series of experiments will be something like this:

1. Determine whether FMCB can be used as a valid method of booting unsigned code on the PSX.
2. Determine whether the HDD unit can be accessed with the homebrew ATAD module.
3. Determine whether the HDD unit is married to the PSX, with the HDD unit's controller PCB being responsible for that.
4. Determine how to access the internal flash storage.
5. Dump the contents of the internal flash storage for analysis.
6. Determine where to install a boot loader, for homebrew launching purposes and for allowing normal ATA disks to be used.

#1 is good, but is not strictly required. But, if FMCB cannot boot on a PSX because the keys in the PSX are different from a retail Playstation 2 console.... it'll be bad if the update program stored in the internal flash storage device has to be encrypted as well (In that case, we have to give up as there will be no way to boot our own code easily).

 

I've MG decrypted xosdmain.elf (that came from the latest version of the update disc) and found that the unpacker stub is headerless. If an update path to external device exists, perhaps such update program is loaded at a fixed address (like the PS2 HDDLOAD does with the PS2HDD MBR).
Sorry for writing hypothetical things, I just had a quick look without deeper analysis.

EDIT : Found "mc0:/BIEXEC-DVDPLAYER/dvdplayer.irx" and "mc1:/BIEXEC-DVDPLAYER/dvdplayer.irx" strings in the unpacked dvdplayer.elf, but no traces of a KELF launcher.
EDIT2 : Uploaded the 4 xosdmain.elf. The link is on Pastie #5597426.

 

I tried your installer (0.93B1) but it freezes on "Installing to memory card 1" with the multi-install. Normal mode works fine.

 

If you are really sure that it froze up (Please wait, since it may take a long while... especially on a really full card), then it could be either:
1. A bug in the installer.
2. Your memory card's filesystem is damaged.
3. Your memory card's NVRAM chips are worn out.
4. Your memory card was misdetected.

Some things you can try:
1. Just simply try again.
2. Copy the contents of your memory card somewhere else before formatting the card.
3. Try another memory card.

If you really can't get a working multi-install, a normal install will do too. Create BIEXEC-SYSTEM if it does not exist on your memory card, before copying osdmain.elf (or osdXXX.elf, where XXX is a number) from your console's update folder (Which is either BIEXEC-SYSTEM, BEEXEC-SYSTEM or BAEXEC-SYSTEM) as BIEXEC-SYSTEM\xosdmain.elf.

It's not a headerless file. You are looking at an encrypted memory card KELF file. It needs to be decrypted first.

I'll look for your archive, and I'll determine whether it can be decrypted by a retail Japanese Playstation 2. It'll prove whether FMCB is theoretically bootable on the PSX or not.

The update mechanism is similar to the one from boot ROM v2.50, but is fully functional. It supports update booting from memory card, the internal flash storage and the HDD unit.

Thank you for your contribution!

EDIT: Alright, you're right... it's headerless.
FYI: Knowing Sony, packed files load at 0x00100000 and decompresses to 0x00200000. So you know where to load the file at if you want to poke around it.

This file doesn't seem to decompress to 0x00200000 though.

BTW: Have you already figured out how the PSX installer disc works? I'll be great if we can patch up the installer disc's contents and get it to install on a PSX that doesn't have a SCE HDD unit.

Beware the nasty check Sony added in it's IOPRP image, if you haven't already found it. It contains a dummy CDVDMAN module that loads on a retail PS2 unit (Since CDVDMAN on a retail PS2 has a lower version number), causing a BSOD.

The function for booting the memory card update is at 0x002030d8 of the OSDSYS of a DESR-5000 series unit.

EDIT 2: I'm thinking... maybe the xosdmain.elf KELF you found isn't for a memory card. I don't think that the PSX ever required the user to leave the memory card inserted at bootup, did it?

Like the HDD unit, the flash storage update method has it's own boot loader (rom0FSLOAD) which works in a similar way.

EDIT 3: The start of the header has 0x4 as the 4th byte... which always seemed to indicate that the KELF is a DISK KELF. So it's most likely installed to the HDD unit or flash storage.

So yea, at any rate... PLEASE SOMEONE GO TRY BOOTING FMCB ON IT!
(After modifying your FMCB v1.8c installation, of course)

Whatever the result is... we'll probably be able to stick the update files on the internal flash storage at least. The 'extflash' driver in the PS2SDK may see some use within the next few months as part of the next experiment.

(Or maybe not... since Sony has conveniently provided a copy of the flash driver in the boot ROM of the PSX)

EDIT 4: Exploring the flash should be easier than expected. Like what mrbrown discovered, the flash uses the Sony MCFS filesystem.

rom0:XFROMMAN has a complete library of I/O routines exported to rom0:IOMAN, so adding a new option to uLaunchELF to support a 'third' memory card should be easy.

Yes, it seems like there is write and formatting support too, so gaining proper access to it should not be impossible.

If possible, I'll like a dump of someone's flash device, to determine what Sony has placed on it. I don't have a program to dump the flash storage yet, but I'll attempt to write one when I get a chance to.

EDIT 5: Hold on. Although it's possible to gain low-level access to the flash storage via PFLASH, it may be better to access it via XFROMMAN instead (Assuming that it's export table is similar to rom0:MCMAN's). The resulting dumps will probably be similar, data without the ECC data.

EDIT 6: Nah, it's better to dump it from PFLASH. If we went the XFROMMAN way, we'll end up with something like my unofficial FMCB installer - the detection of the size of the flash chip will be dependent on the filesystem.

By going through PFLASH directly, we can dump the entire flash chip.

 

Happy new year to you and yours.

The packed xosdmain loads at 0x00100000 like you mentioned, and decompressed then executed at 0x00800000.

More or less. Unlike PS2 Utility Discs, the main program is not XORed and the AtaSecIdentify routine is clearly visible.
As for installable contents, it extracts very well with your PAKer Utility. I ran my KELF Corruption Tool against a xosdmain.elf (for adding patched data to my patcher). It has found the corruption point of the AtaSecIdentify jal, but unfortunately was unable to print the list of alterations because of some stupid bug.
I had a look into the unPAKed folder "xosd/__xdata/temp/DownloadRoot/boot_0.2/" of the update disc v1.10. There are crypted modules, including atad.irx ffended: (and an intriguing bcertifyH.irx).
And I cannot assure you that there is no more HDD validation code, other than AtaSecIdentify.

A friend of mine solved that issue. Despite that, the installer still halts with an error message when run on a PS2 console. Perhaps it's due to PSX-styled hardware checks or the impossibility to load some PSX designed drivers (like the DVR driver for example). Since I don't have a PSX unit and never touched one, I didn't try to hack and test a PSX update disc.

Sorry if my previous post was confusing. The xosdmain KELFs I did post are indeed meant to be installed to the HDD, not to the MC. At least, that's what install.txt (from the update disc) says :

Just saying that if the MC update KELF needs to be headerless (like the MBR), a FMCB KELF (with an ELF header, like DVDELFs) will not work. A KELF can naturally embed any kind of data, as it acts like a container. All depends on what the launcher does after the data are decrypted. A few examples :
- A "standard" KELF : The launcher parses the ELF header, loads the executable to the address specified in the ELF header and executes it to it's entrypoint.
- A MBR KELF : The launcher loads and executes the program to a static (specified by the launcher itself) address. The program is headerless.
- A deobfuscated PS2 utility disc "wobble" : Uncommon case. The loader (the DVD Player installation program in this special case) unpacks data with it's own internal unpacking function. The KELF contains no raw executable segment, just packed data.