EXE back to buildable project

[Mefistotelis]

I have a built LabView 14 project which I want to get back to a form which would allow me to "build" it again.

My programming skills are high, but LabView skill is almost non-existent.

 

I found LLB file within the Windows Resources of PE Executable.

I noticed the LLB file contains one, large "block" of data inside, called 'LVzp', which is encrypted.I wrote proper xor-based decryption algorithm.

This resulted in a Zip file. I extracted the ZIP, and found many folders and files inside.

Some folders have names which indicate they might've been libraries in original project, but were all extracted and put into directory structure instead. For example, I see a folder "vi.lib", and inside there's a folder "dlg_ctls.llb".

Now to my questions:

How should I prepare all that for re-building?

Should I re-create all the LLB files from single VI files I see in extracted folders?

Should I also create LIB files before adding everything to a new project? I understand that "New -> Library" in project view creates LLB file, how do I create LIBs?

Or maybe adding everything to a project as-is will work as well?

Are any specific actions needed to re-create a project out of these files? I figured all the "Remove ..." options in "Additional Exclusions" tab of build target need to be unchecked, anything more?

 

[hooovahh]

This likely won't get you very far.  Yes you have the files that are in the EXE extracted which is useful.  And in theory you should be able to add all those files to a project and rebuild it.  But if you are trying to do this so you can rebuild in a newer version of LabVIEW, or so you can edit some part of the EXE, then you aren't going to be able to.

When a set of VIs are turned into a binary, they are compiled for that that target and runtime version.  Then in almost all situations the block diagrams are removed, and in many cases the front panels are removed.  What is in the EXE is then still VI files but most are just the compiled component with no source, and no way to edit them.  If when you built the EXE debugging was enabled then block diagrams and front panels will still be included, and then extracting the files will mean you can get the VI source out, and then it can be recompiled or edited like any normal VI.  So the files you extracted could probably be added to a project, and then rebuilt, but you won't be able to edit anything in any of the VIs.  I guess you might be able to replace one of the VIs with a new one from source if you recreate all the functionality of it, and have the same connector pane and name but I've never tried that.  Still anything you discover is good information and the community welcomes any thing you are able to figure out.

[Aristos Queue]

I'm intellectually intrigued by the project, but I hesitate to help since the tool you're building would allow someone to create a new EXE that looks like an EXE that might come from some reputable source but has had various key components replaced. That is, of course, something someone could do today (in LV or any other programming language), given enough effort and time. But it takes effort and time, and I don't think I should help short circuit that, given who I work for.

I am interested in your use case. I take it you have some EXE that you don't have the source code for but you need/want to make changes?

[Mefistotelis]

Thanks for your answers.

 

For my use case:

I have an EXE of a tool which has some functions not working according to needs, I was asked to update these. Not anything desperately needed, but would increase user base of the tool.

The tool is proprietary, and quite large - 30MB EXE. There is a lot of things inside, and I was hoping I won't have to look at details. Files go in thousands, didn't checked exactly.

I am not planning on changing LV version; that would require more effort, and that's not really needed.

 

For my progress:

I see that LLB folders don't have to be merged into library - the LV itself has a set of folders with .llb extension, so that's normal.

I looked at the VI files, and the do miss the edit functionalities. I will check other versions of the tool, but I expect that will be the case for every version.

I tried creating a project and adding everything to it; but the resulting EXE is half of the size of original EXE - so maybe LV cannot see some dependencies? Or the original project has some unnecessary dependencies in it?

I don't even understand all functionalities of the tool, so can't tell if my version lost something.

 

 

[Aristos Queue]

> The tool is proprietary

So you cannot just rebuild from source code because you don't own the source code? I'm going to assume the EULA agreement on this tool lets you do this. If it doesn't, please don't tell me... that's between you and the code owner. But you might consider contacting the author of the tool and asking for the source code and/or asking for some specific changes. Sometimes asking works, and either would be less work than reverse engineering LV's internal EXE structure.

[Mefistotelis]

I mostly meant that this is internal tool used by a company, created years back. Not sure if it was created internally on by a contractor.

 

Anyway, looks like the tool re-compiles properly from the reversed sources. Can't be completely sure as I don't have a related hardware, but various forms are properly linked to each other and are trying to display something.

The original project probably had some fake dependencies in it - the smaller binary I built seem to do the same thing as original. (though I can't be sure there's no corner case where it will go "file not found")

General steps:

1. Extract EXE, decrypt ZIP inside

2. Create a folder, create new LabView project there

3. create sub-folder within project folder, ie. "app" or "lv" or however you want to call the labview app part; copy the files extracted from ZIP there

4. Copy any config and data files (and folders) distributed with original binary to the project folder

5. Copy options from BinryName.ini into your BinaryName.lvproj (created in step 2)

6. Open the project in LabView

7. Add each folder from your labview app part to the project; use "My Computer" -> "Add" -> "Folder (Auto-populating)"

8. Make new build target; use "Build Specifications" -> "New" -> "Application"

9. Set proper "Name: and "Target filename" in build target "Information" tab

10. Find the starting form of the original app and add it as "Startup VIs" in build target "Source files" tab

11. You shouldn't have to put anything in "Always included" list in build target "Source files" tab; but if you want - you can now

12. Disable all the "Remove ..." and "Disconnect ..." options in build target "Additional Exclusions" tab

13. Fix any "Missing items" in the project, by placing files in correct places or modifying *.lvlib files which point to locations of additional files

14. Build the project

 

Now I'm getting interested in the single VI files, and how to get their edit functionality back.

 

Edited October 18, 2019 by Mefistotelis

[Rolf Kalbermatter]

On 10/18/2019 at 11:13 AM, Mefistotelis said:

I mostly meant that this is internal tool used by a company, created years back. Not sure if it was created internally on by a contractor.

Now I'm getting interested in the single VI files, and how to get their edit functionality back.

That's about the same as when you have a DLL and want to get the C source back! Rewriting it from scratch!

As explained before, those VIs inside an executable have their diagram and usually front panel completely stripped out. They are not hidden or anything, they are simply completely gone, nada, futschi, niente! LabVIEW doesn't need them to execute the VI in an executable, so why keep it and ballon the executable size unneccessarily? Also there are many people who do not want their source code (and precious IP) handed out to their users and they would be very upset if LabVIEW executables contained the full source code, no matter how much hidden. So the safest thing to do is to remove it, what is not there can not be stolen!

The only thing inside such a VI is the actual compiled code (machine code instructions for the CPU it is meant to run on) and some linker information so LabVIEW can piece the VIs together when loading the whole hierarchy and connect the correct terminals with the data values that are represented through the wires that go into the node, only the wires in the calling diagram are gone too just as the rest of the diagram. Still for the compiled code that is enough.

So you could with lots of trickery and reverse engineering retrieve the machine code streams from the VIs and feed them piece for piece to a disassembler and then you end up with Assembly Code text, the text form of the lowest level machine instructions that the CPU processes. This is source code too, but not something that most people will easily understand. It is one level deeper than C programming and several levels deeper than LabVIEW diagram code! To regenerate C from assembly code while not easy and not automatic is possible, going from assembly to LabVIEW is pretty much futile except for the approach of describing the algorithme involved from the assembly code and then recreate it in LabVIEW. The problem is that going from assembly code to something like "Read channel 0 from DAQ board 1, turn it in a hex string and write the result to GPIB instrument at primary address 4 on GPIB bus 0" would likely cover 10 pages of assembly code and would be hard to deduce from those 10 pages without very careful study. It would be in absolutely all cases quicker and more effective to simply put up a high level description of what the application does and reimplement it from scratch based on that. This is one of the reason the other approach has never been really tried and the effort is to big to allow a hobbyist to try it for fun.

Edited October 20, 2019 by Rolf Kalbermatter

[Mefistotelis]

Yes, you might be right @Rolf Kalbermatter.

As long as the whole work can be divided into steps, this might be doable though. For example - there is probably a way to tell labview to compile the assembly. So only disassembling the code, still puts us one step closer, and allows us to create buildable project.

Right now, I already can replace single VIs and re-build the project. Having ASM blocks would allow me to replace only single blocks inside VIs.

 

For the people who fear for their code being stolen - if the current solution is broken, NI will put resources into making "real" security in next version - so such reversing effort actually makes the tool more secure, and forces it to move to modern standards.

 

I'd have to learn about LabView in general to go any deeper; last time I made a project with it was circa 20 years ago. Not sure if I have enough time to go that way.

 

[Rolf Kalbermatter]

On 10/21/2019 at 2:14 PM, Mefistotelis said:

For the people who fear for their code being stolen - if the current solution is broken, NI will put resources into making "real" security in next version - so such reversing effort actually makes the tool more secure, and forces it to move to modern standards.

There is nothing broken! It's the nature of the beast that the CPU needs to be able to read the machine instructions in order to execute them. If the CPU can anyone else can too unless you execute on special security enhanced CPU engines where the code is encrypted and only decrypted inside the CPU itself with no external access to that decrypted code. Such hardware is however VERY specialized and VERY expensive and VERY unusual.

Good luck in your attempts but there are a lot more interesting and beneficial things to do with your time than "breaking" LabVIEW VIs. Especially since it is not breaking but simply piecing together all kinds of information that has to be present in various ways in order to be even functional. If LabVIEW VIs were broken in that context, every single Windows, Linux, Mac and whatever executable and shared library would be broken too. And especially the much loved .Net assemblies! Reverse engineering them is even with obfuscation a piece of cake. Still tedious, sure, but much easier than trying to reverse engineer a LabVIEW executable from getting all the VIs out and disassembling every machine code stream for each VI and figuring out the linker information to piece those disassembly streams correctly together.

Edited August 29 by Rolf Kalbermatter

[hooovahh]

5 hours ago, Mefistotelis said:

if the current solution is broken

It is not.

5 hours ago, Mefistotelis said:

NI will put resources into making "real" security in next version

They will not.

5 hours ago, Mefistotelis said:

so such reversing effort actually makes the tool more secure, and forces it to move to modern standards.

As stated this is how all programs work.  You cannot keep the executable safe, while also having it be open enough to execute it.  I do hope you share anything you discover with the community, I just expect what you will discover is that reversing a binary of any kind to its source will take forever, be error prone, will be incomplete, and won't be very useful.  This will especially be true for LabVIEW as the tools for this disassembly are less mature than other languages.

[Mefistotelis]

7 hours ago, Mefistotelis said:

 if the current solution is broken

I see that ambiguous wording got a strong reaction. Yes, the format is not broken/cracked currently.

I actually only found two readers for VIs, both quite rudimentary: one in Python, other in PHP.

1 hour ago, hooovahh said:

I do hope you share anything you discover with the community

I am typically sharing everything I can share. For the specific subject discussed in this thread, see here:

https://github.com/mefistotelis/pylabview/commit/867dac8e2f249978defa380110efb744ff52c650

1 hour ago, hooovahh said:

You cannot keep the executable safe, while also having it be open enough to execute it

Currently, yes. Though we already have certificates fused into out CPUs, ie. for Protected Audio Video Playback. And there is a lot more of them.

On ARM, we recently see explosion of TrustZone use. Same principle - protect the code but allow its execution.

 

I do hope the world will not go this way; but currently, as tools for reversing get better, the push towards protecting them by hardware also increases.

 

Edited October 21, 2019 by Mefistotelis

[Aristos Queue]

Speaking as a 19-year dev in LabVIEW R&D, Hooovaaah is pretty much right. NI wouldn’t do anything to change our EXE format because of this work. None of the current design is viewed as a security layer. 

We’ve talked about secure computing initiatives in R&D. NI will probably lag the curve there (NI tends to adopt tech when it is already commodity), but I suspect it’ll happen this decade. I very much hope the world gets there soon. Unsigned EXEs are a major threat vector, and the IOT threat just keeps increasing. The world can’t afford to keep running arbitrary code much longer, in my opinion. 

[Aristos Queue]

5 hours ago, Mefistotelis said:

as tools for reversing get better, the push towards protecting them by hardware also increases.

 

The reverse engineering isn’t the driver of trustzone and similar. The driver is the threat of untrustworthy code being distributed by malicious authors. We need a chain of trust back to the original code author in all cases. 

[ShaunR]

2 hours ago, Aristos Queue said:

Unsigned EXEs are a major threat vector, and the IOT threat just keeps increasing. The world can’t afford to keep running arbitrary code much longer, in my opinion. 

I have done this for VIP, and Zip packages for an installer I've had on the back burner for a while.

[hooovahh]

17 hours ago, Mefistotelis said:

I actually only found two readers for VIs, both quite rudimentary: one in Python, other in PHP.

I reversed the PHP code into LabVIEW here as well, adding just a few features.  Also you've probably come across Flarn's stuff, he has some code for object deconstruction getting into pulling out and manipulating objects in the LabVIEW source.  Which is neat but probably isn't what helpful for what you are doing.

[Mefistotelis]

On 10/22/2019 at 2:41 PM, hooovahh said:

you've probably come across Flarn's stuff

Actually, I didn't. Tried searching after your post, but only found hidden options thread.

 

I had a long fight with "conflicts" after I tried to update the reversed project, and now I'm seeing:

"VI's record of owning library's password does not match library's actual password."

I did removed password entries from library files. I see the copy of these passwords (i mean, md5 of passwords) in VI files (LVSR section). Will check if I can easily remove these.

 

[hooovahh]

When a VI is in a library, the password is stored in the VI, and in the library, and there is some kind of link in the password of the VI to the library, in the VI.  So if you recreate a VI, and it doesn't have a password but the library does, or if the two passwords don't match, then you will get that error.

Now that I'm searching for it I can't find much, but Flarn also had some code for getting file structures of a VI.  His personal site had a few things but seems to be down at the moment.

http://flarn2006.dyndns.org/llvim/#downloads

Just be aware that most of his stuff is viewing and editing the objects in a VI, so I'm not sure how useful it will be.  But he should have some general file parsing stuff.

[Michael Aivaliotis]

On 10/21/2019 at 5:41 PM, Aristos Queue said:

Unsigned EXEs are a major threat vector, and the IOT threat just keeps increasing. The world can’t afford to keep running arbitrary code much longer, in my opinion.

I sign all my built EXEs, for all my customers. It's trivial to do and doesn't cost much. This also allows me to know if the application that I'm asked to support was built by my company or the customer did the rebuild themselves.

[Aristos Queue]

4 hours ago, Michael Aivaliotis said:

I sign all my built EXEs, for all my customers. It's trivial to do and doesn't cost much. This also allows me to know if the application that I'm asked to support was built by my company or the customer did the rebuild themselves.

That's level 1 signing, to verify provenance. Good practice, but what we are talking about is level 2 signing, which requires you to submit your EXE to MS/Intel/Apple/etc to have it signed by the chip's own signature. Without that, a secure CPU will refuse to run your code. MS/Intel/Apple/etc would pretty much operate the way Apple does with the Apple App Store, where they vet who you are, why you're putting this EXE out into the world, etc.

A company could create their own signature (derived from the MS/Intel/Apple/etc) signature and install that on all the CPUs of their company, and that would let them sign their own apps. So you would deliver your EXE to your customer and they would have to sign it before installing it on their machines.

[ShaunR]

 

9 hours ago, Aristos Queue said:

MS/Intel/Apple/etc would pretty much operate the way Apple does with the Apple App Store, where they vet who you are, why you're putting this EXE out into the world, etc.

Chinese, Russian and North Korean companies too?

9 hours ago, Aristos Queue said:

A company could create their own signature (derived from the MS/Intel/Apple/etc) signature and install that on all the CPUs of their company, and that would let them sign their own apps. So you would deliver your EXE to your customer and they would have to sign it before installing it on their machines.

Excuse me if I'm not entralled by allowing M$/Intel/Apple/etc backdoors or control of what I can and can't run in an age where computers are always connected and OS telemetry is rife. I reject this dystopian sales pitch for "security" which is nothing more than a hardware version of Certificate Authorities aimed squarely at market control.

Edited November 1, 2019 by ShaunR

[ShaunR]

14 hours ago, Michael Aivaliotis said:

I sign all my built EXEs, for all my customers. It's trivial to do and doesn't cost much. This also allows me to know if the application that I'm asked to support was built by my company or the customer did the rebuild themselves.

Signing is great but just be aware the weakness is key distribution. Not so much a problem with physical distributions but a concern over the internet depending on your threat model.

[Aristos Queue]

6 hours ago, ShaunR said:

Chinese, Russian and North Korean companies too?

If they can be vetted and approved for signing. But the big point is that unsigned code simply cannot execute on these CPUs, so unknown actors cannot approve.

 

6 hours ago, ShaunR said:

Excuse me if I'm not entralled by allowing M$/Intel/Apple/etc backdoors or control of what I can and can't run in an age where computers are always connected and OS telemetry is rife. I reject this dystopian sales pitch for "security" which is nothing more than a hardware version of Certificate Authorities aimed squarely at market control.

But you are already in that situation. The operating systems already can (and do) lock out a bunch of functionality. OSes and CPUs can already break backward compatibility if they choose. You already trust those companies deeply.

"nothing more"? Yes. It is exactly that. I don't know what you mean by nothing more... it should be "nothing less than Cert Authority", which is what we have today.

Also, as I said, you can get your own signature for installation on your CPU to allow you to sign other apps. The system doesn't make you beholden to those companies. But it does keep foreign code that gets smuggled onto your system from executing, which is a massive and rising problem today.

[ShaunR]

3 hours ago, Aristos Queue said:

If they can be vetted and approved for signing. But the big point is that unsigned code simply cannot execute on these CPUs, so unknown actors cannot approve.

They will be vetted and approved by their respective governments. The problem as I see it isn't limiting execution to signed code, it is who has capability to create and control the keys. "Derived keys" are weasel words for backdoors. But I see it as worse than that. These proposed hardware keys only limit what you can run, not what they (M$ et.al.) can run and they are major players in my threat model.

Remember the the Clipper Chip? Or the Apple "Kill Switch"?. These kinds of technologies are packaged as "security" but give the corporate behemoths an inordinate amount of control over your devices.

The technology already exists for self-signed secure boot. and a similar route for execution is far more appropriate. You don't need to trust anyone else but yourself (by that I mean your company) - you can't outsource security!

3 hours ago, Aristos Queue said:

You already trust those companies deeply.

Nope. I don't trust them as far as I can throw them.  I go to great lengths to mitigate exfiltration of information to the likes of Google, M$ (i refuse to use Apple products) etc. I block all sites that are behind Coudflare (which is a MITM) and I use my own servers for things like Git, SVN, Jenkins etc. I realise the current trend is for online services (e.g Github) storing all your data but this is folly IMO.

I may have to use a M$ OS, but I can and do limit their ability to leverage their indisdious telemetry and who has Driver Signing turned on?

3 hours ago, Aristos Queue said:

it should be "nothing less than Cert Authority"

The annointed ones? China has it's own Certificate Authorities so good luck with that if your data gets routed through their servers. Cert Auth is a poor solution that only really works for the man-in-the-street because the root certificates are routinely distributed with browsers (Windows updates it's store once a week, IIRC). When did NI last update their users' LabVIEW CA file for the HTTPS Vis? What exactly is NI's policy on this and where is it documented?

Edited November 1, 2019 by ShaunR

[Mefistotelis]

On 10/31/2019 at 6:19 PM, hooovahh said:

Now that I'm searching for it I can't find much, but Flarn also had some code for getting file structures of a VI.  His personal site had a few things but seems to be down at the moment.

http://flarn2006.dyndns.org/llvim/#downloads

Just be aware that most of his stuff is viewing and editing the objects in a VI, so I'm not sure how useful it will be.  But he should have some general file parsing stuff.

Thanks; I can look at the page using Wayback Machine, plus I found the related thread:

 

The LVSR block I want to modify is used to compute checksums which are stored in BDPW (Block Diagram Password) block. So I need to be able to re-create the BDPW values in order to modify LVSR.

Fields within BDPW, depend on counts of some connectors which are buried deep within VCTP (Virtual Connectors / Terminal Points).

I'm now baffled with how connector entries which affect the checksum are selected. It looks like one of interface connectors is used (also referred to as Terminal connector), but I have no idea how to pick which of the interfaces will be used.

 

Edited November 2, 2019 by Mefistotelis

[hooovahh]

Oh yeah I forgot about that.  This is the Salt that gets applied to the MD5 of the password.  Starting in 2012 NI started salting the block diagram passwords.  The salt that gets applied is something like the number of all String, Path, and Numeric controls connected to terminals.  I think this does go into clusters and arrays so the work actually needs to be recursive.  This ends up being a 12 byte salt, but I think 9 bytes are always 0.

Of course you don't need to do all of this, to figure out what the salt is.  I mean all you need to do is guess three numbers, all of which are the number of controls on a terminal so you know that the value will probably be small.  So when I wanted to figure out what the salt was I would just keep guessing until a match was found.  It was easier than trying to look into the VCTP block to find all objects, and then all terminals, and blah blah blah.  If you have a VI that is passworded correctly then the only unknown in the equation is the salt.  I mean lets use this example equation (note that the actual one is different):

Result = MD5(Hash 1 + Hash 2 + Hash 3 + Salt)

In a valid passworded VI I can pull out each of the variables from the VI other than the salt.  So I just made a VI that sets salt to 0,0,0, then 0,0,1, then 0,0,2, etc, until the equation matches.

Fun story:  Years ago we were in a meeting with a few LabVIEW champions and LabVIEW R&D and the discussion of protecting intellectual property came up.  Someone was asking NI about ways they could tighten up their security.  I made a suggestion of encrypting the password with the number of string terminals in a VI,  knowing that this was something NI already was doing.  Another LabVIEW Champion said that was a bad idea since that could be figured out by simply opening the VI and looking at it.  I had to inform them that I said that knowing that that scheme was actually used by NI, and I put that out there to subtly let R&D know we know about it.