(Update 2) Help with a crash

[m0skit0]

Advertising

@Acid_Snake: you know Python right? So how can you say you don't know what it's a return value?

Code: Select all

def increment(x):
    return x+1

The return value is x+1.

In MIPS architecture, $v0 register is the one used to hold the value returned by functions. So for example the above Python function when translated to MIPS (which is what the Python interpreter does) would be something like

Code: Select all

move $a0, $v0      # Copy x parameter value to $v0 register (return value)
addui $v0, $v0, 1   # Add one to $v0
jr $ra                  # Return from function with return value $v0

[Acid_Snake]

Advertising

Ok, now I get that part. Well after doing some more test I can only influence $v0, not even $s0, so I believe this crash is useless.

[wth]

yes, looks like I have control over $v0:

Code: Select all

zr:0x00000000 at:0xDEADBEEF[u] v0:0xD4D4D4D4[/u] v1:0x00000000
a0:0x092909D0 a1:0x00000000 a2:0x000D7B80 a3:0x09BE8B00
t0:0x00000000 t1:0xFEFEFEFF t2:0x09BE8AA0 t3:0x093033D8
t4:0x09BE8B20 t5:0xDEADBEEF t6:0xDEADBEEF t7:0xDEADBEEF
s0:0x09BE8AC0 s1:0x092909D0 s2:0x00000010 s3:0x00000001
s4:0x00000003 s5:0x09BE8AC0 s6:0x00000001 s7:0x00000004
t8:0xDEADBEEF t9:0xDEADBEEF k0:0x09F7FF00 k1:0x00000000
gp:0x088840C0 sp:0x09F7F360 fp:0x08880000 ra:0x088191F4
0x08819154: 0x03E00008 '....' - jr         $ra

This is the same crash but using a different form of the savedata
But it seems I don't have control over $ra or $sp

well since it crashes just before jr $ra it means you already have control over this subroutine's return value's address, so you can return what you wish
but yeah it doesn't mean it's exploitable at all with just that ^^

try replacing this v0 you have control of with some valid address to see if it doesn't unlock a more useful crash

[m0skit0]

You need to RE some code around that to see if influencing the return value of that function is of any use.

[Acid_Snake]

You need to RE some code around that to see if influencing the return value of that function is of any use.

how can I calculate the position of the savedata in memory? I already dumped it and found where the save is located

[m0skit0]

Huh? If you already found it in memory, what do you want to calculate?

[Acid_Snake]

Huh? If you already found it in memory, what do you want to calculate?

isn't the memory dumped from 0x88? then in a hex editor the offset would be different

[m0skit0]

You meant 0x08800000. No. The memory is dumped from wherever you said it to start dumping, and depends on the tool used (this is not fixed). If you mean how to calculate real memory addresses from a memory dump, well, couldn't be easier:

real memory address = starting dump memory address + dump offset

[Acid_Snake]

0x08800000

^ that.
I can't seem to affect any other register apart from the return value ($v0). Here is how the save works:
I put a name, let's say "ACID"
I hex edit "SDDATA.BIN"
The name is encrypted using a general rule, for example "ACID" would be "mnbv" (this is not the real encoding, it's just an illustration)
And that is static, so "AAAA" would be "mmmm", and "CCCC" would be "nnnn".
This isn't much of a problem, but makes things difficult to know what part influences $v0.
For the fisrt crash I used a username "iiiiii" and then added more (encoded) "i"s to do an overflow, and the result was: v0:0xD4B765B4
I just can't see a pattern here.