How to understand if exe/dll is written in C++/.Net/Java or in any other language. I tried to use Dependency walker but not able to get required information.
asked Jan 5, 2014 at 7:02
-
2Usually the compiler used to build the executable file leave some explicit strings about itself. Try to look at the extra sections left in the executable. And, second, if no explicit tag is left, you will be able to deduce the original language (and probably the compiler) by recognizing the ABI used to produce the assembler.– perrorCommented Jan 5, 2014 at 9:35
-
It's worthwhile to remember that a program can be written in more than one languages and then converted or exported to a binary.– CppLearnerCommented Jan 10, 2014 at 23:01
-
Mandiant's Red Curtain had this functionality, wonder if you can reverse what they did there?– atdreCommented Feb 22, 2014 at 14:46
Add a comment
|
7 Answers
(reposting my SO answer to a similar question)
In many cases it is possible to identify the compiler used to compile the code, and from that, the original language.
Most language implementations include some kind of runtime library to implement various high-level operations of the language. For example, C has the CRT which implements file I/O operations (fopen, fread etc.), Delphi has compiler helpers for its string type (concatenation, assignment and others), ADA has various low-level functions to ensure language safety and so on. By comparing the code of the program and the runtime libraries of the candidate compilers you may be able to find a match.
IDA implements this approach in the FLIRT technology. By using the signatures, IDA is able to determine most of the major compilers for DOS and Windows. It's somewhat more difficult on Linux because there's no single provider of compiler binaries for it, so signatures would have to be made for every distro.
However, even without resorting to the runtime library code, it may be possible to identify the compiler used. Many compilers use very distinct idioms to represent various operations. For example, I was able to guess that the compiler used for the Duqu virus was Visual C++, which was later confirmed.
answered Jan 5, 2014 at 9:44
- .NET could be identified by import which you can see using dependency warker - check if there is an import of
mscorlib.dllwhich is a core lib of .net framework. - C++ can be identified by
- looking at the assembly - it uses this call convention.
- PEid can show partial info about what compiler and run-time were used. In general it uses list of signature for that.
- Detect It Easy - this tool is still maintained and has pretty interesting features.
-
For some reason I can't unRAR
PEid. Windows Defender removes it as malware.– c00000fdCommented Jan 5, 2018 at 22:23
Marco Pontello's TrID software can usually identify what was used to compile a file.
-
1
-
Do you have a guide on how to use it? I've downloaded the main program but cannot find the database of definitions it requires as a separate package? I see where the definitions are on the website, but I haven't been able to figure out how to download them.– mattybCommented Apr 6, 2017 at 18:06
-
Java bytecode files can be identified by their magic number: 0xCAFEBABE at the beginning of the file. Also the standard naming convention is to have these files' names end in .class.
However, @hexafraction warns in a comment: "Java classfiles would not have their magic number or file extension visible when packed into a .exe PE, except if they were unpacked (assuming that they're just packed in the first place, and not recompiled to machine code)"
-
Java classfiles would not have their magic number or file extension visible when packed into a .exe PE, except if they were unpacked (assuming that they're just packed in the first place, and not recompiled to machine code) Commented Sep 4, 2014 at 17:35
Stud_PE (free) scans a lot of signatures of PE files (.EXEs and .DLLs).
You can detect a .net assembly by looking at the PE headers. Read the CLR spec and the PE/COFFEE spec for details.
Java uses it's own class file format. I'm not too familiar with it, but it should be possible to positively id a class file.
Native language development is mostly about heuristics. Things like calling conventions, prologues, epilogues, etc. A recursive descent disassembled, plus an idiom recognizer can likely id the source compiler. GCC and class generate very distinctive code, for example.
(blatant plug)
protectionid (pid.gamecopyworld.com) reports the compiler info (turn it on in the configuration)
to do it, its a multitude of things
checking for byte patterns
checking imports (mscoree.dll, msvcr*.dll and so on)
checking entrypoint code
checking mz stub
checking linker version
and a few other things
example output
Scanning -> C:\ProtectionID.source\problematic.files\solved\detected\Agile.NET 6.2.0.16.AgileNETUnpackMe\AgileUnpackMe.exe
File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 7680 (01E00h) Byte(s)
[File Heuristics] -> Flag : 00000100000001001101000000110000 (0x0404D030)
[Entrypoint Section Entropy] : 5.25 (section #0) ".text " | Size : 0x1288 (4744) byte(s)
[DllCharacteristics] -> Flag : (0x8540) -> ASLR | DEP | NOSEH | TSA
[ImpHash] -> f34d5f2d4577ed6d9ceec516c1f5a744
[SectionCount] 3 (0x3) | ImageSize 0x8000 (32768) byte(s)
[VersionInfo] Product Name : AgileUnpackMe
[VersionInfo] Product Version : 1.0.4999.25574
[VersionInfo] File Description : AgileUnpackMe
[VersionInfo] File Version : 1.0.4999.25574
[VersionInfo] Original FileName : AgileUnpackMe.exe
[VersionInfo] Internal Name : AgileUnpackMe.exe
[VersionInfo] Legal Copyrights : Copyright 2013
[Debug Info] (record 1 of 1) (file offset 0x1414)
Characteristics : 0x0 | TimeDateStamp : 0x522C69AD | MajorVer : 0 / MinorVer : 0 -> (0.0)
Type : 2 (0x2) -> CodeView | Size : 0x57 (87)
AddressOfRawData : 0x3230 | PointerToRawData : 0x1430
CvSig : 0x53445352 | SigGuid A75CE0F5-0D67-4FC4-A2C612B95C81F742
Age : 0x6 | Pdb : c:\AgileUnpackMe\AgileUnpackMe\obj\x86\Debug\AgileUnpackMe.pdb
[!] AgileDotNet detected
[CompilerDetect] -> .NET
[.] .Net Info -> v 2.5 | x86 managed (/platform:x86) | Flags : 0x00000003 -> COMIMAGE_FLAGS_ILONLY | COMIMAGE_FLAGS_32BITREQUIRED |
[.] Entrypoint (Token) : 0x06000006
[.] MetaData RVA : 0x00002184 | Size : 0x00000C0C (3084)
[.] MetaData->Version 1.1 -> v2.0.50727
[.] Flags : 0x0 | Streams : 0x5 (5)
- Scan Took : 0.156 Second(s) [00000009Ch (156) tick(s)] [539 scan(s) done]
