Jump to content

WireFlow releases security dongles for all LabVIEW targets

Recommended Posts

WireFlow releases the first Security suite software that is natively supported on any LabVIEW platform with an available USB port, including VxWorks and Pharlap based Real-Time targets.


The security suite addresses IP protection issues for the LabVIEW platforms; not only does it add copy protection, but also enables user identification and feature control.




To learn more, please visit http://www.wireflow.se/news/SecuritySuite_news


/The WireFlow Team

Edited by Mellroth
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.

  • Similar Content

    • By smidsy
      I would like to implement a Run-time license checking mechanism that will enable or disable some parts of my LabVIEW API depending on a license status. 
      After reading numerous discussions here on the forum (We need a new password cracker :( , Low level VI data editor (warning: not for production use!) , I found some more hidden INI keys, Password Security in LabVIEW) I realised few things:
      - reverse engineering in a LabVIEW-related field seems to be a doable task for some smart people, 
      - password protection on block diagrams does not protect your IP, it is more of a "read-only" or a "private property" sign,
      - removing block diagrams or compiling it into an executable are the ways to go, and finally,
      - there are few tools out there, that seem to have a potential to "unflatten" VI data and modify/extract its data even without block diagrams.
      Back to my task. I decided to remove block diagrams. Inside my protected VI I call an external library that does the actual license checking. So the code only gets this status and returns it back to other VIs. Then the VIs do not perform their main functions, and the user gets an error. 
      Do you think I am safe here?
      Is it possible to extract sensitive string information out of my VIs (without BD)?
      Is there a way to change wiring rules/connector pane on my VIs?
      Should I worry about DLL hijacking? 
      Does NI have some kind of a tutorial for protecting your run-time API? 
      How do you protect your API knowing all that? Do you sleep well?
    • By A Scottish moose
      Hey everyone!
      I'm working on a test system right now that requires the operators to sign the test reports.  In the previous generation this was done by the print/sign/scan method.  During one of the meetings it was mentioned that getting around this requirement would be nice.  I recommended we look into a digital signature pad and see what would be required to integrate one.  I've been thinking about ordering one and just giving it a go but I thought first I'd ask and see who has done this with LabVIEW before.  I know someone has, I just haven't found the documentation online yet.  
      Here's how I expect it would go:
      1. The software prompts the user to sign at the end of the test.  
      2. The signature pad saves the image location to the hard drive or provides it to the client through an API (any experience on how this usually works is appreciated) 
      3. My software would aquire the image and save it to a named range in Excel using the report gen toolkit.  Currently my report writing tool of choice.  
      4... Profit!
      Does this theory match with reality?  What are your experiences?  Do you have any models you prefer to work with?  
      I dug for a few minutes on this and didn't come up with much so perhaps a discussion on the subject is valuable.
      Thanks for the help!
    • By Gary Armstrong
      LV2016 64-bit
      I have inherited a LabVIEW Interface that talks thru a USB2 Interface to a micro-Controller at 921,600 baud.
      This opens a new world of possibilities as USB2 can handle data at much higher rates than a typical RS232 interface.
      I have been tasked with rewriting the LabVIEW code as it is difficult to maintain.  I have an application that will talk to the uC at 230 kbaud but can't attain the 921,600 baud. I have tried copying the pertinent VIs from the supplied code into my app but still can not attain 921,600 baud. Plus I don't have a serial line analyzer capable of handling USB2, so I can only trial and error with the uC. Is there a setting I have to do in LabVIEW to allow serial communications at the higher rates? At the moment, I am trying to get the Find Controllr VI to work. I have included the support VIs for the Find Controllr.vi. The Find Controllr VI attempts to find the correct port and baud rate and then obviously communicate with the uC.
      Find Controllr.vi
      Packet TR.vi
      Get Available Ports.vi
      Serial Data.vi
      Check For Packet.vi
      Open Port.vi
      Create Packet.vi
      Extract Packet ID.vi
      PTI CRC.vi
    • By Yohann
      I'm currently encountering a problem when accessing FPGA indicator with "Reading/ writing a control" node
      The FPGA part acquires data every 10µs
      The RT part Read the indicator every 2000µs
      But when Running the VIs, I see that the elapsed time between 2 Readings of the indicator change from one iteration to another
      Can someone help me?
    • By Tripmeister
      Hey guys,
      I'm trying to do some scripting on a Realtime-VI wich uses the FPGA Interface "Read/Write Control". I open a Reference to a VI containing a Read/Write Control, and when scrolling through the BD-Objects I find it with the class-name "nirviReadWriteControl".
      I used the "to more specific class"-VI to check wich class i can cast it to, and i tracked it down to be child of the GObject->Node Class. But i can't cast it to any of the childs offered in the class specifier constant.
      I also found out, that the "nirviReadWriteControl" is a xnode.
      I have never worked with those, is there a way to access theyr methods (I think they're called "abilities" for xnodes)?
      The goal of the application is to make the Read/Write Control display all available FPGA FP-Elements, and connect Controls/Indicators to them.
      There is the same Problem with the "Open FPGA Reference"-Node (Classname "nirviOpenFPGA").
      I really hope somebody dealed with the xnodes a bit and can help me programmatically controlling them!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.