Patapon2, HBL and TN HEN 620

[jigsaw]

It's an old topic. But I'm not sure how it works when I look back.

TN HEN 620 uses sceUtilityHtmlViewerInitStart, i.e., sceUtility_CDC3AA41, to load htmlviewer_utility.prx so as to get access to some NIDs.

However, I find that sceUtilityHtmlViewerInitStart/sceUtility_CDC3AA41 is *not* imported by Patapon2. (see here: http://code.google.com/p/valentine-hbl/ ... 2Fpatapon2 )

So the question is, how HBL resolves sceUtility_CDC3AA41 for TN HEN 620?

[m0skit0]

IIRC on 6.20 syscall estimation works perfectly, so even if a NID is not imported, HBL will calculate it automatically.

[jigsaw]

IIRC on 6.20 syscall estimation works perfectly, so even if a NID is not imported, HBL will calculate it automatically.

k understood. and it seems that syscall estimation no longer works since 660.
but i'll give it a try.

thanks

[m0skit0]

It seems that syscall estimation no longer works since 660

Well I think the problem has more to do with how syscalls are activated. Syscall estimation most likely still works fine BUT the kernel now does not activate syscalls not imported by modules (you get a breakpoint IIRC).

[jigsaw]

It seems that syscall estimation no longer works since 660

Well I think the problem has more to do with how syscalls are activated. Syscall estimation most likely still works fine BUT the kernel now does not activate syscalls not imported by modules (you get a breakpoint IIRC).

Yes, I noticed that. Kernel maintains a jmp table, which contains all the *imported* syscall function address (yeah, the real address in memory, both user mod and kmod). So if you try to call a syscall which is not in the table, freeze.

[jigsaw]

It seems that syscall estimation no longer works since 660

Well I think the problem has more to do with how syscalls are activated. Syscall estimation most likely still works fine BUT the kernel now does not activate syscalls not imported by modules (you get a breakpoint IIRC).

Another question: Is it possible to get the syscall number from user mode? (Assume that it's a imported syscall).

I noticed that HBL can print syscall number, but I haven't found out how you did it.

[m0skit0]

Is it possible to get the syscall number from user mode? (Assume that it's a imported syscall).

I don't quite understand the question. If it's an imported syscall, that means it exists somewhere in user-mode land and thus you can just parse this to get it. Or maybe I didn't understand what you meant... I'm assuming you're talking for 6.60, since in <6.60 you can just estimate it.

I noticed that HBL can print syscall number, but I haven't found out how you did it.

All known calls are stored in a tNIDResolver struct which is part of HBLNIDTable struct, like this:

(tables.h)

Code: Select all

typedef struct
{
        u32 nid;                    // NID
        u32 call;                   // Syscall/jump associated to the NID
        unsigned int lib_index; // Index to the library descriptor tSceLibrary
} tNIDResolver;

typedef struct
{
        unsigned int num;                                       // Number of nids on table     
        tNIDResolver table[NID_TABLE_SIZE];     // NID resolver
} HBLNIDTable;

The call member is actually the instruction, and thus the syscall (if it's a kernel call, of course). If you want to extract the syscall number, you can use the GET_SYSCALL_NUMBER(sys) macro. This table is stored on the global struct.

You can parse that and print it, although I think there's already a part of the code that does that, but I'm unable to find it. Check for NID_DEBUG define, that should lead you.

[jigsaw]

If it's an imported syscall, that means it exists somewhere in user-mode land and thus you can just parse this to get it.

Yes, this is exactly what I mean. Say, my own application imports sceKernelIcacheInvalidateAll, a.k.a. UtilsForUser_920F104A. Now I want to know what is the syscall number.

As I understood, the syscall num is dynamically generated, i.e., is different from each time the app is loaded.
So the syscall number is not sth. that I can find in the .prx or EBOOT. Is that right?
Then how do I find it in live app? Could you give a hint?

EDIT:

Code: Select all

; ======================================================
; Subroutine UtilsForUser_920F104A - Address 0x0000C114
; Imported from UtilsForUser
UtilsForUser_920F104A:      ; Refs: 0x0000C228 0x00000624
   0x0000C114: 0x03E00008 '....' - jr         $ra
   0x0000C118: 0x00000000 '....' - sll        $zr, $zr, 0



Is it so that, those "jr ra" NID stubs in the prx will be replaced with syscall instruction in the runtime?

[m0skit0]

As I understood, the syscall num is dynamically generated, i.e., is different from each time the app is loaded.

Correct.

So the syscall number is not sth. that I can find in the .prx or EBOOT. Is that right?

Correct.

Then how do I find it in live app? Could you give a hint?

I still don't understand. Let me clarify a thing first: there are 2 different kinds of executables (PRXs): official and homebrew. The executables have a section called "stubs", and it's where the executable lists all the imports it needs. Such imports come like this in the executable file:

Code: Select all

jr $ra
nop

This, as you must have guessed, just does nothing but return to caller. This is the same for both official and homebrews.

Official executables (e.g. official games) are loaded by the kernel, and the kernel resolves the imports listed, transforming them into something like

Code: Select all

jr $ra
syscall insertsyscallnumberhere

That is, the executable's imports are resolved in RAM before executing it.

For homebrews (non-signed), kernel of course won't load these, since they're not signed. So here comes HBL: it loads the homebrew in RAM and resolves the imports. How does HBL resolves the imports? Well it first looks if that import was used by another module previously loaded in RAM, like the exploited game's module. If not, it tries to guess it by using a method I called "syscall estimation". This was pretty much tuned up by JJS and works flawlessly in <6.60 firmwares, but does not work on 6.60 as we discussed before.

TL;DR: you cannot use syscalls for an import that's not already imported by kernel-loaded (not HBL-loaded) modules in 6.60.

[jigsaw]

Official executables (e.g. official games) are loaded by the kernel, and the kernel resolves the imports listed, transforming them into something like

Code: Select all

jr $ra
syscall insertsyscallnumberhere

That is, the executable's imports are resolved in RAM before executing it.

This is what Im looking for.
Now I want to make a signed homebrew which can prints the syscall number of all imported NIDs.
I'd assume the code is as below:

Code: Select all

u32 text = find_my_module_start_address();
u32 func_addr = text + offset_of_stub; // offset_of_stub can be checked by dis-assmbler

printf("syscall num is: %x\n", _lw(func_addr) >> 6);


Is it correct?


Thank you for your patience.