Collection of Hack-Phreak Scene Programs

home *** CD-ROM | disk | FTP | other *** search

/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / XINE-1.ZIP / XINE-1.013 < prev next >

Wrap

Text File | 1996-10-25 | 17KB | 356 lines

/-----------------------------\ | Xine - issue #1 - Phile 013 | \-----------------------------/ b0z0 and Kernel Panic proudly brings into your hands ------------------------------------------- | LowLevel Internet Hacking with Injector | ------------------------------------------- a) Introduction ---------------- This is an article dealing with low level aspects of TCP/IP. It comes toghether with a program, Injector, that helps to understand and to play with TCP/IP networks. Please have a look in the doc directory of Injector that you get with this zine. With Injector you can look for packets that pass on your ethernet and enter new packets entirely formatted by you. Even you can quite easily write C programs that looks for a specified packet and when they get it to respond adeguately. First of all a small intorduction to how TCP/IP works. This is only a brief survey, so don't expect to learn too much from it. Please refer to some good books (I personally prefer D.E. Comer's book "Internetworking with TCP/IP"). The definitive references for the Internet are the RFCs, but they aren't suited for first-time learning. The key to the functionality of Internet is layering. When an application on a given host transimits data to another host it is passed through many -more or less indipendent- protocol layers. Every layer does a part of work in sending the data. Because they are, at least conceptualy, indipendent, there can be different protocol specification for every layer. On the Internet we have three different layer: * The transport layer. This takes a stream of data from application and divides it in packets. It performs also a port multiplexing, so every applications on a machine has a port number. On the Internet the protocol for this layer are the TCP (Transport Control Protocol) and the UDP (User Datagram Protocol). The TCP additionaly assures (by retrasmission) that the data is correctly passed over the network. The packet generated by the transport layer are passed down to the next layer. * The internet layer. This assigns every host an unique identification (hardware indipendent) and handles routing of packet from the source route to the destination. It' doesn't assure that the packet is correctly delivered, this is a duty of the previsious layer or the application. Additionaly it provides that packets (which are now called datagrams) are of a suitable length for the next layer by eventually fragmenting them (and of coures reassembling them on the destination host). The protocol uses here is the IP (Internet Protocol). * The link layer. This depends on the various type of hardware connection. There can be broadcast networks, many host sharing the same medium -at least logically- or point to point links, i.e. two host linked togheter. In the former case the protocols used are mainly Blue Book Ethernet, IEEE 802 (Ethernet, Token Ring), X.25 in unconnected mode, in the later PPP (Point to Point Protocol), SLIP (Serial Line Internet Protocol) or so called virtual circuits (for example IP in IP encapsulation wormholes or X.25 in connected mode). Here the packet of date are called frames. Every layer adds to the packet some additional data for internal use (for example checksums, progressive numbers, host and port addresses, lengths, etc.). So when flowing on the communication medium the format of a frame is usually: link layer overhead, internet layer overhead, transport layer overrhead, useful application data. Additionaly there are other helper packets of various protocols, for example ARP and RARP for finding Ethernet addresses, LCP,IPCP and others for PPP conection negotiation, ICMP (Internet Control Message Protocol) as an aid to IP and others. Application data can be either from user-level application (FTP, Telnet, HTTP, etc,) or system applications (DNS for name resolving, NFS when we speak of exported file systems, RIP,EGP,BGP and such for route enstablishing). Both of them undergo the layering scheme. Keep in mind that system application (DNS, NFS and routing info) usually use UDP for efficency, instead user level applications use TCP for easyness because TCP already provides a reliable communication chanell. Injector is useful in understanding Ethernet networks. I have put a brief extract from the RFCs in this zine as reference for packet building, but get the full RFCs as soon as you can! b) A little Injector tutorial ----------------------------- - Creating packets If you want to know how to create a packet check the "Summary of useful data in building TCP/IP packets" and give a look at our included examples. Explaining how to create packets is a very hard thing, so I decided to include a reference so you may be able to do it yourself :) Here is just some stuff that you need to be able to create packets using the included summary. First of all, a tipical packet is like this: ------------------------------------ | Ethernet header | main packet | ------------------------------------ The ethernet header is needed and it is used to determinate from where this packet is, what it is etc. Be sure to include the 'e' charachter in the packet ('e' means end of the ethernet header) when you finished with the ethernet header. Then of course also the main packet is divided in various parts. Let see a TCPIP main packet: ------------------------------ | IP datagram | TCP packet | ------------------------------ In the same way the an UDPIP is: ------------------------------ | IP datagram | UDP packet | ------------------------------ And then, at it's time, the TCP (or UDP) is divided into various sub parts, but this is well explained in the summary. But this is only for packets that uses the Internet Protocol (IP) such as TCP, UDP, ICMP and EGP. For example the ARP (Adress Resolution Protocol) isn't preceeded by an IP datagram, so the main packet will be just composed from the ARP packet. Concluding with an example a TCP packet will look like: ------------------------------------------ | eth. header | IP datagram | TCP packet | ------------------------------------------ ...or better: ----------------------------------------------------- | Eth. header | IP datagram | TCP Header | TCP Data | ----------------------------------------------------- ...while the ARP which doesn't use the IP will simply be: ------------------------------------------ | eth. header | ARP packet | ------------------------------------------ So pay attention when creating packets and when reading the summary! This isn't a simple topic and i hope that you understanded this very-very short intro. But i repeat: get a good book or yell us :) - Injector as a packet sniffer Once you have entered in Injector (and configured the net hardware :) ) you'll be able to see what is going up in your local network. The console is divided in two parts: * the network watcher * the command part In the network watcher all the packets that pass over the network are displayed. Injector tryes to identify the packets types, their source and their destination and of course it displays it's contents. In the command part you can type the various commands that Injector offers to you. Also errors will be displayed here. If you are sniffing in a quite big local network you may be very confused by a great traffic of packets. To prevent this you may set a filter to the displayed output. Injector can filter the packets by: * Type of packet. You can only look for TCP/IP packets using the command "onlyip" and then turn back to all packet (ie. IPX) displaying by using the command "allpack". * Type of packet in IP datagram. You can look only for TCP packets using the "onlytcp" command and then set it back to full displaying (UDP, ICMP...) by using "allpkt" * Source port. You can watch only packet from a port using the command "maskpsrc [port number]". To watch again all the packet just set the port to 0. * Destination port. As for source port, but you must use the "maskpdst" command. * Source IP. You can watch only packet from an IP using the command "maskipsrc [ip adress]". To reset this set the IP to 0.0.0.0. Setting the IP to 192.12.0.0 means that packet from 192.12.*.* are displayed. * Destination IP. As for source IP but using the command "maskipdst". Of course if you would like to see what's up in the net for a lot of time it wouldn't be very pleasant to stay there day and night. And here comes the log options. There are two types of logging: * The normal log, which stores everything that you see on the network wathcer (type of packet, source, destination, contents and special stuff for some types of packet). This is activated by using the command "logon". The log session is closed with "logoff". The entire logging will be appended to the file INJECTOR.LOG. * The raw log, which store everything in a byte-by-byte log. Infact this type of log will store in a file (RAW.LOG) every byte that comed trought the network. This of course isn't very friendly if you would just to see what's going up in the network. The raw logging is infact present as a help for packet creation. Infact with the raw log you will have the opportunity to see how the packet _really_ is and this may be of help to you when you'll have to create your own packets. To activate the raw log you must just enter "do rawlog" and press a key to stop it. This are basically all the options that Injector used as a sniffer gives you. - Injecting packets This is the real power of Injector: you can send *everything* that you want (well, if the packet are someway logical and not just random data it is much better ;)) in your local network (and, of course, the local network will then send this ahead in the Internet if you want this). After we have created a packet we can now inject it. Injector may just send the packet by using "inject" function. If our packet is named ping.pkt (i suppose it is compiled and ready to be sent) our injecting session may look like this: set infile ping.pkt do inject we have just defined that the packet that we would like to inject is ping.pkt and then sent it. But we may also have to set an ethernet adress for source or destination of this packet. So let's do it: setmyeth 11:11:11:11:11:11 setethto 22:22:22:22:22:22 set filleth 1 set fillethto 1 set infile ping.pkt do inject we have just sent a packet with an ethernet header different from the packet file one. Infact we have set up the source (setmyeth) and the destination (setethto) hardware adress and then defined that we will fill the source adress (we set filleeth to a value. 1 is just for example) and the destination adress (we set fillethto). Then we finally sent the packet. Of course you may not know or you may not have the possibilty to know the hardware adress of a machine on your local network. So let's look how to get it (we suppose that you want to get the hardware adress of the IP 192.168.0.2) and set is as it was our ethernet adress: set arpip 192.168.0.2 do getarp In this way we now will have defined as our ethernet adress the ethernet adress of the machine with the IP equal to 192.168.0.2. Infact the "do getarp" functions send an ARP request, which is, in a few words, a request for the harware adress for an IP. Of course if the machine doesn't exist or is down the program will tell us that the adress haven't been set. We can also do the same for the destination ethernet adress. Just do: set arpip 192.168.0.1 do getarpto that's it. Pay attention! If you are working on a network and would like to go outside of it you must of course set the destination ethernet adress as the hardware adress of your gateway! Note also that all the TCP packet MUST have the ethernet destination set to the right hardware adress. The hardware source may be quite always 255:255:255:255, the same is for the hardware to, if you don't count TCP packets. Well, let's suppose that we created a ping packet (the ping.pkt) and we would like to change the IP from adresses in the ping without exiting Injector. What shall we do? See... setmyip 192.168.0.5 set fillipfrom 1 set infile ping.pkt do injectip The funcion "injectip" infact verifies if it have to fill the source IP (if the variable fillipfrom is set it takes the IP from the setmyip), the destination IP (if the variable fillipto is set it takes IP from the settoip), the source port (this isn't avaiable in ICMP packets, but if it can be applied (TCP or UDP packets) it put the value of portfrom in the right place) or the destination port (if portto is defined). After this it will made the right changes it will recalculate the checksums and will send the packet with new interesting data! Simple eh? Now let's see another example. We are dealing with the echo.pkt sample included in the package. The packet starts an udp echo war between the port 7 of the 192.168.0.1 and the 192.168.0.2. Let's imagine that we would like to start an udp chargen war (on port 19) between two servers on our net, respectively the 10.0.0.4 and 10.0.0.7 (of course they must have the chargen active :) ) but we don't know how to change the packet manually with an editor. Let's see how to do it: set infile echo.pkt setmyip 10.0.0.4 settoip 10.0.0.7 set fillipfrom 1 set fillipto 1 set portfrom 19 set portto 19 do injectip As you may have already understanded we have first defined the file with the packet, then defined the IPs of the two servers, defined that our function will fill the packet with them, then we have defined the source and destination port and finally sent the modified packet. Of course, depending on the packet you have built, Injector will put, if allowed (the port is only present in TCP and UDP packets. If you are sending an ICMP packet, a ping, the ports will be totally ignored), the various values in the right place, recalculate the checksums and send it. Let's imagine that the sysadm of the 10.0.0.7 have just disabled the chargen. Naaaa, what a mess! :) But hey! You can still create a good dialog between the chargen (19) of the 10.0.0.4 and the echo (7) of 10.0.0.7. So (i consider that you haven't quit or changed anything from the last example) we can just undefine the To port. It's simple unset portto do injectip this will unset the portto, so Injector will use the original port that was in the echo.pkt file, that's 7. We may also have done the same thing in a more polite way: set portto 7 do injectip but i had to demostrate to you the unset command :) There is also a flood example function that comes with injector. This will just send a determinate number (let's say 666) of packets. Let's see: set infile ping.pkt set pktnumber 666 do flood This will just send 666 packets ping.pkt. If the packet was just like a real ping it will produce the effect of a "ping -f" on a *nix. Notice that the flood function just send packets without changing them, so with this you won't be able to do SYN-Flood attacks or something like. But to do this (and here is where i was trying to come :) ) you can just add your own function in Injector. Infact Injector, that of course come with full source code, has the ability to be expanded in a very simple way by anyone! In this way you will be able to create everything (for example create a new synflood function that will send syn request packets but will also change the sequence number, the source ip and the port) using the already prepared functions. Just give a look at the main documentation if you want to know more about adding functions. Anyway don't desperate, also the SYN-Flood capability is included, but the rule is that you can enhance a function or make a new one in a very short time using the already prebuilt Injector functions. So just wake up hack the world :) And, as the last example, let's see how can we do a SYN-flood session. Come on: set arpip 192.168.0.1 do getarpto set fillethto 1 set synip 192.168.0.1 set synportfrom 5 set synportto 80 set synpkt 100 do synflood As you can see we will first set our ethernet adress to the destination one (again, TCP _must_ have a good hardware adress... the gateway adress if you want to exit from your network) and set that the program will fill it. Then we define which host to attack, from which to which port and how many packets (yay, 100 is a little to much... but the example will fill the bill). And the game is done, just execute it!