Sysconf adress
-
- Posts: 31
- Joined: Mon Mar 24, 2008 12:31 am
Sysconf adress
Hi everyone,
I want to know how did certain developers do to know what is the adress of the firmware version in sysconf_plugin.prx (0x15EE0 in 5.00 firmware) ?
Excuse me if it's not clear but I want to know how :).
Thanks in advance and I'm apologize for my bad english because I'm French...
I want to know how did certain developers do to know what is the adress of the firmware version in sysconf_plugin.prx (0x15EE0 in 5.00 firmware) ?
Excuse me if it's not clear but I want to know how :).
Thanks in advance and I'm apologize for my bad english because I'm French...
I'm apologize for my bad English because I am French :)
.::pspflashsystem::.
.::pspflashsystem::.
-
- Posts: 22
- Joined: Sat Jan 03, 2009 6:51 am
It calls a function located in scePaf to get ahold of the version, but this function changes it's NID every 3 firmwares or so.
However, what really is usefull here is the second argument being passed, it's a string but Prxtool doesn't properly analyze the data references in new firmware modules, so it's a little harder to track back.
It fills the pointer to this string by combining the lui and addiu.
Lui fills the upper 16 bits (0x00020000), and addiu fills the lower 16 bits, ending up with 0x00027C8C.
If we search this address in the assembly, we find this:
This has been misidentified as assembly, but we can find the string, which is msgshare_version.
In later firmwares, simply look up this string again, then search for a reference to the address it's at, and you'll find the function to patch. :)
However, what really is usefull here is the second argument being passed, it's a string but Prxtool doesn't properly analyze the data references in new firmware modules, so it's a little harder to track back.
Code: Select all
0x00015EDC: 0x3C050002 '...<' - lui $a1, 0x2
0x00015EE0: 0x0C008D68 'h...' - jal scePaf_970DC20D
0x00015EE4: 0x24A57C8C '.|.$' - addiu $a1, $a1, 31884
Lui fills the upper 16 bits (0x00020000), and addiu fills the lower 16 bits, ending up with 0x00027C8C.
If we search this address in the assembly, we find this:
Code: Select all
0x00027C8C: 0x7367736D 'msgs' - Unknown
0x00027C90: 0x65726168 'hare' - Unknown
0x00027C94: 0x7265765F '_ver' - Unknown
0x00027C98: 0x6E6F6973 'sion' - Unknown
0x00027C9C: 0x00000000 '....' - nop
In later firmwares, simply look up this string again, then search for a reference to the address it's at, and you'll find the function to patch. :)
mmm,
excuse me,
I've looked at scePaf_970DC20D function ( ofw 500) , and I've found this:
Why?
It's an empty function??
excuse me,
I've looked at scePaf_970DC20D function ( ofw 500) , and I've found this:
Code: Select all
======================================================
; Subroutine scePaf_970DC20D - Address 0x000235A0
; Imported from scePaf
scePaf_970DC20D:
0x000235A0: 0x03E00008 '....' - jr $ra
0x000235A4: 0x00000000 '....' - nop
It's an empty function??
Get Xplora!
-
- Posts: 22
- Joined: Sat Jan 03, 2009 6:51 am
You're looking at the stub inside the vshmain module. You see, when modules import a function, those useless "stubs" are created and jumps towards it are placed. Once the ELF loader loads the actual module, it'll replace those useless instructions with a jump towards the scePaf_970DC20D exported from paf.prx. So, if you want to see the function, you need to look in paf.prx for scePaf_970DC20D. ;)ne0h wrote:mmm,
excuse me,
I've looked at scePaf_970DC20D function ( ofw 500) , and I've found this:Why?Code: Select all
====================================================== ; Subroutine scePaf_970DC20D - Address 0x000235A0 ; Imported from scePaf scePaf_970DC20D: 0x000235A0: 0x03E00008 '....' - jr $ra 0x000235A4: 0x00000000 '....' - nop
It's an empty function??
-
- Posts: 31
- Joined: Mon Mar 24, 2008 12:31 am
-
- Posts: 31
- Joined: Sun Mar 23, 2008 2:16 am
- Contact: