psp-dev have released their exploit for ver. 1.5
That's because it's statistically bound to happen when people arbitrarily pick from a number of threads with essentially the same topic. People don't know which one is more appropriate so they'll just pick one. It is haphazard and silly. It's far better to have one thread on a topic, period. All the information you need you will find in one place - makes sense and I applaud the moderators for doing just that.MarfPSP wrote:I often find reading through duplicated posts on other forums that you can get tidbits of other information from them.
to F9zDark:
it wont work. even a simple program like hello world. if i where you i would wait for a dead pixel or something to go wrong with it, and exchange it for another psp with 1.5. thats if you got store waranty.
it wont work. even a simple program like hello world. if i where you i would wait for a dead pixel or something to go wrong with it, and exchange it for another psp with 1.5. thats if you got store waranty.
There are 10 types of people in the world: Those who understand binary, and those who don't...
I actually have quite a few dead pixels... I might do just that.
If they don't have an exchange available, the nearby store has a refurb PSP for I think 100 bucks. I can ask them to check the system information before I buy it, if its 1.5 I can buy away :)
**Added**
I just feel so stupid for updating... Its obvious that the security fix was meant to address this hack specifically.
If they don't have an exchange available, the nearby store has a refurb PSP for I think 100 bucks. I can ask them to check the system information before I buy it, if its 1.5 I can buy away :)
**Added**
I just feel so stupid for updating... Its obvious that the security fix was meant to address this hack specifically.
PSP-DEV released the only one MS exploit:
http://putoamo.addr.com/index2.html
http://web.icoiig.es/ubalda/index2.html
No PBP in PBP, only a % in the directory name!!!!!!
http://putoamo.addr.com/index2.html
http://web.icoiig.es/ubalda/index2.html
No PBP in PBP, only a % in the directory name!!!!!!
apperantly you don't need a canon to kill a musquito!... who knew?!
and it's (at first glance) the same exploit, but they used a second system hole with directory name recognition.
first one (directory) with the "%" gets executed the "loader" and authoring process passes on only the directory minus the unrecognized "%" for execution.
kudos to the youth =)
and it's (at first glance) the same exploit, but they used a second system hole with directory name recognition.
first one (directory) with the "%" gets executed the "loader" and authoring process passes on only the directory minus the unrecognized "%" for execution.
kudos to the youth =)
if it is a bug in path parsing, I can't imagine how sony made such an obvious and stupid error(Just can't imagine, maybe it really is a bug. If anyone know how such an error is likely to occur while writing code, please tell people here).Arjan wrote:the logic behind it is that there's a bug in the path parsing somewhere.
I could've found this if I tried to experiment more with the paths too :P (I bet it'll work with other characters too)
At my first thought, it looks like some kind of system back door(don't know what it is for and done nothing to test yet).
Come on, Sony was the company that released the 1.0 PSPs that had absolutely no necessity for encryption/signature reading, thus allowing homebrew code without hinderance...konfig wrote:if it is a bug in path parsing, I can't imagine how sony made such an obvious and stupid error(Just can't imagine, maybe it really is a bug. If anyone know how such an error is likely to occur while writing code, please tell people here).Arjan wrote:the logic behind it is that there's a bug in the path parsing somewhere.
I could've found this if I tried to experiment more with the paths too :P (I bet it'll work with other characters too)
At my first thought, it looks like some kind of system back door(don't know what it is for and done nothing to test yet).
This would also explain the 1.52 update, unless this problem is addressed in the 1.51 update, I hope it isn't .
ah indeed, I didn't think of that before :) It was just my guess though, I could also say % is used to pass arguments to the app.. Pure speculation though..
After some toying around, I found out that the percent mark can be put anywhere in the application directory name (not in any other dir name, PSP\%GAME\APP won't work). You can also put multiple percent marks in the directory name, as long as they're not adjecent.
After some toying around, I found out that the percent mark can be put anywhere in the application directory name (not in any other dir name, PSP\%GAME\APP won't work). You can also put multiple percent marks in the directory name, as long as they're not adjecent.
Well, I tried this version of the exploit on my 1.51 PSP, and it gave me an error "The game cannot be started (80020148)". Perhaps a different character than % might work on 1.51? Or do you think they'll have closed this hole entirely?F9zDark wrote:Come on, Sony was the company that released the 1.0 PSPs that had absolutely no necessity for encryption/signature reading, thus allowing homebrew code without hinderance...konfig wrote:if it is a bug in path parsing, I can't imagine how sony made such an obvious and stupid error(Just can't imagine, maybe it really is a bug. If anyone know how such an error is likely to occur while writing code, please tell people here).Arjan wrote:the logic behind it is that there's a bug in the path parsing somewhere.
I could've found this if I tried to experiment more with the paths too :P (I bet it'll work with other characters too)
At my first thought, it looks like some kind of system back door(don't know what it is for and done nothing to test yet).
This would also explain the 1.52 update, unless this problem is addressed in the 1.51 update, I hope it isn't .
Dan Jackson
I'm curious as to why you're so sure about this? Granted, the existence of a "security fix" in 1.52 points to a hole in 1.51, but it doesn't seem likely that it'd be the same one...? Unless they thought they'd fixed it, but found that they hadn't and had to fix it again?Nick Fury wrote:I'm thinking they didn't fix this error for 1.51
I'm at work currently but when I get home I'll be sure to play around with every special character I can. This has to work for 1.51.
Dan Jackson
Call it instinct. Either way I'm dreaming right now and won't know until I get home to test some things.Danj wrote: I'm curious as to why you're so sure about this? Granted, the existence of a "security fix" in 1.52 points to a hole in 1.51, but it doesn't seem likely that it'd be the same one...? Unless they thought they'd fixed it, but found that they hadn't and had to fix it again?
So while I'm at it... I would really like to see a firmware hack for this device. I think until that is done Sony is going to continuously release updates and force us to use them with all of their new games.
Anyway, I'll play with this when I get home... back to work.
It could be related to the formatting characters used by functions like sprintf and printf. It's a fairly easy mistake to make. if you say something like sprintf(outbuffer, inbuffer) when you really mean sprintf(outbuffer, "%s", inbuffer) you can run in to issues with %'s in the inbuffer being interpretated as a formatting directive.Arjan wrote:ah indeed, I didn't think of that before :) It was just my guess though, I could also say % is used to pass arguments to the app.. Pure speculation though..
After some toying around, I found out that the percent mark can be put anywhere in the application directory name (not in any other dir name, PSP\%GAME\APP won't work). You can also put multiple percent marks in the directory name, as long as they're not adjecent.
That could also explain why %% would not work, because %% is the directive for for a single %.
I decided to try and test the theory that this is some sort of printf-format related bug, and also to see if I could find a method that would work on 1.51 firmware. To that end, I used the KXploit tool with the precompiled Hello World program to create the two directories. I decided to choose a printf format code which would most likely produce anomalous output, and consequently I picked %p which is apparently intended for pointers. I then renamed my HELLOPSP% folder to HELLOPS%p. Upon attempting to run the loader on the PSP, I get a different error number than before, this time it is 80010002. I then tried %n which according to the man page I found should output the number of characters written so far. I changed the names of my folders to HELLOPS%n and HELLOPS7 respectively. This caused rather more spectacular results; the PSP froze in the menu screen and then after a couple of seconds turned itself off. Fortunately the PSP seems to be okay once I turned it back on. I've also tried a few different characters other than % (such as # and ~) but they just seem to result in the 80010002 error.
Dan Jackson
Nice. That is almost certainly a classic format string bug. %n does not cause output; it stores a value to the address pointed to by the next argument, which would definitely explain the crash. Does this work on both 1.51 and 1.52? It's definitely a strong possibility for exploit, but it's made a bit more difficult because we can't see the output of the format string. (it would be nearly trivial if we could see what %p got written as...)Danj wrote: I then tried %n which according to the man page I found should output the number of characters written so far. I changed the names of my folders to HELLOPS%n and HELLOPS7 respectively. This caused rather more spectacular results; the PSP froze in the menu screen and then after a couple of seconds turned itself off.
Got a 1.50 PSP today, tried the Kxploit and it works fine. One qualm I have with it is the fact that the PSP shows the corrupt data and since the exploit includes its own image in the EBOOT.PBP file it creates, its rather annoying trying to find which game is which.(not to mention the corrupt data appearing on there disorganizes everything.)
Other than that it works wonders.
Other than that it works wonders.
LiquidIce wrote:It seems to order apps by the date they were transfered to the memory stick. Is there any way to modify this date so directories without the % get marked in the past to put them on the bottom of the list?
Code: Select all
touch *; touch -d yesterday *%
As far as I know, a simple way to do this on a Windows box (if you don't have cygwin/touch/etc.) would be to simply rename the '%' directories, and then rename them back to their original name -- this would change the modified date to the current date, thus placing it at the top of the list.LiquidIce wrote:It seems to order apps by the date they were transfered to the memory stick. Is there any way to modify this date so directories without the % get marked in the past to put them on the bottom of the list?
Make sense?
I haven't tested this and could be talking out my ass, if so, please disregard.
EDIT: Didn't work and evidently my version of XP Pro is missing touch, so I found a Windows9x/NT/2K/XP version available here: http://www.codeproject.com/tools/touch_win.asp
Last edited by n1ckn4m3 on Thu Jun 23, 2005 10:07 am, edited 2 times in total.
... anyone up for some l33th4x?
;)
;)