pyrdp player logs are different with/without headless
i-am-shodan opened this issue · comments
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
Seems like Replay is only returning 1 event, the first one
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 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.
Yes, getting a decrypted pcap would be great. Attach it here or send it to my username at gosecure.net.
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.
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