I need a debug version of glibc.I have some doubts regarding the installation of glibc-2.29 from source in kali linux.Based on the post https://www.tldp.org/HOWTO/html_single/Glibc-Install-HOWTO/,
To install glibc you need a system with nothing running on it, since many processes (for example sendmail) always try to use the library and therefore block the files from being replaced. Therefore we need a "naked" system, running nothing except the things we absolutely need. You can achieve this by passing the boot option
init=/bin/bash to your kernel.
it says that we need to install the glibc in a single usermode environment.In another post https://www.tldp.org/HOWTO/Glibc2-HOWTO-5.html
single usermode is not required for installation but backing up the old libraries.I dont know which one to follow.Can anyone help?
I found that we can use glibc without installing but building from source by adding '-g' flag in ./configure and setting LD_LIBRARY_PATH varible as follows after building
LD_LIBRARY_PATH=/path/to/the/build_directory gdb -q application
Note: this solution only works when the system GLIBC and the built-from-source GLIBC exactly match, as explained here.
I need a debug version of glibc.
Most distributions supply ready-made libc6-dbg packages that match your installed GLIBC. This is the best approach unless you are a GLIBC developer (or plan to become one).
I have some doubts regarding the installation of glibc-2.29 from source in kali linux.
Installing / replacing system libc is almost guaranteed to render your system unbootable if there are any mistakes. Recent example.
Before you begin, make sure you either know how to recover from such a mistake (have a rescue disk ready and know how to use it), or you have nothing of value on the system and can re-image it from installation media in the likely case that you do make a mistake.
The document you referenced talks about upgrading from libc5 to libc6. It was last updated on 22 June 1998, and is more than 20 years old. I suggest you find some more recent sources. Current documentation does suggest doing make install while in single-user mode.
Related
I use gopacket in my program. on linux, it runs perfectly.
But on windows the whole program crashes if i did not install WinPcap before.
My plan was to check if WinPcap is installed, and if not to inform the user that he needs this to use 100% of all features.
But i dont come to this point. i cant use gopacket if WinPcap is not available. I mean... not a single line of code of it (=> crash)
Has anyone an idea how i can solve this? im do not need gopacket actually. My plan was, if it is installed, fine, super! If not, dont care... do other things.
But now i have 2 choices... remove gopacket totally or find a way to start my program without the need of wpcap.dll. at least to tell the user that he needs it.
Please help me :(
You're wrong in that you are «not [using] a single line of code of it»: it's not hard to see that
its Windows-specific code calls into winpcap.dll.
What is more fun, is that
its Unix-specific code calls into libpcap.so, and this means you have it working on your local system simply due to the fact you have libpcap package installed (or whatever it's named in your code).
All this means that currently your program is not really portable
anyway (I mean, in the sense you supposedly think it is portable).
You can run something like
$ ldd ./yourbinary
and see it printing a reference to libpcap.so of some version.
There are several ways to solve this.
The easiest is to just try shipping winpcap.dll with your binary. Windows by default looks for DLLs in the current directory of the application trying to load them. Since gopacket uses cgo, it means the winpcap.dll is attempted to be linked it at the application startup, so the application has no chance of changing its working directory before that library is attempted to be found and linked in.
A more complicated approach is to make (or obtain) a static version of the winpcap library (remember that DLL is a library, just a special form of it) and then jump around building gopacket so that it picks that static library.
Install Npcap in "Wpcap API compatibility mode".
I've just compiled BPF examples from kernel tools/testing/selftests/bpf and tried to load as explained in http://cilium.readthedocs.io/en/v0.10/bpf/:
% tc filter add dev enp0s1 ingress bpf \
object-file ./net-next.git/tools/testing/selftests/bpf/sockmap_parse_prog.o \
section sk_skb1 verbose
Program section 'sk_skb1' not found in ELF file!
Error fetching program/map!
This happens on Ubuntu 16.04.3 LTS with kernel 4.4.0-98, llvm and clang of version 3.8 installed from packages, iproute2 is the latest from github.
I suspect I'm running into some toolchain/kernel version/features mismatch.
What am I doing wrong?
I do not know why tc complains. On my setup, with a similar command, the program loads. Still, here are some hints:
I think the problem might come, as you suggest, from some incompatibility between kernel headers version and iproute2, and that some relocation fails to occur, although on a quick investigation I did not find exactly why it refuses to load the section. On my side I'm using clang-3.8, latest iproute2, but also the latest kernel (some commit close to 4.14).
If you manage to load the section somehow, I believe you would still encounter problems when trying to attach the program in the kernel. The feature called “direct packet access” is only present on kernels 4.7 and higher. This is what makes you able to use skb->data and skb->data_end in your programs.
Then as a side note, this program sockmap_parse_prog.c is not meant to be used with tc. It is supposed to be attached directly to a socket (search for SOCKMAP_PARSE_PROG in file test_maps.c in the same directory to see how it is loaded there). Technically this does not prevent one to attach the program as a tc filter, but it will probably not work as expected. In particular, the value returned from the program will probably not have a meaning that tc classifier hook will understand.
So I would advise to try with a recent kernel, and to see if you have more success. Alternatively, try compiling and running the examples that you can find in your own kernel sources. Good luck!
I have a GCC 3.4.3 toolchain built for ARM (arm-elf) here in my Windows 7 (64bits) setup. We use this to build our software product to a specific hardware.
Recently, we have been experiencing some problems with this particular toolchain.
First, when we try to call arm-elf-gcc to build each source file (there are lots of them), it complained about it not being able to allocate enough heap.
Then, I thought it was some problem with the outdated cygwin DLL distributed by the hardware vendor. So I replaced it with a more recent version (1.7.35). The problem stopped and the build does go ok but now it is incredibly SLOW (it took about 40s to build a single .c source file).
Does anyone has experienced this problem before? How can I debug and fix it?
Thanks in advance.
Sounds like you have had a similar problem to me and might be worth trying this. When i first encountered this, I had to install cygserver and then run this (make sure you right click admin):
Previous solution
However, the problem resumed and I simultaneously couldn't install/uninstall some problems. Eventually I resolved this by terminating SearchIndexer.exe in Task Manager. Indeed, I have gone in to Control Panel / Searach Indexing and pulled it back from doing any indexing. My installation taking 1hr took 3 more seconds. The change to Cygwin was instantaneous.
Cygwin is now flying!
I've had an issue with slow execution of builds for a while on cygwin, using make and a proprietary compiler that "isn't gcc, honest...", but has very similar error returns.
I was forced to update yesterday and ran into the issue of rebaseall simply failing to execute. This forced me to dig into other things and I found a report that Trusteer Rapport/End Point Protection has been known to cause issues with rebaseall,and slow response times. So I removed it. This fixed the rebaseall, but has also massively increased the speed of my build. Worth checking to see if you have it installed, try removing it. AV packages in general are reputed to interfere and may be the cause.
I am studying "Hacking: The Art of Exploitation". I am trying to follow the code examples, but for some reason the assembly codes simply does not match the one on my actual Linux (running on Virtual Box as Guest). I have made sure that I have installed 32 bit Linux OS. Is there any args that I can pass to gcc that lets me compile the code into an assembly that matches closely with the ones given in the book?
I would be fine reconciling the code differences between the book & what I see if they were minor, but the difference I see is stark. I somehow don't like to run the code from the "Preconfigured incubator environment" as this inhibits my skill development.
I've actually been in the same boat--for the last week or two I've tried a ton of ways to produce comparable assembly code in my normal development environment (LMDE), including chroot, compiling with the -m32 flag, installing an x86 ubuntu, etc, and nothing really worked. Today I found http://www.nostarch.com/hackingCD.htm and I followed the instructions and was able to get the livecd to boot in vmware workstation 10. Here's what I did:
Download the iso from the link above (though it should work with the
livecd as well)
Create a .vmx file and copy and paste the config from the link
I took out the section defining the cdrom device, since I was using an iso
Open the file with VmWare Workstation--if you are using the iso, go to "Edit VM Settings" and set up a cdrom device and point it to the iso
VM booted without any issues
I know this isn't as convenient as going through the examples in your main OS/system, and that you were trying to avoid using the LiveCD, but after doing a lot of research I've discovered that this is an extremely common issue and hopefully this answer helps someone. Using the LiveCD might not be ideal but it is still a heck of a lot better than dual booting.
for some reason the assembly codes simply does not match the one on my actual linux
The most likely reason is that the book was published in 2008, and used then-stable GCC (you can see GCC release history here).
GCC that you are using now is likely much newer, and so generates significantly different (and one hopes better) code.
Is there any args that I can pass to gcc that lets me compile the code into an assembly that matches closely with the ones given in the book?
No. You can try to compile and install a version from 2008, perhaps 4.2.3 or 4.3.0, and check whether that gives you closer output.
P.S. It looks like the first revision of the book is from 2003, and it's unlikely that the authors rebuilt all of their examples for the second edition in 2008, so perhaps try GCC 3.3 instead?
This is why the book comes with a LiveCD with a linux distro and all of the example source code from the book on there. All of the examples in the book match exactly with what will happen in the LiveCD.
Just run the included LiveCD using VirtualBox or VMware and follow along with the book using that. If you don't have the CD, it can be downloaded from a torrent provided by No Starch (linked from their website)
it doesn´t matter whether the output of gcc is different, the only thing it changes is the memory addresses; plus, you said u r using a VM to run it, meaning that the memory u will get is dummy memory, try booting the iso and run it directly, it will almost the same.
https://www.youtube.com/watch?v=pIN7oFkz5rM
I'm trying to get Wanderlust working in Windows to connect to Gmail. Compiling the code is much more painful than expected. Here are the barriers so far:
Can't download dependent packages: SEMI, APEL, and FLIM. I eventually found newer versions, but I'm not sure they will work. Anyone have the older versions?
Needs make and install. I used MSYS and it seems to have compiled okay.
SSL support. I was getting a "Cannot open load file: ssl" error. I found an ssl.el that comes with w3. So installed w3.
Bash command in ssl.el: ssl-get-command is running something from /bin/sh (not a directory I have in Windows). I really don't want to refactor this code. Is there a better way?
Others speak very highly of Wanderlust, so I want to give it a try. I feel like I'm almost there, but am pretty much worn out with all the crazy configuration I have to do. Does anyone have this working on Windows? I'm pretty sure it will work with Gmail, because of this post. But will it work in Windows too? If you have a few pointers, please help.
ssl.el is part of wanderlust. Just look in the wanderlust/utils directory.
For STARTTLS you may either use the starttls or gnutls-cli programs.
Unfortunately, both of these programs use signals (SIGALRM to be precise) which are not supported on Windows.
You need to use the Cygwin ports of these programs -- not MSYS!
Additionally, if you're using a Windows port of Emacs (ie. not Cygwin's emacs) you need to modify starttls.el (which is part of GNU Emacs) because the signal-process function doesn't do anything regarding SIGALRM. Replace all instances of
(signal-process (process-id process) 'SIGALRM)
with
(call-process kill-program nil nil nil
"-ALRM" (format "%d" (process-id process)))
and initialize kill-program somewhere apropriately to point to cygwin's kill.exe:
(setq kill-program "c:/cygwin/bin/kill.exe")
If you want to use SSL you have to set ssl-certificate-verification-policy to a value greater than 0. Otherwise connecting to Gmail would fail.
Using the wl configuration here:
http://box.matto.nl/emacsgmail.html
After adding ssl.el from here:
http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/contrib/ssl.el
I am able to get wanderlust talking just fine to gmail on a linux configuration of wanderlust, and since the ssl.el file there isn't really system-dependent (although it does require the openssl command-line tools), I don't see that there should be any problem with it working on msys.
The 'cannot open load file: ssl' error is exactly what I ran into until I installed that ssl.el file too :)
Edit; Just in case you have trouble finding it, the MSYS port of openssl you'll want is here:
http://sourceforge.net/projects/mingw/files/MSYS%20openssl/
[posted as a new answer since I think you'll get a notification that way :)]
I recently installed wl on a linux host, and had the same issue with not being able to locate the dependencies as specified. However, I, like you, found the 'more recent versions' and used them. They did indeed work fine, so unless those new versions have added any incompatibility with windows, they shouldn't present any problem.
The error you're receiving is because it's not finding the 'install' utility, which is part of GNU coreutils. Autotools (and it's family) depend on install being able to work, so if you want to continue with the cygwin method, then installing autotools should bring in the install program.
(I have no idea if wl will compile/work using cygwin otherwise, though.)