I am trying to run this code to get a shell but I am getting a segmentation fault even with ASLR disabled. I am running this code on my AMD Ryzen 3 computer with Ubuntu 20.04 64bit version.
I am compiling with the following command:
$ gcc -O0 -fno-stack-protector -z execstack getshell.c -o getshell
File getshell.c is as following:
#include <stdio.h>
unsigned char shellcode[] = \
"\x48\x31\xf6\x56\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x54\x5f\x6a\x3b\x58\x99\x0f\x05";
int main()
{
int (*ret)() = (int(*)())shellcode;
ret();
}
Edit: I found this piece of code here
unsigned char __attribute__((section(".text#"))) shellcode[]
works for me (mind the #)
# is a trick - it comments part of the emitted assembly code by gcc.
Related
I am running Xubuntu on a vm (because it was easier to do that compared to getting gcc on windows).
I have tried all of the different arguments for compiling the program (eg. running gcc filename.c and gcc filename.c -o filename), but none of them have changed the outcome.
My code is:
#include <stdio.h>
int main(void) {
printf("a");
return 0;
}
I've tried using main() and main(arg...[or whatever it is I can't remember]) and I get the same error.
I came across -nostartfiles and -nostdlib options under gcc compilation options. I, however, do not understand as to how one can write code for the above options. Do you need to write every startup function (like _start, __libc_csu_init etc.)?
Can I get a simplified code for both these options just to understand it's working?
Edit:
Also I just discovered that using static along with nostartfiles throws a segmentation fault. A simple c code to reproduce the same:
#include<stdio.h>
#include<stdlib.h>
void _start()
{
int x = main();
exit(x);
}
int main()
{
printf("Hello world!\n");
return 0;
}
Compiled using:
gcc -nostartfiles -static -o foo foo.c
The output to the above code is a segmentation fault. Is it the expected output?
Yes, this is expected behaviour.
If you want to write your own startup-code or your own standard library, you need these options, otherwise you could not write your own code as symbols would be duplicated.
I have a simple C "Hello world" program, compiled using GCC toolchain for mips74-kc running a Linux S/O (kernel 3.10.36)
#include <stdio.h>
int main() {
printf("Hello world\n");
return 0;
}
The program is compiled on a x64-86 Ubuntu machine, as I don't have GCC available on the MIPS machine. I compile the program with the static linking flag.
mips-linux-gnu-gcc --verbose -static -march=74kc main.c -o main
When I launch the program on the MIPS processor, the program holds and never returns, consuming 100 % of the CPU.
Does anyone have a clue on why this could happen?
I wrote some code in nasm and I'm trying to implement it in a C program as a replacement of strlen through a shared library, but it doesn't work.
nasm code:
section .text
global strlen:function
strlen:
mov rax, 42
ret
C code:
#include <stdio.h>
size_t strlen(const char *s);
int main()
{
printf("%zu\n", strlen("foobar"));
return (0);
}
I compile the C program just using gcc without any arguments, and I create the shared library with the following commands:
nasm -f elf64 strlen.asm
gcc -shared -fPIC -o libasm.so strlen.o
Finally, I include the shared library:
export LD_PRELOAD=`pwd`/libasm.so
But it displays '6' where I expect it to display '42'.
I don't think the problem comes from my library, because I get segmentation fault when I execute the ls command with LD_PRELOAD.
I'm working on Ubuntu 16.04.
This is not related to nasm at all. A C equivalent of your strlen() function does not work either.
$ cat strlen.c
#include <stddef.h>
size_t strlen(const char *s)
{
return 43;
}
$ cat s.c
#include <stdio.h>
size_t strlen(const char *s);
int main()
{
printf("%zu\n", strlen("foobar"));
return 0;
}
$ make s
cc s.c -o s
$ gcc -shared -fPIC -o strlen.so strlen.c
$ LD_PRELOAD=$PWD/strlen.so ./s
6
What is happening here is that gcc is using its own built-in version of strlen() that cannot be overridden. If the C program that calls strlen() is recompiled to not use this built-in version of strlen(), then your shared library can override it.
$ rm s
$ make s CFLAGS=-fno-builtin-strlen
cc -fno-builtin-strlen s.c -o s
$ LD_PRELOAD=$PWD/strlen.so ./s
43
$ LD_PRELOAD=$PWD/libasm.so ./s
42
I have a programe, which is so simple. The code as below.
I compiled it with
gcc -g -Wall -I../software/libxml2-2.9.0/include/
-lxml2 -L/usr/lib test.c -o test
I can absolutely run it with "./test", but when I run it with "gdb test" and then print "run" it will receive signal SIGSEGV. So I want to know what happened?
#include <libxml/xmlreader.h>
int main( void )
{
const char *file = "/usr/share/mime/application/javascript.xml";
xmlNewTextReaderFilename( file );
return 0;
}
If you are debugging using gdb test you may actually be debugging /bin/test rather that your own program. If the backtrace does not correspond to your expected program switch to gdb ./test (in a similar manner to how you are running the program as ./test)