i'm trying to execute a buffer overflow attack on a program written in c, i'm using GNU/Linux (Ubuntu 16.04 LTS).
this is the source code:
#include<stdio.h>
void CALLME(){
puts("successful!");
}
int main(void){
char s[16];
scanf("%s",s);
}
what i want to do is override the return address of main so that after main function, the function CALLME will be executed.
i compile the program with
gcc -m32 -fno-stack-protector -o prog prog.c
use command:
nm prog | grep CALLME
i got the address of CALLME: 0804845b
disassemble main in gdb i found that: during main function, the return address is located at 8(%ebp) and the address of string s is at -0x18(%ebp). So the difference is 0x8 + 0x18 = 32
i try to exploit:
perl -e 'print "a" x 32 . "\x5b\x84\x04\x08"' | ./main
it didn't work.
Segmentation fault (core dumped)
Why ? Is main function more special ? Because in other functions (i made) that have a similar vulnerability it works ?
NOTE: i don't think about ASLR, some guys said that happens only when i compile gcc -pie ... and other stuffs.
We are using dlopen to read in a dynamic library on Mac OS X. Update:
This is a posix problem, the same thing fails under cygwin.
First the compile. On cygwin:
extern "C" void foo() { }
g++ -shared foo.c -o libfoo.so
nm -D libfoo.so
displays no public symbols. This appears to be the problem. If I could make them public, nm -D should display them.
Using:
nm libfoo.so | grep foo
000000x0xx0x00x0x0 T _foo
you can see the symbol is there. In Linux, this does seem to work:
nm -D foo.so
0000000000201020 B __bss_start
w __cxa_finalize
0000000000201020 D _edata
0000000000201028 B _end
0000000000000608 T _fini
0000000000000600 T foo
w __gmon_start__
00000000000004c0 T _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
However, even in Linux, we cannot seem to connect to the library. Here is the source code:
include
include
using namespace std;
int main() {
void* so = dlopen("foo.so", RTLD_NOW);
if (so = nullptr) {
cerr << "Can't open shared library\n";
exit(-1);
}
#if 0
const void* sym = dlsym(so, "foo");
if (sym == nullptr) {
cout << "Symbol not found\n";
}
#endif
dlclose(so);
}
If we remove the #ifdef, the above code prints "Symbol not found"
but it crashes on the dlclose.
We tried exporting LD_LIBRARY_PATH=. just to see if the library cannot be reached. And the dlopen call seems to work in any case, the return is not nullptr.
So to summarize, the library does not seem to work on Mac and Cygwin. On Linux nm -D shows the symbol in the library, but the code to load the symbol does not work.
In your example, you wrote if (so = nullptr) {, which assigns nullptr to so, and the condition is always false. -Wall is a good idea when debugging!
This alone explains why you can't load the symbol, but I also found that I needed to do dlopen("./foo.so", RTLD_NOW); because dlopen otherwise searches library paths, not the current directory.
I followed this below webpage to install ATLAS + Lapack in linux :
http://math-atlas.sourceforge.net/atlas_install/node6.html
bunzip2 -c atlas3.10.1.tar.bz2 | tar xfm - # create SRCdir
mv ATLAS ATLAS3.10.1 # get unique dir name
cd ATLAS3.10.1 # enter SRCdir
mkdir Linux_C2D64SSE3 # create BLDdir
cd Linux_C2D64SSE3 # enter BLDdir
../configure -b 64 -D c -DPentiumCPS=2400 \ # configure command
--prefix=/home/whaley/lib/atlas \ # install dir
--with-netlib-lapack-tarfile=/home/whaley/dload/lapack-3.4.2.tgz
make build # tune & build lib
make check # sanity check correct answer
make ptcheck # sanity check parallel
make time # check if lib is fast
make install # copy libs to install dir
After that , I try to run an sample in
http://www.netlib.org/lapack/lapacke.html
the sample code :
#include <stdio.h>
#include <lapacke.h>
int main (int argc, const char * argv[])
{
double a[5*3] = {1,2,3,4,5,1,3,5,2,4,1,4,2,5,3};
double b[5*2] = {-10,12,14,16,18,-3,14,12,16,16};
lapack_int info,m,n,lda,ldb,nrhs;
int i,j;
m = 5;
n = 3;
nrhs = 2;
lda = 5;
ldb = 5;
info = LAPACKE_dgels(LAPACK_COL_MAJOR,'N',m,n,nrhs,a,lda,b,ldb);
for(i=0;i<n;i++)
{
for(j=0;j<nrhs;j++)
{
printf("%lf ",b[i+ldb*j]);
}
printf("\n");
}
return(info);
}
I have found out the build library has no iblapacke.a , so I build this library by myslef
cd lapack-3.4.2
cp make.inc.example make.inc
cd lapacke
make
Then , finally I have the iblapacke.a now , so I compile the sample above by :
g++ test3.cpp liblapacke.a -o test3.exe
I get the following errors :
liblapacke.a(lapacke_dgels_work.o): In function `LAPACKE_dgels_work':
lapacke_dgels_work.c:(.text+0x1dd): undefined reference to `dgels_'
lapacke_dgels_work.c:(.text+0x2b7): undefined reference to `dgels_'
After I google , I have found :
http://www.netlib.org/lapack/explore-html/d7/d3b/group__double_g_esolve.html
Functions/Subroutines
subroutine dgels (TRANS, M, N, NRHS, A, LDA, B, LDB, WORK, LWORK, INFO)
DGELS solves overdetermined or underdetermined systems for GE matrices
There is a function dgels , without underline , and in
http://shtools.ipgp.fr/www/faq.html#l4
I think the underline is added for accident ,
nm -A liblapacke.a |grep "dgels_"
liblapacke.a:lapacke_dgels.o: U LAPACKE_dgels_work
liblapacke.a:lapacke_dgels_work.o: U LAPACKE_dge_trans
liblapacke.a:lapacke_dgels_work.o:0000000000000000 T LAPACKE_dgels_work
liblapacke.a:lapacke_dgels_work.o: U LAPACKE_xerbla
liblapacke.a:lapacke_dgels_work.o: U dgels_
liblapacke.a:lapacke_dgels_work.o: U free
liblapacke.a:lapacke_dgels_work.o: U malloc
I think I should try to not avoid underline like build "dgels" not to "dgels" while build liblapack.a ,means I should change something build Lapack and ATLAS ,
just don't know how to do it ....Any suggestion is appreciated !!
Update : http://software.intel.com/sites/products/documentation/doclib/mkl_sa/11/mkl_lapack_examples/c_bindings.htm
I have no idea if related , -Ddgels=dgels_ is added , the same link error !!
see:
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=12&t=3336
for example:
gcc LinearEquation.c -Ilapack-3.5.0/lapacke/include/ -Llapack-3.5.0 -llapacke -llapack -lrefblas -lgfortran -o LinearEquation
the order of lapacke > lapack > refblas is important... also if you don't want to use the double step gcc gfortran, use -lgfortran
I had the exact same problem. You need to do it as follows:
gcc(or g++) -c -O3 -I ../include -o test.o test.c
and then
gfortran test.o ../liblapacke.a ../liblapack.a ../blas.a -o test.exe
You can then run it like so:
./test.exe
Basically, you need to follow the gcc compile with a gfortran compile. The -c option in the first command forces gcc to skip the linker. gfortran is then used to link the libraries.
You can learn more by looking at the makefile for the examples provided with LAPACKE.
I had the same problem (using g++), but fixed my problems by adding a -lblas and -lgfortran.
To resolve the issue, here are the steps I have done.
sudo apt-get install libblas-dev liblapack-dev gfortran
linking a -lblas and -lgfortran when it runs
I have one .cu file that contains my cuda kernel, and a wrapper function that calls the kernel. I have a bunch of .c files as well, one of which contains the main function. One of these .c files calls the wrapper function from the .cu to invoke the kernel.
I compile these files as follows:
LIBS=-lcuda -lcudart
LIBDIR=-L/usr/local/cuda/lib64
CFLAGS = -g -c -Wall -Iinclude -Ioflib
NVCCFLAGS =-g -c -Iinclude -Ioflib
CFLAGSEXE =-g -O2 -Wall -Iinclude -Ioflib
CC=gcc
NVCC=nvcc
objects := $(patsubst oflib/%.c,oflib/%.o,$(wildcard oflib/*.c))
table-hash-gpu.o: table-hash.cu table-hash.h
$(NVCC) $(NVCCFLAGS) table-hash.cu -o table-hash-gpu.o
main: main.c $(objects) table-hash-gpu.o
$(CC) $(CFLAGSEXE) $(objects) table-hash-gpu.o -o udatapath udatapath.c $(LIBS) $(LIBDIR)
So far everything is fine. table-hash-gpu.cu calls a function from one of the .c files. When linking for main, I get the error that the function is not present. Can someone please tell me what is going on?
nvcc compiles both device and host code using the host C++ compiler, which implies name mangling. If you need to call a function compiled with a C compiler in C++, you must tell the C++ compiler that it uses C calling conventions. I presume that the errors you are seeing are analogous to this:
$ cat cfunc.c
float adder(float a, float b, float c)
{
return a + 2.f*b + 3.f*c;
}
$ cat cumain.cu
#include <cstdio>
float adder(float, float, float);
int main(void)
{
float result = adder(1.f, 2.f, 3.f);
printf("%f\n", result);
return 0;
}
$ gcc -m32 -c cfunc.c
$ nvcc -o app cumain.cu cfunc.o
Undefined symbols:
"adder(float, float, float)", referenced from:
_main in tmpxft_0000b928_00000000-13_cumain.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Here we have code compiled with nvcc (so the host C++ compiler) trying to call a C function and getting a link error, because the C++ code expects a mangled name for adder in the supplied object file. If the main is changed like this:
$ cat cumain.cu
#include <cstdio>
extern "C" float adder(float, float, float);
int main(void)
{
float result = adder(1.f, 2.f, 3.f);
printf("%f\n", result);
return 0;
}
$ nvcc -o app cumain.cu cfunc.o
$ ./app
14.000000
It works. Using extern "C" to qualify the declaration of the function to the C++ compiler, it will not use C++ mangling and linkage rules when referencing adder and the resulting code links correctly.
I am building a 16 bit operating system. But character array does not seem to work.
Here is my example kernel code:
asm(".code16gcc\n");
void putchar(char);
int main()
{
char *str = "hello";
putchar('A');
if(str[0]== 'h')
putchar('h');
return 0;
}
void putchar(char val)
{
asm("movb %0, %%al\n"
"movb $0x0E, %%ah\n"
"int $0x10\n"
:
:"m"(val)
) ;
}
It prints:
A
that means putchar function is working properly but
if(str[0]== 'h')
putchar('h');
is not working.
I am compiling it by:
gcc -fno-toplevel-reorder -nostdinc -fno-builtin -I./include -c -o ./bin/kernel.o ./source/kernel.c
ld -Ttext=0x9000 -o ./bin/kernel.bin ./bin/kernel.o -e 0x0
What should I do?
Your data segment is probably not loaded in to the target. What are you doing after the link with your brand new kernel.bin file, which is in fact an elf file ?