Re: Code working with LIBNET_RAW4, not with LIBNET_LINK

Mike Schiffman <[email protected]> Thu, 20 Jan 2005 10:14:56 -0800
Newsgroups gmane.comp.security.libnet,gmane.spam.detected
Message-ID <[email protected]>
Dump the relevant code to the list.

PS: Why would you expect to see bi-directional IP traffic from <Source> 
to <Target> using udp2.c or tcp1.c? As you noted, they're using 
non-legit MAC addresses. In fact, assuming your host OS allows you to 
spoof the source MAC address, you should only see the outgoing UDP and 
TCP packets, with no response from <Target>. If you want to try an 
experiment, go ahead and replace the hardcoded enet_src and enet_dst 
with the proper MAC addresses of the machines in question.

PPS: If you want sample code of dynamic MAC address assignment, check 
out Firewalk 5.0 (http://www.packetfactory.net/projects/firewalk).

On Jan 20, 2005, at 12:32 AM, Karen Pease wrote:

> On Wednesday 19 January 2005 2:10 pm, you wrote:
>> Read through the sample code that comes with libnet
>> (www.packetfactory.net/libnet). This sounds like a simple problem that
>> could be solved by seeing the relevant code.
>
> Actually, I did run into these previously when searching the net; they 
> were no
> help.  They don't work, and I can't see how they would work.  For 
> example,
> lets look at the one that's closest to what I'm doing - udp2.c.  It 
> sets the
> destination mac to the value of enet_dst.  This variable isn't 
> modified at
> all in udp2.c - it is defined, initialized, and never changed in
> libnet_test.h, as:
>
> u_char enet_dst[6] = {0x00, 0x10, 0x67, 0x00, 0xb1, 0x86};
>
> A preset hwaddr?  How could that possibly work?
>
> It doesn't, at least when I've tried it.  Lets call my machine Source, 
> and the
> other machine Target.  First off, I shut off iptables on Source and 
> Target,
> just in case.  Now, running tcpdump on the target machine as follows:
>
> [root@ipl3 kpease]# /usr/sbin/tcpdump | grep <Source>
> tcpdump: listening on eth0
>
> Now, lets test the tcpdump by pinging the computer:
>
> 02:15:24.398157 <Source> > <Target>: icmp:echo request (DF)
> 02:15:26.044271 <Source> > <Target>: icmp:echo request (DF)
> 02:15:26.470916 <Source> > <Target>: icmp:echo request (DF)
>
> Etc.  So, we know it's working.  So, I try:
>
> while true; do ./udp2 -s <Source> -d <Target> -P 22; done
>
> Not a thing shows up (port 22 is not only unblocked, but open and 
> recieving
> connections, as evidenced from nmap from Source).  So, lets try tcp 
> there:
>
> while true; do ./tcp1 -s <Source>:30000 -d <Target>.22; done
>
> Not a thing.  Once again, it's using that hard coded mac addr, so I 
> can't see
> how it would make it.
>
> So, enough with the samples - to my code.  Here's what gets sent when 
> I use
> LIBNET_RAW4:
>
> 00:31:45.778733 IP <Source>.30000 > <Target>.http: UDP, leng
>         0x0000:  0020 e035 5440 0050 046c e730 0800 4500  
> [email protected].
>         0x0010:  0026 8d68 0000 4011 1d41 c0a8 0003 81ff  
> .&[email protected]......
>         0x0020:  8d73 7530 0050 0008 ba3f 0102 0304 0506  
> .su0.P...?......
>         0x0030:  7465 7374                                test
>
> And here is with LIBNET_LINK
>
> 00:34:07.799767 IP <Source>.30000 > <Target>.http: UDP, leng
>         0x0000:  0004 758f 1153 0050 046c e730 0800 4500  
> ..u..S.P.l.0..E.
>         0x0010:  0026 0000 0000 4011 aaa9 c0a8 0003 81ff  
> .&....@.........
>         0x0020:  8d73 7530 0050 0008 ba3f 0102 0304 0506  
> .su0.P...?......
>         0x0030:  7465 7374                                test
>
> Looking at the ethernet header, we find:
>
> LIBNET_RAW4: Dest MAC: 00 20 e0 35 54 40
> LIBNET_LINK: Dest MAC: 00 04 75 8F 11 53
>
> Source MAC: 00 50 04 6C E7 30
>
> Ethertype: 08 00
>
> What I don't get is why LIBNET_RAW uses 00 20 e0 35 54 40.  Because, 
> in my
> test case, I hard-coded the target machine's mac addr - here's its 
> output
> from ifconfig:
>
> eth0      Link encap:Ethernet  HWaddr 00:04:75:8F:11:53
>           inet addr:<Target>  Bcast:<TargetBcast> Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:8662615 errors:0 dropped:0 overruns:1 frame:0
>           TX packets:1625176 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:2317535814 (2210.1 Mb)  TX bytes:996608893 (950.4 
> Mb)
>           Interrupt:17 Base address:0xd400
>
> So, in short, I'm confused.
>
>  - Karen
>
>
--
Mike Schiffman, CISSP
http://www.packetfactory.net/schiffman
Doveryay No Proveryay