Forum rules: Forum rule Nº 15 is strictly enforced in this subforum.
#41989 by kgsws
Thu Mar 03, 2011 1:45 pm
Well i made one experiment, and i was successfull :)

Try this only on old FAT PSP's, if you brick new PSP, it is your fault.
This example contains simple LCD driver tested on TA-079,
because each motherboard contains different parts, it might
not work on different models.

If you want to test it:
- instal OFW 6.20
- use HEN to run PSP filer
- obtain original lfatfs.prx
- decrypt original lfatfs.prx, also get kirk header for later fake encryption
- compile fake lfatfs.prx (this)
- append zeros to fake lfatfs.prx to make it as big as original, uncompressed lfatfs.prx
- gzip fake lfatfs.prx, it has to be at least 16 bytes smaller than original lfatfs.prx gzipped
- use any fake encrypter to encrypt your fake lfatfs.prx, keep original lfatfs.prx ~PSP hader and kirk header
- copy fake lfatfs.prx to flash0:/kd/, overwrite original
- restart your PSP and watch

Notes:
- you must append zeros to make it as big as original
- you must gzip it
- you must use original lfatfs.prx ~PSP and kirk headers
- every PRX in flash contains signcheck = your PRX is bound to your PSP
- this won't allow you to enter OFW anymore, you will have to use pandora to flash it again
- this trick will likely work on new PSPs, but this small LCD driver not, and your PSP will become useless anyway (so wait for CFW)

My idea for CFW:
Use fake lfatfs.prx as CFW "SystemControl" module, and instead only patching also load original lfatfs.prx (which will be renamed).

Special thanks:
Boosters IPL SDK
Advertising
Attachments
permanent CFW is possible
(11.08 KiB) Downloaded 734 times
Last edited by kgsws on Thu Mar 03, 2011 2:12 pm, edited 1 time in total.
#42071 by Nickolas
Thu Mar 03, 2011 5:36 pm
Wait a sec... Does this mean that we can feed anything to the psp as long as it has the same size with the original file? WOW!!!
Hey i just thought of something...
in the earlier motherboards the remaining 0x20 bytes were ignored but they had a meaning in the newer ones... What if those bytes contained the size of the block checked by the pre-ipl ?

EDIT: Sorry if I got you confused... I mean the 0x20 bytes mentioned here : viewtopic.php?f=6&t=811
Advertising
Last edited by Nickolas on Thu Mar 03, 2011 5:38 pm, edited 1 time in total.
#42075 by Nickolas
Thu Mar 03, 2011 5:41 pm
haslomaslo2 wrote:I think this is fooling the IPL.
The pre-ipl has just been made irrelevant...


I know but I thought that those *random* 0x20 bytes could represent the size of the block.... That's why (maybe) a 4.01 block is a tiny bit different from the 4.05 one...They just made changes and increased the size a bit....
#42087 by haslomaslo2
Thu Mar 03, 2011 6:07 pm
In my understanding you are describing the checks done by the pre-ipl to validate ipl.
The old attacks focussed on hacking the pre-ipl to accept a custom ipl. The custom ipl would load anything we wanted it to.

This attack does not even try to mess around with pre-ipl. It starts acting once the original and validated ipl already takes over. It is a very different layer of security.

This means that the extra security does not matter. We can boot custom firmware with original ipl. The original ipl thinks that our code is official... So no need to bother with pre-ipl ever again.

Then again, I may be wrong.
#42089 by Nickolas
Thu Mar 03, 2011 6:16 pm
haslomaslo2 wrote:In my understanding you are describing the checks done by the pre-ipl to validate ipl.
The old attacks focussed on hacking the pre-ipl to accept a custom ipl. The custom ipl would load anything we wanted it to.

This attack does not even try to mess around with pre-ipl. It starts acting once the original and validated ipl already takes over. It is a very different layer of security.

This means that the extra security does not matter. We can boot custom firmware with original ipl. The original ipl thinks that our code is official... So no need to bother with pre-ipl ever again.

Then again, I may be wrong.


No you got me wrong... I didn't refer to this post at all.. It is just what made me think of all these stuff initially.. I am just saying that the 0x20 bytes could actually hold the size of the block getting decrypted by kirk when the pre ipl checking is beeing performed...
#44557 by m0skit0
Mon Mar 07, 2011 2:04 pm
First, abstain of useless posts like these:

AssasinRam wrote:Let's see what this develops into! :)

or

DaNS wrote:So maybe u can upload your compiled versiob or send me a pm? :)

Posts deleted btw.

Quite interesting finding kgsws. But if it implies overwriting a file, how would you get the original file when needed? Are there any modules loaded on boot that are not really required?

Nickolas wrote:in the earlier motherboards the remaining 0x20 bytes were ignored but they had a meaning in the newer ones... What if those bytes contained the size of the block checked by the pre-ipl ?

Err if it was that simple, it would have been hacked already, don't you think?

Anyway, he's not talking about fooling the Pre-IPL, what he's talking about happens on firmware booting (after IPL has been already loaded). Keep on-topic.
#44583 by haslomaslo2
Mon Mar 07, 2011 2:58 pm
Another thought is unbricking PSPs that have the unhackable motherboard but enter service mode via pandora. In this case the problem of finding a useless module is much less relevant.
#44610 by hrimfaxi
Mon Mar 07, 2011 4:07 pm
I just confirmed on 635 this method doesn't work. Maybe it's because of ECDSA signature (0x380280F0) :(

Here is my kirk1 header on vshmain:

Code: Select allu8 vshmain_kirk_header[272] = {
   0xA8, 0x68, 0x67, 0xB1, 0x50, 0x8F, 0x1F, 0xA2, 0x24, 0xA1, 0x59, 0xFE, 0xB7, 0xD7, 0x4D, 0xCE,
   0x66, 0x4F, 0xE1, 0xF2, 0xE9, 0xD6, 0x63, 0x36, 0xF7, 0x33, 0x0B, 0xCA, 0xB9, 0x55, 0x6D, 0xB6,
   0xEB, 0xE8, 0x05, 0xDC, 0xA0, 0x9F, 0x78, 0x93, 0x3E, 0x0B, 0xFA, 0xF4, 0xAD, 0xAF, 0x17, 0xAA,
   0x81, 0x05, 0x7E, 0x63, 0x49, 0xD4, 0xD0, 0xBE, 0xCD, 0xE3, 0x88, 0xA6, 0x3C, 0x1D, 0x57, 0xDC,
   0x5E, 0x94, 0xEE, 0xAC, 0x2E, 0x6C, 0x9F, 0x2E, 0x81, 0xC7, 0x1C, 0x58, 0xD3, 0x7C, 0xBE, 0x1F,
   0xB3, 0x76, 0xC0, 0x95, 0x62, 0xDF, 0xBB, 0x4E, 0x4A, 0xBB, 0x7B, 0xB5, 0x07, 0x21, 0xCE, 0x76,
   0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x1A, 0x3B, 0x02, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x7E, 0x50, 0x53, 0x50, 0x00, 0x08, 0x01, 0x00, 0x01, 0x01, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0x06, 0x0C, 0x06, 0x00, 0x70, 0x3C, 0x02, 0x00,
   0x70, 0xF5, 0x00, 0x00, 0x1C, 0x00, 0x04, 0x00, 0x7C, 0x61, 0x00, 0x00, 0x10, 0x00, 0x10, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x53, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x28, 0x53, 0x05, 0x00, 0xB0, 0x76, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x05, 0x03, 0x06, 0x03, 0x00, 0x00, 0x00
};


Notice 0x40~0x50 have extra hash bytes. Are they the ECDSA signature?
#44643 by m0skit0
Mon Mar 07, 2011 6:12 pm
haslomaslo2 wrote:Another thought is unbricking PSPs that have the unhackable motherboard but enter service mode via pandora. In this case the problem of finding a useless module is much less relevant.

No. Stop talking nonsense and confusing people.

Who is online

Users browsing this forum: No registered users and 1 guest