Allow Extended Data Blocks in the ClientData and ServerData PDU

[Res260]

Right now, when receiving the clientData PDU (MCS connect initial, https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/db6713ee-1c0e-4064-a3b3-0fac30b4037b), PyRDP only parses the 3 required data blocks (clientCoreData, clientSecurityData, clientNetworkData) and one optionnal data block (clientClusterData).

However, more data blocks exist (see link above) such as one for multi-monitor support. This prevents more than one monitor to be used for an RDP connection through PyRDP which can reveal a MITM usage.

I worked a bit on this, I’ll submit a draft PR soon.

TODO:

• Make it so the negociation response PDU sent to the client keeps the EXTENDED_CLIENT_DATA_SUPPORTED flag (currently flags are hardcoded to 0x00) (ref https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/b2975bdc-6d56-49ee-9c57-f2ff3a0b6817)
• Support parsing and writing of unkown data blocks in the clientData and serverData PDU parsing
• Thoroughly test the MITM and the player, as this new behavior could lead to undesirable effects (such as UDP being negociated between client and server https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/3801236b-b5ba-4b6e-bf0d-afbde1fe391c)

[obilodeau]

We are planning to release 1.1.0 in the next month or so. Do you feel like working on this to make the cut or not?

[Res260]

Probably not, it would require a lot of testing and require changes to a lot of parts on the code base. I might be overestimating the effort, though. If someone wants to work on it I can share what I did.

[obilodeau]

You can open a draft PR if you want but it's not a necessity since we are not going to work on this for 1.1.0. Thanks for the quick reply.