Leaderboard

Thanks for keeping up the fight! I don't even want to imagine your inbox on a Monday...

You guys lost me days ago, but I love reading this. Please continue to share 🙂

Ok, here's what I did: I found a lvlibp file in my LV14 installation, and extracted it: $ file lv_icon.lvlibp lv_icon.lvlibp: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows $ wrestool -x --raw lv_icon.lvlibp -o ./ $ ls -l lv_icon* -rwxr-xr-x 1 mefisto None 5377536 2014-06-25 lv_icon.lvlibp -rw-r--r-- 1 mefisto None 5375712 06-10 12:47 lv_icon.lvlibp_10_2_0 -rw-r--r-- 1 mefisto None 704 06-10 12:47 lv_icon.lvlibp_16_1 Then checked the RSRC file from inside: $ file lv_icon.lvlibp_10_2_0 lv_icon.lvlibp_10_2_0: National Instruments, $ ./readRSRC.py -x -i 'lv_icon.lvlibp' Error: [Errno RSRC {:d} Header sanity check failed.] 0 So, I never tried that before, and my tool doesn't currently support these files. But it should be an easy fix, so I will patch it and get back to you with more info. For fixing 'tampered with password' message - what I do is just removing the file from library when in extracted form (can't remember exactly, but I think 3 changes are required, one of them is removal of the LIBN which you mentioned). Btw, NI is inconsistent here - they say the password is just 'unintended modification' avoidance, but the 'tampered' message suggests the intent for creating that functionality was to provide some impression of security. EDIT: Fixed it! Now I'm getting: $ ./readRSRC.py -vv -x -i 'lv_icon.lvlibp_10_2_0' lv_icon.lvlibp_10_2_0: Starting file parse for RSRC extraction lv_icon.lvlibp_10_2_0: Block 'LVzp' index 0 recognized lv_icon.lvlibp_10_2_0: Block b'LVzp' max data size set to 5273600 bytes lv_icon.lvlibp_10_2_0: Block b'DATA' max data size set to 5375472 bytes lv_icon.lvlibp_10_2_0: Writing block b'LVzp' lv_icon.lvlibp_10_2_0: Storing block b'LVzp' section 0 binary in 'lv_icon_LVzp.bin' lv_icon.lvlibp_10_2_0: Writing block b'DATA' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 0 binary in 'lv_icon_DATA0.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 1 binary in 'lv_icon_DATA1.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 2 binary in 'lv_icon_DATA2.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 3 binary in 'lv_icon_DATA3.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 4 binary in 'lv_icon_DATA4.bin' lv_icon.xml: Writing binding XML The ZIP is auto-decrypted, so we can now extract it: $ file lv_icon_LVzp.bin lv_icon_LVzp.bin: Zip archive data, at least v2.0 to extract # unzip lv_icon_LVzp.bin Archive: lv_icon_LVzp.bin extracting: NI_Embedded_Library.xml extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read Boolean.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read Color.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read String.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write Boolean.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write Color.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write String.vi [...] Will update after I look at the files I got. EDIT2: Looked at the files: The only real issue is lack of VCTP section. The rest of removing the VI from library is trivial, if you check how the file looks before and after compiling the library. VCTP sections from all files seem to be merged together (after all it stands for VI Consolidated Types), and stored in DATA resource of index 0. That resource is then compressed with ZLIB. Looks like DATA0 is zlib'ed, while DATA1+ are not. I will have to update the tools to handle a situation where the same resource ID has compressed and uncompressed sections. ps. If anyone wonders about the strange shortcuts we're using, I've made a wiki page on this: https://labviewwiki.org/wiki/Resource_Container

If a VI is compiled for current platform, isn't the initialization code arbitrarly executed when VI is being loaded in LV? Isn't that like, very bad? I mean, I could place a copy of Back Orifice there. The community here is exchanging VIs all the time, it would destroy the trust completely if a bad actor would do that. And NI engineers are loading VIs from users as well, right? For example there is the version conversion forum.. I wonder how many of them have source code on the same computers. That would be a massive leak. Though I must say I didn't checked if it's really executed, that isn't my point of interest. Anyway, I'm near to finishing my involvement with LabVIEW. Will soon decide what to publish (most of what I did is already published).

I sign all my built EXEs, for all my customers. It's trivial to do and doesn't cost much. This also allows me to know if the application that I'm asked to support was built by my company or the customer did the rebuild themselves.

There is nothing broken! It's the nature of the beast that the CPU needs to be able to read the machine instructions in order to execute them. If the CPU can anyone else can too unless you execute on special security enhanced CPU engines where the code is encrypted and only decrypted inside the CPU itself with no external access to that decrypted code. Such hardware is however VERY specialized and VERY expensive and VERY unusual. Good luck in your attempts but there are a lot more interesting and beneficial things to do with your time than "breaking" LabVIEW VIs. Especially since it is not breaking but simply piecing together all kinds of information that has to be present in various ways in order to be even functional. If LabVIEW VIs were broken in that context, every single Windows, Linux, Mac and whatever executable and shared library would be broken too. And especially the much loved .Net assemblies! Reverse engineering them is even with obfuscation a piece of cake. Still tedious, sure, but much easier than trying to reverse engineer a LabVIEW executable from getting all the VIs out and disassembling every machine code stream for each VI and figuring out the linker information to piece those disassembly streams correctly together.

That's about the same as when you have a DLL and want to get the C source back! Rewriting it from scratch! As explained before, those VIs inside an executable have their diagram and usually front panel completely stripped out. They are not hidden or anything, they are simply completely gone, nada, futschi, niente! LabVIEW doesn't need them to execute the VI in an executable, so why keep it and ballon the executable size unneccessarily? Also there are many people who do not want their source code (and precious IP) handed out to their users and they would be very upset if LabVIEW executables contained the full source code, no matter how much hidden. So the safest thing to do is to remove it, what is not there can not be stolen! The only thing inside such a VI is the actual compiled code (machine code instructions for the CPU it is meant to run on) and some linker information so LabVIEW can piece the VIs together when loading the whole hierarchy and connect the correct terminals with the data values that are represented through the wires that go into the node, only the wires in the calling diagram are gone too just as the rest of the diagram. Still for the compiled code that is enough. So you could with lots of trickery and reverse engineering retrieve the machine code streams from the VIs and feed them piece for piece to a disassembler and then you end up with Assembly Code text, the text form of the lowest level machine instructions that the CPU processes. This is source code too, but not something that most people will easily understand. It is one level deeper than C programming and several levels deeper than LabVIEW diagram code! To regenerate C from assembly code while not easy and not automatic is possible, going from assembly to LabVIEW is pretty much futile except for the approach of describing the algorithme involved from the assembly code and then recreate it in LabVIEW. The problem is that going from assembly code to something like "Read channel 0 from DAQ board 1, turn it in a hex string and write the result to GPIB instrument at primary address 4 on GPIB bus 0" would likely cover 10 pages of assembly code and would be hard to deduce from those 10 pages without very careful study. It would be in absolutely all cases quicker and more effective to simply put up a high level description of what the application does and reimplement it from scratch based on that. This is one of the reason the other approach has never been really tried and the effort is to big to allow a hobbyist to try it for fun.

Due to the overwhelming response I put together a solution using some free online tools. First, you will need a tool called yEd. (http://www.yworks.com/en/products_yed_about.html) This is a very nice free tool for generating various graphs and charts. Next you will need Excel because that is the file type yEd uses to import an adjacency matrix. Last, you will need some LV code to generate an adjacency matrix and node property list from a project. Here is one I made for Actor Framework. Please excuse the poor code layout as I hacked this together quickly. Generate AF Node Map Data.vi (Note: this can easily be adapted to other message systems. The only change would be the mapping for the color properties to the appropriate parent classes. Open the VI, choose your target project and your destination xlsx file and run it! You will get a file like this: AF Demo node list.zip (zipped for your protection. ) Next you need to open this file in yEd. When you do, you need to set the data ranges correctly, like this: and choose a presentation configuration like this: which I created earlier using this: The end result, after a few cosmetic tweaks results in this: Pretty cool, eh? (Well, I think it is useful. I always prefer to visualize my applications. Complex apps using messaging architectures can get pretty hard to follow without good documentation.) I hope others find this useful. -John