Reverse of TN HEN main function

[jigsaw]

Nice job again! And nice idea to make open-sourced stuff. I just hope you won't change your mind like dridri

On the technical side, that C code can be improved, for example removing all the gotos, which are just horrible. On the other side, if you write your own strncmp() (which is very easy) it should work.

For people who aren't going to enter technical discussion, please abstain putting useless posts, let's keep this thread clean

I don't know the story of dridri but I would never change the licence (GPLv2) of project hen. And I would appreciate anyone who like to join so that it won't die soon.
The code is not so clean and has room for improve. Pls feel free to give more advices.

The strncmp is really sth. I don't understand. The scenario is as the following.
If this code is inserted before calling sceUtility_private_2DC8380C:

Code: Select all

do {
    strncmp("sceVshVH", s, 8);
    s++;
} while (s < 0x0A000000);

This is OK. Note that we don't check return value of strncmp. It's just a useless loop. (Certainly then we need to calculate the routine address with JSS's code)
However, if we check the return value:

Code: Select all

do {
    if (!strncmp("sceVshVH", s, 8))
        break;
    s++;
} while (s < 0x0A000000);

Now we check the return value of strncmp and debug log shows that we get the correct address. But then PSP crashed - even if we still use JSS's code to calculate routine address!
I also tried replacing it with built-in strncmp, same thing happens. As long as we don't check return value, it's fine; otherwise crash. WTF?

PS: I personally like to replace while/for loop with goto when possible. It's all over kernel's code, isn't it.

Advertising

[FrEdDy]

Your set_value function is kinda useless,you could use _sw and _lw

Thanks for noticing. I didn't know there are such macros. I'll fix it.

Also

Code: Select all

        callback >>= 2;
        callback &= 0x03FFFFFF;
        callback |= 0x0C000000;
        set_value(addr + ((m == 0) ? 0x2F28 : 0x2CD8), callback);

Can be simplified in this way:

Code: Select all

#define MAKE_CALL(a, f) _sw(0x0C000000 | (((u32)(f) >> 2)  & 0x03ffffff), a)
MAKE_CALL(addr + ((m == 0) ? 0x2F28 : 0x2CD8),rebootex_callback);

Advertising

[wololo]

Code: Select all

do {
    strncmp("sceVshVH", s, 8);
    s++;
} while (s < 0x0A000000);

This is OK. Note that we don't check return value of strncmp. It's just a useless loop. (Certainly then we need to calculate the routine address with JSS's code)
However, if we check the return value:

Code: Select all

do {
    if (!strncmp("sceVshVH", s, 8))
        break;
    s++;
} while (s < 0x0A000000);

Here's a random thought, be ready for some Voodoo magic...
the string sceVshVH appears twice in the ram. Once at the position you are looking for...and once in your own code! So you need to check not only strncmp, but also that the value you found is not the one from your code...

something like:

Code: Select all

const char * blah = "sceVshVH";
do {
    if (s!= blah && !strncmp(blah, s, 8))
        break;
    s++;
} while (s < 0x0A000000);

[m0skit0]

Insert some delay on the loop. PSP's firmware hates long loops.

[jigsaw]

Hi Wololo,

I tried your trick with no luck.

Hi m0skit0,

It becomes more tricky, and I would stay with current implementation since it works.

Hi Freddy,

I decrypted the reboot.bin with PRXDecrypter. To my understanding it's a raw binary, i.e., just raw MIPS instructions in sequence. Therefore prxtool no longer works.
So the next step is to disassemble the raw binary to assembly and start reading, is it?

thx &
rgds,
-ql

[FrEdDy]

Hi Freddy,

I decrypted the reboot.bin with PRXDecrypter. To my understanding it's a raw binary, i.e., just raw MIPS instructions in sequence. Therefore prxtool no longer works.
So the next step is to disassemble the raw binary to assembly and start reading, is it?

thx &
rgds,
-ql

You have to use -b option of prxtool,like this:

Code: Select all

prxtool -r 0x88600000 -b -w reboot.bin > reboot.s

-r 0x88600000 is for relocating reboot at its loading address (0x88600000) so you can understand it better,remember since it's a raw binary,data isn't separated from .text,so you may find unknown instructions,don't care about these,it's just data that is threated as code by prxtool

[jigsaw]

Hi Freddy,

I decrypted the reboot.bin with PRXDecrypter. To my understanding it's a raw binary, i.e., just raw MIPS instructions in sequence. Therefore prxtool no longer works.
So the next step is to disassemble the raw binary to assembly and start reading, is it?

thx &
rgds,
-ql

You have to use -b option of prxtool,like this:

Code: Select all

prxtool -r 0x88600000 -b -w reboot.bin > reboot.s

-r 0x88600000 is for relocating reboot at its loading address (0x88600000) so you can understand it better,remember since it's a raw binary,data isn't separated from .text,so you may find unknown instructions,don't care about these,it's just data that is threated as code by prxtool

Oh man you came just in time. I was trying this tool ( http://acade.au7.de/disasmips.htm ) and get nothing useful out of it.

BTW, you said

It contains a gzip'd copy of systemctrl,prxtool finds invalid code because it's a binary file,"real" code ends at 0x88FC0908 (0x00000908 if you didn't relocate)

I don't quite get it. Do you mean the code in _un_decrypted_ bin ends at 0x88FC0908? I think the decrypted bin should contain much more than that, is it?

[FrEdDy]

Hi Freddy,

I decrypted the reboot.bin with PRXDecrypter. To my understanding it's a raw binary, i.e., just raw MIPS instructions in sequence. Therefore prxtool no longer works.
So the next step is to disassemble the raw binary to assembly and start reading, is it?

thx &
rgds,
-ql

You have to use -b option of prxtool,like this:

Code: Select all

prxtool -r 0x88600000 -b -w reboot.bin > reboot.s

-r 0x88600000 is for relocating reboot at its loading address (0x88600000) so you can understand it better,remember since it's a raw binary,data isn't separated from .text,so you may find unknown instructions,don't care about these,it's just data that is threated as code by prxtool

Oh man you came just in time. I was trying this tool ( http://acade.au7.de/disasmips.htm ) and get nothing useful out of it.

BTW, you said

It contains a gzip'd copy of systemctrl,prxtool finds invalid code because it's a binary file,"real" code ends at 0x88FC0908 (0x00000908 if you didn't relocate)

I don't quite get it. Do you mean the code in _un_decrypted_ bin ends at 0x88FC0908? I think the decrypted bin should contain much more than that, is it?

When you disassemble the code,rebootex code ends at 0x88FC0908,rest are variables and systemctrl

[jigsaw]

Now you lost me...
By relocate reboot at 0x88600000, the furtherest code (or variables, whatever) is 0x88613640, which is much less than 0x88FC0908.
Besides, in the very beginning of rebootbin, we jump to 0x88602868 which is offset 2868, larger than 908.

In case that I get the wrong reboot.bin, I post the first and last few lines of it. Pls kindly let me know if this is wrong.

first routine:

Code: Select all

; ==== Section .text - Address 0x88600000 Size 0x00013644 Flags 0x0006

; ======================================================
; Subroutine _start - Address 0x88600000 
_start:
	0x88600000: 0x401A6000 '.`.@' - mfc0       $k0, Status ; mfc0: move from co-processor 0 to
	0x88600004: 0x3C1BFFBF '...<' - lui        $k1, 0xFFBF
	0x88600008: 0x377BFFF9 '..{7' - ori        $k1, $k1, 0xFFF9
	0x8860000C: 0x035BD024 '$.[.' - and        $k0, $k0, $k1
	0x88600010: 0x241B0000 '...$' - addiu      $k1, $zr, 0
	0x88600014: 0x035BD025 '%.[.' - or         $k0, $k0, $k1
	0x88600018: 0x409A6000 '.`.@' - mtc0       $k0, Status ; mtc0: move to co-processor 0
	0x8860001C: 0x0000D821 '!...' - addu       $k1, $zr, $zr
	0x88600020: 0x3C1D8880 '...<' - lui        $sp, 0x8880
	0x88600024: 0x27BDFFC0 '...'' - addiu      $sp, $sp, -64
	0x88600028: 0x3C028860 '`..<' - lui        $v0, 0x8860
	0x8860002C: 0x24422868 'h(B$' - addiu      $v0, $v0, 10344
	0x88600030: 0x00400008 '..@.' - jr         $v0 ; j 0x88602868
	0x88600034: 0x00000000 '....' - sll        $zr, $zr, 0

Last few lines:

Code: Select all

0x88612BE4: "flashfat%d:"
0x88612BF4: "lflash"
0x88612BFC: "Physical Formatting (0.8.0 - current)\n"
0x88612C2C: "done\n"
0x88612C34: "lflash.c"
0x88612C40: "Assertion failed at %s:%s:%04d"
0x88612C60: "Initialize"
0x88612C6C: "FAT32   "
0x88612C78: "FAT12   "
0x88612C84: "FAT16   "
0x88612C90: "single"
0x88612C9C: "sceReboot"
0x88613423: "#$%&'()"
0x88613430: "0123456789"
0x8861345E: "^_`ABCDEFGHIJKLMNOPQRSTUVWXYZ{"

[FrEdDy]

Now you lost me...
By relocate reboot at 0x88600000, the furtherest code (or variables, whatever) is 0x88613640, which is much less than 0x88FC0908.
Besides, in the very beginning of rebootbin, we jump to 0x88602868 which is offset 2868, larger than 908.

In case that I get the wrong reboot.bin, I post the first and last few lines of it. Pls kindly let me know if this is wrong.

first routine:

Code: Select all

; ==== Section .text - Address 0x88600000 Size 0x00013644 Flags 0x0006

; ======================================================
; Subroutine _start - Address 0x88600000 
_start:
	0x88600000: 0x401A6000 '.`.@' - mfc0       $k0, Status ; mfc0: move from co-processor 0 to
	0x88600004: 0x3C1BFFBF '...<' - lui        $k1, 0xFFBF
	0x88600008: 0x377BFFF9 '..{7' - ori        $k1, $k1, 0xFFF9
	0x8860000C: 0x035BD024 '$.[.' - and        $k0, $k0, $k1
	0x88600010: 0x241B0000 '...$' - addiu      $k1, $zr, 0
	0x88600014: 0x035BD025 '%.[.' - or         $k0, $k0, $k1
	0x88600018: 0x409A6000 '.`.@' - mtc0       $k0, Status ; mtc0: move to co-processor 0
	0x8860001C: 0x0000D821 '!...' - addu       $k1, $zr, $zr
	0x88600020: 0x3C1D8880 '...<' - lui        $sp, 0x8880
	0x88600024: 0x27BDFFC0 '...'' - addiu      $sp, $sp, -64
	0x88600028: 0x3C028860 '`..<' - lui        $v0, 0x8860
	0x8860002C: 0x24422868 'h(B$' - addiu      $v0, $v0, 10344
	0x88600030: 0x00400008 '..@.' - jr         $v0 ; j 0x88602868
	0x88600034: 0x00000000 '....' - sll        $zr, $zr, 0

Last few lines:

Code: Select all

0x88612BE4: "flashfat%d:"
0x88612BF4: "lflash"
0x88612BFC: "Physical Formatting (0.8.0 - current)\n"
0x88612C2C: "done\n"
0x88612C34: "lflash.c"
0x88612C40: "Assertion failed at %s:%s:%04d"
0x88612C60: "Initialize"
0x88612C6C: "FAT32   "
0x88612C78: "FAT12   "
0x88612C84: "FAT16   "
0x88612C90: "single"
0x88612C9C: "sceReboot"
0x88613423: "#$%&'()"
0x88613430: "0123456789"
0x8861345E: "^_`ABCDEFGHIJKLMNOPQRSTUVWXYZ{"

Oh,sorry,0x88FC0908 is the end of rebootex's real code ^^'