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:
Tips to Determine Whether an App is Written in Delphi or Not
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.
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..
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.
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.
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.
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.
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.
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.
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.
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.
It looks like the VC++ linker from V6 up adds a signature to the PE header which youcan parse.
i suggest PEiD (freeware, closed source). Has all of Delphi for Win32 signatures, also can tell you which was packer used (if any).
Related
I am coding for WinAPI in MinGW
One thing I still have not fully understood is the VC redistributable,
I got a whole pack of question to it
Some say that such programs will need the msvcrt.dll
is the same library needed for bot c++ and c compilation?
is this available on all targets of clients?
must I redistribute it? can I redistribute it?
can I easily get rid of this external dependency?
is there other compiler that will allow me not to carry such unpleasant external dependency? (as I vaguely remember hearing that something is wrong with it - it is probably not core system lib, I heard, or it is not free to use and redistribute the library)
I see something wrong is here as I would like to produce no dependency small exes only calling the system WinAPI and if I use
some like C standard library functions functions I would prefer it economically and statically compiled in, not any third-party dependencies
MSVCRT.DLL contains mostly the C runtime, and MinGW can only use the C part. C++ binary code cannot be used across compilers generally.
It depends on your "target". It is available from Windows 2000.
No. No. It is Microsoft-proprietary code, and every Windows version has a slightly different version.
No. I am not aware of a mature alternative C run-time DLL.
You do not need to worry about the dependency, as it is available everywhere. (Do notice that it is not really a great run-time, esp. regarding multi-byte characters.)
Microsoft compilers can link with "static" libraries so that the resulting executable depends only on system DLLs like kernel32.dll, user32.dll, etc. MinGW cannot do this (yet).
EDIT: A concise description of the MSVCRT.DLL problem is here.
According to the MS White-paper here:
http://www.microsoft.com/en-gb/download/details.aspx?id=13350
you can redistribute certain parts of the Visual Studio components.
Some software, such as the Microsoft .NET Framework, can be
distributed. Components of software products included in MSDN
subscriptions that can be distributed (either within an application or
as separate files) without royalty are identified in the REDIST.TXT
file associated with the product. Components that can be distributed
to non-Microsoft platforms are identified in the OTHER-DIST.TXT file
associated with the product. Code identified as distributable that has
the extension .lib cannot be directly distributed; it must be linked
into the application. However, the resulting output can be
distributed.
You may also:
Modify and distribute source code and objects for code marked as “sample” or “Code Snippet”.
Distribute the unmodified output of Microsoft Merge Modules for use with an application's .msi file.
Distribute the MDAC_TYP.EXE file containing core data access components (such as the Microsoft SQL Server OLE DB provider and ODBC
driver).
Distribute the object version of C++ libraries (Microsoft Foundation Classes, Active Template Libraries, and C runtimes).
MS also produces a redistributable package specifically for the purpose of developers: http://www.microsoft.com/en-gb/download/details.aspx?id=40784
So, to answer your questions:
Yes. Although it is "purely C", it contains fundamental functions that are used by the C++ part of C as well, such as file I/O, time and date functions, math functions, and so on.
Within reason. See link above.
No, yes. As described above: You may choose to just say to customers "you need to download an install this package", but the license should allow you to distribute it free of charge with your product.
Depends on what you call "easily" and exactly what parts of the library your code uses. Some functions may be easy to replace, others not so - but it's not easy in the sense of "yes, just go do http://www.example.com/msvcrt.dll-plugin-replacement" - it would require coming up with some replacement code. The reason MinGW DOESN'T come with its own C library is that it's not entirely trivial to write a replacement for ALL of the windows functionality that you may need here...
See above - if it was easy, someone would have done it. There MAY be some compilers out there that come with their own library, but it's probably not a free-of-charge and free to distribute one (I'm not aware of any product that doesn't rely on the MSVCRT.DLL - but it's not impossible that one exists)
Soon I will be coding the file patcher for my application (check if the files are up-to-date and download newest if not) so its not much to code.
The problem is that I don't want the application users to be forced to use additional libraries like .NET (even though I like to code in vb.net or C#). I keep in mind that the .NET framework is installing together with the Windows but still there are plenty people who somehow doesn't have this framework installed, and thats why I'm looking for the programming language that wont require an additional libraries to run the application.
I haven't got much knowledge about programming in C++/Java but I have some experience with the AutoIT, vb.net, C#.
So the question is, what programming language will be the best for this purpose?
This answer is for "what language is available on any version of Windows without additional requirements". There are many other options for "what I can use to create application that can be xcopy deployed on any version of Windows".
JavaScript is probably your best bet - it is supported on most recent versions of Windows (according to Wikipedia article - Windows Script Host JavaScript available for scripting starting with Windows 98). Allows basic operation with files and HTTP communication - maybe enough for simple patching application.
Next would be native Win32 application, but lack of C++ experience will make it hard.
Freepascal, D and Go — to name a few — are much easier to program than C++ and could be told to produce statically-compiled binaries (not dependent on anything but certain system DLLs).
I, personally, would use the latter as it has all the necessary tools (including HTTP and binary I/O) in its standard library and is super-easy to get started with.
Is there someone that can suggest me a programming language that allows you to write quickly GUI programs (on windows platform)?
P.S. I am interested on only languages that do not rely on virtual machines and then have a compiler that produces executable code directly on the machine
I would go with AutoIT, it's a very easy to learn windows scripting language with tons of functionalities: http://www.autoitscript.com/autoit3/index.shtml
I'm using it to automate some tasks, but it can do way more than that.
EDIT
Just to make things a little bit clearer for everybody:
You can create new applications using AutoIT and the Aut2Exe compiler provided. The .exe files created are stand-alone, thus require no other files but the files that you might need in your app. Everything is free and the AutoIT scripting language has a BASIC-like syntax.
The GUI that you'll use are standard Windows controls. Among the functionalities you have the possibility to automate keystrokes/mouse movements, call the Windows API and external .dlls, manipulate windows and processes and through user created libraries (called UDFs) you can even acces local databases, manage networking tasks, encryption, archiving and many more.
All I can say is that it's worth take a look and the first app I built with AutoIT was done in roughly 8 hours since I started learning. It took a folder as the source and copied everything in a chosen directory, copying files in folders named as the date when the files were created. So the destination directory would have a series of subfolders like:
11.11.2010
whatever.txt
whatever.png
12.11.2010
archive.zip
and so on. Just 8 hours and got me rid of a lot of effort ordering the files myself.
Any .NET will probably be what you're after.
Start with VB.NET which is now called Visual Basic CCYY eg (Visual Basic 2005, Visual Basic 2008, Visual Basic 2010).
If you want something not using .NET framework, you might as well go back to older version of VB and if you want something compilable that'd be like C++ with their MFC (Microsoft Foundation Class).
You need to give more info on the type of gui and what you're using it for. This could be accomplished with Microsoft Access forms and VBA, or you could make an HTML Application (.hta).
I'll put in a vote for Delphi. You can easily write applications by dragging and dropping components on to a form and doing minimal coding in Pascal, which isn't hard to learn. Later, if you decide to go deeper, you can do pretty much whatever you want. And it compiles to native executable code.
Is an executable bundler, that combines the script with the framework/interpreter, good enough?
If so, you might look at Tcl/Tk or Lua.
http://www.powerbasic.com/
http://www.powerbasic.com/aboutpb.asp
Seems like it has a RAD GUI and of course it's BASIC, plus it compiles down to .exe (as I understand it.) Might be worth checking out.
A 'quick and simple' language will only allow you to do 'quick and simple' things - and for those, having a VM or not wont make much of a difference to you.
For quick and simple & native code, about all I can think of is RealBasic. Its cross platform Windows/Mac/Linux. I find their IDE to be difficult to work with due to its inflexibility and the help system last I looked wasnt that great, but the underlying language isnt bad and does compile to native code. So it might do the trick for you.
Which programming language and tools can i use, to develope a complete stand-alone gui-application? This application will be burned on a cd and should run on every windows-pc without any installations.
Questions like what your application and what your capabilities are need to be considered.
There are many solutions to your problem. From 'Visual Studio Ultimate' to a HTML file which contains javascript.
Win32 API.. a similar question was asked today...
Use Visual Studio (you can use express edition) and build whatever you like.
This is the most powerful language, yet development time is very very slow, but the results are:
a. independent.
b. if you a good programmer - small and fast.
one thing - you got to know what you're doing when programming win32...
one Petzold book will get you where you want to go.
similar question
Well, if you really have the time and don't need to deploy on 16-bit Windows, you could always write in Win32 assembly -see MASM32 and Iczelion's Win32 tutorials. There's even a IDE for Win32 ASM -WinAsm Studio :)
The only dependencies you'll need are the Windows system DLLs which are already there on every Win32 system.
However, if you need to build something quick, something like Visual Basic 6 will do nicely - it only needs the VB6 runtime by default (1 ~ 2 MB) and that definitely fits into a CD together with your VB6 EXE.
I'd go for C++ with MFC. Reasonable development times and with static linking it could all be one standalone exe file.
If you are just looking to make one of those interactive splash screens, might want to look into Demoshield. I know its old and not supported any longer, but can be of real use for something great looking.
http://www.componentsource.com/products/509937/12838/index.html
You can find copies of it free by google-ing it. Don't think the company is around any longer so not sure if this is legit or not.
But not the right choice if you need to do some serious programming stuff.
Delphi also may be a good choice.
I've got a working proprietary application (windows exe) and would like to know which particular toolkit was used to make it. The reason is that I like the widgets it uses and seek to use same library in my project (to buy it if it's proprietary as well).
Just use Process Explorer to see what DLLs the application has loaded. That will be your widget set. Sort the results by folder to roughly group them by manufacturer. You may need to examine the properties of the DLLs for more detailed info as well.
If the library is statically linked you may have to do some deep looking around, maybe you'll get lucky and find a string saying the name of the library or a class/function in it. You can use OllyDbg for this to view strings loaded at runtime, or something like the linux command strings to look through statically, although that wont work if the program decodes itself at startup. If that doesn't work, you'd have to come up with a list of libraries that do what the one you are looking at does, and find some artifacts in the binary that are common between the two. Anyways, better to check the dlls first like Paul Sasik said.
You can use PEiD to identify the compiler, which can be a hint aswel. PEiD also has a nice process explorer.
For instance, Google Chrome uses C:\WINDOWS\SYSTEM32\IEFRAME.DLL :-) Nice isn't it?
(Don't trust it 100%. For instance, my own compiler has the "Morphine 1.2 - 1.3 -> rootkit" description, which I find quite awkward: that's a packer/compiler trace obfuscator.)