MSRC4Plugin Not Compatiable with 1.0.9.x

[YY]

Tried to use MSRC4Plugin, and found it (all version: 1.1.x or 1.2.x) is not able be working under UltraVNC 1.0.9.x.

Below is my test results, where:

10961 viewer is the released dated Apr 15
10961 server is the released dated Apr 18
1.0.9.x viewer/server are the 1.0.9.6 or 1.0.9.5 viewer/server (both version were tested)
1.0.8.2 viewer/server -- i.e. exactly what they are


Viewer 　　Server 　　Able To Establish Connection?
====　　　====　　　==============================

10961 　　　10961　　　Error: Server run as Application
1.0.9.x　　10961　　　Error: Server run as Application
1.0.8.2　　10961　　　OK

10961 　　　1.0.9.x　　Error: Server run as Application
1.0.9.x　　1.0.9.x　　Error: Server run as Application
1.0.8.2　　1.0.9.x　　Not able to be tested (See note below)

10961 　　　1.0.8.2　　OK
1.0.9.x　　1.0.8.2　　OK
1.0.8.2　　1.0.8.2　　OK


Note: There is a bug in 1.0.9.x, when connected with 1.0.8.2, server CPU will jump to 100%


Base on the result, looks like the problem is at 1.0.9 server, because:
10961 or 1.0.9.x viewer ---> 1.0.8.2 server can be working properly with MSRC4Plugin.

[Rudi De Vos]

Can't repeat it with plugin
1.2.2-noreg
1.2.4

with rc4.key and without i get connected.

server and viewer 10961 as service encoder hextile.

Tested auto encoder -> fail !!!!!!
Seems zrle is causing it....

Can you confirm it's a zrle issue ?

[Rudi De Vos]

Damm.... this was fixed, it's a viewer zrle issue.

If MSRC4Plugin.dsm then oldplugin
else new

then i added the same for ARC4plugin

If ARC4plugin.dsm then oldplugin
else new

Natural, when you have a MSRC4Plugin.dsm it is not ARC4plugin.dsm
and this answer new....
"if" needed to be a "else if" ..oçé"è!(à!ç&(§&éè!à"'(§à&!èà

Fixing...

Anyway, viewer info on encryption is wrong for old plugins, they always
no encryption, confusing... fixing this also at once.

tofix updated with new bins

[redge]

Further bug testing with service_commandline in the middle condition
test 10961 winvnc system 18 april
test 10961 vncviewer 15 and 21 April

MSRC4 1.2.4.0 active both side NO rc4.key only VNC password
LAN 100Mb <--switch/router-> LAN 100Mb
while winvnc system doing reverse connect to repeater as background
service_commandline=-autoreconnect id:1234 -connect repeaterhost
vncviewer (NOT listen) do direct connect to winvnc

vnc authentication success OK... wait... 5min... see result:
Why waiting 5min before show remote screen if authentication success for direct connection even winvnc is doing reverse connection to repeater and waiting viewer?


vncviewer GUI, deleted saved settings before start all test
whatever quick option without any further change.


vncviewer 15 April result
QuickOption: Bold value
VNC authentication OK
Negociate Protocol Version... 5min...
(no encryption)

• AUTO
  Error: Server running as Application
• LAN
  5min ... later see remote screen OK
• MEDIUM
  server running as Application
• MODEM
  remote screen visable then it autoclose immediately with... server running as Application.
• SLOW
  remote screen then it autoclose immediately with... server running as Application.
• MANUAL
  remote screen OK
  

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


vncviewer 21 April result
QuickOption: Bold value
VNC authentication... OK
Negociate Protocol Version...
(old plugin, rc4.key, encryption)

• AUTO
  waiting 5min ... remote screen OK (auto connected as hextile)
• LAN
  waiting 5min ... remote screen OK (hextile)
• MEDIUM
  after 5 min... remote screen OK (ZRLE)
• MODEM
  after 5min ... remote screen OK (ZRLE cache)
• SLOW
  after 5min... remote screen OK (ZRLE cache)
• MANUAL
  after 5min... remote screen OK (ultra2)

[Rudi De Vos]

5 minutes ....
Possible cause.

Vnc does not allow to initiate 2 connections simultanious as some parameters are global set.

service_commandline=-autoreconnect id:1234 -connect repeaterhost

First connection to viewer= repeater
Second connection= direct LAN

The problem is, that when no viewer is waiting, the repeater partly initialize the viewer connection..block second connection.
After the socket timeout period, First connection is dropped and server handle second connection.

The message rc4.key is wrong, inverted the output.
Will correct it.

[redge]

After the socket timeout period, First connection is dropped and server handle second connection.

the direct connection should be allowed instant in this case, right ?
there no security issue as my knowledge. There 2 different case without interfering the ID mode,

edit
removed comment unrelated to subject

[Rudi De Vos]

Yes it should, but i can't make it work that way.
I should have thinked about it 5 years ago...and used another protocol.

This is how it works.

server connect to repeater
repeater answer i'm a viewer
server send first init message
server keep waiting for answer
repeater can only answer if a viewer is connected
no answer..... server timeout.
server reconnect


The new nat2nat i'm working on doesn't require the pre-connect and will
do it that way.

reuploaded, rc4 info message corrected

[redge]

vncviewer 22.04 crash after message error pop up if still one connection exist (wait few second before it happen)

added
date build of vncviewer

[twagner]

Hallo rudi,

i have tested winvnc.exe 20110418 with vncviewer 20110422 and the msrc4plugin.dsm 1.2.4 with and without rc4.key.
Could it be that we don`t need a rc4.key anymore when noone exist?
But when no rc4.key exist, encryption will use a hash value generated by the vnc-password?
And the rc4.key would be used when it was generated by user and copied on both sides and in the same folder than the winvnc.exe or vncviewer.exe??
Would be great, thanks

twagner

[Rudi De Vos]

twagner,

That's exact how it works.

[YY]

Tried to use MSRC4Plugin, and found it (all version: 1.1.x or 1.2.x) is not able be working under UltraVNC 1.0.9.x.

to fix updated with new bins

But I still have the exact same issue when using the new bins ,

winvnc.exe (Apr.18 )
vncviewer.exe (Apr.22 )

Or did I have something doing wrong ??

Viewer 　　Server 　　Able To Establish Connection?
====　　　====　　==============================
10961 　　　1.0.8.2　　OK
1.0.9.x　　1.0.8.2　　OK

it's a viewer zrle issue.

But why the 1.0.8.2 server can take care this bug ?

[Rudi De Vos]

My and Redge tested the update and is works..

The problem existed only for zrle encoder ( this encoder handle encryption
a little different and depend on the used plugin)
Even without the update ,using a fixed encoder other the zrle, doesn't had the issue.

Fixed on viewer site.

[YY]

That's right.

I'm still able to repeat the error with zrle encoder.

It is weird .....

[Rudi De Vos]

YY, what's the name of the plugin "MSRC4Plugin.dsm" ?

switch for old plugins is name based...if you rename the plugin the fix doesn't work.

restested with the win32 uploaded file.
Rechecked source, seems i forfot one spot, on my test this isn't used, but
this could be the cause, spot seems to be used by autoreconnect.

viewer updates are online

[YY]

switch for old plugins is name based...if you rename the plugin the fix doesn't work.

Oh Yes, that's the cause.
For the convenience of testing, I renamed the files as MSRC4Plugin-122.dsm, MSRC4Plugin-124.dsm, etc.

This used to be working fine in the past versions of UltraVNC until now.

Frankly speaking, I really feel this is a bad idea that craft the running logic of the vncviewer by hard code the file name (MSRC4Plugin.dsm) inside the code.

Rechecked source, seems i forfot one spot, on my test this isn't used, but
this could be the cause, spot seems to be used by autoreconnect.

viewer updates are online

I will test and report later. Thanks

[Rudi De Vos]

In the past, all plugins worked the same way...

Now there are old and new and the new plugins handle the zrle
(sub encodings direct send) different then the old.

This took me weeks to find

I known using a name isn't the best way, but didn't find an easy code to detect old.

[YY]

Yes, that's really a hard job to implement new features, while keeping compatibility with old function.

Anyway, this does eliminate the problem.

May be adding a readme in the download package to remind the users that not renaming the plugin file name, or otherwise the problem that may be happened.

[pgmoney]

In the past, all plugins worked the same way...

Now there are old and new and the new plugins handle the zrle
(sub encodings direct send) different then the old.

This took me weeks to find :(

I known using a name isn't the best way, but didn't find an easy code to detect old.

This seems to work ok (after InitPlugin()) but I haven't done much testing with it yet. It still has some limitations (maybe need to read the version too) but renaming the file doesn't break it.

Code: Select all

char szDsmName[8]; //PGM
strncpy_s(szDsmName, _this->m_pDSMPlugin->GetPluginName(), 6); //PGM
if (strcmp(szDsmName,"MS RC4")==NULL) //PGM
   _this->m_pOpt->m_oldplugin=true; //PGM
else //PGM
   _this->m_pOpt->m_oldplugin=false; //PGM


[redge]

Problem signature:
Problem Event Name: APPCRASH
Application Name: vncviewer.exe
Application Version: 1.0.9.6
Application Timestamp: 4db7278e
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7b96e
Exception Code: c0000005
Exception Offset: 0001f8a5
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 4108
Additional Information 1: abcc
Additional Information 2: abcc8f7853b48d9807d6d51eb1fa5df9
Additional Information 3: abcc
Additional Information 4: abcc8f7853b48d9807d6d51eb1fa5df9

still have the bug of vncviewer 26 April crashing (and should not crash)
msrc4 1.2.4.0 on both side
pc1 winvnc vista
pc2 vncviewer win7

steps: msrc4plugin.dsm (1.2.4.0) in use in all steps)

1. pc1: winvnc system service + service_commandline=-autoreconnect id:1234 -connect repeaterhost
2. pc2: vncviewer GUI direct connect hostname to winvnc, vnc auth OK, screen OK (don't close the active connection)
3. pc2: vncviewer GUI connect id:1234 and repeaterhost ,
vnc authentication OK then show error and crash

[redge]

Problem signature:
Problem Event Name: BEX
Application Name: vncviewer.exe
Application Version: 1.0.9.6
Application Timestamp: 4db9d503
Fault Module Name: StackHash_1de1
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 6f92874b
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 4108
Additional Information 1: 1de1
Additional Information 2: 1de14467493ead87d9c6e76022441716
Additional Information 3: d09f
Additional Information 4: d09f404b6132ccb83a7d8a57ca61aec3

winvnc + vncviewer 28.04.2011

test
1. pc1 host: winvnc system service + service_commandline=-autoreconnect id:1234 -connect repeaterhost
2. pc2 client: vncviewer GUI connect id:1234 and repeaterhost , (don't close the active connection)
3. pc2 client: vncviewer GUI direct connect hostname to winvnc, vnc auth OK, alert message followed fews second later of vncviewer crash

[Rudi De Vos]

added pgmoney patch to see if this behave better.

[redge]

vncviewer + winvnc 30.04.2011 and msrc4plugin.dsm 1.2.4.0
for my part test, nothing change

error vncviewer running as application this not true at all and no firewall issue
my vnc password is correct 100% sure, no problem with SecureVNC direct and id mode

what are the change between 28 and 30 April ?
except PGMoney MSRC4 filename support from msrc4plugin.dsm --> msrc4plugin1240.dsm
not see update

[Rudi De Vos]

changes

viewer
corrected
-autoreconnect timeout (gui)

-server
-autoreconnect behaviour,
3x winvnc -autoreconnect, opens 3x connections to last settings
now it opens only one.

-server
-modified old plugin detection (pgmoney way)

[Rudi De Vos]

bad change

Code: Select all

if (_this->m_pDSMPlugin->InitPlugin())
   {
   char szDsmName[8]; //PGM
   strncpy_s(szDsmName, _this->m_pDSMPlugin->GetPluginName(), 6); //PGM
if (strcmp(szDsmName,"MS RC4")==NULL) //PGM
   _this->m_pOpt->m_oldplugin=true; //PGM

_this->m_pDSMPlugin->GetPluginName() == "unknown" and not MS RC4

plugin is new -> incorrect

pgmoney,
_this->m_pIntegratedPluginInterface
Does this only exist for the new plugins... else this could be the way to test it ?

[pgmoney]

_this->m_pIntegratedPluginInterface
Does this only exist for the new plugins... else this could be the way to test it ?

The plugin has to be loaded before the "MS RC4" string test will work...

But...

I like the following way much better, doesn't depend on any names, it only cares if the plugin can actually support the feature or not.

This is working great here... (I didn't try to see if it can be checked before loading the plugin)

Code: Select all

if (m_pDSMPlugin->InitPlugin())
{
   m_pDSMPlugin->SetEnabled(true);
   m_pDSMPlugin->DescribePlugin();
   m_opts.m_oldplugin=!m_pDSMPlugin->SupportsMultithreaded(); //PGM


Or you could use "SupportsIntegrated()" instead of SupportsMultithreaded() depending on what you really need.

Maybe just set m_oldplugin once in the actual SupportsMultithreaded() or SupportsIntegrated() routine instead of testing it so many times.

If anyone wants to test it, the signed binaries are at:
32bit http://www.advantig.com/files/vncviewer32pgm10961.zip
64bit http://www.advantig.com/files/vncviewer64pgm10961.zip

[YY]

Have tested the vncviewer32pgm10961

It worked with the MSRC4Plugin that renamed, but found having problem on following encoding:

1. Zlib (+xor) -- will crash the server.
2. Ultra -- the viewer crash itself.

The exact same problems were found on 10961 (Apr.30) viewer as well, with the un-renamed MSRC4Plugin.


Tests were done on WinXP Prof.; 10961 Server (Apr.30); MSRC4Plugin 1.2.2

[Rudi De Vos]

Correct, dammm

Server crash...
Old Plugin can't handle queue in this encoders.
Encoder queue exist only for zlib and ultra, sub encode option disabled if oldplugin is used.
Viewer crash caused by same...

Possible this explain some unexpeced crash reports..

bins updated

[YY]

Test the 10961 (May 2)

The Zlib (+xor) & Ultra issues are gone.

[racassel]

Are we correct to assume MSRC4Plugin.DSM is not compatible? Maybe put a big banner on the page and update the docs?

[Rudi De Vos]

It should be compatible, bins were updated and retested by "yy"
Just make sure that you use the same encryption plugins on both site ( viewer and server need to use the same version)