Associate
- Joined
- 16 Jul 2008
- Posts
- 86
Right, so I've played with it a bit and I've hacked my firmware, but I'm confused as to why Sony let this happen in the first place when there's a cheap solution. Let me explain.
The PSP has an EEPROM chip where its firmware is installed, which you can flash with an update file. The hackers first got around this by using a bug in the GTA game save handling code to inject a custom patch into memory and have it put their own data on the EEPROM. The PSP then reboots and voila - you have a custom firmware installed on your PSP. Since then there have been patches to stop this and the hackers have gotten round it.
So, now to my solution. I know nobody in the public wants this to be fixed but I'm just putting my thoughts out there so that they can be heard.
Here's a hypothetical situation:
Sony writes their firmware and compiles it, making sure that there is a 256-byte array full of zeros. This array must be static on the EEPROM - i.e. it must stay in the same place no matter what you do with the rest of the firmware code. Sony builds the PSP with a tamper-proof secondary processor (something like an FPGA) that had an implementation of RSA's hash signing algorithm on it. They write a simple RSA signing application and generate a 1024-bit RSA key pair. They keep the private key secret within the corporation. They hard-code the public key and the address of the 256-byte array into this processor and "seal" the code onto the chip's ROM.
Sony now hashes their firmware with SHA1 and signs the hash using their RSA private key. They write this value over the array of zeros and put the firmware on the device.
Here's how the EEPROM will look when it is compiled (bla bla bla is firmware code):
Their software takes that data, hashes it with SHA1, then signs the hash and writes that value over those zeros.
The RSA processor loads the raw EEPROM data into its memory and extracts the key from the 256-byte array and stores it. It then replaces the 256-byte array with zeros again and hashes the EEPROM data as before, but this time it doesn't need to sign it. It then verifies the signature against the generated hash using the public key and RSA's signed hash verification function. If the signature is verified, the RSA processor sends an enable signal to the PSP's main processor allowing it to begin running the firmware. If the signature could not be verified, the PSP does not boot.
If anyone can think of a way to bypass this, shout up. And please, if you don't understand asymmetrical encryption like RSA, don't try to put your 2 cents in because I don't feel like explaining the same thing over and over again.
The PSP has an EEPROM chip where its firmware is installed, which you can flash with an update file. The hackers first got around this by using a bug in the GTA game save handling code to inject a custom patch into memory and have it put their own data on the EEPROM. The PSP then reboots and voila - you have a custom firmware installed on your PSP. Since then there have been patches to stop this and the hackers have gotten round it.
So, now to my solution. I know nobody in the public wants this to be fixed but I'm just putting my thoughts out there so that they can be heard.
Here's a hypothetical situation:
Sony writes their firmware and compiles it, making sure that there is a 256-byte array full of zeros. This array must be static on the EEPROM - i.e. it must stay in the same place no matter what you do with the rest of the firmware code. Sony builds the PSP with a tamper-proof secondary processor (something like an FPGA) that had an implementation of RSA's hash signing algorithm on it. They write a simple RSA signing application and generate a 1024-bit RSA key pair. They keep the private key secret within the corporation. They hard-code the public key and the address of the 256-byte array into this processor and "seal" the code onto the chip's ROM.
Sony now hashes their firmware with SHA1 and signs the hash using their RSA private key. They write this value over the array of zeros and put the firmware on the device.
Here's how the EEPROM will look when it is compiled (bla bla bla is firmware code):
Code:
bla bla bla bla bla bla bla 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bla bla bla bla bla
Their software takes that data, hashes it with SHA1, then signs the hash and writes that value over those zeros.
The RSA processor loads the raw EEPROM data into its memory and extracts the key from the 256-byte array and stores it. It then replaces the 256-byte array with zeros again and hashes the EEPROM data as before, but this time it doesn't need to sign it. It then verifies the signature against the generated hash using the public key and RSA's signed hash verification function. If the signature is verified, the RSA processor sends an enable signal to the PSP's main processor allowing it to begin running the firmware. If the signature could not be verified, the PSP does not boot.
If anyone can think of a way to bypass this, shout up. And please, if you don't understand asymmetrical encryption like RSA, don't try to put your 2 cents in because I don't feel like explaining the same thing over and over again.
Last edited: