shramos / polymorph

Polymorph is a real-time network packet manipulation framework with support for almost all existing protocols
GNU General Public License v2.0
445 stars 61 forks source link

Problems with the packet Dissector #24

Closed tanaxer01 closed 3 years ago

tanaxer01 commented 3 years ago

Hi @shramos, While trying to modify some RTSP traffic, I noticed that the RTSP layer was weirdly parsed. Screenshot from 2020-10-14 15-14-47 You can see that the TCP payload is correct but in the RTSP layer there is some stuff missing, instead, there is a blank space.

I also noticed this problem when you are working with functions, the "request" variable inside the layer is used in the response packets. For example, using this function: Screenshot from 2020-10-14 15-27-49

You get both the request and the response: Screenshot from 2020-10-14 15-26-25

Thanks in advance!

shramos commented 3 years ago

Hi @tanaxer01,

Thank you for your comment. Polymorph is interpreting the values correctly, the problem you have with the display is related to the type of the field.

If you look, the payload field, it is interpreted by Polymorph as type bytes, however, the request and transport fields of the RTSP layer are interpreted as strings. When printing on screen the value of these fields as a string, what happens is that special characters such as \r or \n are interpreted as such and therefore represented as a line break.

If you want these two fields in the RTSP layer to be interpreted as bytes, you can change the field type in Polymorph very easily, from the main interface you access the field interface and execute the following command:

PH:cap/t3 > layer RTSP
PH:cap/t3/RTSP> field request
PH:cap/t3/RTSP/request > type -a

1: FT_INT_BE
2: FT_INT_LE
3: FT_STRING
4: FT_BYTES
5: FT_BIN_BE
6: FT_BIN_LE
7: FT_HEX
8: FT_ETHER
9: FT_IPv4
10: FT_IPv6
11: FT_ABSOLUTE_TIME
12: FT_RELATIVE_TIME
13: FT_EUI64

Select the type of the field: 4
New type Ftype.FT_BYTES added to the field.

PH:cap/t3/RTSP/request >

Once this is done, you will see how the special characters appear when you invoke the show command.

On the other hand, the problem you mentioned about printing the request and part of the response, has to do with the way Polymorph works.

When Polymorph generates a template, it parses the captured network packet and generates a series of fixed positions for the fields in that packet. It then uses these positions to access the network packets it intercepts in real time. However, polymorph does not know which network packet it is intercepting, it only accesses the bytes that are in that fixed position. Therefore, it is the user's job to pre-filter the captured packets to ensure that the fields we are interested in are in those positions.In your example, you should put an if condition that separates the RTSP network request packets from the responses based on another field that you know exists in both. I recommend that you take a look at the simple examples in the wiki.

In addition to your question, there is one more thing you should be aware of that may give you problems if you continue to modify these types of network packets. If the value of the field is variable, i.e. its length can be modified by a user, a system, etc... then we have to tell Polymorph where it can obtain the length of this field, otherwise it will assume that the length of that field is the same as that of the network packet with which the template was generated, and therefore it may be wrong. This process is explained in this section of the wiki: https://github.com/shramos/polymorph/wiki/Case-Study.-Part-3:-Structs

I hope this solves your problems

tanaxer01 commented 3 years ago

Hi again!

After testing some stuff, I think the reason why some of the fields (Ej Cseq) arent placed in the RTSP layer is because their position varies depending on which packet is sent.

thanks for the help!