Remove all unknown layers: when this setting is active, TraceWrangler will cut away all protocol layers of a frame that it does not understand. For example, there is no parser for SMTP at the moment, so if a packet is part of a SMTP conversation it will only be written to the sanitized file up to the TCP layer. That way no details will be kept that TraceWrangler does not know how to handle, which minimizes the risk of exposing sensitive information by mistake. You can choose one of three ways to handle unknown layers:
- cut away bytes from packets: the unknown layers will be cut away and discarded. This will shorten the frame bytes, but TraceWrangler will keep the Wiresize value intact. That means that all calculations based on the original frame length will still be valid.
- replace bytes with zeroes: in this mode, the packet length will stay the same, but all bytes of unknown layers will be replaced with zeroes
- replace bytes with pattern: instead of cutting bytes away or replacing them with zeroes, TraceWrangler will use the value specified in the Payload Replacement Pattern field to overwrite unknown bytes. The pattern will be repeated as many times as required until all bytes are overwritten. Remaining pattern bytes will be discarded if the pattern is too long.
WARNING: Do not uncheck this setting unless you are fine with keeping all protocol layers, even those that cannot be sanitized!
Truncate packet after layer: this setting can be used to remove any packet content that is following the mentioned layer. For example, removing all payload after layer 4 (usually meaning TCP or UDP) will lead to all frames being written without any layer above TCP or UDP. TraceWrangler will determine where the layer to be kept ends and cut at the exact byte. This means that even when a TCP packet has options of different sizes it will keep the TCP header intact and remove the payload. The difference to doing this on a TAP is that TraceWrangler will keep the original frame length intact, e.g. for making it possible to keep working with TCP sequence numbers.
Truncate packet after offset: when this setting is active, TraceWrangler will truncate all packets after the offset that is specified.
If more than one or even all settings are active, they will all be applied from top to bottom. This means that all unknown layers will be removed, followed by another truncate that will cut away anything beyond the layer specified, and finally the offset truncation will take place. So if for some reason you need a combination of these settings they will just work.
Replace specific strings in unknown payloads: If you want to replace strings in frames you can use this option to specify which string should be replacement with another string. There are a couple of important details if using this feature:
- This option is only available if the packets are not truncated after a layer, and if unknown payloads are kept in the sanitized file. Otherwise string replacement just makes no sense because there is no payload to look at, at least as long as TraceWrangler doesn't understand protocols transported by TCP.
- The replacement string needs to be the same length as the original. For that purpose a counter will appear in the upper right corner of the replacement list whenever a string replacement is added. You should try to make the replacement string the same length, otherwise it will be padded with spaces if too short, or truncated if too long.
- Adding more than one string is possible, but a little awkward at the moment: you need to press "cursor down" to add a new line.
- There is a pop up menu that allows importing and exporting strings, to make it easier to edit lots of strings without having to use the table editor on the form. The list needs to be comma separated, basically in the most simple from of "<key>,<value>". If you need to use commas in key or value they are escaped with a backslash.
- Strings can only be entered as numbers, characters and some extra characters - basically the lower 127 characters in the ASCII table.
- You can also use Snort style hexadecimal string syntax, embraced in two pipe characters, e.g. |00 01 02 03|. You can mix ASCII string elements with those hex elements if you wish. This allows the replacement of any type of byte string.
- Replacing payload content may lead to minor side effects of checksums being recalculated correctly even when the original frame had bad checksums. You can always take control of that behavior in the respective settings of each protocol layer.