known psp devices

[loser]

hiya

ive written a psp program to brute force test all io devices.
from what ive seen so far there seem to be 2 main types of devices:
"fat access" devices which provide file system access
"block access" devices which provide access to a big chunk or block of data

usually with fat access you need to open specific files, but with block access u just open the device itself, eg open("flash0:").
it seems some block devices are seekable, while others arent.
i havent played with these devices yet, but hope to later. maybe some others would like to jump and and find out more about them.

ill post to this thread as i come accross them.
if anyone knows of others please also post.


these were found by nemnem:
flash0: - fat access - system file volume
flash1: - fat access - configuration file volume



these were found by my program:

ms0: - fat access - memcard
umd: - block access - umd
irda: - block access - infra-red port (doesnt support seeking, maybe send/recieve data from port tho)
mscm: - block access - memstick cm??
umd0: fat access - umd
umd1: block access - umd
umd2: error 0x80010013
umd3: error 0x80010013
umd4: error 0x80010013
umd5: error 0x80010013
umd6: error 0x80010013
umd7: error 0x80010013
umd8: error 0x8001B002
umd9: error 0x8001B002


im not sure what the errors 0x80010013 and 0x8001B002 are.
anyone got any ideas?

ill add more as i have time to run my scanning program
(if it finds any more of course)


PLEASE keep this thread concise and easy to read.
DONT post comments etc, only post if you are mentioning a new device

[CybBlade]

i find some nice things in wipeout boot.bin name and example

host0:
host0:DVD\USRDIR\FE.wad
file://host0:/www/index.htm

fatms0:
fatms0:\PSP\SAVEDATA\

disc0:
disc0:\PSP_GAME\USRDIR\.wad

mscmhc0:
another name for ms0:

[loser]

it seems there is a way of assigning a device name similar to the ps2's AddDrv function. wipeout shows funcs that assign "umd:", "wad:" and "ms:" to other files on the memcard and disc. for this reason a search through files is not enough to give real device names. if you find a device name in this way, then check it n your own program without having that game (and therefore its fake drives loaded)

i have tested all device names up to 5 characters in length (testing of 6 character names will take 9 days, so it'll be a while before they are done testing. and 7 character names would take a year. so i wont bother with them or any longer names) so if you have found a devicename that is 5 characters or less, and its not in this thread, then chances are its a fake name.

in reference to CybBlades post:
"host0:" and "disc0:" seem to be fake as is "wad:" which is also used in wipeout.


fatms: fat access to memstick
isofs: fat access to umd
irda?: block access to irda port (doesnt support seeking), (? = any number - 0-9)
mscm0: block access to memstick (doesnt support seeking)
mscm?: error 0x80220081 (? = any number - 1-9)
umd00: block access to umd
umd01: block access to umd
umd0?: error 0x80010013 (? = any number 2-7)
umd??: error 0x8001B002 (?? = any number 08-99)

[loser]

well seems my brute force device name checker paid off big time!!
it found exactly what i was looking for :)

lflash:

this give you block access to the flash, the full 32meg of it!
btw thanks to mrbrown for realising that a blocksize of 512byte multiples is needed when reading from it.

w00t!

it also opens the device with read/write access, so who wants to test write capabilities? :)

[MelGibson]

thats really nice info.... wonder if you can see more of the OS now then compared to flash0 / flash1 access

[MindWall]

nice =)

did you check?:
prfat0:
msstor0p0:
msstor0p1:

[mrbrown]

I think a listing of native devices is good enough to be stickied.

[zigzag]

So, now we can extract the firmware easily I take it -- just read the entire contents of lflash to a file. But flashing a 1.5 is still a ways off unfortunately as we can't run any code to perform the flash and it looks like its impossible to tweak a Sony update to include our own flash :(

[pedroleite]

So, now we can extract the firmware easily I take it -- just read the entire contents of lflash to a file. But flashing a 1.5 is still a ways off unfortunately as we can't run any code to perform the flash and it looks like its impossible to tweak a Sony update to include our own flash :(

On the PSP Exploit forum, there's the java dissamble code from the Wipeout files downloader Jar...

I have got around the JAR a couple of minutes and there's an Internal Key... and the seed at the bottom of the file. This is used in a XOR stream cipher, a block one, based on SHA1...

What it does from reading the code is, calculate the SHA1 from the seed (last 20 bytes) and the internal key, this is placed internally.
Then each byte read for the actual data is XOR with a byte from this digest...
After consuming the digest, the calculated value + the internal key is SHA1'ed again to produce a new digest value... to be xored some more.

Code: Select all

public synchronized class SHA1CipherStream
{
    private static final byte INTERNAL_KEY[] = Util.parseBytes("D3C64E430B3F2C1152DBFEF1A5C71CA4");
    private byte internalKey[];
    MessageDigest digest;
    byte buffer[];
    byte seed[];
    int bufferOffset;

    static 
    {
    }

    public SHA1CipherStream(byte seed[])
    {
        this(seed, INTERNAL_KEY);
    }

    public SHA1CipherStream(byte seed[], byte internalKey[])
    {
        this.seed = seed;
        this.internalKey = internalKey;
        digest = Util.getDigest();
        if (digest == null)
            throw new NullPointerException("SHA-1 not set");
        digest.update(this.seed);
        digest.update(this.internalKey);
        buffer = digest.digest();
        bufferOffset = 0;
    }

    public void xor(byte buffer[])
    {
        xor(buffer, 0, buffer.length);
    }

    public void xor(byte buffer[], int offset, int length)
    {
        int i;
        i = 0;
        expression buffer
        expression offset + i
        dup 2 over 0
        push []
        expression (byte)(read() & 255)
        ^
        convert W to B
        pop []
        i++;
        if &#40;i < length&#41; goto 6 else 34;
    &#125;

    public int read&#40;&#41;
    &#123;
        if &#40;bufferOffset >= buffer.length&#41;
        &#123;
            digest.reset&#40;&#41;;
            digest.update&#40;buffer&#41;;
            digest.update&#40;internalKey&#41;;
            buffer = digest.digest&#40;&#41;;
            bufferOffset %= buffer.length;
        &#125;
        int value = buffer&#91;bufferOffset&#93;;
        bufferOffset++;
        return value;
    &#125;
&#125;

What I could ask ... Does any section of your firmware, has this key and probably others?

Anyone care to try this method on PSAR ou ~PSP formats?

[loser]

i tried all known devices with all known prefixes and suffixes.
eg "ms" with "fat" and "stor" added to front and back etc.
there is always the possibility that a module may need to be loaded to gain access to particular device, but i have tried these 'as is' with no extra modules loaded. (i havent been able to find any kind of usb device, or remote control/serial, or wifi as yet. ive tried all the obvious names i could think of for them)

(? = any number, i tested 0 to 100)
prfat and prfat? do not open, so arent native devices
msstor and msstor0 open ok (they seem to give block accces to memstick? read was successful, but i havaent checked what i got in the read buffer)

here are some more that opened ok:
flash0: FAT
flash1: FAT
flashfat: FAT
flashfat0: FAT
flashfat1: FAT
lflash: BLOCK R | W
lflash?: BLOCK R | W
ms0: FAT
mscm: BLOCK R | W
mscm0: BLOCK R | W
mscmhc: BLOCK R | W
mscmhc0: BLOCK R | W
msstor: BLOCK R | W
msstor0: BLOCK R | W
fatms: FAT
fatms?: FAT
irda: BLOCK R | W
irda?: BLOCK R | W
isofs: FAT
isofs0: FAT
isofs1: FAT
isofs2: ERROR 80020199
isofs3: turns off psp when i try to open this!!
umd: BLOCK R
umd0: FAT
umd1: BLOCK R


i havent looked closely at actually accessing most devices, so 'FAT' or 'BLOCK' device types are based on error codes that i seemed to get for other known fat/block devices. there may even be some other kind of device, like for just sending ioctl/devctl commands (ala ps2).

i still havent finished scanning thru all 6 character devicenames (seems it will take a month to do so, and im about a third of the way thru so far)
i will finish scanning for 6 character names, but wont bother with 7 character names, as it will take much much too long. besides i found the main device i was after ;)

[Vampire]

lflash:
and
lflash?: (? = any number)
are identical

blocksize: 512

[Vampire]

flash0:
and
flashfat:
and
flashfat0:
are identical

flash1:
and
flashfat1:
are identical

[Vampire]

irda:
and
irda?: (? = any number)
are identical

blocksize: any

[Vampire]

msstor:
and
msstor0:
are identical

blocksize: 512

[Vampire]

fatms:
and
fatms0:
and
ms0:
are identical

[Vampire]

msstor: and msstor0: is the entire physical disk (the hole disk: mbr,partition1,...)

msstor0p1: is partition1

...

of the memory stick

[Vampire]

isofs:
and
isofs0:
are identical

[0xdeadface]

Vampire,

Care to disclose (or even hint) how you figured this out?

0xdf

[Marco_N]

host0: can also be found in Gretzky NHL;

disc0:/PSP_GAME/USRDIR/browser/hsbrowser.prx
and then
host0:browser/hsbrowser-host.prx

is it possible host0: uses some generic code supplied by sony for network access?

[mrbrown]

host: does not exist in consumer PSPs.

[Vampire]

umd:
and
umd0:
and
umd1:
are identical

blocksize: 2048

[Vampire]

lflash0:0,0
lflash0:0,1
...

[mrbrown]

lflash0:0,0
lflash0:0,1
...

Don't you want to explain what they do? lflash0:0,0 is logical partition 0 (normally mapped to flash0), lflash0:0,1 is logical partition 1 (flash1), etc.

[Vampire]

Don't you want to explain what they do?

well, i thought it was pretty obvious...

[mph2]

host0: can also be found in Gretzky NHL;

disc0:/PSP_GAME/USRDIR/browser/hsbrowser.prx
and then
host0:browser/hsbrowser-host.prx

is it possible host0: uses some generic code supplied by sony for network access?

I think disc0: is the name given in sceIoAssign function for access umd0:

[MindWall]

I was wondering why the ipl:/ in not in the list?
could the bruteforce search have missed it?

[PspPet]

> I was wondering why the ipl:/ in not in the list?
"ipl" doesn't appear to be a real device. It is a special case in the version 2.00 updater (not present in earlier updaters).
[in a dissembly, search for a strncmp-like call with the r5="ipl", r6=3]

[MindWall]

I haven't had time to look at it, but from your words it looks a lot like the kbooti.bin

remember that some of the modules are not accessible through the usual device accesses, I guess the ipl: should be assigned to the "restricted" section of the flash?

[pyrosama]

flashfat2:
flashfat3:

FATFMT (Not device. Used as mount at start of .rodata)