dissecting PPP compressed packets to discover rtsp address

Question

Hi there I'm trying to find the rtsp URL for a video using Wireshark. I am only able to connect to the site and play the video using a VPN. I start Wireshark sniffing on wlan0 and when I stop the capture and sort the captured packets by protocol, I don't see any that are listed RTSP. However, there are a whole heap of PPP compressed datagrams. If I were able to decompress these PPP packets, would the data inside them contain the RTSP URL? Furthermore, is there any way to decompress these packets using Wireshark? Thanks.

Answer 1

0

If I were able to decompress these PPP packets, would the data inside them contain the RTSP URL?

Yes, if they contain the RTSP traffic, otherwise, no.

is there any way to decompress these packets using Wireshark?

What form of compression are they using?

answered 16 Mar '13, 10:52

Guy Harris ♦♦
17.4k●3●35●196
accept rate: 19%

I'm using www.freecanadavpn.com, so I'm guessing they're compressed using GRE?

(16 Mar '13, 14:52) daloonik

GRE is a tunneling mechanisms, not a compression mechanism. FreeCanadaVPN speak of PPTP, and this Microsoft page on PPTP says PPTP uses "a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames as tunneled data" and that "PPTP inherits encryption or compression, or both, of PPP payloads from PPP."

PPP has the Compression Control Protocol, as specified by RFC 1962, which allows many different compression algorithms to be negotiated.

(16 Mar '13, 16:43) Guy Harris ♦♦

So are you seeing any Compression Control Protocol packets when the session starts up, to show what form of compression is being negotiated? The form of compression being negotiated might, or might not, be one that Wireshark knows how to decompress.

(16 Mar '13, 16:44) Guy Harris ♦♦

Thanks for your response. Based on what I can see below, I'd say Microsoft PPC. Is this correct?

Internet Protocol Version 4, Src: 192.168.xx.xxx (192.168.xx.xxx), Dst: 184.107.xxx.xxx (184.107.xxx.xxx)
Generic Routing Encapsulation (PPP)
Point-to-Point Protocol
    Protocol: Compression Control Protocol (0x80fd)
PPP Compression Control Protocol
    Code: Configuration Request (0x01)
    Identifier: 0x02
    Length: 10
    Options: (6 bytes)
        Microsoft PPC: Supported Bits: 0x01000040

(25 Mar '13, 13:09) daloonik

Answer 2

Based on what I can see below, I'd say Microsoft PPC. Is this correct?

According to RFC 2118, the low-order bit of "Supported Bits" is set if compression is being requested, but that bit isn't set. According to RFC 3078, the two bits that are set in "Supported Bits" request 128-bit encryption and stateless mode.

So I think the answer to your question is "no"; confusingly, the packets aren't compressed, but they are encrypted. Decrypting will probably require not only code but also the initial session key (or information sufficient to derive it).