Rolf Kalbermatter

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.

VISA TCP Socket is in principle the same that you also get with the native TCP nodes. Advantages: - VISA implements more in terms of automatic message termination recognition - VISA may seem more familiar to you if you have excessive experience writing instrument drivers Disadvantages: - You need to have NI-VISA runtime installed on the target system and the according TCP passport driver. If you use the native nodes, everything is included in the standard LabVIEW runtime. For the rest the VISA Write is pretty much equivalent to the TCP Write and VISA Read is similar to TCP Read. Therefore implementation of any protocol on top of TCP/IP will be pretty much the same independent if you use VISA or native TCP.

Sorry I"m not sure what you try to say. But generally unless the function is documented in the External Code Reference Manual, calling it is certainly playing with fire Those documented functions are fairly guaranteed to not go away, and 100% sure to not suddenly change the signature (parameters and their types). The documentation also states what you have to watch out when calling this function and which parameters for instance could accept a NULL pointer if not needed. Nothing of this can be "guessed" from just the function name in the shared library export list. And even if you guess everything right, there is no guarantee at all that this function will stay in future versions, or won't change the parameters somehow, as the developer just has to make sure to update any internal code that calls this function and can rightly assume that nobody else was making use of that function as it is not documented.

Well the function documentation has been there since LabVIEW 2.5. There was even a separate printed manual just for them (and a chapter or two about writing CINs). The documented use of these functions is to call them from external code, originally from CINs and later from DLLs. Officially there is no documentation that I can remember that states that the Call Library Node can be used to call these functions by using LabVIEW as library name. As ensegre writes, he is aware that especially here on Lava it is sort of common knowledge among people who care, that this possibility exists, but it would seem to me that he looks for a more official source for this that comes in some way from NI. As mentioned I'm not aware of such an official statement in any documentation that could be attributed to NI or an employee that speaks for NI. So he will probably have to live with the supporting facts that make this a long standing, stable and unlikely to disappear feature that is known in the developer community outside of NI. As long as you call the documented LabVIEW manager functions, knowing what you are doing (calling MoveBlock() with bad parameters is for instance a serious hazard and the nature of the Call Library Node has no way to protect you from shooting in your foot with a machine gun!) there is nothing that could prompt NI to remove this feature from LabVIEW classic. It may be present or not in NXG for various involved reasons.

Well, this may be not an official NI document but it is an example being published over 12 years ago. It sort of documents the use of the LabVIEW keyword in the Call Library Node as library name, to refer to the internal LabVIEW kernel functions. It is also used in various places in VIs inside vi.lib, so not very likely to change over night either. The fact that you could refer to the LabVIEW kernel functions through use of this keyword is more or less present since the Call Library Node was introduced in LabVIEW around 5.0. Changing this now would break lots of code out there, which either inherited some of those password protected VIs from vi.lib or custom made libraries that were created by various people. I'm personally not really to much concerned that this would suddenly go away. How and if it is supported in LabVIEW NXG I haven't looked at yet, but unless you want to be NXG compatible too with your library, which I suppose will impose quite a few other more important challenges than this, I would not bother.

I find that a bit unwieldy, but could go for the 60 weeks year, with 6 days per week and no designated weekend, but rather a 4 day work shift. It would also solve some of the traffic problems at least to some extend as only 2 third of the population would at any moment be in the work related traffic jams, and 1 third in the usually on different times and different locations occuring weekend traffic jams. And the first Deci calendar was the French Republican calendar, but it was very impractical and hard to memorise, with every day of the year having its own name. Napoleon abolished it quickly after taking over power, and not just because it was not his own idea :-).

One extra tidbit: The Timestamp fractional part is AFIK actually limited to the most relevant 32 bits of the 64 bit unsigned integer. For your situation that should not matter at all as you still get a resolution of about 0.1 ns that way. Also while the Timestamp allows a range of +- 263 or +-10E19 seconds (equals ~3*10E12 or 3 trillion years) from the LabVIEW time epoch, with a resolution of ~0.1ns, 99.9% is not even theoretical useful since calendars as we know it only exist for about 5*10E3 years. It's pretty unlikely that the Julian or Gregorian calendar will still be used in 1000 years from now.

I also have a method to propose: U64 Nanoseconds to LabVIEW Timestamp.vi

Nope sorry. Somewhere between transfering that image to the LAVA servers and then back to my computer something seems to have santized the PNG image and removed the LabVIEW specific tag. The image I got onto my computer really only contains PNG data without any custom tags. The same thing seems to happen with the snippet from my last post. I suspect something in Lava doing some "smart" sanetizing when downloading known file formats, but can't exclude the possibility of a company firewall doing its "smarts" transparently in the background. Hope that Michael can take a look in this if snippets have been getting sanitized on Lava or if it is something in our browsers or network. I attached a simplified version of my VI for you. C String Pointer to String.vi