I want to compile this old exploit to complete my exercise: https://www.exploit-db.com/exploits/895/.
After gcc repoted that <asm/page.h> was missing.
I searched around the net and found out that a number of headers in asm have been moved to:
/usr/src/linux-headers-4.0.0-kali1-common/include/asm-generic/
To make sure that the source file had everything it needed to compile, I made a link for each and every file in the above directory to:
/usr/include/asm
/usr/include/asm-generic
I ran gcc, this time, it didn't report missing <asm/page.h> but <linux/compiler.h>
After digging around, I found this:
<asm/page.h>
|
|---#include <asm-generic/getorder.h>
|
|--#include <linux/compiler.h> ==> missing
A simple locate linux/compiler.h showed me that compiler.h was in here
/usr/src/linux-headers-4.0.0-kali1-common/include/linux/compiler.h
Surely, I could make another link from that <linux/compiler.h> to /usr/include/linux.
But I don't really know how many of them are left and how many more links I have to make.
Is there any way to tell the compiler that it must fetch the header from the new include directory?
Or Am I missing something here?
I'm still new to linux, so any help is appreciated.
Note: I'm using Kali 2.0 64 bit and have installed/reinstalled build-essential
UPDATE:
I tried -I option:
gcc source.c -m32 -I /usr/src/linux-headers-4.0.0-kali1-common/include/
This time, gcc said that I need something from
/usr/src/linux-headers-4.0.0-kali1-common/arch/x86/include/
(=.=)
Related
I am trying to compile some source codes about UNIX scokets programs, on Linux I have no problems but on macOS I get stuck in front of types definition problems. I don't know how many details I can put here, but I'll try.
The source codes to be compiled are:
errlib.c
errlib.h
server_test.c
sockwrap.c
sockwrap.h
where the main is located in server_test.c.
To compile I use:
gcc -Wall -DTRACE -o server_test server_test.c errlib.c sockwrap.c
There are no problems running this on Linux, but on macOS I get more than 20 error and all of these are about a (perhaphs) missing definition of bool_t. I suppose something not working in /usr/include/rpc/* files located in macOS internal libraries.
So I looked for if <sys/types.h> is included in /usr/include/rpc/xdr.h and it seems to be not missing.
Some of the first lines of the gcc output are:
In file included from server_test.c:16:
/usr/include/rpc/xdr.h:126:3: error: type name requires a specifier or qualifier
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:126:10: error: function cannot return function type 'int (struct __rpc_xdr *, int *)'
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:128:3: error: type name requires a specifier or qualifier
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:10: error: function cannot return function type 'int (struct __rpc_xdr *, const int *)'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:3: error: duplicate member 'bool_t'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:126:3: note: previous declaration is here
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:136:3: error: type name requires a specifier or qualifier
bool_t (*x_getbytes)(struct __rpc_xdr *, char *, unsigned int);
...
and many others lines that are very similar.
For those who want to deepen, the sources are available here.
What could be the problem?
The bad answer
Issue solved by simply including <rpc/types.h> in the server_test.c source as follows:
#include <rpc/types.h>
The better one
This is a solution above is valid only for this server_test.c implementation.
If you want fix this issue "globally", you can follow follown steps:
disable SIP (how to? here)
get your macOS's xdr.h (from here /usr/include/rpc/xdr.h)
copy it elsewhere two times: one copy is for backup and modify the other one simply adding the required include (#include <rpc/types.h> and see the picture below)
overwrite your modified xdr.h onto the original one in /usr/include/rpc/
re-enable SIP
Here is how I did it:
I have recently been trying to compile dropbear for 64bit arch android devices. I got the program to compile and run, but when I log in to the server it kicks me off with an error.
I configured & compiled like so:
cp ../config.guess ../config.sub .
./configure --build=x86_64-windows --host=arm-linux-androideabi \
--disable-zlib --disable-largefile --disable-loginfunc \
--disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog \
CFLAGS='-Os -W -Wall -fPIE' LDFLAGS='-fPIE -pie'
make dropbear
The error:
CANNOT LINK EXECUTABLE: "/system/lib/libc++.so" is 32-bit instead of 64-bit
page record for 0x7f800b8010 was not found (block_size=32)
I believe the error is caused by dropbear linking sh and other executables to the library in wrong location.
The device has two locations for libc++
#1 /system/lib/libc++.so
#2 /system/lib64/libc++.so
How can I tell/force the compiled binary to use the lib(s) in
/sytem/lib64
If giving an example please show me exactly what needs to be added, so I can apply the information correctly. I'm almost sure the fix is simple but I'm not a programmer. I do this stuff when I'm desperate.
Turns out there was a hard link in srv-chansession.c that needed to be modified
From:
addnewvar("LD_LIBRARY_PATH", "/system/lib");
To:
addnewvar("LD_LIBRARY_PATH", "/system/lib64");
It may actually be better to comment out that line and let androids linkers take care of it.
Now I have working a working dropbear ssh server on my 64 bit android device.
I want to run serial commands from a Bealgebone to a 4Dsystems display. Therefore I copied the c library found here into a directory and created a test program main.c:
#include "Picaso_const4D.h"
#include "Picaso_Serial_4DLibrary.h"
int main(int argc,char *argv[])
{
OpenComm("/dev/ttyUSB0", B115200); // Matches with the display "Comms" rate
gfx_BGcolour(0xFFFF);
gfx_Cls();
gfx_CircleFilled(120,160,80,BLUE);
while (1) {}
}
Now when I do gcc -o main main.c its says
main.c:2:37: fatal error: Picaso_Serial_4DLibrary.h: No such file or
directory
So I try linking it:
gcc main.c -L. -lPICASO_SERIAL_4DLIBRARY
which gives me the same error. Then I tried to create a static library:
gcc -Wall -g -c -o PICASO_SERIAL_4DLIBRARY PICASO_SERIAL_4DLIBRARY.C
which gives me this:
PICASO_SERIAL_4DLIBRARY.C:1:21: fatal error: windows.h: No such file
or directory compilation terminated.
What am I doing wrong? the git page clearly says this library is created for people who do not run windows.
Thanks in advance!
You're not getting a linker error; you're getting a preprocessor error. Specifically, your preprocessor can't find Picaso_Serial_4DLibrary.h. Make sure that it's in your include path; you can add directories to your include path using the -I argument to gcc.
You've had two problems. First was the picaso_whatever.h file that couldn't be found. You fixed that with the -I you added. But, now, the picaso.h wants windows.h
What are you building on? WinX or BSD/Linux?
If you're compiling on WinX, you need to install the "platform sdk" for visual studio.
If you're using mingw or cygwin, you need to do something else.
If on WinX, cd to the C: directory. Do find . -type f -name windows.h and add a -I for the containing directory.
If under Linux, repeat the find at the source tree top level. Otherwise, there is probably some compatibility cross-build library that you need to install.
Or, you'll have to find WinX that has it as Picaso clearly includes it. You could try commenting out one or more of the #include's for it and see if things are better or worse.
If you can't find a real one, create an empty windows.h and add -I to it and see how bad [or good] things are.
You may need the mingw cross-compiler. See https://forums.wxwidgets.org/viewtopic.php?t=7729
UPDATE:
Okay ... Wow ... You are on the right track and close, but this is, IMO, ugly WinX stuff.
The primary need of Picaso is getting a serial comm port connection, so the need from within windows.h is [thankfully] minimal. It needs basic boilerplate definitions for WORD, DWORD, etc.
mingw or cygwin will provide their own copies of windows.h. These are "clean room" reimplementations, so no copyright issues.
mingw is a collection of compile/build tools that let you use gcc/ld/make build utilities.
cygwin is more like: I'd like a complete shell-like environment similar to BSD/Linux. You get bash, ls, gcc, tar, and just about any GNU utility you want.
Caveat: I use cygwin, but have never used mingw. The mingw version of windows.h [and a suite of .h files that it includes underneath], being open source, can be reused by other projects (e.g. cygwin, wine).
Under Linux, wine (windows emulator) is a program/suite that attempts to allow you to run WinX binaries under Linux (e.g. wine mywinpgm).
I git cloned the Picaso library and after some fiddling, I was able to get it to compile after pointing it to wine's version of windows.h
Picaso's OpenComm is doing CreateFile [a win32 API call]. So, you'll probably need cygwin. You're opening /dev/ttyUSB0. /dev/* implies cygwin. But, /dev/ttyUSB0 is a Linux-like name. You may need some WinX-style name like "COM:" or whatever. Under the cygwin terminal [which gives you a bash prompt], do ls /dev and see what's available.
You can get cygwin from: http://cygwin.com/ If you have a 64 bit system, be sure to use the 64 bit version of the installer: setup-x86_64.exe It's semi-graphical and will want two directories, one for the "root" FS and one to store packages. On my system, I use C:\cygwin64 and C:\cygwin64_packages--YMMV.
Note that the installer won't install gcc by default. You can [graphically] select which packages to install. You may also need some "devel" packages. They have libraries and .h files that a non-developer wouldn't need. As, docs mention, you can rerun the installer as often as you need. You can add packages that you forgot to specify or even remove ones that you installed that you don't need anymore.
Remember that you'll need to adjust makefile -I and/or -L option appropriately. Also, when building the picaso library, gcc generated a ton of warnings about overflow of a "large integer". The code was doing:
#define control_code -279
unsigned char buf[2];
buf[0] = control_code >> 8;
buf[1] = control_code;
The code is okay, and the warning is correct [because the code is sloppy]. If the code had done:
#define control_code -279
unsigned char buf[2];
buf[0] = (unsigned) control_code >> 8;
buf[1] = (unsigned) control_code;
it probably would have been silent. Use -Wno-overflow in your Makefile to get rid of the warnings rather that edit 50 or so lines
I am running a Eclipse for C/C++ using cygwin GCC. I need to get the library path of "libws2_32.a", which is in C:\cygwin\lib\w32api for me in windows. However I do not understand how this is translated into a cygwin-path.
I've tried stuff like:
/cygdrive/c/cygwin/lib/w32api
/lib/w32api
/usr/lib/w32api
Any ideas?
EDIT: update
Here's the make Eclipse log used for building, if it helps:
make all
Building target: Filesharing_core.dll
Invoking: Cygwin C Linker
gcc -L/cygdrive/c/cygwin/lib/w32api -shared -o"Filesharing_core.dll" ./src/test.o -llibws2_32.a
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibws2_32.a
collect2: ld returned 1 exit status
make: *** [Filesharing_core.dll] Error 1
It's not a problem with the path; it's a problem with the name of the library (the -l option).
Where you have entered libws2_32.a, instead enter ws2_32.
See the GCC manual for how the -l option works.
Generally, when asking for help with programming, don't describe, but show. Don't describe what you're doing; don't describe what you think the error is. Instead, show exactly what you're doing, show the exact code (or a cut down version that exhibits the same problem), and show the exact error message.
This way others don't have to guess as to what's wrong, and you are more likely to receive an answer right away that solves your problem.
You can use the find utility to find the file, although it may take a while.
find / -name libws2_32.a -print
Edit: Based on your edit to the question, simply move -llibws2_32.a to before ./src/test.o.
The folder C:\Opt\Cygwin\lib\w32api or whatever it is in your system is simply /lib/w32api from within Cygwin. The library you're looking for is /lib/w32api/libws2_32.a.
But I'm not sure what you're trying to achieve. I guess your Eclipse in running in Windows, and not from a Cygwin'ized version of Java? Why are you using Cygwin GCC? Do you want to compile for Cygwin? If not, MinGW or TDM-GCC would be the tool to pick.
If you do want to compile for the Cygwin environment using Eclipse (a combination I haven't tried), then user experience like the following might be helpful:
http://www.benjaminarai.com/benjamin_arai/index.php?display=/eclipsecygwingcc.php
(I simply googled: eclipse cygwin gcc)
I've compiled my C program using gcc 4.4.1 using the flag -g, but when I try to step through one of my functions in gdb version 7.0, I get the message:
"Single stepping until exit from function _DictionaryTree_getNodeList,
which has no line number information."
Can someone tell me why this is happening?
Just guessing, but is _DictionaryTree_getNodeList in another file that wasn't compiled with -g?
I had the same problem but in my case adding -g to the compiler wasn't enough so I used -ggdb as suggested by Manav.
In my case, the problem was version skew between gcc and gdb.
After landing here from search and none of these answers fit my situation, I figured out that (because of aliases / symlinks / Makefile / environment variables) I was accidentally using a newer GCC (4.8.x) and an older GDB (7.2). Stepping up to a newer version of GDB (7.8) fixed the problem. For some reason, using a newer GCC and older GDB didn't work.
I had this error message too but the source of my problem was different. If anyone is still having any problems, make sure you have #include <stdio.h> in your file, with the the appropriate brackets around stdio.h (the text message would not show up if I had it around stdio.h).
I had the same issue, when I compiled a file using -g option and without -g option.
For one of the file, the gdb showed line number without any issues(even when it was compiled without -g option)..
And for the other file, I had to explicitly mention -g flag...
Any ideas as to whether the source file could be loaded at run time in
GDB with cross referencing would be good solution... by mapping the
lines to the addresses :D.
I had this issue because I was debugging a shared library without pointing LD_LIBRARY_PATH to correct location with debug endstates.
you can use
export LD_LIBRARY_PATH=<location of the debug build of the .so file>:$LD_LIBRARY_PATH
Hopefully this is helpful to someone
I had the same trouble despite I was already compiling with -g2. Changing it to -g3 did the trick.
Im using GBD 12 , im not able to use any of these flags and options , also im debugging .exe file , so yes I used makefile