Ask Your Question
0

How to convince Wireshark to interpret packets as RDP

asked 2022-02-08 09:33:33 +0000

Youda008 gravatar image

updated 2022-02-08 14:03:43 +0000

I'm trying to debug a custom RDP implementation, but can't make Wireshark display the RDP packets properly. To be sure the issue is not in my captures, i downloaded some examples from https://wiki.wireshark.org/RDP

But when i open it, i see no RDP packets. Filter rdp displays nothing, and so does tpkt. When i manually select tcp.port == 3389, i see the connection sequence but all the packets including the first are wrongly displayed as "SSL: Continuation Data" or "TSL: Ignored Unknown Record", even though the first few ones are unencrypted because they contain encryption negotiation.

I tried Analyze -> Decode As, but it does not work. When i add a rule "TCP port | 3389 | Integer, base 10 | (none) | TPKT" and click OK, nothing happens and when i open the Decode As dialog again, my rule is not there.

I also tried manually editing the text file at C:/Users/Youda/AppData/Roaming/Wireshark/decode_as_entries but when i added decode_as_entry: tcp.port,3389,(none),TPKT saved the file and restarted Wireshark, the rule wasn't there either.

To make my intent clear, i'm NOT trying to decrypt the entire RDP traffic, i'm trying to view the first few unencrypted connection initiation packets.

Can anyone help me?

EDIT: I also tried Edit -> Preferences -> Protocols -> TPKT, and added 3389 to TCP ports field. But after restart the field was reset to default 102. Any other port than 3389 survives the restart, only 3389 gets deleted. And same applies for the Decode As dialog. Is this some kind of anti-RDP conspiracy? Where-ever i enter the port 3389, the setting gets deleted. Is there some hardcoded rule preventing this port from being used in Wireshark?

EDIT2: My version is:

Wireshark 3.6.1 (v3.6.1-0-ga0a473c7c1ba)

Compiled (64-bit) using Microsoft Visual Studio 2019 (VC++ 14.29, build 30138),
with Qt 5.15.2, with libpcap, with GLib 2.66.4, with zlib 1.2.11, with Lua
5.2.4, with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.44.0, with brotli, with LZ4,
with Zstandard, with Snappy, with libxml2 2.9.10, with libsmi 0.4.8, with
QtMultimedia, with automatic updates using WinSparkle 0.5.7, with AirPcap, with
SpeexDSP (using bundled resampler), with Minizip.

Running on 64-bit Windows 10 (21H2), build 19044, with Intel(R) Core(TM)
i7-8750H CPU @ 2.20GHz (with SSE4.2), with 32584 MB of physical memory, with
GLib 2.66.4, with Qt 5.15.2, with Npcap version 1.31, based on libpcap version
1.10.1-PRE-GIT, with c-ares 1.17.0, with GnuTLS 3.6.3, with Gcrypt 1.8.3, with
nghttp2 1.44.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.4.0, without
AirPcap, with LC_TYPE=Czech_Czechia.utf8, binary plugins supported (0 loaded).
edit retag flag offensive close merge delete

Comments

Try it with the high (client) tcp.port number in the Decode as rule.

Can you add output of wireshark -v to the question?

Chuckc gravatar imageChuckc ( 2022-02-08 13:18:36 +0000 )edit

@Chuckc Tried it with the client port, doesn't work. The rule stays there this time, but it doesn't do anything.

Youda008 gravatar imageYouda008 ( 2022-02-08 14:01:04 +0000 )edit

Sorry - I was running a pre-release 3.7.0 build.
In 3.6.1 I have to disable SSL then set the rule decode_as_entry: tcp.port,10446,(none),TPKT
(for SampleCaptures/RDP-002.pcap.gz from the RDP wiki page)

Chuckc gravatar imageChuckc ( 2022-02-08 14:18:07 +0000 )edit

Chuckc, Is this a bug issue or feature request? The answer isn't obvious. I found the same answer after looking at version 1.10. Version 1.10 reports the stack as eth:ip:tcp:tpkt:cotp. I checked the Wireshark issue site and found an open "RDP dissector TODO list", but I don't see this on the list.

BigFatCat gravatar imageBigFatCat ( 2022-02-09 11:07:29 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-02-09 19:34:00 +0000

Chuckc gravatar image

updated 2022-02-09 19:34:50 +0000

I think the behavior changed with TPKT: Add the dissector to the list of TLS subdissectors.
There should be a way to exclude 3389 from TLS. And it shouldn't use what @rknall calls a "magic number" with the port hard coded to "3389". (packet-tpkt.c#L687)
Testing with a previous version (3.0.2), added 3389 to the tpkt ports Preference and the dissection works fine with TLS enabled.

edit flag offensive delete link more

Comments

Issue 17952: RDP dissected as SSL has been closed with commits in the Main branch and cherry picked back to the 3.4 and 3.6 branches.
Pre-release builds are available to test in the Automated Builds download area.

Chuckc gravatar imageChuckc ( 2022-04-03 23:26:00 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2022-02-08 09:33:33 +0000

Seen: 2,058 times

Last updated: Feb 09 '22