I have taken the first step towards unofficially opening up the Project Provider Framework.

[Sparkette]

The Project Provider Framework is an API provided by LabVIEW that has minimal support from NI. This API can be used to create new types of project items, add new menu items, and other stuff like that. They only share documentation about the API with those who apply to be partners, however, and there is a signature mechanism to enforce this. Well I've figured out how that signature is generated, so hopefully the LAVA community can do some cool stuff with this! I haven't really played around with it at all, but I plan to.

 

Each plugin is defined by an INI file, located in resource\Framework\Providers\GProviders. Each INI file has a Signature key, which is required to be valid in order for LabVIEW to load the plugin. To generate this signature, first you need to concatenate all the values (not the keys) in the INI file. Only string values though, not numeric or Boolean ones. I'll use GOOP_MyComputer.ini from OpenGDS as an example:

[Provider]
SupportedType={CEFE1B10-1732-4678-A70A-299293455410}
IsPrimary=0
ItemInterfaceVI=..\Open_GDS\GOOP_MyComputer_Item_Interface.vi
CreateNewWizardInterfaceVI=..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.vi
CreateNewWizardHost=Source
LicenseName=None
InterfaceVersion=1.0
Signature=KS5CBT93T9SSJK3SNWB239RLN95WTC9W

Ignore the Signature line as well, of course. The concatenated string here will be "{CEFE1B10-1732-4678-A70A-299293455410}..\Open_GDS\GOOP_MyComputer_Item_Interface.vi..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.viSourceNone1.0". Take the MD5 hash of this string. In this case, the hash is "8423091770884C816AF971DB7A632067". The next step is to apply a simple substitution cipher to the MD5 hash:

0123456789ABCDEF
T3C5K7W9SBNRJLX2

Just replace the character on the top with the one under it. So the new string will be "SKC5TB399TSSKJS3WN2B93LR9NW5CTW9". One more step! For each pair of characters, i.e. "SK", "C5", "TB", ..., switch the two characters. In this case you'll have "KS5CBT93T9SSJK3SNWB239RLN95WTC9W". And look! That's the signature in the INI file!

I've attached a VI that does this for you, minus the step of concatenating the INI values. Just pass the VI a string and it will output the signature.

Enjoy, but keep in mind the usual warning about using unreleased features of LabVIEW: don't use it for anything too high-stakes.

Generate PPF Signature.vi

EDIT: To make this process easier, I have also written a C# program that will automatically sign an INI file for you. Just drag and drop the INI file onto the EXE, or use the command line to specify an output filename as well. Both the source code and EXE are included here.

SignPPFPlugin.zip

Also, here's some palette files for the PPF's API VI's. Since they won't all fit on one page, I did some very simple categorization, simply creating separate menus for "Get" functions, "Set" functions, and one for all the others. Extract the ZIP file to menus\Categories\Addons, and then just put it in your palette from the palette editor.

PPF Menus.zip

Finally, here's a tool that will automatically generate the interface VI's for you. I found it annoying to always have to update them. Basically they're just VI's that output a cluster with a bunch of paths to "method VI's", which are basically the PPF equivalent to XNode ability VI's. So this will just search for method VI's in the same folder, and generate an interface VI for you through scripting. I called it "PPF Assistant" in case I ever decide to add stuff to it for other PPF-related tasks. This requires OpenG, as well as gb119's Scripting Tools.

PPF Assistant.zip

EDIT2: Looks like the PPF was recently officially made public (though still not supported) including NI's official INI signing tool. Glad my thread here could be of assistance to the people having trouble with that tool!

Edited January 15, 2019 by flarn2006

[SDietrich]

Hi flarn2006,

 

nice work, I take my hat off to you . I don't know how you did it, but it clearly shows us two things:

• Kerckhoffs's principle proves true again
• the INI-file key should have read Checksum instead of Signature

I personally never heared of the PPF before and certainly will investigate what its opportunities are.

 

Regards,

 

Sebastian

 

PS: Maybe you want to share how you found the algorithm? I would think if it was by some reverse-engineering neither our friends at NI nor the guys here at LAVA would appreciate it. I have a hard-copy anyways

[ShaunR]

nor the guys here at LAVA would appreciate it.

 

Oh, I don't know. I think we appreciate it here but condemn most of these things because NI will do something about it now they know for sure it's been compromised

[hooovahh]

I would think if it was by some reverse-engineering neither our friends at NI nor the guys here at LAVA would appreciate it. I have a hard-copy anyways

Flarn does tend to make being a moderator / admin interesting around here.  I'm not so sure there is a need for a hard-copy, I mean the description on how to do this is in everyone's RSS feed by now.  The step by step is so simple that the posted VI isn't even required.  

 

One thing I find interesting is that the signature has nothing to do with the actual code, just the names of the items in it like the VIs used.  So before this signature weakness was found, one could simply install a valid tool, then edit the VIs in it to get the functionality you want.  Or replace the existing VIs with your own without renaming and it would work.  If I were investigating how to do this type of thing that would be the first step I would take, so I'm sure others found a weakness in the signature process before.

[Sparkette]

Oh, I don't know. I think we appreciate it here but condemn most of these things because NI will do something about it now they know for sure it's been compromised

Well there's other, similar things they haven't done anything about.

Edited September 30, 2014 by flarn2006

[SDietrich]

Oh, you mean like XNodes?

 

I think NI's options are quite limited given the fact that they certainly do not want to break existing plug-ins. The whole thing seems to be a forced QA to control how LabVIEW is modified. After all, people pay money for LabVIEW and expect it to behave well, while the PPF gives developers many ways to screw things up, resulting in support calls on the NI hotline.

 

One alternative for NI could be to establish something like a "approved by NI" logo. Everybody can create a working PPF plugin but to have it "approved by NI" it must be signed (as in signature, not in checksum).

[MikaelH]

I tried it on the file: GOOP_Library.ini and it didn't work.

[Provider]
SupportedType={ABC740D6-F254-4BBC-5675-8858F35B820E}
IsPrimary=0
ItemInterfaceVI=..\Open_GDS\GOOP_Library_Item_Interface.vi
LicenseName=None
InterfaceVersion=1.0
Signature=N2JJ9X329XL9TBJR7XT9J2XRXBW7XCSN

The Value string is:

{ABC740D6-F254-4BBC-5675-8858F35B820E}0..\Open_GDS\GOOP_Library_Item_Interface.viNone1.0

 

But the Signature became: KXCB229B7CKCK9BRC5BC5SR7CC3J259R

 

[Sparkette]

I tried it on the file: GOOP_Library.ini and it didn't work.

[Provider]
SupportedType={ABC740D6-F254-4BBC-5675-8858F35B820E}
IsPrimary=0
ItemInterfaceVI=..\Open_GDS\GOOP_Library_Item_Interface.vi
LicenseName=None
InterfaceVersion=1.0
Signature=N2JJ9X329XL9TBJR7XT9J2XRXBW7XCSN

The Value string is:

{ABC740D6-F254-4BBC-5675-8858F35B820E}0..\Open_GDS\GOOP_Library_Item_Interface.viNone1.0

But the Signature became: KXCB229B7CKCK9BRC5BC5SR7CC3J259R

Remember, only include strings, not numbers or Booleans. You put the 0 from IsActive in there, which is why the hash is different. I checked without that 0 in the string and the signature is correct.

EDIT: Wait, you're one of the developers of OpenGDS, so don't you already know how the signature is generated? Or does NI just give you a program that signs it for you?

Edited October 1, 2014 by flarn2006

[Rolf Kalbermatter]

 

PS: Maybe you want to share how you found the algorithm? I would think if it was by some reverse-engineering neither our friends at NI nor the guys here at LAVA would appreciate it. I have a hard-copy anyways

 

Never having tried to look at the Project Provider Framework at all I can't really say for sure, but I would assume that in order to verify that a PPF is valid this check is done on every load, so is in the provided PPF base framework. With flarn having admitted to have broken password protection before it seems not so hard to guess how it all went.

 

And yes, PPFs have the potential to wreck a LabVIEW installation completely and even worse modify code on the fly in a way that is very hard to detect. So this "signing" business is most likely much less about NI not wanting developers to be able to add plugins, but rather safeguarding those customers who have VERY stringent requirements about approved software running on their systems. They are out there and they have rules that even forbid to install OpenG VIs since they are not from an officially approved source.

[hooovahh]

Okay I have a feature request.  Very often I'll setup a project with an EXE and installer with what I want.  Then after changing the software the only thing that the build specifications ever changes is the EXE version, and the installer version.  Wouldn't it be nice if you could right click your EXE, and choose instead of Properties which opens the whole window and takes a while to load, just pick "Change Version" and a separate window popus up allowing the version to be changed.  Then if you right click an installer and pick "Change Version" a similar window pops up, but this window shows the version of other EXE builds, and allows you to set the installer version, to the same version of the EXE.

 

I'm pretty sure this can be done in a Pre-Build VI but have never tried it.  2014 added new controls for setting build versions programatically.  Before then you could do it by setting tags and each version was slightly different.

[Sparkette]

Sorry, I wouldn't know where to begin with that. Maybe someone else can once we know more about the framework.

This PowerPoint presentation is pretty much the only official documentation about the API by the way, and I noticed something kind of weird with it. On slide 25, it shows an example INI file, and it mentions how a signature is required. The signature shown in the sample INI file is "J7W9927AAAAAA5TBNTSSTTKWR29CNT9X". The six A's in a row caught my eye, and then I realized that 'A' isn't even a valid character in a signature! The correct signature would be "J7W9927KW29BR5TBNTSSTTKWR29CNT9X". Strange.

[Rolf Kalbermatter]

 Strange.

 

Why should someone post a working ini file verbatim in a power presentation? The person creating this presentation remembered that PPFs are some restricted feature and simply changed a few characters. 

[Sparkette]

Why should someone post a working ini file verbatim in a power presentation? The person creating this presentation remembered that PPFs are some restricted feature and simply changed a few characters.

Wouldn't be very useful without the VI's. But I guess there's always a chance that whoever changed it didn't know that.

Also, right now I'm working on a tool that automatically generates the interface VI's using scripting. That is, the VI's that output those huge clusters full of paths. I already finished all the scripting code (those diagrams can get quite complicated!) and now I'm going to create the actual interface for it.

EDIT: Finished; check the OP.

Edited October 2, 2014 by flarn2006