Low level VI data editor (warning: not for production use!)

[Sparkette]

One thing I've always wanted (and have asked about here before) was a way to edit the data inside VI files at a low level. Well I finally figured that out. I have here a tool that will let you open a VI, look at the individual blocks of data stored within, and make changes. Plus, with the power of private methods and internal settings, it can also convert VI's to a format where the front panel and block diagram are XML-based, so you can easily edit the raw representations of objects.
 

 
Here you go. Run "Resource Editor.vi", select a VI (make sure you make a backup first if you care about it), and click Load to load its resources. Click "Load as XML" if you want to edit the front panel and diagram as XML. If you've edited the block diagram at all, make sure to click Fix VI Checksums. Then just click Save once you've made the changes you want.

 

EDIT: Second version is posted; this one should work in LabVIEW 2014, and fixes some bugs. I also added copy/paste buttons for the front panel and block diagram resources, since LabVIEW's built-in copy/paste function didn't seem to work for some reason. Note that if you edit the front panel or block diagram in the VI without using copy/paste (and the size is different), you need to update the size (first 4 bytes) as well. You can do this by clicking Copy and then Paste.
 
Now this may not be too useful for you, considering it's not something you should use in production code or anything you don't want to break. (I say that a lot in my posts, don't I?) But if you're curious about how VI's work internally, it's perfect.
 
This requires OpenG. Also, special thanks goes out to Thomas Zeugner for making VI Explorer. You know, that tool for cracking VI passwords. Turns out he figured out how the VI checksum (in the BDPW block) is calculated, which helped me greatly.
 
Oh, one more thing, I do plan on improving it. I was just excited to share what I had. So keep in mind there may be bugs.

 

Latest version:

 

The latest version is posted on the tool's home page, here: http://flarn2006.dyndns.org/llvim/

Older versions:

 

Low-Level VI Manipulation rev2.zip
Low-Level VI Manipulation.zip

Edited August 24, 2015 by flarn2006

[hooovahh]

So I made a few improvements, first I found that there were relinking issues from trying to load resources normally in the user.lib.  The updated one should load from normal locations like the downloads folder (which is where most people are going to try this out from)

 

It looks like you might just not know the right way to make UI's with the event structure.  Generally you move the control into the case that is handling it, so that its value is read when you enter.  Buttons being latch when released causes them to bounce back, so they are only true for that first time, then go back to false.  This means when you enter the event structure it will always have a value of true and you don't need to check it.

 

Polling the timeout case with 0ms isn't necessary.  The code does nothing until you press a button or interact with the UI so remove it.

 

I added a case for panel close, so to stop you close the window instead of hitting a button.

 

Prompting for the number of numerics, strings, and paths, had a while loop with 0ms wait which is bad for CPU usage.  I replaced it with an event structure.

 

I removed several backwards wires.

 

I added Update While Typing to the string control, so that value changes are registered if you click on the save right after making a change.

 

After a load it picks the first resource to display.

 

Functionally I think it is the same as what you had.

 

Now lets talk about this fix MD5 business you have going on.  You prompt to ask how many Numerics, Strings, and Paths are on your connector pane, but you never use this data to calculate your salt.  But even if you did you need to be aware that this includes going into other controls.  If you have a single cluster with two numerics in it on the connector pane, and a scalar numerc also on the connector pane then you have 3.  So this needs to include things like numerics and strings in error controls.

 

A more robust method is to calculate the salt by reversing the equation and guessing what the salt is.  I've done this in the past by assuming something like, there will be no more than 20 numerics, strings, or path controls on the connector pane.  This could be increased of course.  But with a known good VI you have the MD5 output, and the data going into the MD5 you just are missing the salt.  An equation with just one missing variable.  So if you keep guessing the salt, making the assumption that there will be no more than 20, then it doesn't take too long to go through each possible combination finding the one that makes the equation MD5 = Data + Salt.  If you want you can remove the limit of 20 setting it to 255, but it would take a decent amount of time to go through all 255*255*255 possible combinations, where 20*20*20 is more realistic. 

 

You also aren't fixing some issues when VIs are part of a library, I believe there are other checksums that need to be updated but don't remember what they were exactly.

 

Oh and was the XNode necessary?  Could you just perform the search on the string name "LIBN" instead of taking LIBN then looking up the type as a number?

 

And I know this won't work for all versions of LabVIEW.  You know how Ned lets you save in multiple binary modes? That's because older LabVIEW versions used the older binary methods, which might have different named blocks, so BDHX I think is some times BDHA or BDHB.

 

And 2015 is really new, most people aren't going to have it, an older version might have been a better choice.

Low-Level VI Manipulation Hooovahh Edit.zip

[Sparkette]

Thanks for your feedback! Here's some specific points that I think are worth mentioning:

It looks like you might just not know the right way to make UI's with the event structure. Generally you move the control into the case that is handling it, so that its value is read when you enter. Buttons being latch when released causes them to bounce back, so they are only true for that first time, then go back to false. This means when you enter the event structure it will always have a value of true and you don't need to check it.

Polling the timeout case with 0ms isn't necessary. The code does nothing until you press a button or interact with the UI so remove it.

Yep, it appears I didn't. I actually thought I tried it the way you suggested before but it didn't work; I guess I was mistaken.

Now lets talk about this fix MD5 business you have going on. You prompt to ask how many Numerics, Strings, and Paths are on your connector pane, but you never use this data to calculate your salt. But even if you did you need to be aware that this includes going into other controls. If you have a single cluster with two numerics in it on the connector pane, and a scalar numerc also on the connector pane then you have 3. So this needs to include things like numerics and strings in error controls.

Oh wow you're right; I forgot to connect that terminal! *facepalm* I guess that's what I get for not testing it with any VI's that actually had terminals.

Also I wasn't aware that it includes values in clusters, etc. Thanks for letting me know so it doesn't confuse me later.

A more robust method is to calculate the salt by reversing the equation and guessing what the salt is. I've done this in the past by assuming something like, there will be no more than 20 numerics, strings, or path controls on the connector pane. This could be increased of course. But with a known good VI you have the MD5 output, and the data going into the MD5 you just are missing the salt. An equation with just one missing variable. So if you keep guessing the salt, making the assumption that there will be no more than 20, then it doesn't take too long to go through each possible combination finding the one that makes the equation MD5 = Data + Salt. If you want you can remove the limit of 20 setting it to 255, but it would take a decent amount of time to go through all 255*255*255 possible combinations, where 20*20*20 is more realistic.

I thought about brute forcing it like that, but I was thinking it would take too long because in order to check it each time it would need to save the VI with the new checksum and attempt to open it. Do you know a better way to test it? Or does it not take as long as I'm thinking even with a maximum of 8,000 attempts?

You also aren't fixing some issues when VIs are part of a library, I believe there are other checksums that need to be updated but don't remember what they were exactly.

I was not aware of that; I'm pretty sure one of the checksums is calculated partially from the library data though, but I may be wrong.

Oh and was the XNode necessary? Could you just perform the search on the string name "LIBN" instead of taking LIBN then looking up the type as a number?

Oh wow you're right (edit: I just realized this is the second time I said that); I was thinking I needed a numeric constant that shows up as a string, but I guess I could also make "find resource by type" a polymorphic VI so it can accept a number or a string. I'll do that.

And I know this won't work for all versions of LabVIEW. You know how Ned lets you save in multiple binary modes? That's because older LabVIEW versions used the older binary methods, which might have different named blocks, so BDHX I think is some times BDHA or BDHB.

I have it trying to find BDHX, BDHc, BDHb, and BDHP, the first one being for XML, the others being what I saw on the VI Explorer page. Are there more I'm forgetting?

EDIT: Oh, I see what you mean. *facepalm* I made the subVI to find the right one once I realized that it could be named something different, but I forgot to actually use that subVI.

And 2015 is really new, most people aren't going to have it, an older version might have been a better choice.

Yeah, I forgot about that. When I post the next version I'll save it for 2014, and then if anyone needs an older version they can ask.

Thanks again!

EDIT: One more thing, how did you fix those relinking issues you found before? I want to know so I can make sure it's not an issue when I post the next version.

Edited August 20, 2015 by flarn2006

[hooovahh]

I thought about brute forcing it like that, but I was thinking it would take too long because in order to check it each time it would need to save the VI with the new checksum and attempt to open it. Do you know a better way to test it? Or does it not take as long as I'm thinking even with a maximum of 8,000 attempts?

At some point I need to stop talking and we are pretty much there.  What I do feel comfortable saying (because it doesn't relate to LabVIEW in particular) is you have an equation similar to this (but not this exactly):

 

MD5(SomeData +  Salt + MoreData) = Hash

 

In this equation you can read the SomeData, MoreData, and the Hash from the contents of the file.  So plug those into your equation and all you are missing is the salt.  Put in a value of 0 for the Salt and see if the two sides of the equation are equal.  If they are you have your salt, if they aren't try another number.  Eventually you'll get it.  And knowing your salt is made up of three numbers, of which each is relatively low number, makes this test a pretty quick when it works.  When it doesn't work then usually what you thought was the value for one of your variables like SomeData was the wrong data, so the two sides will never be equal.

[Sparkette]

At some point I need to stop talking and we are pretty much there.  What I do feel comfortable saying (because it doesn't relate to LabVIEW in particular) is you have an equation similar to this (but not this exactly):

 

MD5(SomeData +  Salt + MoreData) = Hash

 

In this equation you can read the SomeData, MoreData, and the Hash from the contents of the file.  So plug those into your equation and all you are missing is the salt.  Put in a value of 0 for the Salt and see if the two sides of the equation are equal.  If they are you have your salt, if they aren't try another number.  Eventually you'll get it.  And knowing your salt is made up of three numbers, of which each is relatively low number, makes this test a pretty quick when it works.  When it doesn't work then usually what you thought was the value for one of your variables like SomeData was the wrong data, so the two sides will never be equal.

What do you mean you need to stop talking? Are you under some kind of NDA or something?

Also yeah, I think I get what you mean. In fact I could actually just leave the second hash unchanged if it's only the block diagram that was modified. Thanks.

[Sparkette]

Huh, it looks like this can edit the .rsc files in the "resource" folder. I wonder what kinds of things you could do with that.

[Cloedu72]

Hi flarn2006

 

I always receive an error when executing this very interresting tool. The Message look like that (Calling :

Error 53 occured at Invoke Node in Save VI with XML Heaps.vi

possible reason:

Labview: Manager call not supported

Method Name: Call Internal Command

 

Enabled: LVdebugKeys=true and changed the Settings in the NED Menu.

Edited August 27, 2015 by Cloedu72

[Sparkette]

Hi flarn2006

 

I always receive an error when executing this very interresting tool. The Message look like that (Calling :

Error 53 occured at Invoke Node in Save VI with XML Heaps.vi

possible reason:

Labview: Manager call not supported

Method Name: Call Internal Command

 

Enabled: LVdebugKeys=true and changed the Settings in the NED Menu.

I think I know what the problem is; I hadn't thought of it until now. I'm pretty sure the specific internal command I used that method to call is only in LabVIEW 2015. Might be in 2014, but I don't think so.

It should work if you uncheck "Load as XML" though, but that won't work in the Easy XML Editor VI though. I'll add a toggle in the next version that should fix that. It might work if you click Continue on the error box however.

Of course, if you do that, you'll need to enable XML saving manually. To do that, just open the Ned menu (your post indicates you know how) and look for the "heap save format" option. Click that until it says XML. Then save your VI and open it with the resource editor. Don't forget to set it back to Binary2 afterwards!

If anyone else sees this post and doesn't know how to open the Ned menu (Cloedu72's post indicates he knows how), you need to open LabVIEW.ini and add the line "LVdebugKeys=true" (without quotes) and restart LabVIEW if it's running. Then you type "DN" while holding down Control and Shift.

Edited August 29, 2015 by flarn2006

[Cloedu72]

Thanks for your quick response. I will try and report later....!

[Cloedu72]

Works very well with LV2015! 

[Mefistotelis]

Any idea on what's up there?

LabView 2014

Loading a VI for binary viewing works fine.

Loading for XML viewing gives the following error.

Tried several VIs, including very simple (empty) one.

[Rolf Kalbermatter]

17 hours ago, Mefistotelis said:

Any idea on what's up there?

LabView 2014

Loading a VI for binary viewing works fine.

Loading for XML viewing gives the following error.

Tried several VIs, including very simple (empty) one.

I would say the error message is very clear! The desired call is not supported in the current LabVIEW version. Why do you think this should work?

[Mefistotelis]

1 hour ago, Rolf Kalbermatter said:

The desired call is not supported in the current LabVIEW version.

I see; so for the XML function, the tool requires LV2015+.

This also means the tool doesn't do VI conversion, just uses functionality which is part of the LabView RE.

1 hour ago, Rolf Kalbermatter said:

Why do you think this should work?

I don't know much about LabView. For most of the tools I use, the default state is that they do 'work'. Didn't know I shouldn't expect that .

There's also that:

On 8/19/2015 at 7:55 AM, flarn2006 said:

Second version is posted; this one should work in LabVIEW 2014

In general, I'm looking into this as I'm planning to implement VI-to-XML conversion by myself, and I think it would be nice to keep the conventions introduced by NI.

EDIT:

Oh, this was actually already discussed, just a few posts before. Should've read before posting, sorry.

On 8/27/2015 at 9:53 PM, Cloedu72 said:

I always receive an error when executing this very interresting tool. The Message look like that (Calling :

Error 53 occured at Invoke Node in Save VI with XML Heaps.vi

possible reason:

Labview: Manager call not supported

Method Name: Call Internal Command

 

Edited November 7, 2019 by Mefistotelis

[Rolf Kalbermatter]

1 hour ago, Mefistotelis said:

In general, I'm looking into this as I'm planning to implement VI-to-XML conversion by myself, and I think it would be nice to keep the conventions introduced by NI.

In general you are working here with non released, non documented features in LabVIEW. You should read the Rusty Nails in Attics thread sometimes. Basically LabVIEW has various areas that are like an attic. There exist experimental parts, non finished features and other things in LabVIEW that were never meant for public consumptions, either because they are not finished and tested, an aborted experiment or a quick and dirty hack for a tool required for NI internal use. There are ways to access some of them, and the means to it have been published many times. NI does not forbid anyone to use them although they do not advertize it. Their stance with them is: If you want to use it, then do but don't come to us screaming because you stepped on a rusty nail in that attic!

The fact that the node has a dirty brown header is one indication that it is a dirty feature.

Edited November 7, 2019 by Rolf Kalbermatter