I'm fairly new to C programming language and packet capturing.
Right now I'm writing a simple program (using Visual Studio 2010 express) to decode a packet trace capture file. I read a number of guides, but most of them are for linux/unix. I managed to include wpcap libraries, but now i need structs defined in the system that are intended to
make decoding Internet packet headers easier.
struct ether_header in /usr/include/sys/ethernet.h
struct in_addr in /usr/include/netinet/in.h
struct ip in /usr/include/netinet/ip.h
struct udphdr in /usr/include/netinet/udp.h
struct tcphdr in /usr/include/netinet/tcp.h
Up until now I understood that winsock2 must be included for in.h, but what about ethernet, ip, tcp/udp? What should i do to manage decoding related to these headers? is it same winsocket? if it is, where could i find simple explanation of what methods to use?
OS: Win 7
Actually, most of those headers were originally intended to make writing the BSD kernel networking stack easier, not making decoding packet headers in sniffers easier; they're present for user programs in part for historical reasons.
I'd suggest getting the source to recent versions of tcpdump or WinDump and making your own copies of the corresponding header files in it; the ether.h, ip.h, udp.h, and tcp.h files from tcpdump/WinDump are taken from BSD-derived operating systems so that tcpdump/WinDump don't have to depend on the operating system supplying those headers or on it supplying particular versions of those headers (not all of the operating systems on which tcpdump/WinDump can run supply versions that work well with tcpdump/WinDump, with some of them requiring special hackery for tcpdump and some others not supplying them at all - Windows, for example, doesn't supply them at all, as you've discovered).
You can get the tcpdump source from tcpdump.org, and the WinDump source from winpcap.org (look under "WinDump 3.9.5 Source Code Download"). The WinDump source is in a ZIP file rather than a gzipped tar file, so it might be easier to unpack on Windows, and might have Windows CR-LF line endings rather than UN*X LF line endings, so you might want to try the WinDump versions.
Even though you're working on Windows, as you're using libpcap you might get some mileage from Unix Network Programming vol. 1 and TCP/IP illustrated Vol. 1. You can buy these new or secondhand off Amazon Marketplace. This will explain the headers and other related items.
I only include these (in this order)
#include <winsock2.h>
#include <windows.h>
Related
Is there really no way to copy a local file by
using some portable way
using built in golang calls ...
... which in turn use the native API of the operating system ?
All ways I found make use of some kind of Reader / Writer or use buffers to copy the content of the source to the target, either bytewise or blockwise or - even worse - spawn commands like cp.
Even add on libraries like [gut/yos][1] that I found by searching awesomego internally do the same
The downside of just reading the source file and writing the content to a new file is that you have to take care that these "properties" (depending on the OS you are using) of the source and destination match:
timestamps
permissions
setuid bits
(soft/hard) links
alternate data streams
I know there are specialized libraries that for example expose the Windows API and enable one to call CopyFileEx. But this approach would be limited to Windows and I need at least to support Linux.
Linux operating system identifies files by looking at its magic number at the starting of the header. How does windows do it ? Does it also have some kind of magic number mechanism or does it only rely on the file extension ?
It relies only on the extension, as provided by the filesystem; the contents of the file are not examined. See e.g. this article - it talks about Windows XP, but AFAIK the general behavior is shared by all released versions of Windows so far: http://support.microsoft.com/kb/307859
Is there a version of the CUPS server available for Windows? Looking at the CUPS source code it seems it is ready for Visual Studio compilation, but I did not find any trace of an actual supported package. I'd like to set up a CUPS server on Windows so that I can print form Linux/MacOSX/Win clients to printers I set up on this server.
I've got a new answer for you:
Since some time there is a project called ippsample on GitHub. It's slowly approaching a mature version 1.0 release.
Here are the first two sentences of given as self-description in the mandatory README file:
"This code provides sample implementations of IPP Clients, Printers, and Proxies. It is largely based upon the CUPS software, with substantial changes to the ippproxy and ippserver implementations to make them more general-purpose and configurable." (my emphasis)
This project is hosted by the ISTO Printer Working Group (PWG), the same industry organization which develops and promotes the IPP as a general standard.
The ippserver, ipptool, ippfind, ippproxy and ipptransform components of the IPP Sample project together make up for a standard-conforming IPP Everywhere implementation, covering the client as well as the server side of printing.
The GitHub code for IPP Sample project is maintained by the very same Mike Sweet who also develops CUPS -- so it's the real thing.
Yes, it compiles and works nicely on Windows, and there are a bunch of .vclxproj and .sln files available to make the build process with MS Visual Studio as smooth as possible.
Yes, the IPP Sample code is working and can print to a CUPS server (or receive print jobs from there) running on macOS or any blend of Linux.
No, this is not yet a fully-blown CUPS server for Windows which can serve as a drop-in replacement for a Windows print server. It does not have with ALL the features which would be required.
But if you want to create such a beast:
this is the place were you would have to poke around first;
this is were you possibly could fork the code and start adding functionality to get where you want to go.
Oh, and did you know that Apple recently changed the license conditions for CUPS and made it more permissive, moving away from GPL2 to Apache 2.0 licensing?
You have never heard of "IPP Everywhere" before? It is the future of "driverless" printing.
Never heard of "driverless printing"? A slightly modified (and stripped down) version of it already implemented as "Apple AirPrint" for iPhone and iPad devices.
The current implementation of the CUPS-based printing stack includes new pieces of code in the cups-drivers project which recently moved to GitHub. This new code implements IPP Everywhere functionality.
This cups-filters project is under the stewardship by The Linux Foundation's OpenPrinting department ever since Apple handed over these parts of the original CUPS source code to them when they became no longer useful for macOS but were still important to Linux.
What are the basic ideas of driverless printing then?
Have the devices automatically announce their presence and their type of service in the local network. Use the IETF standard protocols mDNS and DNS-SD (which are implemented in macOS under the name of "Bonjour" and in Linux as "Avahi") to take note of the offered services.
Tell the print clients that they can use the IPP protocol in order to get a query response when they make a get-printer-attributes request. This request will tell them which set of print options the devices support. The print clients can then show an exactly tailored print dialog to show to the printing user a selection of choices. The print client will also be told what job submission formats each devices supports. This MUST be either PDF or a simple raster format called "PWG-Raster".
So... where would you need a specific "printer driver" in such an environment? Everything and everyone can create PDF documents nowadays. Check! No need for a device-specific conversion to any other print language.
Are there printers which support IPP Everywhere already? Oh yes, look here -- they are all said to be fully compliant with the standard:
List of IPP Everywhere printer models
The .sln and .vcproj files you've been seeing in the CUPS sources are not meant to compile all of CUPS for Windows.
They serve to compile only a few of its utilities (such as ipptool.exe)...
Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world.
CUPS uses Internet Printing Protocol for client-server communications. According to Technet article, Windows can be used as IPP host:
To enable a computer running Windows
Server 2008 to act as a server
supporting Internet printing, you must
install the Web Server (IIS) role, the
Print Services role, and the Internet
Printing role service in the Print
Services role.
Moreover, it seems that Windows, Linux and Mac OS X clients can use printers shared via SMB.
"Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world."
Back in the dial up internet days, I ran into a problem where some IPS' had a replacement dll for modem functionality. The problem with it was that the dll prevented legit programs from accessing the modem until you uninstalled the IPS program.
This same technique can be used to create a Windows CUPS server by writing a Windows spooling and printing replacement program that, rather than printing directly to the printer, hands off the printing tasks to the CUPS server.
It would of course, take someone with in depth knowledge of the windows spooling and printing protocols.
cygwin ports has patch files for implementing a cups in (some versions of) cygwin. I can't speak to how well it might work.
https://github.com/cygwinports-extras/cups
I remember a few years ago(2002) there was a multipartite virus that could be run natively on linux and windows. I don't know if a compiler could be specially craft an executable so that it could be read as both ELF and PE, so that the os would start executing at different entry points. Or a program that could merge two programs, one compiled using mingw, one compiled in native linux, to one program.
I don't know if such a program exists, or could it exist, and I'm know this could be implemented in Java or some scripting language, but that's not a native program.
Imagine the possibilities, I could deploy a program with linux and window (and perhaps os/x)libraries, and one main executable that could be run on any os. The cross-platform support would compensate the bigger size.
Windows programs have a DOS stub in the beginning, and I just ran an ELF executable through debug.com, which said that the first instruction of this exe was JG 0x147. Just maybe something could be done with this...
No.
Windows and Linux use vastly different binary file formats. See Portable Executable (Windows) and Executable and Linkable Format (Linux).
Something like WINE will run Windows executables on Linux but that's not the same thing.
This is actually a really terrible idea for multiple reasons.
Cross-compiling across operating system boundaries is extremely difficult to do properly.
If you go for the second route (building separate PE binaries on Windows and ELF on Linux, and then somehow merging them) you have to maintain two machines, each running a different OS and the full build stack, and you'd have to make sure that you tested both versions separately before gluing them together.
Dynamic linking is already a pain to properly manage, on Windows and on Linux; static linking can generate binaries that are much more inconvenient to deal with than whatever imaginary benefits you get from providing one single file type to your end-user.
If you want to run the same binary executable file on multiple OSes, your options are Java, Mono, and potentially NativeClient, the browser plug-in Google's developing to work around the "webapps are too slow" problem.
I'm looking for a tool (or a set of tools) for Windows that will perform the following:
Capture UDP packets from a specific network interface to a file.
Play a stream of packets from a file through a network interface.
In addition to 2: replay the original packets to a different host than the original one.
I've already got 1 and 2, but I can't find a tool to do 3.
For capturing I can use Wireshark, for playback Colasoft Packet Player, but I couldn't find a way to change the host the packets are sent to.
The tool should work on Windows XP SP2/3.
The BitTwist (http://bittwist.sourceforge.net) editor commandline program (bittwiste) allows you to change the destination IP address (and port number) amongst other things.
See a similar question (and worked answer) at the Super User site: Replay UDP Packet Capture
You mention Colasoft Packet Player and it sounded like a useful tool, so I checked it out.
While checking their site I found they also have Packet Builder.
It seems this tool can import pcap files (and some other formats) and edit them. It can then export the edited packets again, but only to Colasoft Capsa Packet files (Colasoft's own capture file format). But that should not be a problem as Packet Player is be able to read their own format.
Unfortunately it seems there is no way to edit multiple packets at the same time, so it's a tedious process to edit a lot of packets.
Try out WinPCap which allows very low-level intercept and injection of packets. It is an open source project that many other stateful packet inspection programs (e.g. Ethereal) are based on.
I use a hex editor to do a global search and replace on the PCAP file to change the destination MAC and IP. For Unicast you need to change both - not just the IP.
You could change more than the addresses, but for quick-n-dirty it's OK.
Bork Blatt mentioned Ethereal, which has been renamed to Wireshark for various reasons, so go to the new site directly. I've never tried editing packets in Wireshark, but you do get the option to save out the packets so you can work with the files offline to change the packets. Do get started with this, check out the libpcap file format documentation.
I've found out that the tcprewrite tool provides editing capabilities to .pcap files. Unfortunately, it does not support Windows.
for visual inspection you can use wire shark tool but you need advanced tool then use wpdpack libraries. It is available in this site.
https://www.winpcap.org/devel.htm
Similar like wire shark you can capture using TestPacketCapture visual studio solution.