I have a capture (pcap) file with GTP-C and GTP-U traffic. I need to edit the inner source and destination IP address of the GTP packet. These would be the IP addresses related the actual subscriber's traffic flow. I was trying to achieve this using tcpprep and tcprewrite, but I am only able rewrite the outer (GGSN and SGSN) IP addresses. I want to keep the outer IP addresses as is, and only change the inner IP addresses. So, is it still possible to achieve what I want using tcpreqrite or do I have to take some other approach? Thanks. asked 29 Oct '13, 09:08  waqasamin |
2 Answers:
TraceWrangler can parse GTP-U packets and allows removing the outer layer, basically stripping the packet down to the inner IP and payload layers. It does not (yet) offer annonymization/modification of GTP-U or GTP-C packets, but maybe I can add that functionality at some point. The problem is that it is quite hard to find adequate samples to do the tests while implementing features like that, because of the sensitive nature of the details found inside. Sort of a Catch-22: I need to see a sample to be able to implement anonymization but I can't get the sample because it is not anonymized yet :-) But back to your question: I doubt that there are any tools that can do what you need, because both tcprewrite and bittwiste cannot deal with tunneled layers. I guess you'll have to do it the hard way in the meantime: using a hex editor (I can recommend the "010 Editor" which has templates that makes it easier to parse pcap files). answered 30 Oct '13, 00:33  Jasper ♦♦ edited 30 Oct '13, 00:34 Removing the outer layer is not difficult, but that is not what I need. I do have a very good sample, but for understandable reasons I cannot share that :). I think the hex editor approach won't work because the file is over 1GB, though I will still give it a go. Thanks. (30 Oct '13, 07:22) waqasamin Some sample files:
Have fun coding that stuff ;-)) (30 Oct '13, 15:20) Kurt Knochner ♦ GTPv1 especially has some stuff out there, mostly as it relates to openGGSN, but even then it's darn-near impossible to get full mobility call flows in a trace file outside of tight NDAs. I'm trying to get permission from a carrier to allow public distribution of 3GPP call flow traces that can be generated in a lab environment (a mini but working cell network, simulator-free and with support for the major EPS, GPRS and traditional CS call flows). With a test network number and non-confidential media payload, I think I could reliably reproduce and capture snapshot examples of most 3GPP-defined call flows including all protocols involved, and comment every packet in the flow citing the 3GPP TS and section number that defines why it's there. Getting that approved might be difficult but since I need to lobby for it anyway to complete a publicly-distributable project I'm trying to get off the ground, if I'm successful I'll get you the trace files if it helps you with your sanitizer. Can't make any promises though. (30 Oct '13, 20:38) Quadratic @Kurt: thanks, I already have some of them, but I'll take a closer look to see if I can improve my decodes. @Quadratic: thanks for your efforts, it would be cool to see something like that. I can understand the sensitive nature of such traces, so if you can provide some that are not violating any NDAs and do not expose any critical data I would love to take a look. If not, that's fine too - there are so many other protocols that I can work on instead... :-) (31 Oct '13, 01:23) Jasper ♦♦
I always wondered what kind of secret byte string could be part of a capture file that requires an NDA? Aren't there test environments where one can generate 'non real world' traffic? (31 Oct '13, 02:59) Kurt Knochner ♦ There are a few things that contribute to the secrecy: Even though a protocol might be standardized, many mobile signaling protocols will reveal engineering decisions made by that vendor or by that operator. If you're a competing operator or vendor, there are a few ways you could take advantage of that. For example a vendor might lobby the 3GPP to make a section mandatory if they knew another vendor chose not to support it in their traces yet, or an operator might leverage design decisions made by another operator in their own decision-making process. And it's not just optional fields, or in some cases literally per-feature booleaan flags indicating support, either. The presence of some optional messages in a call flow would tell you whether that network was using real-time policy/QoS control, real-time credit control, checks against IMEI black list registries, etc. It would reveal whether they had deployed Diameter routing which is a hot topic in the industry right now. Even in a development environment, it would suggest a lot about their plans or the state of their production environment. Even to take something as standard as DNS, due to the 3GPP's extensive use of NAPTR and SRV records to convey service information, a full DNS trace would practically serve as an NMAP protocol scan in the core of a carrier's network, providing a list of logical systems, their IPs and what protocols and protocol versions they support. In general, since mobile networks have so many small parts communicating so verbosely to each other, a packet capture of all the signaling flows is revealing on many levels. Some vendors also have proprietary versions or extensions to standards, where the messages themselves (unlike something like EIGRP) could actually be under NDA as well. And for exchanges in the SS7 stack, the equivalent of public IP info (public point code and GT information) would be revealed as well. You'll notice that most traces that have been made public have been GTP or MTP3-related, which are sent between carriers and can't really be "protected" in this way from untrusted peers. Rarely will you see radio network exchanges (NBAP, RANAP, S1AP) or intra-core exchanges (SGsAP, Diameter policy/credit/authentication for the time being) in the wild right now. Anyway, my plan is to use a minimalist lab environment to demonstrate the simplest, standards-based flows possible, then request NDA exemption for them. I honestly don't think I will succeed, but we shall see (03 Nov '13, 13:14) Quadratic @Quadratic: thanks for elaborating, this was a really interesting explanation. It also means that I probably shouldn't spend too much time on thinking about sanitization for these kind of traces, since you made it clear that even features being present/not present can be a problem - and I just really don't know enough of these protocol families to be able to do a good job in that regard. So dear network carrier engineers, I'm sorry, but unless I change jobs and become really familiar with your network protocols I will spend my time sanitizing others that I know better ;-) Of course, if there is a good lab trace and someone tells me what to focus on / what makes sense to sanitize I could try ;-) (03 Nov '13, 13:25) Jasper ♦♦
Jesus, that sounds like 3GPP environments are more like a secret society than an 'open' protocol standard ;-) O.K. I see, there is obviously no simple way to generate meaningful traces, except by capturing them in a live environment and that would contain too much about internal structures. In that respect, I wish you good luck with your endeavor :-) Thanks (04 Nov '13, 05:24) Kurt Knochner ♦ showing 5 of 8 show 3 more comments |
See my answer to a similar question: Basically you can use a hex editor (as @Jasper said), or you can use sed on Linux. The IP header in the GTP encapsulated frame should be pretty unique in the capture file, so if you just replace the byte string that contains the IP addresses, it should work (in most of the cases). Sample gtp-u file: Now, run sed on Linux (tested and works!) One direction of communication:
Other (reverse) direction of communication:
This will change the IP addresses from: 202.11.40.158, 192.168.40.178 This is not perfect, as you may hit false positives in your pcap file, but it's better than nothing ;-)) Hint: The IP checksum will be wrong after that change, but there is no simple solution for this. Sorry. Regards answered 30 Oct '13, 15:32  Kurt Knochner ♦ edited 31 Oct '13, 03:29 |
I'm not certain if it works on GTP traffic, but you might take a look at Bittwist http://bittwist.sourceforge.net/ It has a packet editor that may do what you need.