Enable forwarding of unparsed Client Data Blocks in the GCC negociation. #304
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following discussion in #233 with @obilodeau, here are my changes to allow the CLIENT (I didnt do the server part) to send other data blocks in the negociation phase. The unparsed data blocks are sent to the server, which should in turn send its extended data blocks (ex. to negociate UDP connection). Currently the unparsed Server Data Blocks will be thrown away by PyRDP.
Bonus: Parse the client Monitor Data block and forward it to the server. This enables PyRDP to allow multiple monitors (like in a normal RDP connection) instead of forcing it to one. This information could be logged as it could be helpful to fingerprint the client.
Not included: PyRDP-player changes to see the other monitors.
I will leave this as a draft PR if you ever want to continue/test/get inspiration from those changes, but I don't plan to further work on this (it was for a CTF challenge), so feel free to close the PR if you don't need this!
The list of data blocks that can be sent is here: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/8a36630c-9c8e-4864-9382-2ec9d6f368ca