• Steam recently changed the default privacy settings for all users. This may impact tracking. Ensure your profile has the correct settings by following the guide on our forums.

SilverSpring said:
Might as well post a more correct version:

It's part of their "PSPID" generation. The function makes sure that you pass the correct "PSPID" registers (which is actually the FuseID registers which are unique per each PSP) and passes the unique ID back (one half of it, they call the function twice to grab the full ID).

Code: 
// Pass FuseID Register as addr: 0xBC10009x
// FuseID only 6 Bytes but needs to be read
// via two word reads at 0xBC100090 and 0xBC100094
u32 uhura_driver_38CF8431(void *addr)
{
    // Ignore least significant nibble (0-3)
    u32 *mem = (u32)addr & 0xFFFFFFFC;

    // verify correct register address passed
    if ((u32)mem - 0xBC100090 > 4)
        return(0x12345678)
        
    // return one half of FuseID
    return(mem[0])
}

The other function, uhura_driver_AF6F18BA, is identical (though only one of them is actually used).
Click to expand...

Ahhh. That makes sense. Good work. :tup:

A question, however, NoEffex found 0x43EFFF70 somewhere in there, and you did not. Can either of you explain why that happened?
 
SilverSpring said:
+0x43EFFF70 is -0xBC100090 in 32bit 2's complement
Click to expand...

Yeah, that's what I figured. The compiler used that (I had disassembled the compiled thing to make sure). I knew it wasn't correct, but I figure it would cause someone who really knew what they were talking about do it. I was close though, I think I was missing the lw at the return.

explosions said:
Are you a machine?... or a god?.... a combination, perhaps?
Click to expand...

E.
 
So do we have the total 100% decompiled eboot then? ... Which can now be 100% fully reversed and thus allow us to sign our own eboots that will work on all known PSP's to date?

Excuse my ignorance, just asking
 
Slasher said:
So do we have the total 100% decompiled eboot then? ... Which can now be 100% fully reversed and thus allow us to sign our own eboots that will work on all known PSP's to date?

Excuse my ignorance, just asking
Click to expand...

You have to decrypt the DATA.PSP in the eboot, so I'm guessing the most we can hope for from reversing it is the ability to write our own code into memory. (This is what I understand from this thread, at least.)
 
Why do they use the UPDATE folder? Is the signature different there? What exactly must they have found out to encrypt/hash the modules? (See my above post). And why do people keep saying 'sign'? This is nothing like a signature. A signature is basically a hash encrypted with a private key, while the data need not even be encrypted. A signature is UNCRACKABLE short of brute force/leak or exploit in the client side verification process. Under no circumstances can you ever 'sign' your own anything. The PSP was inherently insecure since they just hid the keys (the same keys used by them for encrypting/hashing). It was just security through obscurity, a lot of obscurity.

---------- Post added at 09:54 AM ---------- Previous post was at 09:41 AM ----------

Sorry for double post, on my phone.

Does the PS3 use a public/private key system or is it also just hidden symmetric keys? If it's the latter then Datel could potentially hack the PS3 as well.
 
explosions said:
I do not understand this one letter reply.
Click to expand...

Traditionally on tests, E is the letter for "All of the above", so I picked "All of the above".

Slasher said:
So do we have the total 100% decompiled eboot then? ... Which can now be 100% fully reversed and thus allow us to sign our own eboots that will work on all known PSP's to date?

Excuse my ignorance, just asking
Click to expand...

Nope, because they signed it much the same way sony did, using external tools. The most we could do is use our own codes.

explosions said:
You have to decrypt the DATA.PSP in the eboot, so I'm guessing the most we can hope for from reversing it is the ability to write our own code into memory. (This is what I understand from this thread, at least.)
Click to expand...

Correctomundo.

Torch said:
Why do they use the UPDATE folder? Is the signature different there? What exactly must they have found out to encrypt/hash the modules? (See my above post). And why do people keep saying 'sign'? This is nothing like a signature. A signature is basically a hash encrypted with a private key, while the data need not even be encrypted. A signature is UNCRACKABLE short of brute force/leak or exploit in the client side verification process. Under no circumstances can you ever 'sign' your own anything. The PSP was inherently insecure since they just hid the keys (the same keys used by them for encrypting/hashing). It was just security through obscurity, a lot of obscurity.
Click to expand...

Loads it in update mode. Different PARAM.SFO and various imports, and the module type is..something else that I forgot.
 
Torch said:
Why do they use the UPDATE folder? Is the signature different there? What exactly must they have found out to encrypt/hash the modules? (See my above post). And why do people keep saying 'sign'? This is nothing like a signature. A signature is basically a hash encrypted with a private key, while the data need not even be encrypted. A signature is UNCRACKABLE short of brute force/leak or exploit in the client side verification process. Under no circumstances can you ever 'sign' your own anything. The PSP was inherently insecure since they just hid the keys (the same keys used by them for encrypting/hashing). It was just security through obscurity, a lot of obscurity.
Click to expand...

Datel signed their own program.
 
explosions said:
You have to decrypt the DATA.PSP in the eboot, so I'm guessing the most we can hope for from reversing it is the ability to write our own code into memory. (This is what I understand from this thread, at least.)
Click to expand...
Yes, either that (getting own code via "cheatcodes" into mem) or finding an exploit in AR that lets us run own code.

AR might have more voulnrabilities than current FWs, I'd say....
 
explosions said:
Yeah, it looks like it was rushed.
Click to expand...
How do you see that?
Also, I tried the obvious things on the Demo, and their stuff seems pretty solid to me. Basically, all the useful information is inside the EBOOT and therefore cannot be influenced easily from the outside. But I only have the Demo version...
Even with a completely changed settings file, the Demo seems to load fine...so...

But of course, they didn't go through sony's verification process. Plus, they won't force you to update if someone finds a leak in that software, which makes it much more interesting than any other vulnerability.
 
here's a little AR license key generator i worked on, it may become handy later on.

Code: 
int main(void)
{
	char tmpbuf[256];
	char lickey[24];
	while(1)
	{
		printf("\nEnter a 18 character string\n");
		scanf("%s",tmpbuf);
		if(strlen(tmpbuf) >= 18)
		{
			strncpy(lickey, tmpbuf, 18);
			prep_chars(lickey);
			gen_key(lickey);
			printf("\nLicense Key: %s", lickey);
		}
	}
	return 0;
}
void gen_key(char lickey[])
{
	short sum = 0, tmp, x;
	for(x = 0; x < 18; x++)
	{
		tmp = (short)(lickey[x] + sum);
		if((tmp & 1) != 0){sum = (short)((tmp / 2) | 0x1000);}
		else{sum = (short)(tmp / 2);}
	}
	sprintf(&lickey[18], "%04X", (sum ^ 0x17D2)); 
}
void prep_chars(char srcbuf[])
{
	int x;
	for(x = 0; srcbuf[x]; x++)srcbuf[x] = toupper(srcbuf[x]);
	replace_char(srcbuf, 'O', '0');
	replace_char(srcbuf, 'I', '1');
	replace_char(srcbuf, 'Z', '2');
	replace_char(srcbuf, 'S', '5');
	replace_char(srcbuf, 'G', '6');
	replace_char(srcbuf, 'T', '7');
}
void replace_char(char srcbuf[], char fndchar, char repchar)
{
	int x;
	for(x = 0; x<18;x++)
	{
		if(srcbuf[x] == fndchar)
		{
			srcbuf[x] = repchar;
		}else if(srcbuf[x] == 0)break;
	}
}
 
Torch said:
Why do they use the UPDATE folder? Is the signature different there? What exactly must they have found out to encrypt/hash the modules? (See my above post). And why do people keep saying 'sign'? This is nothing like a signature. A signature is basically a hash encrypted with a private key, while the data need not even be encrypted. A signature is UNCRACKABLE short of brute force/leak or exploit in the client side verification process. Under no circumstances can you ever 'sign' your own anything. The PSP was inherently insecure since they just hid the keys (the same keys used by them for encrypting/hashing). It was just security through obscurity, a lot of obscurity.
Click to expand...

You can't just load any kernel module you like from game mode, unlike VSH mode, where they can load them using vshKernelLoadModuleBuffer, which is what they do with updater mode. It being an updater has nothing to do with a difference in encryption, even the kernel PRX's inside are encrypted.
 
sorry about val0 , ive readed #133 and not the last version.

> suposition about the "twins" functions :
maybe datel have prepared the hack of they key/serial so the main.prx load Uhura.prx , it make his job (return the value) , and main.prx reload uhura and use the seconde function to verify the returned value. so if you patch only the first function , the main.prx will be aware about it (so it start a WLAN connection to the FBI.gov , send us your PSP's UID , pic of your gf etc...)
 
You must log in or register to reply here.
Back
Top