Discuss the development of new homebrew software, tools and libraries.
Moderators: cheriff , TyRaNiD
kralyk
Posts: 114 Joined: Sun Apr 06, 2008 8:18 pm
Location: Czech Republic, central EU
Post
by kralyk » Wed Jun 24, 2009 12:44 am
Hi, I need a little help with MIPS assembly.
I dumped some prx code from RAM and compared it to dissassembly just
to see that it was quite different.
I know that MIPS assembly is somewhat transformed during "compilation" (or when going to RAM?), but to be honest I have no clue how...
In Coldbird's post I found these macros that helped me a bit:
Code: Select all
#define MIPS_NOP 0x00000000
#define MIPS_SYSCALL(NUM) (((NUM)<<6)|12)
#define MIPS_J(ADDR) (0x08000000 + ((((unsigned int)(ADDR))&0x0ffffffc)>>2))
#define MIPS_STACK_SIZE(SIZE) (0x27BD0000 + (((unsigned int)(SIZE)) & 0x0000FFFF))
#define MIPS_PUSH_RA(STACKPOS) (0xAFBF0000 + (((unsigned int)(STACKPOS)) & 0x0000FFFF))
#define MIPS_POP_RA(STACKPOS) (0x8FBF0000 + (((unsigned int)(STACKPOS)) & 0x0000FFFF))
#define MIPS_RETURN 0x03E00008
But apart from those I also need JAL, ADDIU and LUI.
Can someone suggest how such macros would look for JAL, ADDIU and LUI?
Thank you...
...sorry for my english...
m0skit0
Posts: 191 Joined: Tue Jun 02, 2009 8:58 pm
Post
by m0skit0 » Wed Jun 24, 2009 1:18 am
The Incredible Bill Gates wrote: The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
kralyk
Posts: 114 Joined: Sun Apr 06, 2008 8:18 pm
Location: Czech Republic, central EU
Post
by kralyk » Wed Jun 24, 2009 6:13 am
I still don't understand...
For example, this is a dissassembly of my module:
Code: Select all
; ==== Section .text - Address 0x00000000 Size 0x000012D0 Flags 0x0006
; ======================================================
; Subroutine splugin_EE3DCDDE - Address 0x00000000
; Exported in splugin
splugin_EE3DCDDE: ; Refs: 0x00000230 0x00001514
0x00000000: 0x27BDFFF8 '...'' - addiu $sp, $sp, -8
0x00000004: 0xAFBF0004 '....' - sw $ra, 4($sp)
0x00000008: 0x3C020000 '...<' - lui $v0, 0x0
; Data ref 0x00002470 ... 0x00000000 0x00000000 0x00000000 0x00000000
0x0000000C: 0x8C422470 'p$B.' - lw $v0, 9328($v0)
0x00000010: 0x0040F809 '..@.' - jalr $v0
0x00000014: 0x00000000 '....' - nop
0x00000018: 0x3C040000 '...<' - lui $a0, 0x0
; Data ref 0x00002468 ... 0x00000000 0x00000000 0x00000000 0x00000000
0x0000001C: 0x8C832468 'h$..' - lw $v1, 9320($a0)
0x00000020: 0x24630001 '..c$' - addiu $v1, $v1, 1
; Data ref 0x00002468 ... 0x00000000 0x00000000 0x00000000 0x00000000
0x00000024: 0xAC832468 'h$..' - sw $v1, 9320($a0)
0x00000028: 0x8FBF0004 '....' - lw $ra, 4($sp)
0x0000002C: 0x03E00008 '....' - jr $ra
0x00000030: 0x27BD0008 '...'' - addiu $sp, $sp, 8
...etc...
And this is what is really in RAM on text_addr:
Code: Select all
0x00000000: 0x27bdfff8
0x00000004: 0xafbf0004
0x00000008: 0x3c028822
0x0000000c: 0x8c420c64
0x00000010: 0x0040f809
0x00000014: 0x00000000
0x00000018: 0x3c048822
0x0000001c: 0x8c830c5c
0x00000020: 0x24630001
0x00000024: 0xac830c5c
0x00000028: 0x8fbf0004
0x0000002c: 0x03e00008
0x00000030: 0x27bd0008
...etc...
How come? That document doesn't seem to cover this.
Is this because of the relocation and thus PRX-specific?
...sorry for my english...
jimparis
Posts: 1145 Joined: Fri Jun 10, 2005 4:21 am
Location: Boston
Post
by jimparis » Wed Jun 24, 2009 8:14 am
Yeah, that looks like normal relocation there...
m0skit0
Posts: 191 Joined: Tue Jun 02, 2009 8:58 pm
Post
by m0skit0 » Wed Jun 24, 2009 5:52 pm
Of course, PRX doesn't have the jumps specified, they're relocated by the kernel when loaded.
The reference I gave you has all the opcodes and instructions, so you just need to check it and build your macros.
The Incredible Bill Gates wrote: The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
kralyk
Posts: 114 Joined: Sun Apr 06, 2008 8:18 pm
Location: Czech Republic, central EU
Post
by kralyk » Wed Jun 24, 2009 10:50 pm
Yes yes, thanks, but theres more trouble with it.
See I need to get address of certain subroutine of fw module because of hooking (it cant be hooked standard way because its a hook already :)).
But the offset of the subroutine differs in each CFW so I have to look it up dynamically.
Somewhere in the beginning of that module theres the code that sets up the hooks and there I can get the address.
Now the problem is that the address is modified during relocation somehow, heres the code:
Original instruction:
In RAM:
So the number I need is 0x1b3c, but in RAM another value has been added to it because it points to a subroutine (0x9300 in this case). This value is dynamic.
What is this value and how can I obtain it?
...sorry for my english...
m0skit0
Posts: 191 Joined: Tue Jun 02, 2009 8:58 pm
Post
by m0skit0 » Wed Jun 24, 2009 11:41 pm
kralyk wrote: What is this value and how can I obtain it?
I don't think anybody can help you if you don't give more details... By "original instruction", I guess you mean in the PRX before loading, and by in RAM, after being relocated. You should give more details I think.
The Incredible Bill Gates wrote: The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
kralyk
Posts: 114 Joined: Sun Apr 06, 2008 8:18 pm
Location: Czech Republic, central EU
Post
by kralyk » Wed Jun 24, 2009 11:47 pm
Yes exactly, before loading to RAM the address (of subroutine) is 0x1b3c and after loading it gets 0xae3c for some reason...
...sorry for my english...
m0skit0
Posts: 191 Joined: Tue Jun 02, 2009 8:58 pm
Post
by m0skit0 » Wed Jun 24, 2009 11:50 pm
Then the routine address is changed. Try dumping the module when loaded in RAM and disassembling it.
The Incredible Bill Gates wrote: The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
kralyk
Posts: 114 Joined: Sun Apr 06, 2008 8:18 pm
Location: Czech Republic, central EU
Post
by kralyk » Thu Jun 25, 2009 12:30 am
uhm no it's not because the subroutine can still be reached by text_addr + 0x1b3c
Anyway, I got it resolved now, I must have messed the text_addr somehow or something, dunno.
My code now works like this:
Code: Select all
u32 instruction //<- in this var I have the addiu instruction from RAM, which is always the same
instruction &= 0x0000ffff; //gets me rid of the opcode etc. and leaves only the immediate
instruction |= text_addr & 0xffff0000;
//now instruction becomes a real and final pointer to the subroutine I need, it can now be found in syscall table
I don't really know why it works like this but Im happy as long as it does... =)
(and it should work across various CFWs)
...sorry for my english...