Waninkoko Released a idea to Develop a PS3 CFW 3.60 / 3.61
Here is a brief update from PS3 Waninkoko, sharing his thoughts on how to develop a full-fledged PS3 CFW 3.60 / 3.61 followed by some details from groveritos below.
This news comes following a PlayStation 3 Custom Firmware hybrid update to PS3 CFW VENIX S-PLUS Spoofing 3.65. To quote, roughly translated:
1. Private keys can not be calculated for any firmware> = 3.56, and are NOT in any site, which for some are private (only the Sony has, and if we make a mistake it was thanks to them which they applied the algorithm So encryption of data and a few mathematical operations could calculate the private keys).
2. IF you can create a CFW 3.61, the only obstacle is to get the public keys, which can be drawn SI, with varying degrees of difficulty but you can. Each loader is encrypted with a private key and decrypted with the corresponding public key. But the lowest level loader in a FW is encrypted and decrypted with the root key, which is invariably because the root public key used to decrypt the loader is located in the metldr (obviously, the metldr will have to have the public key to decrypt the loader) and metldr NOT be updated in any way, so that the root key can not be changed from one version to another firmware because it is sad if any.
So if you want to create a CFW of 3.61, changing the LV2 to add new features, we have to go hacking the chain of loaders to get on. Example:
METLDR -> LV0LDR -> LV0 -> LV1LDR -> LV1 -> LV2LDR -> LV2
More or less this is the chain of loaders (do not know if there is some small variation in FW 3.61).
METLDR, as I said, NO you can update.
METLDR LV0LDR decode the root key (LV0LDR loader is the lowest level, if we do not have to METLDR) and executes it.
LV0LDR LV0 decode the LV0-key (this key if you can change between versions of firmware as LV0LDR SI is upgradeable and can therefore LV0 encrypt a private key and update LV0LDR to decode it with the new corresponding public key) and runs.
Decrypts LV0 LV1LDR ....
LV2 LV2LDR decrypts the lv2-key and executes it.
Therefore, if you want a CFW, we need to decipher LV0LDR (with the root key, which geohot public and will never change), change LV0LDR change LV0 decryption key (the change of a key that is capable of decoding a LV0 encrypted with a private key that we DO know ... that private key? anyone, as if we generate a key), encrypt LV0LDR with the root key, and we can modify LV0 to our liking and is now LV0 deciphered with a different public key, which we know the private key. And so we change the whole chain to LV2, modify and recifrarlo with the new key we've chosen.
Well, that's the way broadly told (when I say encrypt / decrypt, I do not mean the contents of the loaders, because it works with AES encryption and symmetric and there is no question of public / private key, but I mean really at the head of such loaders, for signature, which uses RSA keys is where public / private partnerships, with the sole purpose of checking that these loaders have NOT been changed).
In the case of FW 3.61 the track is a bit more complex as there are RSA public key and AES keys that are easy to obtain, but hey, there are methods to obtain, there are people who have them, and therefore it is not impossible .
Now, we must take into account that a CFW can be installed only if the console is in a FW 3.55 or lower, because higher versions will make use of a new updater, which verifies the upgrade package (internal data the PUP, so I understand) by checking with new firms (which had not previously existed and are now mandatory) which we have neither the public nor the private key (the public can take, but privately we can forget and here no no chain so we can prevent this ... the updater is a separate application of FW and no longer has to do with the above explained).
Said this last, some will think that if the upgrade to a CFW 3.56/3.60/3.61 and thou mayest not reinstall any other CFW (that is, you stay forever in that CFW or FW actualizais an official). The answer is yes, but hey, is not inevitable and that, in creating this CFW, we can modify the VSH (or one) to use the old updater (which does not check new firms and therefore we have no obstacle to install new CFW), or modify the APPLDR to allow us to load the new updater but modified to not check signatures (the new updater can be changed, of course, but also need to modify our FW APPLDR currently installed to the recifrar updater with a private key known and APPLDR then be able to decrypt and run).
And that's all.
From groveritos: teknoconsolas.es/foro/viewtopic.php?f=214&t=983 19&hilit=
Code:
SELF header
elf # 1 offset: 00000000_00000090
header len: 00000000_00000500
target offset: 00000000_000001e0
PhDr offset: 00000000_00000040
shdr offset: 00000000_0003cc68
file size: 00000000_0003cab8
auth id: 1ff00000_01000001 (Unknown)
vendor id: FF000000
info offset: 00000000_00000070
sinfo offset: 00000000_00000140
offset version: 00000000_00000180
control info: 00000000_00000190 (00000000_00000070 bytes)
app version: 1.90.0
SDK type: Retail (Type 0)
app type: level 0
Control info
control flags:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
digest file:
The 8th 7c 62 80 b1 b9 8c 38 e3 2c the 6th August 17, 1972 09 57 25 86 e4 9e
F5 d8 24 60 94 98 48 4c b6 ae af bd 2c 47 92 ba e5 7b April 1919
Section header
unk2 unk1 offset encrypted compressed size
00000000_00010500 00000000_00000ae8 [NO] 00000000 00000000 [YES]
00000000_00020720 00000000_0001c590 [NO] 00000000 00000000 [YES]
Metadata Encrypted
Unable to decrypt metadata (not the metadata decrypy)
ELF header
type: Executable file
machine: PowerPC64
version: 1
PhDr offset: 00000000_00000040
shdr offset: 00000000_0003c7f8
entry: 00000000_00037b48
flags: 00000000
header size: 00000040
Head size: 00000038
program headers: 2
section header size: 00000040
section headers: 11
section header string table index: 10
Program headers
vaddr offset type paddr
SPE PPU filesize memsize align RSX
LOAD 00000000_00010000 00000000_00000000 00000000_00000000
00000000_00000ae8 00000000_00000ae8 00000000_00010000 rwx --- ---
LOAD 00000000_00020220 00000000_00020220 00000000_00020220
00000000_0001c590 00000000_00020f08 00000000_00010000 rwx --- ---
Section headers
[Nr] Name Type Addr ES Flg Lk Inf Al
Off Size
[00] NULL 00000000_00000000 00 00 000 00
00000000_00000000 00000000_00000000
[01] PROGBITS 00000000_00000000 00 08 00 000 WAE
00000000_00000ae8 00000000_00010000
[02] PROGBITS 00000000_00020220 wa 00 000 08 00
00000000_00014e10 00000000_00020220
[03] PROGBITS 00000000_00035030 00-00 000 08
00000000_00002110 00000000_00035030
[04] PROGBITS 00000000_00037140 00 000 16 00 e
00000000_00000890 00000000_00037140
[05] PROGBITS 00000000_000379d0 00 000 01 00 WAE
00000000_00000188 00000000_000379d0
[06] PROGBITS 00000000_00037b60 00 000 08 00 e
00000000_00003b88 00000000_00037b60
[07] PROGBITS 00000000_0003b6e8 00 000 08 00 e
00000000_00000090 00000000_0003b6e8
[08] PROGBITS 00000000_0003b780 00 000 08 00 e
00000000_00001030 00000000_0003b780
[09] 00 ae 00000000_0003c800 NOBITS 00,000,128
00000000_00004928 00000000_0003c7b0
[10] STRTAB 00000000_00000000 00 00 000 01
00000000_00000047 00000000_0003c7b0
and that of 3.61:
SELF header
elf # 1 offset: 00000000_00000090
header len: 00000000_00000500
target offset: 00000000_000001e0
PhDr offset: 00000000_00000040
shdr offset: 00000000_000b51d8
file size: 00000000_000b4fe8
auth id: 1ff00000_01000001 (Unknown)
vendor id: FF000000
info offset: 00000000_00000070
sinfo offset: 00000000_00000140
offset version: 00000000_00000180
control info: 00000000_00000190 (00000000_00000070 bytes)
app version: 3.61.0
SDK type: Retail (Type 0)
app type: level 0
Control info
control flags:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
digest file:
The 8th 7c 62 80 b1 b9 8c 38 e3 2c the 6th August 17, 1972 09 57 25 86 e4 9e
The 8th d9 7c 7d 3b 58 02 74 15 09 65 a0 b6 04 eb b8 42 d5 86 bd
Section header
unk2 unk1 offset encrypted compressed size
00000000_00010500 00000000_00000c70 [NO] 00000000 00000000 [YES]
00000000_00020500 00000000_00094d28 [NO] 00000000 00000000 [YES]
Metadata Encrypted
Unable to decrypt metadata ------> more of the same
ELF header
type: Executable file
machine: PowerPC64
version: 1
PhDr offset: 00000000_00000040
shdr offset: 00000000_000b4d68
entry: 00000000_00000c60
flags: 00000000
header size: 00000040
Head size: 00000038
program headers: 2
section header size: 00000040
section headers: 10
section header string table index: 9
Program headers
vaddr offset type paddr
SPE PPU filesize memsize align RSX
LOAD 00000000_00010000 00000000_00000000 00000000_00000000
00000000_00000c70 00000000_00000c70 00000000_00010000 rwx --- ---
LOAD 00000000_00020000 00000000_08000000 00000000_08000000
00000000_00094d28 00000000_00099c50 00000000_00010000 rwx --- ---
Section headers
[Nr] Name Type Addr ES Flg Lk Inf Al
Off Size
[00] NULL 00000000_00000000 00 00 000 00
00000000_00000000 00000000_00000000
[01] PROGBITS 00000000_00000000 00 08 00 000 WAE
00000000_00000c70 00000000_00010000
[02] PROGBITS 00000000_08000000 wa 00 000 04 00
00000000_0001657c 00000000_00020000
[03] PROGBITS 00000000_08016580 00-00 000 16
00000000_000026c0 00000000_00036580
[04] PROGBITS 00000000_08018c40 00 000 16 00 e
00000000_00076ee8 00000000_00038c40
[05] PROGBITS 00000000_0808fb30 00 000 08 00 e
00000000_00004188 00000000_000afb30
[06] PROGBITS 00000000_08093cb8 00 000 08 00 e
00000000_00000080 00000000_000b3cb8
[07] PROGBITS 00000000_08093d40 00 000 08 00 e
00000000_00000fe8 00000000_000b3d40
[08] 00 ae 00000000_08094d80 NOBITS 00,000,128
00000000_00004ed0 00000000_000b4d28
[09] STRTAB 00000000_00000000 00 00 000 01
00000000_0000003d 00000000_000b4d28
