Did anyone have the guts to....

[0xdeadface]

Aha, another theory, hopefully not as farfetched as some others, but feel free to flame me, after all I don't have the guts to try it out myself.

First off...has anyone had the courage to actually try to write to "lflash:"?

Because..

As is known, one of the prx's in the firmware dump is not encrypted, so it's likely that changing a byte in there wouldn't cause any checksum error.
So if you would change some unimportant char there (in a string I'd say) and call the function that you assume uses that string you knew it'd be possible to manipulate said prx file.

Why you'd want that?

Well, the prx is part of the kernel it seems. At least I hope it is.

We know the MIPS has a user mode and a kernel mode, and parts of memory can't be accessed in user mode, which can be accessed in kernel mode. So if you'd be able to inject your code in a prx that is running in kernel mode and thus have kernel mode access - you'd have made a huge leap.

All code that is run in kernel mode is apparently hiding behind a syscall (as far as I managed to figure out anyhow), so in order to get code running you'd either have to patch it into a kernel prx (which you won't be able to do from user mode) or find a buffer overrun in one of the syscall'ed functions. Worth a shot too to see if you can even get it to hang on a syscall, although you wouldn't know whether it was actually hanging because of a corrupted stack or a general exception without an installed exception handler, so that too is a bit tricky.

Hence the prx theory.....one unencrypted prx, if you *can* write it.......it *could* be the key.

Now if I were a hero, I'd fire up my dear 1.0 PSP and tried.

Unfortunately - I'm no hero at all.

So back to my original question.
Has anyone tried writing to "lflash:"?

0xdf

[Vampire]

has anyone had the courage to actually try to write to "lflash:"?

yes ;-)

[0xdeadface]

That's encouraging....maybe I _will_ sacrifice my 1.0 to test it out.....

~shudder~

Edited to say...wow, some guts of you to do that. -respect-

[Guest]

Vile rumour has it that one high profile dev'er lost his PSP to such an event just within the past weekend. ;) (not it wasn't me, one brick is enough :)

[0xdeadface]

Would you happen to know more details regarding what exactly he tried?
I am considering to give it a try, but I don't want to wreck my $500 toy (1.0's get scarce) if it's already been tried.
Do you know whether he just changed an innocent byte in a string, and not some random code or header byte? I could see the latter wreaking havoc if not done carefully, however changing a string byte would only cause trouble if the PSP actually stores and checks checksums of modules somewhere.

I would try not to change the size and no code at first. Only some char in some string and *if God has mercy* work from there....

0xdf

[Guest]

Not for me to discuss. But let me say this - unless you really really really know what you are doing at that point, chances are extremely good you will end up with a brick. Its an extremely unsafe thing to try at this point, even for experienced people.

[th0mas]

however changing a string byte would only cause trouble if the PSP actually stores and checks checksums of modules somewhere.

Ask yourself if you're willing to bet the farm on that one before trying anything, because most likely they are signed (imho.. so I'm not doing it, at least).

[0xdeadface]

I'm pretty sure they're not signed....well the one that's unencrypted anyhow. That doesn't mean tho that it's CRC isn't stored and checked elsewhere...that could be painful to say the least.

Not sure yet whether I fancy a Sony-style paperweight.

[mrbrown]

Would you happen to know more details regarding what exactly he tried?

The plan was to replace libatrac3plus.prx with one that dumped all of kernel memory (0x88000000-0x883fffff) to the memory stick. I picked libatrac3plus.prx because it seemed out of the way, and something that would only get used when the VSH played an .at3 (such as popping in a UMD). Because libatrac3plus.prx was stored unencrypted on the WO UMD, I knew all of the NIDs of the stubs that the VSH would import once libatrac3 was loaded. Note that my _start() routine consisted of checks designed to abort early if libatrac3 figured out it was not loaded in kernel mode. The actual dump code was tied to each one of the libatrac3 exports.

Because I'm not completely familiar with the PRX ELF format I chose a fixed address in RAM of 0x9e00000 to load the rogue libatrac3. It seems that this was my downfall.

After overwriting the encrypted libatrac3plus.prx in lflash with my own, I exited my "inject" program using the Home button back to the VSH. I popped in my WO UMD, and it loaded on the Game screen. There was no music, but the VSH didn't crash. It displayed the custom background and played the icon PMF normally.

I checked the memory stick and flash1 (where I had written a log file) and I didn't have a dump of kernel memory nor any logs. So I modified libatrac3 to have a clear indication of when it was called by adding a huge delay. Further attempts showed no change, which indicted to me that the clandestine libatrac3 wasn't being loaded at all. Hmm.

Note that during all of this I had help and guidance from nem who had successfully overwrote a different PRX (I won't go into details here). We both agreed that libatrac3 wasn't being loaded which is why there was no kernel dump and why the VSH didn't crash. Nem had observed a special set of module_info flags tied to the PRX that he had replaced. I noticed that my libatrac3 didn't have those flags.

I OR'd my libatrac3's flags with the ones nem mentioned, and reran the injecter. Lo and behold, when I exited back to the VSH, it crashed. Without me using a UMD at all. So it was the load address that killed it, but the special flags that allowed it to load.

My PSP now crashes on boot, during the boot splash animation. So it is possible to overwrite a kernel driver with your own, whether or not it's encrypted. It seems this is part of the same "flaw" in the 1.0 firmware that allows it to run plain ELFs in the first place. I do not recommend that anyone attempt to do this. If you are still insane enough to try it, you had better have a better understanding of relocatable PRX files than I did.

[steddy]

The plan was to replace libatrac3plus.prx with one that dumped all of kernel memory (0x88000000-0x883fffff) to the memory stick. I picked libatrac3plus.prx because it seemed out of the way, and something that would only get used when the VSH played an .at3 (such as popping in a UMD). Because libatrac3plus.prx was stored unencrypted on the WO UMD, I knew all of the NIDs of the stubs that the VSH would import once libatrac3 was loaded. Note that my _start() routine consisted of checks designed to abort early if libatrac3 figured out it was not loaded in kernel mode. The actual dump code was tied to each one of the libatrac3 exports

Wow, that was such a brave thing to do for the cause. Without such sacrifices its doubtful we could learn the answers we need.

If you can resurrect the device it may be worth trying to compile a PRX of your own and write a standard BIN to load it from inside a PBP. That way you could at least check the module loads and executes without affecting existing functionality. The PRX thread I started may help with this.

Steddy

[Warren]

You think that a usermode program is going to be able to load a module in kernel mode?

[steddy]

You think that a usermode program is going to be able to load a module in kernel mode?

That I don't know. But given that lots of kernel modules are also present on the UMD disks, I would GUESS that it can be loaded by both User and Kernel modules. Just a guess though.

Also, the Media Interface on the PSP (XMB) will not be running in Kernel mode.

[0xdeadface]

Actually, this does make me hopeful. At least I know a prx can be changed without locking up the system because of some sort of CRC check being done with an externally stored CRC.

As for whether user mode programs can enter kernel mode, no most likely not straight away, but if you'd manage to modify a prx that would be loaded in kernel space I think it would be able to access kernel data as it would be called through a syscall and thus be in kernel mode.

0xdf

[mrbrown]

If I made this too easy for you guys, then a friend of mine would kill me.

What's the difference between a PSP PRX file and a PSP ELF file?

[0xdeadface]

...apart from prx being relocatable not much I guess.

Trying to figure out the hint in that remark........

[_Psycho]

You can most likely send back your PSP to the store saying "it stopped working" send it back to sony, but they will probably reflash it with 1.51. Suck for that but at least you keep the device (hopefully).

Does nem has the ability / material whatever to write back the firmware the same way he did the dump ? Maybe he could rewrite that file for ya =P (Guessing to talked to him already, I probably mention that for nothing).

Nice stuff thought.

[Guest]

You can most likely send back your PSP to the store saying "it stopped working" send it back to sony, but they will probably reflash it with 1.51. Suck for that but at least you keep the device (hopefully).

Please do not sugggest people do unethical things. Okay ?
(any further tangential meanderings in this topic will begin a split-out to the off-topic forum...)

[Squall333]

Would the difference be that some PRX files are unencrypted and all ELf's are encrypted?

[steddy]

What's the difference between a PSP PRX file and a PSP ELF file?

The ELF is a standard portable file format for binaries in any form. I guess the question is what is the difference between a BIN and a PRX, both of which are ELF's.

My answer to that would be that a PRX exports functions and is the equivalent to a DLL in the windows world, whereas a BIN is the equivalent of an EXE. See this thread for the details on the format I have uncovered so far, which includes the Exported function details (bottom of sceResident or sceVstub).

http://forums.ps2dev.org/viewtopic.php?t=1949

I am pretty sure PRX files which are not utility functions to the XMB will have the exports in the sceResident section. XMB utility functions will proabably only export functions via sceVstub.

This is a good reference to ELF files:

http://www.muppetlabs.com/~breadbox/software/ELF.txt

Steddy

[0xdeadface]

So it is possible to overwrite a kernel driver with your own, whether or not it's encrypted.

mrbrown,
Are you saying it´s possible to replace an encrypted prx with an unencrypted one?

My plan was not to run my code in another game like WO, as you wouldn´t know what got called.
What I actually intended to do was to replace one function which I figured would be least likely to be called by Vsh code (to prevent a crash', and call the replaced routine from my own program through a stub. Wouldn´t have to worry about calling convention as my own code awaits.
I´d pass an adress from a routine in my own program and have the called function jump there again, but now hopefully in kernel mode.

That way I would have no problems with relocation as far as I can see.<
Whether I´ll have the guts still remains to be seen, but comments and or suggestions or flaws in my reasoning are welcome.

0xdf