LabVIEW Embedded/ARM with password = Crash to Desktop

[NicB]

Should we call this "reverse engineering" or ... robbery?

[tonykcrane]

Only if you consider copying an unprotected VI's block diagram from an unprotected ZIP file could this be considered reverse engineering.

Then again, I think "robbery" better fits the concept of re-posting something in the public domain.

Mind clarifying your question?

Tony

[NicB]

This thread doesn't need more argue.
Claire's reply is more than plausible and makes sense.

If I handled drawing the VI from the generated C in less than an hour then a software tool will do this in a second.
Password means protection and any workaround would be someone rights infringement.

[tonykcrane]

Indeed.

Dissent has herewith been crushed.

Good day to you.

[Claire_Reid]

Hi Tony,

I sent a message to R&D and still haven't heard back from them. My guess is there won't be any change to their stance on this issue. Especially because this VI is not one of our VIs.

Regards,

Claire

[tonykcrane]

Understood.  A nice error message or refusal to compile would be preferable to the environment simply dissapearing, but I have no illusions that the embedded compiler will ever be compatible with LabVIEW's password protection system.

Thanks,

Tony

[Jaidev]

Hi Tony,

I work with the R&D team that develops LabVIEW Embedded and let me respond to your question directly:

1. I agree that the LabVIEW generated C code is fairly hard to read, but with certain optimizations such as "Serial only" enabled, the code becomes pretty easy to follow. The code that is generated by default has the LabVIEW scheduler built in, which makes it convoluted but experienced users like NicB have no problems decoding that either. LabVIEW App builder can adopt a different policy for this because they convert your VI into machine code directly, there is no way (that I know of) to retrieve even the assembly. Now arguably you could reconstruct the algorithm from machine code but you'll admit its a lot harder than doing it from C.

2. VIs shipped by NI are password protected either for intellectual property reasons or because users modifying the behavior can lead to unforeseen consequences. In the embedded context, they can contain labVIEW primitives that we do not support, like property nodes.

Having said this, let me assure you that we are very receptive to your questions and requests. I am, in fact working with Claire to see if we can do something about the password protection. However if the password protected VI is shipped by Endevo (as Claire said in one of her posts), we might not be able to do much. If this VI is one of our own, I will certainly talk to the developer who wrote it and keep you posted.

Thank You,

Jaidev Amrite

[tonykcrane]

Jaidev,

Thanks for the response, it's greatly appreciated.

I apologize for being snippy, I was rather put off by NicB's abrasive comment.  (Not that this excuses similar behavior...) 

NicB, if you really did translate that snippet from the C code, then you're definitely not being paid what you're worth.

I guess to that point, it's true that the App Builder's bytecode output is compressed and encrypted, but as many have pointed out, (Google "security through obscurity" sometime for an interesting read.) even the best encryption systems are vulnerable to at least one method of attack.  (Granted, it's completely outside my sphere of desire to have a couple thousand processors brute force attacking LabVIEW's encryption for the next 3 billion years just to crack a single VI...)  However, the password protection system definitely does a good job of keeping the vast majority of prying eyes out of the more sensetive bits behind the scene, and rightfully so.  I myself make use of a (freely available) password to notify my customers when they're crossing a boundary they really shouldn't be crossing unless they know what's really going on.

It's not my intention to extract IP from protected VIs, C code, or even from what could be inline assembler.  (Or even, for that matter, an encrypted C file using a shared key/method/etc between Keil and NI.)  I simply would like to be able to use the same technologies in the Embedded world that I do in the bigger world.  (Mainly GOOP.)

While you're investigating on your end, I'll talk with Endevo to see what options they are willing to open up to make this happen.

Thanks for the response,

Tony

[Jaidev]

Hi Tony,

I think NicB was just trying to show that with a little experience, it is possible to reconstruct the algorithm. You said earlier that you liked the product and so if you end up using these forums regularly, you will see that NicB is certainly one of our smartest and most helpful contributors. I am hoping you'll be one too 🙂

Now for the matter at hand, our policy of not generating code for protected Vis may not change because there could always be primitives in there that break the build. But if you hit one of our VIs that prevent you from generating, we can explore the possibility of unlocking it. In this particular case, Endevo would need to provide you with the passwords.

I hope this is acceptable to you,

Jaidev

PS: I completely understand that you are not interested in extracting IP from these VIs, you just do not want to be restricted by our system. Hopefully, you see our perspective on why the system exists.

Message Edited by Jaidev on 10-22-2009 06:37 PM

[tonykcrane]

Jaidev,

Well, NicB definitely did what he set out to do.  And my personal preference on response style and tact probably will not get my anywhere with NicB, but that's life.

I'm having a slight problem understanding why generating C code for protected nodes/VIs would cause the primitives to not work.  The policy is not my problem here, it is what it is.  (And even if it was a problem for me, it's not going to change just because I'm all grumpy about it.)  Maybe the problem is that I'm not familiar enough with the LabVIEW scheduler (Which I would definitely like to learn more about, it seems to be a very elegant solution to an enourmously complex problem) or the C generation subsystem to know the subtleties of just why an unsupported node could not be converted to C.  Not a biggie.

Still looking into Endevo, but OpenGOOP may be the only "real" option left...

Thanks again,

Tony