I'm by no means an expert on any of this, but its pretty obvious that people are talking out of their ass.
From my (limited) knowledge:
1) For all practical purposes, forget about cracking the code encryption (Sony's 'signature' -- its not really a signature the way its implemented).
Because:
a) We don't even know the algorithms.
b) Even if the algorithms are found, I doubt that they would have invented their own algorithm. It would probably just be an implementation of some public algorithm which cannot be exploited to falsely encrypt data, or to reveal the private key.
2) Even if you somehow externally reflash the NAND in the MCU, current CFW won't work because they use a custom IPL.
To have a CFW we would need an exploitable IPL/kernel that works on the new hardware. It would probably need to bootstrap using that just like the Phat bootstrapped with the exploitable 1.50 IPL to perform the patches on the 3.xx firmware.
If the above is found, good for us. Even then Sony *could* just revise the hardware to be incompatible with the exploited IPL/kernel and new PSPs would ship with the latest compatible IPL/kernel. Just like the Slim is incompatible with the old 1.50 bootstrapped CFWs. Although it needn't be such a drastic hardware change as the Slim. They already attempted something like that with the TA-082 requiring the patched Key 5 or the IPL would crash, but they fucked up there so we got around it.
3) HEN is very much possible though. But whether it leads to a Power-On-Instant-CFW depends on the requirements in point No. 2.
Cracking the PSP OFW without pandora
Sigh!!! I might as well lock this thread, it is like 2005 all over again, with the pointless speculation.
Lets get some points clear...
* Encryption/Sign Check is done in hardware, you would have a job changing the keys.
* The signing check relies more on a HMAC algorithm it seems then real signing in the generally perceived sense.
* The "swaploit" only worked on 1.5 because the firmware already loaded plain executables, just some parts ensured this was the case, others couldn't be arsed, it never worked by replacing an encrypted elf with a plain one
* Timing attacks on the loader are difficult, the ELF does get loaded into memory and decrypted in place from what I remember (sure I could be wrong :P)
* The Pandora IPL was "signed" in our sense of the word, it just relied on horrendous logic bugs in the hardware in order to work, this is probably what they have now fixed.
See my CCC presentation if you want to see it in a bit of depth.
But certainly good points Torch, about the best we could hope for at this point would be HEN :) Hmm wonder if there are still any kernel exploits though :P
Lets get some points clear...
* Encryption/Sign Check is done in hardware, you would have a job changing the keys.
* The signing check relies more on a HMAC algorithm it seems then real signing in the generally perceived sense.
* The "swaploit" only worked on 1.5 because the firmware already loaded plain executables, just some parts ensured this was the case, others couldn't be arsed, it never worked by replacing an encrypted elf with a plain one
* Timing attacks on the loader are difficult, the ELF does get loaded into memory and decrypted in place from what I remember (sure I could be wrong :P)
* The Pandora IPL was "signed" in our sense of the word, it just relied on horrendous logic bugs in the hardware in order to work, this is probably what they have now fixed.
See my CCC presentation if you want to see it in a bit of depth.
But certainly good points Torch, about the best we could hope for at this point would be HEN :) Hmm wonder if there are still any kernel exploits though :P
I thought the kernel exploit that Illuminati used was undisclosed? The user mode exploit through Lumines was patched as usual because it would have been relatively easy for Sony to locate once the exploit PoC demo was released.TyRaNiD wrote:But certainly good points Torch, about the best we could hope for at this point would be HEN :) Hmm wonder if there are still any kernel exploits though :P
But judging from the Team C+D 2.81 - 3.03 kernel exploit which is caused by calling that registry function repeatedly with increasing values, it would seem near impossible to identify the cause by reverse engineering the exploit code.
Has that also been fixed or is it still working and we just need a user mode exploit now?
The registry exploit has been fixed (it got fixed in the next revision of the firmware), Sony also added code to make it more difficult to do the attack on the memory protection registers as well while they were at it.
I can't remember what kernel exploits are known and fixed or not known, also possible that the one I do know about is also fixed as well :)
I can't remember what kernel exploits are known and fixed or not known, also possible that the one I do know about is also fixed as well :)
I've read through all the PSP programming docs and have experience on other platforms as well but I am FAAAAAAR away from ever doing anything of any significance for the PSP hacking scene.jube wrote:if this thread is still active...
"See my CCC presentation if you want to see it in a bit of depth. "
I would like to see this presentation, have nearly finished ( and understood ) the module pdf so would like to advance, where do i find it, is there a transcript?
Don't take this the wrong way, but don't get your hopes up.
me hacking the OFW? you joking!! ( man you got to be !! )
Im so far behind you guys its ridiculous!
No am just trying to learn, preferably from sources who know the subject and that i can trust.
Also originally was looking for a hardware solution, which is more up my ally!! , i was under assumtion that one only really needed to run 1 unsigned piece of code and that all the CFW could be put in place from that module ( calling other modules to flash etc etc etc ) ie needed only 1 point of entry, this assumtion seems to be inaccurate for a start. Also any hardware door seems to be a lot harder to exploit then i thought, ( if they have gone to trouble of disabling jtag and the silicon area that represents, they must be pretty hot on this subject ) generally a bit of a dead end?
Im so far behind you guys its ridiculous!
No am just trying to learn, preferably from sources who know the subject and that i can trust.
Also originally was looking for a hardware solution, which is more up my ally!! , i was under assumtion that one only really needed to run 1 unsigned piece of code and that all the CFW could be put in place from that module ( calling other modules to flash etc etc etc ) ie needed only 1 point of entry, this assumtion seems to be inaccurate for a start. Also any hardware door seems to be a lot harder to exploit then i thought, ( if they have gone to trouble of disabling jtag and the silicon area that represents, they must be pretty hot on this subject ) generally a bit of a dead end?
Technically we require only 1 piece of unsigned code to be run SOMEHOW for user mode homebrew. Just that you would need to keep performing the exploit every time you wanted to run homebrew, like the GTA eLoader process.
A regular CFW like what we have needs exploits in the IPL or kernel while cold booting.
A regular CFW like what we have needs exploits in the IPL or kernel while cold booting.
ok think i got you, so at best a hardware solution would end up with a mod-chip type device, maybe if very lucky something that plugs into the MS port.
TyRaNiD.......
I know this is a far out idea but would cash help? If by some miracle PSPZ does well i could ( and would want to ) set up a paypal fund to help on the effort long term, maybe to buy units for people like you to play with/blow up?
But have zero idea if that would help,hinder or just be a wast of time and cash.
TyRaNiD.......
I know this is a far out idea but would cash help? If by some miracle PSPZ does well i could ( and would want to ) set up a paypal fund to help on the effort long term, maybe to buy units for people like you to play with/blow up?
But have zero idea if that would help,hinder or just be a wast of time and cash.
http://google.com/search?q=tyranid+cccjube wrote:if this thread is still active...
"See my CCC presentation if you want to see it in a bit of depth. "
I would like to see this presentation, have nearly finished ( and understood ) the module pdf so would like to advance, where do i find it, is there a transcript?
very interesting overview ( the presentation), should have watched it before launching this thread.
Can anyone inform me what has changed with the new motherboards?
Obviously sevice mode is still there with the same access through the battery, and it looks like it will always be there.( ie ipl can still be loaded throgh memory stick)
Hence the change is either in the pre-ipl or KIRK?, and that means there is a cpu die revision?
Or is it something else which is stopping the custom IPL? Some hardware change to do with system architecture?
Can anyone inform me what has changed with the new motherboards?
Obviously sevice mode is still there with the same access through the battery, and it looks like it will always be there.( ie ipl can still be loaded throgh memory stick)
Hence the change is either in the pre-ipl or KIRK?, and that means there is a cpu die revision?
Or is it something else which is stopping the custom IPL? Some hardware change to do with system architecture?
On TA-088v2 the hardware was slightly revised to be incompatible with the mixed 1.50+3.40 kernel that previous DCs were using. That was solved by making DC6 use the 4.01 M33 patched kernel+IPL.
On TA-088v3 the pre-IPL in the CPU (the mask ROM) has been rectified so that the exploit used to run custom IPLs doesn't work anymore.
We would either need to exploit the pre-IPL again, or find firmware exploits.
On TA-088v3 the pre-IPL in the CPU (the mask ROM) has been rectified so that the exploit used to run custom IPLs doesn't work anymore.
We would either need to exploit the pre-IPL again, or find firmware exploits.
has the new pre-ipl been examined ie do the same exploits that get us to the 4k ( if it is still 4K )pre-ipl dump still work?
Why do the custom ipl not now work? Is it cos the cracking of the signing is no longer effective? Or has the encrypt-lengh exploit been removed?
I have stopped looking for another sevice mode, am convinced the one initiated by the battery is the only one.
I have a slim stripped down now, am verifying what in the system still has working jtag, although the cpu prob has jtag fuse blown, as discussed, maybe other system components ; using off-the shelf chips; still have jtag access, and maybe will find something usefull there, one does not know till one tries!
Torch..... Thanks for the info mate :)
Why do the custom ipl not now work? Is it cos the cracking of the signing is no longer effective? Or has the encrypt-lengh exploit been removed?
I have stopped looking for another sevice mode, am convinced the one initiated by the battery is the only one.
I have a slim stripped down now, am verifying what in the system still has working jtag, although the cpu prob has jtag fuse blown, as discussed, maybe other system components ; using off-the shelf chips; still have jtag access, and maybe will find something usefull there, one does not know till one tries!
Torch..... Thanks for the info mate :)
Curiously, since 4.01 (or maybe 4.00), they renamed the slim ipl to "psp02h" instead of psp2000, and they decreased the block size which had been always been 0xF60, to 0xF40. This could be related to a preipl change, maybe they check the size to be 0xF40 always (just guessing) in the new preipl, if they did so, this would also avoid downgrade to pre 4.00.
not sure i would use cunning, but bastards yes!
and now got my test bench sorted, i find out psp3000 out in november, if thats going to replace slim prob best to work on one of them. Well did say this was going to be a long term thing! Im pretty sure by november i will be up to speed on mipps assembler and have a good handle on the subject in general.
Its all looking pretty black though, right back to a new custom ipl. At least its not back to stage 1, Thanks to T and the team we all have a standardised plan of attack, see no reason not to repeat the stages of pandora effectivly try again, at least that will show if pre-ipl or KIRK or both have changed, and maybe how.
Does anyone think sony reads this stuff? If we do make progress should we be posting it? They seem to make hardware revisions afully quickly.
and now got my test bench sorted, i find out psp3000 out in november, if thats going to replace slim prob best to work on one of them. Well did say this was going to be a long term thing! Im pretty sure by november i will be up to speed on mipps assembler and have a good handle on the subject in general.
Its all looking pretty black though, right back to a new custom ipl. At least its not back to stage 1, Thanks to T and the team we all have a standardised plan of attack, see no reason not to repeat the stages of pandora effectivly try again, at least that will show if pre-ipl or KIRK or both have changed, and maybe how.
Does anyone think sony reads this stuff? If we do make progress should we be posting it? They seem to make hardware revisions afully quickly.
omg, i actually watched that, uhh it took a long time too, lol T get some contacts :P, no offense intendedjimparis wrote:http://google.com/search?q=tyranid+cccjube wrote:if this thread is still active...
"See my CCC presentation if you want to see it in a bit of depth. "
I would like to see this presentation, have nearly finished ( and understood ) the module pdf so would like to advance, where do i find it, is there a transcript?
anyway, im back in the scene, so i can help out in anyway possible. Usually when sony does something to make the psp unhackable, i think there will be a few loopholes here and there as toughening up the software only makes it worse in the end arent i correct?
the questions of today are awnswered by the blood and bullets of tomorrow! ---EagleEye--- (Socom FTB2)
i really do hope so! I for one would really like to be writing hombrew all the way to the psp lifecycle end, and unless we are pro-active on the subject, at least thinking abut it, that wont happen!
I think we are safe to post at this speculation stage? I feel that public posting is always the best way unless you are really forced not to, you never know who might read and be able to help.
Otherwise we could do it by email? its real safe but slooooow
I think we are safe to post at this speculation stage? I feel that public posting is always the best way unless you are really forced not to, you never know who might read and be able to help.
Otherwise we could do it by email? its real safe but slooooow
yea, with my current schedule i cant even finish my homebrew game "deathcorev1.0". Its supposed to be a Devil May Cry 4 remake, but so far i have had no progress and im so pissed off about it. I can try the best i can to help out the scene so please let me know if you need some help on something.
the questions of today are awnswered by the blood and bullets of tomorrow! ---EagleEye--- (Socom FTB2)
-
Dariusc123456
- Posts: 388
- Joined: Tue Aug 12, 2008 12:46 am
Because its not that easy?Dariusc123456 wrote:Why cant someone make a homebrew program that will capture the process and find any holes while its running/debugging sony programs
There are still a lot of functions undefined in the SDK as the devs don't know or can't be bothered ;) finding what they do. That is by miles much more important than allowing rampant noobs coming to the scene and asking "WHERE IS MY PS2 EMULATOR" then they release some LUA shell clone.
Wally
T......
Thats kind of what i thought, but was not going to argue since just got on that board. Maybe they found the jtag entrance, ( although nobody replied when asked the question directly ) or found a mipps de-bug unit that could do it, Im just speculating though.
Kind of have to revise my earlier statement about the level of hardware talent over there, medium talent but LOADS of accumulated knowlege, which i suppose equates to the same thing? But anyway, the upshot is that i think the effort here is not wasted and i dont think work would be replicated.
Thats kind of what i thought, but was not going to argue since just got on that board. Maybe they found the jtag entrance, ( although nobody replied when asked the question directly ) or found a mipps de-bug unit that could do it, Im just speculating though.
Kind of have to revise my earlier statement about the level of hardware talent over there, medium talent but LOADS of accumulated knowlege, which i suppose equates to the same thing? But anyway, the upshot is that i think the effort here is not wasted and i dont think work would be replicated.
-
Dariusc123456
- Posts: 388
- Joined: Tue Aug 12, 2008 12:46 am
Listen, im not here to argue about the past. If we want the to get cfw for the newest psp, we have to work together.Wally4000 wrote:Because its not that easy?Dariusc123456 wrote:Why cant someone make a homebrew program that will capture the process and find any holes while its running/debugging sony programs
There are still a lot of functions undefined in the SDK as the devs don't know or can't be bothered ;) finding what they do. That is by miles much more important than allowing rampant noobs coming to the scene and asking "WHERE IS MY PS2 EMULATOR" then they release some LUA shell clone.
Wally
-
Dariusc123456
- Posts: 388
- Joined: Tue Aug 12, 2008 12:46 am
Listen, im not here to argue about the past. If we want the to get cfw for the newest psp, we have to work together.Wally4000 wrote:Because its not that easy?Dariusc123456 wrote:Why cant someone make a homebrew program that will capture the process and find any holes while its running/debugging sony programs
There are still a lot of functions undefined in the SDK as the devs don't know or can't be bothered ;) finding what they do. That is by miles much more important than allowing rampant noobs coming to the scene and asking "WHERE IS MY PS2 EMULATOR" then they release some LUA shell clone.
Wally