starred/AnyPS5
1
0 Fork 0
mirror of https://github.com/boykopovar/AnyPS5.git synced 2026-10-22 08:33:12 -05:00
Code Issues Packages Projects Releases 3 Wiki Activity
Files
da54c652e30b59cdc54087e9c1fc9e46237964ca
AnyPS5/docs/dev/debt/libSceSystemService.md
T

35 KiB
Raw Blame History

libSceSystemService technical debt

Silent stubs

  • sceShellCoreUtilActivateAbort, sceShellCoreUtilActivateStart, sceShellCoreUtilActivateStartAsync, sceShellCoreUtilActivateTerm return zero with the recovered handle argument. Activation service state is not modeled.

  • libSceSystemService - sceSystemServicePowerTick, sceSystemServiceReportAbnormalTermination, sceSystemServiceDisableMusicPlayer, sceSystemServiceReenableMusicPlayer, sceSystemServiceDisableMediaPlay and sceSystemServiceReenableMediaPlay return success and do nothing: the host has no auto power-off timer to reset, no system crash reporter to notify, no system music player to pause or resume and no system media playback to disable. PPSA01521 calls sceSystemServiceDisableMediaPlay during start-up, and its wrappers for both pass no arguments

  • sceSystemServiceLaunchWebBrowser (libSceSystemService) - AnyPS5 launches no web browser, so the call fails and nothing is shown. RommPS PPSA76677 then tells the player to scan its QR code instead

  • sceSystemServiceShowControllerSettings (libSceSystemService) - returns success without showing the controller settings: AnyPS5 has no system UI to open. Cat Quest III (PPSA15065) imports it

  • sceSystemServiceShowDisplaySafeAreaSettings (libSceSystemService) - returns success without showing the display safe area settings dialog: AnyPS5 has no system UI to open. PPSA03332 imports it, and the no-argument signature is assumed: Orbital has sceSystemServiceShowControllerSettings but not this call

  • sceSystemServiceOpenChallengeActivity (libSceSystemService) - returns success without opening the challenge activity: AnyPS5 has no system UI to open. Cat Quest III (PPSA15065) imports it

  • sceSystemServiceOpenTournamentOccurrence (libSceSystemService) - returns success without opening the tournament occurrence: AnyPS5 has no system UI to open

Unknown function info

Functional

  • sceSystemServiceLoadExec (libSceSystemService) - besides "exit", it starts the title's own /app0/eboot.bin or another executable under /app0 that the relinker converted with --executable, which is looked up beside the running one (/app0/picker/picker.bin as picker.picker.bin with the running executable's extension). The main executable is the one APS5_EBOOT names, which the first call sets to its own path. After the guest shutdown the old process ends without running guest exit handlers or host destructors; as during exit, a guest thread that calls a library the shutdown has stopped waits for the end instead of unwinding. "exit" ends the process after the host shutdown without running the title's atexit and __cxa_atexit handlers, since the console's shell closes the title instead; a line the title writes just before through its own thread, such as a forwarded standard error line, may not be printed. VLC for PS5 (PPSA85300) relaunches itself with no arguments; RetroArch (PPSA99169) starts its frontend picker with {"", NULL}, and the picker starts eboot.bin with {"--ps5-mode=retroarch", NULL} or /app0/es-de/es-de.bin (picker.cpp), so the list holds only arguments. A list with a first entry becomes the whole guest argv, with no program name in front (LoadExec.cpp): a PS5 RetroArch console transcript records a restart with one argument entering with argc=1, argv[0]="--ps5-relaunch=1", and a launch from the home screen with argc=1, argv[0]="" (relaunch_ps5.cpp). For such a list Linux replaces the process with fexecve, and macOS with posix_spawn and POSIX_SPAWN_SETEXEC: the PID and the standard streams stay, the other descriptors are closed and the working directory becomes the executable's. Windows starts a suspended process that inherits only the standard streams and a handle of the old process, and its entry stub waits for the old process to end before it loads the title's libraries, so a shell or script that started the title sees it end. A null list or one without a first entry keeps the earlier launch: the new executable gets only its own path as its command line (CreateProcessW on Windows, execv on Linux and macOS), so its argv[0] is the host path, and the old process ends without waiting for it. What the console passes for such a list is not known, nor are its argument limits and error codes. Paths outside /app0 and unconverted executables throw

  • Running application ID (libSceSystemService) - sceSystemServiceGetAppIdOfRunningBigApp reports 1 as the running title's app ID. The value is AnyPS5's own: the console's shell assigns app IDs and their values are not known here, so other calls that take an app ID must use the same one. sceSystemServiceKillApp with that ID and the arguments -1, 0 and 0, which SwanStationPS5 passes to close itself and ps5-payload-dev's hbldr passes to close the running game, ends the title as its own exit(0) would: the guest's shutdown and atexit handlers run and the process exits with status 0. On the console the call returns and the shell then ends the title, and whether those handlers run there is unknown; here there is no shell, so the call does not return. Another app ID or other arguments throw.

  • sceLncUtilKillApp, sceLncUtilKillAppWithReason (libSceSystemService) - the running title's app ID ends the title as sceSystemServiceKillApp does, which SharpProspero describes as a wrapper of sceLncUtilKillApp; the signatures follow its launcher utility bindings. Another app ID throws, and so does a reason other than 0, whose meaning and effect on the console are not documented

  • LoadExec descriptors (libSceSystemService) - on Linux, a call with an argument list replaces the process with fexecve, which first closes every descriptor above 2, and on macOS with posix_spawn, which closes them through POSIX_SPAWN_CLOEXEC_DEFAULT; a call without one uses execv, and the guest's descriptors stay open across it. On both paths descriptor 2 first gets back the host standard error a guest redirect kept, so the runtime's output does not follow the title's redirect (RetroArch's trace file, VLC's log) into the next executable. Which descriptors the console passes to the new process is not known

  • LncUtil process and status payloads: local-process creation transmits a 72-byte parameter block whose fields remain unresolved. Title-ID output occupies 16 bytes; category output is a four-byte string, while category type and launched-user outputs are 32-bit scalars. The argument lists are recovered through the indirect dispatch targets rather than the decompiler's apparent zero-argument wrappers.

  • LncUtil event and diagnostic payloads: Daemon and shell-UI events are distinct output structures. GetDbgExecutablePath writes up to a 1024-byte protocol output and forwards a 64-bit selector whose meaning is unresolved. Boolean outputs and the two direct boolean budget/mode queries are confirmed.

  • LncUtil launch and lifecycle payloads: Flag values and service-side focus/resume/suspend/exception behavior remain unresolved. Launch and load-exec use null-terminated argument vectors; asynchronous launch/kill write a 32-bit request ID. The argument positions and transported widths are confirmed, but the service operations remain protected stubs.

  • ShellCoreUtil application data: GetAppLaunchTypeInfo writes eight bytes whose fields are unresolved. Application-data and launched-parameter keys are null-terminated strings, with 32-bit capacities/outputs. Format/fsck paths and mini-app return values are strings. File-formatting and service implementations remain protected stubs.

  • ShellCoreUtil queries: launched-parameter strings have signed 32-bit capacities; checker strings use machine-sized capacities and one or two string keys. Cloud status and device-index outputs are 32-bit scalars; the timeout variant consumes one byte. Partition-size output and the direct temporary-content free-size return are 64-bit. The service-side checker protocol remains unresolved. Device-index scene output uses a 32-bit native store despite the managed wrapper using a byte-backed scene enum; the native output width is preserved.

  • ShellCoreUtil storage and HID queries: partition free sizes and required application-content size are 64-bit outputs; fsck progress takes a title ID and a 32-bit progress output. HID string queries transport a 64-bit capacity and 32-bit selector, while output-vector lengths sign-extend the capacity's low 32 bits. HID selectors are configuration indices; the wrapper declares 32-bit capacities while the native code transports 64 bits, so their declared width remains unresolved. IDU mode byte values remain unresolved. Streaming status and the compositor-profiler return are boolean; the compositor-profiler and current GPU-load queries consume no caller arguments.

  • ShellCoreUtil account and privacy payloads: Pbtc user information occupies 800 bytes; privacy-event data occupies eight bytes after two string keys, each limited to 32 characters. The five account-information outputs occupy 8, 104, 136, 1024 and 1032 bytes; their fields remain unresolved. Category-default list output has a byte capacity and unresolved element format. Remote-play/share-play/social-screen outputs are boolean; application display-state queries take a 32-bit application ID. Only the support-site query signature is restored; no endpoint content is included.

  • ShellCoreUtil telemetry and user queries: telemetry-token output is 4112 bytes, including an eight-byte service result at offset 4104; its meaning remains unresolved. UI status is a 64-bit event mask; VM statistics and workaround-file strings use machine-sized capacities. Eye-distance adjustment writes one byte.

  • ShellCoreUtil launch and status arguments: Navigation consumes one 32-bit value, not the phantom vector/register arguments shown by decompilation. Workaround checks and mount requests take strings. Logout-state queries transmit two 32-bit values and return a byte output; selector meanings remain unresolved.

  • ShellCoreUtil notifications: IDU notifications use a signed 64-bit identifier, optional text and a 32-bit type. PSM events carry a 32-bit event ID and a string.

  • ShellCoreUtil state setters: UI updates take a 64-bit status and mask; app data takes two strings. Display-state setters mask their low bits, so source enum names and declared widths cannot be inferred from those masks alone. Streaming/impose/profiler setters test all 32 bits. User-focus reads take an application ID and return its user ID; writes apply a user ID to the current application.

  • ShellCoreUtil dialog parameters: the 24-byte error-dialog parameter contains a message pointer at offset zero, a null-terminated vector of string arguments at offset eight and a byte flag at offset 16. Field offsets and size are asserted; the flag meaning remains unresolved. Start/stop streaming-game and unmount requests take strings. Bus-transfer testing writes one byte after a string input.

  • SystemService activation and process signatures: activation wrappers validate a machine-sized handle and expose 32-bit status/result outputs or a byte activation flag. Shell activation initialization also receives a type selector; managed callers confirm the machine-sized handle consumed by constant-return start/abort/terminate exports. SystemService local-process parameters differ from LncUtil parameters and are kept as distinct types; general creation reads through offset 71, JVM/PS2 creation reads two 32-bit fields at offsets four and eight. Install status writes 12 bytes and application status writes 16 bytes; their remaining field meanings are unresolved.

  • SystemService query payloads: daemon events write 12 bytes; local-process entries occupy 36 bytes, consisting of a 32-bit value and 32-byte name. PS-button extraction reads a 16-byte event and rearranges its fields into a distinct 16-byte output; semantic names remain unresolved. Privacy definition/version queries take string keys and distinct output types; their layouts remain unresolved. Workaround information writes four bytes at offset zero and 16 bytes at offset eight.

  • SystemService direct aliases: assembly-only jumps now share the confirmed signatures of their LncUtil/ShellCoreUtil targets for application-ID lists, remote-play/UI status, navigation, controller-focus permissions and boolean budget/status queries. Aliases of unresolved targets still require target or caller analysis.

  • LncUtil collapsed dispatch stubs: assembly table targets confirm application-ID lookup takes a title-ID string, current/focused status outputs occupy 64 bytes, GPU-crash status occupies 1320 bytes, and dialog activation writes one byte. Shared-memory registration takes a string. The protected service implementations remain unchanged; collapsed assembly procedures are not missing exports.

  • SystemService launch and telemetry arguments: store-launch parameters contain only a four-byte size; web-app launch takes one string argument. Process lifecycle wrappers forward the verified LncUtil argument lists. TelemetrySetData takes a string key, binary payload and machine-sized length; TelemetrySetData2 takes two strings. Token storage consumes a 32-bit identifier and string; only its signature is restored, with no token values included.

  • SystemStateMgr and modal signatures: keep-main-on-standby takes a string, reboot timer consumes a 32-bit mode and wake-up consumes a 16-bit trigger. Suspend/resume progress forwards a string to kernel logging. Disc readiness, shell shutdown progress and standby enablement return booleans. Modal open takes a string and close takes a 32-bit dialog ID. Platform privacy setting writes a 32-bit value; the kernel platform query it calls consumes no caller arguments.

  • USB storage aliases and USB exports: direct-jump signatures are matched to the supplied USB module. RequestMap/RequestMapWSB take six arguments; the two extra helper arguments are internal. IsExist takes a device, directory and byte output, with a separate boolean failure result. Callbacks receive an event pointer and user data. Device information writes 824 bytes, device lists hold eight 32-bit IDs, and mount-point outputs occupy 128 bytes. Event/device field meanings and initialization attributes remain unresolved.

  • Assembly-only shell and clock queries: format/fsck progress returns a float in XMM0. Impose-menu, accessibility-zoom and suspend-confirmation queries take an application ID and return a boolean. Suspend-blacklist lookup forwards a 32-bit ID to SysCore. Clock changes take a string and 32-bit value; CPU pstate takes a 32-byte input structure whose fields remain unresolved, and memory pstate takes one 32-bit value.

  • Integer system parameters: registry-backed parameters 100–111, 200–213 and 300 throw because their settings are not modeled. Language results omit the console SDK-version compatibility remapping, and parameters 7, 400 and 1000 do not reproduce platform-dependent availability.

  • Tournament launch parameters: occurrence parameters occupy 32 bytes and contain two string pointers and a user ID. The final string semantics are unresolved. Event-details and team-profile launches retain an unused first argument slot of unknown declared type. The daemon blocking-event receive argument is passed unchanged as 64 bits to IPC; its meaning remains unresolved. Protected bodies in PendingExports.cpp remain unchanged.

Reference in new issue View Git Blame Copy Permalink