2.0 - user space mode - syscall

[testereto]

Hello

I wonder if someone could tell me what are the addresses for each syscall when working in user space mode (instead kernel mode).

I'd like to develope some programs in my psp2.0 so any help will be appreciated.

Following code belongs to "flash-backup" which uses the new 2.0 exploit:

Code: Select all

// 0x208F,0x109f50bc,sceIoOpen
int sceIoOpen(char *name, int flags, int mode) {
// function args are readily in registers, so just do syscall --abu
  asm("syscall 0x208f");
}

Parameters and "long" (0x109f50bc) address could be obtained from http://pspdev.ofcode.com/api.php?type=4&id=893, I wonder where I can get the "short" (0x208F) one.

P.d: btw, sorry for my poor english ;)

[Chrighton]

For a specific <function>

printf("0x%x\n", *(u32 *)(<function>+4));

may work. You can always disassemble as well.

[PspPet]

> I wonder if someone could tell me what are the addresses for each syscall when working in user space mode (instead kernel mode).
FWIW: the syscalls are only for user space (they syscall is an implementation detail of the USER->SYSTEM switch)
The SYSCALL order is a side-effect of the entries being registered. The order may be different under 2.0 than 1.0/1.50.

TRY: printf("0x%x\n", *((u32 *)(<function>)+1) / 0x40)
BTW: SYSCALL opcode is the second (32bit) opcode in the library stub. The SYSCALL opcode is the syscall number * 0x40 + 0xc (0x208f * 0x40 + 0xc = 0x823cc)

That only works if the function has not been called. Once the function is called, the SYSCALL stub gets replaced with something else.
What you call the "long address" is really a "NID" (a SHA1 hash value). It is not the same thing and not directly mappable (system and user entries have NIDs, only user entries have SYSCALLs). The PSPSDK only supports the NID approach. The NID approach is version independent.
----
Here's my SYSCALL list:
http://www.aibohack.com/psp/syscall_expt1.txt
See warnings at top of file !!
Scraped from 1.0 firmware - not guaranteed to be the same as 2.0

[mrbrown]

That only works if the function has not been called. Once the function is called, the SYSCALL stub gets replaced with something else.

Er, the syscall stub only gets replaced on the first invocation if you're using late binding. If the kernel PRX you link into is already loaded, you will get the actual syscall number as soon as your program loads.

[groepaz]

i've compared the list from pspinside (v1.5 syscalls) with the one from psppet, see the result here: http://hitmen.c02.at/files/releases/psp/syscalls.txt

as you can see even between 1.0 and 1.5 a bunch are different... now it would be interisting to see a list of proofed working ones from 2.0 (or well, even extensions/corrections to the other two lists for that matter :))

[PspPet]

> i've compared the list from pspinside (v1.5 syscalls)...
Haven't seen that one. Please post a URL.

> as you can see even between 1.0 and 1.5 a bunch are different...
Not only the names, but also the order. The SYSCALL numbers are determined by the order. By the time you get to the Dcache entries the 1.0 syscall numbers are out of whack -- don't use that first list.

Here's an updated list using the 1.52 firmware (I can't experimentally confirm it on a 1.52, but should be closer to 1.50 and hopefully 2.0)
http://www.aibohack.com/psp/syscall_expt152.txt

[ZMaster]

Stupid questions: How do you get this information out of the PRX files? I thought they where encrypted?!? I actually can't disassemble them, or am I doing something wrong? Sorry for my noob-ness :-)

[groepaz]

i've made a better list ... http://hitmen.c02.at/files/releases/psp/syscalls.txt

@PspPet: the 1.50 list is in the config dir of pspinside, get it from our homepage at http://hitmen.c02.at/html/psp_releases.html

[testereto]

How did u get the syscall list for psp 2.0 flash-dump? by trial and error?

[testereto]

i've made a better list ... http://hitmen.c02.at/files/releases/psp/syscalls.txt

Btw, it seems there's something wrong in your list, look at this:

name nid v1.0 v1.5 v1.52 v2.0 comment
sceIoDopen |0xb29ddf9c|0x209b|0x209b|0x209b| |

syscall v1.0 v1.5 v1.52 v2.0
0x209a, sceIoDopen sceIoDopen sceIoDopen

And for v2.0, the list should have:

0x209B,0xb29ddf9c,sceIoDopen
0x209C,0xe3eb004c,sceIoDread
0x209D,0xeb092469,sceIoDclose

[groepaz]

hrm yes, the second list was bugged :=)

i've fixed the bug and generated it again....this time also showing which ones changed in the second list.... so redownload :)

[testereto]

hrm yes, the second list was bugged :=)

i've fixed the bug and generated it again....this time also showing which ones changed in the second list.... so redownload :)

Thx for ur effort :o)

[Saotome]

here are some more pretty usefull syscalls :)

0x2148, sceDisplaySetFrameBuf
0x2150, sceDisplayWaitVblank
0x2152, sceDisplayWaitVblankStart

and not tested, but probably these too:
0x2151, sceDisplayWaitVblankCB
0x2153, sceDisplayWaitVblankStartCB

[testereto]

here are some more pretty usefull syscalls :)

0x2148, sceDisplaySetFrameBuf
0x2150, sceDisplayWaitVblank
0x2152, sceDisplayWaitVblankStart

and not tested, but probably these too:
0x2151, sceDisplayWaitVblankCB
0x2153, sceDisplayWaitVblankStartCB

Thx, one question.. try&error to find them? ^^

[PspPet]

> 0x2148, sceDisplaySetFrameBuf
I assume that was found experimentally under 2.0 (the syscall number is greater than those on the earlier 1.0/1.5x)

Once you find one syscall in a module, you can guess that all the others will shift up in order. That's why the 1.52 list is only a starting point.
When the user export table of one system PRX grows, the syscall numbers of the later modules will increase (but typically the order will not). If they change the load order or add new user modules things may change more significantly.

Guess work and experimental confirmation needed (at least until we can decrypt 2.0 PRXs or at least grab the 2.0 kernel memory space)

Syscalls are very ugly for this reason. The best answer is to write a standard ELF loader so all other 2.0 programs can go back to using NIDs (like 1.0 and 1.50 homebrew)

[stefan]

Guess work and experimental confirmation needed (at least until we can decrypt 2.0 PRXs or at least grab the 2.0 kernel memory space)

Syscalls are very ugly for this reason. The best answer is to write a standard ELF loader so all other 2.0 programs can go back to using NIDs (like 1.0 and 1.50 homebrew)

No one wants to do the hard work :). I've mentioned before that all the NIDs->syscalls homebrew needs for 2.0 are already loaded in RAM. I would wager that 90% of what's in use by the majority of programs is imported by paf.prx (scePaf_Module).

I am currently collecting these from a RAM dump. I also want to work on a ELF loader that will resolve these, but first I need to secure a 2.0 PSP.

[Saotome]

Thx, one question.. try&error to find them? ^^

Exactly. I just put the args for the specific function into a0..a3 and increase (when new functions are added, most probably the syscall number will be higher ;)) the syscall number until I get the expected result :)

I think with that method I could have 50% of the syscalls until end of the day, but everytime I find a new interesting one I have to play with it until I get bored ;o)

[Vampire]

Guess work and experimental confirmation needed (at least until we can decrypt 2.0 PRXs or at least grab the 2.0 kernel memory space)

or until we find the decrypted 2.00 PRXs in the 2.00 user memory:

Code: Select all

0x09000000,"/kd/pspcnf_tbl.txt"
0x090001C0,"/kd/pspbtcnf.txt"
0x09000800,"/kd/sysmem.prx"
0x09014F00,"/kd/loadcore.prx"
0x0901F6C0,"/kd/exceptionman.prx"
0x09020540,"/kd/interruptman.prx"
0x09022E00,"/kd/sysclib.prx"
0x09024900,"/kd/threadman.prx"
0x09031040,"/kd/dmacman.prx"
0x09032A40,"/kd/systimer.prx"
0x09033580,"/kd/iofilemgr.prx"
0x09036800,"/kd/uart4.prx"
0x09037140,"/kd/stdio.prx"
0x09038300,"/kd/utils.prx"
0x0903A100,"/kd/memlmd.prx"
0x0903D500,"/kd/modulemgr.prx"
0x09040D40,"/kd/init.prx"
0x09042800,"/kd/sysreg.prx"
0x09043EC0,"/kd/gpio.prx"
0x09044BC0,"/kd/pwm.prx"
0x09045340,"/kd/i2c.prx"
0x09046480,"/kd/dmacplus.prx"
0x09048700,"/kd/lcdc.prx"
0x09049400,"/kd/emc_sm.prx"
0x0904B3C0,"/kd/emc_ddr.prx"
0x0904BD80,"/kd/ge.prx"
0x0904F700,"/kd/idstorage.prx"
0x090512C0,"/kd/syscon.prx"
0x09053B00,"/kd/rtc.prx"
0x09056880,"/kd/lfatfs.prx"
0x090601C0,"/kd/clockgen.prx"
0x09060C00,"/kd/codec.prx"
0x09061DC0,"/kd/audio.prx"
0x09064400,"/kd/display.prx"
0x09066680,"/kd/ctrl.prx"
0x09067E00,"/kd/loadexec.prx"
0x09077700,"/kd/mesg_led.prx"
0x0907CC40,"/kd/led.prx"
0x0907D600,"/kd/hpremote.prx"
0x0907F140,"/kd/power.prx"
0x09082C00,"/kd/mebooter.prx"
0x090C9540,"/kd/me_wrapper.prx"
0x090CC940,"/kd/usb.prx"
0x090D3DC0,"/kd/mediaman.prx"
0x090D4C80,"/kd/ata.prx"
0x090D7900,"/kd/umdman.prx"
0x090E17C0,"/kd/blkdev.prx"
0x090E2500,"/kd/umd9660.prx"
0x090E62C0,"/kd/isofs.prx"
0x090EAA00,"/kd/mscm.prx"
0x090EEBC0,"/kd/msstor.prx"
0x090F4340,"/kd/fatmsmod.prx"
0x0910F300,"/kd/wlan.prx"
0x0912D280,"/kd/registry.prx"
0x09131540,"/kd/mgr.prx"
0x09136680,"/kd/msaudio.prx"
0x0913A9C0,"/kd/semawm.prx"
0x091431C0,"/kd/peq.prx"
0x09143880,"/kd/vaudio.prx"
0x09144400,"/kd/mediasync.prx"
0x09146800,"/kd/utility.prx"
0x0914A800,"/kd/chkreg.prx"
0x0914BB40,"/kd/impose.prx"
0x09151B00,"/kd/vshbridge.prx"
0x09153080,"/vsh/module/chnnlsv.prx"
0x091555C0,"/kd/usersystemlib.prx"
0x09155A80,"/vsh/module/heaparea1.prx"
0x09156240,"/vsh/module/paf.prx"
0x092175C0,"/vsh/module/common_gui.prx"
0x09219900,"/vsh/module/common_util.prx"
0x0921C880,"/vsh/module/vshmain.prx"

[cheqmate]

here are 2 more tables i dumped today.
0000 means couldnt be resolved to syscall ( see above)

Code: Select all

nidDump v0.1

[NID]         [SYSC]  [NAME]
CA04A2B9      2000    sceKernelRegisterSubIntrHandler
D61E6961      2001    sceKernelReleaseSubIntrHandler
FB8E22EC      2002    sceKernelEnableSubIntr
6A638D83      2091    sceIoRead
42EC03AC      2093    sceIoWrite
27EB27B8      2095    sceIoLseek
63632449      2099    sceIoIoctl
ACE946E8      20A2    sceIoGetstat
54F5FB11      20A5    sceIoDevctl
810C4BC3      208D    sceIoClose
109F50BC      208F    sceIoOpen
977DE386      20D2    sceKernelLoadModule
50F0C1EC      20D6    sceKernelStartModule
D1FF982A      20D7    sceKernelStopModule
2E0911AA      20D8    sceKernelUnloadModule
446D8DE6      206D    sceKernelCreateThread
9FA03CD3      206E    sceKernelDeleteThread
F475845D      206F    sceKernelStartThread
AA73C935      2071    sceKernelExitThread
809CE29B      2072    sceKernelExitDeleteThread
383F7BCC      2074    sceKernelTerminateDeleteThread
3AD58B8C      2075    sceKernelSuspendDispatchThread
27E22EC2      2076    sceKernelResumeDispatchThread
293B45B8      207B    sceKernelGetThreadId
278C0DF5      201A    sceKernelWaitThreadEnd
CEADEB47      201C    sceKernelDelayThread
D6DA4BA1      2020    sceKernelCreateSema
28B6489C      2021    sceKernelDeleteSema
3F53E640      2022    sceKernelSignalSema
4E3A1105      2023    sceKernelWaitSema
58B1F937      2025    sceKernelPollSema
8FFDF9A2      2026    sceKernelCancelSema
55C20A00      2028    sceKernelCreateEventFlag
EF9E4C70      2029    sceKernelDeleteEventFlag
1FB15A32      202A    sceKernelSetEventFlag
812346E4      202B    sceKernelClearEventFlag
402FCF22      202C    sceKernelWaitEventFlag
30FD48F0      202E    sceKernelPollEventFlag
CD203292      202F    sceKernelCancelEventFlag
369ED59D      205A    sceKernelGetSystemTimeLow
79D1C3FA      20C6    sceKernelDcacheWritebackAll
3EE30821      20C8    sceKernelDcacheWritebackRange
61EB33F5      0000    sceAtracReleaseAtracID
7A20E7AF      0000    sceAtracSetDataAndGetID
6A8C3CD5      0000    sceAtracDecodeData
868120B5      0000    sceAtracSetLoopNum
136CAF51      212D    sceAudioOutputBlocking
E2D56B2D      212E    sceAudioOutputPanned
13F592BC      212F    sceAudioOutputPannedBlocking
5EC81C55      2130    sceAudioChReserve
6FC46853      2131    sceAudioChRelease
B011922F      2132    invalid
CB2E439E      2133    sceAudioSetChannelDataLen
95FD0C2D      2134    sceAudioChangeChannelConfig
B7E1D8E7      2135    sceAudioChangeChannelVolume
1F4011E6      2159    sceCtrlSetSamplingMode
DA6B76A1      215A    sceCtrlGetSamplingMode
1F803938      215D    sceCtrlReadBufferPositive
0E20F177      2142    sceDisplaySetMode
289D82FE      2148    sceDisplaySetFrameBuf
984C27E7      2152    sceDisplayWaitVblankStart
617F3FE6      20F0    sceDmacMemcpy
E47E40E4      20F3    sceGeEdramGetAddr
AB49E76A      20F9    sceGeListEnQueue
1C0D95A6      20FA    sceGeListEnQueueHead
E0D68148      20FC    sceGeListUpdateStallAddr
03444EB4      20FD    sceGeListSync
B287BD61      20FF    sceGeDrawSync
B448EC0D      2100    sceGeBreak
4C06E472      2101    sceGeContinue
40D2F9F0      2174    sceHprmReadLatch
21FF80E4      0000    sceMpegQueryStreamOffset
611E9E11      0000    sceMpegQueryStreamSize
C132E22F      0000    sceMpegQueryMemSize
D8C5F121      0000    sceMpegCreate
606A4649      0000    sceMpegDelete
42560F23      0000    sceMpegRegistStream
591A4AA2      0000    sceMpegUnRegistStream
A780CF7E      0000    sceMpegMallocAvcEsBuf
CEB870B1      0000    sceMpegFreeAvcEsBuf
F8DCB679      0000    sceMpegQueryAtracEsSize
167AFD9E      0000    sceMpegInitAu
FE246728      0000    sceMpegGetAvcAu
E1CE83A7      0000    sceMpegGetAtracAu
0E3C2E9D      0000    sceMpegAvcDecode
800C44DF      0000    sceMpegAtracDecode
D7A29F46      0000    sceMpegRingbufferQueryMemSize
37295ED8      0000    sceMpegRingbufferConstruct
13407F13      0000    sceMpegRingbufferDestruct
B240A59E      0000    sceMpegRingbufferPut
B5F6DC87      0000    sceMpegRingbufferAvailableSize
F50AAE41      0000    invalid
ACCE25B2      0000    invalid
3F7AD767      2105    sceRtcGetCurrentTick
4CFA57B0      210A    sceRtcGetCurrentClock
E7C27D1B      210B    sceRtcGetCurrentClockLocalTime
96 nids dumped.

[NID]           [SYSCALL Nr]
6A638D83      2091    sceIoRead
42EC03AC      2093    sceIoWrite
27EB27B8      2095    sceIoLseek
3AD58B8C      2075    sceKernelSuspendDispatchThread
27E22EC2      2076    sceKernelResumeDispatchThread
55C20A00      2028    sceKernelCreateEventFlag
EF9E4C70      2029    sceKernelDeleteEventFlag
1FB15A32      202A    sceKernelSetEventFlag
812346E4      202B    sceKernelClearEventFlag
402FCF22      202C    sceKernelWaitEventFlag
56C039B5      2043    sceKernelCreateVpl
89B3D48C      2044    sceKernelDeleteVpl
AF36D708      2047    sceKernelTryAllocateVpl
B736E9FF      2048    sceKernelFreeVpl
C9831AFF      0000    scePaf_Unkonow_c9831aff
5FAC9869      0000    scePaf_Unkonow_5fac9869
FCB4E053      0000    scePaf_Unkonow_fcb4e053
545FE2DA      0000    scePaf_Unkonow_545fe2da
7EC15225      0000    scePaf_Unkonow_7ec15225
FD4C9F47      0000    scePaf_Unkonow_fd4c9f47
F95EA3F1      0000    scePaf_Unkonow_f95ea3f1
6829D7AF      0000    scePaf_Unkonow_6829d7af
CA79D58B      0000    scePaf_Unkonow_ca79d58b
49A81B18      0000    scePaf_Unkonow_49a81b18
809A4F83      0000    scePaf_Unkonow_809a4f83
54AB18DD      0000    invalid
D6759EEF      0000    invalid
2CFAE498      0000    scePaf_Unkonow_2cfae498
58846DF3      0000    scePaf_Unkonow_58846df3
E357380E      0000    scePaf_Unkonow_e357380e
DB62C9CF      2193    scePowerCancelRequest
92E41280      21DC    sceReg_driver_Unkonow_92e41280
FA8A5739      21DD    sceReg_driver_Unkonow_fa8a5739
1D8A762E      21DF    sceReg_driver_Unkonow_1d8a762e
0CAE832B      21E0    sceReg_driver_Unkonow_0cae832b
39461B4D      21E1    sceReg_driver_Unkonow_39461b4d
0D69BF40      21E2    sceReg_driver_Unkonow_0d69bf40
17768E14      21E4    sceRegSetKeyValue
C5768D02      21EB    sceRegKickBackDiscover
30BE0259      21EC    sceReg_driver_Unkonow_30be0259
EADB1BD7      20EA    sceKernelPowerLock
3AEE7261      20EB    sceKernelPowerUnlock
09C39AF4      0000    invalid
43 nids dumped.

[ChaosKnight]

Very cool stuff with the syscalls.

Saotome - Any chance you will release some documentation on the single tif exploit? Or at least point me in that direction? Great job on the Pong by the way, looks like that syscall research is a lot of fun.

[groepaz]

i have updated the comparison table with the info from cheqmate.... its slowly becoming obvious which are the same as 1.52 and which have moved etc... :)

[Saotome]

ChaosKnight: actualy jonny2002 on the pspupdates forum did most of the tif work. I did the code. I've written a tool for PS2 that automaticaly inserts the code (compiled with the PS2 toolchain) into the tif-file. That means the tool and the psp code gets compiled from one c-file into one ELF file, I run it on my PS2 and it stores the tif file on my harddrive, then I just need to copy it on my psp :)
If you want to use the tif from the pong game, the code starts from pos 0x01c0 to end of file.

And yea, syscall research is fun, but downgrading and do some 1.50 developing is tempting as well ;)

groepaz:
found some more
0x21a1, scePowerGetBusClockFrequency
0x21a2, scePowerGetCpuClockFrequency
0x21a8, scePowerSetClockFrequency

[groepaz]

updatet again :)

[Fanjita]

Saotome, any chance you could help by releasing some snippets from the pong source?

I've been working on a tetris port, which is mostly working except I can't work out how you managed to read the key input. Everything I've tried with sceCtrl* has either crashed, or just not returned any data.

A few pointers on how you managed it would be really appreciated.

Thanks.

[Fanjita]

Of course I've tried disassembly, btw - but I'm having problems building pspdis (can't figure out how to get libintl into Cygwin :-( ) and ps2dis seems to give misleading results.

[PspPet]

Commentary / IMHO:
Probably not worth continuing down this path. The SYSCALL numbers are very version specific (and can vary depending on how a program loads additional library PRXs)

Thanks to the MPH/TIFF version tweek, I suspect everyone with a 1.51/1.52/2.0 PSP who wants to run homebrew will "downgrade" to version 1.50 [BTW: Good job to everyone involved]

The main appeal for homebrew 2.0 is exploiting 2.0 features (like new codecs and web browser) *AND* so you can stay on the track for future updates. However it is very likely the TIFF hole will be closed in any future 2.1 update from Sony. So the 2.0 TIFF hack will have a very short lifetime in the terms of homebrew expliots (long enough to "downgrade" to 1.50 that is ;-)

[Fanjita]

Surely it's worth getting homebrew working on the latest version, if it is at all possible?

Even if Sony decide to update the firmware again, it's better to have a 2.0 PSP than a 1.5 PSP, if the homebrew capability is the same.

The syscall interface doesn't seem like a huge barrier at the end of the day.


BTW, ignore my earlier request for help with source - I narrowed down my problem to invalid assumptions about register usage when compiling under the PSPSDK toolchain, and now my syscalls are all working fine.

[Saotome]

BTW, ignore my earlier request for help with source - I narrowed down my problem to invalid assumptions about register usage when compiling under the PSPSDK toolchain, and now my syscalls are all working fine.

I think the source code wouldn't be much better than disassembling it anyway, since it's written in pure assembly - very few comments - and I used just register as variables. But here it is anyway, maybe someone else is still interested.

[groepaz]

i agree with fanjita. hacking 2.0 will be all worth it and it has to be done imho. will be done anyway :=P

[cheqmate]

psppet: i think you're misunderstanding the purpose.
sure nid imports are much nicer, but to get there we need to use kernel functions somehow, dont we ?