Any guide on using FMCB and OPL on PS2 Test Kit?

I was heard FMCB installer doesn't support PS2 Test Kit.So any one tell me if the latest version improved that?Or is there an alternative way to use memory card boot with elf program binary on PS2 Test Kit?
If memory card boot is not even possible on PS2 Test Kit,any one can tell me why in technical or give me article url on this topic?Thanks!

And does OPL support PS2 Test Kit(DTL-H30000 or later model)?I have never tried to use it on my test kit.If it does,I plan to use my test kit and sell my spare retail ps2s.

Thanks.

 

It depends on your TEST unit model.

The DTL-H10000 and DTL-H30000 series are incapable of booting FMCB due to a lack of a full Magicgate implementation (No KELF support). On the other hand, the DTL-H10100, DTL-H30100, DTL-50000 and DTL-70000 series are fully capable of booting FMCB... or rather, I should just say that they can boot an OSD update, but FMCB may still not boot because it was designed with only retail consoles in mind.

In the DTL-H10000 and DTL-H30000 series units, the MECHACON lacks support for the KELF decryption Magicgate commands. Their boot ROMs have a "lite" SECRMAN module (secrman_for_dex) too, one that also lacks support for decrypting KELFs.

I don't have a DTL-H30100 or DTL-10100 (and neither do I know of any special requirements by these consoles), and so I never tested nor designed the FMCB v1.9 series for use on one. I did hear from a reputable source that FMCB v1.92 doesn't work on a DTL-H30101 unit.

OPL is a different matter. I'll probably work all TEST unit models, since it doesn't involve the console's Magicgate mechanism.

 

Really thanks for explain the problem that cause FMCB not working.

And thanks for proving that OPL will working on devkit.
Now I plan to connect my old test kit to my NAS in new place

=)

 

How would I install Free McBoot on my DTL-H50000? Does Free McBoot support being installed from a CD-R? If so, I could mark the image as a master and boot it.

What is OPL? I was able to figure out what the FMCB acronym was likely to be, but I have no idea about OPL.

If Free McBoot works on certain test models, it's probably also possible to get the DVD player to work on them, though likely a lot of work.

 

OPL (Open PS2 Loader)

https://bitbucket.org/ifcaro/open-ps2-loader/overview

 

Just make a disk of uLaunchELF and put the FMCB installer in a flash drive

 

fmcb wont work on a test(with magicgate), because of it's nature to reject dvdplayer kelfs, it will even completly ignore the memory card with fmcb on it in the browser&ule, so you cant even access it with a file browser.
i tested it myself, the only solution i found so far was installing software on the hdd with wobble kelfs.

 

Like I wrote here, somebody I know has been tinkering around with one of these units:

It does accept OSD updates (The existence of the TDB startup cards is the proof), but one cannot transfer the update files between a Debugstation and a retail PlayStation 2 (Decryption will probably fail, and the update will get rejected) because something was done to make the bound KELFs (for TESTs) not compatible with the retail units. So if one installs FMCB, it has to probably be done with the TEST unit itself.

But he discovered later on that there's a problem with the boot certification step, and so FMCB causes freezes due to the DTL-H30100 series having a mismatched boot ROM (It has ROM v1.50, but its MECHACON expects v1.10). The ROM OSD has the ROM version hardcoded within it as v1.10, hence how it works around this abnormally.

Unfortunately, no FMCB developer had access to one of these units.

 

That's really a pity......

=(

 

I'm curious to know here: If you can install FMCB v1.92 with your DTL-H50000 unit itself (Assuming that installs made with retail consoles won't work), will it work fully? On the DTL-H30101, the CD/DVD drive cannot be accessed without it locking up, although it seems like FMCB hangs because of that.

The DTL-H30101 has got a mismatched boot ROM (and hence all the problems), but I have no data on the DTL-H10100 (Presumed to be in the same state as the DTL-H30100 series), DTL-H50000 and DTL-H70000 series. A customized build will have to be created, to minic the behaviour of the DTL-H30100 series's OSD (Boot certify with a hardcoded ROM version of v1.10).

There's no way to get FMCB supported on the DTL-H10000 (Presumed to be in the same state as the DTL-H30000 series) and DTL-H30000 series, due to a lack of working Magicgate KELF support by these consoles.

If installing FMCB with the FMCB installer doesn't work on these consoles, perhaps the SECRMAN module needs to be changed. I noticed that these consoles have a ROM SECRMAN module that doesn't perform a key swap, so I presumed that it's the reason why it wouldn't decrypt stuff that were installed for retails (But if that's the case, won't binding/installation fail with the retail SECRMAN modules then?).

 

A friend of mine is trying to install PS2 HDD images with pre installed applications due to fmcb not working on his PS2 Test console. He made a master disc patched Ulaunchelf disc which boots fine and has formatted the HD from there. Is there way to install a boot loader, so that Ulaunch boots up without using any discs and then boot OPL from there?

The images that have been tried and copied via raw copy to the HD all hang on a black screen on boot-up. I cannot try myself as I sold off my test consoles recently.

 

As noted by richi902, for memory card stuff on TEST consoles, the file must NOT be DVD player flagged (MG type 0x07) and because it will be bound with a different algorithm on KBit/KC, they won't work on normal retail consoles after binding. This means a card that work on a TEST for booting won't work on the matching retail due to different KC/KBIT decryption algorithm.

This, by the way, is why the DTL-H10020 TDB doesn't work on retail consoles.

Additionally, because of ESR, FMCB files have to use DVD player MG filetype, so the bog standard FMCB you get on the web will fail to operate on the TEST units.
And changing MG filetype from 0x07 will break ESR for Retail units, as the DVD drive won't unlock for DVD Video discs without decrypt such a MG file.

So in the end a custom build of FMCB would have to be made for DTL hardware.

I recommend use FHDB instead.

As suggested above, for non MG enabled units, make a masterdisc with uLE as boot elf.

 

FHDB would be able to load the hacked OS updates from a hard drive on a DTL-H50001?

I'm curious--do debugging stations allow reading DVD video sectors the way that ESR does, if the disk has a VIDEO_TS directory? It would be cute to have ESR for test systems, although really you could just modify the ESR patcher to do both the master disk patch and the VIDEO_TS patch so the disk would work on modded retails, ESR unmodded retails, and debugging stations.

By the way, an ESR build for debugging stations could get CD-based games working on a debugging station without a patch to the ISO if it hung around and messed with the IOP libcdvd. Debugging stations' mechacons recognize pretty much any any non-PS2 data CD as a PS1 disk as far I understand, which is good enough to allow reading.

 

Any MG capable PS2 DTL unit will be able to boot stuff from the HDD without any restrictions.
Now, onto DVD Video playback, there's two states the PS2 mechacon has regarding DVD video discs: Forbid and Allow.

In forbid mode, it prohibits any kind of access to to Video discs. It will identify a disc as DVD Video but you won't be able to read it's contents.

On boot, the startup code which does the initialization of the optical drive performs a task called "boot certify" which initializes the CDVD driver software (CDVDMAN and support stuff, plus HW init) and "certifies" the drive. One of the tasks the ROM does during that step is "sceCdForbidDVDP" which blocks completely DVD playback until a file with MG filetype of 0x07 (DVD Player software) is decrypted. That is EXACTLY meant to stop things like ESR from working.

But when it was discovered that a DVD Player MG file could be trojaned, the MECHACON would be already in a state which allowed for DVD playback to occur. That's what made VAST and ESR possible. The catch is that DTL hardware has MG files with filetype 0x07 blacklisted in MECHACON firmware. You cannot unlock the DVD drive for DVD Video playback, making ESR impossible on any DTL/TOOL unit.


CDVDMAN imports: http://lukasz.dk/mirror/cdvdmania/cdvdapi.html

 

Boot certify doesn't initialize libcdvd. libcdvd (on the IOP and EE) is initialized before the boot certify command. The boot certify command simply passes information about the boot ROM (version, type and region code) to the MECHACON, probably for ensuring that the right boot ROM is installed on the console.

I think that it was more for preventing unauthorized DVD players (e.g. region-free/non-Sony ones) from being run on the system.

If they wanted to prevent people from reading data from non-data discs (CDDA and DVDV discs), they have certainly failed to protect audio discs from being used for such a purpose (There was another project like ESR that allowed data to be stored on a CDDA-like filesystem, wasn't there?).

I never managed to try this because all our MG files have the DVD video player value set (It's the default setting, as you know), but does this mean that DVD playback is disabled by default, even if sceCdForbidDVDP is not invoked? If an OSD update is detected, the update will be booted before sceCdForbidDVDP() is invoked.

In such a case, the OSD update will invoke sceCdForbidDVDP() on behalf of the ROM OSD.

 

I might not be using the proper wording. It's my fault not being able to explain what I meant correctly. I meant to say that part of the normal process (in the ROM) that initialize the optical drive is invoke the DVD playback forbid call.

Also, why would SONY be afraid of unauthorized DVD players if all the interfaces and knowledge on how the hardware needed for DVD Video playing is acessed was never disclosed to any licensed software developer ? The reason that made sense for the forbid flag existence was prevent that a DVD Video disc could be used as a data source.

It backfired when DVD flagged packages got trojaned ... lol

As per the TEST, I don't know how it would behave, but I suppose that not invoking sceCdForbidDVDP might be why normal FMCB crashes to a black screen before putting up the splash on a TEST PS2. That's something I've thought of investigating, but I kind of lack competence to do so. >_<

 

When working on security, there are usually several layers. While they usually used security through obscurity, there had to be some parts that were deliberately protected.

For one, they didn't protect CDVDMAN at all. The code was reversed-engineered and the interface for sceCdReadDVDV() was figured out, as well as the N-command for it.

The CD/DVD drive doesn't understand MPEG nor the DVD region codes. Everything is done by the DVD player, in software. Hence why they probably had to ensure that only authorized DVD players are allowed to use the DVD video playback function of the CD/DVD drive, since it's possible for anyone to interface with the CD/DVD drive and issue the READ DVD SECTOR N-command to it (either via CDVDMAN or directly).

But yes, it's also possible that one reason they blocked the DVD video sector reading function by default is to prevent it from being exploited. Limiting the available functions to the user is also another form of security.

Don't blame yourself entirely for that. We don't have sufficient facilities for debugging that. The best you can do is to use Kermit and give me a memory dump + the PC (Program Counter/address) of the lockup/deadlock. But even so, we may not be able to determine what's wrong because it may be complicated.

 

That's a great idea. If I can boot kermit and have it survive the crash. I'll give it a try. I happen to have a EESIO on the DTL-H30101 too so I can have a better picture of what's going on in there.

 

Great! If you do so, please use a specially signed copy of the public version of FMCB v1.93, so that I'll have the exact same binary as the one that you are using. Debugging will be easier that way, for me.

Otherwise, please send me a copy of your binary and the source code for it. Even if I can build a copy on my own, the generated binary may be different because of differences in our SDKs and the development environments.

 

What you're saying sounds like you could make a hacked OSD update that doesn't call sceCdForbidDVDP and then sceCdReadDVDV would actually work on DVD Video disks on Test systems.

I have a DTL-H50001 if you'd like me to try something with Free McBoot. Too bad you live in Singapore, though, since that makes it inconvenient to let you borrow it.