Sorry, I was away putting sheetrock up in my house.
Printable View
Sorry, I was away putting sheetrock up in my house.
In a time like this???Zitat:
Zitat von Xay_J
Getting out of a FEMA trailer and back into my house is WAY more important... >_>
I dont have a binary of the psp remote, just source. Do you want it?
I have the remote emulation binary.
Can someone catch me up as to what is going on? sorry, i really am.Zitat:
Zitat von TeamOverload
Let see if i got it figured out: he made a cable that can go from that music thing to the computer and supposedly we can flash the psp with some software on the pc...is that correct?
Can you post it?Zitat:
Zitat von Xay_J
Arggg I have to recompile it.
Should I use cygwin or my Ubuntu live disc?
O_o, You should know how to do it...Zitat:
Zitat von Xay_J
[cygwin]
dsl cant even use the make command...thats pathetic.
try zip slackZitat:
Zitat von TeamOverload
is there going to be anything that becomes of this tonight? (possibly??)
cygwin was also mentioned in the other post i read. so we're on the right track,
now all we need to do is figure out how to use these apps to either execute an eboot remotely from the pc to overwrite the flash (if possible) or continue monitoring the communication to see if access to the flash is even possible. maybe direct overwriting of the 2.7 files with 1.5 files will be possible. but the question i'm wondering is will the psp boot up properly if the files are simply overwritten.
another thing i thought of....on psp bootup is the serial port activated right away or later during the boot process.
the boot sequence would really help us here.
do the prx's tell us anything about the way the psp executes commands?
what in the psp tells it that the firmware on the psp is newer than lets say a 1.5 when we try to launch it? if we could find that out then maybe we could overwrite or erase that info directly without bricking the psp and then be able to lauch a 1.5 and downgrade that way,
or if possible but i doubt it, during the boot process maybe finding a command to pause the boot sequence at a certain point without cutting off communication to the psp so that any protection that the psp might launch is stopped before hand so we can overwrite the flash.
sounds crazy yeah i know but i believe this is how real working exploits are discovered........by trying out or stripping down crazy a$$ ideas for real solutions.
I highly doubt it. Maybe something small, but nothing major.
edit: not you jedi
Maybe they will get closer to the goal, but I can tell there is much much more work for these guys to do. Much more information about how the psp flashes and other stuff needs to be figured out.
i also wonder what do the use that ir port is used for by sony
I can't even get my preexisting environment running.. *sigh*
Jedi do you have a decrypted firmware dump?
I do.
well although there is nothing in the psp's firmware that allows us to use the irport on the damn thing, nothing in 2.70 firmware gives me any ability to use it, but people believe it could be for device to device communication. like for example laptop with ir port to psp for file transfering. or maybe an alternate means to transfer files from one psp to another incase wifi fails.
but who really knows.
I would love to know if the ir receiver is enabled or active by default, if so i could line my psp up with my laptop and see what happens. but i would need someone to tell me if the ir port is on always or if software is required to turn it on.
anyone know?
I know, but he asked about the boot process, which is in the dump. I was curious if he checked it out yet.
Boot Sequence
As Taken From PSPBTCNF.TXT
**EDIT**
Stupid Copywrights T_T
But its Loaded durring Bootup
i wish, i wanted to do some kind of work when i found out that 2.7 was decrypted, i was thinking psp emulatyion on the pc and then running the decrypter through the emulator but then i read the instructions on how to obtain the dump and it requires a 1.5 psp which i don't have. but i believe they are being hosted somewhere.Zitat:
Zitat von TeamOverload
You shouldnt post that. It is copyrighted.
Note the bolded part: yes if we could run a simple version changer though this (similar to tiff exploit) then we could all have v1.50 :Punk:Zitat:
Zitat von jedimasteryoda
There is new encryption on the index.dat so that wont work.
If anyone needs the 2.71 decrypted dump, I have it. I can't post it I know. But I do have it just incase anyone cared.
>_>
Also if anyone cares my E-mail is [email protected]
thanks sarahbaby, i think the boot sequence will hopefully help us find an exploit somewhere, or if we're lucky maybe we can slip in our own prx (*if possible ) that will open a new door for code execution. but thanks again for the sequence. much abligedZitat:
Zitat von SarahBaby3325
please excuse spelling mistakes, part my fault part laptop keyboard fault. lol
Nice way to be subtle :p
Jedi check your pms!
I like where this thread is going :) Alot of good progress being made, keep it up!
Alright, Im off to bed now. I cant wait to check up on this in the morning.
well i'll try to do some more digging and check back tomorrow during work to see what's developed from all this, i wish everyone the best of luck on this and i'll gladly contribute in any way i can. with that said i bid you all a good night and dreams of a world where we can do as we please....with our psp's lol.
just to get something clarified here because i know there was alot of discussion and flaming over the signature on eboots and stuff. but if it's impossible to modify an eboot without breaking the encryption, why couldn't we modify the portion of the chip that either controls or verifies the signature so that signature would no longer be required to launch eboots.Zitat:
Zitat von TeamOverload
is it possible that even if the eboot contains an encryption key, if the unit (psp) does not have the ability to validate the key that it can or will launch it anyway
or
once that portion of the flash chip info is modded we can go back to writing eboot files that will launch without signing them.
of course this requires knowing if the psp in fact has the ability to verify and decrypt the key and if so what module or file controls this function.
which leads me to my last question for the night.
can someone find out if the psp main board has a third chip (possibly known as an eeprom chip) outside the 2 tsop or nand chips? if so there may be something there to exploit as well. maybe not, i'm just wondering, because of what i know about sat irds.
I'll look into it. I've had my PSP opened up before, but I was at my real home and I had all of my tools with me. Not sure if I want to do it here.Zitat:
Zitat von jedimasteryoda
By the way, I believe that the .prxs must be signed/encrypted, so we can't edit them. At least that was what I was told. That was why everyone wanted 1.0 so bad was because they didn't believe it checked to see if it was signed/encrypted.
EDIT: I think I see what you are saying. Because if the PSP can tell if the .prxs are encrypted, then that must mean that the encryption check must be somewhere else on the PSP's hardware. But if that's the case, how is U.P. able to supposedly have custom firmwares? Unless it accesses the part of the hardware that does the checks.
EDIT: Also, here are pictures of the PSP opened up.
EDIT: So what is the Sony chip that the U.P. connects to for?
He has a point, the serial port is obviously used by sony, but whats this speak about a "Special" battery?
NOTE: If you havnt noticed yet, you can awaken your psp from sleep in the XMB by touching 2 of the contacts in the serial port. ( Do it quickly. )
|_ You can also just plug in the CONTROLLER and press play. ( Retail, with PSP. )
In ALL firmwares, this will awaken your psp from sleep.
I assume there is a "debug" mode to be unlocked from within the psp by giving a quick series of connections in the serial port.
HMM! ( Whilst off? )
I hope I don't come off as a noob, but what can I use to view the .prx files?
What sort of prx files?
Use a dumper to see the ones in your firmware, or a UMD.
Explain which...
Are we Talkin Button Combos? b/c I remember finding some type of Glitch/Debug for a Game UMD after pressing home and quitting from a umd game, then repeatedly pressing select...A UMD Menu Pops up...Nothing real BigZitat:
Zitat von LordSturm
The 2.71 dump. I'm also thinking about viewing the 1.5 dump.
To be hoenst, if this thing really is a flasher, I don't think I'll be able to find anything in the .prx's. Sony can't rely on files that possibly aren't there (in the case of a bricked PSP) to try and fix the PSP.
EDIT: I have the files already, but the obviously don't work in a text viewer. I get a lot of odd symbols.
Hi everyone :)
So, I finally finished reading most of this thread....
The idea of using the serial "port" is not new indeed. There HAS to be a cost effective and quick way of reflashing.
My thoughts:
Serial is far to slow to flash a 20+MB Firmware.
What about this:
When powered on and even before the IPL is executed some sort of hardcoded (in ROM) "basic recovery routine" checks for some (specially indicated?) connection on the serial port.
If found it sits there and waits for data that it simply copies into the PSP's RAM
That data is raw binary code (pure assembler, not even ELF, maybe) that is executed when finished "uploading" into the PSP's RAM.
This pice of code is then the "real disaster recovery program" that initiates the USB port and allows to flash the flash0:/ from the USB port (by redirecting/forwarding the data arriving on the USB into the internal flash memory)
Maybe that "flashed over USB" firmware isn't even in file format but a raw byte-by-byte dump that's written back to the NAND flash....
This is how it's done on most integrated devices, like MP3 players.
[edit]
This way it also works if the FW update fails right after the format/erasing of the flash0:/ (so there's absolutely NOTHING to execute from there) and also leaves absolutaly NO hint to it in the actual firmware!
So walking through the .PRXs would reveal nothing about the disaster recovery, what might be the reason why we didn't find a thing so far....
Our focus was always the firmware itself.
But for recovery, you must take the FW itself out of the equasion.... IMHO....