I see a lot of people talking and guessing. Some are even writing code.
The only promising thing I have seen so far was the thread about the memory / flash chip. This is the way to go guys.
Reverse engineering requires a lot of time to try and poke around. With a 1.50 firmware and no hardware experience you are stuck.
Due to my lack of time, I can only tell you what I think to be useful.
- The 1.0 software will help a lot when being compared to the 1.5 software. Maybe somebody can sell/swap his PSP.
- You need to understand assembly, in particular you must have read and understood the MIPS documentation referenced earlier.
- You need very good soldering knowledge. You must be able to desolder the flash and attach wires to the ball grid array.
- You need to know VHDL.
- You need to know the pinout of the flash / ram (posted earlier here).
- You need to attach a very fast FPGA to the PCB where the FLASH/RAM was. The FLASH/RAM needs to be hooked to the FPGA itself. This way you can monitor / filter / poke around in the flash or ram while the PSP is running. Maybe this could break the RAM timing. If so, try to deacrease the master clock speed of your PSP (either route it through the FPGA and devide it or use a slower/different clock source or both of them).
- First write some VHDL software that understands the RAM and the Flash bus protocols. You might decide it is too complicated to handle the RAM, then attach the RAM directly to the PSP (instead of the FPGA) and just hook the FPGA on the bus. Your goal is to get the PSP running with the FPGA attached.
- Attach your logic analyzer to your FPGA as well. Try to find out how the PSP is starting up. At the beginning, the CPU is jumping to a certain address in the flash. That code is probably trying to verify the validity of the rest of the firmware. Maybe it is decrypting and decompressing the firmware into the ram. Maybe the whole firmware is executed directly from the flash saving ram but wasting flash. If so, the firmware needs to be unencrypted and uncompressed what would be VERY VERY GOOD for us. If not, there needs to be some code taking byte for byte of the firmware, decrypting it and saving it to the ram. Using your logic analyzer you can intercept the writes to the ram and get a clear copy of the firmware.
- If you are unlucky, there is already some code hard wired in the main cpu itself verifying the content of the flash. Unfortunately you can not patch this code but you can try disabling it (maybe the cpu has some pins telling it wheter it should start from the internal rom or the external one). Try to get some code executed that is actually dumping that code to a bus in order to be intercepted by the logic analyzer. Then you can disassemble it to find out how checksum/encryption is made.
- Your first priority should be disabling all caches of the main cpu. Check out the MIPS datasheet for this. Assuming your PSP is first building a checksum of the flash, write some VHDL code that allows you to blend in code changes (or complete blocks) whereever you want and obviously trigger this functionality after the checksum of the flash has been calculated.
Now the real reverse engineering can begin...
What is an FPGA: http://en.wikipedia.org/wiki/FPGA
What is a logic analyzer: http://en.wikipedia.org/wiki/Logic_analyzer
What is VHDL: http://en.wikipedia.org/wiki/VHDL
What I forgot to say about FPGA: Instead of attaching wires to the FPGA chip itself, buy some sort of development board that has display, ram, serial port, buttons, power supply etc on it. If I remember correctly my Virtex 2 board from Xilinx was around $1500.
Reverse engineering
This could be done just as effectively with a 1.5 PSP as a 1.0 PSP, and would be just as tedious. The advantage of the 1.0 PSP is that we could see the process of our own code.
This is a pretty good idea, and I just wish I wasn't in the middle of a move and in the middle of a few large purchases. I would be willing to do a bit of analysis myself by doing what nem has done to a 1.5 US model (minus the code execution obviously).
At least there /is/ a use for all that VHDL I picked up in my CompEng degree (which I use for software, oddly)... I hate the language, a lot of the compilers barf on perfectly valid complex constructs.
This is a pretty good idea, and I just wish I wasn't in the middle of a move and in the middle of a few large purchases. I would be willing to do a bit of analysis myself by doing what nem has done to a 1.5 US model (minus the code execution obviously).
At least there /is/ a use for all that VHDL I picked up in my CompEng degree (which I use for software, oddly)... I hate the language, a lot of the compilers barf on perfectly valid complex constructs.
Indeed VHDL is the most complex and unfriendly language in existence. If your project is big, it can take HOURS to compile. If something doesn't work, you could have made a mistake but on the other hand, your timing could be too fast (input clock) and you are exceeding the physical limits of the chip.
If I would have to setup that system, I expect it to take around one month or two. Fortuantely I have written several thousands of lines of VHDL code containing a built in hex editor (for real time editing of mapped out blocks of the flash), command line interface, serial communication and more. If somebody really wants to take to burden and start on this, msg me.
Unfortunately I think the whole thing is so cmplex that I do not belive a single person is capable of doing all the tasks required (BGA soldering, VHDL, MIPS, C, time) so if you think you can do at least one of these tasks, post it here to form up a team.
Furthermore the ideas I have posted in the first place where valid for some completely different CPU architectures where security was not so important. But I have accumulated them over several years of doing this job. Some of them can certainly be applied.
There is no guarantee that the PSP can not be hacked by software alone. On the other hand, Sony can fix and update the firmware all the time.
I can also assure you that, from a commercial point of view (time is money), this is the way to go if you want to hack something or create a mod chip.
The whole hardware thing *might* not be required if you can learn enough and fast enough from the 1.0 firmware.
If I would have to setup that system, I expect it to take around one month or two. Fortuantely I have written several thousands of lines of VHDL code containing a built in hex editor (for real time editing of mapped out blocks of the flash), command line interface, serial communication and more. If somebody really wants to take to burden and start on this, msg me.
Unfortunately I think the whole thing is so cmplex that I do not belive a single person is capable of doing all the tasks required (BGA soldering, VHDL, MIPS, C, time) so if you think you can do at least one of these tasks, post it here to form up a team.
Furthermore the ideas I have posted in the first place where valid for some completely different CPU architectures where security was not so important. But I have accumulated them over several years of doing this job. Some of them can certainly be applied.
There is no guarantee that the PSP can not be hacked by software alone. On the other hand, Sony can fix and update the firmware all the time.
I can also assure you that, from a commercial point of view (time is money), this is the way to go if you want to hack something or create a mod chip.
The whole hardware thing *might* not be required if you can learn enough and fast enough from the 1.0 firmware.
Dont forget to look for JTAG connectors.
They're used in many, many embedded systems now to recover from a bad flash and/or to program in the original BIOS/OS.
Its possible that the PSP has a ROM bios, that will get the firmware from either the memory card or via a serial port connection (search the posts, there was one about that)..
But if theres a JTAG header and its coupled to the processor/flash or both..
That can be used to read in the bios, and to debug. I.e. step by step. Theres problems with that way, but, all we really need is to understand the BIOS and how it works..
I strongly believe theres a backdoor because how else would sony recover from bad flashes? That same back door could be used to reflash to our own OS, or reflash to version 1.0.. Among other uses.
They're used in many, many embedded systems now to recover from a bad flash and/or to program in the original BIOS/OS.
Its possible that the PSP has a ROM bios, that will get the firmware from either the memory card or via a serial port connection (search the posts, there was one about that)..
But if theres a JTAG header and its coupled to the processor/flash or both..
That can be used to read in the bios, and to debug. I.e. step by step. Theres problems with that way, but, all we really need is to understand the BIOS and how it works..
I strongly believe theres a backdoor because how else would sony recover from bad flashes? That same back door could be used to reflash to our own OS, or reflash to version 1.0.. Among other uses.
It can be anything sony wants it to be. It can be a BIOS ROM that will listen for serial port commands from the headjack port or another special place. JTAG is an alternative, but if theres no BIOS ROM or any other kind of BIOS, then I'd be willing to bet on JTAG.ooPo wrote:Its a fact that there's a backdoor in the psp for restoring bad or empty flash data. I doubt it actually is jtag, however... but who knows?
Hey nem, is it? :)
Hell, the battery has 3 terminals. 2 are for power, 3rd is most likely temperature sensor - but that could also be a "hidden" uplink port.
I may open up my PSP to hunt for any suspect ports. The pictures of the hardware helps, but its alot easier (and risker) to look for it with the device in my hands, especially since I have experience with creating circuit schematics from circuit boards.
http://ps2.ign.com/articles/430/430963p1.html
"Extension Port"???I/O
USB 2.0
Memory Stick
Extension Port(reserved)
Stereo Head phone Out
Don't pin all your hopes on jtag, it is a very minimal interface for connecting to devices like in-circuit emulators. Unless you know how to talk to them once you've connected to it via jtag, you're stuck. You can get an IDCODE at most and use that to trial-and-error it maybe... but there generally isn't a standard way of talking to devices.
If you want to keep looking, fine... you only need about 5 pins or so to make it work. But you'd probably be better off looking at that remote port.
If you want to keep looking, fine... you only need about 5 pins or so to make it work. But you'd probably be better off looking at that remote port.
Nothing quite so sinister as data flow. There is no control logic in the battery more complex than a standard protection circuit. There is also the possibility for that pin to be a power pin for higher voltage. The smallest data link I have seen is I2C, which uses two pins, not including power. I have yet to see a 1-pin data bus between two distinct devices.Hell, the battery has 3 terminals. 2 are for power, 3rd is most likely temperature sensor - but that could also be a "hidden" uplink port.
I agree with ooPo on JTAG... each device tends to be rather specialized, requiring specific software to use the JTAG. While it is very much a worth-while avenue, I wouldn't risk your only PSP to the search for it. :)I may open up my PSP to hunt for any suspect ports. The pictures of the hardware helps, but its alot easier (and risker) to look for it with the device in my hands, especially since I have experience with creating circuit schematics from circuit boards.
-
Guest
On the contrary, it is likely the number of PSP's in each country are about even right now. The US only has just over twice the population of Japan, and Japan has 10 times more electronic gadget fetish than the US, and the PSP has been out much longer in Japan.omlette wrote:Even if you could reflash your PSP to the original firmware, we all know that the US models shipped with 1.5. I don't think it would revert to 1.0.
(Yeah, it would work fine for people with JP PSPs, but I think US PSPs are the majority here.)
And most dev'ers here have JPN PSP's :)
Despite that, the hardware should be exactly the same.