Page 1 of 1
PS2 BIOS reverseing
Posted: Tue Oct 11, 2005 12:08 pm
by 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.
Re: PS2 BIOS reverseing
Posted: Tue Oct 11, 2005 8:06 pm
by dlanor
Robert [K-medulla] wrote: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
Posted: Tue Oct 11, 2005 8:20 pm
by Robert [K-medulla]
Thx, dlanor. I've found interesting code in Misc.c from pscx2 sources, i'll put reversed structs here soon.
Posted: Thu Oct 13, 2005 5:20 pm
by 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:
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.
Posted: Thu Oct 13, 2005 5:41 pm
by 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.
Posted: Thu Oct 13, 2005 6:09 pm
by 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 :(
Posted: Fri Oct 14, 2005 10:10 am
by dlanor
Robert [K-medulla] wrote: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
Posted: Fri Oct 14, 2005 3:28 pm
by 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?
Posted: Fri Oct 14, 2005 9:59 pm
by dlanor
Robert [K-medulla] wrote: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
Posted: Fri Oct 14, 2005 11:02 pm
by 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 :)
Posted: Sat Oct 15, 2005 12:42 am
by dlanor
Robert [K-medulla] wrote: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
Posted: Sat Oct 15, 2005 1:04 am
by stefan
dlanor wrote: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.
Posted: Sat Oct 15, 2005 1:48 am
by weltall
the last time i tried doing a Dopen/Dread on rom0: i got nothing
Posted: Sat Oct 15, 2005 2:50 am
by 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 :)
Posted: Sat Oct 15, 2005 10:54 am
by dlanor
weltall wrote: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
Posted: Sat Oct 15, 2005 11:12 am
by dlanor
stefan wrote:dlanor wrote: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
Posted: Sat Oct 15, 2005 11:32 am
by dlanor
Robert [K-medulla] wrote: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
Posted: Sat Oct 15, 2005 11:40 am
by 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.
Posted: Sat Oct 15, 2005 8:35 pm
by 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 :)
Posted: Sun Oct 16, 2005 12:18 am
by 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)