Use RDPDR logged on message to time payloads properly

[xshill]

The RDPDR channel seems to send a special PDU when the user has logged on. This would be ideal for timing on-connection payloads.

The packet ID for this message is PAKID_CORE_USER_LOGGEDON.

To do:

1. Check when the message is sent. It's possible we might have to use a small delay to make sure everything works properly. Also check if the message is always sent if the RDPDR channel is initialized, even if the client doesn't actually use the channel.
2. Run the payload when receiving the message in the cases where we can predict that the message will indeed be sent. In other cases, keep it the way it currently works (user-configured delay).

[Res260]

Need to confirm, but i'm 90% sure the message does not get sent if the RDPDR channel is not activated. The purpose of this PDU is to prevent the client from sending useless disk/other IO requests that won't get answered because the client should not have access to the devices

[Res260]

However, in a typical work environnent, I think its a fair assumption to say that the channel is active most of the time (since I think its activated by default)

[xshill]

What I would really like to know is whether or not it gets sent even if the client does not have the intention of mapping drives or anything. I'm think all MS clients initialize all channels anyway. If this is indeed the case, then we could probably make use of that message 100% of the time.

[Res260]

It is sent when the user is logged on, or when the server reconnects to a session with an already logged-on user, immediately after it receives a Client Core Capability Response. This packet is sent only if the client's general capability set has the RDPDR_USER_LOGGEDON_PDU bit set in the extendedPDU field.

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpefs/2ecd5c18-8c8c-4f5d-97ef-794ce19e91ba

So the client needs to send its capabilities first, we just gotta confirm that tsclient.exe indeed does that even if you don't map anything (I'd think its the case)

[Res260]

Other reference: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpefs/006b6528-0684-438e-8c62-e30c8c27f0f0

[Pourliver]

I've done a few tests to understand how the RDPDR channel works, and from my understanding, it only seems enabled when connecting via the default Windows RDP client.

I've tried a few other RDP clients. For example, using Windows Remote Client, the server sends the "PAKID_CORE_SERVER_ANNOUNCE" request after connection, but the client never sent any DeviceRedirectionPDU.

[alxbl]

I'm going to close this since the proposed solution would not work across all clients (FreeRDP uses rdpdr for announce lists but never seems to receive a USER LOGGED ON) and would require handling both behaviors.

We can revisit this if we find a better way to detect authentication in the future.