GoSecure / pyrdp

RDP monster-in-the-middle (mitm) and library for Python with the ability to watch connections live or after the fact
https://www.gosecure.net/blog/2020/10/20/announcing-pyrdp-1/
GNU General Public License v3.0
1.5k stars 242 forks source link

pyrdp player logs are different with/without headless #445

Open i-am-shodan opened 1 year ago

i-am-shodan commented 1 year ago

I'm using the latest version of pyrdp

When I run: venv/bin/pyrdp-player.py /mnt/d/rdpdebug/19700101000000_191.101.157.12%3A50217-10.0.13.101%3A3389.pyrdp

I get this log at the bottom of the screen

--------------------
HOST: iPhone

--------------------

--------------------
USERNAME: Administrator
PASSWORD: MYPASSWORD
DOMAIN: 

--------------------
notepad
<Return pressed>
<Return released>hellhello world!
<Connection closed>

But when I run:

venv/bin/pyrdp-player.py --headless /mnt/d/rdpdebug/19700101000000_191.101.157.12%3A50217-10.0.13.101%3A3389.pyrdp

I get either this debug out file

[2023-07-28 14:49:28,808] - INFO - pyrdp - Starting PyRDP Player in headless mode.

or this from stdout

== REPLAY FILE: 19700101000000_191.101.157.12%3A50217-10.0.13.101%3A3389.pyrdp                                                                                                                                                                                                                                                                                                                    --------------------                                                                                                                                                                             HOST: iPhone                                                                                                                                                                                                                                                                                                                                                                                      --------------------                                                                                                                                                                                                                                                                                                                                                                              -- END --------------------------------

They should be the same

i-am-shodan commented 1 year ago

Seems like Replay is only returning 1 event, the first one

obilodeau commented 1 year ago

I can't reproduce this from my setup and @robeving's fix puzzles me so I want to test it out.

Can you provide the .pyrdp file? How was it created? With pyrdp-mitm or with pyrdp-convert?

i-am-shodan commented 1 year ago

I can provide you an original decrypted PCAP if you like and the command lines I use with pyrdp-convert to get the result.

Basically timestamp is always 0 when I do: Enc pcap -> decrypt with tshark -> convert with pyrdp-convert -> replay to get logfile

The only thing unusual in my set up is that the pcap is constructed with a library coming out of our custom RDP load balancer. That being said it looks valid in wireshark and tshark is producing the decrypted pcap.

obilodeau commented 1 year ago

Yes, getting a decrypted pcap would be great. Attach it here or send it to my username at gosecure.net.

obilodeau commented 10 months ago

The fix proposed in #446 is not going to be accepted in its current form. It affects how all files are replayed (including via the GUI). Using an index instead of a timestamp affects the video reconstruction by stitching together all protocol actions (display, mouse, etc.) without delays or silence.

If I could get my hands on a pcap to reproduce I might find another fix.

I suspect that it could be fixed at the pyrdp-convert stage instead.

obilodeau commented 8 months ago

You might want to check the fix merged in #466 if it improves your situation.

The problem was: if several events had the same timestamp, we would bundle them together but the ReplayReader iterator would only process the first event of a given timestamp. Additionally, the length of the conversion to do was evaluated on timestamps rather than events so conversion jobs with events on the same timestamp would end sooner, making the conversion shorter than it should be.

cc #446