I have gone through the walkthrough about smashing the stack. Both the one http://insecure.org/stf/smashstack.html here and one I found on here Trying to smash the stack. I understand what is suppose to be happening, but I can't get it to work properly.
This is just like the other scenarios. I need to skip x=1 and print 0 as the value of x.
I compile with:
gcc file.c
The original code :
void function(){
char buffer[8];
}
void main(){
int x;
x = 0;
function();
x = 1;
printf("%d\n", x);
}
When I run
objdump -dS a.out
I get
0000000000400530 <function>:
400530: 55 push %rbp
400531: 48 89 e5 mov %rsp,%rbp
400534: 5d pop %rbp
400535: c3 retq
0000000000400536 <main>:
400536: 55 push %rbp
400537: 48 89 e5 mov %rsp,%rbp
40053a: 48 83 ec 20 sub $0x20,%rsp
40053e: 89 7d ec mov %edi,-0x14(%rbp)
400541: 48 89 75 e0 mov %rsi,-0x20(%rbp)
400545: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)
40054c: b8 00 00 00 00 mov $0x0,%eax
400551: e8 da ff ff ff callq 400530 <function>
400556: c7 45 fc 01 00 00 00 movl $0x1,-0x4(%rbp)
40055d: 8b 45 fc mov -0x4(%rbp),%eax
400560: 89 c6 mov %eax,%esi
400562: bf 10 06 40 00 mov $0x400610,%edi
400567: b8 00 00 00 00 mov $0x0,%eax
40056c: e8 9f fe ff ff callq 400410 <printf#plt>
400571: c9 leaveq
400572: c3 retq
400573: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
40057a: 00 00 00
40057d: 0f 1f 00 nopl (%rax)
In the function I need to figure out how many bytes the return address is beyond the start of the buffer. I am not sure about this value. But since there are 6 bytes from the beginnig of the function to the return; would I add 7 bytes to the buffer?
Then I need to skip the instruction
x=1;
And since that instruction is 7 bytes long. Would I add 7 to return pointer?
Something like this?
void function(){
char buffer[8];
int *ret = buffer + 7;
(*ret) += 7;
}
void main(){
int x;
x = 0;
function();
x = 1;
printf("%d\n", x);
}
This throws the warning:
warning: initialization from incompatible pointer type [enabled by default]
int *ret = buffer1 + 5;
^
And the output is 1. What am I doing wrong? And can you explain how to do it right and why it is the correct way?
Thank you.
Try the function below, I wrote it for 32-bit compiler try using (-m32 gcc flag) or with a little effort you can make it work with your 64-bit compiler (Note that in your objdump listing you got 7 bytes offset between call to function and the next instruction so use 7 instead of 8.
void function(void)
{
unsigned long *x;
/* &x will more likely be at -4(ebp) */
/* Adding 1 (+4) gets us to stored ebp */
/* Adding 2 (+8) gets us to stored return address */
x = (unsigned long *)(&x + 2);
/* This is the tricky part */
/* TODO: On my 32-bit compiler gap between call to function
and the next instruction is 8 */
*x += 8;
}
We know that automatic variables are created on the stack - so taking the address of an automatic variable yields a pointer into the stack. When you call a void function, its return address is pushed onto the stack and the size of that address depends on your platform (4 or 8 bytes normally). So if you pass the address of an automatic variable to a function and then write over the memory before that address, you will damage the return address and smash the stack. Here is an example:
#include <stdlib.h>
#include <stdio.h>
static void f(int *p)
{
p[0] = 0x30303030;
p[1] = 0x31313131;
*(p - 1) = 0x35353535;
*(p - 2) = 0x36363636;
}
int main()
{
int a = 0x41424344;
int b = 0x45464748;
int c = 0x494a4b5c;
f(&b);
printf("%08x %08x %08x\n", a, b, c);
return 0;
}
I compiled this on linux with 'gcc -g' and ran under gdb and got this:
Program received signal SIGSEGV, Segmentation fault.
0x000000000040056a in f (p=0x7fffffffde74) at smash.c:10
10 }
(gdb) bt
#0 0x000000000040056a in f (p=0x7fffffffde74) at smash.c:10
#1 0x3636363600400594 in ?? ()
#2 0x3030303035353535 in ?? ()
#3 0x494a4b5c31313131 in ?? ()
#4 0x0000000000000000 in ?? ()
(gdb)
As you can see, the parent function addresses now contain some of my magic numbers. I ran this on 64 bit linux, so really I should have used 64 bit ints to fully overwrite the return address - as it is I left the lower word untouched.
Related
Based upon this MSVC Windows disassembly, is there a method to determine the number of bytes between the labels
jmp_code_start and jmp_code_finish? Manually counting the opcode bytes B8 D0 10 36 00 2D C3 00 00 00 89 45 FC FF 55 FC shows there are 16 bytes but that's tedious. Perhaps there's a better technique?
int main(int argc, char* argv[])
{
003610D0 66 90 xchg ax,ax
003610D2 55 push ebp
003610D3 8B EC mov ebp,esp
003610D5 51 push ecx
jmp_code_start:;
char (*jmp)() = (char*)&main - sizeof(shellcode);
003610D6 B8 D0 10 36 00 mov eax,offset main (03610D0h)
003610DB 2D C3 00 00 00 sub eax,0C3h
003610E0 89 45 FC mov dword ptr [jmp],eax
jmp();
003610E3 FF 55 FC call dword ptr [jmp]
jmp_code_finish:;
return 0;
003610E6 33 C0 xor eax,eax
}
I tried this code but it gave errors:
int jmp_size = jmp_code_finish - jmp_code_start;
printf("jmp_size %d", jmp_size);
The original source code is
#include <windows.h>
#include <stdio.h>
// 195 bytes small Windows/x86 null-free WinExec Calc.exe shellcode.
char shellcode[195] =
"\x89\xe5\x83\xec\x20\x31\xdb\x64\x8b\x5b\x30\x8b\x5b\x0c\x8b\x5b"
"\x1c\x8b\x1b\x8b\x1b\x8b\x43\x08\x89\x45\xfc\x8b\x58\x3c\x01\xc3"
"\x8b\x5b\x78\x01\xc3\x8b\x7b\x20\x01\xc7\x89\x7d\xf8\x8b\x4b\x24"
"\x01\xc1\x89\x4d\xf4\x8b\x53\x1c\x01\xc2\x89\x55\xf0\x8b\x53\x14"
"\x89\x55\xec\xeb\x32\x31\xc0\x8b\x55\xec\x8b\x7d\xf8\x8b\x75\x18"
"\x31\xc9\xfc\x8b\x3c\x87\x03\x7d\xfc\x66\x83\xc1\x08\xf3\xa6\x74"
"\x05\x40\x39\xd0\x72\xe4\x8b\x4d\xf4\x8b\x55\xf0\x66\x8b\x04\x41"
"\x8b\x04\x82\x03\x45\xfc\xc3\xba\x78\x78\x65\x63\xc1\xea\x08\x52"
"\x68\x57\x69\x6e\x45\x89\x65\x18\xe8\xb8\xff\xff\xff\x31\xc9\x51"
"\x68\x2e\x65\x78\x65\x68\x63\x61\x6c\x63\x89\xe3\x41\x51\x53\xff"
"\xd0\x31\xc9\xb9\x01\x65\x73\x73\xc1\xe9\x08\x51\x68\x50\x72\x6f"
"\x63\x68\x45\x78\x69\x74\x89\x65\x18\xe8\x87\xff\xff\xff\x31\xd2"
"\x52\xff\xd0";
int main(int argc, char* argv[])
{
jmp_code_start:;
char (*jmp)() = (char*)&main - sizeof(shellcode);
jmp();
jmp_code_finish:;
return 0;
}
Based upon the supplied answer, this code below now works!
#include <windows.h>
#include <stdio.h>
// 195 bytes small Windows/x86 null-free WinExec Calc.exe shellcode.
char shellcode[195] =
"\x89\xe5\x83\xec\x20\x31\xdb\x64\x8b\x5b\x30\x8b\x5b\x0c\x8b\x5b"
"\x1c\x8b\x1b\x8b\x1b\x8b\x43\x08\x89\x45\xfc\x8b\x58\x3c\x01\xc3"
"\x8b\x5b\x78\x01\xc3\x8b\x7b\x20\x01\xc7\x89\x7d\xf8\x8b\x4b\x24"
"\x01\xc1\x89\x4d\xf4\x8b\x53\x1c\x01\xc2\x89\x55\xf0\x8b\x53\x14"
"\x89\x55\xec\xeb\x32\x31\xc0\x8b\x55\xec\x8b\x7d\xf8\x8b\x75\x18"
"\x31\xc9\xfc\x8b\x3c\x87\x03\x7d\xfc\x66\x83\xc1\x08\xf3\xa6\x74"
"\x05\x40\x39\xd0\x72\xe4\x8b\x4d\xf4\x8b\x55\xf0\x66\x8b\x04\x41"
"\x8b\x04\x82\x03\x45\xfc\xc3\xba\x78\x78\x65\x63\xc1\xea\x08\x52"
"\x68\x57\x69\x6e\x45\x89\x65\x18\xe8\xb8\xff\xff\xff\x31\xc9\x51"
"\x68\x2e\x65\x78\x65\x68\x63\x61\x6c\x63\x89\xe3\x41\x51\x53\xff"
"\xd0\x31\xc9\xb9\x01\x65\x73\x73\xc1\xe9\x08\x51\x68\x50\x72\x6f"
"\x63\x68\x45\x78\x69\x74\x89\x65\x18\xe8\x87\xff\xff\xff\x31\xd2"
"\x52\xff\xd0";
void shellcode_func(void);
void dummy_function(void);
int main(int argc, char* argv[])
{
size_t jmp_size = (size_t)dummy_function - (size_t)shellcode_func;
return 0;
}
__declspec(naked) void shellcode_func(void) {
char (*jmp)();
jmp = (char*)&main - sizeof(shellcode);
jmp();
}
void dummy_function(void) {}
WARNING
After determining the code size is 16 bytes, using that exact code elsewhere can differ in size i.e., 17 bytes. The compiler chooses which registers to use and directly affects the number of opcode bytes generated.
char (*jmp)();
jmp = (char*)&main - sizeof(shellcode);
005E10D5 B9 C0 10 5E 00 mov ecx,offset main (05E10C0h)
005E10DA 81 E9 C0 00 00 00 sub ecx,0C0h
005E10E0 89 4D FC mov dword ptr [jmp],ecx
jmp();
005E10E3 FF 55 FC call dword ptr [jmp]
char (*jmp)();
jmp = (char*)&main - sizeof(shellcode);
005E11B0 B8 C0 10 5E 00 mov eax,offset main (05E10C0h)
005E11B5 2D C0 00 00 00 sub eax,0C0h
005E11BA 89 45 FC mov dword ptr [jmp],eax
jmp();
005E11BD FF 55 FC call dword ptr [jmp]
There is no way to do this in standard C.
But in practice - you can usually accomplish this with code like:
__declspec(naked) void shellcode_func(void) {
char (*jmp)();
jmp = (char*)&main - sizeof(shellcode);
jmp();
}
void dummy_function(void) {}
int main() {
size_t jmp_size = (size_t)dummy_function - (size_t)shellcode_func;
}
the __declspec(naked) attribute (available as __attribute__((naked)) in GCC) is necessary for ensuring that the shellcode function is defined without a function prologue or epilogue - thus maintaining its original size in bytes.
GCC and Clang have an extension to take label addresses:
(char *)&&jmp_code_finish - (char *)&&jmp_code_start
This question already has answers here:
How to get c code to execute hex machine code?
(7 answers)
Closed 2 years ago.
#include<stdio.h>
#include<stdlib.h>
char code[] ="\x52\x56\x57\x50\xB8\x41\x00\x00\x00\x50\xB8\x01\x00\x00\x00\xBF\x01\x00\x00\x00\x48\x89\xE6\xBA\x01\x00\x00\x00\x0F\x05\x58\x58\x5F\x5E\x5A\xC3";
int main(){
void(*func)() = (void (*)())code;
(*func)();
return 0 ;
}
what I have here is a string which stores a binary code to print a character ('A') , I pass it as a function pointer to func , than i try to execute it .
the output :
$ ./test
Segmentation fault (core dumped)
this is the assembly code :
0: 52 push rdx
1: 56 push rsi
2: 57 push rdi
3: 50 push rax
4: b8 41 00 00 00 mov eax,0x41
9: 50 push rax
a: b8 01 00 00 00 mov eax,0x1
f: bf 01 00 00 00 mov edi,0x1
14: 48 89 e6 mov rsi,rsp
17: ba 01 00 00 00 mov edx,0x1
1c: 0f 05 syscall
1e: 58 pop rax
1f: 58 pop rax
20: 5f pop rdi
21: 5e pop rsi
22: 5a pop rdx
23: c3 ret
As pointed out by #WeatherVane, you need permission to execute a data segment, mprotect can help:
#include <stdio.h>
#include <sys/mman.h>
#include <stdint.h>
static char code[] = "\x52\x56\x57\x50\xB8\x41\x00\x00\x00\x50\xB8\x01\x00\x00"
"\x00\xBF\x01\x00\x00\x00\x48\x89\xE6\xBA\x01\x00\x00\x00"
"\x0F\x05\x58\x58\x5F\x5E\x5A\xC3";
int main(void)
{
uintptr_t page = (uintptr_t)code & -4095ULL;
mprotect((void *)page, 4096, PROT_READ | PROT_EXEC | PROT_WRITE);
void (*func)(void) = (void (*)(void))code;
func();
return 0;
}
You can see the result (A) in godbolt
I've created the following function in c as a demonstration/small riddle about how the stack works in c:
#include "stdio.h"
int* func(int i)
{
int j = 3;
j += i;
return &j;
}
int main()
{
int *tmp = func(4);
printf("%d\n", *tmp);
func(5);
printf("%d\n", *tmp);
}
It's obviously undefined behavior and the compiler also produces a warning about that. However unfortunately the compilation didn't quite work out. For some reason gcc replaces the returned pointer by NULL (see line 6d6).
00000000000006aa <func>:
6aa: 55 push %rbp
6ab: 48 89 e5 mov %rsp,%rbp
6ae: 48 83 ec 20 sub $0x20,%rsp
6b2: 89 7d ec mov %edi,-0x14(%rbp)
6b5: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
6bc: 00 00
6be: 48 89 45 f8 mov %rax,-0x8(%rbp)
6c2: 31 c0 xor %eax,%eax
6c4: c7 45 f4 03 00 00 00 movl $0x3,-0xc(%rbp)
6cb: 8b 55 f4 mov -0xc(%rbp),%edx
6ce: 8b 45 ec mov -0x14(%rbp),%eax
6d1: 01 d0 add %edx,%eax
6d3: 89 45 f4 mov %eax,-0xc(%rbp)
6d6: b8 00 00 00 00 mov $0x0,%eax
6db: 48 8b 4d f8 mov -0x8(%rbp),%rcx
6df: 64 48 33 0c 25 28 00 xor %fs:0x28,%rcx
6e6: 00 00
6e8: 74 05 je 6ef <func+0x45>
6ea: e8 81 fe ff ff callq 570 <__stack_chk_fail#plt>
6ef: c9 leaveq
6f0: c3 retq
This is the disassembly of the binary compiled with gcc version 7.5.0 and the -O0-flag; no other flags were used. This behavior makes the entire code pointless, since it's supposed to show how the stack behaves across function-calls. Is there any way to achieve a more literal compilation of this code with a at least somewhat up-to-date version of gcc?
And just for the sake of curiosity: what's the point of changing the behavior of the code like this in the first place?
Putting the return value in a pointer variable seems to change the behavior of the compiler and it generates the assembly code that returns a pointer to stack:
int* func(int i) {
int j = 3;
j += i;
int *p = &j;
return p;
}
I wanted to understand a litte more about assembly and wrote a little example:
#include <stdio.h>
#include <math.h>
void f() {
unsigned char i[4];
i[0] = 5;
i[1] = 6;
i[2] = 7;
i[3] = 8;
int j = 0;
for(j=0; j < 20; j++)
printf("%02X\n", i[j]);
}
int main() {
int i[5];
i[0] = 3;
i[1] = 3;
i[2] = 3;
i[3] = 3;
i[4] = 3;
f();
return 0;
}
My goal was to see the actual return address for the instruction pointer, laid down by the call to
callq in main(), when it started f().
I used gdb to disassemble main() and got the following
Dump of assembler code for function main:
0x0000000100000eb0 <main+0>: push %rbp
0x0000000100000eb1 <main+1>: mov %rsp,%rbp
0x0000000100000eb4 <main+4>: sub $0x20,%rsp
0x0000000100000eb8 <main+8>: movl $0x3,-0x1c(%rbp)
0x0000000100000ebf <main+15>: movl $0x3,-0x18(%rbp)
0x0000000100000ec6 <main+22>: movl $0x3,-0x14(%rbp)
0x0000000100000ecd <main+29>: movl $0x3,-0x10(%rbp)
0x0000000100000ed4 <main+36>: movl $0x3,-0xc(%rbp)
0x0000000100000edb <main+43>: callq 0x100000e40 <f>
0x0000000100000ee0 <main+48>: movl $0x0,-0x8(%rbp)
0x0000000100000ee7 <main+55>: mov -0x8(%rbp),%eax
0x0000000100000eea <main+58>: mov %eax,-0x4(%rbp)
0x0000000100000eed <main+61>: mov -0x4(%rbp),%eax
0x0000000100000ef0 <main+64>: add $0x20,%rsp
0x0000000100000ef4 <main+68>: pop %rbp
0x0000000100000ef5 <main+69>: retq
so i was expecting to find the laid down instruction pointer return address to be 0x0000000100000ee0, as this is the next instruction after callq. When I run my program I get ( I grouped these in groups of 4 so you can read them better):
05
06
07
08
40
1B
08
56
FF
7F
00
00
E0
EE
B7
09
01
00
00
00
00
00
00
00
03
00
00
00
03
00
00
00
03
00
00
00
03
00
00
00
Ok, so I can see my 5,6,7,8 that I wrote into my local variable in f() and I can see the local variables of main() those 4-byte integers, which have been set to 3. After 5,6,7,8 (this is a 64 bit system) I would have expected the next 8 bytes to encode the previous value of the %rbp register, and THEN the
next 8 bytes to contain the return address for the instruction pointer. So the return address should be
E0
EE
B7
09
01
00
00
00
Now when I compare this to the 0x0000000100000ee0 that I am expecting from gdb, I can see the 00000001 in the last 4 bytes and I can see the e0 from 00000ee0 in the very first byte. But why am I not getting exactly what I am expecting? I thought about byte-ordering (Mac OS X is little endian I believe), but that would not explain what I see here, from what I understood.
Any input is welcome,
Thank you guys,
Christoph
Try this program and run it multiple times.
#include <stdio.h>
int
main(int argc, char **argv)
{
int foo;
printf("%p %p\n", main, &foo);
return 0;
}
I'm pretty sure that you'll get different addresses every time. MacOS has position independent binaries and the stack changes positions all the time too. This is a security feature.
If you run your program in gdb, you'll probably get what you expect since gdb disables the randomization to make debugging easier.
The dump of the following C program:
int main() {
int i,j;
for(i=0; i<2; i++) {
j++;
}
return 0;
}
is producing:
08048394 <main>:
int main() {
8048394: 8d 4c 24 04 lea 0x4(%esp),%ecx
8048398: 83 e4 f0 and $0xfffffff0,%esp
804839b: ff 71 fc pushl -0x4(%ecx)
804839e: 55 push %ebp
804839f: 89 e5 mov %esp,%ebp
80483a1: 51 push %ecx
80483a2: 83 ec 10 sub $0x10,%esp
int i,j;
for(i=0; i<2; i++) {
80483a5: c7 45 f8 00 00 00 00 movl $0x0,-0x8(%ebp)
80483ac: eb 08 jmp 80483b6 <main+0x22>
j++;
80483ae: 83 45 f4 01 addl $0x1,-0xc(%ebp)
int main() {
int i,j;
for(i=0; i<2; i++) {
80483b2: 83 45 f8 01 addl $0x1,-0x8(%ebp)
80483b6: 83 7d f8 01 cmpl $0x1,-0x8(%ebp)
80483ba: 7e f2 jle 80483ae <main+0x1a>
j++;
}
return 0;
80483bc: b8 00 00 00 00 mov $0x0,%eax
}
No matter whether I put i<2 or i<10, I am seeing two main()'s with the same structure. Can someone tell me why this is happening?
You are not seeing two main()s. You are seeing a disassembler utterly confused out of its mind by a for loop. The actual assembly, if you read it all the way through, represents exactly one function, main(), and the logic path is identical to the C code.
In short: the C interleaved into the assembly is wrong.
The disassembler is dutifully interleaving the source code exactly as the compiler's output debug information says. On Linux, you can see this with objdump -W:
…
Line Number Statements:
Extended opcode 2: set Address to 0x80483e4
Copy
Special opcode 91: advance Address by 6 to 0x80483ea and Line by 2 to 3
Special opcode 132: advance Address by 9 to 0x80483f3 and Line by 1 to 4
Special opcode 60: advance Address by 4 to 0x80483f7 and Line by -1 to 3
Special opcode 148: advance Address by 10 to 0x8048401 and Line by 3 to 6
Special opcode 76: advance Address by 5 to 0x8048406 and Line by 1 to 7
Advance PC by 2 to 0x8048408
Extended opcode 1: End of Sequence
…
My compiler apparently differs a bit from yours, as the addresses are different, but you see how it works: the mapping between addresses in the output assembly and lines in the input source file is imprecise.