2.70 IPL

ryoko_no_usagi · Post by **ryoko_no_usagi** » Sun Jun 11, 2006 8:29 pm

I have had a look at the IPL for 2.70 and here's what I have found. TyRaNiD already revealed[1] that for 2.60+ IPL Sony added a new protection that is based on data that is gone by the time the PSP has booted. Here are some more details on that, but first a little recap (courtesy Nem[2]):

1) On-chip bootcode copies and decrypts IPL onto 0x040f0000.
2) IPL initializes and decompresses an embedded gzip file (called main_led.bin in 1.00, main.bin in 1.5) stored at offset 0xcc0.
3) Unzipped file does many initializations and decrypts 2nd stage IPL
4) 2nd stage IPL boots firmware.

For 2.60+ the gzip file is encrypted and it is stored at offset 0x1ac0. The encryption seems to work like this:

The Hardware Exception Vectors at 0xbfc00040 - 0xbfc002c0 are run together with 64 bytes stored at offset 0x1980 through SHA-256 (exact details are not yet known to me) to produce a 256-bit hash value.

The 256-bit hash value is repeatedly copied to fill up a 624-byte buffer and then the hash value is erased. The 624-byte buffer is used as the 19,937 bits long initial seed for a Mersenne Twister PRNG.

To decrypt the gzip file, for each 32 bytes of ciphertext, 16 pseudo-random 32-bit integers are fetched from the PNRG and stored in a temporary buffer. Then the same procedure with SHA-256 is run on this buffer but instead of values from the 0xbfc00000 range, the source data is taken from offset 0x19c0. The 32 bytes produced this way are finally XOR'd with the ciphertext to produce the plaintext gzip file and then the procedure is repeat for the next 32 bytes to be decrypted.

Here are some final speculative thoughts.

The contents of the Hardware Reset Vectors are apparently changed between the time they are used for decryption and the time the PSP has booted so we can't get them that way. It also doesn't seem possible to me to get them through external hardware either, because I don't think any data ever leaves the chip so not possible to snoop.

Invasive probing is perhaps possible but require skills beyond what I possess.

That leaves crypto-analysis. Now, I'm not at all skilled in cryptography so this is outside my jurisdiction, but maybe this is actually feasible? The encryption is a one-time pad but the encrypted file is longer than the pad and even if the avalanche effect of SHA-256 injects entropy, it still seems to me as a layman that it should be possible to break it. I obviously don't have the necessary crypto analysis skills though.

EDIT: Um, obviously the strength depends on the PRNG, in addition to SHA. If it generates perfect random numbers then the cipher is unbreakable...and conversely...

moonlight · Post by **moonlight** » Sun Jun 11, 2006 9:47 pm

ryoko_no_usagi wrote: The contents of the Hardware Reset Vectors are apparently changed between the time they are used for decryption and the time the PSP has booted so we can't get them that way. It also doesn't seem possible to me to get them through external hardware either, because I don't think any data ever leaves the chip so not possible to snoop.

But anyways, the RAM could be hardware-dumped after the firmware has been inited, right? In this way, the keys to decrypt prx's could be obtained from the kernel memory.

Of course, this doesn't solve the problem of decrypting the third stage of ipl.
But anyways, the loadexec.prx should have inside a reboot code very similar.

ryoko_no_usagi · Post by **ryoko_no_usagi** » Mon Jun 12, 2006 3:54 pm

Yes, as far as I know, dumping RAM after boot should be able to reveal prx keys. And it doesn't even need to be hardware based :)

LuMo · Post by **LuMo** » Mon Jun 12, 2006 7:46 pm

dumping ram is that hard?
guess not, so what are you waiting for ;)

ryoko_no_usagi · Post by **ryoko_no_usagi** » Mon Jun 12, 2006 7:52 pm

Intercepting a 333MHz DDR with strict latency/timing requirements is at least a little bit hard for this poor Usagi :)

Software wise, well, can we run code with kernel priviliges on 2.60+ yet?

moonlight · Post by **moonlight** » Mon Jun 12, 2006 7:55 pm

ryoko_no_usagi wrote: Software wise, well, can we run code with kernel priviliges on 2.60+ yet?

No, unfortunally.

LuMo · Post by **LuMo** » Mon Jun 12, 2006 8:18 pm

true, still thinkting with my 1.5 brain ;)

digihoe · Post by **digihoe** » Mon Jun 12, 2006 8:22 pm

I have asked 0okm0000 (hardware guru, it seems) some time ago if dumping the ram would be possible using his hardware, but he didn't seem too intressted...
Hopefully the keys will come out eventually...

0okm0000 · Post by **0okm0000** » Mon Jun 12, 2006 8:33 pm

digihoe wrote:I have asked 0okm0000 (hardware guru, it seems) some time ago if dumping the ram would be possible using his hardware, but he didn't seem too intressted...
Hopefully the keys will come out eventually...

DDR SDRAM & NAND Flash are the completely different thing !!

digihoe · Post by **digihoe** » Mon Jun 12, 2006 8:39 pm

0okm0000 wrote:
digihoe wrote:I have asked 0okm0000 (hardware guru, it seems) some time ago if dumping the ram would be possible using his hardware, but he didn't seem too intressted...
Hopefully the keys will come out eventually...
DDR SDRAM & NAND Flash are the completely different thing !!

I'll take that as a no... Good luck with the dual NAND flash...

dot_blank · Post by **dot_blank** » Tue Jun 13, 2006 10:39 am

hehe yea thats a no ;)
ryoko once again great research
you are the man thanx again buddy

Guest · Post by **Guest** » Thu Jun 15, 2006 6:01 am

here's what someone wrote about a year ago... (google search):

Encryption - 128bit AES
AES info: http://home.ecn.ab.ca/~jsavard/crypto/co040401.htm

RSA Security Solutions Adopted for PSP™:
Quote:
"RSA Security Inc. (NASDAQ: RSAS) announced today that it has licensed RSA BSAFE® Secure Sockets Layer (SSL) and public key infrastructure (PKI) products to Sony Computer Entertainment Inc. (SCEI), to provide a secure interactive environment for software title developers and publishers creating game titles for its new PSPTM (PlayStation® Portable) handheld entertainment system. "

http://www.rsasecurity.com/press_releas ... oc_id=5648

basic structure:
http://www.rsasecurity.com/products/bsa ... S_0503.pdf

More detailed BSAFE Cert-C Micro Edition:
https://eval.rsasecurity.com.au/downloa ... index.html

Internet-Drafts (public documents made availabe from RSA itself, now expired as specifications, but not tottaly useless to us)
BSAFE (1999):
http://quimby.gnus.org/internet-drafts/ ... afe-00.txt
TestCases:
http://quimby.gnus.org/internet-drafts/ ... est-00.txt

AES info: http://web.archive.org/web/200503240948 ... 040401.htm

from: http://www.iaik.tu-graz.ac.at/research/krypto/AES/

AES Security
The following table lists the best known short-cut attacks on each of the three AES variants.

Attack Year Paper AES-128 (10 Rounds)
AES-192 (12 Rounds)
AES-256 (14 Rounds)

Related Key 2005 Biham et al., Related-Key Boomerang and Rectangle Attacks, Advances in Cryptology – EUROCRYPT 2005, LNCS 3494, pages 507-525 , Springer, 2005 9 Rounds

Truncated Differential 2003 Jakimoski et al., Related-Key Differential Cryptanalysis of 192-bit Key AES Variants, SAC 2003, LNCS Vol. 3006, pages 208-221, Springer, 2004 6 Rounds

Impossible - Differential Related-Key 2003 Jakimoski et al., Related-Key Differential Cryptanalysis of 192-bit Key AES Variants, SAC 2003, LNCS Vol. 3006, pages 208-221, Springer, 2004 8 Rounds

Impossible Differential 2001 Cheon et al., Improved Impossible Differential Cryptanalysis of Rijndael and Crypton, ICISC 2001, LNCS Vol. 2288, pages 39-49, Springer 6 Rounds

Square Attack 2000 Lucks, Attacking seven rounds of Rijndael under 192-bit and 256-bit keys. Proceedings of AES3, NIST 7 Rounds 7 Rounds

Square Attack 2000 Ferguson et al. Improved cryptanalysis of Rijndael, FSE 2000, LNCS Vol. 1978, pages 213-230, Springer 7 Rounds 7 Rounds 9 Rounds

Collision Attack 2000 Gilbert et al., A collision attack on seven rounds of Rijndael, Proceedings of AES 3, NIST 7 Rounds 7 Rounds 7 Rounds

groepaz · Post by **groepaz** » Thu Jun 15, 2006 6:09 am

how is this even relevant...neither does anyone know for sure if its *really* AES, nor would knowing it help in any way :=P

laichung · Post by **laichung** » Thu Jun 15, 2006 12:50 pm

Becasue there are still many people on earth are misleading by the specification of PSP from sony about the AES. (also the USB Host by Talkman mic)

They dont realize that the fact is, PSP has a power to do AES doesnt mean It must use it for every encrypt/decrypt process.

groepaz wrote:how is this even relevant...neither does anyone know for sure if its *really* AES, nor would knowing it help in any way :=P

Guest · Post by **Guest** » Thu Jun 15, 2006 2:45 pm

from what I understand PSP has hardware 128-AES Crypto

and if I had to install F/W in a possibly compromised system vulnerable to monitoring I would like to use the hardware Crypto system and the keys passed to the hardware will have to change at least twice

anyway, just few random thoughts

too bad we don't have hardware emulation so we can run things on it ;)

ryoko_no_usagi · Post by **ryoko_no_usagi** » Thu Jun 15, 2006 3:08 pm

Guest wrote:from what I understand PSP has hardware 128-AES Crypto
and if I had to install F/W in a possibly compromised system vulnerable to monitoring I would like to use the hardware Crypto system and the keys passed to the hardware will have to change at least twice

They are not using the cipher-hw for decrypting this part. I have reversed the routines to C code mostly, only details in the SHA-256 and MT PRNG are missing but I can assure you that they don't call on any hw.

Mind you, we don't know what happens inside the compressed file. There they most certainly use the hardware to decode the bootloader and maybe they are doing something exotic there as well.

laichung · Post by **laichung** » Fri Jun 16, 2006 11:28 am

Even PSP using hardware to decode the files , it can be somethings other than AES too (or more complicate steps before AES, example , exract the Keys from files). Again , we have no evidence to prove PSP are using AES in somewhere (encrypt/decrypt) until now. Or anyone try to prove it now?

ryoko_no_usagi wrote:
Guest wrote:from what I understand PSP has hardware 128-AES Crypto
and if I had to install F/W in a possibly compromised system vulnerable to monitoring I would like to use the hardware Crypto system and the keys passed to the hardware will have to change at least twice
They are not using the cipher-hw for decrypting this part. I have reversed the routines to C code mostly, only details in the SHA-256 and MT PRNG are missing but I can assure you that they don't call on any hw.

Mind you, we don't know what happens inside the compressed file. There they most certainly use the hardware to decode the bootloader and maybe they are doing something exotic there as well.

jimparis · Post by **jimparis** » Sat Jun 17, 2006 3:29 pm

ryoko_no_usagi wrote:Intercepting a 333MHz DDR with strict latency/timing requirements is at least a little bit hard for this poor Usagi :)

I think the RAM is only running at 111MHz by default (that's what I see on CK+/CK- at least). If you call scePowerSetClockFrequency(19,1,1) it goes down to 37MHz. I haven't managed to get it any slower.

EDIT: oh yeah, I guess it's DDR so that's still 222MHz, and 74MHz at the slowest.

moonlight · Post by **moonlight** » Mon Aug 21, 2006 4:55 pm

I've been able to dump the area [0xbfc000000-0xbfc001000) at "exceptionman.prx boot time".

Because of what i've seen, neither the modules that load before exceptionman (sysmem and loadcore) nor the 1.50 ipl modifies that area.

So, the dump obtained should be able to be used to decrypt main.bin from 2.60+ ipl's... however it doesn't.

Researching a bit more, when i did a double-dump like this:

Code: Select all

	u8 *boot = &#40;u8 *&#41;0xbfc00000;
	u8 *address1 = &#40;u8 *&#41;0x883e0000;
	u8 *address2 = &#40;u8 *&#41;0x883e1000;

	int i;

	for &#40;i = 0; i < 0x1000; i++&#41;
	&#123;
		address1&#91;i&#93; = boot&#91;i&#93;;
		address2&#91;i&#93; = boot&#91;i&#93;;
	&#125;

The two resulting files of this dump were different between them and different from the first obtained by a single dump!

The differences are only in the certain same bytes. If no module modifies them, i don't know why those values result different... anyone has a clue about it?

The dumper program:

http://moonlight.lan.st/bin/exceptionmanboot.rar

Why it works? 1.50 has another more flaw that lets modules from exceptionman and on (until init.prx or untill all?) to be run decrypted if they DO NOT have either kernel mode attributes (despite that it is executed in kernel mode) or imports.

Instructions: This is ONLY for people that can reprogram their nands, and that have both of them. (since one of them gets "bricked");

- There are 3 exceptionman. All of them dump the area [0xbfc000000-0xbfc001000) to unused kernel ram (that usually, not always, survives hard reset).
exceptionman1 -> it dumps once time to the address 0x883e0000
exceptioman2 -> it dumps twice to the addresses 0x883e0000 and 0x883e1000 at the same time (single loop)
exceptionman3 -> it dumps twice to the addresses 0x883e0000 and 0x883e1000 one after the other (two loops).

- Have both of the nands with 1.50
- Flash one of the two nands (the reprogrammable one) with one of the exceptioman.prx (i don't include any flasher, code it your own).
- Hardware reset with that nand. The firmware WON'T run, but the custom exceptionman will have done its job of dumping the boot memory to ram.
- Hard reset in the other nand and run the "Bootdumper". It will dump from kernel ram the previously dumped data to ms0:/boot.bin and ms0:/boot2.bin.

Compilation: the first make fails because of a bug in the pspsdk with programs that do not import anything. Just type make again and the prx will be generated and it will work.

groepaz · Post by **groepaz** » Mon Aug 21, 2006 6:54 pm

The two resulting files of this dump were different between them and different from the first obtained by a single dump!

have you analyzed the dumped data? maybe there is some selfmodifying code (unlikely, though possible), or certain data (as in variables) stored there. or maybe you are dumping while exceptionman.prx is initializing the exception handler (ie, copying stuff to 0xbfc0...)?

moonlight · Post by **moonlight** » Mon Aug 21, 2006 7:09 pm

groepaz wrote:
The two resulting files of this dump were different between them and different from the first obtained by a single dump!
have you analyzed the dumped data? maybe there is some selfmodifying code (unlikely, though possible), or certain data (as in variables) stored there. or maybe you are dumping while exceptionman.prx is initializing the exception handler (ie, copying stuff to 0xbfc0...)?

the real exceptionman.prx is not there because it has been replaced by the custom one (that's why it "bricks"), so the last posibility cannot be.

I'll try to mod the thing so it can work in a single nand (without bricking :P), and it can be tested by more people, but i won't be able to do it until this night.

i don't know if interruptman could be being executed at the same time and writing stuff there, but i thought that until module_start didn't return, the next prx is not loaded. (i guess i'll have to test also destroying all prx's from exceptionman and on :p)

groepaz · Post by **groepaz** » Mon Aug 21, 2006 7:52 pm

interruptman doesnt touch the stuff at bfc0... if i recall correctly.... mmmh thinking of it, i'm not even sure if exceptionman does, it would make sense to have the first loaded module or even the ipl init that area *shrug*

moonlight · Post by **moonlight** » Mon Aug 21, 2006 7:55 pm

groepaz wrote:interruptman doesnt touch the stuff at bfc0... if i recall correctly.... mmmh thinking of it, i'm not even sure if exceptionman does, it would make sense to have the first loaded module or even the ipl init that area *shrug*

I've checked the full dissasembly of the 1.50 ipl, sysmem and loadcore. None of them touch that.

exceptionman does it (well i made a recheck, and it seems to touch 0xbfc01000 and on, bfc00000-bfc000040, which is not needed for the decryption) , that's the point of replacing it (plus is the first module that can be replaced by a decrypted version with that flaw, replacing loadcore or sysmem won't work).

groepaz · Post by **groepaz** » Mon Aug 21, 2006 7:59 pm

mmh well, something *must* touch the ram at bfc... before, since this is where the cpu starts executing :=) probably the embedded bootstrap then... mmmh

moonlight · Post by **moonlight** » Mon Aug 21, 2006 8:02 pm

groepaz wrote:mmh well, something *must* touch the ram at bfc... before, since this is where the cpu starts executing :=) probably the embedded bootstrap then... mmmh

But that doesn't explain the fact that three dumps are different, even the two that are dumped at the same time. in the same loop. That's my real headhache :P

Raphael · Post by **Raphael** » Mon Aug 21, 2006 10:03 pm

I really got no clue about such stuff, but could it be that somewhere at 0xbfc... is some kind of instr counter or mem addr pointer, dependent on the currently executed operation?
Doesn't make much sense elseway, since the double dump should definately get the same result if no other prx interferes

0okm0000 · Post by **0okm0000** » Mon Aug 21, 2006 11:50 pm

may be used by hardware

Disasm exceptionman2 - exceptionman.prx

Code: Select all

L00000000&#58;
  lui    a0,$bfc0                           ;00000000&#91;3C04BFC0&#93;
  lui    a1,$883e                           ;00000004&#91;3C05883E&#93;
  ori    a2,a0,$1000                        ;00000008&#91;34861000&#93;
  lbu    v0,$0&#40;a0&#41;                          ;0000000C&#91;90820000&#93;
  sb     v0,$0&#40;a1&#41;                          ;00000010&#91;A0A20000&#93;
  lbu    v1,$0&#40;a0&#41;                          ;00000014&#91;90830000&#93;
  addiu  a0,a0,$1                           ;00000018&#91;24840001&#93;
  sb     v1,$1000&#40;a1&#41;                       ;0000001C&#91;A0A31000&#93;
  bne    a0,a2,$0000000c                    ;00000020&#91;1486FFFA&#93;
  addiu  a1,a1,$1                           ;00000024&#91;24A50001&#93;
  jr     ra                                 ;00000028&#91;03E00008&#93;
  addiu  v0,0,$1                            ;0000002C&#91;24020001&#93;

Post by **TyRaNiD** » Tue Aug 22, 2006 1:49 am

Exceptionman does indeed touch bfc* cause it loads the debug exception handler to there, something which 1.0 doesn't do. Maybe worth trying 1.0 instead, maybe :P

moonlight · Post by **moonlight** » Tue Aug 22, 2006 1:57 am

TyRaNiD wrote:Exceptionman does indeed touch bfc* cause it loads the debug exception handler to there, something which 1.0 doesn't do. Maybe worth trying 1.0 instead, maybe :P

But it seems that the interesting part for the decryption, [0xbfc00040-BFC002C0] is not modded by exceptionman, since my dumps obtained by replacing the useless uart4.prx are identical in that segment to the obtained replacing exceptionman. (i didn't realize it until today :P)

Post by **TyRaNiD** » Tue Aug 22, 2006 2:04 am

It still might be worth trying v1.0 just because :P

forums.ps2dev.org

2.70 IPL

2.70 IPL

Re: 2.70 IPL