Rolf Kalbermatter

Ohh I'm not saying that the pre/post build steps should be removed. Just that it shouldn't be necessary to use them to install 32 or 64 bit shared libraries depending what LabVIEW version you install into.

Well no menu editor in what I have. I find menus quite important to use but way to infrequent to create to have felt I would want to spend lots of time into this. I did add a feature to allow for 32 bit and 64 bit shared library support but as I do actually rely on VIPM to be able to install the created package, couldn't quite go all the way as I had wanted. The VIPM format is missing a specific flag that could work to flag files to be used in a specific bitness mode and the platform string as used in OpenG and hence VIPM is to much massaged to allow that distinction. My suggestion to add such a feature to VIPM was not really considered as it was considered to obscure. Instead I had to rely on a Post Install VI that will then rename the according shared library to the required name and delete the unneeded one. Basically the OpenG platform consisted of several tools. First there was the Package Builder, which as already mentioned is a glorified ZIP file builder. OpenG packages and VIPM files too are in fact simply ZIP files with one or more specific files in the root, one of them being usally an INI type spec file specifying the contents of the package and the rules to use when installing it, another one being the package bitmap and optional license text. The rest are folders corresponding to file groups that need to be installed to the target system according to the rules in the spec file. The VIPM spec file contains a few additional optional items to support some of the later VIPM features. Then there was first an OpenG Application Builder project hat eventually morphed into the DEAB tool which was the OpenG variant of an application builder. It also allows renaming of file hierarchies to create source distributions with file prefix or postfix additions before NI really supported such a feature. This was the tool used by the OpenG libraries to namespace the library files by adding the __ogtk postfix to each filename. Creating an OpenG package simply meant running first the DEAB tool to rename/relink the source VIs into a new location that was meant to mirror the final VI hierarchy on the target system, then running the package builder task to turn this into an OpenG package. It seems the OpenG SVN repository contains a new sub project Builder, that is another wrapper that tries to automate the execution of the DEAB task and the package builder in a very simple UI. My attempt was to basically extend the old Package Builder UI to allow some additional configuration options that could be used to create the necessary data structures to run the DEAB tool programmatically before invoking the package step. But in comparison to VIPM this UI is more involved and for many users probably less intuitive. The main GUI is found in "source/GUI/OpenG_Package_Builder.vi" OpenG Package Builder V2.0.zip

It's nothing to fancy. I added a few things to the UI to support more features and in preparation of adding the VI renamining/relinking step that was done seperately in the OpenG DEAB tool before calling the OpenG package builder. But I never got around to really add the deab part into the package builder. It's kind of extra difficult as the DEAB compononent doesn't currently support newer features like lvclass and lvlib at all and of course no mallable VIs etc. I can post what I have somewhere, but don't get to excited.

Realistically that might mean that there is no new LabVIEW feature in many years! So I doubt that this rigorous specification is ever reasonably considered.

I don't think it can be LAVA's responsibility to verify licenses infringement, copyright and whatever issues of such code. Obviously the code review process should take care about glaring problems, but it can not be the idea that LAVA could and should be responsible about guaranteeing that no such issues exist. If we require that we can stop right now because we can't do that, even if we hire several full time lawyers . By submitting code for the CR each submitter basically needs to state that he is providing the code according to the the license requirements that he selected and that to the best of his knowledge there are no copyright or license issues. Anything more than that is simply not workable. As to providing a LAVA repository I don't think we would need a special OS/hardware system other than some internet accessible FTP/HTTP storage, which I'm sure the existing LAVA server could do, except for the additional server space that might require. I'm not sure about the exact internal workings of VIPM and it seems that even packages released on the OpenG Sourceforge site don't automatically are picked up, though it shouldn't be very difficult to do that. (Yes I did some package update in the last year and posted it to the OpenG repository but it still doesn't show up in VIPM). It seems that even for that repository there is some manual step involved from JKI to add a package to some list that VIPM then will be able to see. or maybe I did something wrong when posting the package on sourceforge. If JKI would then add this LAVA repository as another default repository besides the Tools Networks and OpenG sourceforge repository, we would be all set even without owning a Pro license of VIPM. And I might be even persuaded to get our company to commit to a few VIPM Pro licenses then .

Yes, and therefore it is courtesy to mention that you posted elsewhere as well. Not everyone frequents both sites and so it is helpful if they can look at the other post and see if the answer they have may already have been given there. Also in the future when someone has the same problem he may come across one post and only see what was answered here, while there might have been other helpful answers in the other thread. You may feel that it is redundant to mention this and maybe counterproductive as people may be less inclined to answer your post if they know you posted elsewhere too, but believe me the people who are likely to answer you either here or on the NI forum will be not noobies who dismiss a post because it has been posted elsewhere, but will want to look at the other thread and if the information they have is not mentioned there, will gladly share it with you. But some of the really valuable posters might get annoyed at seeing the same question on different boards without any mentioning of crossposting and might decide to not bother about spending time to answer your problem even if they might have helpful information. After all we all do this on a volunteering base with no obligation other than goodwill to share the information we know with anyone on these fora. If you don't get the answer you look for, it won't be because you mentioned that you had crossposted, but instead because nobody else who frequents any of these board has the answer or is not allowed to share it because of some NDA agreement. And yes there are manufacturers who believe that their product is so super special that nobody should be allowed to know how to communicate with it, and if they ever share any information with some specially valued customer, that they need to hold them at gunpoint with a lengthy legal document about sharing that super confidential information. Generally I think it hurts them more than anyone else, but it is their choice. They seem to be based in India and don't mention any international sales or technical support offices, so it may be indeed hard to get any information from them if you are not located in India yourself. The site also looks kind of last century in some ways and they do seem to be secretive even about pricing information, so I'm not sure if it is the best supplier for such hardware. We have generally quite good experience with Watlow and Eurotherm devices and they are not difficult about sharing technical information about their products.

It may be valid. The math function may behave badly on wrong or empty data sets. Sure you could detect the actual input arrays to be of valid sizes etc., and a solid algorithme definitely should do that anyways, but the error in is an immediate stop gap to trying to process on data that may have been not even generated because of an error upstream. I understand that not every function needs an error in/error out but I prefer to have a superfluous error cluster on a VI that may never really be used for anything but dataflow dependency than none, and later when revising the function and having to add one anyhow, having to go everywhere and rewire the function.

If you happen to use these VIs in LabVIEW 64 bit you will certainly have to review them and make sure that all Windows handle datatypes such as the HWND used in those functions are configured to be pointer sized integers rather than 32 bit integers (and change the according LabVIEW controls to be of type 64 bit integer).

No no. Gnu C on Windows has no significant use. You might need it if you use one of the Open Source C compilers such as DevC or or MinGW or Cygwin, which are based on gcc but Visual Studio is based on Microsoft Visual C and will never use the GNU C library! It might work with the Visual Studio 2003 runtime installer but there is no 64 bit version for that. Visual Studio 2005 was the first version to properly support creating 64 bit applications. If it works depends on what Visual Studio version was used to create the installer executable. You shouldn't need to install the entire Visual Studio software, just the redistributable Visual C runtime library for the correct Visual Studio version.

8.5 came out in 2007 and 8.2 in 2006, so they and their installer may or may not be built in Visual Studio 2005. There is a good change that they were in fact created using Visual Studio .Net 2003 or even Visual Studio .Net 2002 though that last one doesn't make to much sense as it was pretty flaky. So you may need to specifically add support for the Visual Studio 2003 C runtime library to your system. Starting with Visual Studio 2002 Microsoft deviated from the previous principle that all Microsoft C compiled programs were referencing the standard MSVCRT.dll that was also part of the Windows installed components. Instead each created application was using its own version of the C runtime library depending on the Visual C version used. Those C runtime versions often are installed in a standard Windows installation as many components that are distributed with Windows were created with various versions of Microsoft C (some pretty old). But it is very feasible to assume that Microsoft managed to extinguish in Windows 10 any application that still requires a C runtime library version prior to 2008. It may still be present on a fresh install of Windows 10 sometimes, depending on additional installs like video or network card drivers for instance with their own specific utilities, but it is very likely that it does not come with any Visual C 2005 support or earlier. Unfortunately it is pretty much impossible to convince Visual C to not use the version specific C runtime library. Writing a new C compiler is almost easier . The installer will of course install the C runtime library support that LabVIEW 8.2 or 8.5 will need, but in order to install the C runtime library support for the installer itself you would need an installer for the installer. A sure catch 22 situation. Only applications created in Visual Studio 6 can run on any Windows version without needing specific C runtime versions to be installed. But I'm sure Microsoft is considering ways to break that at some point

When this library was created somewhere around 2000 or so, LabVIEW was still more than 5 years away from supporting 64 bit integers in any way. So it could not be added then even if one had wanted to. And the OpenG movement has lost a bit of traction in the last 15 years or so. Nobody seems to have noticed this deficit or if they did they just added the extra cases without reporting it back. The real problem is however that these libraries, while not perfect, do work for most users good enough to not bother about putting the effort into it to update them and the original maintainers for each of those libraries almost all moved into other positions that often mean less or now daily LabVIEW programming anymore. The OpenG libraries also follow a development model that makes it difficult to push updates by other users into it and release a new version. But the according Read Key VI also has that omission, only here the fix is more complicated to perform since the VI uses the NI INI file class which still only supports 32 bit integers. So at least for the 64 bit variant something else needs to be developed and in doing so it probably would be best to change the other integer types too to use the same method.

It may not help to calm you down at all, but even many of the security experts just know barely what they are talking about. It's a special world and the really tricky part is that what is considered safe enough today is already tomorrow outright inadequate. A computer from just 10 years ago wouldn't survive even a single day nowadays when connected to the net without being compromised in some ways, and even fully up to date computer systems are under continuous attack when they are visible in any way to the big dangerous net out there. You can only hope that your network modem will keep your internal network invisible and that the modem itself hasn't been compromised in some way already. Mirai and friends don't only can be used to attack network cameras but just about any network appliance.

I think this is it. https://indico.cern.ch/event/306567/attachments/583776/803586/Why_Control_System_Cyber-Security_Sucks__CLA_2014.pptx

You can't do that! Your LabVIEW code really is equivalent to this .Net code which will definitely throw an error! int stringdata[] = {1, 2}; String string = new String(stringdata); SqlString sql = (SqlString)string; // throwing an error and String is not an SqlString in a long shot and neither is an SqlString a String, as it does not inherit from String at all. It is its own object type. Maybe .Net does some super magic behind the scenes and the C# code you wrote is valid but purely from a type compatible point of view reinterpreting the String object o as SqlString isn't a direct compatible conversion. The proper code construct would be something along the lines of: SqlString sql = new SqlString(o); In LabVIEW use the SqlString contstructor that allows to pass in a String paremeter for the initialization.

Nope! If you have the according certificate, Wireshark has an option to decrypt the SSL encrypted data stream directly into fully readable data (which might be binary or not). Obviously the client should only have the certificate containing the public key which won't make direct decryption possible and only the server should know the certificate with the private key but that is already an attack surface.

I'm pretty sure that the IPE structure where the DVR wire was directly wired from the left access node to the right access node without doing anything else with the wire (except a unbundle to get some data out of the DVR content) was already optimized by LabVIEW to be more or less a NOP (no operation) for the right access node. The only real impromvement with read-only setting is that the DVR doesn't need to be locked for the entire IPE but only for the read acces at the left access node.

The performance boost can be from more or less negligible to serious. It really depends what else you are doing on that DVR. If there is no other access to the same DVR at the same time, the gain from just locking the DVR for the value read rather than the duration of the entire IPE structure really won't matter at all. There is no other code that could be blocked waiting for the DVR and consequently nothing that could be slowed down. If you have many concurrent read only accesses to the same DVR then you will see a significant improvement. Before the read only access, each DVR IPE access had to wait for any previous IPE access to that DVR until it was finished. You could achieve similar behaviour before by just using the IPE structure to reference the necessary data in the DVR and do any further processing outside of the DVR. As such the only advantage of the read only access is that the DVR doesn't need to be accessed a second time before leaving the IPE. If there is a IPE non-read-only access to the DVR active however any read-only access still needs to wait for the write access to finish and therefore can be blocked.

I fail to see what Israel has to do with this. While I have been working with ACS controllers from LabVIEW, I only used them through the TCP/IP interface protocol that the controller provides. It's a powerful device with lots of possibilities to implement control functionality inside the controller itself in their basic like programming language (which I assume is what you show in your image). But we never got around to use gantry mode but rather implemented the coupling of the axis in LabVIEW itself and then sending according commands. So I can't really help you with this problem, also because I didn't do any of the programming on the ACS controller itself.

An application crash is IMHO a DOS. Never mind that it does obviously happen due to an actual user action (the opening of the file) rather than stealthy in the background, and I find it irrelevant in this context that LabVIEW can sometimes crash out of the blue without anyone trying to DOS it. (That explicitly excludes the crashes that I sometimes cause when testing external code libraries ) Code execution is another but as I wrote not very likely option. Buffer overflow write access errors can theoretically be used to execute some code that you loaded through careful manipulation of the file into a known or easily predictable location in memory. But that is kind of tricky to exploit and the LabVIEW nature makes it even more tricky to get any predictable memory location. Even if you manage to do that it almost certainly will only work on a specific LabVIEW version.

It is in the basic RSRC format structure of VIs and the code to load that into LabVIEW has basically not changed much since about LabVIEW 2.5. So it is safe to assume that this vulnerability has existed since the begin of multiplatform LabVIEW. I doubt that it was there in this way in the Mac only versions 2.2.x and earlier as VIs were then real Macintosh resource files and LabVIEW used the Macintosh resource manager for loading them. (Note that the Mac OS 7 from those times wouldn't even survive a few seconds of being connected to the net! It's security was by nowadays standards mediocre and its only security from modern internet attacks was its lack of a standard internet connectivity out of the box; you had to buy an expensive coax network plugin card to make it connect to TCP/IP and install a rather buggy network layer that was redesigned more than once and eventually named Open Transport, because it connected the Mac to a non-Apple only standard network ). NI puts the latest three versions before the current one into maintenance mode and only releases security patches for them, as well as making sure that driver installations like NI-DAQmx etc support those four versions. Anything older is put in unsupported status and is normally not even evaluated if a bug exists in it. If a customer reports a bug in an older version and it gets assigned a CAR, then that older version may be mentioned, but retrospective investigations in older than the last 4 versions is officially not done by NI. This threat is assigned on the nist.gov link that I mentioned a Common Weakness Enumeration 787 status, which is an out of bounds write access, or buffer overflow write error. As such it is pretty easy to use as a DOS attack and potentially also as a code privilege execution escalation but those are tricky to exploit and LabVIEW makes them even trickier to exploit due to its highly dynamic memory management scheme.

I didn't check for linger but there are several others that definitely differ.

It depends how you do it. There are many registry hacks to enable and disable various features also for Winsock. That way you force it indeed even for all network interfaces. But the setsocketopt() works on a socket (the underlaying socket driver handle that a LabVIEW network refnum encapsulates). That way you only change the option for that specific network connection.

Well, LabVIEW is a software development platform just like Visual C and many other development environments are too. Should Visual C disallow creation of code because you can write viruses with it? I can send you a Visual C project and tell you to compile it and if you are not careful you just compiled and started a virus. The project may look even totally harmless but containing precompiled library files that disguise as some DLL import library, and/or even a precompiled dll that you absolutely need to talk to my super duper IOT device that I give away for free . Will you use diligent care and not run that project because you suspect something is funky with this? The only real problem a LabVIEW VI has is that you can configure it to autostart on load. This is the only real problem with VIs. This is a feature from the times when you did not have an application builder to create an executable (and in 1990 the security awareness was much lower, heck the whole internet at that time was basically open, with email servers trusting each other blindly that the other won't be abused for malicious or even commercial reasons). If you wanted a noob to be able to use a program you wrote you could then tell him to just click that VI file and LabVIEW would be started, the VI loaded and everything was ready to run, without having to explain that he also should push that little arrow in the right upper corner just under the title bar. The solution to this is to NOT click on a VI file that you do not know what it contains to open it but instead to open an empty VI and drag the VI onto its empty diagram. That way you can open the VI diagram and inspect it without causing it to autostart. Removing the autostart feature in later LabVIEW versions would probably have been a good idea but was apparently disregarded as it would be a backwards incompatibility. Also the article on The Hackers News site dates from August 29, 2017 (and all the links I can find on the net about CVE 2017-2779 are dated between August 29 and Sebtember 13). They may have gotten a somewhat ignorant response from a person at NI, or they might not! I long ago stopped to believe articles on the net blindly. This site has a certain interest to boost about their activities and that may include putting others into a somewhat more critical light than is really warranted. Here is a more "official" report about the security advisory (note that the link on the The Hackers News report has gone stale already), and it mentions on September 13, 2017 the official response from NI, although the NI document has a publish date of September 22, 2017, probably due to some later redaction of it. If I remember correctly the original response contained an acknowledgement and stated that NI is looking into this and will update the document once they determined the best cause of action. So on September 22, 2017 they probably updated that document to state the availability of the patches. Note that the blog post from Cisco Talos about this vulnerability, which is cited as source of the article on The Hackers News, but without providing any link to the actual Cisco Talos blog post, does contain the same claim that NI does not care, but has an updated notice from September 17, 2017 that NI has made an official response available. The security report from Cisco Tales itself does not mention anything about NI not caring! It does however state that the vulnerability was apparently disclosed to NI on January 25, 2017, so yes there seems to have been a problem at NI not giving this due diligence until it was publicly disclosed. I would think that the original reaction was apparently lacking but the reaction time of less than one month after the sh*t hit the fan, to produce a patch for a product like LabVIEW is actually pretty quick. And that if someone at The Hackers News really would care about this type of reports rather than just blasting others, they would have found some time to edit that page to mention the availability of patches, contrary to their statement that NI doesn't care!

But watch out! The socketoptions are NOT compatible between WinSock and Linux. There are even differences in the actual numeric values for the SOL_ and/or SO_ constant names between different Unix implementations. And some of the options have different datatype between Windows and Unix.

As crossrulz said, definitely use something like Wireshark to debug the actual communication. VISA supports TCP socket communication on all platforms it is available. But installaiton on Linux may be not always seamless. I always prefer to use the native TCP nodes whenever possible. VISA is for me only an option if I happen to write an instrument driver for an instrument that supports multiple connections such as serial and/or GPIB together with TCP/P.