Summary
Network protocols are often inscrutable, but if you have an effective way to experiment with them then they expose a lot of power. This week Guillaume Valadon explains how Scapy can be used to inspect your network traffic, test the security of your systems, and develop brand new protocols, all in Python!
Preface
- Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
- I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
- When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at www.podastinit.com/linode?utm_source=rss&utm_medium=rss and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app.
- Visit the site to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch.
- To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
- Get a shirt and support the show! Go to https://teespring.com/podcastinit?utm_source=rss&utm_medium=rss and get a mug to go with it.
- Your host as usual is Tobias Macey and today I am interviewing Guillaume Valadon about Scapy, the swiss army knife for packet manipulation in Python
Interview
- Introductions
- How did you get introduced to Python?
- Can you explain what Scapy is and what problem it was created to solve?
- How has the decision to build Scapy in Python benefited the project?
- How has the 10 year history of the project affected your ability to maintain and evolve the code?
- How has the project evolved from the initial prototypes by Philippe Biondi through to its current incarnation as Scapy 2?
- I understand that the project was originally hosted on Bitbucket and then moved to Github. What prompted that decision and how has it played out?
- Who is the target audience and what are some of the primary intended use cases for Scapy?
- How is the implementation of packet layering architected in order to allow for such flexibility and composability?
- What are some of the most interesting and unexpected ways that you have seen Scapy used?
- What protocols have been the most problematic to implement and maintain?
- What have been some of the most challenging aspects of developing Scapy?
- What do you have planned for the future of Scapy?
Contact Info
Picks
- Tobias
- Guillaume
Links
- Six
- UTScapy
- CodeCov
- Appveyor
- Jython
- OpenBSD
- MicroPython
- NSA
- Extra Bacon
- SNMP
- ASN.1
- X509
- TLS
- IPSec
- DNS
- HTTP2
- PEP8
- Scapy 3
The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA
[00:00:14]
Unknown:
Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable. When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out linode at ww w.podcastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your app or experimenting with something that you hear about on the show. You can visit the site at www.podcastinit.com to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch. To help other people find the show, please leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media. You can also now get a t shirt and help support the show by going to teespring.com/podcastinit.
You can also pick up a mug and a sweatshirt while you're at it. Your host as usual is Tobias Macy. And today, I'm interviewing Guillaume Veladon about Scapy, the Swiss army knife for packet manipulation in Python. So, Guillaume, could you please introduce yourself?
[00:01:10] Unknown:
Yeah. So hello, everyone. So my name is Guillaume. I'm French, and I've been managing escapee since a few years, by now. During my, let's say, day life, I'm doing network security. And, me and my team, we use a lot, Scapy to, play around with the network and implement, new protocols.
[00:01:33] Unknown:
And do you remember how you first got introduced to Python?
[00:01:36] Unknown:
The first time was, I think, in 2003, during a conference, and someone was presenting the language. And I think my first, first thing I said about Capi Python, sorry, was to, that I didn't like the way, they were enforcing, the way you have to code. You see, the I didn't like at that time the fact that you don't have to put brackets, for example, and you need to indent your code. I did, like like, let's say, 15 years after that. That's what I like with Python, the way that the language is forcing you to indent your code and making your life easier, and also making your code, easier to read. And the first project I did with Python was indeed, like, playing around with Scapy. The first time was in 2004, I guess. And so it's a mix between Python and Scapy for me, at least. I started Python because of Scapy.
[00:02:26] Unknown:
And can you explain what Scapy is and the problem that it was trying to solve when it was created?
[00:02:32] Unknown:
So first of all, I'm just 1 of them Scapy met now. The other 1 being, Pierre Lale. And Skeppy was designed and implemented by Philippe Lionli, another French guy, in 2003. And the main goal of Skype is to ease, people live when it comes to playing with the network, which is sending packets to network, receiving them, and also implementing new protocols. So Scapy is really good at helping you and people to easily and quickly, implement a new protocol. For example, adding a new network protocol, adding a new packet header, it's just in in between 10 or 15 lines of Scapy, which is really, really nice and simple. And Scapy helps you to do that. It provides you, let's say, enhanced Python shell where you can send packet to network, read them, and interact with packets. And also, you can use KPI as a regular Python module in order to build your own tools and build your build your tools on top of KPI.
[00:03:34] Unknown:
And if you do have a custom packet format, is it possible to provide a definition for that so that as you receive those packets, it can, sort of unpack them as it as the packets are arrive into your program?
[00:03:48] Unknown:
Yeah. The the the way it goes indeed in Scapy, what you need to do is to define the, an object. Let's call it, like, for example, layer 1, and you will also describe in Python the fields in your layer 1 packet. And most of the times, Scapy will do the job for you of, like, reading the packet from binary into a Python object and then taking your Python object and converting it to binary. And that's just a matter of, like, defining a new class and defining, a list of fields.
[00:04:18] Unknown:
That would have been very handy in a project I was involved in a few years ago where we had a custom sensor and we had a custom packet definition where the different bit fields within the headers had different meanings. And so we needed to write some custom code to parse those out from the binary object and then figure out what those different fields were supposed to pertain to. So it seems that Scapy would have been able to solve that problem much more elegantly than the code that we ended up having to write. That, yeah. That's a typical use case. Like, hence, of course, generic. So you can reuse
[00:04:51] Unknown:
your packet definition, whatever you need. So the thing I really like about this project is just you are not stuck with 1, let's say, way of doing thing. If you decide to implement your packet in order to decode it, and later on, you can also decide to inject it in the network. And that's what I really like. Only 1 definition, 1 piece of code, and you can do both, sending and receiving. And when it comes to playing with, protocol, for example, for security audits, defining a new protocol for experiments, it's really, really powerful.
[00:05:21] Unknown:
How has the decision to build Scapy in Python benefited the project? And are there any edge cases where Python starts to fall down in terms of the implementation?
[00:05:31] Unknown:
I don't know why. Indeed, Philippe started, to use, Python for Skyping. I guess that's mainly because the language is really flexible. It was easier to achieve this kind of tool with Python rather than than c. But, for this project, Python is really good because of its dynamic features. It allows us to benefit for the dynamic creation of object, for example. Also, it's really simple with Python to have your own shell. So for us, Python is like, and Scapy on top of Python is like a domain specific language, and that's really nice because we can enhance Python language with the SAPI features. And another benefit for us is, there's a lot of targets, meaning that's operating system or architectures for Python.
And also, today, Python is everywhere. So it's really easy to to have a tool that works on Windows, OS 10, FreeBSD, OpenBSD, and so on. And that's, for me, I guess, the main benefit of Python. On the other end, Python and the way Skype is defined and developed is makes Scapy slow in some situation. For example, if you want to inject a lot of packets really fast or if you want to read a lot of packets from the network to sniff packets really, really fast too. And Scapy, because the way it's like building objects on the fly and dynamically is, let's say, slow. However, slow is, you can still be able to inject at the rate of, let's say, 200 megabits per second, and you can also achieve the same speed while sniffing the network. So that's really slow, but today we have, like, gigabits
[00:07:04] Unknown:
or 10 gigabits interface. So to that extent, the SCAPI is slow. And would something like Cython give you the opportunity to speed up the critical pieces to increase that overall throughput?
[00:07:16] Unknown:
Not to my knowledge. We tried, PyPI last year, for example, but, we didn't manage to make it faster by, switching the Pycelle interpreter. And recently, I tried a project from Facebook or Instagram. I forgot, but some stuff. There's not a big benefit of, of changing the Python interpreter.
[00:07:36] Unknown:
And given the fact that you're dealing with network protocols, so mostly at the bits and bytes layer, what are some of the challenges posed by Python 3? I noticed that it is not yet supported. So I'm sure that dealing with the shift to how bytes and bits are handled in the newer version is likely going to pose a bit of an issue for you.
[00:07:57] Unknown:
There's indeed some contributors trying to push, let's say, a compatibility layer into Scapy to achieve Python 2 and Python 3 compatibility. And that's kind of hard to do because the switch of the the way bytes, handle in Python 3 makes it difficult to make this compatible version. But hopefully, that's something they will manage to achieve in this year in 2017. So that means, like, we need to change a lot of codes to have this compatibility layer. So 1 of the perspective is to use the 6 Python modules in order to abstract Python 2 specific stuff or Python 3 specific stuff. And on this topic, 1 important fact to keep in mind is that we try to stay Python 2.5, 2.6, and 2.7 compatible until, late 2016, which means that we are not able to use, let's say, 2, 7, and 3, compatible features, such as list comprehension and so on. So we had to deal with the backward compatibility of, maintaining, Python 2.5 compatibility. And that's something we try to keep as long as possible as the use case here was, for example, you are doing a a network audit and a really old, and you find a really old Linux, computer's laptop, and only has a Python 2.5, and you want to escape it. So that's why we try to keep this compatibility for long in order for people to to be able to use KPI, let's say, everywhere. But because the language, let's say, Python 2.5 language is all, we decided to drop this, backward compatibility.
[00:09:32] Unknown:
And given that the project has been around for 10 years, I'm sure that that has also added some legacy weight to that backwards compatibility, as well as increasing the overall effort
[00:09:46] Unknown:
Yeah. But I I think we won't move to Python 3 only. So we we'll try to achieve some some way to run both Python 2 and Python 3 on Scapy or with Scapy. And, yeah, we have, like, some a lot of things we need to clean up. For example, we have a lot of map functions in Scapy. It's like, more than 100, and we need to rewrite them using, these comprehensions. And that takes a lot of time. Of course, 223, the tool, help us to do that. But for some time, we need to fix, let's say, weird syntax ourselves. So it takes time to just to clean up the Scapy code and make it, let's say, more recent. Like removing the old 2.5 or 2.6 only, parts of the code takes time to remove that.
[00:10:30] Unknown:
And how has the overall project evolved from the initial prototypes that were created by Felipe Endy through to its current incarnation as Scapy 2? I think a lot a lot changed.
[00:10:42] Unknown:
Like, last year, we tried to do some archaeology with Philippe, and we found the first, Scapy file, which was not called Scapy at that time. It was like a pyrates or pyrats. It was just a single file, and it was the first, let's say, PC.ovscape insight. And at that time, the tool only allows you to inject packets at layer 2. It was not able to read the packets, but still you could find, you can find the file the syntax which is quite similar. And so that was in November 2003 2002. Sorry. And then Philippe decided to start Skype in 2003. And at first, again, it was a single file, scapy.py.
That's something you can just download on a laptop, on your server, and start, using Scapy. It was really convenient, for example, for security audits, but the design was not perfect and the site was, like, getting bigger and bigger. And the last, release, which was a Scapy, of the Scapy 1 branch, it was in 2008, and Philippe decided to split this, scapy.pwad file into a Python module, and that was released in 2008. It was called Scapy 2. So design is a bit different, and it's more similar to what you can expect from a regular Python module with, directories and some modules and so. And then so it was a release of version 2 in 2008. And then the project, evolved, in between 2008 and 2000 11. And finally, Philippe didn't have time to, maintain the project, and not much did happen in between 2011 and 2, 040 2014.
Sorry. So Philippe asked us, like, it was me, Pierre, and Nicolas to take over the code and try to maintain it. So I tried to we tried to do that. And the first, let's say, new release happened in, 2014, with, Scapy, 2 dot 3 dot 0. It was mainly, at that time, fixing all bugs, merging, let's say, also all pull requests. It was, like, basic maintenance maintenance work. So the project evolved a lot since, it's, like, almost 15 years now. So a lot of, things changed. For example, Philippe decided to do his own unit test, and the tool is called UT Scapy. And the main goal was to achieve what we do today with the BiTEs, for example, to have unit test of the code inside Scapy. But at that time, we had to Philippe had to develop its own system. So also a big change compiled for
[00:13:13] Unknown:
to escapee 1. And I understand that in the process of that evolution, you were originally hosted on Bitbucket and then moved to GitHub. So I'm wondering what prompted that decision
[00:13:24] Unknown:
and how has that decision played out. So first, the move was, I think, the best decision someone in the project ever made. It was the other mate, Pierre, who decided to do that. And the first goal was to move from Mercurel to Git. It was not about GitHub at this time, but, we both use Git a lot in our project, who are credited our personal project. So we wanted to stop using a Mercurial for Scapy. So that's what we did. And then we also decided to move to, GitHub, and the goal was just to attract more people. There is indeed more people with GitHub accounts, people with, Bitbucket accounts. So at first, it was a the main idea was to move the project to GitHub to attract more issues, more contributors, and so on. And finally, what we got, we got also more maintenance, more people helping out with the project. And, we moved to GitHub in January 2016. And since then, the project is, let's say, more active than it has ever been done. There's a lot of issues, a lot of poll requests. Also, the really like the poll ecosystem on GitHub because of specific features like the merge or the squash, feature. And also, there's a lot of services that we are using like Travis for CI. So at first, we used Travis to check for Linux and, you need to run when you need test on Linux. Then we also added OS 10, and then we are also able to test KPI on Linux, OS 10, with a regular user, with roots, and so on. And later on in was in November, we added support for AppVeyo, which is a unit test on Windows. And finally, in December, we had support to Codecov, which is a website that displays your code coverage.
And I think that was a smart move to move to GitHub, mainly because of these services. Like, it's really simple to make your pull request trigger calls to these services and then launch launch tests. And indeed, Capi code, like, is getting better and better, the quality of the code, and the stability, mainly because of this, Travis and Adeo websites.
[00:15:26] Unknown:
And going back briefly to your mention of the multiple platform support, 1 thing that I meant to ask is whether you're aware of if Scapy is able to run on MicroPython for being able to be used in microcontrollers or embedded systems.
[00:15:41] Unknown:
No. I never tried. At some point, like, when, like, some weird requests, for example, to make it work on, which was the name, Jython, the Java, JVM based Python. But I think it's not working. And last week, we had a pull request to a project, I forgot, which is a Python app, interpret on, iOS. But this, like, the iOS based 1 or the Java 1, they are really specific because you miss a lot of, let's say, bits from the OS module, and Skype relies relies on that a lot. So I don't know if it will also will also be the case with a micro Python. I will suspect that it won't work. I mean, the packet passing parts, maybe. Packet building also, but injecting and receiving packets, I guess that's, they won't won't be able to to to work. For example, PyPy, last time I checked, 1 year ago, was not able to fully run Scapy. For example, you are not able to inject, packets with, the type, IP IP row. So indeed, Scapy is not fully working on, on PyPI. You you can't inject packet with PyPI, at least last time I checked 1 year ago. Because, a specific, like, call it Cisco, even though it's not it's not 1, was not available on PyPI.
[00:16:52] Unknown:
So who is the target audience for Escapee? And what are some of the primary intended use cases for it? So the the first target was,
[00:17:01] Unknown:
people doing, network security audits. And the main goal was to ease their life, help them to discover the network, send packets, record packets, and so on. Another aspect was to help people writing network related exploits. So from time to time, you have like an exploit against Windows or Linux, and you need to write a lot of c code in order to send your packets in a specific way. Enscape helps you to write packets really easily and send your exploit, for example, if you need to in just 1 1 line of Python. That These 2 kind of people, they were the primary targets.
And nowadays, the target audience is more related to people willing to test or write new protocols. And for example, especially people wanting to do fast prototyping, people that do not want to work with C or, for example, implement a WorldShare code desector, they tend to use Scapy for fast prototyping. And finally, more and more people are using it to teach network protocols and the concepts because it tells students to have a simple access to packets. For example, you can teach how TraceWorks works by making students write packets themselves and also, having a look at, at the answers.
[00:18:15] Unknown:
So reading through the documentation, I was noticing that there's the ability to layer different types of packets in an arbitrary fashion. So I'm wondering, how is the project architected internally to allow for that level of flexibility and composability of the different network layers and network protocols?
[00:18:31] Unknown:
Okay. So first, we have the slash or divide operator that was really fine in order to be able to stack network layers on top of each other. And that's a single trick, but it also make, Scapy really special because it just can stack with a device IP and then UDP and then DNS. So in 1 line, you can, like, stack protocols. So that's first thing in the design. Also, we have quite a few default values that work. So by using Python keyword arguments, we can decide to specify or not specify, for example, the IP destination address or source address on the TTL field, and Scapy will take care of everything for you. For example, if you don't specify the IP checksum, Scapy will compute it for you. On the other hand, if you want to put 0 for the checksum, Skeppy will send an actual 0. If you try to do that with a regular library, most of the time, you you won't be able to send a check sum of value 0 because the system will say, okay. If it's 0, I will compute the check sum. So that's another Scapy feature. Going back to the packets, internally, Scapy is designed around fields. And a field, it has a name and a default value. And by combining fields, you can make a packet and landscape is able to, based on the types of the fields, is able to dissect the packet, so read it from the network, and also able to, build the packets into, raw bytes.
Finally, in Scapy, by design, it's able to, let's say, dynamically encode and decode packets. Yeah. So that's seems that's that's it. Given the level of
[00:20:12] Unknown:
flexibility that the library enables, what are some of the most interesting or unexpected ways that you've seen it used?
[00:20:20] Unknown:
That's a good question. So there's a lot of people, playing with Scapy to do tools and proof of concept. For example, people trying to use, Scapy to to detect, 8.2.11 access points because Skype can do that compared with Wi Fi. Last year, I discussed with, open BSD people because they are using Skype to test the IPv6 stack. So it was really nice to see that that Skype is using in open BSD to to test the stack. Also, I'm aware that some people managing, the root DNS servers are using Scapy to do some network test testing to build specific packets in order to step test the architecture.
And finally, this 1 is kind of funny. I don't know if you know, but, NSA, got some, code leaked last year from, people called Shadow Brokers. And you have 1 exploit in there called, extra bacon, and this 1 is using Scappy in order to send, SNMP packets to some Cisco router in order to exploit them. So this 1 is kind of funny even NSA is using Skippy.
[00:21:28] Unknown:
Well, it's it's a good validation of the work that you're doing on the project, if even if even NSA is using it for their particular use cases.
[00:21:36] Unknown:
No. It was kind of funny to find my name into the shadow brokers, leak.
[00:21:41] Unknown:
So given the wealth of protocols that are available at the network layer and the wide variety of them that are implemented and supported in Scapy. What have been the most problematic to implement and to maintain? And are there any protocols that you are not yet able to support?
[00:21:59] Unknown:
Yeah. The 1 with, thing with bits and not bytes, I think we'll we'll never be able to support them, if they are not byte aligned. For example, if we have, like, 3 bits and 4 bits and that's it, so it's not a byte. It's only 7 7 bits. That's it. We won't be able to to support this this kind of protocols because the way Skype is designed, unfortunately. I think in the past, 1 really difficult protocol to implement was SNMP because it's based on the ASN 1. And Philippe Lion did an amazing, really amazing job at implementing ASN 1 in Scapy. And this part of the call is kind of kind of tricky, but works fine.
And last year, when when guy, Maxence, another French guy, rewards the implementation of, X509 certificates, the 1 using HTTPS, using the native SN 1 KPI support. So this part of the code again is, let's say, more difficult to maintain because of the way the protocol is done. It's like a pure binary protocol. It's kind of difficult. On the other hand, you have, like, it's kept in as a part which is also more difficult than the other. That's IPSec and TLS. So we got IPSec support 2 years ago, I think, and TLS, last year. And this 1 are more difficult than the other because it deal with crypto. So we need to handle keys and so on. So way more difficult than Ethernet, for example.
So the most difficult ones. And finally, we have, like, ones that are difficult, not because the protocol is difficult, the fields are weird, but just because they are an old implementation in Skateboarding. For example, DNS, because it's really old, it's not the best way to write a DNS protocol in Scapy. But again, due to some backward compatibility, we decided to to keep it this way. And from that time, like, the DNS layer tend to break. But it's getting better.
[00:24:00] Unknown:
And what have been some of the most challenging aspects of developing and maintaining Scapy overall?
[00:24:06] Unknown:
So for me as a maker, the I think the most changing part is to keep the core working. So for me, it's really easy to write a new protocol in Skippy and to maintain it. But the core is, still from time to time buggy. And because we try to support a lot of, operating system so again, Linux, Windows, OpenBSD, NetBSD, FreeBSD, OS 10, Solaris. It's really could be difficult to adapt to some specific usage or specificities. So from time to time, we have bugs in the core, that are really difficult to to reproduce and to fix. So for me, as a matter, that's the most challenging part, like keeping the core working and, different, operating system. And things like Travis and Abeo, that passed a lot to make sure that what we make, the change we make, they don't break anything. So that's really, really nice.
Also, it was a bit silly, but we used to support Python 2.5, 2.6, 2.7, and PyPy. And that was a bit challenging because we couldn't use, like, let's say, modern, Python features. So essentially, we stopped last year. And as of today, we only support 2.7.
[00:25:21] Unknown:
Yeah. I'm sure that that will allow you to go through and clean up a lot of the old code and refactor a lot of things to make them easier to reason about and work on going forward.
[00:25:32] Unknown:
That's 1 aspect of what we don't want to do yet. That's still difficult because, we also want to keep git history. We don't want to break it. So for Fantasia, it's also difficult to, let's say, maintain historical comments or reason and move the code to, let's say, newer worlds.
[00:25:52] Unknown:
So what do you have planned for the future of Skippy?
[00:25:55] Unknown:
Let's say a lot of things. But if we have a look at 2016, which is not the future but recent past, we did a lot already. We have a better Windows support. That works fine. We have a native BSD support. So we have no dependency. You can just get clone scapy. It will work on the OS 10, for example. So it was nice. And due to this new feature, we have a decrease in the number of issues related to OS 10. People do not need to install Python dependencies anymore, related to libdnet and lpcap, which is nicer for us. Also, we got a really nice TLS and XRavanai support as well as HTTP 2. So that was for 2016.
And what's interesting to have that in mind, that's that's many Windows support, TLS, and HTTP 2. It was done by New Main. So because we switched to GitHub, a lot of people are coming to a project and pushing new pull requests. So I don't know what people will push into the 5th 17. But on our site, maintenance, what we want to do is to write a manual test in order to fix some, aspect of scaling. So we started in December with a little bit more than 50% of coverage. And as of today, I think the number is 77%. So it takes time, but, 1 step after another, we are able to make, Scapy better by writing this test and fixing the bugs. Also, we have some discussion to make the code, let's say, PEP 8 compliance.
Skeppy code, legacy code is kind of, unique in its colleague style. Some people say it's ugly and it should not exist. So we are thinking of moving the code to, let's say, a cleaner syntax. But for us, the main question is, who can do it, and is it possible to do it without breaking the story? Something we don't want to have is a single commit that will break the story. For example, if you use GitBlend, we won't be able to know who, wrote that piece of code in the in the first place. It's difficult to, let's say, link everything and preserving this story. So we don't know how to do that yet, but it's something we have in mind for a long time.
Especially because, even for us, the code from time time is not nice. Also, like, due to historical reason, the codes and some code and some function are never used or never tested. So, again, that's something we want to to change. And if I have time this year, I think I will invest my time in something called Scapy 3, which is a proof of concept by Philippe Biondi. This 1, you can find it on Bitbucket. It was designed as a pure rewrite of Scapy 2. And the goal was to say, okay, if we need to invest time in Python Swiss report, it's better to, write Scapy again. So Philippe did that. So I need to have a look at this quote and see what we can do, either like pushing it at a new project or pushing ideas from Scapy 3, the proof of concept into by Scapy 2.
Also, we'd like to to work on speed improvements to in order to try to make API a little bit faster. As of today, my main goal is to write, more unit testing to get some more code coverage.
[00:29:28] Unknown:
And are there any other topics that you think we should cover before we start to close out the show? No. I think I think we're okay. Scapy is definitely a very interesting project with a lot of capabilities. So I highly recommend that people download it, play with it, read through the documentation because there's a lot there that we weren't able to able to cover today. So for people who want to follow you and get in touch, I'll have you add your preferred context information to the show notes. And with that, I'll bring us to the picks. And my pick today is a music artist called Buckethead.
And he gets that name because he at least used to, and I believe still does perform wearing a mask and a Kentucky fried chicken bucket on his head. But he is a an incredible guitarist. He is he has a lot of really interesting, styles and has played with some other interesting musicians as well. So I definitely recommend checking him out. Most of his stuff is purely instrumental, but he occasionally has vocalists appear on his albums as well. So definitely recommend that. And do you have any picks for us today, Guillaume?
[00:30:34] Unknown:
Yeah. It will be a reach to development. So, yeah, Rust will be my pick today. So last week, I tried to play with, Rust as a new way to, implement SkippyCore. So so far, there is not much success, but it's always fun to play with a new language such as Rust, because it's, like, give you new ideas. Like, for example, it give me new ideas for, like, sharing stuff in, in Skippy. You are writing stuff differently. So my pick will be Rust. Yeah. Let's say, I will learn. Tell people it's always good to start with a new language because it's fun.
[00:31:13] Unknown:
Well, I really appreciate you taking the time out of your day to join me and tell us all more about the history and implementation of Scapy. It's definitely a project that I plan to experiment with some more and see if I can find any other use cases for it. So I hope you enjoy the rest of your day. Yeah. Thank you.
Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable. When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out linode at ww w.podcastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your app or experimenting with something that you hear about on the show. You can visit the site at www.podcastinit.com to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch. To help other people find the show, please leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media. You can also now get a t shirt and help support the show by going to teespring.com/podcastinit.
You can also pick up a mug and a sweatshirt while you're at it. Your host as usual is Tobias Macy. And today, I'm interviewing Guillaume Veladon about Scapy, the Swiss army knife for packet manipulation in Python. So, Guillaume, could you please introduce yourself?
[00:01:10] Unknown:
Yeah. So hello, everyone. So my name is Guillaume. I'm French, and I've been managing escapee since a few years, by now. During my, let's say, day life, I'm doing network security. And, me and my team, we use a lot, Scapy to, play around with the network and implement, new protocols.
[00:01:33] Unknown:
And do you remember how you first got introduced to Python?
[00:01:36] Unknown:
The first time was, I think, in 2003, during a conference, and someone was presenting the language. And I think my first, first thing I said about Capi Python, sorry, was to, that I didn't like the way, they were enforcing, the way you have to code. You see, the I didn't like at that time the fact that you don't have to put brackets, for example, and you need to indent your code. I did, like like, let's say, 15 years after that. That's what I like with Python, the way that the language is forcing you to indent your code and making your life easier, and also making your code, easier to read. And the first project I did with Python was indeed, like, playing around with Scapy. The first time was in 2004, I guess. And so it's a mix between Python and Scapy for me, at least. I started Python because of Scapy.
[00:02:26] Unknown:
And can you explain what Scapy is and the problem that it was trying to solve when it was created?
[00:02:32] Unknown:
So first of all, I'm just 1 of them Scapy met now. The other 1 being, Pierre Lale. And Skeppy was designed and implemented by Philippe Lionli, another French guy, in 2003. And the main goal of Skype is to ease, people live when it comes to playing with the network, which is sending packets to network, receiving them, and also implementing new protocols. So Scapy is really good at helping you and people to easily and quickly, implement a new protocol. For example, adding a new network protocol, adding a new packet header, it's just in in between 10 or 15 lines of Scapy, which is really, really nice and simple. And Scapy helps you to do that. It provides you, let's say, enhanced Python shell where you can send packet to network, read them, and interact with packets. And also, you can use KPI as a regular Python module in order to build your own tools and build your build your tools on top of KPI.
[00:03:34] Unknown:
And if you do have a custom packet format, is it possible to provide a definition for that so that as you receive those packets, it can, sort of unpack them as it as the packets are arrive into your program?
[00:03:48] Unknown:
Yeah. The the the way it goes indeed in Scapy, what you need to do is to define the, an object. Let's call it, like, for example, layer 1, and you will also describe in Python the fields in your layer 1 packet. And most of the times, Scapy will do the job for you of, like, reading the packet from binary into a Python object and then taking your Python object and converting it to binary. And that's just a matter of, like, defining a new class and defining, a list of fields.
[00:04:18] Unknown:
That would have been very handy in a project I was involved in a few years ago where we had a custom sensor and we had a custom packet definition where the different bit fields within the headers had different meanings. And so we needed to write some custom code to parse those out from the binary object and then figure out what those different fields were supposed to pertain to. So it seems that Scapy would have been able to solve that problem much more elegantly than the code that we ended up having to write. That, yeah. That's a typical use case. Like, hence, of course, generic. So you can reuse
[00:04:51] Unknown:
your packet definition, whatever you need. So the thing I really like about this project is just you are not stuck with 1, let's say, way of doing thing. If you decide to implement your packet in order to decode it, and later on, you can also decide to inject it in the network. And that's what I really like. Only 1 definition, 1 piece of code, and you can do both, sending and receiving. And when it comes to playing with, protocol, for example, for security audits, defining a new protocol for experiments, it's really, really powerful.
[00:05:21] Unknown:
How has the decision to build Scapy in Python benefited the project? And are there any edge cases where Python starts to fall down in terms of the implementation?
[00:05:31] Unknown:
I don't know why. Indeed, Philippe started, to use, Python for Skyping. I guess that's mainly because the language is really flexible. It was easier to achieve this kind of tool with Python rather than than c. But, for this project, Python is really good because of its dynamic features. It allows us to benefit for the dynamic creation of object, for example. Also, it's really simple with Python to have your own shell. So for us, Python is like, and Scapy on top of Python is like a domain specific language, and that's really nice because we can enhance Python language with the SAPI features. And another benefit for us is, there's a lot of targets, meaning that's operating system or architectures for Python.
And also, today, Python is everywhere. So it's really easy to to have a tool that works on Windows, OS 10, FreeBSD, OpenBSD, and so on. And that's, for me, I guess, the main benefit of Python. On the other end, Python and the way Skype is defined and developed is makes Scapy slow in some situation. For example, if you want to inject a lot of packets really fast or if you want to read a lot of packets from the network to sniff packets really, really fast too. And Scapy, because the way it's like building objects on the fly and dynamically is, let's say, slow. However, slow is, you can still be able to inject at the rate of, let's say, 200 megabits per second, and you can also achieve the same speed while sniffing the network. So that's really slow, but today we have, like, gigabits
[00:07:04] Unknown:
or 10 gigabits interface. So to that extent, the SCAPI is slow. And would something like Cython give you the opportunity to speed up the critical pieces to increase that overall throughput?
[00:07:16] Unknown:
Not to my knowledge. We tried, PyPI last year, for example, but, we didn't manage to make it faster by, switching the Pycelle interpreter. And recently, I tried a project from Facebook or Instagram. I forgot, but some stuff. There's not a big benefit of, of changing the Python interpreter.
[00:07:36] Unknown:
And given the fact that you're dealing with network protocols, so mostly at the bits and bytes layer, what are some of the challenges posed by Python 3? I noticed that it is not yet supported. So I'm sure that dealing with the shift to how bytes and bits are handled in the newer version is likely going to pose a bit of an issue for you.
[00:07:57] Unknown:
There's indeed some contributors trying to push, let's say, a compatibility layer into Scapy to achieve Python 2 and Python 3 compatibility. And that's kind of hard to do because the switch of the the way bytes, handle in Python 3 makes it difficult to make this compatible version. But hopefully, that's something they will manage to achieve in this year in 2017. So that means, like, we need to change a lot of codes to have this compatibility layer. So 1 of the perspective is to use the 6 Python modules in order to abstract Python 2 specific stuff or Python 3 specific stuff. And on this topic, 1 important fact to keep in mind is that we try to stay Python 2.5, 2.6, and 2.7 compatible until, late 2016, which means that we are not able to use, let's say, 2, 7, and 3, compatible features, such as list comprehension and so on. So we had to deal with the backward compatibility of, maintaining, Python 2.5 compatibility. And that's something we try to keep as long as possible as the use case here was, for example, you are doing a a network audit and a really old, and you find a really old Linux, computer's laptop, and only has a Python 2.5, and you want to escape it. So that's why we try to keep this compatibility for long in order for people to to be able to use KPI, let's say, everywhere. But because the language, let's say, Python 2.5 language is all, we decided to drop this, backward compatibility.
[00:09:32] Unknown:
And given that the project has been around for 10 years, I'm sure that that has also added some legacy weight to that backwards compatibility, as well as increasing the overall effort
[00:09:46] Unknown:
Yeah. But I I think we won't move to Python 3 only. So we we'll try to achieve some some way to run both Python 2 and Python 3 on Scapy or with Scapy. And, yeah, we have, like, some a lot of things we need to clean up. For example, we have a lot of map functions in Scapy. It's like, more than 100, and we need to rewrite them using, these comprehensions. And that takes a lot of time. Of course, 223, the tool, help us to do that. But for some time, we need to fix, let's say, weird syntax ourselves. So it takes time to just to clean up the Scapy code and make it, let's say, more recent. Like removing the old 2.5 or 2.6 only, parts of the code takes time to remove that.
[00:10:30] Unknown:
And how has the overall project evolved from the initial prototypes that were created by Felipe Endy through to its current incarnation as Scapy 2? I think a lot a lot changed.
[00:10:42] Unknown:
Like, last year, we tried to do some archaeology with Philippe, and we found the first, Scapy file, which was not called Scapy at that time. It was like a pyrates or pyrats. It was just a single file, and it was the first, let's say, PC.ovscape insight. And at that time, the tool only allows you to inject packets at layer 2. It was not able to read the packets, but still you could find, you can find the file the syntax which is quite similar. And so that was in November 2003 2002. Sorry. And then Philippe decided to start Skype in 2003. And at first, again, it was a single file, scapy.py.
That's something you can just download on a laptop, on your server, and start, using Scapy. It was really convenient, for example, for security audits, but the design was not perfect and the site was, like, getting bigger and bigger. And the last, release, which was a Scapy, of the Scapy 1 branch, it was in 2008, and Philippe decided to split this, scapy.pwad file into a Python module, and that was released in 2008. It was called Scapy 2. So design is a bit different, and it's more similar to what you can expect from a regular Python module with, directories and some modules and so. And then so it was a release of version 2 in 2008. And then the project, evolved, in between 2008 and 2000 11. And finally, Philippe didn't have time to, maintain the project, and not much did happen in between 2011 and 2, 040 2014.
Sorry. So Philippe asked us, like, it was me, Pierre, and Nicolas to take over the code and try to maintain it. So I tried to we tried to do that. And the first, let's say, new release happened in, 2014, with, Scapy, 2 dot 3 dot 0. It was mainly, at that time, fixing all bugs, merging, let's say, also all pull requests. It was, like, basic maintenance maintenance work. So the project evolved a lot since, it's, like, almost 15 years now. So a lot of, things changed. For example, Philippe decided to do his own unit test, and the tool is called UT Scapy. And the main goal was to achieve what we do today with the BiTEs, for example, to have unit test of the code inside Scapy. But at that time, we had to Philippe had to develop its own system. So also a big change compiled for
[00:13:13] Unknown:
to escapee 1. And I understand that in the process of that evolution, you were originally hosted on Bitbucket and then moved to GitHub. So I'm wondering what prompted that decision
[00:13:24] Unknown:
and how has that decision played out. So first, the move was, I think, the best decision someone in the project ever made. It was the other mate, Pierre, who decided to do that. And the first goal was to move from Mercurel to Git. It was not about GitHub at this time, but, we both use Git a lot in our project, who are credited our personal project. So we wanted to stop using a Mercurial for Scapy. So that's what we did. And then we also decided to move to, GitHub, and the goal was just to attract more people. There is indeed more people with GitHub accounts, people with, Bitbucket accounts. So at first, it was a the main idea was to move the project to GitHub to attract more issues, more contributors, and so on. And finally, what we got, we got also more maintenance, more people helping out with the project. And, we moved to GitHub in January 2016. And since then, the project is, let's say, more active than it has ever been done. There's a lot of issues, a lot of poll requests. Also, the really like the poll ecosystem on GitHub because of specific features like the merge or the squash, feature. And also, there's a lot of services that we are using like Travis for CI. So at first, we used Travis to check for Linux and, you need to run when you need test on Linux. Then we also added OS 10, and then we are also able to test KPI on Linux, OS 10, with a regular user, with roots, and so on. And later on in was in November, we added support for AppVeyo, which is a unit test on Windows. And finally, in December, we had support to Codecov, which is a website that displays your code coverage.
And I think that was a smart move to move to GitHub, mainly because of these services. Like, it's really simple to make your pull request trigger calls to these services and then launch launch tests. And indeed, Capi code, like, is getting better and better, the quality of the code, and the stability, mainly because of this, Travis and Adeo websites.
[00:15:26] Unknown:
And going back briefly to your mention of the multiple platform support, 1 thing that I meant to ask is whether you're aware of if Scapy is able to run on MicroPython for being able to be used in microcontrollers or embedded systems.
[00:15:41] Unknown:
No. I never tried. At some point, like, when, like, some weird requests, for example, to make it work on, which was the name, Jython, the Java, JVM based Python. But I think it's not working. And last week, we had a pull request to a project, I forgot, which is a Python app, interpret on, iOS. But this, like, the iOS based 1 or the Java 1, they are really specific because you miss a lot of, let's say, bits from the OS module, and Skype relies relies on that a lot. So I don't know if it will also will also be the case with a micro Python. I will suspect that it won't work. I mean, the packet passing parts, maybe. Packet building also, but injecting and receiving packets, I guess that's, they won't won't be able to to to work. For example, PyPy, last time I checked, 1 year ago, was not able to fully run Scapy. For example, you are not able to inject, packets with, the type, IP IP row. So indeed, Scapy is not fully working on, on PyPI. You you can't inject packet with PyPI, at least last time I checked 1 year ago. Because, a specific, like, call it Cisco, even though it's not it's not 1, was not available on PyPI.
[00:16:52] Unknown:
So who is the target audience for Escapee? And what are some of the primary intended use cases for it? So the the first target was,
[00:17:01] Unknown:
people doing, network security audits. And the main goal was to ease their life, help them to discover the network, send packets, record packets, and so on. Another aspect was to help people writing network related exploits. So from time to time, you have like an exploit against Windows or Linux, and you need to write a lot of c code in order to send your packets in a specific way. Enscape helps you to write packets really easily and send your exploit, for example, if you need to in just 1 1 line of Python. That These 2 kind of people, they were the primary targets.
And nowadays, the target audience is more related to people willing to test or write new protocols. And for example, especially people wanting to do fast prototyping, people that do not want to work with C or, for example, implement a WorldShare code desector, they tend to use Scapy for fast prototyping. And finally, more and more people are using it to teach network protocols and the concepts because it tells students to have a simple access to packets. For example, you can teach how TraceWorks works by making students write packets themselves and also, having a look at, at the answers.
[00:18:15] Unknown:
So reading through the documentation, I was noticing that there's the ability to layer different types of packets in an arbitrary fashion. So I'm wondering, how is the project architected internally to allow for that level of flexibility and composability of the different network layers and network protocols?
[00:18:31] Unknown:
Okay. So first, we have the slash or divide operator that was really fine in order to be able to stack network layers on top of each other. And that's a single trick, but it also make, Scapy really special because it just can stack with a device IP and then UDP and then DNS. So in 1 line, you can, like, stack protocols. So that's first thing in the design. Also, we have quite a few default values that work. So by using Python keyword arguments, we can decide to specify or not specify, for example, the IP destination address or source address on the TTL field, and Scapy will take care of everything for you. For example, if you don't specify the IP checksum, Scapy will compute it for you. On the other hand, if you want to put 0 for the checksum, Skeppy will send an actual 0. If you try to do that with a regular library, most of the time, you you won't be able to send a check sum of value 0 because the system will say, okay. If it's 0, I will compute the check sum. So that's another Scapy feature. Going back to the packets, internally, Scapy is designed around fields. And a field, it has a name and a default value. And by combining fields, you can make a packet and landscape is able to, based on the types of the fields, is able to dissect the packet, so read it from the network, and also able to, build the packets into, raw bytes.
Finally, in Scapy, by design, it's able to, let's say, dynamically encode and decode packets. Yeah. So that's seems that's that's it. Given the level of
[00:20:12] Unknown:
flexibility that the library enables, what are some of the most interesting or unexpected ways that you've seen it used?
[00:20:20] Unknown:
That's a good question. So there's a lot of people, playing with Scapy to do tools and proof of concept. For example, people trying to use, Scapy to to detect, 8.2.11 access points because Skype can do that compared with Wi Fi. Last year, I discussed with, open BSD people because they are using Skype to test the IPv6 stack. So it was really nice to see that that Skype is using in open BSD to to test the stack. Also, I'm aware that some people managing, the root DNS servers are using Scapy to do some network test testing to build specific packets in order to step test the architecture.
And finally, this 1 is kind of funny. I don't know if you know, but, NSA, got some, code leaked last year from, people called Shadow Brokers. And you have 1 exploit in there called, extra bacon, and this 1 is using Scappy in order to send, SNMP packets to some Cisco router in order to exploit them. So this 1 is kind of funny even NSA is using Skippy.
[00:21:28] Unknown:
Well, it's it's a good validation of the work that you're doing on the project, if even if even NSA is using it for their particular use cases.
[00:21:36] Unknown:
No. It was kind of funny to find my name into the shadow brokers, leak.
[00:21:41] Unknown:
So given the wealth of protocols that are available at the network layer and the wide variety of them that are implemented and supported in Scapy. What have been the most problematic to implement and to maintain? And are there any protocols that you are not yet able to support?
[00:21:59] Unknown:
Yeah. The 1 with, thing with bits and not bytes, I think we'll we'll never be able to support them, if they are not byte aligned. For example, if we have, like, 3 bits and 4 bits and that's it, so it's not a byte. It's only 7 7 bits. That's it. We won't be able to to support this this kind of protocols because the way Skype is designed, unfortunately. I think in the past, 1 really difficult protocol to implement was SNMP because it's based on the ASN 1. And Philippe Lion did an amazing, really amazing job at implementing ASN 1 in Scapy. And this part of the call is kind of kind of tricky, but works fine.
And last year, when when guy, Maxence, another French guy, rewards the implementation of, X509 certificates, the 1 using HTTPS, using the native SN 1 KPI support. So this part of the code again is, let's say, more difficult to maintain because of the way the protocol is done. It's like a pure binary protocol. It's kind of difficult. On the other hand, you have, like, it's kept in as a part which is also more difficult than the other. That's IPSec and TLS. So we got IPSec support 2 years ago, I think, and TLS, last year. And this 1 are more difficult than the other because it deal with crypto. So we need to handle keys and so on. So way more difficult than Ethernet, for example.
So the most difficult ones. And finally, we have, like, ones that are difficult, not because the protocol is difficult, the fields are weird, but just because they are an old implementation in Skateboarding. For example, DNS, because it's really old, it's not the best way to write a DNS protocol in Scapy. But again, due to some backward compatibility, we decided to to keep it this way. And from that time, like, the DNS layer tend to break. But it's getting better.
[00:24:00] Unknown:
And what have been some of the most challenging aspects of developing and maintaining Scapy overall?
[00:24:06] Unknown:
So for me as a maker, the I think the most changing part is to keep the core working. So for me, it's really easy to write a new protocol in Skippy and to maintain it. But the core is, still from time to time buggy. And because we try to support a lot of, operating system so again, Linux, Windows, OpenBSD, NetBSD, FreeBSD, OS 10, Solaris. It's really could be difficult to adapt to some specific usage or specificities. So from time to time, we have bugs in the core, that are really difficult to to reproduce and to fix. So for me, as a matter, that's the most challenging part, like keeping the core working and, different, operating system. And things like Travis and Abeo, that passed a lot to make sure that what we make, the change we make, they don't break anything. So that's really, really nice.
Also, it was a bit silly, but we used to support Python 2.5, 2.6, 2.7, and PyPy. And that was a bit challenging because we couldn't use, like, let's say, modern, Python features. So essentially, we stopped last year. And as of today, we only support 2.7.
[00:25:21] Unknown:
Yeah. I'm sure that that will allow you to go through and clean up a lot of the old code and refactor a lot of things to make them easier to reason about and work on going forward.
[00:25:32] Unknown:
That's 1 aspect of what we don't want to do yet. That's still difficult because, we also want to keep git history. We don't want to break it. So for Fantasia, it's also difficult to, let's say, maintain historical comments or reason and move the code to, let's say, newer worlds.
[00:25:52] Unknown:
So what do you have planned for the future of Skippy?
[00:25:55] Unknown:
Let's say a lot of things. But if we have a look at 2016, which is not the future but recent past, we did a lot already. We have a better Windows support. That works fine. We have a native BSD support. So we have no dependency. You can just get clone scapy. It will work on the OS 10, for example. So it was nice. And due to this new feature, we have a decrease in the number of issues related to OS 10. People do not need to install Python dependencies anymore, related to libdnet and lpcap, which is nicer for us. Also, we got a really nice TLS and XRavanai support as well as HTTP 2. So that was for 2016.
And what's interesting to have that in mind, that's that's many Windows support, TLS, and HTTP 2. It was done by New Main. So because we switched to GitHub, a lot of people are coming to a project and pushing new pull requests. So I don't know what people will push into the 5th 17. But on our site, maintenance, what we want to do is to write a manual test in order to fix some, aspect of scaling. So we started in December with a little bit more than 50% of coverage. And as of today, I think the number is 77%. So it takes time, but, 1 step after another, we are able to make, Scapy better by writing this test and fixing the bugs. Also, we have some discussion to make the code, let's say, PEP 8 compliance.
Skeppy code, legacy code is kind of, unique in its colleague style. Some people say it's ugly and it should not exist. So we are thinking of moving the code to, let's say, a cleaner syntax. But for us, the main question is, who can do it, and is it possible to do it without breaking the story? Something we don't want to have is a single commit that will break the story. For example, if you use GitBlend, we won't be able to know who, wrote that piece of code in the in the first place. It's difficult to, let's say, link everything and preserving this story. So we don't know how to do that yet, but it's something we have in mind for a long time.
Especially because, even for us, the code from time time is not nice. Also, like, due to historical reason, the codes and some code and some function are never used or never tested. So, again, that's something we want to to change. And if I have time this year, I think I will invest my time in something called Scapy 3, which is a proof of concept by Philippe Biondi. This 1, you can find it on Bitbucket. It was designed as a pure rewrite of Scapy 2. And the goal was to say, okay, if we need to invest time in Python Swiss report, it's better to, write Scapy again. So Philippe did that. So I need to have a look at this quote and see what we can do, either like pushing it at a new project or pushing ideas from Scapy 3, the proof of concept into by Scapy 2.
Also, we'd like to to work on speed improvements to in order to try to make API a little bit faster. As of today, my main goal is to write, more unit testing to get some more code coverage.
[00:29:28] Unknown:
And are there any other topics that you think we should cover before we start to close out the show? No. I think I think we're okay. Scapy is definitely a very interesting project with a lot of capabilities. So I highly recommend that people download it, play with it, read through the documentation because there's a lot there that we weren't able to able to cover today. So for people who want to follow you and get in touch, I'll have you add your preferred context information to the show notes. And with that, I'll bring us to the picks. And my pick today is a music artist called Buckethead.
And he gets that name because he at least used to, and I believe still does perform wearing a mask and a Kentucky fried chicken bucket on his head. But he is a an incredible guitarist. He is he has a lot of really interesting, styles and has played with some other interesting musicians as well. So I definitely recommend checking him out. Most of his stuff is purely instrumental, but he occasionally has vocalists appear on his albums as well. So definitely recommend that. And do you have any picks for us today, Guillaume?
[00:30:34] Unknown:
Yeah. It will be a reach to development. So, yeah, Rust will be my pick today. So last week, I tried to play with, Rust as a new way to, implement SkippyCore. So so far, there is not much success, but it's always fun to play with a new language such as Rust, because it's, like, give you new ideas. Like, for example, it give me new ideas for, like, sharing stuff in, in Skippy. You are writing stuff differently. So my pick will be Rust. Yeah. Let's say, I will learn. Tell people it's always good to start with a new language because it's fun.
[00:31:13] Unknown:
Well, I really appreciate you taking the time out of your day to join me and tell us all more about the history and implementation of Scapy. It's definitely a project that I plan to experiment with some more and see if I can find any other use cases for it. So I hope you enjoy the rest of your day. Yeah. Thank you.
Introduction and Guest Introduction
Guillaume Veladon's Background and Introduction to Python
Overview of Scapy
Benefits and Challenges of Using Python for Scapy
Evolution of Scapy
Transition to GitHub and Community Contributions
Platform Support and Compatibility
Target Audience and Use Cases
Internal Architecture and Flexibility
Interesting and Unexpected Uses of Scapy
Challenges in Implementing and Maintaining Protocols
Overall Challenges in Developing Scapy
Future Plans for Scapy
Closing Remarks and Picks
