 He has published articles in several big German magazines, computer magazines, and he's an expert in packet capture and analysis. Jesper will be talking today about the various issues that can arise when sanitizing and anonymizing packet captures and how to deal with them. So please help me welcome Jesper to this talk on sanitizing packet captures, fun and games until someone uses IP version 6 or TCP. Welcome. Thank you. So welcome. I didn't expect so many people in this room because they have not news shows coming up soon. So if you're leaving in the middle of the talk, I'm not going to be disappointed. So just go ahead. Yeah, I'm Jesper. If you want to follow my stuff on Twitter, this is my handle. Okay. This talk is about sanitizing P caps. So packet captures. I do a lot of work reading packet captures. So you probably heard of the tool called Wireshark. I use it every day. And very often I have something that I want to show other people, but there's something in there that I can't let them know like IP addresses and other stuff that may be sensitive. So I need to sanitize them, remove all the critical information so that nobody can see what my IP addresses are, what my MAC addresses are because from the MAC addresses of you, which you probably know, you can deduct the vendor of the device quite often, not always, but in a lot of cases. So it may be important to do that before sharing stuff. Okay. So the first slide that I'm going to show you is going to surprise you because it has nothing to do with P caps. Once upon a time, I did something other than that. I worked on computer games like this one. I didn't write it, but I did the German translation. And also that one. It's like 20 years ago. I came to remembering those times when writing the talk because back then, I had to do something that I hated when sanitizing P caps as well. And that is using an hex editor to edit stuff because it's very complicated to get things right. Back then, in those times, when LucasArts and Westwood published those games, we didn't get any source code because you can imagine LucasArts back then was already very... Well, they're not giving things to you in a way where they think you could do something with it, like compile their game again or something. So they only got us the binaries. So I had to patch the German translation into the English game. Most of you know that most sentences in German, if they are going to be nice, are much longer than the English ones. So we're sitting there in the room translating the game and over thinking like, oh, damn, how am I going to translate this? It's going to be not longer than the English phrase and still sound cool. And that is a big problem. So it costs a lot of nerve to do that. I can show you how that looked like because I got the eye of the beholder binary here. You can see here there are all the strings in there, in the executable, unobfuscated, which was quite... In these times, it's quite surprising. Nobody uses plaintext strings anymore, right? Back then there were. And so we were editing in this all the time, translating the game. And that is something that I never want to do again, but sometimes with pcaps, I had to do it again. And this is what the talk is about, how to get a solution to that kind of problem. These days now, if you're doing computer game translation, of course, you get the resource files with all the translation strings and them and everything. So it's much easier, but back then that was really hard work. So for those of you who don't know what a pcap is, a pcap is a packet capture, meaning it's network packets that have been captured using a capture device. It can be a PC or something special. And it's a file format. It's a binary lock, and that is something quite a number of people doesn't always recognize or understand because a lot of times we get questions about how to read it with a text editor. It doesn't really work. You need to have something to read it, and most people for this kind of thing use Wireshark. A pcap is an old format. It's used a lot still because it's easy to write and easy to read. The much better one is pcap ng. I don't know if you've heard about it, but I can recommend it because you can do much more things with it like putting comments into packets and stuff like that. But still a lot of tools only can do pcap, so we have to still work with it. TCP dump writes it, Wireshark writes it. Well, dumpcap is the tool that writes it, but Wireshark tells dumpcap to write the stuff and snort and everything else. So why sanitization? Yeah, first of all, it's quite similar for editing packets to be able to replay them, which is sometimes necessary to mess with them and play them back to the network and see how a device reacts to it. But it's a little bit different because your focus is not on changing the packets to test something, but to remove sensitive details, like user credentials or network topology. You don't want somebody to know what their IP addresses are in your network and what the gateways are and what the MAC addresses are, stuff like this. Device and software version information, because as we all know, if you find a banner from a device that tells you this is Cisco router, something whatever, everybody will Google, is there an exploit for this? And if there's one, you try to attack it, so it may be interesting to remove those. Vulnerable protocol, of course. If you have telnet in your network, I would consider that a vulnerable protocol. But of course, payloads. So if you have something that is sensitive in itself and it's transported over the network, maybe you want to remove it because you don't need it for the analysis or something that you're doing later and then you can strip it. Okay, very often people do something like this. This is actually a screenshot that I have taken from one of the Wireshark Q&A sites. People post these kinds of screenshots of Wireshark and try to remove the sensitive stuff by painting over it. Sometimes it's really funny because you still have the hex decode down here and then you can, if you can read hex, still see everything. So that's also a danger that you have when doing something like this. You may miss something that you need to sanitize, but you didn't, well, see that this is also the same information. Most people never look at the hex in Wireshark, so they don't realize that everything that is in the decode area is also in the hex area. That isn't, so that's okay. And if I'm going to analyze something, somebody shows me a screenshot like this. Very often my answer will be, first of all, nice, but I can't help you with it. Get me a P-CAP. If you can't get me the P-CAP because there's the IP addresses that you don't want me to see, sanitize them. Replace them with something else. Okay, and this is what we're going to talk about. So there's two main groups of people that want to sanitize packet captures. That's, first of all, the network analysts, and a lot of them are, for example, guys working in a company. I had one occurrence where a firewall administrator told this boss, okay, this firewall company wants me to send them captures from what our firewall does so they can debug why it's not doing what it should do. And the boss said, well, we can't do that because there's sensitive information in this network. And they're at a kind of a deadlock, like the database, the firewall vendor says, I can't help you without the P-CAPs. And the customer says, well, I can send you the P-CAPs. So what do we do? Well, you could sanitize them and remove everything that you think is critical. And then hopefully not remove too much because if you remove too much, the firewall vendor will say, well, with this, I can't see what the problem is. So you're always trying to find the right balance between removing stuff so that nobody sees your IP addresses and whatever, but not so much that it is unusable. And sometimes I see people removing so much stuff that it's basically unusable. So you need to find the right amount of sanitization. As a network analyst, you need packets up to the TCP layer because if things go wrong in a network these days, it's most of the time related to how TCP works and what it does. I can see timing issues, retransmissions, packet loss, whatever. And I don't need the payload for it. So removing all of this payload after the TCP header is no big deal. Because a lot of networks have these obscure middle boxes. I don't know if you have seen any of those. These can be things like packet shapers, firewalls, varnexer, raters, all these magic boxes that do funny things with TCP but don't get them quite right all the time. So in that case, you can lose everything above TCP. All the payloads doesn't care. Don't matter. And sometimes you still need stuff like FQDNs, so DNS names, things like this, or URLs, and then things get complicated because then you're on top of TCP, so you're in the stuff that is transported over UDP or TCP, and replacing those can be a big nightmare and I will talk more about why it can be a nightmare. Security analysts or researchers, they usually have other stuff they care about because they don't care about Ethernet, ARP, IPv4, TCP, UDP. Not that much at least. And if you see an ARP-based attack, well, okay, then sanitize the MAC addresses and you can still see the attack going, but from different MAC addresses, it doesn't matter. As you can also see here, I intentionally wrote IPv4 because nobody cares about IPv4 anymore because it's quite stable by now. That doesn't really work for IPv6 because IPv6 is still in a stage where it does crazy things sometimes and it may be interesting to see attacks that are based on IPv6, like extension header chains that you built. I don't know how many of you are using IPv6 already. Quite a few, okay. Not that many, it's say 10% maybe. There's a lot of things in IPv6 that is still problematic, so sometimes you need to see those. And of course, as malware analysts or security analysts, you often need stuff like the FQDNs, URLs, binary payloads, so you can't just remove them. So sometimes the kind of sanitization that you do is different if you're looking at it from a network analysis point of view or from a security researcher point of view. Okay, the challenge, as I already said, is don't remove too much to make it unusable, but remove as much as you need to not give away anything that you want to keep a secret. So you need to find the right amount of, well, replacement or removal, whatever. The second problem that we have is if there's only one packet that you need to change, that's quite simple. You can still do it in a hex editor if you have to because, yeah, it's a lot of work, but it's just one packet. I put out a challenge like half a year ago or a couple of months ago at the Wireshark conference. The packets were in the range of, I don't know, a couple of million, and it was like a two gigabyte file. Editing those, because they were taking it to customer side, it was a real-world problem that I wanted to show as an exercise. So I had to sanitize 600,000 or more packets, and doing that with a hex editor, well, I would be editing to the end of my days, probably, so trying to replace everything that I needed. So for that, you need something else. You can't just do it with an hex editor or something that works well for just one packet. And I will show you a couple of editors that you can use for one packet, but not so much for many. The protocol complexity is another challenge. Most of you have not yet worked or played with IPv6 that much, but IPv6 has a lot of dependencies that can really make things very difficult. I'm going to show you an example of how difficult it can get, and you maybe see, even if you don't know much about IPv6, that there's a lot of things that you need to look at to be able to replace stuff that doesn't fall apart after sanitization, basically. You have protocol dependencies. Again, IPv6 or sometimes ARP and stuff like this depend on each other. So if you replace something in another protocol, you need to keep that replacement consistent in the next protocol. Again, something I will show in IPv6. And then there's something that a German university coined as a term, I think. It's called defensive transformation. Who's ever heard that, defensive transformation? It basically means if you're looking at a network packet and you find some kind of information that you don't know what it is for, drop it, because you cannot keep it. If you keep it, it may expose something sensitive. So defensive transformation means when I look at the network packet, I try to understand everything in the packet and everything that I don't understand, I will not write into the sanitized packet. So I will lose information. But it's better to lose information than to expose stuff that you don't want to be exposed, because very often in the end, you will find out, oh, I still exposed the IP address because it was still in the hex dump or something like this. So defensive transformation is a principle that you should keep in place to avoid mistakes exposing stuff. Thank you. Okay, hex editors. I showed you a hex editor already, so replacing packet content in a hex editor is quite a challenge. Even if you are able to... Well, I have Bill Murray here because it's sort of like a Groundhog Stay task if you do that on a lot of packets. It looks like this. You go on some packets like maybe this one. I use 101 editor for this. So, well, you can go in here and start replacing stuff. But you need to calculate IP addresses into hex values all the time. It doesn't make any kind of sense, not for many IP addresses. You can use search and replace, of course, but very often you will miss stuff. And I want to show you something where you can easily miss stuff, and that is in, for example, the HTTP packet that I have here. If you're replacing by bytes, for example, in the sketch request, you will see here IP addresses up here. They are 32-bit numbers, but the IP address of the X-Forward 4 here, that is ASCII text. So that is something completely different, but it's the same IP address. But one is 32-bits, the other one is much longer, obviously. We can also see that in the decode down here. The IP addresses are somewhere in here, and down here you will see the IP address as text. So you need to replace text and 32-bit numbers, and they need to be the same IP address. So you have to transform them all the time. This is really no fun at all, because it will also change the packet length if you do something like this. And if you change packet length, something really funny will happen. And I can show you that because I already did. You look at this trace there, it looks fine. You have a SYN at the beginning, a FIN-AC at the end, no retransmissions, no packet loss, no warnings from Wireshark Nothing. And I did a replacement of the IP address in the X4.4. And now the trace looks like this. You have a lot of red lines there. They're really small, I will make them bigger for you. It tells me previous segment, not captured, unknown segment. So this is something where a network analyst will get kind of, er, something is wrong here. I have lost packets, there's something missing here. No, there isn't. The only problem, and you can see that up to this packet everything is fine. The problem is that I replaced the IP address in here, which was 192.168 something longer than this, actually seven characters longer, with something shorter. And that means that every sequence number in TCP following this packet will be seven bytes too long. So Wireshark will all be like, I'm missing seven bytes here. There are seven bytes missing. There must be packet loss. And it goes through all the packets because every sequence number after the packet that is shorter or even longer will be off by the amount of bytes that you replaced. So you need to then go into every packet and adjust every sequence number, but only after you did the replacement, not before. So you need to keep like a lookup table, like in which conversation did I please replace in what sequence number, how many bytes, and how much do I need to adjust this. And you can do multiple replacements in one conversation. So you have multiple points of now I need to add seven, now I need to remove 14, now I need to add 25. It's really a nightmare. So this is why TCP very often can be hard to sanitize correctly if you're going into replacing stuff in the payload. This only happens if you're in the TCP payload. It doesn't happen if you change anything in the TCP header. Okay? All right, so this is how you do the menu replacement. There's also something in Wireshark that I don't think many people have seen. Who has used Wireshark before? Oh, most of you. Okay, good. You can do this. You can go into Wireshark. This one is, I hope the correct version. This is 2.1, well it's quite new. I use the legacy version. Legacy means it's GTK based. That's the old one. And in here you can go into Edit, Preferences. And down here there's a checkbox for Enable Packet Editor. And with that you can now go to any packet and say Edit Packet. And now I can go in here and for example change time to live and say, well now it's 63. Okay. And instantly, of course, the checksum is wrong because I changed something, right? So if you're doing replacements in a packet you always need to fix the checksum. Really always? Well sometimes you have packets where the checksum is already bad in the original. So what do we do? Do we fix it in the fixed version? Hopefully not because you kind of remove the symptom that the checksum was wrong from the packet. So you need to keep it bad if it was bad but keep it correct or recalculated if it was correct. So something else that you need to keep in mind like, oh was the checksum okay? Well replace it. Stuff like this. Well this is something you can do with Wireshark but only in the GTK version, not the new QT version. Okay. Then the other thing we have is wire edit. Wire edit is a relatively new tool. You can use it to, well what's my desktop? Oh it can only work with pcap and cap files. It doesn't know pcap and g. So I need to save this as pcap first. I should have kept an example in pcap format but I didn't. Test.pcap. This is just a FICON version. Don't worry there it is. And now you can go in here and say, well I want to edit the packet. Well it's kind of confusing because you think you need to edit something here but down here there's everything in that packet. And now you can say, well I want to change the host and want to write in here www.packetfood.com. Let's say I want to change it to www.lock.packetfood.com. Okay. And the good thing about wire edit is it will automatically fix the checksum. So you don't have to worry about it. You can also add stuff, remove stuff and you will run into the same problem as the sequence number. Okay so that is wire edit. And again if you do the manual stuff you need to have Bill Murray on your side and stay in the time loop because it will take a lot of time to do this. Okay if you do batch editing which means you're looking at replacing stuff in an automated way to a lot of packets, to many packets. There's a couple of things that you need to keep in mind like if you replace an IP address with another IP address you need to keep replacing the same original with the same replacement. You cannot just replace it with anything you want. It needs to be consistent. And there's a couple of problems with that because if you have a lot of IP addresses you need sort of a database to store stuff or you do a hash kind of thing so that you hash the original and use the hash as an output for the new IP address but very often that gives you funny IP addresses. So you can end up with 127.001 as the replacement when the original was 10.something else. You're like really someone's sending stuff from local host? I don't think so. And then you look at the original like oh no. Okay so these are all problems that you can run into. Bit twisty TCP rewrite are basically command line tools that are used to prepare packets for reinjection into the network so they're basically designed to help you modify packets for replace stuff. So they're not sanitizing tools by trade but you can use them of course also kind of sanitization. Then there's packet anonym, these are the guys with the defensive transformation. Then there's a new project. Basically packet anonym is a Linux tool that is using XML files to do automatic conversions on packets. It's also quite nice because you can pipe stuff from TCP dump directly into packet anonym that will write never the original to disk but only the sanitized stuff which is kind of nice. And you can define how strong the replacement should be if you want to replace the MAC addresses, the IP addresses and everything else. There's pcaplib which from my point of view is not such a good name because I don't know if you know this. Libpcap is the library that reads and writes pcap files and these guys are from China that probably didn't realize. They wrote a paper on packet anonymization and used that kind of name. So if you want to take a look at it they basically used the Wireshark sources to read and write packets in an automatic kind of way. So they have a nice project that hasn't continued since 2012 I think. So most packets sanitization things that you can find on the network are research papers and as soon as people have turned in their research papers the development stops of course. So it's out there, it's open source, go and use it and modify it but it doesn't seem that many people do. Okay and then there's the last one which is called Tres Rengler and that is my tool. So I'm going to show it to you. It's a bit different because it doesn't run on Linux except you use wine because it's written in Delphi which is not a great language. Only Russians use it I'm told. So Tres Rengler is for automated replacement of stuff and I'm going to show you a little demo. What you can do here is, or is it up here? So you add a pcap file or let's say, this is just one, and then you add a anonymization task and then you can tell it, well what do you want replaced? And one of the most important ones is this one telling it to remove everything that you don't recognize. So if Tres Rengler doesn't know how a protocol works please remove it completely. That way everything usually after TCP will be dropped because I cannot parse that many protocols yet that are above UDP or TCP but I'm working on it. So I'm not a research paper guy, I'm continuing my work so it will improve. You can also tell it to truncate after a certain layer or after a certain offset or replace some strings in here but the more important things usually are replacing IP addresses. So you can replace by a list telling it like, well 192.168.0.1 replace it by 10.001 and it will do that. For every IP that it finds no matter where it is if it's in an app packet or an IP packet or in a payload it doesn't matter it finds it it will replace it. Or you can go in and say well replace subnets. Replace everything that is in 192.168.00 slash 24 by 10.000 slash 24. Which is good because then all IP addresses from the original net will end up in a new net and not in completely different networks because very often if you randomize stuff everything will end up in different crazy networks and you're like why are these two IP addresses talking to each other? The one is in USA, the other one is in Germany. What are they doing with one hop between them or something? So that doesn't make any sense. It will do a lot of this also automatically if you randomize IP addresses it will keep multicast addresses multicast because that's another problem. If you have a multicast address and you're randomizing it it could end up like a lupic address or a zero address or a private address which is not the same anymore. It's completely different then. Apipa, I don't know if many have heard the term that is the automatic private IP addressing thingy. If you do DHCP but you don't get one 169.254 something everybody has seen us and cursed them. If you have something like this in a trace it's quite interesting because that means DHCP didn't work so for analysts you don't want to replace them and on the other hand they're like randomly generated anyway so they don't post any kind of threat if you expose them. It doesn't make any sense to replace them normally but if you want to you can tell it to. And then documentation IP addresses are a special IP address range that is specifically for documentation so replacing those doesn't make any sense again. There's one for IPv4 or 2 not only IPv6 but few people know this. Okay and then there's something here that is called the private range mode which means I told Tracefrodinger to if you find an IP address that is 192 something or 10.something or 172.something it's already private. Please keep it private because I want to see in the end that it was private and don't change it into a public IP by mistake because then again I have something that it wasn't before. You can also go in and say well randomize it over the full address range or do not randomize it at all and keep all the private IP addresses private because it doesn't matter. Okay similar things you can do for IPv6 for ICMP you can decide which kind of packets you want to remove if you choose to. Then there's ICMPv6 and that is quite interesting and I'll show you Trace why IPv6 is such a big problem. 15, okay this is the last demo I think. If you take a look at this packet which is IPv6 so if you haven't seen IPv6 before now you do this packet is kind of problematic because if you know a bit about IPv6 the destination IP address here ff02 colon colon 1 and so on is a very special multicast address that is created for a search kind of I want to know where my neighbor is which used to be ARP before. ARP doesn't exist anymore in IPv6 for those of you who don't know so use ICMPv6 for this. This IP address is based on that IP address you can tell by looking at the last couple of bytes here you see they are the same so this one and that one if you replace any of them you need to keep the two of them consistent but they're different classes so that is a problem and the other thing which is even worse and by spotting the fffe in here every IPv6 administrator will tell you this this IP address was created from the MAC address so look at the MAC address up there and you will see it again that this here 026EA5 somewhere up there from there the destination is kind of replaced here it's like this so you need to look at the IP address the multicast address and the MAC address and if you replace any of them replace all of them so you need to change the MAC address then the IP address and the other IP address and that is something that Resslinger can do but nobody else so far I've seen which is it was something where I thought this is easy but it was a weekend of coding so it took a lot more time than I thought okay and Treslinger can even do work on crazy stuff like this I don't know if you've ever seen a packet like this yay Ethernet, MPLS, MPLS, Ethernet, IP UDP, GTPU which is a tunneling protocol IP again, TCP and if you want to sanitize this good luck because it's a lot of stuff but I can read all of them in Treslinger and do the sanitization for you and it should work if it doesn't send me an email I fix it okay so Treslinger can be downloaded and that's the last thing I'll show before going to questions if there are any it's downloadable here if you want to I didn't open source it yet but I will I'm still looking at the licenses I already asked you about it which one I'm going to use well I'm going to use probably GPL or something then you can look at the Tres at the Treslinger code also and well all of this already did talking and thanks and questions anyone with questions there are four microphones in the room you can go to the microphones now if not send me an email later that works too or Twitter or whatever yeah there we go right here you thought about the problem with the HTTP analyzing HTTP could you get a little closer to the microphone? sure the problem with anonymizing HTTP we have the IP also in layer 4 or 5, 6 that's not something you can address with packet wrangler not right now I wrote a well basically what Treslinger does it it reads the packet from internet up to the highest level it can pass right now that stops at TCP but I'm working on an HTTP already and then it replaces everything that it finds and reconstructs the packets from top to bottom so basically pulls it apart replace everything puts it back together that's the only way that you can do this and I've started working on the HTTP and I tried to get it done for ccc but I didn't because I didn't have enough time it will be the next thing that I do and then you can do it in Treslinger it's a lot of work because there is the reassembly coming into play most of you know probably what TCP or assembly means that means that you have to recombine all the payloads first because an HTTP request can span across multiple packets there are sometimes very long URLs that go from one packet over 4 or 5 more and you need to reconstruct it first and then replace stuff and things can get longer or shorter then you need to cut it into pieces again but they need to be the same size or they should be so you need to remember where the cuts were and what happens if you have packet loss and something is missing in the middle and it's like uh oh there must be a retransmission somewhere but where is it so you need to here get it here put it in there reconstruct it put it back there when you write the file again so I cannot even read and write stuff sequentially I need to read it try to put it together and then remember where everything was before I read it and write it out like in the same order that I read it so that's why it's a nightmare to work on TCP stuff it's really not easy um well far future maybe but I will do this for one packet stuff already so most HTTP requests are in a single packet unless they're very long and that will be something that I will do in the next couple of weeks probably do we have any questions from the internet um yes there was one question do you also anonymize domain names um right now no I don't but I'm really close to this because I can already read DNS but DNS is another big problem I have one slide on this if you're replacing FQDNs and you have something like testpacketfood.com and you replace it with somethingsecret.com that means that you replace packet food with secret comwithcom and test with something and if you then have abcdefpacketfood.com you need to remember that you replace this with secret this here needs to be replaced with something else so again you need to remember parts of the FQDN you need to pull it apart put it back together it takes a long time to get that right and I haven't gotten there yet but it's one of the next things I have to do because for the HTTP thing to work I need to be able to sanitize the hostname in the get request so that means first I need to be able to sanitize FQDNs that's the first step that I have to do and then I can do the rest with that I'm not there yet too much work at Airbus thanks thank you on the left side right here is there a command line interface not right now the problem with that is that if you look at the replacement parameters in trace wrangler and you see it's a big dialogue here to add all these options as a command line version would make it very long or you need some sort of a parameter file that you give into the program I put a lot of code into the GUI version to be able to make sure that the user doesn't do anything crazy that will mess with my program and that's why I don't have a command line version yet because then I need to sanitize the input first and that is a nightmare in its own as everybody knows right so sanitizing inputs even less fun than writing a GUI which is no fun at all next question with Wireshark you usually try to find a problem as you said networking or whatever and with Wireshark we did a lot of work to actually get it bulletproof to actually do the IP addressing and whatever correctly dissected how often does it happen to you that you actually introduce new problems into the captra file and how easy or how hard it is to actually detect this so if I get you right you mean when I read a pcap and write it again and do something wrong when writing it how often do I put problems in there I mean you're actually trying to troubleshoot something and you try to sanitize the pcap and then you send it to someone and then he try to analyze it okay and then you find something that I introduced by sanitizing it exactly okay yes that is a problem and there's something that I live in constant fear about because if I insert problems into a captra file that hasn't been there before I may lose reputation quite fast because basically I'm more of a problem than helping you so I try to make sure that this doesn't happen the last thing I usually do is when I'm able to read and write packets files I don't sanitize them at all I just read them, deconstruct them and write them back out again if that works and if I get an identical copy I'm relatively sure that I'm okay-ish and then I need to do the replacement and then there's a lot of checking if this is correct the good thing is I'm doing packet analysis for over 10 years now so I'm one of the most feared guys when it comes to Wireshark because I very often am in contact with the core developers and giving them hell about how Wireshark is doing things wrong I can spot stuff going wrong by looking at packets and the first thing I always ask myself is Wireshark wrong or am I wrong and very often it's 50-50 I'm going to ask the internet is there another question coming from the internet no question from the internet okay then we have one right over here thank you yeah it's been I think a decade since I looked at it but do you know about Argos yeah and Ranonymize that stuff I haven't really used it I have to admit the thing is that Argos is I think I've seen it to be web based from the front end kind of thing I have to try to take a look at it but I haven't used it yet okay I think it's mainly command line based but it uses its own capture format and does a lot of analysis itself the problem is that would be if you can you convert it to pcap yes okay then it is okay because what I don't like is somebody is writing an arbitrary protocol nobody else can read and then you want to give it away for somebody who only can read pcap so if you can do that well I have to take a look at it I wanted to write a tool that is fully under my control that I can tell to do everything I like and do not do stuff that I don't like so maybe I'm doing stuff that Argos already can do I have to take a look at it but thank you okay if there are no more questions then as Jasper said you can email him but for now please help me to thank Jasper thank you for the talk today