0_o

LOL, you could have started with this post saying that you already talked this issue over there. Thanks. It's always nice to read stuff that Jack, you and the rest of the old folks here write about yet it didn't calm me at all. It is as if we are all experts here, real programmers and physics/elec engs yet when it comes to security we just finished kindergarten and we heard of another big world out there from rumors.

As for the .net secure comm, I didn't go too deep into it, I simply trust the .net department when they say it is secure. I'll ask them in our next meeting. As for the certification of code in the community and inside NI... I feel very much like the CERN guy from the video. No one is concerned with security. They just check for functionality, calibration, maintainability, licenses and safety. The only solution I see is the agreement defining the limited responsibility

Thanks! Searching for that title I got to this youtube video:

This is the case. Only the server has the private key. How can you reduce the attack surface of hacking the private key from the server? This is a task for the IT and not for an app developer. ?

1. You can sniff with Wireshark but you'll understand nothing since it is encrypted as I said. 2. Not only that I don't have time to go over the code of such tools, most are password protected. I guess the question here is what do the community do when is says a tool was verified? What does NI do before it gets a tool or driver on the shop? If it only means they installed it and ran an antivirus on the folder then I can't rely on such a verification anymore. 3. Made sure Limited Liability appears in all our contracts. It was missing from some. Thanks! 4. If an ecosystem like LV decides to use a problematic toolbox and I'm taking the risk since I'm using that ecosystem then this ecosystem itself is problematic. If you put that ecosystem in comparison with other languages then the risk is not language agnostic 5. If I sold a stand alone app that can be an island disconnected from the world then this might be nice. Setup, do an image, tell the costumer to call only if the image fails or they want a new feature. However, in my case, the app controls a factory and talks with a central server that talks with a DB server. It is monolithic and thus can't turn into Lambdas at AWS and the servers are out of my control. 6. How do I get this: 2014ClaEu_Day3_03_Control System Security ????? 7. What do you think about https://aws.amazon.com/iot/?nc=sn&loc=0

The .net WCF is encrypted. You can't sniff it with wireshark. Only by checking the WCF log from the server directly. License has nothing to do with IT security. I ment that I felt free to use any BSD/MIT from VIPM yet now I'm starting to think that I should go over that code and even then it is risky. Basically I'm afraid that a tool I give to a costumer will and up as the door for a hack and I'll get sued not only for an app I wrote but for a production line stop. Security is not language agnostic as you can see in the self executing vi you talked about and their decision to use OpenSSL

I take good care that whatever is in my control is safe to a reasonable degree: The client app uses a .net secure comm to a server app that checks the request and operates on a MS SQL DB. However, I like standardization+code reuse and hate writing from scratch tools that are available and approved by the community. Till now I had to worry mainly about license types. Should I be afraid of such code more than I already do? Should I move more parts of my code to a language that takes security as a priority? Does NI take it seriously? Those where the questions behind my post since I'm not writing a small laboratory toy, I'm automating production lines.

You guys... All I wanted is to signal NI to take LV's security more seriously. Instead you started here a tutorial explaining what the real vulnerabilities are and how to exploit them. T h a n k s

Thanks for the links. It is reassuring to see that NI took action and patched it. The real issue that I wanted to see is that they care about security. Personally I'm less afraid of running malicious code. The thing that scares me is LV environment itself being vulnerable and acting as a door for a hacker accessing the computer. My code is used in the manufacture line of big companies which spend big money for security in the IT department. However, if the management computers and servers are compromised the damage is big but not as big as a manufacturing line that stopped because of a compromised automation. The damage of a hack in a power plant or a robot on Mars running LV is much greater than even the ERP of the company having to come back from backup. If you understand that then LV should be made much more secure than regular programs.

A co worker of mine had the hobby of embedding stuff and make LV behave in unexpected ways. It is not that I'm a scared noob. The only thing that bothered me in the article is the disregard they got from NI and the question if NI takes security into account at all.

I stumbled upon the following article which is dated Aug 17: https://thehackernews.com/2017/08/hacking-labview-vi-file.html Do you know what it is about? If I understand correctly only vis that I wrote are safe to use. Maybe that is why the company's server blocks emails that contain an attached vi Thanks in advance.

Finally. That's a start. NI should have took the videos and uploaded long time ago. Thanks Mark!

Lucky you, I'm at 342. The last 2 videos are more than 2GB!!!

I found the solution. It was a resolution issue. I resized x2 and smoothed/sharpened the image with linear interpolation and it works now. Thanks!

And yet again it is unreachable but I enjoy it so much that I don't complain. Thanks!

Another thought: LV doesn't allow you to compile code from program files. You could take the hard drive/ssd out of that computer, connect it to a different computer with LV and compile there. This way all the files will be accessible since program files is just a name now.

Can you reach the server?

It is in DataMatrix format and it should say: LOC-909A094-0014 Z650-1.25 I use OpenCV with Zxing.net instead of Vision mainly because each deploy costs about 500$ with Vision while OpenCV is free.

I'm using about the same code for QR and everything is working just fine. Lately I got rectangle DataMatrix that Zxing should be able to deal with but I have no luck. Could one of you try to run the attached image in your code and tell me if there is any success? Thanks in advance. closer1.bmp

Just a thought... try running LV as admin after first upgrading to 2017. Check to see if there are no file permission issues or password protected vis.

Yay!

This is most probably a race condition but I simply can't wait so I had to ask...

Removed TSVN and still got the crash. Sometime before the crash I got the following runtime error directing to the culprit. Thanks! I love this community

I meant execution in that paragraph. Not executable. In later paragraph I meant the executable. This line you wrote is the solution in my case I guess. I'll update the person who created that code and hope for a quick fix. Thank!

LogMAN, you are correct. Thanks! I wonder why NI's support eng that connected to my computer couldn't tell me the same? He simply searched for an incompatibility issue that could save him from dealing with the problem. I too saw those issues: 1. providers always race with the internal provider and cause problems. 2.OpenCV DLL wrapper... DLL... However, the crashes didn't happen during execution and you refer to DWarns and not DAborts. Thus, I think more in the line of memory issues from call libraries. Can you elaborate as to the reason it happens. I have several ways to check for memory issues and already saw that even when I close a reference to a dll using the call library the memory is not freed till the calling vi is closed (BD closed) and that is often the stage when LV crashes. Analyzing a video and keeping the snapshots in an array can get LV from 50MB RAM to 380 MB in no time and this is a 32bit version (2GB max RAM). From my experience the issue is FP memory usage. Even 50MB under 1 control is an issue. Why should the call library behavior be expected? Anyway to prevent it without restarting once a hour? The exe should work 24/7. I can't ask for it to be restarted for memory issues every couple of hours. Thanks in advance.