For those who are wondering, I’m not dead - just swamped with work and an unhealthy obsession with Fable II. Which is unusual for me, considering that I’m really not much of an RPG buff.

Some great news in the PSP-3000 hacking front came and went, the most promising one being the motherboard of the new system — it’s a TA-90, hence “pandorizable”, though currently with some sort of protection. Let’s hope not for too long.

In other news, I’ve noticed that while Atari800 has not seen any releases since mid-last year, work on it has been ongoing. While the changes are mostly structural (code reshuffling, etc…), they have made me consider an intermediate, possibly beta release of Atari800 PSP, based on code in the CVS repository. If that happens, I’ll most likely post a build in the forum for those interested to test (I’ll post an update here as well).

For the Fuse fans, here’s the situation on future releases: Philip Kendall, the principal developer of Fuse, commented earlier about changes coming to a future release; these changes will be substantial (from the sound of it, and at least from a structural standpoint), going so far as to change how extended disk support functions. Fuse PSP is being actively developed, and will be updated when the next version of Fuse is released, or shortly before.

There are other things being worked on at the moment, but as I’m not certain of their status, I’m going to keep any comments to myself, until I know for sure.

You’ve probably heard about this elsewhere already, but Dark_AleX has recently posted information on why the newer PSP models (later-model Slim, and likely Brite) cannot currently be hacked.

The upshot of the story is that 32 bytes of data that were previously unused space used for padding, are now actually used for storing two cryptographic hashes. The hashes are assumed to be (and in all likelihood are) based on the decrypted copy of the encrypted information, and are used to authenticate the validity of the encrypted data. If a computed hash doesn’t match the supplied hash, the CPU will refuse to run the firmware.

The new implementation is not very different from the implementation of the SSL/TLS protocol, as well as many other common encryption protocols — in fact, it’s rather strange (though perhaps fortuitous for us) that it wasn’t implemented until now. It does, however, significantly complicate the initial bootstrapping process (if only in terms of cryptography), which simply required valid decrypted data (according to the same article, original encryption was destroyed by employing a timing attack).

If there is a silver lining here, it’s in the potential weakness of the human element. For those of you who recall, Pandora came about when a Sony repairman left specially-formatted memory stick in a repaired PSP sent back to a customer. Let’s hope that some lucky soul somewhere finds a bunch of unencrypted boot IPL’s in his/her memory stick (and that he/she knows who to send them to).

Odds are that you’ve probably heard about the new PSP-3000 model (colloquially called “PSP Brite”) that’s due to be released soon, and one that will replace the PSP-2000 series (”PSP Slim”). The new model will include a built-in microphone and a brighter, more responsive screen - an improvement that is almost negligible when one considers the improvements between “Slim” and “Phat” (PSP-1000 series).

Like many other developers and hobbyists, I suspect that there’s more to the system than what the press release lets on - I’m fairly certain that the new PSP model will be built differently to eliminate the extremely efficient “Pandora” hack. A recent dcemu thread discusses just that - probability of the elimination of PSP’s “hackability”, and raises some interesting points, among them “will this stop piracy?”. I’m fairly certain that the answer is “no” - and not just to piracy, but hacking in general. After all, the initial hacks of the PSP centered around badly implemented loading routines in the PSP’s image viewer and GTA: LCS, and as long as there are inquisitive people, there will be exploits to be found and security holes to be exploited. While I expect to see the end of Pandora, I doubt we’ve seen the end of buffer overflow exploits - hardware (and firmware) necessary to deter/elminate buffer overflow exploits would, in all likelihood, break backwards compatibility (not to mention prove too costly).

One thing that I believe is important to remember, however, is that Sony shouldn’t necessarily be chastised for this step. Piracy is an unfortunate side-effect of homebrew development - while I’m not going to venture a guess as to how much money the company is losing/has lost due to piracy, I’m fairly certain that it’s a considerable amount. For many, like myself, the PSP is a retrogamer’s dream come true - there’s no better way to waste hours on end than by playing Legend of Zelda, a port of Doom, or any of the large number of homebrew applications. For too many, however, it’s just a way to hoard modern games.

Sony has stated in the past that they’re aware of PSP’s homebrew community, and that their problem is not with homebrew, but piracy. While I have no reason to trust any particular large company (Enron, anyone?), I have no basis to doubt this fact in the current situation - if anything, homebrew development has helped Sony sell more units. At the same time, piracy hurts those who make the PSP into what it is - the makers of the PSP games. No PSP games means much fewer sales (I don’t think homebrew alone will carry the PSP); fewer sales means no motivation to support or manufacture the PSP.

Comments are welcome.

UPDATE Indeed, Pandora is no longer bootable in the same fashion as the older models

The recent issue with fMSX 3.5.3 (fw 1.50 version) prompted me to rethink future support for 1.50/kxploit executables. One option was to regress to an earlier version of the library, dropping any of the adhoc functionality; another was to simply stop working on versions for 1.50.

I (grudgingly) decided to stop providing support for fw 1.50 - reasons for this being threefold - a) the ps2dev community recommends moving away from this firmware, as continuing support for it is getting more challenging (flash0 memory being one reason); b) running simple applications in kernel mode seems counter-intuitive, and c) it’s becoming exceedingly more difficult to cope with two distinct programming models.

The emulators that are currently up will probably be the last ones with support for firmware 1.50; all future emulators are likely to only run on firmware 2.00 and greater.

UPDATE Wow, what a coincidence

The ps2dev.org forum has an interesting thread on porting existing applications to firmware 3.60 - though there are reports that many applications already run on 3.60 without any updates:

Development for the Slim and 3.60 is largely the same. Since it’s not 1.50 anymore, you’ll want to set BUILD_PRX=1 and PSP_FW_VERSION=360 in your Makefile. Since the executable is now a PRX, the default heap size will be only 64kb and you’ll want something like PSP_HEAP_SIZE_KB(25000) in your C file to give malloc() a bigger pool. The extra memory is located in a different partition as described here, which newlib isn’t set up to use at the moment.

Read more…

dcemu.co.uk reports that the first custom firmware for PSP 2000 (or “PSP Slim” as it is commonly called) is now available! Installation of the firmware requires another “fat” (classic) PSP and a “Pandora” battery.

Great news for all concerned, to be sure