PS2 BIOS reverseing

[Robert [K-medulla]]

Hi guys. Plz post here all related info. Here is my simple PS2 BIOS unpacker - http://brokensword.narod.ru/ps2bios_unpacker.zip. It just unpacks bios image to .elf files. For exemple, my Europe v.2.00 (14/06/2004) (btw, how pcsx2 knows it?) bios contains 59 .elfs.

just launch ps2bios_unpacker.exe dump.bin
post here results of your reverseing progress.

[dlanor]

Hi guys. Plz post here all related info. Here is my simple PS2 BIOS unpacker - http://brokensword.narod.ru/ps2bios_unpacker.zip. It just unpacks bios image to .elf files. For exemple, my Europe v.2.00 (14/06/2004) (btw, how pcsx2 knows it?) bios contains 59 .elfs.

just launch ps2bios_unpacker.exe dump.bin
post here results of your reverseing progress.

Clicking that link doesn't work with Internet Explorer, because you forgot to put it in a URL bracket, so the '.' character ending the sentence is added to the end of the URL. The following link works better, http://brokensword.narod.ru/ps2bios_unpacker.zip.

Best regards: dlanor

[Robert [K-medulla]]

Thx, dlanor. I've found interesting code in Misc.c from pscx2 sources, i'll put reversed structs here soon.

[Robert [K-medulla]]

Sorry guys. PS2 BIOS unpacker has been updated, new version extracts file-modules from BIOS image useing ROMDIR structure, produces self-explanatory filenames and includes source code. Plz, check it now. The link is the same:

http://brokensword.narod.ru/ps2bios_unpacker.zip

Here is reversed modules info (in alfabetical order):


Module name Type Description

ADDDRV ELF file ???????????
CDVDFSV ELF file CDVD driver
CDVDMAN ELF file CDVD driver part?
CLEARSPU ELF file ???????????
DMACMAN ELF file DMA driver part?
EECONF ELF file EE config
EELOAD DATA EE data
EELOADCNF DATA EE loader config
EENULL DATA ???????????
EESYNC ELF file ???????????
EXCEPMAN ELF file Exception manager
EXTINFO DATA Extended BIOS info
FILEIO ELF file FILEIO service
FNTIMAGE DATA Font image data
FONTM DATA ???????????
HEAPLIB ELF file Heap library
ICOIMAGE DATA Icon images
IGREETING ELF file ???????????

to be continued...

plz, post here all related info.

[jbit]

Nice work I guess, but unless I'm missing something... this has been done before.
Also, a good chunk of the BIOS modules have been decompiled (and some published). Check out http://ps2dev.ps2-scene.org/

It'd be nice if people started documenting their findings from to reverse engineering too... Obviously some stuff doesn't want to be published, but some things are quite interesting and helpful overall.
I plan on cleaning up and releasing my notes from when I was playing with low level EE and IOP stuff, but I'm trying to focus on game stuff right now so it'll be a while.

[Robert [K-medulla]]

thx, jbit.

very useful link. you right - guy Alex Lau wrote tool for splitting the bios long time ago. here is an interesting article - http://ps2dev.ps2-scene.org/2extract.html# but there is no updates since 2003 year :(

[dlanor]

thx, jbit.

very useful link. you right - guy Alex Lau wrote tool for splitting the bios long time ago. here is an interesting article - http://ps2dev.ps2-scene.org/2extract.html# but there is no updates since 2003 year :(

Of course the existence of old solutions should never be a hindrance to producing new and improved solutions. The important thing about the previous work done in this field is that you can make use of earlier findings to ease and improve your own work.

On the subject of those old solutions I want to take this opportunity to warn you against one of the pitfalls you need to avoid. Some of the old tools have a filename length limitation of 8 characters, which does NOT correspond to that used in the ROMDIR filesystem, which allows longer names. Since some of the existing files have names that are identical in the first 8 characters, those old tools are unable to extract all the files, as some of those extracted will overwrite some of the others, when their names are truncated to 8 characters. (eg: IOPBTCONF vs IOPBTCON2) Your present code does handle this correctly, so do NOT follow any old examples when it comes to filename handling...

Unfortunately I was not able to use your program with the BIOS of my own PS2 though, as the program complains about the format. I don't see why, when it works with another BIOS file I have, and both of those BIOS files work with other software...???

In any case, all attempts to use your program with my own BIOS gives the following error message: "Invalid BIOS image file"

That file is a standard 4MB file, just like the ones it works for, and I can find the ROMDIR filenames in it with a hexeditor in the same ways too.

This might be ROM version dependent though, so here's the full ID of it:
The file name is: "SCPH-50004_BIOS_V9_PAL_170.BIN"
One ROM ID string (after the ROMDIR listing) is: "20030227-193050,ROMconf,PS20170EC20030227.bin,hana@rom-server/~/g/app/rom"

I'm not sure if that info is of any help to you in fixing this, but at least you have it... Let me know if there's anything else I can check for you concerning the compatibility of this BIOS. Too bad I can't share the file itself with you, but that would violate the rules of the forum, and various copyright laws... :(

Best regards: dlanor

[Robert [K-medulla]]

those old tools are unable to extract all the files, as some of those extracted will overwrite some of the others, when their names are truncated to 8 characters.

There is only one entry which is not handled correctly in my tool - entry with filename "-". There are 7 entries in my ROMDIR with such filename, all of them are just zero-filled junks. btw Alex Lau ignores all of them - i think it's a right way.

In any case, all attempts to use your program with my own BIOS gives the following error message: "Invalid BIOS image file"

This mesage will be displayed only if there is no "RESET" string in your image (RESET - is the first file in ROMDIR). Can you find the first occurrence of this string in hex-editor and tell me the offset of this string?
The second reason may be - ROMDIR isn't padded to 10h boundary in your image... hmm... how it can be?

[dlanor]

There is only one entry which is not handled correctly in my tool - entry with filename "-".

Good. I hoped as much. I only mentioned this limitation of the old tools to discourage you from using their methods, since I did encourage you to study the old tools earlier in my text.

There are 7 entries in my ROMDIR with such filename, all of them are just zero-filled junks. btw Alex Lau ignores all of them - i think it's a right way.

I agree. I don't think they have any real meaning at all. They are probably just 'placeholders'.

In any case, all attempts to use your program with my own BIOS gives the following error message: "Invalid BIOS image file"

This mesage will be displayed only if there is no "RESET" string in your image (RESET - is the first file in ROMDIR). Can you find the first occurrence of this string in hex-editor and tell me the offset of this string?

I've gathered some info further down, which I hope you'll find useful.

The second reason may be - ROMDIR isn't padded to 10h boundary in your image... hmm... how it can be?

Well, that doesn't seem to be it, as the first entry found is in exactly the same location as in that older BIOS which your tool does handle correctly.

I have searched for the string "RESET" inside the ROM code, and found several 16 byte entries that look like the right kind of table entry. The first such entry heads a list of such entries that matches the list of files which your program can extract, when used with another BIOS version. For comparison I have also made a similar search of an older BIOS, SCPH-39001.BIN, with the following results

Code: Select all

Found My_BIOS OldBIOS
 1st  002740  002740  What appears to be the real file list
 2nd  049190  049190  4 entry list, part of file data for EELOADCNF
 3rd  04B160  04B160  4 entry list, part of file data for OSDCNF
 4th  1CDE00  1CC5E0  7 entry list, part of file data for FNTIMAGE
 5th  1E1F10  1E06F0  15 entry list, part of file data for SNDIMAGE
 6th  245530  243D10  46 entry list, part of file data for TEXIMAGE
 7th  27F2F0  27DAD0  16 entry list, part of file data for ICOIMAGE

All of those lists had 3 similar entries at their start, named RESET, ROMDIR, and EXTINFO, though the binary data for the last two of those entries varied between all of them. Weirdly enough the binary data of the RESET entry only varied for the main list, all the other lists having identical data for it.

Is it just me, or does this look like a subfolder structure to others as well ?

I mean, all these tables look very similar, so if the first one represents a directory, isn't it logical that the others do so too ?

Best regards: dlanor

[Robert [K-medulla]]

dlanor, you are right - some of modules contain "romdir" structures at the beginning. it means that such images can be unpacked with my tool separately, e.g.

ps2bios_unpacker.exe SNDIMAGE

will produce

RESET
ROMDIR
EXTINFO
SNDBOOTH
SNDBOOTB
SNDBOOTS
SNDTNNLS
SNDCLOKS
SNDTM30S
SNDTM60S
SNDOSDDH
SNDOSDDB
SNDLOGOS
SNDWARNS
SNDRCLKS

files. I just need change one line in the source to make it possible :) i'll do it tomorrow.

For now, it's very interesting to me why my tool doesn't work with one of your images... check PM :)

[dlanor]

dlanor, you are right - some of modules contain "romdir" structures at the beginning.

Good, I thought that was the case, but actually I think it goes a bit further than that. I really believe that this is how subfolders are implemented in the rom0: device driver.

If so, then it should be possible to access all (or at least most, since some may have protection flags) of these files and folders simply by browsing that device, like any other file storage device. Sometime I really must try to add rom0: to the selectable devices in LaunchELF's file browser.

it means that such images can be unpacked with my tool separately, e.g.

----- snip ----- re: example of subfolder unpacking

I just need change one line in the source to make it possible :) i'll do it tomorrow.

That's great. But for a final solution I suggest you also add the ability to automatically deal with unpacking of subfolders, so that users don't have to identify them on their own.

For now, it's very interesting to me why my tool doesn't work with one of your images... check PM :)

Yes, that is very odd indeed. Possibly the tool I used to transfer that BIOS image made some error, but I don't think so. (It seems fine in all ways I can test.) Anyway, I've already sent you a PM about how to resolve this, so hopefully we should soon know.

Best regards: dlanor

[stefan]

Good, I thought that was the case, but actually I think it goes a bit further than that. I really believe that this is how subfolders are implemented in the rom0: device driver.

There is no support for "subfolders" or directories in the ROM filesystem. These are just plain files that have their own ROMFS internally, no different than the IOPRP images used to reset the IOP.

[weltall]

the last time i tried doing a Dopen/Dread on rom0: i got nothing

[Robert [K-medulla]]

file has been updated.

http://brokensword.narod.ru/ps2bios_unpacker.zip

i think it now supports dlanor's bios :) and it works with another ROMFS images.

auto-generation of subfolders will be implemented in next release.

stefan, i think we can call ROMFS images within main ROM image as "subfolders", because they are subfolders at all :)

[dlanor]

the last time i tried doing a Dopen/Dread on rom0: i got nothing

Ok, but that only means that those operations are not implemented for this device. Otherwise they should at least return normal info for the root directory. It may still be possible (remains to be seen) to access files as normal in those subfolders. Like for instance "rom0:/EELOADCNF/IOPBTCONF".

If that works, then 'files' like "EELOADCNF" really are subfolders, though the device driver lacks support for some directory operations.

Best regards: dlanor

[dlanor]

Good, I thought that was the case, but actually I think it goes a bit further than that. I really believe that this is how subfolders are implemented in the rom0: device driver.

There is no support for "subfolders" or directories in the ROM filesystem.

If you say so, then I have no real argument against it, as I have not analyzed how that device driver works. However, from a functional viewpoint, those files I spoke of are used merely as containers for other files. So we can still regard them as subfolders, and treat them as such in unpacking the files. (Creating a new subfolder for each group of files that were contained this way.)

These are just plain files that have their own ROMFS internally, no different than the IOPRP images used to reset the IOP.

Some of them, like EELOADCNF, are indeed used to reset the IOP. But remember that this is normally done through UDNL, which in turn searches EELOADCNF for the file IOPBTCONF. In other words, it treats the passed name "EELOADCNF" as the name of a subfolder which it searches for the needed file.

The only real difference (and one I still haven't tested) is whether or not the support for this subfolder access is in the device driver or in the accessing program (here UDNL). In the first case these really are true subfolders, and in the latter case they are not.

Best regards: dlanor

[dlanor]

i think it now supports dlanor's bios :) and it works with another ROMFS images.

I can confirm that it works fine for me now, with all the BIOS versions I have (only 3, so others need to test this too).

auto-generation of subfolders will be implemented in next release.

Great, that eliminates the risk of losing some IOPBTCONF files, as some BIOS contain several files using that name (mine has 3). This may also apply to other files, though I haven't noticed it.

Best regards: dlanor

[jbit]

I reversed a version of ROMDRV a while ago. I'll try to put it up tomorow if somebody thinks it'll be useful.

[Robert [K-medulla]]

Unpacker has been updated. Now with "subfolders" feature. Ugly source, hope I'll optimize it someday...

jbit, just keep in mind legality problem :)

[weltall]

to hack the rom disc you could use my ps2shell who accept input from keyboard so it's not needed to rebuild every time an application to test this, just load the iop driver, if needed, and then try to access the file.
it's still a beta application but can be usefull.. (it's based on fileio)