Variant Posted January 13, 2009 Report Share Posted January 13, 2009 Can anyone explain this labVIEW exe ini file key Setting "server.tcp.enabled ". Quote Link to comment
Antoine Chalons Posted January 13, 2009 Report Share Posted January 13, 2009 QUOTE (Variant @ Jan 12 2009, 10:07 AM) Can anyone explain this labVIEW exe ini file key Setting "server.tcp.enabled ". Well there is not much to say.. Check out the http://wiki.lavag.org/LabVIEW_configuration_file/VI_Server#server.tcp.enabled' rel='nofollow' target="_blank">LabVIEW Wiki on LabVIEW configuration file. This key will be present in the INI file beside your EXE when TCP/IP is checked in your LabVIEW options (Tools >> Options... >> VI Server: Configuration) ; I think you need this to be activated only if your EXE has to communicate with another application through TCP/IP. [EDIT] As Ton pointed : You need this to be activated if you want your VI Server to be accessible to other applications. Hope this helps. Quote Link to comment
LAVA 1.0 Content Posted January 13, 2009 Report Share Posted January 13, 2009 According to the LabVIEW wiki this refers to the VI server enabled/disabled setting. See LabVIEW_configuration_file/VI_Server#server.tcp.enabled Ton QUOTE (Antoine Châlons @ Jan 12 2009, 10:20 AM) ... I think you need this to be activated only if your EXE has to communicate with another application through TCP/IP.Hope this helps. Well Antoine you are fast. But, this only needs to be activated if you want to expose VI server, for normal TCP/IP connections you don't need it. Ton Quote Link to comment
jdunham Posted January 13, 2009 Report Share Posted January 13, 2009 [edited:] Jeepers, way too slow! Quote Link to comment
Antoine Chalons Posted January 13, 2009 Report Share Posted January 13, 2009 QUOTE (jdunham @ Jan 12 2009, 10:24 AM) Jeepers, way too slow! That's because you took time to make a screen shot With our 3 posts I think we've come to a pretty comprehensive answer in a limited amount of time ! :thumbup: Quote Link to comment
LAVA 1.0 Content Posted January 13, 2009 Report Share Posted January 13, 2009 QUOTE (Antoine Châlons @ Jan 12 2009, 10:30 AM) With our 3 posts I think we've come to a pretty comprehensive answer in a limited amount of time ! :thumbup: http://www.stackoverflow.com' rel='nofollow' target="_blank">StackOverflow eat your heart out. Ton Quote Link to comment
Variant Posted January 14, 2009 Author Report Share Posted January 14, 2009 I need to know the internal details like, whether we are making the exe as a server or VI server opens an option for the exe to be accessed by the other applications. Quote Link to comment
Rolf Kalbermatter Posted January 15, 2009 Report Share Posted January 15, 2009 QUOTE (Variant @ Jan 13 2009, 06:38 AM) I need to know the internal details like, whether we are making the exe as a server or VI server opens an option for the exe to be accessed by the other applications. Can you be a bit more clear with your question? I for one still wonder what you meant by this sentence. Rolf Kalbermatter Quote Link to comment
jdunham Posted January 15, 2009 Report Share Posted January 15, 2009 QUOTE (Variant @ Jan 13 2009, 03:38 AM) I need to know the internal details like, whether we are making the exe as a server or VI server opens an option for the exe to be accessed by the other applications. Rolf is right, it would be helpful to know more about what you are asking. If you are asking if this is a security vulnerability, then yes. If you enable the VI Server then LabVIEW will listen on port 3363. If your firewall lets that port through, then other machines can detect that your computer is listening. If another computer connects to VI Server, and that computer can speak the VI Server protocol, then it can run any VI on your system if it knows the name. I don't think LV scripting will work through this connection. I don't think you could use this connection to build new VIs on the target system which could do very bad things like list or read or delete the contents of your hard drive without specific advance knowledge of VIs existing on the remote system. (That's an interesting discussion on its own, especially if I am wrong). If you build a separate EXE, you would have to enable VI Server for that application in its own INI file in order for that to be exposed or vulnerable. If that wasn't the thrust of your question, then you could try again. Quote Link to comment
Variant Posted January 16, 2009 Author Report Share Posted January 16, 2009 QUOTE (jdunham @ Jan 14 2009, 05:21 PM) If you build a separate EXE, you would have to enable VI Server for that application in its own INI file in order for that to be exposed or vulnerable.If that wasn't the thrust of your question, then you could try again. Ok this is what I wanted, When I build an LabVIEW exe. In that exe ini i enable the server.tcp.enabled = True and assign it with some other port 5346. (Please correct me if my understanding is wrong). Doing this will actually make my exe as server and listens for clients to connect. Quote Link to comment
Variant Posted January 16, 2009 Author Report Share Posted January 16, 2009 QUOTE (jdunham @ Jan 14 2009, 05:21 PM) If you build a separate EXE, you would have to enable VI Server for that application in its own INI file in order for that to be exposed or vulnerable.If that wasn't the thrust of your question, then you could try again. Ok this is what I wanted, When I build an LabVIEW exe. In that exe ini i enable the server.tcp.enabled = True and assign it with some other port 5346. (Please correct me if my understanding is wrong). Doing this will actually make my exe as server and listens for clients to connect. Quote Link to comment
LAVA 1.0 Content Posted January 16, 2009 Report Share Posted January 16, 2009 QUOTE (Variant @ Jan 15 2009, 04:28 AM) (Please correct me if my understanding is wrong). Doing this will actually make my exe as server and listens for clients to connect. Yes but only to VI server connections (with http://zone.ni.com/reference/en-XX/help/371361E-01/glang/open_application_reference/' target="_blank">Open Application), it is not some magic token to set up a random data server connection. Ton Quote Link to comment
LAVA 1.0 Content Posted January 16, 2009 Report Share Posted January 16, 2009 QUOTE (Variant @ Jan 15 2009, 04:28 AM) (Please correct me if my understanding is wrong). Doing this will actually make my exe as server and listens for clients to connect. Yes but only to VI server connections (with http://zone.ni.com/reference/en-XX/help/371361E-01/glang/open_application_reference/' target="_blank">Open Application), it is not some magic token to set up a random data server connection. Ton Quote Link to comment
jdunham Posted January 16, 2009 Report Share Posted January 16, 2009 QUOTE (Ton @ Jan 14 2009, 09:22 PM) Yes but only to VI server connections (with http://zone.ni.com/reference/en-XX/help/371361E-01/glang/open_application_reference/' target="_blank">Open Application), it is not some magic token to set up a random data server connection. Well you can connect to it with Telnet (this is useful for testing your connectivity and checking your firewalls), but after you send it a few keystrokes and it realizes you don't speak VI Server, it will disconnect. If you want a server like Ton is mentioning, you have to write code using the TCP routines in vi.lib, and it has nothing to do with the INI file. You can listen on any port you want, but you have to write all the code to receive data and send responses. The LabVIEW Examples are a good place to start. Quote Link to comment
jdunham Posted January 16, 2009 Report Share Posted January 16, 2009 QUOTE (Ton @ Jan 14 2009, 09:22 PM) Yes but only to VI server connections (with http://zone.ni.com/reference/en-XX/help/371361E-01/glang/open_application_reference/' target="_blank">Open Application), it is not some magic token to set up a random data server connection. Well you can connect to it with Telnet (this is useful for testing your connectivity and checking your firewalls), but after you send it a few keystrokes and it realizes you don't speak VI Server, it will disconnect. If you want a server like Ton is mentioning, you have to write code using the TCP routines in vi.lib, and it has nothing to do with the INI file. You can listen on any port you want, but you have to write all the code to receive data and send responses. The LabVIEW Examples are a good place to start. Quote Link to comment
Rolf Kalbermatter Posted January 16, 2009 Report Share Posted January 16, 2009 QUOTE (jdunham @ Jan 14 2009, 11:21 AM) Rolf is right, it would be helpful to know more about what you are asking. If you are asking if this is a security vulnerability, then yes. If you enable the VI Server then LabVIEW will listen on port 3363. If your firewall lets that port through, then other machines can detect that your computer is listening. If another computer connects to VI Server, and that computer can speak the VI Server protocol, then it can run any VI on your system if it knows the name. Actually you can limit both the VIs that will be accessible over remote VI server connections as well as the IP addresses that can connect to the server. The syntax for the keys is not documented nor easily described in full, but configuring everything in the LabVIEW options and copying the keys over to a built applications ini file is best. QUOTE I don't think LV scripting will work through this connection. I don't think you could use this connection to build new VIs on the target system which could do very bad things like list or read or delete the contents of your hard drive without specific advance knowledge of VIs existing on the remote system. (That's an interesting discussion on its own, especially if I am wrong). There are a lot of VI server operations (including almost all scripting) that is not even present in a built application. Many other methods and properties are also not accessible at all. And with above settings you can tighten it up so much that there is really not much an attacker can do other then sending it malformed packages to try to make it crash. Rolf Kalbermatter Quote Link to comment
Rolf Kalbermatter Posted January 16, 2009 Report Share Posted January 16, 2009 QUOTE (jdunham @ Jan 14 2009, 11:21 AM) Rolf is right, it would be helpful to know more about what you are asking. If you are asking if this is a security vulnerability, then yes. If you enable the VI Server then LabVIEW will listen on port 3363. If your firewall lets that port through, then other machines can detect that your computer is listening. If another computer connects to VI Server, and that computer can speak the VI Server protocol, then it can run any VI on your system if it knows the name. Actually you can limit both the VIs that will be accessible over remote VI server connections as well as the IP addresses that can connect to the server. The syntax for the keys is not documented nor easily described in full, but configuring everything in the LabVIEW options and copying the keys over to a built applications ini file is best. QUOTE I don't think LV scripting will work through this connection. I don't think you could use this connection to build new VIs on the target system which could do very bad things like list or read or delete the contents of your hard drive without specific advance knowledge of VIs existing on the remote system. (That's an interesting discussion on its own, especially if I am wrong). There are a lot of VI server operations (including almost all scripting) that is not even present in a built application. Many other methods and properties are also not accessible at all. And with above settings you can tighten it up so much that there is really not much an attacker can do other then sending it malformed packages to try to make it crash. Rolf Kalbermatter Quote Link to comment
Variant Posted January 16, 2009 Author Report Share Posted January 16, 2009 QUOTE (Ton @ Jan 15 2009, 06:22 AM) Yes but only to VI server connections (with http://zone.ni.com/reference/en-XX/help/371361E-01/glang/open_application_reference/' target="_blank">Open Application), it is not some magic token to set up a random data server connection.Ton I have the following questions: 1 Which means using open application reference I will be able to communicate with my exe and this communication is done through VI server. So VI server manges different application with TCP server enabled. 2 "Only VI server connections" Will I not be able to communicate with any other application other than labVIEW. if this is wrong what do you mean by only VI server connections. 3 Lets say i have two exes running with different ports TCP server enabled. How does it work? Can you give me the levels of hierarchy of this communication. like How this whole flow works( Machine name--> ..-->Port--> Application). please explain this I want to understand clearly and 100% Quote Link to comment
Variant Posted January 16, 2009 Author Report Share Posted January 16, 2009 QUOTE (Ton @ Jan 15 2009, 06:22 AM) Yes but only to VI server connections (with http://zone.ni.com/reference/en-XX/help/371361E-01/glang/open_application_reference/' target="_blank">Open Application), it is not some magic token to set up a random data server connection.Ton I have the following questions: 1 Which means using open application reference I will be able to communicate with my exe and this communication is done through VI server. So VI server manges different application with TCP server enabled. 2 "Only VI server connections" Will I not be able to communicate with any other application other than labVIEW. if this is wrong what do you mean by only VI server connections. 3 Lets say i have two exes running with different ports TCP server enabled. How does it work? Can you give me the levels of hierarchy of this communication. like How this whole flow works( Machine name--> ..-->Port--> Application). please explain this I want to understand clearly and 100% Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.