You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like the dupio/dupsh templates are broken when you run the following shellcode in a MIPS machine (emulated using qemu-system. I used the setup from arm_now:
sc=asm(shellcraft.dupsh())
In case you need the MIPS kernel version I am using:
# uname -a
Linux buildroot 4.11.3 #1 SMP Sun Mar 4 03:29:34 UTC 2018 mips GNU/Linux
Error seems to traceback to this file. Seems like this code is looping through values 0-2 via a counter at register $t0.
However, seems like after one call to the syscall 0x40404 instruction, it seems like $t0 is set to 0. As a result, only dup($reg, 2) is called, ignoring fd's 0 and 1.
Not sure if it is standard that $t* registers are potentially volatile after a syscall in the MIPS linux kernel or just an edge case behavior for some older kernel version. See gef-gdb debug output below:
It seems like the dupio/dupsh templates are broken when you run the following shellcode in a MIPS machine (emulated using qemu-system. I used the setup from arm_now:
In case you need the MIPS kernel version I am using:
Error seems to traceback to this file. Seems like this code is looping through values 0-2 via a counter at register
$t0
.However, seems like after one call to the
syscall 0x40404
instruction, it seems like$t0
is set to 0. As a result, onlydup($reg, 2)
is called, ignoring fd's 0 and 1.Not sure if it is standard that $t* registers are potentially volatile after a syscall in the MIPS linux kernel or just an edge case behavior for some older kernel version. See gef-gdb debug output below:
The text was updated successfully, but these errors were encountered: