PSP FW 2.70 RELEASED, PSP[I] use New Ver 2.60

[0okm0000]

PSP-1000
　　100V
WS259　I

release:2.60:
build:985,0,3,1,0:root@vsh-build
system:29904@release_260,0x02060010:
vsh:p5029@release_260,v20603@release_260_2,20051209:
target:1:WorldWide

on 2006-04-25 SONY JP will RELEASE FW 2.70
http://www.jp.playstation.com/psp/update/ud_01.html

FW 2.70 RELEASED
Content-Length: 19102705
http://dj01.psp.update.playstation.org/ ... /EBOOT.PBP

[Chrighton]

Firmware 2.70 coincides with a new PSP downloadable/playable demo (Loco Roco). Something to explore :)

[0okm0000]

i mod. PspPet's PSAR Dumper .02A w/o Decrypte
but can not decode Special PSAR records second block...

PSAR Dumper .02A w/o Decrypte
by PspPet
version .02A
PSAR file loaded (15052544 bytes)
special PSAR records:
version info - 272 bytes
Sys_DecodeE returned $ffffff32 144
Failed to decode(2)

[0okm0000]

release:2.70:
build:1238,0,3,1,0:builder@vsh-build2
system:33151@release_270,0x02070010:
vsh:p5186@release_270,v22631@release_270,20060420:
target::WorldWide

release:2.60:
build:985,0,3,1,0:root@vsh-build
system:29904@release_260,0x02060010:
vsh:p5029@release_260,v20603@release_260_2,20051209:
target:1:WorldWide

release:2.60:
build:962,0,3,1,0:root@vsh-build
system:29904@release_260,0x02060010:
vsh:p5029@release_260,v20391@release_260,20051125:
target::WorldWide

release:2.50:
build:863,0,3,1,0:root@vsh-build
system:28611@release_250,0x02050010:
vsh:p4810@release_250,v19039@release_250,20051011:
target:1:WorldWide

release:2.01:
build:822,0,3,1,0:root@psp-vsh
system:26084@release_200,0x02000010:
vsh:p4793@release_201,v18444@release_201,20050928:
target:1:WorldWide

release:2.00:
build:725,0,3,1,0:root@psp-vsh
system:26084@release_200,0x02000010:
vsh:p4705@release_200,v15867@release_200,20050726:
target:1:WorldWide

release:1.52:
build:555,0,3,1,0:root@psp-vsh
system:23740@release_152,0x01050200:
vsh:p4421@release_152,v13394@release_152,20050525:

release:1.51:
build:513,0,3,1,0:root@psp-vsh
system:22984@release_151,0x01050100:
vsh:p4388@release_151_sc,v12875@release_151_sc,20050507:

release:1.50:
build:376,0,3,1,0:root@psp-vsh
system:20182@release_150,0x01050001:
vsh:p4201@release_150,v11079@release_150,20050201:

release:1.00:
build:228,0,3,1,0:root@psp-vsh
system:17919@release_103a,0x01000300:
vsh:p4029@special_day1,v9972@special_day1,20041201:

release:1.00:
build:106,1:root@psp-vsh
system:16214,0x00100000:
vsh:2004_1104_s16214_p3883_v8335:

[emiisdev]

link to locoroco demo eboot:
http://www.jp.playstation.com/scej/titl ... al_dl.html

it's a cute game. sony should have been doing game demos since day one.

emi

[Fanjita]

The LocoRoco demo appears to be a simple signed EBOOT. Editing the PARAM.SFO will allow you to launch it on lower firmwares than 2.7, but it doesn't really start before producing an error popup of 80020001 - the only meaning we have for that is "Error". Possibly it's an unresolved NID for a function that's only present in 2.7.

The GTA exploit appears to have been patched by somehow detecting the hacked data during the loadgame API calls. The saves don't show as corrupt in the XMB save browser, or on initial viewing within GTA, but when GTA tries to load them it displays the error "the data is corrupt". My guess is that the loadgame API has been patched to do some sort of special detection of the exploit, if the game key supplied corresponds to a version of GTA. I've only tested the UK/general EU version of GTA, but I think we can assume that the US and DE versions are also covered.

More experiments later to try to find out just what pattern the API is trying to detect.

[moonlight]

The LocoRoco demo appears to be a simple signed EBOOT. Editing the PARAM.SFO will allow you to launch it on lower firmwares than 2.7, but it doesn't really start before producing an error popup of 80020001 - the only meaning we have for that is "Error". Possibly it's an unresolved NID for a function that's only present in 2.7.

In my psp (1.50), it produces a 0x80020148 error (unsupported prx type)

[Fanjita]

In my psp (1.50), it produces a 0x80020148 error (unsupported prx type)

Isn't that the classic error when the module is unencrypted? Presumably v1.5 doesn't support the encryption method in the EBOOT.PBP. I was testing on v2.6.

[ryoko_no_usagi]

More experiments later to try to find out just what pattern the API is trying to detect.

I don't know any details of the flaw in GTA but it would be stupid if the patch did something other than check the length of the input data that causes the overflow.

[zshadow]

The LocoRoco demo appears to be a simple signed EBOOT. Editing the PARAM.SFO will allow you to launch it on lower firmwares than 2.7, but it doesn't really start before producing an error popup of 80020001 - the only meaning we have for that is "Error". Possibly it's an unresolved NID for a function that's only present in 2.7.

In my psp (1.50), it produces a 0x80020148 error (unsupported prx type)

you could try replacing the prx files in the data.psp, although if it relies on new 2.7 syscalls it most likely won't boot still.

[kuroitenchi]

you could try replacing the prx files in the data.psp, although if it relies on new 2.7 syscalls it most likely won't boot still.

You cannot actually decrypt a prx unless you can run kernel mode code, and as far as I am aware, the 1.00/1.50 firmwares do not possess the required keys to decrypt this data.psp files, I also tested decrypting it with 2.00-2.50 keys but all I got is a FFFFFFFF error (witch means decryption error) So there are actually no ways to extract any prx files from the data.psp unless we figure out the key needed to decrypt it (witch is probably only embebed in 2.70 (and maybe 2.60))

Beside speaking about the 2.70 Update it seems that :

- The psar format changed

- The modules embebed within the updater changed :

The new modules are :

- scePSAR_Driver (modified form the eariler updaters but that's obvious)

- sceTexureLoader

- sceUpdate_driver

- ConvertTex

- CheckSwTimer

- sceNetworkUpdate

and

- SetDisplayBuffer

The remaining unchanged modules are:

- IplUpdater (needed to overwrite the ipl)

- sceLflashFatfmt (needed to overwrite flash0)

- sceSuspendCaneler (probably the sleep mode remover)

- sceChkuppkg

All of those modules can be extracted and decrypted using 1.00/1.50 fw.


To finish, most earlier modules were removed in this newer updater revision the removed modules are :

- coldreset_updater

- LeptonUpdaterfor103

- LeptonUpdaterfor150

- SecureRtcReset

- sceUmdEx_driver

Since all those modules are needed to the updaters I believe that they are hidden within one or serveral of the newer modules, Sony probably changed them as an antempt to obscure the updating process.


Finally here is the updater version info:

release:1.00:
build:190,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0x01000300:
vsh:p5181@updater_270,v22592@updater_270,20060420:

@0okm0000: Could you tell us what are the differences between the 2.60 from the eboot and the pre-flashed 2.60 from the "I" psp version ?
What modules or ressources files were exactely changed ?

[zshadow]

you could try replacing the prx files in the data.psp, although if it relies on new 2.7 syscalls it most likely won't boot still.

You cannot actually decrypt a prx unless you can run kernel mode code, and as far as I am aware, the 1.00/1.50 firmwares do not possess the required keys to decrypt this data.psp files, I also tested decryptiong it with 2.00-2.50 keys but all I got is a FFFFFFFF error (witch means decryption error)
So there are actually no ways to extract any prx files from the data.psp unless we figure out the key needed to decrypt it (witch is probably only embebed in 2.70 (and maybe 2.60))

Ah, I didn't know they encrypted the data.psp itself with the new keys (havent taken a look at it yet). in that case it seems like we are out of luck for now until we get the new decryption keys =/

[Fanjita]

Ah, I didn't know they encrypted the data.psp itself with the new keys (havent taken a look at it yet). in that case it seems like we are out of luck for now until we get the new decryption keys =/

Considering how far it gets before failing, I'd say the keys must be present on v2.6. I didn't time anything, but subjectively the time to error (on v2.6) was the same as time-to-loco-roco-screen (on 2.7), i.e. the failure seemed to be very late in the loading process.

My 2.6 is now updated to 2.7, so I can't run any further tests I'm afraid.

[Fanjita]

More experiments later to try to find out just what pattern the API is trying to detect.

I don't know any details of the flaw in GTA but it would be stupid if the patch did something other than check the length of the input data that causes the overflow.

That seems most likely, but an alternative is that they're checking for a particular code sequence. I'm hoping that's the case, as it ought to be simple to bypass. I can't see any way how a check that understands the GTA-specific file format -- which is, in bare-bones essence:

Code: Select all

int size_of_struct;
struct {
   player data
}

can really be defeated if it checks that size_of_struct is within range.

EDIT: Update:
I've verified that the savegame API is checking that the struct size is exactly what it's expect to be. Lower, higher, and negative values all fail to load.

Seems like this avenue is now closed on 2.7 and beyond.

[PspPet]

> mod. PspPet's PSAR Dumper .02A w/o Decrypte
> but can not decode Special PSAR records second block...
...
>Sys_DecodeE returned $ffffff32 144
> Failed to decode(2)

Get PSAR dumper .02"B"
http://www.aibohack.com/psp

[jimparis]

... sorry, wrong button

[dot_blank]

psppet: woopee thanx :)