Console Hacking > Reverse Engineering

Bruteforcing NIDs on the PS Vita

(1/1)

dots_tb:
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: ---6F16901583C1DFE13731A51CFD2B528845256D2D
--- End code ---

The library nid is the following:

--- Code: ---0x1590166F
--- End code ---

So then, with a quick check, I found that the following libraries can be easily bruteforced with this method:

--- Code: ---SceDisplayForDriver
SceFace
SceFios2KernelForDriver
SceIdStorageForDriver
SceLedForDriver
ScePower
ScePowerForDriver
SceSmart
SceVoice
SceVoiceQoS
--- End code ---

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: ---5bd0d709bda4fc415a90380f1990d51ecea56eee
--- End code ---

The functions nid:

--- Code: ---0x09D7D05B
--- End code ---

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: ---c1b886af5c31846467e7ba5e2cffd64a
--- End code ---

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: ---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
--- End code ---

Yields the results:

--- Code: ---96D15C936510321C7D607B4DFC06BC73063E2561
--- End code ---

The actual NID is:

--- Code: ---0x935CD196
--- End code ---

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.

dots_tb:
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).

teakhanirons:
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: ---nidbruteforcer.exe NID KNOWN_PREFIX KNOWN_SUFFIX
--- End code ---
KNOWN_PREFIX and KNOWN_SUFFIX are optional.

dots_tb:
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.

Graphene:
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.

Navigation

[0] Message Index