Hi,
I try to run this code: ipt_evil.c - ipt-evil - A userspace iptables QUEUE that does "evil" things to packets. - Google Project Hosting . But I get this error: Socket opertaion on non-socket - Pastebin.com Could anyone tell me what is wrong here?
MC
We are not keen to take part in evil activities.
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
I am not going to do nothing bad. This is for my studies. Do you think I would keep the original C code If I wanted to do smth evil?
The first thing to do is compile your code with the -g flag, so that when it dumps a stack trace...
passer: Failed to receive netlink message: Socket operation on non-socket
*** glibc detected *** ./A: double free or corruption (fasttop): 0x00000000013f5010 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7e626)[0x7fcd4f05c626]
/lib/libipq.so.0(ipq_destroy_handle+0x18)[0x7fcd4f39bfb8]
./A[0x400af6]
./A[0x400e23]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fcd4efff76d]
./A[0x400a19]
You'll get a list of function names rather than just hex addresses.
This will at least tell you where in the code the crash originated.
The next telling thing is the heap corruption, which probably means you trashed memory somewhere.
The fact that you're dumping 64-bit pointers also means that you need to be wary of certain kinds of casting operations.
For example
Linux/include/linux/netfilter_ipv4/ip_queue.h
Assuming that unsigned long is a 32-bit integer in ipq_packet_msg_t
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I get this with -rdynamic. -g flag doesnt do anything.
/lib/x86_64-linux-gnu/libc.so.6(+0x7e626)[0x7f4272d83626]
/lib/libipq.so.0(ipq_destroy_handle+0x18)[0x7f42730c2fb8]
./A[0x400c46]
./A(main+0xef)[0x400f73]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f4272d2676d]
./A[0x400b69]
Also I get this with gdb bt:
#0 0x00007ffff7850445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff7853bab in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff788de2e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff7898626 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff7bd7fb8 in ipq_destroy_handle () from /lib/libipq.so.0
#5 0x0000000000400c46 in die (h=0x603010) at A.c:66
#6 0x0000000000400f73 in main (argc=1, argv=0x7fffffffe138) at A.c:156
Thank you Salem.
MC
Show us exactly how you compile this, starting with the gcc command.
Because
gcc -g prog.c
should show you function names in the stack trace when it crashes.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Sorry Salem. I understood you incorrectly and compiled this with other flags too. Now I get this:
/tmp/ccaUJtDN.o: In function `die':
/home/dell/Desktop/Geri/A.c:65: undefined reference to `ipq_perror'
/home/dell/Desktop/Geri/A.c:66: undefined reference to `ipq_destroy_handle'
/tmp/ccaUJtDN.o: In function `main':
/home/dell/Desktop/Geri/A.c:143: undefined reference to `ipq_create_handle'
/home/dell/Desktop/Geri/A.c:147: undefined reference to `ipq_set_mode'
/home/dell/Desktop/Geri/A.c:154: undefined reference to `ipq_read'
/home/dell/Desktop/Geri/A.c:158: undefined reference to `ipq_message_type'
/home/dell/Desktop/Geri/A.c:161: undefined reference to `ipq_get_msgerr'
/home/dell/Desktop/Geri/A.c:170: undefined reference to `ipq_get_packet'
/home/dell/Desktop/Geri/A.c:176: undefined reference to `ipq_set_verdict'
/home/dell/Desktop/Geri/A.c:198: undefined reference to `ipq_set_verdict'
collect2: ld returned 1 exit status
Edit: Could it be smth with libraries?
Edit2: I always compile it like this: gcc -Wall A.c -o A -lipq
MC
Last edited by MiniComa; 08-20-2012 at 12:38 PM.
Oh dear.....
I didn't mean for you to take the command literally!
Let's assume that you have
gcc -o A A.c -lwhatever
Where 'whatever' is the name of a library (one which resolves ipq_create_handle etc).
Now to get debug symbols, you do this
gcc -g -o A A.c -lwhatever
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
But it doesnt show any errors then.Originally Posted by Salem
And if I take code from libipq manual page: http://linux.die.net/man/3/libipq it works fine.
Last edited by MiniComa; 08-20-2012 at 12:45 PM.
Sorry Salem again. I found my mistake. Had comments on one of the lines and hadnt see it. But now it shows another one. I get: "passer" after I try to execute code. I will try to find answer to this by myself.
Thank you for all your help.
MC
