i've dumped the lflash device and it seems that there are four fat-12 partitions on it:
0x00000000...0x017FC1FF (~24MB) flash0 files
0x01800000...0x01BFC1FF (~4MB) flash1 files
0x01C00000...0x01CFC1FF (~1MB) no files
0x01D00000...0x01DEC1FF (~1MB) no files
lflash device
Re: lflash device
Perhaps the 2 1M partitions are bootstrap/loader and system specific information, region coding, etc.... any chance of a hex dump?Vampire wrote:i've dumped the lflash device and it seems that there are four fat-12 partitions on it:
0x00000000...0x017FC1FF (~24MB) flash0 files
0x01800000...0x01BFC1FF (~4MB) flash1 files
0x01C00000...0x01CFC1FF (~1MB) no files
0x01D00000...0x01DEC1FF (~1MB) no files
Cheers
-
pedroleite
- Posts: 39
- Joined: Sun Apr 10, 2005 8:31 am
Either the device is mapped to a diferent address... or the bootstrap isn't there...
Wasn't there an 8MB bootstrap area just before the FAT partitions?
Wasn't there an 8MB bootstrap area just before the FAT partitions?
Last edited by pedroleite on Fri May 20, 2005 8:44 pm, edited 2 times in total.
yes there is fat12-file-structure-data (BPB, FAT-Table, ...)laichung wrote:no file doesnt mean no data , right?
in all probability, but there is no bootstrap in lflashlaichung wrote:the bootstrap may be not a FAT file format~~~
hmm, silly question. no, only in text form ;-)laichung wrote:Anyway , can we read/dump the flash in binary form?
Any chance we can use say Wipeout's browser that runs a command using redirected proc://command/http://eu.playstation.com/ingame_sites/ ... oad.pspdif to custom pspdif command file, to flash an image of ver1.0 on a ver1.5?
(after we write a proper command for filetransfer via lflash of the flash images of 1.0, and sign it properly http://forums.ps2dev.org/viewtopic.php?t=1795 )
(after we write a proper command for filetransfer via lflash of the flash images of 1.0, and sign it properly http://forums.ps2dev.org/viewtopic.php?t=1795 )
Please read the thread you quoted again. Only the hardware ID file on PSP is signed and the applet is only getting a zip file from internet, extracts it and places the files on the memory stick. But the extracted files could be encrypted, signed and anything else, too, so this doesn't help. And why should a Wipeout Pure update procedure allowed to store some unencrypted firmware update?MindWall wrote:Any chance we can use say Wipeout's browser that runs a command using redirected proc://command/http://eu.playstation.com/ingame_sites/ ... oad.pspdif to custom pspdif command file, to flash an image of ver1.0 on a ver1.5?
(after we write a proper command for filetransfer via lflash of the flash images of 1.0, and sign it properly http://forums.ps2dev.org/viewtopic.php?t=1795 )
actually I was refering to the pspdif file, which gives the commands to be performed in order to create an update of the game. And this commands should include "download the game-pack" and "unpack the files in some directory".
The pspdif is probably not encrypted as the eboot.pbp.
The idea is to create a proper valid replacement of the pspdif and redirect the wipeout browser to execute it (not as ELF but commands for file manipulation). And in the "new" pspdif the instructions will be to "copy ver1.0 files" (using lflash) to flash.
so we'll replace the flash contents of ver1.5 with ver 1.0, shouldn't be enough? (since the person who had made a copy of the flash can take the battery off, and when placed back his PSP should start. the same should be with a 1.5 flashed with 1.0?) unless of course theres some unique hardware ID tied up with the flash information...
just pondering
The pspdif is probably not encrypted as the eboot.pbp.
The idea is to create a proper valid replacement of the pspdif and redirect the wipeout browser to execute it (not as ELF but commands for file manipulation). And in the "new" pspdif the instructions will be to "copy ver1.0 files" (using lflash) to flash.
so we'll replace the flash contents of ver1.5 with ver 1.0, shouldn't be enough? (since the person who had made a copy of the flash can take the battery off, and when placed back his PSP should start. the same should be with a 1.5 flashed with 1.0?) unless of course theres some unique hardware ID tied up with the flash information...
just pondering
-
pedroleite
- Posts: 39
- Joined: Sun Apr 10, 2005 8:31 am
I've spent a couple of minutes with the Java code...
From what I can tell it shows the tweaked ideia of encryption from Sony :)
XOR with a cyclic sha1...
What happens is that breaking the SHA1 while prove too hard... but...
The process is a simple XOR byte for byte with a buffer...
The buffer is initialized by concatenating the SEED (20 bytes after each record on DATA2.BIN) with the internal Key, hard coded on the class.. and calculating the SHA1 result. The result from SHA1 is a 20 byte array...
When this buffer is consumed, it's contents are concatenated with the internal key again, and computed the SHA1... stored on this buffer.
This implies that the seed should be a 20 byte (160 bit) array... I've done some calculations and the sizes of encrypted stuff is correct (download.pspdif, DATA1.BIN from the same place of this DATA2.BIN)
Of interest would be to find the position of the seed and if the SAME internal key is used.
The fact that XOR is used with SHA1 block, could lead to an empirical determination of the key used. (brute-force anyone?)
Also, all the binary values not yet determined on the PARAM.SFO could lead to some kind of key.
Knowing the "block" size of the cipher can lead to more statistically correct attacks.
From what I can tell it shows the tweaked ideia of encryption from Sony :)
XOR with a cyclic sha1...
What happens is that breaking the SHA1 while prove too hard... but...
The process is a simple XOR byte for byte with a buffer...
The buffer is initialized by concatenating the SEED (20 bytes after each record on DATA2.BIN) with the internal Key, hard coded on the class.. and calculating the SHA1 result. The result from SHA1 is a 20 byte array...
When this buffer is consumed, it's contents are concatenated with the internal key again, and computed the SHA1... stored on this buffer.
This implies that the seed should be a 20 byte (160 bit) array... I've done some calculations and the sizes of encrypted stuff is correct (download.pspdif, DATA1.BIN from the same place of this DATA2.BIN)
Of interest would be to find the position of the seed and if the SAME internal key is used.
The fact that XOR is used with SHA1 block, could lead to an empirical determination of the key used. (brute-force anyone?)
Also, all the binary values not yet determined on the PARAM.SFO could lead to some kind of key.
Knowing the "block" size of the cipher can lead to more statistically correct attacks.
Since firmware 1.50 flash0 directory is about 12.5 Mb,0x00000000...0x017FC1FF (~24MB) flash0 files
0x01800000...0x01BFC1FF (~4MB) flash1 files
0x01C00000...0x01CFC1FF (~1MB) no files
0x01D00000...0x01DEC1FF (~1MB) no files
it seems there is almost room for a duplicate copy of firmware there.
What would happen if you tried to write a file that would not fit on flash0?
Maybe nobody has found out..... also wonder if MPH fw launcher could load firmware from folders placed in there.
hmm, the ini file assumes files are on the ms.. but it could be written another way.
Try to dump the IPL:/ device :)
It can be used to write the IPL using sceIo :)
Although I don't know much about it as when I dump it's content I just end up with some part of the psp ram.
Still there are chances that it's one of the 1MB devices Vampire found. I dont' know what the other would be for tough.
If you plan to replace the 1.50 flash0 to the 1.00 flash0 don't forget to change the IPL as well or your psp will be bricked.
It can be used to write the IPL using sceIo :)
Although I don't know much about it as when I dump it's content I just end up with some part of the psp ram.
Still there are chances that it's one of the 1MB devices Vampire found. I dont' know what the other would be for tough.
If you plan to replace the 1.50 flash0 to the 1.00 flash0 don't forget to change the IPL as well or your psp will be bricked.