I have my doubts that there is an editcap solution for this, but I thought I would pose this question to this audience of packet people: I need a way to replace or remove the contents of a protocol container. The container can be presented one or more times in a packet, where in all cases the content would need to be replaced or removed. IP checksum recalculation would be preferable but not required. I've been reading up on various tools but can find none that could read through a packet with the granularity of a Wireshark display filter and manipulate content in this way. There are tools (eg: bittwist) that can sanitize IP addressing, or editcap for cutting off the tail bytes, but I can't find anything that can accomplish this. Does anyone have any ideas? Edit: For clarity this would be a protocol running over SCTP, which rules out most options I've looked at. asked 14 Jun '13, 15:22  Quadratic edited 14 Jun '13, 15:29 showing 5 of 6 show 1 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
So I understand you correctly - you have a protocol that is following after a SCTP header and you want to replace or remove the bytes of that protocol from the frame? Is there anything coming behind it that you need to keep, or is it always the last part of the frame? You said that it could occur multiple times in a frame, so I'm assuming there is some kind of encapsulation layer involved. Which would lead to the assumption that you look for a tool that can surgically remove that layer but keep everything else intact?
SCTP is a problem since no sanitizing solution seems to understand that protocol as of now.
Protocol stack would be IP/SCTP/M3UA, where one or more protocol containers for various MTP3 applications can follow.
Within such a packet, the need would be to surgically look for one attribute in one application and either remove or replace its content. The application containers in the packet can come in any order, and there can be multiple occurrences.
Simple enough, right? :)
I don't think there is any solution for that right now - it's basically falling into the type of task (trace file sanitization) that I'm going to talk about next week on the Sharkfest conference.
Right now I know of no tool that can sanitize protocols beyond layer 4, and your case is special since it is a less common protocol (not to say rare, compared to others like HTTP etc :-)). So in this case it'll be hex editor pain for you I'm afraid - unless someone else knows a tool that can help, but I kinda doubt it.
If you decide to go Hex editor and your file is in pcap format you might want to take a look at the 010 editor by Sweepscape. They have a template that allows parsing of pcap structures, which means that at least you have some sort of guidance in the file.
Thanks. Yes, I don't think there's a good solution here and will probably need to build something. :/
Just to speak on the rarity though, SS7 over IP is super popular in telecom and mobile carriers. The challenge is really that it's one entire protocol stack encapsulated as the application payload of another. There are actually a lot of challenges on the protocol analysis front for sigtran that stem from this.
I don't know much about telecom and carrier traffic, but want I meant was that it is a protocol that only a limited number of people will have to work with in terms of analysis/sanitization, when compared to widely used stuff like HTTP. Unfortunately, this is what makes it less probable that someone writes a tool to sanitize it.
I'm building a trace sanitization tool for over a year now and if you really want to build your own I can tell you that it is a ton of work if you not just want to patch bytes at specific offsets (which is what most of the existing tools do, and why they usually fail for complicated protocol layers or encapsulated stuff).
Oh yes, it'll be a lot of work if I have to go that route. I have some advantages there like having fixed-length headers for stuff I care about right up the point where MTP3 starts, but there are a lot of headers and length fields I'd have to read after that to get the right containers.
It's a shame really - tshark is clearly able to dissect all this right up to the point where it can cleanly identify and decode the fields I'm after and can print it cleanly in a fields -e output. It's done almost all the work I'd need it to do, except one little text edit once it has mapped it all out. It seems to have almost everything it needs to be the perfect packet crafter but it just can't do that last text edit. Might be something I can add to the wanted list for features. :)