/closes #850 /claim #850

Description

Add support for RDP.

How to test

1. Build screenpipe-rdp. (its is isolated not member in workspace for ez build and test)
2. Copy capture_agent.exe and session_service.exe to your Windows server. (copy to any place just make sure both are in same folder)
3. Register the service from Administrator powershell terminal(Adjust the path of session_service):

• sc.exe create MySessionService binPath= "C:\Users\User\Desktop\session_service.exe" start= auto

4. Connect to Windows Server through RDP.
5. start the service from GUI or by sc.exe start MySessionService. (You can start the service before connect the client but you need to wait 60sec so session_service enum session and starts capture_agent in you session)
6. You should see screenshot from all session are running in the server in “C:\session_manager”.
7. loges can be found in “C:\session_service.log”.

Video:

https://github.com/user-attachments/assets/b379a8c4-1cb4-4451-8f90-77a2b6b03d15

Limitation

The only limitation is related to the capture screenshot code, you cant capture when the RDP application window(in client PC) are minimized(not focused RDP window work normally) that because of RDP protocol itself and windows are not render the desktop to save power and CPU.

So the capture agent starts on the different client sessions but cant capture the screen ONLY when the client RDP application window are minimized. while it capture screen if its not foreground window. Maybe there is a workaround but i don’t believe something like that can be bypassed(at least without driver)

Why the need of service

• WTSQueryUserToken(session_id) also needs LocalSystem (or a service account with SeTcbPrivilege).
• Even a full Administrator process running “as admin” does not have this privilege.
• OpenProcessToken and DuplicateTokenEx can’t help or bypass that. (As normal/admin user you just don’t have privilege to do that)

Bottom line:
There’s no way to “hack around” this from a plain Administrator process. Windows enforces this restriction so only trusted system processes can manipulate user sessions.

Best Approach for Implementation in Screenpipe

This feature requires inter-process communication (IPC) between the new service and screenpipe.

• For high-performance requirements: SharedMemory with proper synchronization or NamedPipe are the most suitable options.
• For less performance-critical scenarios: sockets or RPC can be used.

A more maintainable design would be to extract the capture logic from screenpipe and implement it as a standalone service (binary). This service should handle capture tasks in a general way, rather than being limited to RDP support. Such an approach improves modularity, makes the system easier to extend for future capture methods, and keeps screenpipe focused on its core responsibilities.

(In my PoC i let capture_agent take screenshot every 10sec and just store screenshots in “C:\session_manager”)

Notes

• You can hide the agent by target Windows subsystem not Console, or just hide the window(code for that are commented)
• You can combine both session_manager and capture_agent as one executable so the session_manager itself could be used to be spawned(CreateProcessAsUserW) on other users session with command line to ignore service_dispatcher::start and start as capture_agent (after add capture screenshot code).