Is There a Way to Tell What Language Was Used for a Program?

Question

I have a desktop program I downloaded and installed. It runs from an .exe file.

Is there some way from the .exe file to tell what programming language was used to write the program?

Are there any tools are available to help with this?

What languages can be determined and which ones cannot?

---

Okay here are two of the sort of things I'm looking for:

1. Tips to Determine Whether an App is Written in Delphi or Not

2. This "IsDelphi" program by Bruce McGee will find all applications built with Delphi, Delphi for .Net or C++ Builder that are on your hard drive.

Answer 1

I use WinDowse (a small freeware utility written in Delphi) to spy the windows of the program.. for example if you look at the "Class" TabSheet you can discover the "Class" Name of the control..

For example:

• TFormXX, TEditYY, TPanelZZZ for delphi apps
• WindowsForms10.XXXX.yyy, for .NET apps
• wxWindowsXXX for wxWindows apps
• AfxWndXX for MFC/VC++ apps (I think)

I think this is the fastest way (although not the most accurate) to find information about apps..

Answer 2

First, look to see what run time libraries it loads. A C program won't normally load Visual Basic's library.

Also, examine the executable for telltale strings. In most executables, this is near the end. If the program uses string constants, there might be a clue in how they are stored.

Answer 3

I understand your curiosity.

You can identify Delphi and C++ Builder apps and their SKU by looking for a couple of specific resources that the linker adds. Specifically RC Data\DVCLAL and RC DATA\PACKAGEINFO. The XN Resource Editor makes this a lot easier, but it might choke on compressed EXEs.

EXE compressors complicate things a little. They can hide or scramble the contents of the resources. Programs compressed with UPX are easy to identify with a HEX editor because the first 2 sections in the PE header are named UPX0 and UPX1. You can use the app to decompress these.

Applications compiled with .Net aren't difficult to detect. Recent versions of Delphi even include an IsAssembly function, or you could do a little spelunking in the PE header. Check out the IsManaged function in IsDelphi.

Telling which .Net language was used is trickier. By default, VB.Net includes a reference to Microsoft.VisualBasic, and VCL.Net apps included Borland specific references. However, VCL.Net is defunct in favour of Delphi Prism, and you can add a reference to the VB assembly to any managed language.

I haven't looked at some of the apps that use signatures to identify the the compiler, so I don't know how well they work.

I hope this helps.

Answer 4

A good disassembler, plus of course an excellent understanding of the underlying CPU architecture, can often help you identify the runtime libraries that are in play. Unless the exe has been carefully "stripped" of symbols and/or otherwise masked, the names of symbols seen in runtime libraries will often provide you with programming-language hints, because different languages' standards specify different names, and vendors of compilers and accompanying runtime libraries usually respect those standards pretty closely.

Of course, you won't get there without knowledge of the various possible languages and their library standards -- and if the code's author was intent to mask the information, that's not too hard for them to do, either.

Answer 5

If you have available a large set of samples from known compilers, I should think this would be an excellent application for machine learning. I believe so-called "supervised learning" is relevant here. Unfortunately I know next to nothing about the topic—only that I have heard some impressive results presented at conferences.

You might dig through the proceedings of the Working Conference on Reverse Engineering to see if anyone else is interested in this problem.

Answer 6

Assuming this is an application for Windows...

Does Reflector recognize it as a .NET assembly? Then it's MSIL, 99% either VB or C#, but you'll likely never know which, nor does it matter.

Does it need an intrepreter (like Java?)? Then it's Java (or whatever the interpreter is.)

Check what runtime DLLs it requires.

Does it require the VB runtime dlls? Congratulations, VB from VisualStudio 6.0 or earlier.

Does it require the Delphi dlls? Congratulations, Delphi.

Did you make it this far? C/C++. Assume C++ unless it requires msys or cygwin dlls, in which case C has maybe a 25% chance.

Congratulations, this should come out correct for the vast majority of Windows software. This probably doesn't actually help you though, as a lot of the same things can be done in all of these languages.

Answer 7

IDA Pro Free (http://www.hex-rays.com/idapro/idadownfreeware.htm) may be helpful. Even if you don't understand assembly language, if you load the EXE into IDA Pro then its initial progress output might (if there are any telltale signs) include its best guess as to which compiler was used.

Answer 8

Start with various options to dumpbin. The symbol names, if not carefully erased, will give you all kinds of hints as to whether it is C, C++, CLR, or something else.

Answer 9

Other tools use signatures to identify the compiler used to create the executable, like PEiD, CFF Explorer and others.

They normally scan the entry point of the executable vs the signature.

Signature Explorer from CFF Explorer can give you an understanding of how one signature is constructed.

Answer 10

It looks like the VC++ linker from V6 up adds a signature to the PE header which youcan parse.

Answer 11

i suggest PEiD (freeware, closed source). Has all of Delphi for Win32 signatures, also can tell you which was packer used (if any).