The byte_xori encoder for mipsbe does not work correctly. At the end of the decoding, it should invoke cacheflush() with the correct parameters:
int cacheflush(char *addr, int nbytes, int cache)
I think this is because the encoder is based of the longxori encoder, which itself is pretty old (2008), and before kernel 2.6.11, cacheflush() did not need any parameters (from the cacheflush man page):
BUGS
Linux kernels older than version 2.6.11 ignore the addr and nbytes arguments, making this function fairly expensive. Therefore, the whole cache is always flushed.
This commit fixes that by setting up the parameters correctly. As an unfortunate side effect this increases the shellcode by 16 bytes, but it is absolutely necessary for it to work properly.
Note that this bug is not present when testing the encoder output on an emulator like qemu; emulators do not need to flush the caches to work properly.
The longxor encoder for mipsbe does not work correctly. At the end of the decoding, it should invoke cacheflush() with the correct parameters:
int cacheflush(char *addr, int nbytes, int cache)
The encoder previously did not setup the arguments, as it even said so in the comments:
; addiu $4, $16, -4 ; not checked by Linux
; li $5,40 ; not checked by Linux
; li $6,3 ; $6 is set above
I think this is because the encoder is pretty old (2008), and before kernel 2.6.11, cacheflush() did not need any parameters (from the cacheflush man page):
BUGS
Linux kernels older than version 2.6.11 ignore the addr and nbytes arguments, making this function fairly expensive. Therefore, the
whole cache is always flushed.
This commit fixes that by setting up the parameters correctly. As an unfortunate side effect this increases the shellcode by 16 bytes, but it is absolutely necessary for it to work properly.
Note that this bug is not present when testing the encoder output on an emulator like qemu; emulators do not need to flush the caches to work properly.
As an added bonus I have also made it compatible with toupper() restrictions, which is common in web server exploits too. This did not add any extra bytes to the encoder.
See the complaint on #4039. This doesn't fix that particular
issue (it's somewhat unrelated), but does solve around
a file parsing problem reported by @void-in