Is there any low-level documentation on the VI format, just as far as the basic structure goes?

[Sparkette]

If you turn on LVdebugKeys in LabVIEW.ini, you can press Ctrl+Shift+D and then Ctrl+Shift+N to open a hidden settings dialog. One of these settings is "Heap Save Format", which defaults to "Binary2". One of the options this can be changed to is XML. At first this got me excited, as I figured I'd be able to open a VI in a text editor and mess around to see what I could discover. However it turns out only the front panel and block diagram sections are saved as XML. The rest of the file is still binary, meaning I can't do anything that changes the size of the XML. Even worse, it seems that making any changes to the XML that don't change the size, even if it's just changing one of an object's coordinates by one, makes LabVIEW think the block diagram has been removed. I assume there's a checksum somewhere that's making it think the block diagram wasn't saved correctly.

 

Has anyone figured out how to extract that specific section, make changes to it, and most importantly put it back into the file with an updated checksum? That VI Explorer tool (whose main purpose is removing passwords from VI's; don't know if it's been updated for 2013 and 2014 as I've used a different method for that since 2013 broke it) can read specific sections from a VI, and I managed to get it to also read out the XML data by telling it to read the BDHX or FPHX section, but it doesn't provide any way to rebuild the VI with a modified version; just to read the data.

 

I'd like to see what I can do by editing the FP/BD data structures directly (even though it's dangerous and not at all supported) but the current method I use (putting addresses from Heap Peek into Cheat Engine and editing the memory) is so limited.

[Rolf Kalbermatter]

If you turn on LVdebugKeys in LabVIEW.ini, you can press Ctrl+Shift+D and then Ctrl+Shift+N to open a hidden settings dialog. One of these settings is "Heap Save Format", which defaults to "Binary2". One of the options this can be changed to is XML. At first this got me excited, as I figured I'd be able to open a VI in a text editor and mess around to see what I could discover. However it turns out only the front panel and block diagram sections are saved as XML. The rest of the file is still binary, meaning I can't do anything that changes the size of the XML. Even worse, it seems that making any changes to the XML that don't change the size, even if it's just changing one of an object's coordinates by one, makes LabVIEW think the block diagram has been removed. I assume there's a checksum somewhere that's making it think the block diagram wasn't saved correctly.

 

Has anyone figured out how to extract that specific section, make changes to it, and most importantly put it back into the file with an updated checksum? That VI Explorer tool (whose main purpose is removing passwords from VI's; don't know if it's been updated for 2013 and 2014 as I've used a different method for that since 2013 broke it) can read specific sections from a VI, and I managed to get it to also read out the XML data by telling it to read the BDHX or FPHX section, but it doesn't provide any way to rebuild the VI with a modified version; just to read the data.

 

I'd like to see what I can do by editing the FP/BD data structures directly (even though it's dangerous and not at all supported) but the current method I use (putting addresses from Heap Peek into Cheat Engine and editing the memory) is so limited.

 

Man you must have a lot of idle time. As far as documentation goes for the binary VI format, all I know is that it basically follows the Macintosh resource format from the good old Mac OS Classic times. That knowledge allows to identify and access the various resources in a VI but of course is just the container format not the understanding of the individual formats of each resource type. While some of them used to be fairly similar to classic Mac OS formats, others and that is the majority of the VI resources, are very LabVIEW specific and the LabVIEW developers more or less threw together whatever they felt was necessary into a C structure and then flatten that to the resource stream. Without access to the LabVIEW C++ source code it is basically impossible to decode these resources in a meaningful way and even more difficult to modify them and write them back into the binary VI structure.

 

VI Explorer really doesn't seem possible to do without access to the actual LabVIEW source code, which would have to be gained either illegally or caused by a preachment of at least some non-disclosure agreement.

 

Also many of the bigger resources are currently ZLIB compressed which adds an extra complication layer into this all.

 

Personally I think your best (and almost only) bet to get at these informations is to apply as LabVIEW developer within NI, but expect them to require you do sign some NDAs before you start, and they will do a good screening and some of your posts in the past may be a bit of an obstacle for that.

[hooovahh]

Oh boy are you in luck.  So I have tucked away some code I made a while ago for reading parts of the VI file structure.  It needs some polish and more features but here is the basics of it.  Open the attachment with OpenG installed, I think it uses the File and MD5 packages.  Then open the Example Read VI Data.  It will read in things like description, icon, version, VI title, bookmarks and a few other things from the file on disk.  Yes it did have the ability to overwrite passwords but I removed that for this post.

 

Also I'd like to mention that the VI Explorer is just crap.  The way it is written it is obvious the author comes from a text based language.  Looking at his PHP source shows how good he is at text programming.  That is mostly what these VIs are, is the reverse of his PHP source.

 

Oh and by the way I don't know if you have visited his site lately but he has updated source that reads front panel and block diagram objects.  This is done by reading the BDHX and FPHX sections, then uncompressing them.  As for editing the VI..yeah not so much sorry.  I assume there are tons of hashes and checksums to look for file corruption.

VI File Structure.zip

[Sparkette]

Thanks for posting! Shame it doesn't work for editing yet. At least those hashes and checksums (other than the ones related to password "protection") are most likely designed with unintentional "edits" (i.e. file corruption) in mind rather than preventing intentional ones.

[Rolf Kalbermatter]

Definit

 

Thanks for posting! Shame it doesn't work for editing yet. At least those hashes and checksums (other than the ones related to password "protection") are most likely designed with unintentional "edits" (i.e. file corruption) in mind rather than preventing intentional ones.

Definitely! They have been there since a long time. One of the possible reasons for the threaded "Insane VI" error messages in earlier LabVIEW versions. Your disk just isn't as reliable as you would like it and LabVIEW using a binary format for older files is very sensitive to even the slightest error there.

[lordexod]

Resource Editor.zip

Need to add plugins of resource tag names "New Plugin.vi"

[Sparkette]

Resource Editor.zip

Need to add plugins of resource tag names "New Plugin.vi"

 

That looks interesting. Does it let you actually edit the data or just view it?

Also, here's a tip: if you need to call a function in LabVIEW.exe using a Call Library node, just type "LabVIEW" in the path box without quotes. That's what NI does, and that way it doesn't rely on a specific installation path (so you don't need to use the path input) plus AFAIK it's platform-independent. Though I doubt calling functions in LabVIEW.exe (except through VI's provided by NI) is at all supported by NI, in case that's not obvious. (All of the VI's in vi.lib that I've seen using that method were password-protected.)

 

Also rolfk, when you mentioned disks being unreliable, at first I thought you typed another, similar word that means something completely different.

Edited September 23, 2014 by flarn2006

[ned]

Also, here's a tip: if you need to call a function in LabVIEW.exe using a Call Library node, just type "LabVIEW" in the path box without quotes. That's what NI does, and that way it doesn't rely on a specific installation path (so you don't need to use the path input) plus AFAIK it's platform-independent. Though I doubt calling functions in LabVIEW.exe (except through VI's provided by NI) is at all supported by NI, in case that's not obvious. (All of the VI's in vi.lib that I've seen using that method were password-protected.)

I don't know about "supported" but calling functions within LabVIEW.exe is the standard way to do memory allocation when it's necessary to pass a pointer to a DLL function, and this is well-documented: https://decibel.ni.com/content/docs/DOC-9091

[lordexod]

I know I can do better this editor.

This is just a simple example of such a editor.

Maybe some of you will do this editor better.