PS2 hard drive file system?

I have access to PC3000 at work and have often thought of buying a Final Fantasy HDD kit to experiment..:nod: Is it possible to dump the complete firmware from the drive and then re-flash another similar drive thus making it compatible with sony's HDD tools and Games? If flashing is possible could we also change regions perhaps, with a view to using the BB navigator discs on PAL and US consoles. I have only seen some BB Navi stuff, and its all Japanese so a little useless to me, but some of the features look great and would be very useful and appreciated among the PS2 homebrew community.

 

I did that to the 4D040H2 drive. The PS2 detects it, let me use the utility disc, allow me to install offline games.

DNAS checking aways fail. I suppose I missed some sort of firmware CRC. So it isn't as easy it might look like.

But modding a drive with PC3000 to fool a legit PS2 into detect the drive as valid is easy.

 

i don't think navi's inability to run on usa/pal units has anything to do with HDD's. I patched my copy of navi (the .32 version i think) to work with third party drives and boot up on all regions.

however, it will boot, and it will install, and it will NOT autorun after installing, only way to run the install is still via the linux RTS.

I actually used a lot of time with navi once upon a time, but it's just a mess beyond anything and making it work on a non-japanese unit without placing a jpn flashrom on the (non-jpn)console just seems to be impossible.

 

What are you talking about (PC3000) ?

 

That wasn't hard to find
http://www.pc3000.com/

 

HDD boot files (HDD OSD update) are Magic Gate encrypted. That's how they region lock it. Only a matching region (DVD player region and game region) console can extract the elf file from such KELF(s).

An Chinese PS2 is NTSC J but won't run with a Japanese HDD nor will boot Japanese utility discs of any kind.

 

Oh dumb ! I already knew that tool, I have similar one at work.

I already tried this. But Maxtor's firmware is divided in two part. One on the controler board and other on the disk. Other HDD manufacturer does not uses this system. How to merge this two firmware ? Tricky thing...

 

Has anyone tried to reverse engineer the additional modules/firmware changes for the official HDD yet? If we knew the special ATA commands, we could build an adapter to emulate them and convert any HDD into an "official" one on-the-fly :love:

Which processor(s) do they use on these drives? And can the drive's firmware be dumped at all? Sorry for the dumb questions, I have no experience in HDD hacking .

 

Yep- We found this out the hard way back in college when ffxi first shipped- a japanese friend of mine bought 2 modchips, and like 3 ps2's before finally getting a jp one so he could legally play the thing.. the disappointing issue was this severe incompatibility with asian systems.. i guess in the end, it pays to check the model number...

 

Just get a modchip with Auto-ATAD patching feature.

I have a MatrixInfinity modchip, and with a Samsung HDD i was able to install the american version of the HDD Utility disc 1.10, that has the Browser 2.0 (adds cd player features, HDD support into the browser, and let's install game files on supported games).

 

That would be -zero- help in playing FFXI.

-hl178

 

Well to be honest, if someone wants to play FFXI today, it would be way easier to just go for the PC version.

On the PS2, you would need a used fat PS2, a network adaptor (the price these days have gone crazy!), and the FFXI kit with both the PlayOnline and FFXI discs, both serial codes and the official HDD.


So, yes, i'm happy being able to use all features, except for FFXI. :110:

 

Playonline main purpose is shield Squaresoft games against reverse engineering and to provide network encryption. It has anti hacking memory protections in place and won't boot if there's "alien stuff" (I.E.: Modchip hooks) on system RAM.

Also, it contains several layers of encryption, strict DNAS checking of the hard disk drive security and it does authenticate with the DNAS server multiple times.

Not playable with a modchip, at all.

Only person I know who made a piece of code that got around that shielding was Silverbull... lol

 

Do you have any details on how they check for kernel changes or an installed modchip? If I remember correctly, the FMCB installer also has problems when modchips were present (due to how they interfere with mechacon <-> DSP communication), and I wonder whether it is the same problem for Playonline/DNAS.

Shit happens :110:. This program was never meant to circumvent anything; its pure luck it works for Playonline as well as regular software.

By the way: I hope to complete v0.5 before the end of the year, with some new features (like a fully-working IOP DECI2 emulation, source mode debugging on both the EE and IOP, and HDL-style disc emulation compatible with the 10k series).

It does, up to the point that it even has the same bugs (like the random crashes in Xenosaga 2, although I hope to have reduced or even fixed them in the latest version ray. Of course, you would also have to expect some newly introduced ones :lol:.

Sorry to hear that. Maybe its just cold comfort, but the boot HDDs usually don't contain anything valuable. Official developers were not supposed to tinker with the Linux installation, so there is nothing but a special kernel with some Sony-specific RPMs stored there. Just put an image of another machine (with the same CPU card) on another HDD, and the TOOL should be operational again.

Thanks for offering, but I made images of all of my TOOLs almost the day they arrived.

Thanks, but I'll let them pass. I think the "new" ones I recently got should be sufficient for the next years :shrug:.

Interesting reading, I forgot that he had attempted this. I'll try to find some time next year and convert one of my units to CF as well.

There are at least two algorithms for VRAM dump implemented by Sony programs, and I got mixed results with both of them.

• DSEDB uses the "raw" method (DECI2's ESDBGP protocol, RDIMG message), which needs the target hardware (GS, GIF, VU1) to be in a certain state to work correctly. Depending on the operation the game's main loop was currently executing when the breakin occured, this might either work (unlikely), give a timeout (most likely), or screw things up completely (even more unlikely than #1).
• VRAMSNAP uses an "enhanced" method, in that it performs a hardware reset before issuing RDIMG. This (should) eliminate the timeout problem, but it is also more likely to screw up a running game. For example, homebrew applications using gsKit almost guaranteed to hang afterwards; indefinitely, unless you break into the debugger and exit the endless loop within gsKit_finish yourself :evil:.

Despite its flaws, I would always use the VRAMSNAP method for taking screenshots; DSEDB its not worth the hassle, and breaking the gsKit_finish loop afterwards is much easier than getting the debugger to halt at the right location.

By the way: I just got an unmodified Xenosaga 1 image to run on my TOOL, and the same program can also execute the flattened image on the retail machine. So I guess DL support of both the core and the installer is working :icon_bigg.

It started as a homebrewn cheat module, but I included other features later on; its more like a full debugger these days, with cheat codes as a bonus ;-).

Do you remember the old cheat cartridges for the PS1's parallel port? When I got my PS2, I wanted to have something similar, so I bought a then-current cheat CD; and was very disappointed because it lacked the in-game PC link. With the PS1, you could just start Xlink and access the console's memory while the game was running; the newer PS2 software just quit at that point OH:. That was the sole reason I started developing for the PS2...

A short feature list:

• PC communication (via Firewire or the EE SIO port) while a PS2 game is running
• PC communication (via the EE SIO port) while a PS1 game is running (modchip required; tested with Crystal Chip 1.1 to 2.0, may be incompatible with others)
• Hex Editor and dumping of live memory (from the PC)
• Gameshark-like cheat codes (from the PC)
• DECI2 support for retail PS2s (PS2-mode only, requires parts of a TOOL BIOS for IOP side, IOP side still bugged). Allows using DSEDB (and, partially, DSIDB) on non-TOOL machines :dance:.
• HDL-style disk emulation from internal HDD

The good news: it works :nod: (well, sort of).
The bad news: it currently needs another (heavily hacked) HDL to install games onto the external HDD (but I hope to include my own installer in the public version).
The ugly news: you need a dev PC (with DSEFILESV) with some special files hooked up to the TOOL to run it. The TOOL's PS2 BIOS is very different from a retail one, up to the point that certain homebrew libraries (like file I/O) do not work. To circumvent this, I had to merge the TOOL and retail BIOS, and the TOOL HDL loads the modified one via the regular PC connection.

Weird that my core isn't detected then, as I install callbacks in exactly those areas. Let alone the patches to interface DECI2...

Thank you :icon_bigg.

I hope to include it at some point, but testing is difficult as I don't have a SCPH-10000 yet .
Top priority was to get it running on a TOOL; which it does, so I think the drivers should work on a SCPH-10000 as well. I will test it on a SCPH-3000x next, which hopefully lets me remove any remaining dependencies on the TOOL hardware...

Its comming, but don't expect a miracle please ;-). I only had a hacked HDL core to start from, so it will most likely suffer from the same game compatibility problems the original HDL had. For example, I managed to get the same random crashes with Xenosaga 2 on the TOOL as a normal HDL produces on my 3900x :banghead:.

Speaking of crashes: my TOOL's boot HDD died yesterday OH:. Wasn't detected at system boot and gave clicking noises. A Deathstar lives up to its name again...
However, the TOOL is operational again, thanks to a cheap replacement I got off eBay some time ago :110:. No idea on how long it'll last, though, but hopefully long enough to get my program out.

Does anybody have experiences with flash or solid state disks on the TOOL? I think of getting a 16GB CompactFlash and bootable CF-IDE adapter to prevent further mechanical failures, but would like to know if another member has something like this running.

The entire DECI2 stuff works as expected, debuggers included. I've actually used them to step through the disk emulator itself (both the GUI and driver/core part).

Breakpoints and single stepping works, RAM dump works, VRAM dump works and is buggy as hell (though that's usual as well :110.

Yes, it was. Has worked perfectly in the past, but after getting it out of the attic yesterday (after something like 5 months of inactivity), it couldn't find its boot drive. After soft reset, the BIOS did detect it, but the system stopped again after displaying the first three characters of the LILO prompt :evil:.

Ah, thanks for the information. I might give it a try anyway, maybe the old TOOL Linux likes flash more than Windows :lol:.

Your problem with the 256MB stick reminds me of something I read in the german magazine c't quite some time ago. Basically, there seem to be some el-cheapo sticks with manipulated flash controllers around which report a larger size to the operating system than they actually have. Result is that everything works fine as long as the stick is less than half full, but as soon as some data is written beyond that mark, it goes directly into the file system structures near the beginning of the drive :evil:.

c't has published a test program to detect these kinds of problems (german site, program is supposed to be in german as well as english): http://www.heise.de/software/download/h2testw/50539

Thanks :icon_bigg.

I have good news: the program now works on my retail SCPH-3900x as well. I just tested it with FFX installed via WinHIIP (my own installer is not ready yet), and it worked just like it did on the TOOL :dance:. I now have to get the DECI2 debugger running on the retail as well; it worked with normal applications as well as regular HDL in the past, but crashes when used with my own emulator. :banghead:

And there was another weird error, as my controller locked up after some time. Analog LED was still lit, but the system didn't react to any button. I had to unplug and replug the controller to get it working again. Has never happened before, neither on the TOOL nor with the normal HDL... OH:

 

TOOL hdloader, YES PLEASE !

 

What is this program you're working on, Silverbull? Sure sounds interesting!

 

I believe they just watch an memory area that is supposed to be empty for "tampering" and maybe also they check the system hooks and interrupt handlers for tampering.

Luck ... Yah I believe... But you surely did a hell of a great job it it.

Can't wait... To bad you have work and other stuff to hinder the programming tasks lol ...
Oh WOW HDL for SCPH-10000 would own so much !

uhhh, oh....

DOWANT

as im still (currently) lacking a t14k from my tool, a hdl would be very VERY handy for certain things

question tho. while running games on TOOL with HDL, would the debuggers and whatnot still operate normally as they do while running games from disks ?

as in, that ram/vram dumping would be normal and the usual stuff?

Sorry to hear about your Tool's hdd, was it the one I sold to you?

Using a CF-IDE adapter might be a good idea but I have some doubts, I had one failed me 3 days ago, the CF suddenly disappeared from the explorer while I was deleting some files, the partition was gone after the reboot, flash devices are too prone to failure I think, or they keep dying in my hands, who knows...I have an half dead 256MB usb flash(if I write more than half of it, everything gets corrupted) and a 4GB one where files larger than 100MB are corrupted from time to time..., you could go for an SSD, but it's not like the Tool is moved a lot while powered on, so the hdd is still the best IMO.

You're a miracle worker SilverBull!

Im not expecting miracles
if it performs even remotely like standard HDL, that would be more than i need. as the project im working on atm is nicely compatible.

sorry to hear that
i had one die on me too and it's quite a bummer. I didn't even have a chance to back it up so it was lost forever:crying:

if you need, i have images for both types of tools (566 and 233) tho i suppose you have them too

also, i have a pile of original HDD's from tools (5 drives actually) incase you want ot have and old noisy one on yours ;-)

you might want to look at defor's TOOL rebuild thread about using CF cards.
He's succesfully running one.

edit: thread here: http://assemblergames.com/forums/showthread.php?t=24210
and particularly this post would propably be of assistance: http://assemblergames.com/forums/showpost.php?p=374006&postcount=4

that's good to hear

the VRAM is kinda buggy indeed so that wasn't really news :lol: I've been having hard time using it at all so far (aside the devtool-opening pic i got.)