If anyone has the bogus firmware update for the psp, can they PLEASE email me or post a link or something.
email: lmucmsimike@gmail.com
aim: lmucmsimike
My team and I (well, 2 of us total) took on the semester project of getting Linux up and running on the PSP. We are in search of the bogus firmware update because it's the only KNOWN program that you can put into your games directory and get it to execute. We'd like to dissect this and see what makes it tick.
So if you or if someone you know knows about it, please help!
Thanks
PS. We do NOT plan on installing this. Just seeing how it works. Please help!
I am in need of the bogus firmware update for PSP
-
LMUCMSIMike
- Posts: 9
- Joined: Wed Mar 23, 2005 11:22 am
- Location: Los Angeles
- Contact:
I am in need of the bogus firmware update for PSP
Check out the progress of putting Linux on the PSP
-
SinisterWhisper
- Posts: 4
- Joined: Sat Mar 19, 2005 12:15 pm
-
LMUCMSIMike
- Posts: 9
- Joined: Wed Mar 23, 2005 11:22 am
- Location: Los Angeles
- Contact:
adsf
thanks all for the replies. i found it on psphacks.net
just like 3 seconds before i got the email notification of the replies.
analyzing the files now...
just like 3 seconds before i got the email notification of the replies.
analyzing the files now...
Check out the progress of putting Linux on the PSP
-
LMUCMSIMike
- Posts: 9
- Joined: Wed Mar 23, 2005 11:22 am
- Location: Los Angeles
- Contact:
asdf
arent you the guy that installed the firmware first?ooPo wrote:You, sir, are going to fail.
I certainly wouldn't put my marks on the line to do something like this with no knowedge of what's involved beforehand.
That said, I wish you luck and I'll send you the bogus file. :)
(edit: looks like someone beat me to it while I was posting... oh well)
mind if i hit u up on aim? (if you have that)
Check out the progress of putting Linux on the PSP
-
LMUCMSIMike
- Posts: 9
- Joined: Wed Mar 23, 2005 11:22 am
- Location: Los Angeles
- Contact:
anything other than freenode is blocked from within the lab for now. im going to have to wait for the admin to come in and for him to add it.ooPo wrote:I'm more of an msn kinda guy myself.
Although I'm much easier to reach on irc. Come to #ps2dev on efnet and ask my secretary, Drakonite, if I'm in.
whats your msn? if you dont mind giving that out
Check out the progress of putting Linux on the PSP
A good portion of the analyzing has already been done. You should look through this forum to see how far we've gotten. Currently, we're up against a nice block of encryption. We don't even know what kind of encryption it is, nor do we know any of the keys required to de-encrypt it. Rumours say it could be AES, since the PSP includes the RSA BSAFE library (although the Nintendo DS does too -- but it uses it for encrypting the wireless communication).LMUCMSIMike wrote:analyzing the files now...
I'm still poking at it myself (see the .psp thread here), but have been backed up with work this past week that I haven't been able to do anything.
One thing everyone seems to forget (or not understand in the first place) is that there are many possible ways to get the PSP to execute code. The problem is, what the hell do you tell it to do? We have no idea what any of the registers are, or what the memory map is... so even if it did run our code, it sure wouldn't do a whole lot because we don't know how to make it draw a dot on the screen! Getting past this means we have to dissassemble existing code to see how it works (the only current thing we have is the ROM update, and it's encrypted), or have someone with an official SDK leak some information (probably what will end up happening anyway).
I wish you luck, but I don't think you're going to accomplish it in the time frame you've given yourselves. :)
-
LMUCMSIMike
- Posts: 9
- Joined: Wed Mar 23, 2005 11:22 am
- Location: Los Angeles
- Contact:
compiling code
It is a mips processor, with the mips32 instruction set, and mips processors are the 'same' all across the board.
i've got a cross compiler up and running, and if you do a
./mips-gcc -S try.c
(where a try.c is nothing more than just
int main(){return 0;}
you get a nice bit of assembly to play around with. my guess is that you can find some sort of assembly reference online.
i downloaded a pdf document called "everything you ever wanted to know about the mips r4000" (or something like that) but like an idiot i didnt open it and now my laptop is all packed up until tomorrow. i'll post back if something is in there
and what people are missing about the files (esp the firmware update) is that, through statistical analysis, we determined that, yes it COULD be encrypted. but at the same time, it COULD be just compressed weirdly. there was an unGodly amount of 00 as compaired to other numbers from 01-255 (about 10000 more than the highest one)
basically, for every byte between 01-255 (01h-FFh) appeared between 42k-46k
00 appeared ~56k times
[i analyzed the ~10 meg file that came with the firmware, UNKNOWN.PSAF or something like that]
i dont know much about encryption algos, but i did study compression algos and its a typical behavior that [at least] ONE byte as to increase and the rest decrease.
but keep in mind, im not saying its NOT encrypted. it could be a combo of the 2.
also, keep in mind that, it would make sense that there is just ONE shared key among all PSPs
now we wont be able to get anything disassembled until we can decrypt it (as im sure all of you know)
i've got a cross compiler up and running, and if you do a
./mips-gcc -S try.c
(where a try.c is nothing more than just
int main(){return 0;}
you get a nice bit of assembly to play around with. my guess is that you can find some sort of assembly reference online.
i downloaded a pdf document called "everything you ever wanted to know about the mips r4000" (or something like that) but like an idiot i didnt open it and now my laptop is all packed up until tomorrow. i'll post back if something is in there
and what people are missing about the files (esp the firmware update) is that, through statistical analysis, we determined that, yes it COULD be encrypted. but at the same time, it COULD be just compressed weirdly. there was an unGodly amount of 00 as compaired to other numbers from 01-255 (about 10000 more than the highest one)
basically, for every byte between 01-255 (01h-FFh) appeared between 42k-46k
00 appeared ~56k times
[i analyzed the ~10 meg file that came with the firmware, UNKNOWN.PSAF or something like that]
i dont know much about encryption algos, but i did study compression algos and its a typical behavior that [at least] ONE byte as to increase and the rest decrease.
but keep in mind, im not saying its NOT encrypted. it could be a combo of the 2.
also, keep in mind that, it would make sense that there is just ONE shared key among all PSPs
now we wont be able to get anything disassembled until we can decrypt it (as im sure all of you know)
Check out the progress of putting Linux on the PSP
-
LMUCMSIMike
- Posts: 9
- Joined: Wed Mar 23, 2005 11:22 am
- Location: Los Angeles
- Contact:
i forgot to mention
the data.bin files in saved game dirs dont SEEM to be encrypted or compressed...
as of right now, the only chance i see me and my parter having at getting into the PSP is somehow through the saved games
the data.bin files in saved game dirs dont SEEM to be encrypted or compressed...
as of right now, the only chance i see me and my parter having at getting into the PSP is somehow through the saved games
Check out the progress of putting Linux on the PSP
-
florinsasu
- Posts: 47
- Joined: Wed Dec 15, 2004 4:23 am
As ooPo said, you are going to fail.
For that project you'll need the sdk, no doubt! You or some ppl here will search in vain that firmware update for any info you might use.
So just go quick and ask to change the project, this time go for something that you can do.
[Remember: this does nothing to do with you, i don't even know u.]
For that project you'll need the sdk, no doubt! You or some ppl here will search in vain that firmware update for any info you might use.
So just go quick and ask to change the project, this time go for something that you can do.
[Remember: this does nothing to do with you, i don't even know u.]
Linux on PSP
For what I've read I think linux developers involved in PSP have been very very very optimistic in terms of what they will be able to do with PSP. It's just my point of view, but I think that sony has done things well (in terms of security) and if they don't decide to share some information or perhaps some special features in firmware it will be impossible or nearly impossible to run a linux or even homebrew software on it. Everything involving code execution seems encrypted so It might be quite difficult to do anything useful.
I repeat, It's just my opinion and I really would like to encourage people doing some dev (as I do), but I think we must know what we are facing and SCE has not been very kind with homebrew or Linux comunities in the past... So I would guess that a Linux running on a PSP would spend at least a pair of years of developement...
I repeat, It's just my opinion and I really would like to encourage people doing some dev (as I do), but I think we must know what we are facing and SCE has not been very kind with homebrew or Linux comunities in the past... So I would guess that a Linux running on a PSP would spend at least a pair of years of developement...
-
LMUCMSIMike
- Posts: 9
- Joined: Wed Mar 23, 2005 11:22 am
- Location: Los Angeles
- Contact:
yea, we kind of hit that wall last night, but i do feel our best bet right now somehow is in the way saved games workflorinsasu wrote:As ooPo said, you are going to fail.
For that project you'll need the sdk, no doubt! You or some ppl here will search in vain that firmware update for any info you might use.
So just go quick and ask to change the project, this time go for something that you can do.
[Remember: this does nothing to do with you, i don't even know u.]
Check out the progress of putting Linux on the PSP
Binaries: CryptedLMUCMSIMike wrote: yea, we kind of hit that wall last night, but i do feel our best bet right now somehow is in the way saved games work
UMD: Crypted
Wlan: Crypted
SaveGames: Crypted
In short words: Everything that's communicating with the outside world is crypted. No decryption key = no communication = no homebrew code.
Hack the encryption first, then talk about "tux on psp".
Mkay ?
-
Guest
Y'all are really jumping too far ahead on this one with respect to Tux. I think mrbrown voiced this already but this should be obvious.
First of all, unless we hope for sloppiness on Sony's part, and under the assumption that AES is the crypto, focusing on the encryption is not the best place for energies. Understanding where the encryption is used, and where it isn't, and all related file formats - yes; attacking the crypto itself - no.
Second of all, lets pretend a way is discovered to run code. I think mrbrown already addressed this, as well as others, but I will repeat it again with implications - once code can be run, Tux is *still* very far away.
Why?
Because, without a knowledge of the hardware devices, registers, memory maps, etc... there is no possibility for I/O.
Once code can run, one needs a way to get *output*. Whether its causing a beep, a flashing light, or incredibly lucky some screen output, one needs some way to know a code injection was successfully run, and return useful information.
Once that is accomplished to get any basic output, it is still a slow road to probing inside, finding all other hardware devices and how to communicate with them. Oh yes, people will still do it, just don't underestimate the effort.
In fact, homebrew without Tux will likely happen first, as the libraries and toolchains for straight homebrew, which also happen to be needed as a foundation for tux, are built.
First of all, unless we hope for sloppiness on Sony's part, and under the assumption that AES is the crypto, focusing on the encryption is not the best place for energies. Understanding where the encryption is used, and where it isn't, and all related file formats - yes; attacking the crypto itself - no.
Second of all, lets pretend a way is discovered to run code. I think mrbrown already addressed this, as well as others, but I will repeat it again with implications - once code can be run, Tux is *still* very far away.
Why?
Because, without a knowledge of the hardware devices, registers, memory maps, etc... there is no possibility for I/O.
Once code can run, one needs a way to get *output*. Whether its causing a beep, a flashing light, or incredibly lucky some screen output, one needs some way to know a code injection was successfully run, and return useful information.
Once that is accomplished to get any basic output, it is still a slow road to probing inside, finding all other hardware devices and how to communicate with them. Oh yes, people will still do it, just don't underestimate the effort.
In fact, homebrew without Tux will likely happen first, as the libraries and toolchains for straight homebrew, which also happen to be needed as a foundation for tux, are built.