SBORPS » Misc http://my.malloc.us/silverspring SilverSpring's bunch of random PSP stuff... Tue, 24 Nov 2009 05:32:47 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 New NAND Flash device support added http://my.malloc.us/silverspring/2008/07/new-nand-flash-device-support-added/ http://my.malloc.us/silverspring/2008/07/new-nand-flash-device-support-added/#comments Sat, 19 Jul 2008 13:15:45 +0000 silverspring http://my.malloc.us/silverspring/2008/07/19/new-nand-flash-device-support-added/ Support for new nand IC's from ST Micro (upto 128MB) have been added to the nand driver in newer firmwares. Previously only Samsung (retail PSP) and Toshiba (devkit PSP) nands were supported.

view plain
C:
  1. const struct {
  2.     u8 id[2]; // [manufacturer ID, device ID]
  3.     u8 type[2];
  4.     u16 bytesPerPage;
  5.     u16 pagesPerBlock;
  6.     u32 blocksPerDevice;
  7.  
  8. } nandIdTable[] = {
  9.  
  10.     // Toshiba 3.3V NAND Flash family
  11.     { {0x98, 0xE6}, {3, 1}, 512, 16, 1024  }, // 8MB
  12.     { {0x98, 0x73}, {3, 1}, 512, 32, 1024  }, // 16MB
  13.     { {0x98, 0x75}, {3, 1}, 512, 32, 2048  }, // 32MB
  14.     { {0x98, 0x76}, {3, 1}, 512, 32, 4096  }, // 64MB
  15.     { {0x98, 0x79}, {3, 1}, 512, 32, 8192  }, // 128MB
  16.  
  17.     // Samsung 3.3V NAND Flash family
  18.     { {0xEC, 0xE6}, {3, 2}, 512, 16, 1024  }, // 8MB
  19.     { {0xEC, 0x73}, {3, 2}, 512, 32, 1024  }, // 16MB
  20.     { {0xEC, 0x75}, {3, 2}, 512, 32, 2048  }, // 32MB (default TA-079/081 PSP NAND)
  21.     { {0xEC, 0x76}, {3, 2}, 512, 32, 4096  }, // 64MB
  22.     { {0xEC, 0x79}, {3, 2}, 512, 32, 8192  }, // 128MB
  23.     { {0xEC, 0x71}, {3, 2}, 512, 32, 16384 }, // 256MB
  24.     { {0xEC, 0xDC}, {3, 2}, 512, 32, 32768 }, // 512MB
  25.  
  26.     // Samsung 1.8V NAND Flash family
  27.     { {0xEC, 0x39}, {1, 2}, 512, 16, 1024  }, // 8MB
  28.     { {0xEC, 0x33}, {1, 2}, 512, 32, 1024  }, // 16MB
  29.     { {0xEC, 0x35}, {1, 2}, 512, 32, 2048  }, // 32MB (default TA-082/086 PSP NAND)
  30.     { {0xEC, 0x36}, {1, 2}, 512, 32, 4096  }, // 64MB (default TA-085/088 PSP NAND)
  31.     { {0xEC, 0x78}, {1, 2}, 512, 32, 8192  }, // 128MB
  32.    
  33.     // ST Micro 1.8V NAND Flash family
  34.     { {0x20, 0x35}, {1, 2}, 512, 32, 2048  }, // 32MB
  35.     { {0x20, 0x36}, {1, 2}, 512, 32, 4096  }, // 64MB
  36.     { {0x20, 0x39}, {1, 2}, 512, 32, 8192  }, // 128MB
  37. };

]]> http://my.malloc.us/silverspring/2008/07/new-nand-flash-device-support-added/feed/ 0 More SCE Mind Games™… http://my.malloc.us/silverspring/2008/01/more-sce-mind-games%e2%84%a2/ http://my.malloc.us/silverspring/2008/01/more-sce-mind-games%e2%84%a2/#comments Sat, 26 Jan 2008 01:42:41 +0000 silverspring http://my.malloc.us/silverspring/2008/01/26/more-sce-mind-games%e2%84%a2/ Have you ever booted up your psp or resumed from sleep and have it appeared bricked (psp freezes then shutoffs)?

Well you can blame SCE for that. You see, if you have corrupt idstorage (keys 4, 5, 6, or 7) there's an exactly 12.5% chance that on boot the psp will appear bricked. The IPL will check for corrupt keys but will only randomly do so. The check is based on the time, if the current time (in millisecs) is a multiple of (approx.) 8, the IPL will check your idstorage keys and if they are corrupt (ie. if the header for those keys dont match what they should be), the psp will shut itself off.

What is even worse is that this check also occurs during resuming from sleep mode. So one could theoretically boot up the psp fine, sleep, then fail on resume. All of this is to confuse us devs by trying to obscure the problem...very sneaky in my opinion.

Technically, it checks like this:

view plain
C:
  1. // a 32/256 (12.5%) chance this check will occur
  2. // errorExit() shuts down the psp
  3. if ((time>>4 ^ time) & 7 == 0)
  4. {
  5.     if ((*(u32*)&leaf4[0] != 0) &&
  6.         (*(u32*)&leaf4[0] != 0x4272796E)) // Bryn
  7.             errorExit();
  8.  
  9.     if ((*(u32*)&leaf5[0] != 0) &&
  10.         (*(u32*)&leaf5[0] != 0x436C6B67)) // Clkg
  11.             errorExit();
  12.  
  13.     if ((*(u32*)&leaf6[0] != 0) &&
  14.         (*(u32*)&leaf6[0] != 0x4D446472)) // MDdr
  15.             errorExit();
  16.  
  17.     if ((*(u32*)&leaf7[0] != 0) &&
  18.         (*(u32*)&leaf7[0] != 0x41506144)) // APaD
  19.             errorExit();
  20. }

So, what do people think of this new trick?

Sneaky? Absolutely. Suprised? Well, this is SCE we're talking about here.

Another day, another mind game...

EDIT: Slight correction, the time is actually in 500ms intervals (0.5second intervals), not milliseconds.

]]> http://my.malloc.us/silverspring/2008/01/more-sce-mind-games%e2%84%a2/feed/ 3 The mind games SCE play… http://my.malloc.us/silverspring/2007/12/the-mind-games-sce-play/ http://my.malloc.us/silverspring/2007/12/the-mind-games-sce-play/#comments Sun, 02 Dec 2007 12:22:53 +0000 silverspring http://my.malloc.us/silverspring/2007/12/02/the-mind-games-sce-play/ We are all familiar with the various tricks SCE use to fool devs, though I recently came across one that has annoyed me the most.

When 3.40 was released, a 'special' prx was flashed with the rest of the firmware that didnt seem to be used at all. It was special in that not only was it not used nor referred to once in the entire firmware, it also could NOT be decrypted (the keys to decrypt it simply did not exist in the firmware). Because of this and the fact that the prx was promptly removed from all future firmware (it only exists in 3.40) it was assumed to be a remnant of a debug prx used during testing and they had simply forgot to remove it. Or was it?

The prx was "idcheck.prx". The module name sounded interesting and on first glance it was assumed to be the debug version of the embedded prx SCE hid in 3.30+ updaters to check for corrupt idstorage in their updaters (the one that refuses to update the PSP if either your keys 4, 5, 6, 7 & 8 were corrupt).

Long story short, the prx has been decrypted and the result was far from expected. It seems that the original module has been taken out and replaced with a dummy instead. The only remains left of the original module was the module name "sceIdCheck" and the data segment, which included the strings "Illegal idstoarge" (SCE always misspell 'idstorage'), "flash is corrupted", and "cannot restore PSP system". The rest of the module (including all the code) had been dummied with another module from the firmware.

Now why would SCE do this? If it were a debug prx that was accidently left in, why would they bother going to the trouble of dummying the code?

Some accidental mistake on their part, or more of their ridiculous mind games at play......

]]> http://my.malloc.us/silverspring/2007/12/the-mind-games-sce-play/feed/ 0