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.)
Related
How to see some basic information about a MacOS binary file, specifically what was used to build it, which frameworks it is linked against and what system calls it is using?
I tried nm and otool -L but their output is only partially useful.
For example, what would indicate that a binary was built with xcode or golang compiler?
NB. I am not interested in reverse engineering macos binaries. I just want to know better what is running on my system using just the tools that are already included OOTB.
The compiler used is not a trivial question. Some compilers embed information about themselves, and you sometimes find that by running strings, but it's not guaranteed. That said, the answer on Mac is almost always clang, so it's not usually that hard to get the basics. As an example:
strings iTunes | grep clang
COMPILER=clang-9.0.0
But that's just luck (and might not even be accurate).
IDA Pro does a good job at this, and is the gold standard for reverse engineering work. If this kind of thing is important to you, then IDA Pro is the tool. It's expensive.
To get a list of frameworks that it links at runtime, otool -L is the tool you want. I don't understand what you mean by "isn't very readable." It just prints out all the frameworks, one per line. It's hard to imagine anything more readable than that. What are you looking for here?
otool -L will not tell you what static libraries were used, so "which frameworks it was built against" may be too broad to answer. You can generally find the symbols for well-known static libraries (OpenSSL for instance), but there is no easy way to know precisely what was included in a binary, particularly if debugging information is stripped. (If there's debugging information, then the filepaths will tend to be available, which can tell you a lot more about how it was built.)
There is no easy static way to get a list of all system calls, since those may be buried in libraries. nm is generally what you want, though. It includes a lot of things that aren't "system" calls, though, since it's going to include every symbol linked from external sources (you probably want something like nm -ju). Again, I'm not sure what you mean by "isn't very readable." It's one symbol per line.
In order to get the list of system calls at runtime, run the application with dtruss. It'll output every system call as it's made, and will focus on actual "system" calls (i.e. syscall).
Assuming you only have access to the final product (i.e. in form of the exe file), how would you go about finding out which libraries/components the developer used to create the application?
In my specific case the question is about an application developed in VC++ using a few third party components and I'm curious which those are.
But I think the question is generally valid, e.g. when it should be proven if a developer is in line with license requirements of a specific library.
So, what you're saying is that if I suspect that a binary is using a certain library, I could try to map the respective function calls and see if I get a result. But there is no shortcut to this and unless I am willing to try out hundreds of mappings or the dev left some information in some strings or other resources, I have little chance of finding this out. Yes?
There is small shortcut, here's what I'd do:
check executable for strings and constants, and try to find out what library is that.
IF used libraries are open-source, compile them on my own and create FLAIR signatures (IDA Pro).
Use generated flair signatures on target executable.
In some situations, that can really work like a charm and can let you distinguish actual code from used libraries.
The IDA Pro Book - Ch 12. Library Recognition Using FLIRT Signatures
I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
This may be the wrong place...but since it's actually regarding a GUI toolkit I figured it might be appropriate here.
Anyways theres a Program (For anyones reference it's actually an automated modding thing for a game called Morrowind). Anyways it has a nice clean GUI layout, it's for Windows. And basically im trying to find out just what toolkit was used.
I've tried contacting the author, and I haven't seen anything about what was used mentioned anywhere. Is there any chance I could find out someway which toolkit was used in making this Program?
Or is that technically private information?
If the program runs on MS-Windows, Dependency Walker allows you to find out which libraries the program requires. The required libraries might give you a hint about which GUI toolkit was used.
On other platforms, ldd is often available and gives you similar information.
This only works if the GUI toolkit is dynamically linked.
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).