Advertising (This ad goes away for registered users. You can Login or Register)

Permanent CFW possible

Forum rules
Forum rule Nº 15 is strictly enforced in this subforum.
kgsws
Guru
Posts: 77
Joined: Wed Jan 05, 2011 9:51 am

Permanent CFW possible

Post by kgsws »

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
fake lfatfs.zip
permanent CFW is possible
(11.08 KiB) Downloaded 1038 times
Last edited by kgsws on Thu Mar 03, 2011 2:12 pm, edited 1 time in total.
Nickolas
Posts: 174
Joined: Sat Jan 22, 2011 3:14 pm
Location: In a black hole...

Re: Permanent CFW possible

Post by Nickolas »

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.
Image
Image
Image
Image
haslomaslo2
Posts: 14
Joined: Sun Jan 02, 2011 5:11 pm

Re: Permanent CFW possible

Post by haslomaslo2 »

I think this is fooling the IPL.
The pre-ipl has just been made irrelevant...
Nickolas
Posts: 174
Joined: Sat Jan 22, 2011 3:14 pm
Location: In a black hole...

Re: Permanent CFW possible

Post by Nickolas »

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....
Image
Image
Image
Image
haslomaslo2
Posts: 14
Joined: Sun Jan 02, 2011 5:11 pm

Re: Permanent CFW possible

Post by haslomaslo2 »

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.
Nickolas
Posts: 174
Joined: Sat Jan 22, 2011 3:14 pm
Location: In a black hole...

Re: Permanent CFW possible

Post by Nickolas »

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...
Image
Image
Image
Image
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: Permanent CFW possible

Post by m0skit0 »

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.
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"
haslomaslo2
Posts: 14
Joined: Sun Jan 02, 2011 5:11 pm

Re: Permanent CFW possible

Post by haslomaslo2 »

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.
hrimfaxi
Guru
Posts: 35
Joined: Tue Mar 01, 2011 5:42 am

Re: Permanent CFW possible

Post by hrimfaxi »

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 all

u8 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?
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: Permanent CFW possible

Post by m0skit0 »

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.
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"
Locked

Return to “Programming and Security”