Syscalls, NIDs, Imports??

Syscalls, NIDs, Imports?? If you know what HBL is, you have at least heard one of those three terms, especially “syscall”. Most time spent on developing HBL was trying to improve syscall estimation (even if now it’s broken again). Syscall estimation is one of the most advanced and important parts of HBL, without it you wouldn’t able to run so many awesome homebrews on your PSV or PSP! Most of the times, people talk about this and have no idea what they’re talking about, so here’s a brief explanation.

(I will not explain how HBL estimates syscalls or how the PSP kernel handles syscalls, I will only explain the core concepts, so you will be able to understand better how HBL works)

– Interrupts –

Syscalls are probably the most difficult concept to understand, so let’s start off with them.

First of all, what is a syscall? A syscall is a software interrupt. I don’t expect you to know what an interrupt is, so I’m going to give you a quick introduction. There are two types of interrupts: hardware and software.

Hardware interrupts are “events” triggered by peripheral devices, like the HDD in your computer or the UMD drive in your PSP.

Software interrupts, on the other hand, are “events” triggered by software itself, syscalls are software interrupts. At boot, the system assigns a handler to each interrupt, so when an interrupt is triggered, it knows what to do; even syscalls have their own handler.

– Syscalls –

So, syscalls are software interrupts, now, what are syscalls for?

Well, you may know there are different levels of permission in a system: user and kernel. Code running in user mode can’t access kernel mode functions just by jumping to them, like it would do with user mode functions, but some functions require kernel mode, so what’s the solution? Syscalls. Syscalls have “numbers”, every number corresponds to a certain function: when some usermode software needs to call a kernelmode function, it triggers the syscall with the number for that function.

For example: There are a bunch of kernel functions we can call:

  • 1 – kernel_doesthis
  • 2 – kernel_doesthat
  • 10 – kernel_hello

and we want to call kernel_hello; of course, since it’s a kernel function, we can’t just jump to its address, we have to trigger a syscall. Since kernel_hello corresponds to syscall number 10, we can call it like this: syscall 10 (this is just pseudo-code, this is not a programming tutorial.)

This is just an example, on PSP, things are most difficult: back in first firmware versions, syscalls were “hardcoded” (means a function had always the same syscall number), but nowadays, syscalls are random. To know what function to call when a certain syscall is triggered, the system keeps a list in kernel memory (so we can’t access it), when an executable is launched that list is filled, but “randomly” (it’s not completely random, there are many factors involved and we know how they are calculated, but I don’t want to go too technical here).

– NIDs –

This is the easiest part of the explanation: a NID (Name Identifier) is an identifier for an exported function (an exported function is a function that can be called outside of the module, as long as the module that contains it is running).

A NID is just the first 32 bits (little-endian) of the SHA1 of the function’s name, this explanation is actually taken from SilverSpring, who actually cracked a lot of NIDs (yes, they can be bruteforced), I just resumed it as his blog is now offline.

NIDs of kernel functions change after some firmware revisions, usermode NIDs should never change (otherwise old games wouldn’t work). NIDs are used by the system to understand what function to link to a certain import.

– Imports –

PSP system provides an API for many tasks like graphics or threading. Applications can call any function they need from that API, but first, they have to declare what functions they need.

When the PSP system executes an application, it parses “imports”, a list of libraries and NIDs, and links every import to the corresponding function: imports of kernel functions will become syscalls and user imports will become jumps. HBL does exactly the same: when you launch an homebrew with HBL, it can’t ask the system to resolve the imports of that homebrew as it would require kernel access (a kernel exploit, basically), instead, it resolves imports for you. The problem is it can’t access the syscall list, so it has to guess syscalls starting from the syscalls it already knows (the ones imported by the game used to run it)


I hope this helps you understanding why HBL isn’t “perfect” and why developing it is so hard ;)
– Freddy

  1. Viral_Weaponry’s avatar

    Nice info, even if sometimes sounds like u r typing in German lol
    I appreciate this info man ;)


    1. freddy_156’s avatar

      Feel free to correct my english, it’s not my native language bur I try to do my best :)


  2. Lindo’s avatar

    the only thing i can do now is pray.


  3. auron’s avatar

    i think this is going somewhere… somewhere magical


    1. fate6’s avatar

      its not >_>
      its just supposed to be informational


  4. Dovahkiin’s avatar

    Thanks Freddy! :D


  5. cris’s avatar

    well i believe in the end kernel access to ps vita psp emulator will be achieved ,at least from someone that do see the vast possiblities of ps vita we need to find an overflow in the system and then get access to the whole system structure of work….


  6. Shacq Gnarly’s avatar

    i can definitely appreciate the hard work put into all that programming now.. i never knew it was so difficult


  7. yosh’s avatar

    Interesting, I never knew about the sha1 thing :D


  8. CATPowah’s avatar

    Ugh…I don’t think I get it all, coz it’s just sound like something from the sci-fi movie.



Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>