PS2 FMCB/FHDB v1.9 series release thread

It might be better to just reimplement OSDSYS.

I plan on making a user interface library that will pull resources from early versions of OSDSYS up to the newest one, or from a ROM file on USB MSD or memory card if resource files can not be found.
Once that is done, I'll build my reimplementation of OSDSYS on top of that.
 
Yes, that's probably better but needs quite some work.
But 'in the long run' that's definitely better, if more features should be added.
 
Btw.: @sp193: Would you mind including a small change in the installer (for example in a test-build)?

Once it detects that it is not a MagicGate-compatible card, it would be nice if the user had the choice to install it anyway and the signing-code using the invalid return-value (none, all 0 or all F or whatever) or what the OSDSYS would retrieve on those cards to generate the signing-ID.

So as if the MC-Hardware-ID (not yet the Signing-ID) is essentially 00 00 00 00 00 00 00 00 or all FF or whatever it uses if it can't read it...

The reason I ask is this is... The OSDSYS does try to decrypt the KELF even on those Clone-MemoryCards, but solely fails because it can't retrieve the MC-Hardware-ID, thus failing to decrypt the KELF.

I think FMCB would work on some of those cards which don't deliver an MC(hw)ID! I can test it on an incompatible card as well!


Edit: But I know you have a lot you are working on, so no need to... It's just, that it would be amazing for (MC-)compatibility-reasons!
 
Last edited:
TnA said:
I think FMCB would work on some of those cards which don't deliver an MC(hw)ID! I can test it on an incompatible card as well!
Click to expand...

But what's the point of that, when we cannot change the behaviour of the PS2 during bootup?
Even if you changed the binding process for some non-compliant cards, you would also need to do the same for the decryption step at bootup.
 
?? I don't quite follow.

What would need to be changed there?

If the MC can't return a hardware-ID the result of it is the part which can be used to calculate the MC-(KELF-)Signing-ID...

However... I am not sure if the OSDSYS entirely revokes the KELF if MC-Auth doesn't work, or if it will return an empty Hardware-ID and thus fail to decode the MC-KELF.

It sincerely seems that it still tries to decode the KELF, but (of course) fails.

I think as long as it (the OSDSYS) is trying to decrypt the KELF (albeit it can't retrieve a valid Hardware-ID), so long it should also be possible to create a valid KELF for these Chinese knock-offs as well!
 
Last edited:
If the memory card could not be used for binding the KELF to the memory card, what are the odds that it supports the commands used during the decryption step? The binding steps always involve passing the Kbit & Kc to the memory card for manipulation.
We never get to see what the memory card does to the Kbit & Kc, from the software. Getting the software to handle MagicGate gives us an opportunity to mess with things, so everything important is implemented within the hardware.

Even if it has working functionality for the decryption part, how can you tell what the card will do (wrong or not)? For the file to be authenticated, it must be signed correctly. So you need to know how the card works (either wrong or not), before you can generate data that will be correctly decrypted by the card, which the MECHACON will also accept.

The code that authenticates the memory card, locating the update & booting the secure update, are found in ROM. We cannot change those, which is why we cannot get the PS2 to support non-compliant cards.
 
Does FHDB have any limitations regarding console model? I'm trying to boot off of a 160GB WD IDE HDD without success.
First I tried with HDD raw copy tool, wasn't working, then reinstalled the latest FHDB, (booted using a FMCB memory card) still did not worked. Reformatted the HDD with HDD Manager, and reinstalled FHDB, nothing.
HDD is jumpered as master, games are running fine from it with both OPL and HD Loader.
After powerup, it gets me straight to menu with Browser and System Configuration.
(console is a 70004 with IDE interface wired out)
Am I missing something obvious?
 
I am not entirely sure, if the HDD-Update-Lookup FMCB implements for old versions is also working on new version, but I suppose you would need FMCB to start FHDB on that kind of PS2-Model!
 
Last edited:
Try to jumper it as 'Cable Select' or leave the jumper out altogether! This works for some HDDs!
 
I have a 80GB WD disc I could try.
(it is full of games, I assume installing FHDB does not alter it in any way right?)
 
unseen said:
(console is a 70004 with IDE interface wired out)
Am I missing something obvious?
Click to expand...
The SCPH-70000 does not support FHDB due to its boot ROM not supporting the HDD. But if you really want HDD support, you can use FMCB to help:
  • Install FMCB on a memory card.
  • Copy DEV9.IRX, ATAD.IRX and HDDLOAD.IRX from INSTALL/SYSTEM to mc:/BEEXEC-SYSTEM as dev9.irx, atad.irx and hddload.irx respectively.
FMCB will search the HDD for FHDB and boot it. This feature was meant for the SCPH-10000, SCPH-15000 and SCPH-18000, but can be (manually set up and) used in cases like this.
 
Ah thanks.
Wondering why did Sony leave all the hardware components on this model, but took out the support from boot ROM?
 
They might not have the new IOP designed and ready yet. Nothing can be removed because the components are also used for network support.
Technically, it isn't really a complete implementation because the hardware no longer prevents the user from resetting the PS2, when the HDD unit is activated and the reset button is pushed.
 
Another little suggestion:

It would be great if there would be an option in the installer to set the attribute of the B?EXEC-SYSTEM-Folder (and possibly SYS-CONF), to non-delete/copy (via SetStat?)!

A copy doesn't work and at least a multi-install should not be deleted manually!
It's gonna make FMCB kind of childproof, if they solely use the hacked OSDSYS or OPL.
 
If it fixes the coldboot-problems which seem to occur with some games - and AFAIR even some Homebrew-Apps - then I'd think calling CLEARSPU before executing an ELF (edit: from the 'hacked OSDSYS') would be a good addition.

If that works, it would probably even fix those coldboot-issues for older OPL-revs on some games!
 
Last edited:
TnA said:
Another little suggestion:

It would be great if there would be an option in the installer to set the attribute of the B?EXEC-SYSTEM-Folder (and possibly SYS-CONF), to non-delete/copy (via SetStat?)!

A copy doesn't work and at least a multi-install should not be deleted manually!
It's gonna make FMCB kind of childproof, if they solely use the hacked OSDSYS or OPL.
Click to expand...

Although it exists, it's not supported by the default browser.

The only people who really need to use the multi-install, are those who must save every KB of space on a memory card and somehow have PS2s from multiple regions. So unless you have such a use-case, try to use a normal, single-region installation.

TnA said:
If it fixes the coldboot-problems which seem to occur with some games - and AFAIR even some Homebrew-Apps - then I'd think calling CLEARSPU before executing an ELF (edit: from the 'hacked OSDSYS') would be a good addition.

If that works, it would probably even fix those coldboot-issues for older OPL-revs on some games!
Click to expand...

It is a feature of FMCB, since v1.90. It just doesn't cover everything as completely as we thought.
 
You must log in or register to reply here.

Similar threads

Back
Top