Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/28/2012 in all areas

  1. Protecting the password is important but the problem doesn't end there. Say my LabVIEW built application queries the OS to decide if the current user has some privilege at launch time. How should my code remember that fact? Do I put it in a LabVIEW global variable boolean called "IsAdmin"? Guess where my weak link is. Forget about attacking the password. If I can find the right byte, I can turn any user into an admin. Or even before that, what if I can attack the code the decodes the answer from the OS. Any application that runs on the users machine and internally makes decisions about allowable operations is susceptible to in memory attacks (through debuggers or code insertion). There are a few LabVIEW-specific things you can do to reduce this exposure. Subroutine priority - Subroutines are less exposed through VI server. Inline VIs - Inlining of security critical VIs means there is no longer a single bottleneck that the user can attack to gain access to multiple pieces of functionality. Each piece must be attacked separately. Request Deallocation node - This node causes all temporary allocations for a VI to be disposed at the end of a subVI's execution. This does not necessarily overwrite the memory but could help. (I'm not sure what happens if you try to use this in a VI that is set to inline.) If we apply these to the issue of remembered state, then you might create inline VIs that know how to get and set into some obscured form of remembered state. Of course that just moves your weak link to be the algorithm used to obscure your state.
    2 points
  2. During my time at NI Week I decided to bring my video camera and record the presentations, Tech Theater and LAVA BBQ. Please see this link for Video downloads The IT department of my company was also kind enough to setup a ftp server so I could share them with the community It took a while to figure out how to compress the 5GB HD .mts files to a more distributable avi format but with the help of crelf I finally got them compressed and uploaded to the ftp sites. Vi Engineering and Distek Integration have also volunteered their ftp servers to help distribute the videos Thank you Chris and Ed for your help. The avi files can be downloaded from one of the 3 ftp sites they range in size from 150 to 300MB. I would strongly recomend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple viedos the ftp client makes things much easier. To download videos from Distek they are requiring you to use an ftp client. My ftp client of choise is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found here The video files are .avi and have been compressed using DivX If you player isn't able to play the videos you will need to install the free DivX codec found at http://www.divx.com/...plus/codec-pack to access the videos via Use this log in information ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. For Use this log in information ftp://tahoe.viengineering.net login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. For Username: NIWeek2012 Password: f7aPadl6 Please Note: You will not be able to access the FTP through a web browser! You MUST use an FTP Software Client to access the FTP. To access the ftp.distek.com please use your FTP software client: Client FTPS settings Hostname: ftp.distek.com Port: 990 Client Settings for SFTP using ssh ftp.distek.com Port 22 if you are using Filezilla your site manager window will look like this. If you have any issues downloading the videos or you are unable to view them please post to this topic. Enjoy, and hopfully the videos will help you learn something new about LabVIEW Mark
    1 point
  3. Hi All, I am starting a new project and, being a relative new-comer to LVOOP (besides a little play-around with examples etc.), am wondering whether this project is a suitable use case for LVOOP ie. will I gain any advantages.The project scope is: - Automated test equipment to test one and only one product type (ie. model). Tested using Labview for hardware interface and TestStand for sequencing the actual tests. This is unlikely to change (duplicating the entire equipment for a new model is more likely). - Hardware interactions with the product are "one only" ie. there aren't several kinds of DMMs or SMUs etc. I have one of each type of hardware interface. This is also unlikely to change since changes to the product are unlikely. There will be around 8-9 hardware interfaces (read. PXI modules). - The equipment is under a controlled system ie. change is a prolonged process, of which actual development is a very small part. Improvement in development time for modifications may not contribute to the total time needed for changes. Besides encapsulation, I'm not sure LVOOP offers me enough advantages for this project, but I am interested in thoughts and ideas. An idea I have had thus far is implementing a simulation interface to each hardware layer (similar to the HAL concept) to allow me to perform unit testing of the architecture levels above but substituting in a simulation class, derived from a base class (eg. DMM_Simulation derived from DMM_Base) instead of the actual hardware-connected class (ie. DMM_Physical also derived from DMM_Base) by way of a the Factory Pattern. This is useful for development purposes but not practical use in production. Thanks for any replies!
    1 point
×
×
  • Create New...

Important Information

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