This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Field obfuscation

0

Hi all, for security reasons, I need to obfuscate the MSISDN of my MAP_IAM.pcap files (example). Even if the CRC will not be valid, I need to post-produce a PCAP file having

msisdn: 91726741582XXX

instead of

msisdn: 917267415827F2

Could someone point me to in the right direction?

Thanks, Riccardo

asked 01 Oct '13, 00:36

Ric79's gravatar image

Ric79
31449
accept rate: 0%


One Answer:

2

You can use any hex editor to replace the bytes.

On Linux you can use sed.

sed -i 's/\x91\x72\x67\x41\x58\x27\xf2/\x91\x72\x67\x41\x58\x00\x00/g' gsm_map_with_ussd_string.pcap

On Windows (and Linux) you can use the swiss file knife)

http://stahlworks.com/dev/swiss-file-knife.html

Here is the result, based on your example.

https://www.cloudshark.org/captures/b8c674b79877

You said:

msisdn: 91726741582XXX instead of msisdn: 917267415827F2

You cannot replace the last digits with an X, as the dissector will convert the values to a number, so all you can do it to replace the last few digits with 0, as I have done (see above).

++ UPDATE ++

Maybe @Jasper is interested to implement binary (and/or text) replacements in tracewrangler as well!?!

Regards
Kurt

answered 01 Oct '13, 02:25

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 01 Oct '13, 02:51

Is it possible to extend your solution to a generic msisdn in a generic PCAP file?

(01 Oct '13, 02:34) Ric79

WARNING: that solution will not replace the MSISDN! It will simply replace the binary string. If, by any chance, the same byte string appears somewhere else in the capture file, it will be replaced as well and might cause a corrupted file!

However, I think the chances are pretty low to find the same 14 digit string (msisdn) somewhere in a capture file and thus I would go for it. However, you have been warned ;-)

(01 Oct '13, 02:38) Kurt Knochner ♦

Ok, so your solution is just for the specific case, not for a generic one. My problem is: 1) generic PCAP 2) find all GSM_MAP:IAM messages 3) obfuscate MSISDN

(01 Oct '13, 03:14) Ric79
1

Ok, so your solution is just for the specific case, not for a generic one.

No, that's a misunderstanding. My solution is generic, meaning you can replace whatever string you want. However, the solution knows nothing about the message structure, means it does not care if 917267415827F2 is a msisdn or something else.

My problem is: 1) generic PCAP 2) find all GSM_MAP:IAM messages 3) obfuscate MSISDN

O.K. for that case you'll need some scripting to find all MSISDNs first and then replace those strings in the file with sed.

This will print all msdisdn fields in the capture file.

for msdisdn in `tshark -nr input.pcap -Y "gsm_map.ss.msisdn" -T fields -e gsm_map.ss.msisdn | sed 's/://g'` ; do echo $msdisdn; done

Then you take each of the msdisn and run the sed command for them.

(01 Oct '13, 03:24) Kurt Knochner ♦

This is a nice idea. Is it possible with tshark also to get something about the byte positioning? For example if I get that 917267415827F2 is at byte 21234 I can modify the file in a more safe way

(01 Oct '13, 04:17) Ric79
1

Is it possible with tshark also to get something about the byte positioning?

Unfortunately not directly. That would help to eliminate false positives while you replace the string ;-))

However, you can do it yourself in a script.

tshark -nr input.pcap -Y "gsm_map.ss.msisdn" -Vx

Then search for the binary string in the HEX output to find the position. However, that position is just the one in the frame. But still, maybe it helps to design a solution.

(01 Oct '13, 05:19) Kurt Knochner ♦

Mmmh, I was thinking to "-e frame.number -e frame.len -e gsm_map.ss.msisdn".

1 138 91726741582341
2 256 7363272892334F
3 138 
4 138 34554323445566

In this way I can restrict the sed impact to specifc frame bytes. For example "7363272892334F" will be searched between bytes 139 and 138+256 ...

As @Kurt said it would be better if, inside a frame, I could know where the field is..

(01 Oct '13, 06:16) Ric79

For example "7363272892334F" will be searched between bytes 139 and 138+256 ...

good idea.

As @Kurt said it would be better if, inside a frame, I could know where the field is..

For that a code change of tshark would be necessary.

(01 Oct '13, 07:50) Kurt Knochner ♦

@Ric79 : Be careful with the offsets, as there are file headers and packet headers involved too. Also, when there was reassembly (at IP or TCP level), the MSISDN might even be in a different packet than the one in which tshark reports it.

(01 Oct '13, 07:57) SYN-bit ♦♦

@Ric79 : Be careful with the offsets,

That's true, so @Ric79 should use the accumulated byte count just as a rough starting point from where he starts searching for the byte string. That will further reduce false positives.

(01 Oct '13, 08:01) Kurt Knochner ♦
(01 Oct '13, 14:11) Ric79

@Ric79, why the breakout to a new question, there's lots of relevant info here?

(02 Oct '13, 02:09) grahamb ♦

@grahamb, here the question was about how to modify. The other post is about who to find the right byte position of a field/protocol in a frame..

(03 Oct '13, 06:06) Ric79
showing 5 of 13 show 8 more comments