forums.ps2dev.org

Ok, I gave more support to Sony by purchasing SCPH-50000 MB
(the midnight blue model) and a "Frontline Mission 3" PS1 disc. This
is PS2 system #3 for me. (I gutted #2 awaiting EE serial install and
couldn't wait anymore to play certain games).

I added SLPS_914.47 to TITLE.DB and then made BIDATA-SYSTEM
a complete copy of BADATA-SYSTEM files. Unfortunately, the system
seems to bypass the exploit. Does anyone have any knowledge of
the exploit working or not working on SCPH-50000 models ? Am I
forgetting anything ?

Any help would be appreciated :)

Gorim

Ithougt that correct procedure is to let the system to generate it's own BXDATA-SYSTEM and then modify the content. Maybe the I and A data content is not compatible...

ole wrote:Ithougt that correct procedure is to let the system to generate it's own BXDATA-SYSTEM and then modify the content. Maybe the I and A data content is not compatible...

*shrug* I have always created BADATA-SYSTEM on my memory cards and it worked fine. I always created it myself because once the system created it I could not access it from PS2Linux.

In my case, I now have BADATA-SYSTEM and BIDATA-SYSTEM on the same memcard, but since they are for different region PS2's I would not have thought there should be a problem.

Gorim

I'm using the exploit on an American/NTSC SCPH-50001/N (comes with network adapter already installed). Mine has the IR built-in so no joystick port is taken up when using the DVD remote. How are you getting the BIDATA-SYSTEM installed to the memory card?

I am installing the BIDATA-SYSTEM via PS2Linux with the modified memcard kernel module. This method has worked well installing BADATA-SYSTEM for USA PS2's in the past, but this is the first time I am doing it for a JPN system.

It's possible that the exploit is fixed in your revision PS2, though I doubt it. You wouldn't happen to be using the HDD OSD would you? I think that would nullify the exploit.

Actually no, I had already removed the originally installed HD in order to move my PS2Linux drive to this system, so I am not using the HD OSD.

The interesting thing is, it doesn't appear to be activating the exploit at all.
If my understanding of payload.c is correct, if at any time nothing works,
it gets sent to a while (1);. Oh, and the screen color is supposed to change
at the beginning any way.

But, here, it just merrily passes right along to the PS1 game. I have tried
a different JPN PS1 disc, I have recreated an empty database, even tried
deleting entries from near beginning of the working database and repopulating.

The even more interesting thing, is the Playstation Driver version on the
SCPH-50000MB is 1.02, whereas on the US SCPH-30001 it is 1.10. Dunno
if that means anything at this point.

Gorim

Have you got the case of the main exe correct ? I have run the exploit quite happily on a 50k PAL unit for quite a while, only thing I screwed up was I put the exe file in using the wrong case and it didn't work :)

Well, for starters, I have been using a TITLE.DB that works just fine on the 30001. In fact, I regularly move the memcard between a US 30001 and the JPN50000, same TITLE.DB in BADATA-SYSTEM and BIDATA-SYSTEM. Sure, afterwards I tried playing around with creating a new TITLE.DB to no effect.

So, I am not sure if that answers the question about MAIN.EXE, I wasn't touching anything already in the TITLE.DB. If I create a new TITLE.DB, do I have to add some sort of MAIN.EXE entry ?

Gorim

Unfortunately, it sounds like the overflow has been fixed in that series. Unless someone else can think of why it wouldn't work? The version number seems very suspicious - is that 1.20 or 1.02?

Well thats the odd thing :) The version number is 1.02, (not 1.20), which
makes it much less than the 1.10 on the US 30001 model. My JPN 30000
is torn apart so I can't compare its version number.

However, the version numbers right now don't give a healthy idea either
way whether the bug is fixed, although that COULD be the case, even though
it isn't fixed in the USA and EU 5000x models.

Oh well...

Thanks for all the help and ideas anyway :)

Gorim

Well, after a grueling evening, I put the JPN 30000 back together.

3 year old scph-30000
- Booted the memcard exploit just fine
- PS1 driver is v1.01.

Brand new scph-50000MB
- Does not boot exploit
- PS1 driver is v1.02.

Since others with 5000x models in North Amer. and Europe can boot
the exploit just fine, it must be that Sony has finally fixed it and it is
making its way into newly manufactured models.

I think I know why the exploit is being fixed now. :( it's because of people using it for evil. :(


If this is true,t hen i guess people will have to start using ARMAX 3.30 or greater to boot their stuff. That SUX.

gorim wrote:Well, after a grueling evening, I put the JPN 30000 back together.

3 year old scph-30000
- Booted the memcard exploit just fine
- PS1 driver is v1.01.

Brand new scph-50000MB
- Does not boot exploit
- PS1 driver is v1.02.

Since others with 5000x models in North Amer. and Europe can boot
the exploit just fine, it must be that Sony has finally fixed it and it is
making its way into newly manufactured models.

I do not have this problem with my 50x console. My only suggestion for you would be to dump your bios and having a peek at ps1drv

Darren wrote:
I do not have this problem with my 50x console. My only suggestion for you would be to dump your bios and having a peek at ps1drv

Darren,

I have already established that some people do not have problems with
their 50x consoles. I am attempting to determine boundary conditions,
such as PS1 driver version, to determine which consoles work and which
do not. If it can be explained by driver version (which would make sense,
if Sony fixes something in it, they increment the version number) then
there is no need to to dump bios and peek inside.

So, what version is your PS1 driver ? What is the full model number of
your system ? (If you don't know how to check PS1 driver version, go
to your console browser and press <triangle>).

I am hypothesizing what works and what doesn't based on the following:

JPN console follow this general driver version pattern:
scph 15000 - 1.00 (works)
scph 30000 - 1.01 (works)
scph 50000 (older ones) - 1.01??? (works??)
scph 50000 (newer ones) - 1.02 <--- doesn't work

US consoles follow this general driver version pattern:
scph 30001 - 1.10 (works)
scph 50001 - ???? (known to work, but not sure about immediately recent models)

and so on similarly for EU & Asia models...

Gorim

I'm using a silver 50003, PS1 Driver ver is 1.11 without any problems.

i would suspect that the 50xMB has the hdd browser files built in due to the fact that its available with the hdd and na bundled together. would be best to backup your bios and have a look to settle this once and for all.

50006 and 50007HK units, no problems with the exploit whatsoever

Guichi wrote:i would suspect that the 50xMB has the hdd browser files built in due to the fact that its available with the hdd and na bundled together. would be best to backup your bios and have a look to settle this once and for all.

50006 and 50007HK units, no problems with the exploit whatsoever

Actually, the 50000MB is bundled with the BB navigator disk that must be
installed to use the HDD.

And my response to you is the same as Darren, I already established that
*some* 5000x do work with the exploit. Please read the earlier messages
in this thread.

And please, if you are aware of a working 50006/7 unit, please indicate
the PS1 driver version number. If we can tie this down to a PS1 driver
version number, its a heck of a lot less effort than digging through BIOS
code in order to confrim the same thing. It really isn't difficult, trust me,
to find that version number, anyone can do it. Just go to the browser
screen. Thank you.

Gorim

US SCPH-50001/N PlayStation Driver v1.11 (works)

I don't know of anyone that has anything newer than the SCPH-50001.

In case Sony has fixed overflow in the PS1 driver, I wondered what verifications are done before the PS2 decides to use a newer DVD player from the memory card. Is there anyway of creating a dvdplayer.elf that the PS2 would consider valid for purposes of hijacking code execution?

fluke wrote:US SCPH-50001/N PlayStation Driver v1.11 (works)

I don't know of anyone that has anything newer than the SCPH-50001.

In case Sony has fixed overflow in the PS1 driver, I wondered what verifications are done before the PS2 decides to use a newer DVD player from the memory card. Is there anyway of creating a dvdplayer.elf that the PS2 would consider valid for purposes of hijacking code execution?

Thanks boomint and fluke!

The pattern so far is, models with no "2" in the driver version work.

Two questions I have:
Are there older JPN 50000 models that are driver 1.01 and therefore work ?
Are there *very* new US/EU 5000x models that are driver v1.12, and
have been checked for PS2Ind success ?

The dvdplayer.elf is an interesting question...what if anything can be
done with it ? :)

Gorim

I thought the DVD player trick would be a good idea, mostly since it'd work on any dvd, not just a particulat ps1 game..

But I remember looking at it in ps2menu and trying to run the player directly from there, and got an invalid ELF error...
So i guessed its one of those encrypted elfs, and it'd be just a little bit funky to try make one ourselves...

The DVD player is a pretty obvious insertion point for foriegn code and i'm willing to bet that sony did a good job of keeping that door locked up tight..

Also, they probably want to keep the lid on 3rd party players and force us all to buy the official one...

cheriff wrote:The DVD player is a pretty obvious insertion point for foriegn code and i'm willing to bet that sony did a good job of keeping that door locked up tight..

Does "MagicGate" ring a bell to you ? :-P

Yeah. It rings the same bell as Adobe eBook format, MS eBook format, DVD CSS, Apple FairPlay, etc. of DRM formats that have fallen to third party cryptographers. The only thing that MagicGate seems to have going for it over the other cracked DRM format is a lack of popular use (while there are several Sony compliant devices, the actual *use* of the system is still relatively low). I expect that if OpenMG actually gains any popularity (such as with compatiblity with PSP) then eventually someone will release MG's "secrets." Until then, I guess hacking via the PS2 DVD Player upgrade launcher will have to wait on the back burner.

This does explain why dvdplayer.elf doesn't have a valid ELF header and looks like random garbage. But does anyone know what the purpose of dvdplayer.dmy is? It appears to be 458037 bytes of null (0x00). If the memory card file system uses 1024 byte blocks and the directory itself takes a block then the baexec-dvdplayer would take up exactly 2MB on the memory card. But it is not like MG is being applied to the whole save directory since it is clear that dvdplayer-e.ver, dvdplayer.ico, dvdplayer.id dvdplayer-j.ver and icon.sys are not encrypted/obfuscated. I'm not sure about dvdplayer.irx, but it seems like only dvdplayer.elf has been obfuscated. I'd be interested in hearing from anyone reverse engineering the BIOS as to how the launcher for the DVD Player works.

Well. Okay, go crack MagicGate. But, before, have a look to what happened to people who cracked CSS, or PDF cryptos. I don't think people over here would be happy to host any exploit involving that.

I don't have the cryptography or reverse engineering skills to attack MG. But the person that broke CSS was successfully defended by the EFF and DeCSS was mirrored on several websites. PDF crypto is not intended to be secret, Adobe has honored the request of the xpdf author to release the crypto information since PDF is intended to be an open format. It's eBook format which is supposed to have DRM support.

Also, unless MG encrypts the file a different way for every MG device, there should be no need to include the MG DRM information in any package that exploits the DVD player launcher. Instead, only the pre-encrypted file would need to be provided.

But regarding your last point, it seemed to me that DeCSS had a much easier time finding hosting web sites than I have had in getting my repackaging of Mr Brown's exploit hosted (which really doesn't break any DRM at all). So, I'll continue holding my breath until Oobles gets back to me about registering for a ps2dev account. Is it normal for the face to start turning blue?

As the originator of this thread, I request that a moderator lock this thread immediately.

I do *NOT* want this to generate into discussion on cracking magicgate,
nor a discussion on the legalities, rightness, wrongness, etc of doing so.
For any of those, the topics are *NOT* appropriate nor representative of
the goals of the PS2Dev community. If anyone doesn't realize that, then
one better realize it fast.

Enough said, end of story.

Thank you everyone so far for your helping on SCPH-5000x PS1 driver
versions.

Gorim

Sorry to add something to a locked thread, but, as far as I know, the two people who cracked PDF crypto and CSS are now in jail. If you wanna follow the same path, that's your problem. But we do NOT want to get involved into that.