Nytro

Download: http://www.2shared.com/file/7080970/9eafe720/File_Cloner_source.html

URL Dumper is an Online scanner written by flash in VB.NET in the last year.. Used too get XSS and SQL Injections vulns.. supports multi search engine, trash system, sqlite db to organize, etc.. Features: -Get all page links by advanced technique with regular expression; -XSS Scanner (auto check all page links); -SQLInjection Scanner (auto check all page links); -Multi-Thread engine; -Get many links by search (google/Yahoo/Live Search/Altavista/Terravista) -Search in the page source by regular expression; -View Source (Code/Browser); -Trash system -Database in SQLite to organize the URL’s -Enabled Proxy server -Etc.. Screen Shot: Binary: http://rapidshare.com/files/182933272/URL_Dumper_2.0_BIN.rar Source code: http://rapidshare.com/files/182933656/URL_Dumper_2.0_SRC.rar

Imi plac intrebarile, dar nu imi place designul.

Download: http://www.2shared.com/file/7066278/67a614e/SceneCoderz_Public_Stealer.html

Cate topicuri mai ai de gand sa reinvii?

Nowadays, there are far more threats out there than plain viruses. You have probably come across the term spyware as well, however, authors of malicious codes and dangerous websites are very innovative, and new kinds of threats emerge quite often, the vast majority of which are on the Internet. Here are some of the most common: · Exploit is a malicious code that takes advantage of a flaw or vulnerability in an operating system, Internet browser, or other essential program. · Social engineering is a common term for various techniques used to trick people into giving away their personal information (passwords, bank account details, credit card numbers etc.). A typical example of social engineering is phishing – an attempt to acquire sensitive personal data by shamming a trustworthy and well-known organization. Usually, the potential victims are contacted by a bulk e-mail asking them to e.g. update their bank account details. In order to do that, they are invited to follow the link provided which then leads to a fake website of the bank. · Scam can be also considered a kind of social engineering; it includes false job offers, or ones that will abuse the workers for illegal activities, summons to withdraw a large sum of money, fraudulent lotteries and the like. · Hoax is a bulk e-mail containing dangerous, alarming or just bothering and useless information. Many of the above threats use hoax e-mail messages to spread. Finally, malicious websites are ones that deliberately install malicious software on your computer, and hacked sites do just the same, only these are legitimate websites that have been compromised into infecting visitors. AVG LinkScanner is here to protect you from all these online threats. AVG LinkScanner is up and running immediately from the moment of installation. All basic settings have been pre-set by the manufacturer, so most of the time you will not have to worry about anything – just let AVG work in the background and protect you without any effort on your part. However, there might be situations where you need to adjust the program settings, or decide what to do with a virus infected file; this help system is here to provide detailed information and assist you with any task. Get AVG LinkScanner and enhance your online protection! Here are some key features of "AVG LinkScanner": · Search-Shield scans search results and places a safety rating next to each link, so you know where it’s safe to click. · Active Surf-Shield scans the page behind any link you click on or any web address you type into your browser. If the page is poisoned, it stops you from opening it. Reasons why this program is marked as adware: · Offers to install AVG Security Toolbar that the program does not require to fully function. Download: http://rapidshare.com/files/264761321/AVG-Linkscanner-8.5_337.rar

Please note this is 32 bit only! - m00n Built on the award-winning ThreatSense® engine, ESET NOD32 Antivirus software proactively detects and eliminates more viruses, trojans, worms, adware, spyware, phishing, rootkits and other Internet threats than any program available. It's the ideal antivirus for Windows XP, and also runs smoothly on Windows legacy systems, MS-DOS, file servers, mail servers, and more. No matter what your system, there is no better antivirus protection. ESET NOD32 Antivirus was awarded the "BEST Antivirus Solution" in 2006 and 2007 by AV-Comparatives. Compare antivirus solutions here to learn more, or check out the latest virus bulletin. ESET NOD32 Antivirus provides: * Proactive Protection: The award winning ThreatSense technology combines multiple layers of detection protecting you from Internet threats before it is too late. * Precise Detection: ESET accurately identifies known and unknown threats. It consistently wins top awards from testing labs and is recognized for having zero false positives. * Lightweight Design: Requires less memory and CPU power, allowing your computer to run fast, making more room for games, web browsing, and emailing. * Fast Scanning Speeds: Highly efficient program ensuring fast file scanning and product updates. It runs quietly in the background. 18.11 MB Download: Download: http://www.mediafire.com/?vzoyyzh4wzc

HIDE YOUR IP ADDRESS V1.0 Did you know your IP address is exposed every time you visit a website? Your IP address is your online identity and could be used by hackers to break into your computer, steal personal information, or commit other crimes against you. Hide My IP allows you to surf anonymously, change your IP address, prevent identity theft, and guard against hacker intrusions, all with the click of a button. Key Benefits & Features Easily Conceal Your IP Address - Just click "Hide IP" and your IP is instantly hidden! Other people see a fake IP, which is not associated with your real IP. Click here to read how it works. Hie My IP 2009 Released January ??, 2009. Now with Secure 128-Bit Encrypted Connection, many new features, and more IPs! Anonymous Web Surfing - Protect your privacy and cover your tracks! Select from one of our many fake proxy IP addresses for totally anonymous browsing. Advanced Application Support - Hide My IP 2009 works with all major browsers and dozens of instant messengers, E-mail clients, games, and more! Protect Your Identity and Stop Hackers - Identity thieves can use your IP addresses to compromise your computer. Installing keyloggers, Trojans, and other tools to aid their crime. Stop them at the source by hiding your IP! Send Anonymous Emails - Hide your IP in E-mail headers. Supports Webmail services like Yahoo, Hotmail, and GMail. Mail clients supported with a Premium account include Outlook, Outlook Express, Eudora, and more! Un-ban Your IP From Forums, Blogs, and other Websites - By faking your IP you can often access many sites you were banned from. Use with Cookie Crumble for the most effectiveness. Instructions On How To Patch The Program: 1. Copy and paste the patch included in this download into the installation directory you installed the program in. The default location to find the directory is: C:\Program Files\Hide Your IP Address 2. Open the Patch and make sure 'Make Backup' is ticked. Click "patch" when ready. 3. Delete the patch from the directory once you have patched the program 4. Open Hide Your IP Address and a box will come up make sure you click Register. 5. Type in anything you want for Name, E-Mail and Serial Key boxes. Click register then OK 6. Restart Hide Your IP Address and you'll see its activated! What's Inside? Download: http://rapidshare.com/files/262261498/HideYourIP_v1.0_Admiral.rar

Registry RegDefense 2009 restores your computer to run like new. RegDefense prevents PC slow downs and crashes by cleaning up registry files and errors. It also repairs DLL’s and general system slowdowns that cause computer frustrations. RegDefense scans your computer and finds the problems with your computer and then fixes them so your computer runs like it did when you first took it out of the box. Features: • Registry Optimizer • Startup Manager • Backup / Restore Tools • Automatic Scheduler • 32 & 64 Bit Compatible • Tweak System Manager • In-Depth Scan • Fix Invalid File Paths • Fix Invalid Shortcuts • Fix Empty Registry Keys • Fix Invalid Class Keys • Fix Invalid Font Files • Fix User Settings • Increases Performance • Increases Computer Speed • Increases Disk Space • Increases Computer Life • Manage Shared Dll's • Customize Settings • Scan Result Manager • Automatic Updates • Automatic or Manual Fix • Visual Scan Process • Validate Startup Programs • Validate Active-X Objects • Prevent PC Freezeing • Prevent System Crashes • Registry Defrag System Requirements Minimum system requirements: 128 MB RAM 10 MB Hard drive space Supported operating system: Microsoft Windows Vista Microsoft Windows XP Microsoft Windows 2000 Download: http://rapidshare.com/files/263635390/Registry_Defense_v4.1.0.6_MUFIDIM_UPLOAD.rar

Tutorials... 1 : [+] Download 2 : [+] tar -zxvf [+]SSH Brutforcing.. by Max`s.tar 3 : [+] cd [+]SSH Brutforcing.. by Max`s 4 : [+] chmod +x * 5 : [+] ./scan ip.ip (ex ./scan 62.175) 6 : [+] Enjoy.... Programs use on Linux Download: hxxp://rapidshare.com/files/265000094/___SSH_Brutforcing.._by_Max_s.tar.html

Changes: New Design Icon Changer Anti VMWare Download: http://rapidshare.com/files/265002051/uNkCrypter_1.4.zip.html

Download: http://rapidshare.com/files/265012450/DelphBinder_Pro.rar.html

Download: http://www.2shared.com/file/7062953/20a9a2f2/StupidStealer.html

This steals pictures from your customers computer Beaver's Pic Hunter Version 1.5 Here Is What It Looks Like On The FTP Features: FTP Upload All Picture Files Containing The Selected Extensions On The Selected Drive Anti-Wireshark Anti-Anubis Anti-Zone Alarm Anti-Sandbox Copy Itself To C:\ And Add To Starup Registry Disable Task Manager Add A Custom Extension To Search For Download: http://www.2shared.com/file/7062928/f83aedbd/Beavers_Pic_Hunter_15.html

Download: http://www.2shared.com/file/7062897/8ab343d0/Redix_-_PoPCoRn.html

Changelog 1.0 Added EULA Removed Plugin Popup Added No-Ip Auto Updater Added DynDns Auto Updater Fixed RAM Display Bug Now Saves your Window State on close of Cerberus Fixed Visible Mode from not properly closing out process Removed LAN Ip from display Removed HWID from Client Name Removed Buggy SMTP Keylogger Send and MSN tab in Extra Options Now Displays if system is 32bit or 64bit Identifies system as Windows 7 Some other small server stability fix's Download: http://www.2shared.com/file/7062888/3176f00/Cerberus.html

"Your Security Get Down !! No Thing To Say , Only Be Have More Security !!" Cat urasc jegurile astea de texte. @d3v1l: De ce sa fie timpul sa se intample?

Winsock Programmer's FAQ Examples: Ping: Raw Sockets Method This pinger uses "raw sockets", so it requires Winsock 2. It's about 3 times longer (288 non-comment lines versus 98) than the ICMP method, but it will continue to work, while the ICMP method might fail to work on future versions of Windows. This program is also much more flexible than the ICMP.DLL pinger. To use this program on Windows NT derivatives, you must be logged in as an Administrator. This program is split into two major parts: a driver part and a "pinger" part. The driver mainly just declares main(), which calls the functions in the pinger part in the proper sequence. The pinger part is mostly reusable as-is, although you will probably want to do things like exchanging the output statements for encoded return values. There is also a separate module for the IP checksum calculation function because it is not specifically tied to pinging; this same algorithm is used in other parts of TCP/IP. This program allows you to change the ICMP packet's TTL (time to live) value. From this, you can do several other interesting things, like developing a traceroute utility, and finding the next hop (such as a router) on your network. Notice that we don't use the "ttl" field in struct IPHeader, because we can only receive the full IP header, not send it. Instead, we use the setsockopt() with the IP_TTL flag to set the TTL option in the IP header. You might want to add timeout functionality to this program, so that it doesn't wait forever for a ping reply. Two ways to handle this are to 1) spin the ping off into a separate thread and handle the timeout from the main thread; or 2) drop in a call to select() before the recvfrom() call, passing something reasonable for the timeout argument. This program is based on a program in the Win32 SDK, though hardly any of the original code remains. Also, this version is a bit smarter, compiles under both Microsoft and Borland C++, and should be much easier to understand and reuse. rawping_driver.cpp /*********************************************************************** rawping_driver.cpp - A driver program to test the rawping.cpp module. Building under Microsoft C++ 5.0: cl -GX rawping.cpp rawping_driver.cpp ip_checksum.cpp ws2_32.lib Building under Borland C++ 5.0: bcc32 rawping.cpp rawping_driver.cpp ip_checksum.cpp ws2_32.lib ---------------------------------------------------------------------- Change log: 9/21/1998 - Added TTL support. 2/14/1998 - Polished the program up and separated out the rawping.cpp and ip_checksum.cpp modules. Also got it to work under Borland C++. 2/12/1998 - Fixed a problem with the checksum calculation. Program works now. 2/6/1998 - Created using Microsoft's "raw ping" sample in the Win32 SDK as a model. Not much remains of the original code. ***********************************************************************/ #include <winsock2.h> #include <iostream.h> #include "rawping.h" #define DEFAULT_PACKET_SIZE 32 #define DEFAULT_TTL 30 #define MAX_PING_DATA_SIZE 1024 #define MAX_PING_PACKET_SIZE (MAX_PING_DATA_SIZE + sizeof(IPHeader)) int allocate_buffers(ICMPHeader*& send_buf, IPHeader*& recv_buf, int packet_size); /////////////////////////////////////////////////////////////////////// // Program entry point int main(int argc, char* argv[]) { // Init some variables at top, so they aren't skipped by the // cleanup routines. int seq_no = 0; ICMPHeader* send_buf = 0; IPHeader* recv_buf = 0; // Did user pass enough parameters? if (argc < 2) { cerr << "usage: " << argv[0] << " <host> [data_size] [ttl]" << endl; cerr << "\tdata_size can be up to " << MAX_PING_DATA_SIZE << " bytes. Default is " << DEFAULT_PACKET_SIZE << "." << endl; cerr << "\tttl should be 255 or lower. Default is " << DEFAULT_TTL << "." << endl; return 1; } // Figure out how big to make the ping packet int packet_size = DEFAULT_PACKET_SIZE; int ttl = DEFAULT_TTL; if (argc > 2) { int temp = atoi(argv[2]); if (temp != 0) { packet_size = temp; } if (argc > 3) { temp = atoi(argv[3]); if ((temp >= 0) && (temp <= 255)) { ttl = temp; } } } packet_size = max(sizeof(ICMPHeader), min(MAX_PING_DATA_SIZE, (unsigned int)packet_size)); // Start Winsock up WSAData wsaData; if (WSAStartup(MAKEWORD(2, 1), &wsaData) != 0) { cerr << "Failed to find Winsock 2.1 or better." << endl; return 1; } // Set up for pinging SOCKET sd; sockaddr_in dest, source; if (setup_for_ping(argv[1], ttl, sd, dest) < 0) { goto cleanup; } if (allocate_buffers(send_buf, recv_buf, packet_size) < 0) { goto cleanup; } init_ping_packet(send_buf, packet_size, seq_no); // Send the ping and receive the reply if (send_ping(sd, dest, send_buf, packet_size) >= 0) { while (1) { // Receive replies until we either get a successful read, // or a fatal error occurs. if (recv_ping(sd, source, recv_buf, MAX_PING_PACKET_SIZE) < 0) { // Pull the sequence number out of the ICMP header. If // it's bad, we just complain, but otherwise we take // off, because the read failed for some reason. unsigned short header_len = recv_buf->h_len * 4; ICMPHeader* icmphdr = (ICMPHeader*) ((char*)recv_buf + header_len); if (icmphdr->seq != seq_no) { cerr << "bad sequence number!" << endl; continue; } else { break; } } if (decode_reply(recv_buf, packet_size, &source) != -2) { // Success or fatal error (as opposed to a minor error) // so take off. break; } } } cleanup: delete[]send_buf; delete[]recv_buf; WSACleanup(); return 0; } /////////////////////////// allocate_buffers /////////////////////////// // Allocates send and receive buffers. Returns < 0 for failure. int allocate_buffers(ICMPHeader*& send_buf, IPHeader*& recv_buf, int packet_size) { // First the send buffer send_buf = (ICMPHeader*)new char[packet_size]; if (send_buf == 0) { cerr << "Failed to allocate output buffer." << endl; return -1; } // And then the receive buffer recv_buf = (IPHeader*)new char[MAX_PING_PACKET_SIZE]; if (recv_buf == 0) { cerr << "Failed to allocate output buffer." << endl; return -1; } return 0; } rawping.cpp /*********************************************************************** rawping.cpp - Contains all of the functions essential to sending "ping" packets using Winsock 2 raw sockets. Depends on ip_checksum.cpp for calculating IP-style checksums on blocks of data, however. ***********************************************************************/ #include <winsock2.h> #include <ws2tcpip.h> #include <iostream.h> #include "rawping.h" #include "ip_checksum.h" //////////////////////////// setup_for_ping //////////////////////////// // Creates the Winsock structures necessary for sending and recieving // ping packets. host can be either a dotted-quad IP address, or a // host name. ttl is the time to live (a.k.a. number of hops) for the // packet. The other two parameters are outputs from the function. // Returns < 0 for failure. int setup_for_ping(char* host, int ttl, SOCKET& sd, sockaddr_in& dest) { // Create the socket sd = WSASocket(AF_INET, SOCK_RAW, IPPROTO_ICMP, 0, 0, 0); if (sd == INVALID_SOCKET) { cerr << "Failed to create raw socket: " << WSAGetLastError() << endl; return -1; } if (setsockopt(sd, IPPROTO_IP, IP_TTL, (const char*)&ttl, sizeof(ttl)) == SOCKET_ERROR) { cerr << "TTL setsockopt failed: " << WSAGetLastError() << endl; return -1; } // Initialize the destination host info block memset(&dest, 0, sizeof(dest)); // Turn first passed parameter into an IP address to ping unsigned int addr = inet_addr(host); if (addr != INADDR_NONE) { // It was a dotted quad number, so save result dest.sin_addr.s_addr = addr; dest.sin_family = AF_INET; } else { // Not in dotted quad form, so try and look it up hostent* hp = gethostbyname(host); if (hp != 0) { // Found an address for that host, so save it memcpy(&(dest.sin_addr), hp->h_addr, hp->h_length); dest.sin_family = hp->h_addrtype; } else { // Not a recognized hostname either! cerr << "Failed to resolve " << host << endl; return -1; } } return 0; } /////////////////////////// init_ping_packet /////////////////////////// // Fill in the fields and data area of an ICMP packet, making it // packet_size bytes by padding it with a byte pattern, and giving it // the given sequence number. That completes the packet, so we also // calculate the checksum for the packet and place it in the appropriate // field. void init_ping_packet(ICMPHeader* icmp_hdr, int packet_size, int seq_no) { // Set up the packet's fields icmp_hdr->type = ICMP_ECHO_REQUEST; icmp_hdr->code = 0; icmp_hdr->checksum = 0; icmp_hdr->id = (USHORT)GetCurrentProcessId(); icmp_hdr->seq = seq_no; icmp_hdr->timestamp = GetTickCount(); // "You're dead meat now, packet!" const unsigned long int deadmeat = 0xDEADBEEF; char* datapart = (char*)icmp_hdr + sizeof(ICMPHeader); int bytes_left = packet_size - sizeof(ICMPHeader); while (bytes_left > 0) { memcpy(datapart, &deadmeat, min(int(sizeof(deadmeat)), bytes_left)); bytes_left -= sizeof(deadmeat); datapart += sizeof(deadmeat); } // Calculate a checksum on the result icmp_hdr->checksum = ip_checksum((USHORT*)icmp_hdr, packet_size); } /////////////////////////////// send_ping ////////////////////////////// // Send an ICMP echo ("ping") packet to host dest by way of sd with // packet_size bytes. packet_size is the total size of the ping packet // to send, including the ICMP header and the payload area; it is not // checked for sanity, so make sure that it's at least // sizeof(ICMPHeader) bytes, and that send_buf points to at least // packet_size bytes. Returns < 0 for failure. int send_ping(SOCKET sd, const sockaddr_in& dest, ICMPHeader* send_buf, int packet_size) { // Send the ping packet in send_buf as-is cout << "Sending " << packet_size << " bytes to " << inet_ntoa(dest.sin_addr) << "..." << flush; int bwrote = sendto(sd, (char*)send_buf, packet_size, 0, (sockaddr*)&dest, sizeof(dest)); if (bwrote == SOCKET_ERROR) { cerr << "send failed: " << WSAGetLastError() << endl; return -1; } else if (bwrote < packet_size) { cout << "sent " << bwrote << " bytes..." << flush; } return 0; } /////////////////////////////// recv_ping ////////////////////////////// // Receive a ping reply on sd into recv_buf, and stores address info // for sender in source. On failure, returns < 0, 0 otherwise. // // Note that recv_buf must be larger than send_buf (passed to send_ping) // because the incoming packet has the IP header attached. It can also // have IP options set, so it is not sufficient to make it // sizeof(send_buf) + sizeof(IPHeader). We suggest just making it // fairly large and not worrying about wasting space. int recv_ping(SOCKET sd, sockaddr_in& source, IPHeader* recv_buf, int packet_size) { // Wait for the ping reply int fromlen = sizeof(source); int bread = recvfrom(sd, (char*)recv_buf, packet_size + sizeof(IPHeader), 0, (sockaddr*)&source, &fromlen); if (bread == SOCKET_ERROR) { cerr << "read failed: "; if (WSAGetLastError() == WSAEMSGSIZE) { cerr << "buffer too small" << endl; } else { cerr << "error #" << WSAGetLastError() << endl; } return -1; } return 0; } ///////////////////////////// decode_reply ///////////////////////////// // Decode and output details about an ICMP reply packet. Returns -1 // on failure, -2 on "try again" and 0 on success. int decode_reply(IPHeader* reply, int bytes, sockaddr_in* from) { // Skip ahead to the ICMP header within the IP packet unsigned short header_len = reply->h_len * 4; ICMPHeader* icmphdr = (ICMPHeader*)((char*)reply + header_len); // Make sure the reply is sane if (bytes < header_len + ICMP_MIN) { cerr << "too few bytes from " << inet_ntoa(from->sin_addr) << endl; return -1; } else if (icmphdr->type != ICMP_ECHO_REPLY) { if (icmphdr->type != ICMP_TTL_EXPIRE) { if (icmphdr->type == ICMP_DEST_UNREACH) { cerr << "Destination unreachable" << endl; } else { cerr << "Unknown ICMP packet type " << int(icmphdr->type) << " received" << endl; } return -1; } // If "TTL expired", fall through. Next test will fail if we // try it, so we need a way past it. } else if (icmphdr->id != (USHORT)GetCurrentProcessId()) { // Must be a reply for another pinger running locally, so just // ignore it. return -2; } // Figure out how far the packet travelled int nHops = int(256 - reply->ttl); if (nHops == 192) { // TTL came back 64, so ping was probably to a host on the // LAN -- call it a single hop. nHops = 1; } else if (nHops == 128) { // Probably localhost nHops = 0; } // Okay, we ran the gamut, so the packet must be legal -- dump it cout << endl << bytes << " bytes from " << inet_ntoa(from->sin_addr) << ", icmp_seq " << icmphdr->seq << ", "; if (icmphdr->type == ICMP_TTL_EXPIRE) { cout << "TTL expired." << endl; } else { cout << nHops << " hop" << (nHops == 1 ? "" : "s"); cout << ", time: " << (GetTickCount() - icmphdr->timestamp) << " ms." << endl; } return 0; } rawping.h /*********************************************************************** rawping.h - Declares the types, constants and prototypes required to use the rawping.cpp module. ***********************************************************************/ #define WIN32_LEAN_AND_MEAN #include <winsock2.h> // ICMP packet types #define ICMP_ECHO_REPLY 0 #define ICMP_DEST_UNREACH 3 #define ICMP_TTL_EXPIRE 11 #define ICMP_ECHO_REQUEST 8 // Minimum ICMP packet size, in bytes #define ICMP_MIN 8 #ifdef _MSC_VER // The following two structures need to be packed tightly, but unlike // Borland C++, Microsoft C++ does not do this by default. #pragma pack(1) #endif // The IP header struct IPHeader { BYTE h_len:4; // Length of the header in dwords BYTE version:4; // Version of IP BYTE tos; // Type of service USHORT total_len; // Length of the packet in dwords USHORT ident; // unique identifier USHORT flags; // Flags BYTE ttl; // Time to live BYTE proto; // Protocol number (TCP, UDP etc) USHORT checksum; // IP checksum ULONG source_ip; ULONG dest_ip; }; // ICMP header struct ICMPHeader { BYTE type; // ICMP packet type BYTE code; // Type sub code USHORT checksum; USHORT id; USHORT seq; ULONG timestamp; // not part of ICMP, but we need it }; #ifdef _MSC_VER #pragma pack() #endif extern int setup_for_ping(char* host, int ttl, SOCKET& sd, sockaddr_in& dest); extern int send_ping(SOCKET sd, const sockaddr_in& dest, ICMPHeader* send_buf, int packet_size); extern int recv_ping(SOCKET sd, sockaddr_in& source, IPHeader* recv_buf, int packet_size); extern int decode_reply(IPHeader* reply, int bytes, sockaddr_in* from); extern void init_ping_packet(ICMPHeader* icmp_hdr, int packet_size, int seq_no); ip_checksum.cpp /*********************************************************************** ip_checksum.cpp - Calculates IP-style checksums on a block of data. ***********************************************************************/ #define WIN32_LEAN_AND_MEAN #include <windows.h> USHORT ip_checksum(USHORT* buffer, int size) { unsigned long cksum = 0; // Sum all the words together, adding the final byte if size is odd while (size > 1) { cksum += *buffer++; size -= sizeof(USHORT); } if (size) { cksum += *(UCHAR*)buffer; } // Do a little shuffling cksum = (cksum >> 16) + (cksum & 0xffff); cksum += (cksum >> 16); // Return the bitwise complement of the resulting mishmash return (USHORT)(~cksum); } ip_checksum.h extern USHORT ip_checksum(USHORT* buffer, int size); Footnotes 1. The traceroute utility ("tracert.exe") works by setting the TTL field to 1, sending a ping, waiting for the reply, setting TTL to 2...and so on. By looking at the addresses returned in the ICMP_TTL_EXPIRE replies, you can "trace" a route through the Internet. Eventually, you'll get an ICMP_ECHO reply, which lets you know when you've completed the route to the host. (Incidentally, many Unix traceroute utilities use UDP instead of ICMP, which if nothing else doesn't require that you use raw sockets.) 2. Finding the next hop on the network can be useful, because it allows you to discover a gateway to another network, such as the Internet. To do this, set the TTL field to 1, send the ping and see who responds with ICMP_TTL_EXPIRE. This isn't reliable, but it can be useful in some situations.

[==============================================================================] [------------------------[Locating Stateless Firewalls]------------------------] [==============================================================================] By: ithilgore - ithilgore.ryu.L@gmail.com sock-raw.org / sock-raw.homeunix.org October 2008 -------------[ Table of Contents ]------------- i. Preface ii. Stateless vs Stateful iii. Corner cases iv. Conclusion v. References [ i. Preface ] ============== Firewalls. One of the main defense-mechanisms of every enterprise. The main network nodes from which nearly all traffic passes through. But these are well-worn facts and there is no point in delving into more details about how important firewalls are. This article instead, focuses on how to remotely discover characteristics which betray the actual nature of the firewall - stateless or stateful. The techniques shown use two main methods of port scanning (SYN & ACK), and unfold the thought process involved in interpreting the results. The other section demonstrates the natural weakness that defines stateless firewalls and how ambiguous configurations can lead to security holes in one's network. [ ii. Stateless vs Stateful ] ============================= Nowadays, nearly everyone is moving to stateful firewalls, both for their completeness and their flexibility in implementing all sorts of arcane, but often needed, configurations. Nevertheless, there are are still cases where a stateless firewall might be in place - the most usual one is for host defense, where more lightweight and perhaps less "restrictive" solutions are preferred. Take for example, ipchains from Linux kernel 2.2, Windows XP SP2 and Windows 2003 Server built-in firewall or simple firewalls in home networking devices using embedded technology. What makes a stateless firewall different from a stateful? It is its inability to make decisions about whether to allow a packet or not based on the packets it has previously received and their relation to the one at hand. It does not keep any state of the connections already taking place, and thus cannot discern if the packet which just arrived, actually belongs to one of these sessions. Every packet is examined independently of any other. The only thing that a stateless firewall does, is to look up at its rule table, see if the nature of the packet falls into any of the categories described there and act accordingly - either blocking or allowing it to pass. As simple as that. The simplicity of its nature is what makes a stateless firewall vulnerable to the ACK scanning reconnaissance attack (and more). The KISS principle unfortunately doesn't always induce good results. Let us examine what the actual "reactions" of both a stateful and a stateless firewall in some usual (SYN) and unusual (ACK) cases are. It is implied here, that the ACK packet is not part of a three-way handshake or any other existing connection, but an isolated hand-crafted one. Both diagrams and tables for each kind are shown below: ************ stateless firewall ************ unblocked / \ (blocked) (closed) (open) || | | |---------------->|| DROP | | | || | | | || | | | || | | | || | | SYN -|--------------------------------->| | | <======================== RST ===| | | || | | | || | | | || | | |------------------------------------------------->| <======================================== ACK ===| || | | || | | || | | unblocked / \ (blocked) (closed) (open) || | | |---------------->|| DROP | | | || | | | || | | | || | | | || | | ACK -|--------------------------------->| | | <======================== RST ===| | | || | | | || | | | || | | |------------------------------------------------->| <======================================== RST ===| || | | || | | || | | Table1:|| blocked | closed | open ======================================= SYN || DROP | RST | ACK ACK || DROP | RST | RST ************ stateful firewall ************ unblocked / \ (blocked) (closed) (open) || | | |---------------->|| DROP | | | || | | | || | | | || | | | || | | SYN -|--------------------------------->| | | <======================== RST ===| | | || | | | || | | | || | | |------------------------------------------------->| <======================================== ACK ===| || | | || | | || | | unblocked / \ (blocked) (closed) (open) || | | |---------------->|| DROP | | | || | | | || | | | || | | | || | | ACK -|--------------------------------->| DROP | | || | | | || | | | || | | |------------------------------------------------->| DROP || | | || | | || | | Table2:|| blocked | closed | open ======================================== SYN || DROP | RST | ACK ACK || DROP | DROP | DROP The only way that actually lets you differentiate between a stateful and a stateless firewall is by sending an ACK packet to an *unblocked* port - either closed or open. A stateless firewall can't know if the packet is part of an already established connection on that particular port or if it is a malicious packet coming from an attacker wanting to map the network . Consequently, it will allow it to pass. On the other hand, a stateful firewall is going to look up at its state table, and if the ACK packet doesn't contain valid field values in the IP/TCP headers that indicate it is a legitimate and expected packet, it will just drop it. [1] As far as blocked ports are concerned, it goes without saying that both kinds of firewalls will drop everything directed to them, be it a SYN, ACK or whatever magical hand-crafted packet you can imagine. It is crucial in order to avoid confusion, to note down that when we write that a port is "unblocked", we mean, that according to the firewall rules, it is not blocked explicitly. Why did we choose this notation instead of saying it is filtered? The following definitions will help in comprehension: 1) blocked port: is the one that is disallowed ANY traffic to reach it - the firewall will DROP everything 2) filtered port: is the one that is protected by a firewall - this can expand into two things: a) blocked - the firewall will drop anything that is dictated by the filtering rule e.g drop everything that comes from host 1.2.3.4 unblocked - the firewall will let through traffic that is allowed by the filtering rule e.g allow everything that has src port 53 As a result, a filtered port can appear as both "open" and "filtered" according to the nature of the packets that hit it. It is imperative that the above sentence is understood, since it sums up the gist of port filtering. The two following examples will try to clear things out. Example1: --------- A port being queried by an address that is permitted according to the firewall ruleset, will appear as unblocked. The same port being queried by an address that is not explicitly allowed will appear as blocked. The firewall "filters" the port by inspecting the source IP address. Example2: --------- Suppose you have a port that is behind no firewall, and a port which is behind PF/ipfilter but its ruleset explicitly says to allow passing traffic to it and also keeps a state entry. It is obvious that the responses you will get in each case will vary. The port is unblocked in both cases, but in the second case there is the additional protection of keeping state. Hence, it is possible to have an open port that is driven through a "filter" - a filter which doesn't DROP all packets, but will reject any non SYN-initiating packets which don't already belong to an existing connection (like isolated ACK packets). The nature of "filtered = blocked" will reveal itself when you hit the above port with ACK packets, while the nature of "filtered -> unblocked" will reveal itself when you hit it with SYN packets. Of course, if you only hit the port with a SYN, you will never know (except if you use other techniques such as timing the rtts) that the port was behind a firewall. Keep in mind, that when performing a test scanning, a "filtered" port implies that our probes weren't replied, thus the port revealed its "filtered -> blocked" nature. If, for another kind of probe, the port replies indicating that it is open, the port will appear as just "open", ignoring the fact that it is actually protected by a firewall filter, and meaning we were lucky enough to get through the firewall. This is the notation that Nmap and nearly all network-security tools use. [2] Time to (partially) leave theory behind and witness an actual example. We are going to scan a Windows 2003 Server host which has the following characteristics: 1) IP address: 10.0.0.45 2) Built-in firewall is enabled and blocks everything apart from ports: 21, 80, 139, 445, 3389 3) Ports 21 and 80 have no listening daemon behind them, while the rest of the unfiltered ports do. We begin with a simple SYN scan - the default scanning method for Nmap: # nmap 10.0.0.45 -F -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 21:03 EEST Interesting ports on 10.0.0.45: Not shown: 95 filtered ports Reason: 95 no-responses PORT STATE SERVICE REASON 21/tcp closed ftp reset 80/tcp closed http reset 139/tcp open netbios-ssn syn-ack 445/tcp open microsoft-ds syn-ack 3389/tcp open ms-term-serv syn-ack Let's perform the same scan, however injecting ACK packets this time, instead of SYN ones: # nmap -sA 10.0.0.45 -F -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 21:05 EEST Interesting ports on 10.0.0.45: Not shown: 95 filtered ports Reason: 95 no-responses PORT STATE SERVICE REASON 21/tcp unfiltered ftp reset 80/tcp unfiltered http reset 139/tcp unfiltered netbios-ssn reset 445/tcp unfiltered microsoft-ds reset 3389/tcp unfiltered ms-term-serv reset Observed a pattern here? While the SYN scanning showed the expected results, we can see in the second scanning that *all* unfiltered ports replied with an RST, meaning the firewall let the ACK packets pass. See what happens when we do the same at an OpenBSD host protected by the venerable stateful firewall PF. Filtered ports: all except 14926, 61438 (both listening) root@openbsd /# cat /etc/pf.conf tcp_services = "{ 14926, 61438 }" block all pass in proto tcp from any to any port $tcp_services pass out all Note down that starting with OpenBSD 4.1, all filter rules automatically keep a state entry. Thus we omitted explicitly writing to "keep state" in the rules. On the attacker's side: # nmap 10.0.0.32 -p14926,61438 -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 22:56 EEST Interesting ports on 10.0.0.32: PORT STATE SERVICE REASON 14926/tcp open unknown syn-ack 61438/tcp open unknown syn-ack # nmap -sA 10.0.0.32 -p14926,61438 -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 22:57 EEST Interesting ports on 10.0.0.32: PORT STATE SERVICE REASON 14926/tcp filtered unknown no-response 61438/tcp filtered unknown no-response PF tosses the ACK packets into the void, since the state entries for these two ports don't mention anything about actually expecting such a packet. We didn't finish exploring here yet though. There is also a third case. Stateful firewalls can be configured to act in a stateless manner for a subset of their rules. As a result, the replies we'll then get, will vary according to which port we hit. Consider a case with PF again. PF has the ability to emulate a stateless firewall behavior by writing a "no state" at the end of the rule to which we wish to apply statelessness. root@openbsd /# cat /etc/pf.conf block all pass in proto tcp from any to any port 14926 pass in proto tcp from any to any port 61438 no state pass out all # nmap 10.0.0.32 -p14926,61438 -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 22:58 EEST Interesting ports on 10.0.0.32: PORT STATE SERVICE REASON 14926/tcp open unknown syn-ack 61438/tcp open unknown syn-ack # nmap -sA 10.0.0.32 -p14926,61438 -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 22:58 EEST Interesting ports on 10.0.0.32: PORT STATE SERVICE REASON 14926/tcp filtered unknown no-response 61438/tcp unfiltered unknown reset While the above demonstrates a fairly simplified situation, we can see that all kinds of confusing (to the one that tries to deduce it rather than to the one who actually implemented it) configurations might take place. Actually, the above results might also give a hint that there may be more than meets the eye. Since, stateful inspection is used for nearly every big network nowadays, it is fairly infrequent for a firewall to be configured like that - partially stateless and partially stateful. So what could the above results indicate? Suppose you were scanning an organization which hosts a decent number of computers. The first thing that would come to mind is NAT. It means that different ports translate to different hosts and thus different personal firewall configurations (or possibly complete lack of them). Example: suppose host 10.0.0.32 is actually a router performing NAT and has a globally routed IP (1.2.3.4) on one of its two network interfaces. The attacker performs the scan from outside the local network. The router forwards the ports according to the following rules: port 14926 --> HOST A:22 port 61438 --> HOST B:3389 HOST A runs Linux 2.6 with ipfilter statefully inspecting port 22 and having disabled access to all other ports. HOST B runs Windows Server 2003 and its firewall permits only 3389 to be accessible. In our case, what is blocked from the two firewalls concerns only the local segment of hosts. What influences the outside world is the fact that port 14926 is open statefully, while port 61438 statelessly. The results of our scanning the router from the outside will be almost like the above: # nmap 1.2.3.4 -p- -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 22:59 EEST Interesting ports on 1.2.3.4: Not shown: 65533 filtered ports Reason: 65533 no-responses PORT STATE SERVICE REASON 14926/tcp open unknown syn-ack 61438/tcp open unknown syn-ack # nmap -sA 1.2.3.4 -p- -n -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-09-21 22:59 EEST Interesting ports on 1.2.3.4: Not shown: 65534 filtered ports Reason: 65534 no-responses PORT STATE SERVICE REASON 61438/tcp unfiltered unknown reset Nmap doesn't show port 14926 in the last case, since it is included on the big list of filtered ports. However, we do know as attackers that this port is open according to the SYN scanning that took place before. Thus, we can be almost certain that port 14926 belongs to a different host than port 61438. Of course, for the above to work, it is implied that the device performing NAT uses a stateless or no firewall or else the router's firewall itself would not let the ACK packets pass through, marking both ports as filtered and thus confusing our inference. The following table summarizes the above. Table3:|| blocked | closed | open ================================================ SYN || DROP | RST | ACK ACK || DROP | RST/DROP | RST/DROP [ iii. Corner cases ] ===================== What we have seen until here assumes that the stateless firewall ruleset states one or a combination of the following: a) Filter a range of N ports thus allowing the 65535-N ports as open. Of course differentiation between destination and source ports is possible. Filter a range of source/destination IPs, effectively blocking everything related to them. c) Use a combination of the above, resulting in allowing a specific range of IPs on a specific range of unfiltered ports. However, there is another capability that firewalls can offer: d) Filtering based on the actual header values of a network packet. Taking advantage of the additional functionality that this capability provides, can quickly result in pretty dangerous situations, where a firewall is easily penetrable. Why is that? It happens mainly, because it is often difficult to know or at least predict the network stack behavior in certain corner cases. These extreme cases are the result of ambiguities in RFCs or a certain approach that a vendor decided to take in implementing the kernel's network behavior in order to support, for example, additional functionality or to solve some particular problem, always according to his own arbitrary judgment. An example is due here, since witnessing an actual real-world case will point out the graveness of the issue. [3] Consider the case where you want to block everyone from accessing your services. However, you still want to be able to connect to anyone, thus you have to allow all egress traffic. It is fairly obvious that blocking ALL incoming traffic is not a solution, since that would also block the packets that came as an answer to your own initiated connections to the outer world. What is left, is to perform some packet header filtering magic: - Allow everything that is NOT a SYN packet. This will allow you to receive replies to your own outbound connections. - Block everything else. In ipchains the above would be written like this: ipchains -A input -p TCP ! -y -j ACCEPT ipchains -P input DENY How does the above sound? It may sound great, but it isn't. The problem stems from the fact that there is an ambiguity on the part of "NOT a SYN packet". Actually, this might be interpreted a bit differently than you might expect. [4] Let's take a brief look into the function responsible for handling initiating packets. The snippet comes from /usr/src/linux-2.6.26.2/net/ipv4/tcp_input.c: static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb, struct tcphdr *th, unsigned len) { struct tcp_sock *tp = tcp_sk(sk); struct inet_connection_sock *icsk = inet_csk(sk); int saved_clamp = tp->rx_opt.mss_clamp; tcp_parse_options(skb, &tp->rx_opt, 0); if (th->ack) { /* ... */ } /* No ACK in the segment */ if (th->rst) { /* rfc793: * "If the RST bit is set * * Otherwise (no ACK) drop the segment and return." */ goto discard_and_undo; } /* ... */ if (th->syn) { /* ... */ } /* ... */ } What does the above tell us? Say a packet doesn't have the ACK or RST flag in the tcp flags. In addition, suppose you hand-craft the packet so that it has both the SYN *and* the PSH flag on for example. According to the above, the packet will be considered a legitimate SYN packet, since the only thing that the kernel checks is if the SYN flag bit is on. It doesn't concern itself with the existence of any additional set flags. Packets containing any of the following combination of tcp flags will be seen as SYN initiating packets: Table4 -------------------- SYN, PSH SYN, URG SYN, FIN SYN, PSH, URG SYN, PSH, FIN SYN, URG, FIN SYN, URG, PSH, FIN -------------------- Try checking some of the above combinations of tcp-flags as scanflags against any Linux host: #nmap -F 10.0.0.100 -n --scanflags SYNFIN -PN --reason Starting Nmap 4.76 ( Nmap - Free Security Scanner For Network Exploration & Security Audits. ) at 2008-10-05 21:30 EEST Interesting ports on 10.0.0.100: Not shown: 98 closed ports Reason: 98 resets PORT STATE SERVICE REASON 111/tcp open rpcbind syn-ack 113/tcp open auth syn-ack Note that we stated that our probes will have both SYN and FIN flags on. tcpdump output on Linux host: IP 10.0.0.12.41448 > 10.0.0.100.auth: SF 3334668331:3334668331(0) IP 10.0.0.100.auth > 10.0.0.12.41448: S 975129621:975129621(0) ack 3334668332 IP 10.0.0.12.41448 > 10.0.0.100.auth: R 3334668332:3334668332(0) IP 10.0.0.12.41448 > 10.0.0.100.sunrpc: SF 3334668331:3334668331(0) IP 10.0.0.100.sunrpc > 10.0.0.12.41448: S 975740821:975740821(0) ack 3334668332 IP 10.0.0.12.41448 > 10.0.0.100.sunrpc: R 3334668332:3334668332(0) It is more clear now that a vague rule like "block all SYN packets" might give trouble, since it might block packets that *only* have the SYN flag on, thus allowing any of Table4 flag-combination packets to pass unhindered. Note that the above attack works against BSD and Windows hosts as well. RFC 793 is ambiguous on the matter, and most implementations, as we can see, choose to ignore any additional flags combined with SYN and thus treat the corresponding packet as a legitimate one. This ambiguity along with the nature of the stateless firewall and a possible misconfiguration could result in big security holes. [ iv. Conclusion ] ================== Summing up, using a combination of SYN and ACK scanning methods can help us determine if a firewall is stateless or not, thus providing the first step in mapping our network. The fact that a firewall may exhibit a "double" nature - partially stateless and partially stateful - is a possible indication that a NAT or other IP translation mechanism might be in place. Knowing that we have to deal with a weak natured firewall such as a stateless one, we can try the SYN-<tcp-flag> combination technique to possibly bypass the restrictions imposed by the filtering ruleset. [ v. References ] ================= [1]. Port Scanning Techniques [2]. Port Scanning Basics [3]. The Art of Software Security Assessment (Mark Dowd, John McDonald, Justin Schuh): Chapter 15 - Firewalls [4]. Ambiguities in TCP/IP - firewall bypassing: Bugtraq: Ambiguities in TCP/IP - firewall bypassing [5]. TCP/IP Illustrated Volumes 1,2 [6]. Linux/BSD kernel sources + relevant man pages

***************************************** * Coding a Syn Scanner * * by ithilgore * * ithilgore.ryu.L@gmail.com * * version 1.2 - March 2007 * ***************************************** 0x0. Index 0x1. Prologue 0x2. Syn Scanning 0x3. Tcp/ip header analysis 0x4. Raw Sockets 0x5. Libpcap/Sniffing Session 0x6. The SYN port scanner(source) 0x7. Epilogue 0x8. References -------------- 0x1. Prologue -------------- In the current article we are going to analyse the process of programming a Port Scanner which uses stealthier methods to scan its victim. In fact we shall see how a SYN scanner is made. It is not the result that counts so much, since there are already some high-quality tools in the open source community that support such a function ( see Nmap ). However, we are more interested in the process of making such a tool, a process which includes many different interesting matters of the security sector. What are these things in a few words? --Raw Sockets --Libpcap/Sniffing --Tcp/ip header analysis --The Syn Scanning itself This guide's purpose, as you will realize, is not to just plainly give the source code of the SYN Scanner ( this in fact by itself doesn't have any actual meaning since, as we have already mentioned there are such tools with an open source in public ) but to give some guidelines for someone who wants to go deeper into the Network Programming (in Unix) through the programming and analysis of the creation of this particular tool.This means that with this guide, you will constantly have to refer to man pages,RFCs etc as well as to execute other tools such as tcpdump. For someone to be able to understand the flow of this guide he will have to: a) have a good understanding of the C language have already delved into the basics of network programming ( see Beej's Guide to Network Programming ) c) know some basic things about networks d) have a box installed with a unix-flavored OS ( root priviledges required ) so as to be able to experiment with the code. e) have a second box ( either as a virtual machine or real ) available (this is not required though) f) have enough free time as some concepts are quite difficult to understand in the first place Note down that the code has been successfully tested on a Slackware 11 box with kernel 2.4.33.3 ------------------ 0x2. SYN Scanning ------------------ The SYN scanning is based on a simple method called half-open connection. As we already know, when two computers communicate with each other through the TCP, the below procedure is followed: a) client ----------SYN J--------------> server client <--------SYN K / ACK J+1------ server c) client --------ACK K+1 -------------> server The above is called 3-way handshake as it goes through 3 stages of handshake: a) In the beginning, the client sends a TCP packet to the servers's port with an initial sequence (usually random). During the second stage, if the server accepts connections on this particular port, he will send as an answer a TCP packet with a sequence ACK equal to SYN+1 (we suppose the client's sequence is SYN) as well as a new SYN sequence of his own. c) In the end, the client will answer with an ACK incremented by 1 in relation to the SYN the server sent during the b part. -->In case the server's port is closed, the server sends a RST packet in the b stage and terminates the handshake. The above way is the classical way of a common port scanner, that scans through the ports that interest the attacker trying to open to each of them a full connection through the simple 3-way handshake. What a nice way for the victim's firewall or IDS to log the attack... A better solution is given by the half-open connection: a) client ----------SYN J--------------> server client <--------SYN K / ACK J+1------ server c) client ----------RST ---------------> server Which is the only difference? As you have already observed the last step during which the client who already knows that the server has sent a positive answer, instead of opening the connection fully ( the usual state: Connection Established ), sends a RST packet terminating the connection prematurely. What is the benefit? A smaller chance to alarm any security mechanism of the victim as the connection is never opened fully. This is in fact the stealth capability that the SYN scanner comes to use. Details for how it is done, below. ---------------------------- 0x3. TCP/IP header analysis ---------------------------- It is time to see more closely what exactly takes place behind the curtains. At this stage it would be a good chance to scan through the RFCs 791 ( Internet Protocol ) and 793 ( Transmission Protocol ) as their knowledge will come in handy later. The TCP header's format is shown below. In fact, the important information that every TCP packet must have is untill the Urgent Pointer, which means 20 bytes in size. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Let's see more analytically each field of the header: ------ ----- ------------ FIELD SIZE DESCRIPTION ------ ----- ------------ Source Port: (16bits) The client's Port number Destination Port: (16bits) The server's (destination) Port number Sequence Number: (32bits) The sequence number that is used for enumerating TCP packets (see 3-way handshake) Acknowledgment Number: (32bits) The answer number to the previous SYN. It stands that ACK = previous_SYN + 1 Data Offset: (4 bits) The number that defines the header's size.WARNING!-> it is counted by multiples of 32bits/4bytes. This means that when the TCP packet has nï options data_offset = 5 Reserved: (6 bits) Just reserved, these bits are all 0 Flags: (6 bits) Each flag defines a special state.(1 bit each -on/off) URG: Urgent: for fast routing ACK: Ácknowledgment: for the 2nd and 3rd stage of the 3way TCP handshake PSH: Push: the system doesn't buffer the segment into the ÉP stack RST: Reset: for immediate termination of a connection SYN: Synchronization: for a new connection and TCP handshake FIN: Final: for the normal termination of a connection ( see TCP termination) Window: (16bits) The maximum quantity of data that the client will receive Checksum: (16bits) The packet's checksum, which we shall analyze later Urgent Pointer: (16bits) It is used in combination with the urgent flag These are in a few words the TCP header's fields with which we shall be occupied below when we create our own datagram. We do not analyse each of them in depth since this is not our purpose.Instead of that we shall point out some of them later as they will be of vital importance to our SYN scanner.For more information you are encouraged to see the corresponding RFCs. But now let's see in a code level how such a TCP header would be like. /* TCP header */ typedef u_int tcp_seq; struct sniff_tcp { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ u_char th_offx2; /* data offset, rsvd */ #define TH_OFF(th) (((th)->th_offx2 & 0xf0) >> 4) u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 #define TH_ECE 0x40 #define TH_CWR 0x80 #define TH_FLAGS (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR) u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ }; As we see there is a 1 to 1 correlation between the struct's fields and the TCP header's fields. We should point out that the above struct is not the classic BSD-flavored but a style proposed by Tim Carstens -> Programming with pcap ( we shall refer to pcap later if this link moved your curiosity ) A little more patience to see the IP header and then we shall look into a live example with tcpdump! The IP header then: 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ ----- ------------ FIELD SIZE DESCRIPTION ------ ----- ------------ Version: (4 bits) The header's version.We are discussing IPv4 so it is 4. IHL: (4 bits) Header length: in 32bit words!! Thus the min_value = 5 (just before Options) Type of Service: (8 bits) It is used for priorities in certain services of some networks Total Length: (8 bits) Total datagram length (in bytes), that includes the ÔCP header. It shows us where the payload begins. Identification: (8 bits) A unique value of the sender in case there is need to reassembly a fragmented packet. Flags: (3 bits) bit 0: reserved 0 , bit 1:DF (don't fragment) , bit 2:MF(more fragments) sequence: b0,b1,b2 Fragment Offset: (13bits) It is used to reassembly fragmented packets. Time to Live: (8 bits) How many hops(routers) the packet can pass before it is discarded. max_value = 255 Protocol: (8 bits) /etc/protocols for info , tcp = 6 , udp = 17, icmp = 1 Header Checksum: (16bits) The checksum of the whole datagram. Later about that Source Address: (32bits) The sender's IP Destination Address: (32bits) The receiver's IP Using the same logic as in the tpc header, we write the struct of the ip header: /* IP header */ struct sniff_ip { u_char ip_vhl; /* version << 4 | header length >> 2 */ u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src,ip_dst; /* source and dest address */ }; #define IP_HL(ip) (((ip)->ip_vhl) & 0x0f) #define IP_V(ip) (((ip)->ip_vhl) >> 4) The 2 above headers refer to the TCP/IP, however we must not forget that the on the data link layer we've got some NICs that are "in the way". NICs huh? But of course we couldn't omit to mention the ethernet and unique MAC addresses that every network interface has. For this reason, we are going to examine one more (little) header that will be enscapsulated into the packet afterwards. This specific header will not bother us later, but it is good to know about it. Thus we have: /* ethernet headers are always exactly 14 bytes */ #define SIZE_ETHERNET 14 /* Ethernet addresses are 6 bytes */ #define ETHER_ADDR_LEN 6 /* Ethernet header */ struct sniff_ethernet { u_char ether_dhost[ETHER_ADDR_LEN]; /* destination host address */ u_char ether_shost[ETHER_ADDR_LEN]; /* source host address */ u_short ether_type; /* IP? ARP? RARP? etc */ }; Things here are quite simple: ------ ----- ------------ FIELD SIZE DESCRIPTION ------ ----- ------------ ether_dhost (6bytes) Destination's MAC address ether_shost (6bytes) Sender's H ÌÁC address ether_type (2bytes) The protocol that is directly "above" ethernet (here we've got IP) The best way for someone to understand the above concepts is a real example. So we open 2 terminals and in the first we write: root@hyena:/home/# tcpdump -i eth0 -l -n -x -vv ( where eth0 is the name of your own NIC ) while in the other terminal we telnet into a host for which we know their port 80 is open ( or some other port ) Our router's web interface would be a good example. ithilgore@hyena:~$ telnet 10.0.0.2 80 Trying 10.0.0.2... Connected to 10.0.0.2. Tcpdump's output will be something like this: tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 19:46:00.774299 IP (tos 0x10, ttl 64, id 17418, offset 0, flags [DF], proto: TCP (6), length: 60) 10.0.0.4.39507 > 10.0.0.2.80: S, cksum 0x8691 (correct), 1121958480:1121958480(0) win 5840 <mss 1460, sackOK,timestamp 7536218 0,nop,wscale 0> 0x0000: 4510 003c 440a 4000 4006 e29c 0a00 0004 0x0010: 0a00 0002 9a53 0050 42df ba50 0000 0000 0x0020: a002 16d0 8691 0000 0204 05b4 0402 080a 0x0030: 0072 fe5a 0000 0000 0103 0300 19:46:00.775223 IP (tos 0x0, ttl 64, id 14712, offset 0, flags [none], proto: TCP (6), length: 60) 10.0.0.2.80 > 10.0.0.4.39507: S, cksum 0xb576 (correct), 448057277:448057277(0) ack 1121958481 win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 188518 7536218> 0x0000: 4500 003c 3978 0000 4006 2d3f 0a00 0002 0x0010: 0a00 0004 0050 9a53 1ab4 cfbd 42df ba51 0x0020: a012 2000 b576 0000 0204 05b4 0103 0300 0x0030: 0101 080a 0002 e066 0072 fe5a 19:46:00.775264 IP (tos 0x10, ttl 64, id 17419, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.4.39507 > 10.0.0.2.80: ., cksum 0xea69 (correct), 1:1(0) ack 1 win 5840 <nop,nop,timestamp 7536219 188518> 0x0000: 4510 0034 440b 4000 4006 e2a3 0a00 0004 0x0010: 0a00 0002 9a53 0050 42df ba51 1ab4 cfbe 0x0020: 8010 16d0 ea69 0000 0101 080a 0072 fe5b 0x0030: 0002 e066 3 packets ... rings a bell? As you will have already guessed this is the 3way TCP handshake. Let's take one to one the values of the packets to find a correspondence with the headers that we saw above. 1st packet: ( it begins with the IP header ) 0x0000: 4510 003c 440a 4000 4006 e29c 0a00 0004 4510: 4 = version , 5 = header length , 10 = type of service , 003c: 003c = total length ( 0x3c = 60d ) thus we know where the payload begins 440a: 440a = identification 4000: 4006 = 010 | 0 0000 0000 0110 where the 3 MSB is the flag field ( so we have DF flag which we see in tcpdump ) - the rest 13 bit are the fragment offset field 4006: 40 = time to live ( 64d ) , 06 = protocol number ( we said that TCP is 6d ) e29c: the header checksum 0a00: The first part of the Source IP address ( 10.0 ) 0004: The second and last part of the Source IP address ( 0.4 ) so 10.0.0.4 0x0010: 0a00 0002 9a53 0050 42df ba50 0000 0000 0a00: First part of the Destination IP address ( 10.0 ) 0002: Second part Destination IP address ( 0.2 ) so 10.0.0.2 -----------------end of IP header/ beginning TCP header-------------------------- 9a53: Source Port ( 0x9a53 = 39507d ) 0050: Destination Port ( 0x0050 = 80d ) 42df: First part of sequence number ( we send SYN ) ba50: Second part of seq number , so: seq = 0x42df ba50 = 1121958480d 0000: First part of ACK 0000: Second part of ACK: we don't have an ACK as in the first packet we just initiate ôï connection 0x0020: a002 16d0 8691 0000 0204 05b4 0402 080a a002: a = data offset (here because of telnet we've got some options so 0xa = 10d != 5d = min_value(no options/data)), 002 = 0000 00 | 00 0010 the 6 MSB are the reserved 0, the rest are flags where we have the 2nd LSB ON (SYN flag) 16d0: window size 8691: datagram checksum ( keep that in mind ) 0000: urgent pointer , ( it doesn't exist in our case ) ---------------from here on follow options and data that we do not interest us--- 0204: <> 05b4: <> 0402: <> 080a: <> Analysing the above we see an analogy with the headers that we studied before. Let's see some more things about the 2 next packets to verify the 3way handshake: 2nd packet: 0x0000: 4500 003c 3978 0000 4006 2d3f 0a00 0002 0x0010: 0a00 0004 0050 9a53 1ab4 cfbd 42df ba51 0x0020: a012 2000 b576 0000 0204 05b4 0103 0300 0x0030: 0101 080a 0002 e066 0072 fe5a Here the values are nearly the same. Where one should focus is on the 42df ba51 Maybe it looks like something we saw before? It is the previous Syn Sequence + 1 and resides in the field of the Acknowledgment Number of the TCP header. So we verified that ACK = previousSYN + 1. Before that let's keep in our memory ( or on the clipboard for those who can't ) the number 1ab4 cfbd which corresponds to the Sequence Number of the current packet. Now let's go and see the 3rd packet and specifically the seq and ack values 3rd packet: 0x0000: 4510 0034 440b 4000 4006 e2a3 0a00 0004 0x0010: 0a00 0002 9a53 0050 42df ba51 1ab4 cfbe 0x0020: 8010 16d0 ea69 0000 0101 080a 0072 fe5b 0x0030: 0002 e066 Here we have Sequence Number = 42df ba51 = previous_ACK (not the essence) and also ACK = 1ab4 cfbe = previoysSYN + 1 Maybe we should remind the graph? a) client ----------SYN J--------------> server client <--------SYN K / ACK J+1------ server c) client --------ACK K+1 -------------> server This about the TCP/IP packet analysis. Don't hesitate to re-read the points that you didn't understand and experiment with other examples on tcpdump. ( reading in parallel it's man pages ) ----------------- 0x4. Raw Sockets ----------------- To be able to construct a SYN scanner we will need to explicitly send our own packet with a SYN flag ON and then see if the answer we get is ACK or RST. How do we construct our own datagram? Enter Raw Sockets. Raw Sockets are nothing more than the capability of constructing our own Network Datagram ( ICMP ,TCP,IP,IGMP ) We know that TCP corresponds to the Transport Layer of the OSI model while IP belongs to the Network Layer both of which are normally managed by the kernel of the operating system. When an application needs to open a new connection with a server, then the usual way to do this is the sockets interface which allows us in a limited extent to set the conditions and parameters under which this connection will take place. In a figure: OSI TCP Layer 7: Application layer -application- | Layer 6: Presentation layer -application- <-| user process Layer 5: Session layer -application- __________________________ sockets interface / raw sockets--| Layer 4: Transport layer <---------> TCP/UDP | <-------| Layer 3: Network layer <---------> IPv4/IPv6 <-| kernel Layer 2: Data Link layer <---------> BPF/DLPI/drivers | Layer 1: Physical layer hardware Raw sockets in contrast to the plain interface give us the potential to define ourselves exactly what the datagram we shall send will be like. We define a raw socket as: int sockfd; sockfd = socket(AF_INET, SOCK_RAW, protocol); where protocol is one of the constants from the <netinet/in.h> header It is also important to set the socket option of IP_HDRINCL which allows us to define the IP header however we like. const int on; if ( setsockopt ( sockfd , IPPROTO_IP , IP_HDRINCL , &on , sizeof(on)) < 0 ) error It should be noted down that for the creation of a raw socket we need root priviledges. From the moment we know the headers' formats that we saw in section 0x3, it is relevantly easy to create the datagram we want: int sockfd,i; struct sockaddr_in sin; char datagram[4096]; // buffer for datagrams struct sniff_ip *iph = (struct sniff_ip *) datagram; struct sniff_tcp *tcph = (struct sniff_tcp *) (datagram + sizeof (struct sniff_ip)); sockfd = socket (AF_INET, SOCK_RAW, IPPROTO_TCP) ; sin.sin_family = AF_INET; sin.sin_port = htons (i); memset (datagram, 0, 4096); /* zero out the buffer */ iph->ip_vhl = 0x45; /* version=4,header_length=5 (no data) */ iph->ip_tos = 0; /* type of service not needed */ iph->ip_len = sizeof (struct sniff_ip) + sizeof (struct tcphdr); /* no payload */ iph->ip_id = htonl (54321); /*simple id*/ iph->ip_off = 0; /*no fragmentation*/ iph->ip_ttl = 255; /*Time to Live -> set maximum value*/ iph->ip_p = IPPROTO_TCP; /* 6 as a value - see "/etc/protocols" */ iph->ip_src.s_addr = ipP->sin_addr.s_addr; /*local device IP */ iph->ip_dst.s_addr = sin.sin_addr.s_addr; /*destination address*/ iph->ip_sum = 0; /*no need to fill ip checksum- kernel does that*/ tcph->th_sport = htons (1234); /* arbitrary port */ tcph->th_dport = htons (i); /* scanned destination port */ tcph->th_seq = random (); /* the random SYN sequence */ tcph->th_ack = 0; /* No ACK needed */ tcph->th_offx2 = 0x50; /* 50h (5 offset) ( 8 0s reserverd )*/ tcph->th_flags = TH_SYN; /* initial connection request FLAG*/ tcph->th_win = (65535); /* maximum allowed window size*/ tcph->th_sum = 0; /* will compute later */ tcph->th_urp = 0; /* no urgent pointer */ { int one = 1; const int *val = &one; if (setsockopt (sockfd, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0) printf ("Warning: Cannot set HDRINCL for port %d\n",i); } Now that our datagram is ready, the only thing that is left is to send it: if (sendto (sockfd ,datagram, iph->ip_len , 0, (struct sockaddr *) &sin, sizeof (sin)) < 0) { printf ("Error sending datagram for port %d\n",i); } We used here a simple i variable for the victim's port. Putting all the above inside a loop we can send SYN packets to any port we are interested in. There is still something missing though... because we left one important value undefined and without it our packet will be DROPed by an receiver!! For those who haven't understood yet, we are talking about the TCP checksum field. The algorithm is described in analysis in RFC 1071 but in a few words it goes as follows: We make 16bit words from the bytes that will be checksumed and we calculate their sum in a 1's complement form. That is what the function below implements: uint16_t checksum_comp ( uint16_t *addr , int len ) { /* compute TCP header checksum */ /* with the usual algorithm a bit changed */ /* for byte ordering problem resolving */ /* RFC 1071 for more info */ /* Compute Internet Checksum for "count" bytes * beginning at location "addr". */ register long sum = 0; int count = len; uint16_t temp; while( count > 1 ) { temp = htons(*addr++); // in this line:added -> htons sum += temp; count -= 2; } /* Add left-over byte, if any */ if( count > 0 ) sum += * (unsigned char *) addr; /* Fold 32-bit sum to 16 bits */ while (sum>>16) sum = (sum & 0xffff) + (sum >> 16); uint16_t checksum = ~sum; return checksum; } What is not so clearly documented is that the TCP checksum mustn't be calculated only on the tcp header but it MUST be calculated along with a pseudo-header that contains the following info: struct pseudo_hdr { u_int32_t src; /* 32bit source ip address*/ u_int32_t dst; /* 32bit destination ip address */ u_char mbz; /* 8 reserved bits (all 0) */ u_char proto; /* protocol field of ip header */ u_int16_t len; /* tcp length (both header and data */ }; Thus we will have to write: struct pseudo_hdr *phdr = (struct pseudo_hdr *) ( datagram + sizeof(struct sniff_ip) + sizeof(struct sniff_tcp) ) ; phdr->src = iph->ip_src.s_addr; phdr->dst = iph->ip_dst.s_addr; phdr->mbz = 0; phdr->proto = IPPROTO_TCP; phdr->len = ntohs (0x14); tcph->th_sum = htons ( checksum_comp ( (unsigned short *) tcph , sizeof(struct pseudo_hdr)+sizeof(struct sniff_tcp))); Attention is needed in fields that will need to be converted to network byte order (big endian) from host byte order (little endian or big endian depending on the box) calling the respective functions htonl or htons as well as their opposites ntohs or ntohl. Sometimes it may be necessary to experiment, like the writer when he calculated the checksum manually. Here is a good point to use the values that tcpdump had given us in the previous section for the tcp checksum field and to verify it manually by calculating the 1's sums of the bytes of the tcp + pseudo headers. --------------------------------- 0x5. libpcap /sniffing session --------------------------------- Given that we have sent the SYN packets, we will need to examine the victim's reply to record which ports it has open. The question is if we can use an equal logic like the one we use in plain sockets. The answer is no. The kernel does never pass TCP ( and UDP ) packets to a raw socket. This is not entirely true for every kernel since Linux implements raw sockets in another way and we could sniff a TCP reply without having to use something else. However a call for portability denotes that we are not going to use this unportable way. This means that we are not going to read the victim's answer with such a traditional way like the sockets API. We will need access to the datalink layer itself! The 3 most common methods to do something like this in a Unix environment are: a) BPF (berkley packet filter) DLPI (SVR4 Datalink Provider Interface) c) SOCK_PACKET interface óôï Linux The bad thing about these methods is that they are platform-dependent and thus reduce portability. Here libpcap gives the solution - the packet capture library. Now is the right time to visit the link that we have mentioned before as a credit to Tim Carstens: Programming with pcap Tcpdump itself has been written with this library, proof of the possibilities that it provides us. For someone to be able to continue smoothly here on, he will need to take a good look at the man pages of the library (online version here -> Manpage of PCAP) and especially at the functions: int pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf) char *pcap_lookupdev(char *errbuf) int pcap_lookupnet(const char *device, bpf_u_int32 *netp, bpf_u_int32 *maskp, char *errbuf) int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask) int pcap_setfilter(pcap_t *p, struct bpf_program *fp) pcap_t *pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, char *errbuf) int pcap_dispatch(pcap_t *p, int cnt, pcap_handler callback, u_char *user) int pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user) void pcap_breakloop(pcap_t *) The first thing we need to do is find which devices are available in our own box and use one of them for sniffing in the datalink layer. Maybe you have already realized which function is appropriate for this job: pcap_if_t *alldev; if ((pcap_findalldevs (&alldev, errbuf)) == -1) { printf ( "%s\n" , errbuf ); exit(-1); } After we find one device and an available IP that represents it ( the default case is usually one IP per device ), we can begin the sniffing session calling pcap_t *pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, char *errbuf) which returns a pointer to a pcap session id that is defined as pcap_t. The function's parameters can even be guessed from their names: char *device: the device we found with pcap_findalldevs() and we are going to use in the session int snaplen: the maximum size of bytes for every packet that we will sniff - 65535 is more than enough int promisc: 1 or 0 , promiscuous or not , hate mail from net admin or not etc int to_ms: read timeout in ms for the platforms that support it - it doesn't interest us char *errbuf: the buffer that holds all libpcap errors After we open the session, we are going to apply filtering. The biggest convenience that the library provides us with are the filters, that are described analytically by the tcpdump manpages (online version here-> http://www.tcpdump.org/tcpdump_man.html ). We filter the network traffic to the specific information that we are interested in and analyse each packet for the fields that interest us. In our case we need to see only the victim's reply. Consequently our filter will be of the form: src host ip where ip is the address of the victim. We go on with the filter's compilation: int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask) pcap_t *p: our session struct bpf_program *fp: the struct into which the compiled filter will be saved char *str: the filter expression , thus src host ip The rest 2 options, we shall not need ( int optimize , bpf_u_int32 netmask ) - 0 both The last step for our sniff engine is the application of the filter: int pcap_setfilter(pcap_t *p, struct bpf_program *fp) as for the 2 options, you can understand yourselves what they are, if you have read the above well enough. Now that our engine is ready the only thing that needs to be done is to power it on. Essentially this is done with one of these: int pcap_dispatch(pcap_t *p, int cnt, pcap_handler callback, u_char *user) Þ int pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user) You can refer to the man pages to see the subtle difference between the two but this is not so important for the scanner. The pcap_handler is the function that we have defined to process each packet that is captured by the engine. Maybe we forgot our purpose? What we need to examine is if the victim has sent a reply with the SYN and ACK flags ON: if ( ( (tcp->th_flags & 0x02) == TH_SYN) && ( tcp->th_flags & 0x10 ) == TH_ACK )) { //PORT OPEN !!! } In the opposite case the victim replies with a RST, so we can say with nearly absolute certainty that the port is closed. There is always the possibility that the packets will be DROPed for 0xE2A reasons (1002d) during the course either from the host itself or from a firewall or other gateway, so in that case we define the port's state as unknown/filtered. We have taken precautions though, with an internal timeout through a SIGALRM that is triggered by an alarm() and a signal handler to be able to escape the immobility that our central pcap_dispatch necessarily has ( it needs to work in blocking mode ) and to go on with the scanning of the rest of the ports. The 3rd step of the SYN scanning is needed though, isn't it? Shouldn't we also send a RST to the receiver if he replies us positively? It seems that the kernel itself (not so oddly) helps us in this situation by automatically sending a RST packet to the victim in that case. Attention though, since this might be different from operating system to operating system and it might be needed to send our own explicitly. In that case, what you need only do is to complete with your own code the explicit sending of the TCP datagram with RST on. If you have understood and studied all the above, it may not seem so difficult now. Another piece of our scanner has just been finished. It is time to put it all together. Combining then all the above we make our SYN scanner. ---------------------------------- 0x6. The SYN port scanner (source) ---------------------------------- /****************************************************************************/ /* Creeper - a simple Syn Scanner */ /* minimalistic port scanner for educational purposes */ /* Copyright © 2007 ithilgore - ithilgore.ryu.L@gmail.com */ /* */ /* This program is free software: you can redistribute it and/or modify */ /* it under the terms of the GNU General Public License as published by */ /* the Free Software Foundation, either version 3 of the License, or */ /* (at your option) any later version. */ /* */ /* This program is distributed in the hope that it will be useful, */ /* but WITHOUT ANY WARRANTY; without even the implied warranty of */ /* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the */ /* GNU General Public License for more details. */ /* */ /* You should have received a copy of the GNU General Public License */ /* along with this program. If not, see <http://www.gnu.org/licenses/>. */ /* */ /****************************************************************************/ /****************************************************************************/ /* Creeper */ /* version 1.2 */ /* by ithilgore */ /* ithilgore.ryu.L@gmail.com */ /* */ /* compile with: gcc creeper.c -lpcap -o creeper */ /* some compilers may also need -fpack-struct */ /* */ /* Use of this code is for educational purposes only. I am not responsible */ /* for any illegal or criminal activities performed with this tool or */ /* any modifications of it. */ /* This tool is free and open software. This means you can do anything you */ /* like with it with your own responsibility and with no warranty from me. */ /* to the source. */ /* */ /* This tool has been tested so far and works sucessfully in: */ /* ----Slackware 11 with kernel 2.2.4.33 */ /* ----Arch Linux (Core Dump) kernel 2.6.23 */ /****************************************************************************/ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <netdb.h> #include <arpa/inet.h> #include <sys/types.h> #include <sys/socket.h> #include <unistd.h> #include <pcap.h> #include <signal.h> #define BUFSIZE 65535 //maximum size of any datagram(16 bits the size of identifier) #define TRUE 1 #define FALSE 0 #define default_low 1 #define default_high 1024 /* change the timeout at will * it defines how long the scanner will wait for * an answer from the scanned host * careful though - testing shows < 4 is bad * it is just another factor between speed and accuracy */ #define DEFAULT_S_TIMEOUT 5 /* default snap length (maximum bytes per packet to capture) */ #define SNAP_LEN 1518 /* ethernet headers are always exactly 14 bytes */ #define SIZE_ETHERNET 14 /* Ethernet addresses are 6 bytes */ #define ETHER_ADDR_LEN 6 /* USING TCPDUMP-like header structs */ /* Ethernet header */ struct sniff_ethernet { u_char ether_dhost[ETHER_ADDR_LEN]; /* destination host address */ u_char ether_shost[ETHER_ADDR_LEN]; /* source host address */ u_short ether_type; /* IP? ARP? RARP? etc */ }; /* IP header */ struct sniff_ip { u_char ip_vhl; /* version << 4 | header length >> 2 */ u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src,ip_dst; /* source and dest address */ }; #define IP_HL(ip) (((ip)->ip_vhl) & 0x0f) #define IP_V(ip) (((ip)->ip_vhl) >> 4) /* TCP header */ typedef u_int tcp_seq; struct sniff_tcp { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ u_char th_offx2; /* data offset, rsvd */ #define TH_OFF(th) (((th)->th_offx2 & 0xf0) >> 4) u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 #define TH_ECE 0x40 #define TH_CWR 0x80 #define TH_FLAGS (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR) u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ }; /* pseudo header used for tcp checksuming * a not so well documented fact ... in public */ struct pseudo_hdr { u_int32_t src; u_int32_t dst; u_char mbz; u_char proto; u_int16_t len; }; /* Global Variables */ int verbose_mode; int stealth_mode; /* Syn Scanning */ int s_timeout; /* timeout seconds for Syn Scanning */ long int low_port = default_low; long int high_port = default_high; char *ipArg = NULL; pcap_t *session; /* Function Prototypes */ void got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char *packet); void print_usage(const char *argv); int check_Port(long *lport, long *hport, char *optar); uint16_t checksum_comp(uint16_t *addr, int len); pcap_t* EnginePreparing(char *vicIP, struct sockaddr_in **ipP, pcap_t *session); struct hostent* host_resolve(void); void Syn_Scanning(void); void Connect_Scanning(void); void sigfunc(int); /* Function Prototypes end*/ /********************************MAIN PROGRAM********************************/ int main(int argc, char *argv[]) { if ( argc == 1 ) { print_usage( argv[0] ); exit(0); } int opt; while ( (opt = getopt(argc , argv , "h:vp:S") ) != -1 ) { switch (opt) { case 'h': ipArg = optarg; break; case 'v': verbose_mode = TRUE; break; case 'p': check_Port (&low_port, &high_port, optarg); break; case 'S': stealth_mode = TRUE; break; case '?': fprintf (stderr, "option inconsistency : -%c \n" "see usage(no arguments)\n", optopt); exit(EXIT_FAILURE); } } if (ipArg == NULL){ fprintf(stderr, "No host given-see usage(no arguments)\n" ); exit(EXIT_FAILURE); } if (!stealth_mode) { Connect_Scanning(); } else { if (getuid() && geteuid()) { fprintf(stderr, "Need to be root to initiate Syn Scanning\n"); exit(EXIT_FAILURE); } Syn_Scanning(); } exit(EXIT_SUCCESS); } void print_usage(const char *argv) { fprintf(stdout, "Port Scanner by ithilgore\n" "usage: %s -h Host [OPTIONS]\n" "Host -> IP or Name\n" "OPTIONS include:\n" "-v : verbose mode\n" "-p : port range (eg. -p23 , -p0-1024)\n" "-S : stealth mode on ( syn scanning )\n" "more options to be included\n\n" , argv); } int check_Port (long *lport, long *hport, char *optar) { char *s1 = optar ; //point to the char after 'p' errno = 0; *lport = strtol(s1, (char **)NULL, 10); if (errno != 0) { perror ("Port number problem \n"); exit(0); } if (!(s1 = index(s1, '-'))) { //if no port range specified (no other '-' found) *hport = *lport; return 0; } else { *hport = strtol(++s1, NULL, 10) ; if (errno != 0) { perror("Port number problem \n"); exit(0); } if (low_port > high_port) { fprintf(stdout, "low_port is higher than high_port: swapping...\n"); *lport ^= *hport; *hport ^= *lport; *lport ^= *hport; } } } struct hostent* host_resolve(void) { struct hostent *hostname; extern char * ipArg; if (!(hostname = gethostbyname(ipArg))) { fprintf (stderr, "Host name resolution failed for %s \n" "Try using the nslookup prog to find the IP address\n", ipArg); exit(EXIT_FAILURE); } if (verbose_mode) { fprintf(stdout, "Host Resolution results:\n" "Name: %s\n" "Aliases:", hostname->h_name); char **alias = hostname->h_aliases; while(*alias) { fprintf(stdout, "%s ", *alias); alias++; } char **addrs = hostname->h_addr_list; fprintf(stdout, "\nIP address/es:\n"); while(*addrs) { fprintf(stdout, " %s ", inet_ntoa(*(struct in_addr *)*addrs)); addrs++; } printf("\n"); } return hostname; } void Connect_Scanning(void) { int sockfd; char temp_addr[7]; struct sockaddr_in sockaddr; struct servent *serv; struct hostent * hostname; hostname = (struct hostent *)host_resolve(); char **addr = hostname->h_addr_list; /* transfer of dotted-decimal IP of first IP from resolving */ strcpy (temp_addr, inet_ntoa(*(struct in_addr *)*addr)); fprintf(stdout, "Initiating Connect() Scan against %s [%ld ports] \n", temp_addr, (high_port-low_port+1)); int i = 0; for (i = low_port; i <= high_port; i++) { if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("Socket error"); exit(EXIT_FAILURE); } sockaddr.sin_family = AF_INET; sockaddr.sin_port = htons(i); inet_pton(AF_INET, temp_addr, &sockaddr.sin_addr); if (!connect(sockfd, (struct sockaddr*)& sockaddr, sizeof(sockaddr))) { serv = getservbyport(htons(i), "tcp"); fprintf(stdout, "TCP port %d open , possible service: %s\n", i, serv->s_name); } close(sockfd); } fprintf(stdout, "Connect Scanning completed\n"); } void sigfunc(int signum) { /* signal handler */ pcap_breakloop(session); } void Syn_Scanning(void) { s_timeout = DEFAULT_S_TIMEOUT; /* global var for timeout */ int sockfd; int timeout = 0; /* check if timeout with return from dispatch */ char temp_addr[16]; struct sockaddr_in sin; struct servent *serv; struct hostent *hostname; struct sockaddr_in *ipP; /* local ip storage */ hostname = (struct hostent *)host_resolve(); char **addr = hostname->h_addr_list; strncpy(temp_addr, inet_ntoa(*(struct in_addr *)*addr), 16); char datagram[4096]; // buffer for datagrams struct sniff_ip *iph = (struct sniff_ip *)datagram; /* tcp header begins right after the end of the ip header */ /* can it work in reverse ? Of course not */ struct sniff_tcp *tcph = (struct sniff_tcp *)(datagram + sizeof(struct sniff_ip)); struct sigaction act; act.sa_handler = sigfunc; sigemptyset(&act.sa_mask); act.sa_flags = 0; /* read man of libpcap -> SA_RESTART MUST BE OFF */ /* Prepare the Sniffing Engine */ session = (pcap_t *)EnginePreparing(temp_addr, &ipP, session); fprintf(stdout, "Initiating Syn Scanning against %s [%ld ports] \n", temp_addr, (high_port-low_port+1)); int i = 0; for (i = low_port; i <= high_port; i++) { if ((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) < 0) { perror("sock:"); exit(EXIT_FAILURE); } sin.sin_family = AF_INET; inet_pton(AF_INET, temp_addr, &sin.sin_addr); memset(datagram, 0, 4096); /* zero out the buffer */ iph->ip_vhl = 0x45; /* version=4,header_length=5 (no data) */ iph->ip_tos = 0; /* type of service -not needed */ iph->ip_len = sizeof (struct sniff_ip) + sizeof (struct sniff_tcp); /* no payload */ iph->ip_id = htonl(54321); /* simple id */ iph->ip_off = 0; /* no fragmentation */ iph->ip_ttl = 255; /* time to live - set max value */ iph->ip_p = IPPROTO_TCP; /* 6 as a value - see /etc/protocols/ */ iph->ip_src.s_addr = ipP->sin_addr.s_addr; /*local device IP */ iph->ip_dst.s_addr = sin.sin_addr.s_addr; /* dest addr */ iph->ip_sum = /* no need for ip sum actually */ checksum_comp( (unsigned short *)iph, sizeof(struct sniff_ip)); tcph->th_sport = htons(1234); /* arbitrary port */ tcph->th_dport = htons(i); /* scanned dest port */ tcph->th_seq = random(); /* the random SYN sequence */ tcph->th_ack = 0; /* no ACK needed */ tcph->th_offx2 = 0x50; /* 50h (5 offset) ( 8 0s reserverd )*/ tcph->th_flags = TH_SYN; /* initial connection request */ tcph->th_win = (65535); /* maximum allowed window size */ tcph->th_sum = 0; /* will compute later */ tcph->th_urp = 0; /* no urgent pointer */ /* pseudo header for tcp checksum */ struct pseudo_hdr *phdr = (struct pseudo_hdr *) (datagram + sizeof(struct sniff_ip) + sizeof(struct sniff_tcp)); phdr->src = iph->ip_src.s_addr; phdr->dst = iph->ip_dst.s_addr; phdr->mbz = 0; phdr->proto = IPPROTO_TCP; phdr->len = ntohs(0x14); /* in bytes the tcp segment length */ /*- WhyTF is it network byte saved by default ????*/ tcph->th_sum = htons(checksum_comp((unsigned short *)tcph, sizeof(struct pseudo_hdr)+ sizeof(struct sniff_tcp))); int one = 1; const int *val = &one; if (setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0) fprintf(stderr, "Warning: Cannot set HDRINCL for port %d\n",i); if (sendto(sockfd, datagram, iph->ip_len, 0, (struct sockaddr *)&sin, sizeof(sin)) < 0) { fprintf(stderr, "Error sending datagram for port %d\n", i); break; } sigaction (SIGALRM, &act, 0); alarm(s_timeout); // give port as argument to callback function timeout = pcap_dispatch(session, -1, got_packet, (u_char *)i); alarm(0); /* trigger off alarm for this loop */ if (verbose_mode && timeout == -2) { fprintf(stdout, "timeout for port %d\n", i); } } fprintf(stdout, "SYN Scanning completed\n"); } uint16_t checksum_comp (uint16_t *addr, int len) { /* compute TCP header checksum */ /* with the usual algorithm a bit changed */ /* for byte ordering problem resolving */ /* see RFC 1071 for more info */ /* Compute Internet Checksum for "count" bytes * beginning at location "addr". */ register long sum = 0; int count = len; uint16_t temp; while (count > 1) { temp = htons(*addr++); // in this line:added -> htons sum += temp; count -= 2; } /* Add left-over byte, if any */ if(count > 0) sum += *(unsigned char *)addr; /* Fold 32-bit sum to 16 bits */ while (sum >> 16) sum = (sum & 0xffff) + (sum >> 16); uint16_t checksum = ~sum; return checksum; } pcap_t* EnginePreparing (char * vicIP, struct sockaddr_in **ipP, pcap_t *session) { char *dev; char errbuf[PCAP_ERRBUF_SIZE]; bpf_u_int32 devip, netmask; struct pcap_pkthdr header; struct bpf_program filter; /* compiled filter */ char filter_exp[30] = "src host "; /* we filter the traffic to the victim */ pcap_if_t *alldev; /* yes some numbers are HARDCODED as they should be */ /* guess why and then try exploiting it */ strncpy((char *)filter_exp+9, vicIP, 16); fprintf(stdout, "filter exp: %s \n ", filter_exp); if ((pcap_findalldevs(&alldev, errbuf)) == -1) { fprintf (stderr, "%s\n", errbuf); exit(EXIT_FAILURE); } struct pcap_addr *address = alldev->addresses; address = address->next; /*first address is U(F)O*/ struct sockaddr_in * ip; while (address) { if (address->addr) { ip = (struct sockaddr_in *) address->addr; fprintf (stdout, "Local IP: %s \n", inet_ntoa(ip->sin_addr)); } address = address->next; } *ipP = (struct sockaddr_in *)alldev->addresses->next->addr; /* local ip to be used in the raw datagram */ /* choose the first you find -there was some problem when choosing the last * ip since the last found might be 0.0.0.0 and thus chaos would occur */ dev = alldev->name; /*if ( (dev = pcap_lookupdev(errbuf)) == NULL) { printf ( "%s\n" , errbuf ) ; printf ( "Using default eth0 \n"); dev = "eth0" ; }*/ if (verbose_mode) { fprintf (stdout, "Using local IP: %s \n", inet_ntoa((*ipP)->sin_addr)); fprintf(stdout, "Using local Device: %s\n", dev); } if ((session = pcap_open_live (dev, BUFSIZE, 0, 0, errbuf)) == NULL) { fprintf (stderr, "Could not open device %s: error: %s \n ", dev, errbuf); exit (EXIT_FAILURE); } if (pcap_compile(session, &filter, filter_exp, 0, 0) == -1) { fprintf (stderr, "Couldn't parse filter %s: %s \n ", filter_exp, pcap_geterr(session)); exit (EXIT_FAILURE); } if (pcap_setfilter(session, &filter) == -1) { fprintf (stderr, "Couldn't install filter %s: %s\n", filter_exp, pcap_geterr(session)); exit (EXIT_FAILURE); } return session; } void got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char *packet) { const struct sniff_tcp *tcp; const struct sniff_ip *ip; const struct sniff_ethernet *ether; struct servent *serv; int size_ip; int size_tcp; ether = (struct sniff_ethernet*) (packet); ip = (struct sniff_ip *) (packet + SIZE_ETHERNET); size_ip = IP_HL(ip)*4; if (size_ip < 20) { fprintf (stderr, "Invalid IP header length: %u bytes \n", size_ip); return; } if (ip->ip_p != IPPROTO_TCP) { fprintf (stderr, "Returned Packet is not TCP protocol \n"); return; } tcp = (struct sniff_tcp*)(packet + SIZE_ETHERNET + size_ip); size_tcp = TH_OFF(tcp)*4; if (size_tcp < 20) { fprintf (stderr, " * Invalid TCP header length: %u bytes\n", size_tcp); return; } /* the actual SYN scanning (heh) : we examine if the SYN flag is on at the receiving packet(port open) */ if (((tcp->th_flags & 0x02) == TH_SYN) && (tcp->th_flags & 0x10) == TH_ACK) { serv = getservbyport ( htons((int)args), "tcp" ); fprintf (stdout, "TCP port %d open , possible service: %s\n", args, serv->s_name); // RST is sent by kernel automatically } else if ((tcp->th_flags & 0x04 ) == TH_RST && verbose_mode) { //fprintf (stdout, "TCP port %d closed\n", args ); too much info on screen } else if (verbose_mode) { //fprintf (stdout, "Port %d state unknown/filtered \n", args); } } -------------- 0x7. Epilogue -------------- If you have managed so far and studied the source coude, then well done. I hope that you have learned something through all this guide and that it aroused your interest for the sector of network programming and security applications/tools on which is based. Like I mention in the source 's introduction I will value any feedback and I encourage you to make your own changes and improvements on the code, as I believe that as a whole it just sets the base for a custom security scanner. Possible expansions for the tool: 1) IP spoofing capabilities 2) Real time port randomization 3) Alternate probing and IP expiry tactics For any ( serious ) contact about the project mail me here -> ithilgore.ryu.L@gmail.com ---------------- 0x8. References ---------------- -UNIX Network Programming Volume 1, Third Edition: The Sockets Networking API -http://mixter.void.ru/rawip.html (raw sockets tutorial) -http://www.netfor2.com/checksum.html (IP checksum introduction) -http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader.htm (TCP checksum and pseudo header) RFCs -http://www.ietf.org/rfc/rfc0791.txt (IP) -http://www.ietf.org/rfc/rfc0793.txt (TCP) -http://www.ietf.org/rfc/rfc1071.txt (Checksum) -http://www.tcpdump.org (libpcap + tcpdump) --EOF--

Grendel-Scan is an open-source web application security testing tool. It has automated testing module for detecting common web application vulnerabilities, and features geared at aiding manual penetration tests. The only system requirement is Java 5; Windows, Linux and Macintosh builds are available. Download: http://grendel-scan.com/download.htm

Project Description Marathon Tool is a POC for using heavy queries to perform a Time-Based Blind SQL Injection attack. This tool is still work in progress but is right now in a very good alpha version to extract information from web applications using Microsoft SQL Server, Microsoft Access, MySQL or Oracle Databases. Application Supported features: Database Schema extraction from SQL Server, Oracle and MySQL Data extraction from Microsoft Access 97/2000/2003/2007 databases Parameter Injection using HTTP GET or POST SSL support HTTP proxy connection available Authentication methods: Anonymous, Basic, Digest and NTLM Variable and value insertion in cookies (Does not support dynamic values) Configuration available an flexible for injections Configurable Log Common Help Topics Configuration: http://marathontool.codeplex.com/Wiki/View.aspx?title=Configuration Reference Links http://technet.microsoft.com/en-us/library/cc512676.aspx Download: http://marathontool.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=16106 Source Code: http://marathontool.codeplex.com/SourceControl/changeset/view/35134

Nu stiu si nu ma intereseaza, e a mia oara cand o spun.

Nu, nu am incercat nimic din ce am postat, nu stiu daca sunt infectate sau nu si nu imi pasa.

Ban, spam, calm tati.