12 ms·

Libtins – High-level and multiplatform C++ network packet sniffing and crafting

111 points by adulau 9y ago

ktta 9y ago
>Note: the scapy benchmarks look like it takes almost the same time as the impacket ones, but it actually doesn't. In fact, it takes so much time that the maximum Y-axis value had to be restricted. Otherwise the rest of the bars couldn't almost be seen. If you hover over each bar, you will see the actual times in seconds. wow, they weren't kidding. In the first and the last graph, scapy is ten times slower than the next slowest lib.
- d33 9y ago
  Well, scapy's code is not of the highest quality - it still uses os.popen and calls tcpdump: https://github.com/secdev/scapy/blob/728177bff883f170e9ac0042fa9723888ef6888d/scapy/arch/linux.py https://github.com/secdev/scapy/blob/728177bff883f170e9ac004...
deleted 9y ago
[deleted]
jaimehrubiks 9y ago
How flexible it is despite being high level? I mean, can I use any field on those supported protocols? Can I tunnel TCP inside, say, dns? can I implement/send custom protocols without touching the lib?
ktta 9y ago
Also check out packit[1] a command line packet crafter. It is very easy to use once you really understand how to use it. Also it has no 'restrictions' on what packets can be crafted. It lets you get away with as much as possible. It should be readily available on most package managers, atleast debian based last time I checked. [1]:http://packetfactory.openwall.net/projects/packit/ http://packetfactory.openwall.net/projects/packit/
- mariuolo 9y ago
  The active version appears to be hosted here: https://github.com/eribertomota/packit https://github.com/eribertomota/packit
  - ktta 9y ago
    No, I thought so too initially. The person is just hosting the project looking for a maintainer(he is hosting other abandoned projects too). Debian project is also looking for someone to maintain the package.
    - mariuolo 9y ago
      Still, Debian packages the (updated) github version. At least in Sid.
jzwinck 9y ago
The linked page says "High level != inefficient" and shows an example program which will print "every TCP packet". With no "if" anywhere in the code, I wondered how it knew to print only TCP packets and not others. And the answer turns out to be that it throws a C++ exception on every non-TCP packet! If most of the packets on your network are TCP, this is sort of OK. But if you have mostly non-TCP packets, this toy program costs about 10x the CPU utilization that it would if it used "if" instead of magic.
- _wmd 9y ago
  There are plenty of ways they can keep the current API while eventually approaching optimal, for example, a chain of exceptions could incrementally refine the framework's idea of what the callback function expects, which could be turned into a BPF filter. So for the cost of a few expensive frames at start, afterwards no exceptions get thrown. Generally speaking though, I'm only replying because I hate people negging on minutia of new projects. If you're going to be critical of something especially when it's a lone wolf effort (or even a small team), try to be constructive, there are real people on the other end of the wire.
  - tjoff 9y ago
    I thought the criticism was quite valid. If high efficiency wasn't touted as a feature then it would have been fine. But when it turns out that one of the main selling points is performance (with no expressed limitations or restrictions) and regular patterns perform badly, as a consequence of the design, then it is quite valid criticism. (Whether this is the case in practice I don't know but GP brings up a very valid point) GPs point begs the question - Why was it designed in such as way? Quite possibly the tradeoffs were considered and the current solution was targeted because of several reasons. But the page doesn't convey any of that, it simply states that "In fact, it is one of the fastest packet sniffing and interpretation libraries available.". While I agree with your point the library isn't exactly marketed as a lone wolf effort either, and that will also affect the criticism it will receive.
  - jzwinck 9y ago
    A more charitable reading of my comment would be that I am recommending the use of "if" instead of C++ exceptions for hot-path control flow in high-performance libraries. Heuristic construction of a packet filter based on previously seen exceptions is infeasible with the current API because rejection of the first N non-TCP packets does not guarantee rejection of the next one.
hacknat 9y ago
If anybody is interested I wrote a zero-copy socket wrapper in golang it's pretty fast and has built in layer detection and checksum functions: https://github.com/nathanjsweet/zsocket https://github.com/nathanjsweet/zsocket
01572 9y ago
Since commenters are weighing in on packet construction libraries, what say you in re: libnet1.0/libnet1.1? libnet-based modular utilities that can be used in shell scripts: http://nemesis.sourceforge.net/docs.html http://nemesis.sourceforge.net/docs.html Also, earlier was nc-data. Slow but allows constructing any packet from the command line. Not limited to known packet formats. http://nc110.sourceforge.net http://nc110.sourceforge.net Let us hear your criticisms.
CoC_CRUSHER 9y ago
Would love to see a header only version of this library.
vram22 9y ago
Somewhat related: pcapy is a useful Python library for network packet handling. We used it recently in a project after evaluating it and a few others (not very thoroughly, though). dpkt is useful too. pcapy can read from a live stream or from a packet capture file (.pcap format).
- jcul 9y ago
  I've found pyshark to be great too, especially for reading from a pcap. Scapy is great but has too many performance issues.
  - vram22 9y ago
    Thanks, will check out pyshark. I read the same about scapy somewhere, otherwise its interface seemed good (on only a little trying).

111 points by adulau 9y ago

ktta 9y ago

>Note: the scapy benchmarks look like it takes almost the same time as the impacket ones, but it actually doesn't. In fact, it takes so much time that the maximum Y-axis value had to be restricted. Otherwise the rest of the bars couldn't almost be seen. If you hover over each bar, you will see the actual times in seconds. wow, they weren't kidding. In the first and the last graph, scapy is ten times slower than the next slowest lib.

d33 9y ago
Well, scapy's code is not of the highest quality - it still uses os.popen and calls tcpdump: https://github.com/secdev/scapy/blob/728177bff883f170e9ac0042fa9723888ef6888d/scapy/arch/linux.py https://github.com/secdev/scapy/blob/728177bff883f170e9ac004...

deleted 9y ago

[deleted]

jaimehrubiks 9y ago

How flexible it is despite being high level? I mean, can I use any field on those supported protocols? Can I tunnel TCP inside, say, dns? can I implement/send custom protocols without touching the lib?

ktta 9y ago

Also check out packit[1] a command line packet crafter. It is very easy to use once you really understand how to use it. Also it has no 'restrictions' on what packets can be crafted. It lets you get away with as much as possible. It should be readily available on most package managers, atleast debian based last time I checked. [1]:http://packetfactory.openwall.net/projects/packit/ http://packetfactory.openwall.net/projects/packit/

mariuolo 9y ago
The active version appears to be hosted here: https://github.com/eribertomota/packit https://github.com/eribertomota/packit
- ktta 9y ago
  No, I thought so too initially. The person is just hosting the project looking for a maintainer(he is hosting other abandoned projects too). Debian project is also looking for someone to maintain the package.
  - mariuolo 9y ago
    Still, Debian packages the (updated) github version. At least in Sid.

jzwinck 9y ago

The linked page says "High level != inefficient" and shows an example program which will print "every TCP packet". With no "if" anywhere in the code, I wondered how it knew to print only TCP packets and not others. And the answer turns out to be that it throws a C++ exception on every non-TCP packet! If most of the packets on your network are TCP, this is sort of OK. But if you have mostly non-TCP packets, this toy program costs about 10x the CPU utilization that it would if it used "if" instead of magic.

_wmd 9y ago
There are plenty of ways they can keep the current API while eventually approaching optimal, for example, a chain of exceptions could incrementally refine the framework's idea of what the callback function expects, which could be turned into a BPF filter. So for the cost of a few expensive frames at start, afterwards no exceptions get thrown. Generally speaking though, I'm only replying because I hate people negging on minutia of new projects. If you're going to be critical of something especially when it's a lone wolf effort (or even a small team), try to be constructive, there are real people on the other end of the wire.
- tjoff 9y ago
  I thought the criticism was quite valid. If high efficiency wasn't touted as a feature then it would have been fine. But when it turns out that one of the main selling points is performance (with no expressed limitations or restrictions) and regular patterns perform badly, as a consequence of the design, then it is quite valid criticism. (Whether this is the case in practice I don't know but GP brings up a very valid point) GPs point begs the question - Why was it designed in such as way? Quite possibly the tradeoffs were considered and the current solution was targeted because of several reasons. But the page doesn't convey any of that, it simply states that "In fact, it is one of the fastest packet sniffing and interpretation libraries available.". While I agree with your point the library isn't exactly marketed as a lone wolf effort either, and that will also affect the criticism it will receive.
- jzwinck 9y ago
  A more charitable reading of my comment would be that I am recommending the use of "if" instead of C++ exceptions for hot-path control flow in high-performance libraries. Heuristic construction of a packet filter based on previously seen exceptions is infeasible with the current API because rejection of the first N non-TCP packets does not guarantee rejection of the next one.

hacknat 9y ago

If anybody is interested I wrote a zero-copy socket wrapper in golang it's pretty fast and has built in layer detection and checksum functions: https://github.com/nathanjsweet/zsocket https://github.com/nathanjsweet/zsocket

01572 9y ago

Since commenters are weighing in on packet construction libraries, what say you in re: libnet1.0/libnet1.1? libnet-based modular utilities that can be used in shell scripts: http://nemesis.sourceforge.net/docs.html http://nemesis.sourceforge.net/docs.html Also, earlier was nc-data. Slow but allows constructing any packet from the command line. Not limited to known packet formats. http://nc110.sourceforge.net http://nc110.sourceforge.net Let us hear your criticisms.

CoC_CRUSHER 9y ago

Would love to see a header only version of this library.

vram22 9y ago

Somewhat related: pcapy is a useful Python library for network packet handling. We used it recently in a project after evaluating it and a few others (not very thoroughly, though). dpkt is useful too. pcapy can read from a live stream or from a packet capture file (.pcap format).

jcul 9y ago
I've found pyshark to be great too, especially for reading from a pcap. Scapy is great but has too many performance issues.
- vram22 9y ago
  Thanks, will check out pyshark. I read the same about scapy somewhere, otherwise its interface seemed good (on only a little trying).