Stinus Olsen

On 11/8/2019 at 1:00 AM, Mefistotelis said:

Back to the salt - the algorithm seem to use some additional data to select which interface is used. It may be some kind of count.

Figuring out the specifics of interface selection would require deep dive into RE libraries, so I'll skip it for now.
...
Any comments / advice?

Well, in case you ever consider going that way, I'll recommend you start by looking at the LinkIdentity parts of the code

Another vector for information could also be to look at the codestreams in the "Ned, the friendly debugger" interface.
While I haven't peeked much at Flarn's later progress, I do know that NED will let you switch the format of some VI resources into XML (Heap Save Format) - dunno if Flarn is utilizing that?!
(be warned though - this will most likely certainly cause LabVIEW to crash if trying to load the VI afterwards)

Also, for quick low-level access to the Resource Fork of LabVIEW VI's and a lot of other NI resource files -from inside LabVIEW- I suggest using the REdLoadResFile/REdSaveResFile (interface)functions found in LabVIEW.exe.
That at least cut away one level of abstraction for me, back when I had the time to immerse myself in this kind of 'research'.

Now off to figure out the "Keep code streams for heap peek" option..

While I know this topic is a bit old now, I just wanted to point you to this thread that I created a while back.

The behavior you're observing is a known bug in LabVIEW that currently doesn't have a solution - just workarounds that all relies on external components ?

On 29/8/2016 at 11:01 AM, rolfk said:

Testing and more testing. The code as it is does sort of work for the things I tried, although I do have an occasional hang where the initial connection seems to not go through, but trying a second time then always seems to work. The pipe idea in Windows is a powerful feature but at the same time also something that I feel they didn't entirely go through with. It definitely is a niche feature that gets seldom used by real code, unlike under Unix (Linux) systems where pipes are more or less the infrastructure many applications use for all kind of interprocess communication.

And when you look at the C code of the DLL you will notice that the code to do standard IO redirection looks pretty complicated in the Windows case. It certainly has a flair of an additional API that got tacked onto the existing Windows process model in order to provide Unix like features.

I'll go and create in the next few days a thread here and attach the latest version of an OpenG package for lvpipe here. If I get some good feedback about it with more than just "it works" or "it doesn't work" and preferably some easy to reproduce (it shouldn't involve installing other software) unit tests, I might be tempted to actually create a real package and add it to the sourceforge download repository so it is then available from within VIPM.

Count me in on this as well! - I have quite a few ideas about where pipes would come in handy in my daily home- and work-related projects.
I never really understood why this toolset hasn't gained more attention than it has, so I'll be happy to help testing and promoting it

From time to time I encounter one of these corrupt controls, usually when upgrading old code onto a newer LabVIEW version.

This time I upgraded my main LabVIEW installation from 2013.0.1f2 to 2013.0.1f5, and somehow this single tree control ended up being corrupt - somehow..

I can set text color and style for the active cell, without an error from the property, but the tree itself doesn't update/change!

I did some minor searching on NI and LAVA this.forum but turned up not-so-much wiser.

Besides, the corruption (if that's what this is) can be worked around by replacing the control/indicator with another one, so nothing's really wasted except for the 2+ minutes it takes to realign the new instances appearance..

Is this a well known issue?

I have attached a small (and fast) VI I copy pasted the 'corrupt' control into to visualize the anomaly.

If the Tree reference is to another tree on the FP the code works as expected, and that tree is updated correctly..

Care to explain this?  

Tree Test.vi

Do you have a specific use for it to be able to read the VIs from within a built executable - or was it just a way of showing that the functions won't work with files in a executable image?

Because thats a limitation of the NI function I guess

I agree that the VI Server should be fixed, or the doc revised to correspond to the code - but if it's a matter of creating a 'temporary' workaound, it shouldn't prove that hard!

I.e. you can access the VI files inside a LabVIEW executable image - but the non-NI way is not as easy as a simple property node (nor as pretty).

Depending on whether the solution should run on RT/Linux, you could use the Windows API to unpack the main resource from the executable, then work from there, whereas if you

were to do the check on RT or Linux you would have to manually unpack the contained resource.

After that you would then parse the output (de-XOR'ed) archive, find and unpack the Resource Fork (VI File) in question, and finally use the REdLoadResFile approach from there..

As I said - not pretty or tidy, but definitely doable...

Edit: fixed minor RT / Linux confusion..

Thanks you and this is nice, but I'm guessing this only works if the full LabVIEW development environment is installed, because this relies on that ever so important REdLoadResFile call Jack mentioned earlier.  Still this is helpful and I will look into modifying my VI File Structure code in the future to have that option, since it probably is less error prone and more flexible than my manual method.

Nope - the REdLoadResFile function is a public export from lvrt.dll as well. So you should be good to go with the RTE too..

(at least until NI some day decides to remove it for various reasons)

Oh and by the way - here are the two missing functions to make the subVI folder complete..     (insert and save functions)

Have fun....

Missing SubVIs.zip

Would this do the trick?

Check for BD.zip

Here is a fix to the above mentioned problem.

I have added an enclosing selector case as a guard against empty objects in the JSON Object::Unflatten function:

JSON Object - Unflatten.zip

(Backsaved to 2011)

As I'm still not a BitBucket user, could one of you possibly add it to the repository?

To test the code, create a file containing only an opening and a closing bracket "{}", and try to load it before and after the fix is applied.. 

According to most of the information I could find on the subject, the shortest possible JSON stream allowed is either an empty Object "{}" or an empty array "[]".

However, when trying to parse a string containing only an empty Object "{}", I'm getting an error 1 in return - is this expected behaviour?

I recon the JSON Object:Unflatten function should be able to handle at least an empty root object?

Could you save it in LabVIEW 2011 please.

Here you go:

Test and Bug Fix_2011.zip

Here is a small VI that shows the usage (and tests) the functionality:

Test and Bug Fix.zip

At the same time there is a small fix for one of the removal VIs that caused a null value to be created if the path to the value object to be deleted was non-existing..

Yes the fix works as it should!

I use the JSON VIs as one of multiple backend providers for a general configuration module in my applications.

For that purpose I've had to add a couple of additions to the toolset - and I don't see why those could not be a part of the standard functions, so here are a changeset:

JSON Change Set.zip

Maybe one of you guys could take 5 minutes to import them to the bitbucket repo?!  (instructions are included )

The added functions are:

 - Setting (possibly overwriting) a hierarchy element, by index of an array of strings

 - Removing (deleting) an element, also by using an array of strings as index

 - Setting a value of path type by internally casting it to a string (my own way of circumventing the path-type-unsupported problem)

And thanks a ton for some quick work yesterday on the TD fix

Bugger...now I remember what i forgot

I dont have access to the code at the moment, but you can pretty easy set it up:

Each of the 5 arrays should have 3 active elements..

Each element is a cluster of:

 - A string value: "StringValue"

 - An array of clusters containing only one element - A numeric value: "NumericValue"

In the StringValue field, for the 3 indexes in each of the 5 arrays, just type some bogus value - Its really not important for the test..

The NumericValue field in the cluster arrays on the other hand are..!

In the following you will only need to enter values in the only index that are visible (0) - the value you enter are not important, only if the array itself are empty or not..

Array 1: NumericValues are all empty...

Array 2: Idx 1: Empty - Idx 2: Empty - Idx 3: some value

Array 3: Empty - some value - empty

Array 4: Empty - some value - some value

Array 5: some value - Empty - some value

Let me know if you got it, - if not I'll attach a new file tomorrow with the standard values set

If you attach a small project showing the problem, I can take a look at it.

I haven't had time to create a project, but I managed to whip up a small example showing off the unexpected behavior.

JSON Test.zip

I spend most of the day debugging this issue - and in the end I solved the problem by changing a value in my config data cluster from a type of U16 to U32, which solved the problem instantaneously..

Those were some pretty expensive 16 bits 

I managed to track down the reason as to why this happens, but still don't know if I know all the cases in which it can happen..

Edit: I haven't included any of the JSON VIs - so you're on your own doing all the relinking necessary to run the test..

Hi guys

I just now stumbled upon a (not so) funny mishab/error that i wanted to highlight for further investigation.

I relates to the JSON VIs use of the "Array of VData to VArray__ogtk.vi" to convert an array of independent (but equally typed) variants into a single array (as a variant)..

The reason I use the word 'mishab' is because I have a hard time figuring out if this actually classifies as a 'real' error and not just me using the JSON VIs in a wrong way

Take a look at the below image..

The text lister shows a snippet of the JSON text I'm trying to parse - an array of type Plugin Subscription containing another array of Subscription Elements.

The whole JSON text has been written by the JSON VIs themselves!

The "Array of VData to VArray__ogtk.vi" function fails because the first parsed element in the JSON text array 'Subscriptions' are used as the type descriptor for the resulting array.

This first index, however, does not have the necessary type information needed to contain the second element of Subscriptions, and thus fails in the conversion..

The "Array of VData to VArray__ogtk.vi" function is called as part of the recursive "JSON to Variant" VI, but at the moment I'm still narrowing down on the specific use case when this happens.

Updates will follow..

Sweet.

I'll take a gander later.

I think Ton is also planning to go over the change this weekend, just to let you know so you don't do any asynchronous work

Hi again

Regarding the post above I took the liberty of adding the functionality to the project.

I have attached a zip file containing only the VI's I have added or changed (folder structure has been kept) - feel free to add it to the project if you want..

Changes:

 + Added VI's for updating an existing JSON Collection Object value - by Array of names

 + Added VI's for removing a JSON Collection Object - by Array of names

 * Changed polymorphic Set VI to include new features .. the 'Set Object' function has been made into a submenu..

Best Regards

Stinus

Changes to tcplomp-json-api-labview-0c0d17447fc4.zip

Hi guys

Thumbs up for the good work!

I am creating a generic variant based intra-process configuration handler, and are considering using this as one of the user-selectable underlying 'file abstraction layers'.

However - since I plan on using an intermediate variant collection between the user and the file layer, I will need to be able to set new values in the JSON value tree without overwriting all other values.

Currently I don't see any way of doing this (I don't see a "Set sub-Item by names" function)..

Is this left out deliberately, or have you guys just not gotten around to it yet?! (or am I missing a point as to why it isn't implemented?)

Another thing, which may be better in a new post, is what is the restrictions on using icons from sites like the one you posted? It has a "Commercial Icons" section which is where you need to pay to use the icons in a commercial application or website. I don't intend on using it for a commercial application, but a work related one. Does that mean I don't need to pay to legally use these icons? I'm sure most people would just grab images from a Google search and use them without thinking about it, and maybe I should too, but I am just curious about what is legal.

Of course you're right,..whenever you are using material that are widely available or easily downloadable, there's a potential risk that you're actually crossing the legal boundary, and

maybe without even knowing it. I for one don't really check if every little icon picture I download and use in my own programs at home, are protected or covered by some legal rights.

However, that doesn't mean that I totally disregard the fact that some rules do apply!

For instance, I always stick to the Icon packages that we have bought and payed for in the company, when I do software that will end up at a customers site somewhere!

Hi Bjarne

Whenever I find myself in need of a new tray icon, I usually do a search on Iconarchive or Google using descriptive terms for the pictures I have in mind.

I then download the images or icon files I find interresting, or just the ones I think looks cool

If the file is an icon file I use an icon editor to remove icons bigger then 32x32px in the file (I stick with IcoFX v1.6.4 - mainly because its simple and doesn't have a trial timeout, newer versions do).

Also sometimes I use an old version of PaintShop Pro to apply transparancy to the image if it didn't exist already.

After that I just use the build in LabVIEW primitive "Read From Binary File" to read the file - that is, I create a new Untitled VI, insert the "Read From Binary File" function, wire the path input to a control, point it to the image file of your choice, wire a constant of -1 to the Count input (to have it read the whole file), and finally I create an indicator on the Data output terminal. Then I run the VI

Once the file is read and the content is displayed in the front panel indicator I go to the block diagram and right click on the indicator terminal and do a 'Convert to Constant' on it. Be aware though, some resizing is probably required..

There you go..

Happy coding

Some years ago i started out the task to create a VI editor that would let me edit the documentation of a VI without actually opening it (other than for reading the flat binary data of course).

This was a spare-time project but ended up being a sort of in-depth view into the fundamentals of the VI structure. Today i use the resulting class framework for mass documenting VIs

whenever i can (included in my editor is a fix for the long lost CTRL-B bold text combo that NI seems to have forgotten to implement).

The editor is pretty basic but are able to edit/change the VI Icon, History, some window properties, Set/Remove Load-and-go, add/remove VIs from libraries/llb/classes, shuffle around with some security stuff, show VI call hiearchy, create boolean 4-picture controls from gif/png/jpgs, extract VIs from old/new style labview exe's and a bunch of other stuff that are pretty handy when developing lots of LV code

Of course, it's all done through LabVIEW itself

I never thought of releasing the code because it probably violates every law out there, but if you spend a little time with a hex editor (or LV itself) its pretty basic figuring out how VIs are build.

Hint: once you figure out the structure of the VIs, you can use the OpenG function "ZLIB Inflate" to restore the packed sections to their normal size..

What I was trying to say is hackers adapt every 6 months or so to crack the latest LabVIEW, which makes me think that the same effort could be put into cracking LabVIEW passwords.

The real problem lies in the fact that is doesn't even take a skilled cracker 6 months to adapt, but more like 6 hours or 6 days at worst.

Using tools like Hey-Rays' IDA Pro you simply build a FLAIR recognition library that will help you seek out and identifies those hard-to-locate ASM functions in a matter of seconds.

Once found, it's only a matter of setting some breakpoints, run the target in a debugger and locate the areas of interrest. Then go and do some NOP'ing

Even the first time you have to disassemble an executable the size of the one for LabVIEW, there are some pretty good identifications tools out there that will sweep the file for any commonly known ASM routines .. like that of the MD5 hashing algorithm or the FlexLM/NET protection scheme functions.

In either case constants like 0x123456789 or piecing strings together at runtime doesn't really make it harder to find these points of interrest.

When talking about the VI security - As several people points out, the best protection really is to remove the block diagram and then put some trust into the fact that nobody has yet managed to Reverse Engineer the internal workings of the LabVIEW Runtime state machine.

Or at least not that I know of .. correct me if i'm wrong here

Your API is great, I just tried using it out and was impressed!

I have some feature requests that I think would make it even better (and these requests depend on the .NET API)"

1. If the clicked events could specify whether there was a right-mouse vs left-mouse click on a given menu/tray/balloon tip
2. If the balloon tip clicked event returned the balloon tip text

Thanks for your contribution to the community!

Those are really good suggestions!

I actually already did some of the mouse-button stuff as an update to the existing version, and now that I'm not the only one missing this feature I'll probably get around to finish it!

At the same time I should probably also try putting this in a nice OpenG package as mentioned by Stobber..

Looks Great!

I posted my own solution for this a little while ago:

NI Community: Icon in Windows system tray with LabVIEW

I'd love to hear some opinions comparing the two and offering suggestions. Maybe we can roll the best of each (assuming my solution has something worth keeping ) into one great tool! It's obvious there's demand for this. I know a number of people have used what I posted, and can see the same thing here.

Looks pretty interesting!..I'll definitely have a look at this tonight

Thanks for the feedback and positive comments..

Hope you put it to some good use in those GUI's out there...

/ Zero