Jump to content

Operands write protect


dak

Recommended Posts

Hello everybody,

 

I would like to ask you if there is possibility to protect operands when using .NET driver.

For monitoring PLC it is sufficient to use read commands.

I tried use SB 140 to protect operands, but still I can write any value to any operand

(it is also possible to connect without knowing PLC name).

This is security problem...

Thank you for any idea.

With my best regards

David

Link to comment
Share on other sites

Hi, the .Net driver does not supply any way of write protecting operands, since the PLC itself doesn't support it.

The .Net driver only implements the API that are published in Unitronics website.

Unitronics supplies the source codes of the .Net driver, free or charge, so you can implement the feature that you want (reading SB 140 before committing your write requests).

Before commiting the ReadWrite requests, read the value of SB 140, and if the bit is set, then remove the Write Requests from the readwrite requests array.

You, as a programmer, can also do it in your code.

 

As for SB140, its actual purpose is to allow Read-Only remote access, meaning, when using Remote Access/Remote Operator to control the PLC, you will only see the screen of the PLC, and touch events and keyboard events will be ignored by the PLC.

 

 

Yes, the .Net driver allows you to connect to the PLC without supplying a PLC name.

The GetPLC factory has 2 flavors, with and without a PLC name, meaning: this is not a bug, but a feature. We actually use both for different needs.

(I specifically use it a lot, if for example, I want to spawn another connection to the PLC, then I take the original channel of an already existing PLC, and create a new PLC object)

The reason PLC name was added on the first place was not a security problem, but a way of identifying/verifying that the PLC you work with is actually what you meant (this is very important when working with Ethernet).

 

If the original reason would have been a security then:

* The user would not have been able to see the PLC name within the Info 

* The PLC could not have been read using a PCOM

* For establishing a connection to the PLC, the PLC would be validating the PLC name, and not the other way around

* The PLC would ignore connections if wrong PLC name was sent

 

All of the above is not true for PLC name, but very true on "Upload Project" when it is password protected (The PLC would validate the sent password and would physically deny access  to the flash area where the Project backup is stored at)

Link to comment
Share on other sites

Dear Saragani,

thank you very much for your detailed explanation and your time to help me.
Unfortunately I can not anymore use PCOM protocol (.Net driver). Any 3rd party application can misuse the protocol and set any

value to the critical operands during the PLC process. As long as there is not System Bit in PLC for operands write protection,

any connection via PCOM is dangerous for application in PLC.

Thank you again for your fast reply
Have a nice weekend.

With my best regards
David

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...