Replayability

[rmoller]

Hi,

this is a many-folded request for a "replayability option".

I managed to record and save VNC traffic and replay it later to a viewer - required for auditing purposes. On the viewer side, I had to choose a specific Encoding, refrain from using encryption and file transfer etc. I imagine that the viewer would be confused to suddenly receive file transfer traffic while not having a file transfer window open, and when I tried to replay a saved auto-encoding session, it aborted after a short while, probably because the viewer decided to change encoding, but the blind replay didn't follow.

So:

Repeater request : automatic record (server traffic, framebuffers only) to file and on demand replay from file to viewer.

VNC server/viewer/SC* request: Switch to limit options/features to those who are replayable, ie. independent of viewer actions.

I hope you can follow my line of thinking, we expect auditability to become more prevalent in the future.


Rasmus Møller

[Rudi De Vos]

Repeater does not understand rfb, he only forward data.
Repeater does not decrypt the data, he does not know what the data is.

The only way to record anything is via the viewer, after the data has been
decrypted.

recording ?
-data can be recorder as avi
-data can recorded as vnc packets

[rmoller]

Yeah, my little program only forwards data, too. That is why I need ways to ensure, that the server only sends replayable data.

Unfortunately the viewer is by nature in the hands of the consultant, whose actions I am supposed to be able to audit. Of course I can make him promise to record his actions faithfully, but our Internal Revisions require me to force recording on our side, that is, either via a repeater-like program or on the server.

But I don't think that your ScreenRecorder can be automatically activated upon connection and deactivated upon disconnection, can it?

Thanks for responding

[Rudi De Vos]

With some changes is possible...

Recorder need to be integrated in winvnc, and just start/stop it
with viewer connection. (use 5fps to not overload the system and auto save to a file using a timestamp as name)

The problem is that i don't want the bundle the recorder with vnc (GPL)
So, apps need to be seperated.

I have never tested if screenrecoder and vnc can use the driver simultanious. If that is possible, adding a driver watcher to the screenrecoder could do the trick.
Driver activated==viewer connected==start recording
Driver desactive==viewer disconnect==stop recording

Perhaps....if more people are interested i could make it.

[bevtech]

Ridi,

I did a test with mirror driver installed ultra 1.0.1

vncdrv.dll version 1.00.19
vnccom.sys version 1.00.17
vncdrv.sys version 1.00.17

and the VNC recorder will work while connected to a winvnc 1.0.1
I also tested 1.1.0.0 and it still will recorded.

I hopes this helps the Ultra VNC developers




Note to Readers!!!

Note: Users have to have windows 2000 or XP boxes to use mirror driver found on http://doc.uvnc.com/

If you are using a old version please uninstall and reboot pc and reinstall the new version making sure to check the clean up registry option:)

Will save yourself a lot of grief and posts As well as searching posts for answers

[rmoller]

Well,

Ultra ScreenRecorder is a great product, but it is more in the league of DemoForge. It is both overkill and not quite enough, as it can in principle miss some updates, that went to the consultants' screen.

Already record/replay seems to work for me (with some limitations) just by replaying recorded servertraffic into a VNC viewer, and if anyway you consider separating the UltraVNC V2 traffic into several data-sessions in the same IP-tunnel, then I have a proposition for the Winvnc Server V2 or Repeater V2:

That one of the data-sessions in the IP-tunnel per design only sent (uniquely decodable) screen data, which could optionally be logged into a per-VNC-session screen-traffic log file.

A "replayer" for that log file would be simple for me or someone else to make, but the whole thing is much more feasible, if per design the screen traffic could be separately logged/saved.

Perhaps I am the only one facing audit issues, so I understand that it may not be high on the general wish list, but the timing (while the V2 protocol is still open) is good, I think, and in any case I am grateful for the attention you have given so far.

[scotte]

Hi,

this is a many-folded request for a "replayability option".

I managed to record and save VNC traffic and replay it later to a viewer - required for auditing purposes. On the viewer side, I had to choose a specific Encoding, refrain from using encryption and file transfer etc. I imagine that the viewer would be confused to suddenly receive file transfer traffic while not having a file transfer window open, and when I tried to replay a saved auto-encoding session, it aborted after a short while, probably because the viewer decided to change encoding, but the blind replay didn't follow.

So:

Repeater request : automatic record (server traffic, framebuffers only) to file and on demand replay from file to viewer.

VNC server/viewer/SC* request: Switch to limit options/features to those who are replayable, ie. independent of viewer actions.

I hope you can follow my line of thinking, we expect auditability to become more prevalent in the future.


Rasmus M�ller

How, exactly, did you manage to perform the playback?

I configured UVNC server on an XP machine at a remote location (cable mdoem connection), and at home, used the UVNC Java interface in a web browser to record the session using highest compression and Tight, with 256 colors. But I have yet to find a way to play back the resulting vncsession.fbs.00x file.

What exactly did you to do to record and play back?

If you also had a .fbs session, how did you play it back?

Thanks.

Scott

[rmoller]

I have not tried to record via the JAVA viewer until today. While recording was active, I could not interact with the JAVA viewer at all. I suppose one has to have two sessions in parallel, one for interacting and the other for recording.

I checked the content of the recorded file, and it was recognizable as a pure dump of binary RFB data wrapped in very few delimiters. I do not know of a player for these data; it might be for rfbproxy.

I tried the ScreenRecorder successfully, it is separately downloadable as a stand-alone EXE from somewhere in the ULTRAVNC website. It makes files to playback with almost any media player.

None of these products are "it" for security audit, though. We need something automatic that cannot be bypassed by a viewer. I have tested a "proof of concept" TCP-tee like program I made myself. A simple TCP forwarder which dumps the traffic to a file a little like the FBS file. I made another program to read the recorded file and play it back (at the original pace) to a VNC viewer.

I had some success replaying the file, as long as I stuck to very predictable features - I did not use file transfer, as the replaying VNC viewer would not be in the same situation as the recording VNC viewer. Similarly, randomizing logon/encryption schemes might upset the VNC viewer during replay. Reverse connections worked easily.

Incidently the same recorder/replayer worked with RemoteDesktop sessions (also with some limitations).

The best thing would be a TCP forwarding program like my recorder, paired with a replaying program which could understand/interpret the UltraVNC RFB stream so as to filter away noise like File Transfers, and at the same time allowing for fast forward, restart etc. But the current UltraVNC protocol definition is only available in the form of the Ultra VNCviewer source code, and it is too big a mouthful for me to decipher.

[redge]

I checked the content of the recorded file, and it was recognizable as a pure dump of binary RFB data wrapped in very few delimiters. I do not know of a player for these data; it might be for rfbproxy.

Why vncviewer unable to open file and read vncession.fbs and play the file ?
it is so complicate for vncviewer ?