Author Topic: Bruteforcing NIDs on the PS Vita  (Read 1917 times)

Offline dots_tb

  • Refugee
  • **
  • Posts: 93
    • View Profile
Bruteforcing NIDs on the PS Vita
« on: April 02, 2020, 04:37:43 AM »
Some information pertaining to bruteforcing NIDs on the PS VITA:

The algorithm would fall into two categories:

Category 1: The system used on the PSP was just a sha1 hash with the first few bytes selected and then byte swapped, there are a few libraries that follow this scheme on the PSV

Example:

sha1(ScePowerForDriver) is equal to:
Code: [Select]
6F16901583C1DFE13731A51CFD2B528845256D2D
The library nid is the following:
Code: [Select]
0x1590166F
So then, with a quick check, I found that the following libraries can be easily bruteforced with this method:
Code: [Select]
SceDisplayForDriver
SceFace
SceFios2KernelForDriver
SceIdStorageForDriver
SceLedForDriver
ScePower
ScePowerForDriver
SceSmart
SceVoice
SceVoiceQoS

This means that any syscall within these libraries can be bruteforced with just sha1. Many of the names are shared with the PSP, however they have been already bruteforced.

I think there is another library called something along the lines HPRemote that can also be bruteforced, with most of the known ones being added to the henkaku wiki using this method.

I have also found that modules compiled with the official SDK also use this:

sha1(mono_profiler_install_code_chunk_new)
Code: [Select]
5bd0d709bda4fc415a90380f1990d51ecea56eee
The functions nid:
Code: [Select]
0x09D7D05B
Thus, every module included in official games can have their function names bruteforced as long as they actually are exported. Ex: Unity modules and the modules included with PSO2.

You CANNOT bruteforce function names that are not exported such as internal functions or any function within the main eboot. This is how the mono NIDs I had posted earlier were found.


Category 2: These NIDs have a suffix which is concatenated to the end of the name before they are hashed. The methodology of obtaining these generating these suffixes are yet to be found.

However, we do have an example of one suffix:
Code: [Select]
c1b886af5c31846467e7ba5e2cffd64a
Found here: https://playstationdev.wiki/psvitadevwiki/index.php?title=Keys#NID_generation_suffixes

This specific suffix is used in generating function NIDs for functions with no library, such as module_start:

module_start + suffix (binary data) as hex:
Code: [Select]
6D 6F 64 75 6C 65 5F 73 74 61 72 74 C1 B8 86 AF 5C 31 84 64 67 E7 BA 5E 2C FF D6 4A
Yields the results:
Code: [Select]
96D15C936510321C7D607B4DFC06BC73063E2561
The actual NID is:
Code: [Select]
0x935CD196
It is theorized that the majority of NIDs are generated using a suffix, however, again, the methodology of generating this suffix is unknown.

Special thanks to CelesteBlue and Princess of Sleeping.
Further thanks to SocraticBliss and ChendoChap for working on a hashcat bruteforcer, and SilverSpring.
« Last Edit: April 02, 2020, 04:58:24 AM by dots_tb »

Offline dots_tb

  • Refugee
  • **
  • Posts: 93
    • View Profile
Re: Bruteforcing NIDs on the PS Vita
« Reply #1 on: April 02, 2020, 09:23:45 PM »
Further info:
Regarding the unknown suffixes, certain properties can be discerned:

We know from modules like SceNpDrm the dbg_fingerprint (or module NID in some non-updated documentation) can change, with functions within it staying the same. Celeste has told me that this is a hash used for versioning.

See:
https://wiki.henkaku.xyz/vita/Modules#Structure
https://wiki.henkaku.xyz/vita/SceNpDrm


The hashing algorithm for this can be found within the official SDK, however we have not confirmed if this is the same algorithm used by Sony internally. It is very likely that it is.

When a module is updated, it doesn't necessarily mean that the suffix will change. We know that certain modules with added features will maintain their NIDs for the syscalls. (Need to check for the libraries).

All Library NIDs get updated per a module, when this happens, the syscall NIDs also get updated? (Need to confirm).

« Last Edit: April 02, 2020, 09:46:31 PM by dots_tb »

Offline teakhanirons

  • Refugee
  • **
  • Posts: 69
  • Saki did nothing wrong.
    • View Profile
Re: Bruteforcing NIDs on the PS Vita
« Reply #2 on: April 02, 2020, 11:25:36 PM »
I made a small piece of concept bruteforcer in C# for this:
https://github.com/teakhanirons/CBPS

Basically bruteforces a string, combines it with optional prefix and suffix, encodes it in SHA1, reads the first 4 bytes backwards and compares it with the NID given. Given the language it's written in, it is unfortunately pretty slow.

USAGE:
Code: [Select]
nidbruteforcer.exe NID KNOWN_PREFIX KNOWN_SUFFIXKNOWN_PREFIX and KNOWN_SUFFIX are optional.
Life Pro Tip: Fry rice before steaming it to enrichen its taste.

Offline dots_tb

  • Refugee
  • **
  • Posts: 93
    • View Profile
Re: Bruteforcing NIDs on the PS Vita
« Reply #3 on: April 05, 2020, 03:11:24 AM »
I thought of something else, since the no name suffix is only used for exports without a library name, that would infer that the suffix is generated from the library name in an unknown fashion.

Offline Graphene

  • Useful Idiot
  • ***
  • Posts: 103
    • View Profile
Re: Bruteforcing NIDs on the PS Vita
« Reply #4 on: November 11, 2021, 11:17:01 AM »
Sometimes library/module name is used as suffix. It may not be the same as the actual library/module name. Examples:

SceSasUser uses SceSasUser suffix.
sceSasCore -> sceSasCoreSceSasUser -> NID match (0x7A4672B2)

ScePaf uses PAF suffix.
sce_paf_realloc -> sce_paf_reallocPAF -> NID match (0x0ADEA3AD)

Example from SCE downloadable apps, paflib.suprx module from LiveTweet/Flickr etc.
Uses ScePafLib suffix.