If all else fails, run “sudo find /opt/local/var/macports/build -name "wdg.*" -print” and it should print the locations of the files. NOTE: These files will only exist *after* attempting the build with macports, so attempt to build first (sudo port install ettercap-ng), and then look for the files. Hope this helps!

UPDATE:
After talking to people in IRC, I found the real root of this problem, wdg.h and wdc.h need to have #include <sys/types.h> included at the top of the file. At this time, I recommend you attempt the install using MacPorts by doing sudo port install ettercap-ng, let it fail, then go into the directory containing the macports build source, add the include into the 2 files, then run sudo port install ettercap-ng again, it will succeed and your copy of ettercap should work!

Thanks @ Raim in #macports and dmacks in #fink for helping track this down. You can see the bug here.

Original message below:

This is a continuation of the pthread error that I mentioned in a previous post

I finally got it working natively; you might be familiar with the following error when trying to compile ettercap-ng using either fink or natively:

gcc -DHAVE_CONFIG_H -I. -I. -I../../../../include -I/sw/include -O2 -funroll-loops -fomit-frame-pointer -Wall -I/sw/include -I/sw/include -I/sw/include -I/sw/include -g -O2 -c -o libwdg_a-wdg.o `test -f 'wdg.c' || echo './'`wdg.c
In file included from wdg.c:23:
./wdg.h:189: error: syntax error before 'u_char'
./wdg.h:189: warning: no semicolon at end of struct or union
./wdg.h:190: warning: type defaults to 'int' in declaration of 'border_color'
./wdg.h:190: warning: data definition has no type or storage class
./wdg.h:191: error: syntax error before 'focus_color'
./wdg.h:191: warning: type defaults to 'int' in declaration of 'focus_color'
etc etc, errors go on forever...

Well, after poking around in the code I was able to find where to fix the code so that it would compile. Open the directory src/interfaces/curses/widgets/ and edit the files wdg.c and wdg.h

Change all of the occurrences of “u_char” to “int” in these two files, you should now be able to compile without errors.

DISCLAIMER: I don’t know what kind of effect this will have on the curses interface, it will probably break the curses interface permanently, personally I use the text interface the entire time (so I run configure with --disable-gtk so I don’t have to deal with the hassle of installing the gtk/glib libraries), but at least you are able to compile, right?

I’ve tar’d up a patched version of the code and configure script (so you don’t get the pthread error). I am planning on hosting on navi.eight7.org, I will put it up and link to it when I’m able to access the machine (work firewall prevents it).

I’m still getting errors when ettercap tries to forward the packets, but I’m positive they are caused by linking to the wrong version of libnet, that has a different number of arguments to the libnet_write_raw_ipv4() function. If I get a fix I’ll post it here.

Download the script here.

Read about aimsnarf in the previous post about it.

Changes in this version:

• Trillian is now supported, as well as AOL’s AIM client. Most other clients should be supported too, I figured out the variable length/number of TLV fields in the packet, so aimsnarf is much smarter about decoding them
• Code cleaned up to be more readable
• Fixed some misc messages that were showing up, you still might see a few

Todos:

• Figure out what the heck iChat is doing, it doesn’t seem to be sending the same kind of data as all the other AIM clients
• Still do OTR stuff
• Maybe add support for different protocols?
• More testing!

If you find any bugs, send me a note or leave a comment. If you really want to help, you can send me some pcap data to analyze   If you have any feature requests, lemme know!

Firstly, download the script here.

aimsnarf.rb is a small (~200 lines) Ruby script that I’ve written to sniff and dump AOL IM messages to STDOUT. I wrote this an as alternative to aimsniff, because I really dislike having to install aimsniff and all of it’s dependancies when all I want is a simple text transcript. I really felt like the dsniff toolkit should have had something like this (they already have urlsnarf, filesnarf, etc) to be used for penetration testing.

The only thing aimsnarf requires is Ruby and the ruby-pcap library (which is waaay easier to install than the 10+ CPAN modules that aimsniff requires). After installing the pcap library, simply run aimsnarf.rb on the console, here’s the usage:

Use '-h' to display usage
Usage: aimsnarf.rb [ -dnv ] [ -i interface | -r file ] [ -c count ] [ -s snaplen ] [ filter ]
Options:
-n do not convert address to name
-d debug mode
-v verbose mode

Due to the way that ruby-pcap works, I don’t have control over the usage displayed, currently the only real options you should mess with are ‘-i interface‘ and ‘-r file‘, changing anything else might produce “unknown” consequences ;). If you want to see hex dumps of the AIM data, edit the script and change the line “ap.data_debug(0)” to be “ap.data_debug(1)“, this will display the hex data as it is received.

Ignore the “pcap.bundle: warning: do not use Fixnums as Symbols” warnings you get when you run the program, the warning lies with the ruby-pcap library, so it’s out of my hands to fix. When run correctly, you should see something like this:

****** --> <you>: <HTML>what're you up to?</HTML>
<you> --> ******: <HTML>doing some stuff</HTML>
****** --> <you>: <HTML>awesome</HTML>
<you> --> ******: <HTML>talkity talk talk</HTML>
etc, etc

“******” will be the screen name of the person that’s talking. Yes, AIM sends the HTML tags, I don’t put those on.

Tangent:
Let’s talk a little bit about how much I hate the AIM protocol
Take a look at the protocol listing as given from ethereal, you can see that each AIM packet actually holds a pretty good amount of information, turns out, AOL decided to make a ton of their fields variable length, which means a headache for me in decoding it, because the length has to be read, translated, then used to set the offset for reading the data, this is the reason the code for the script is incredibly messy, I plan on cleaning it up at a later time. In a future post, I’ll also go into more detail about how this particular script decodes the protocol (very much hackish at the moment).

Known Issues:

• Messages received by people who are away don’t get intercepted due to the packet being different than a regular incoming message packet
• Different clients might not work (depending on the features supported). Right now I’ve tested with GAIM/Pidgin and Adium, it looks like Trillian isn’t working correctly yet, although I’ve collected some data for analysis so I can get it working.
• This is probably the first *useful* script I’ve written in Ruby. I am not a ruby master so the code is really messy and probably badly written, have a problem with it? Send a patch!
• OTR encrypted chat interception doesn’t work (duh)

TODO (no particular order):

• Clean up code to make it easier to extend to different protocol/clients
• Fix the Trillian problem
• Test with AOL’s AIM client
• Fix the incoming/away message
• Correctly detect OTR chat and do (something?) about it

Remember people, don’t send credit card numbers, social security numbers, passwords, PIN numbers, etc over IM, ESPECIALLY when you’re somewhere like a coffeeshop using public wifi.

Thanks to the HeX LiveCD team for putting out a great release, already having the tools installed for use in a system is super helpful

Questions? Problems? Patches? Hatemail? Email me or leave a comment below!