Ida Pro View Decompiler
Gene Honnette
A friend of mine downloaded some malware from Facebook, and I'm curious to see what it does without infecting myself. I know that you can't really decompile an .exe, but can I at least view it in Assembly or attach a debugger?
With a debugger you can step through the program assembly interactively.
With a disassembler, you can view the program assembly in more detail.
With a decompiler, you can turn a program back into partial source code, assuming you know what it was written in (which you can find out with free tools such as PEiD - if the program is packed, you'll have to unpack it first OR Detect-it-Easy if you can't find PEiD anywhere. DIE has a strong developer community on github currently).
Additionally, if you are doing malware analysis (or use SICE), I wholeheartedly suggest running everything inside a virtual machine, namely VMware Workstation. In the case of SICE, it will protect your actual system from BSODs, and in the case of malware, it will protect your actual system from the target program. You can read about malware analysis with VMware here.
psoul's excellent post answers to your question so I won't replicate his good work, but I feel it'd help to explain why this is at once a perfectly valid but also terribly silly question. After all, this is a place to learn, right?
Modern computer programs are produced through a series of conversions, starting with the input of a human-readable body of text instructions (called "source code") and ending with a computer-readable body of instructions (called alternatively "binary" or "machine code").
The way that a computer runs a set of machine code instructions is ultimately very simple. Each action a processor can take (e.g., read from memory, add two values) is represented by a numeric code. If I told you that the number 1 meant scream and the number 2 meant giggle, and then held up cards with either 1 or 2 on them expecting you to scream or giggle accordingly, I would be using what is essentially the same system a computer uses to operate.
Now, assembly language is a computer language where each command word in the language represents exactly one op-code on the processor. There is a direct 1:1 translation between an assembly language command and a processor op-code. This is why coding assembly for an x386 processor is different than coding assembly for an ARM processor.
Disassembly is simply this: a program reads through the binary (the machine code), replacing the op-codes with their equivalent assembly language commands, and outputs the result as a text file. It's important to understand this; if your computer can read the binary, then you can read the binary too, either manually with an op-code table in your hand (ick) or through a disassembler.
Disassemblers have some new tricks and all, but it's important to understand that a disassembler is ultimately a search and replace mechanism. Which is why any EULA which forbids it is ultimately blowing hot air. You can't at once permit the computer reading the program data and also forbid the computer reading the program data.
However, there are caveats to the disassembly approach. Variable names are non-existent; such a thing doesn't exist to your CPU. Library calls are confusing as hell and often require disassembling further binaries. And assembly is hard as hell to read in the best of conditions.
If you are just trying to figure out what a malware does, it might be much easier to run it under something like the free tool Process Monitor which will report whenever it tries to access the filesystem, registry, ports, etc...
You may get some information viewing it in assembly, but I think the easiest thing to do is fire up a virtual machine and see what it does. Make sure you have no open shares or anything like that that it can jump through though ;)
Immunity Debugger is a powerful tool to write exploits, analyze malware, and reverse engineer binary files. It was initially based on Ollydbg 1.0 source code, but with names resoution bug fixed. It has a well supported Python API for easy extensibility, so you can write your python scripts to help you out on the analysis.
What I would like though is to change the default editor from Class File Viewer to Class Decompiler Viewer so when I open a *.class file (e.g. by double-clicking it in the Package Explorer view or via the Open Type... dialog) it opens directly in the right view.
At the moment *.class files are consistently opening in the Class File Viewer editor regardless of my settings. I have to go back to the Package Explorer view, right-click the *.class file and select the desired decompiler explicitely in the Open Class With option to get it open in the Class Decompiler Viewer editor.
I have set the Class Decompiler Viewer editor as the default one for *.class files, applied, restarted Eclipse even, but still all the *.class files I open are coming through the Class File Viewer by default.
One of our customer (Pharma industry) has a compiled LABView application running on Win98 for +10 years. The source code is not available and it seems nobody knows what's under the hood. Based on Win98 dates, I expect them to run a LABView version between v4 and v6.
I never tried it, but I recall hearing that in older versions of LV executables were a special kind of folder or compressed file. Try moving a copy of the executable to a different computer with the LV development environment. Then change the extension from .exe to .llb and see if you can open it. You may need an older version of the LV development system, depending on what version the executable was in.
I don't believe there's a decompiler available for any version of LabVIEW. However, in older versions of LabVIEW (prior to 8, if I'm not mistaken) a compiled LabVIEW application was pretty much a ZIP file with all the VIs inside. Try renaming a copy of the application, replacing the .EXE extension with .ZIP, then see if you can look inside it. You might be able to get a list of all the VIs, and with some luck they will have been named in a way that gives you some clues. If you get this far, and you can identify and install the correct version of LabVIEW (probably including patch release), you might then be able to drop those VIs into the block diagram of a new VI. You won't be able to see the front panel or block diagram but you'll at least be able to identify the terminals of the subVIs and see the output with different inputs.
The whole issue is a little bit more complicated. Before LabVIEW 8.6 the internal executable resource was indeed a LabVIEW VI archive (LLB) and since LLBs have only one hierarchy depth it is basically like a single directory. This caused troubles with the newer LV library based instrument drivers and also LVOOP classes which use the same VI name but with a different library prefix each, so that LabVIEW had to move those files to external directories when building executables, in order to avoid naming collisions.
In all newer LabVIEW versions the internal executable resource in which the VIs are stored is in fact a ZIP file by default. You still can force LabVIEW to use an LLB format to store the files, by enabling the "Use LabVIEW 8.x file layout" in the Advanced build options. Now the ZIP resource was in the beginning stored as simple ZIP formatted data resource and that caused some problems since most ZIP utilities simply scan a file for the ZIP file header and open it as such, even if the actual ZIP file resource is anywhere inside the file, so that almost all ZIP tools could open a LabVIEW executable. NI changed that format so that ZIP tools can not recognize it anymore.
Now, yes you could look into the LLB and ZIP resource in the past (and still can with some extra effort) but before anyone screams "Ohhh my precious IP is on the street" please be aware that the only thing you can do from such a resource is to get the VI names and if you manage to load it into the exactly right LabVIEW version drop the generic icons onto a diagram to see the connector pane. Unless of course you also check the "Enable debugging" checkbox in the Advanced build options, which will leave the diagrams and frontpanels in the VIs, and in fact create something similar to a packed source distributions.
So without the Enable debugging build option, someone gets in fact not much more than what he can do by opening any binary DLL created from C, C++, or whatever mainstream compiler with the dependency tool from Microsoft and MUCH MUCH less than what you can get by simply putting such a DLL through a disassembler.
I will gather additional information from the client such as LV exact version, existing documentation, "debug" feature enabled or not... But, based on you answers, my expectation went from "It might be possible" to "Let's find another way".
Actually before LabVIEW 8.0 or so there was no officially sanctioned way to create executables that would not have removed diagrams. There was some Application Builder utility from OpenG that would open up some extra features to the application build process, but it had many other issues from using undocumented LabVIEW interfaces so I doubt it was ever used in commercial grade applications.
As the previous posters have said, the older ".exe" were in fact .llb files. You can, if it is opened in the correct version of LabVIEW, drop the sub-vi's onto a blank diagram and get names and connector types, which, if the program is complex, will tell you little. If the original programmer was very verbose and descriptive in naming the sub-vi's you might get an idea of what they do, but no structural info (other than provided by the input and output connectors, a real jigsaw puzzle!) to tell you how it fits together, just essentially a bunch of "black boxes" without any indication of what goes on within them. Much better to get a detailed requirements document of what the customer thinks/wants the tester to do and build it from scratch. Any changes to the existing program, if it were possible, would require requalification testing anyway, so building from scratch is a good idea. The real critical aspect though, is the detailed requirements document! Good Luck!
93ddb68554