PDA

View Full Version : detecting source language


sniffysnif
08-31-2004, 05:28 PM
sorry if this is a really stupid question, but is it possible to detect the language a .dll or .exe is written in? any signature it leaves behind?

i HEX edit a couple of freeware programs and i'll get some information reguarding the compiler. based on that i could assume that a VB Compiler would compile VB. is that actually true? is it possible to code a program in 2+ languages and have no complications? ( some languages are mroe similar than others? )

any help would be great. and if you know the compiler, and know the language, is it possible to reverse the actions of the compiler? ( in the home program ) say if you just took the .dll

rous
08-31-2004, 06:53 PM
I know GDB will try to guess a binaries source language. Otherwise, take a look at the names of functions within the binary, whether they are C functions, etc.

rous

Crudd
09-01-2004, 06:32 PM
I believe alot of compilers leave some sort of 'signature'. VB apps are the most obvious. And i know PeID (and i think IDA) can tell if i program is written in C. As for reversing the compiled code back to its sources, this would be difficult to do without knowing all the options used to compile the program. I think it could be possible to guess alot of it, but not sure about the accuracy. Your best bet is to just get good at asm, if you are gonna take reversing seriously. You dont neccesarily need to know how to code in asm, just whut all the instructions mean. And there is plenty of documention for this on the web.

As for coding in two different languages, yes and no. You can code a program in C/C++ (and maybe VB and Delphi) and use inline asm. But you cant use VB code in Delphi app, or C in a VB app, or Delphi in a C app. You could code the .exe in one lang and the .dll in another though.

Hope that answers all your questions thoroughly enough.
Crudd [RET]

Crudd
09-01-2004, 06:36 PM
Is today tuesday?

sniffysnif
09-01-2004, 11:05 PM
As for reversing the compiled code back to its sources, this would be difficult to do without knowing all the options used to compile the program. I think it could be possible to guess alot of it, but not sure about the accuracy.

is it possible to create a sort of brute-force decoder? if you told me it is, i assure you i'd start learning how to do that right away :P ( after i figure out how to identify the signatures )

this is sort of a out-of-nowhere question, but what language do you code in to develop other languages? ( something i never thought about, because it scared me to think about it. just like hardware programming :/ )

( both your replies answered my questions. thanks! )

Devine9
09-02-2004, 01:27 PM
peid does some detection.. you might try looking there.

Devine Right [RET]

Devine9
09-02-2004, 01:30 PM
"what language do you code in to develop other languages?"

well to start off "developing a language" is done on paper and just with thinking and careful planning.. it is not so much coding something.. now what you actually code is a compiler for that specific language.. and you can write a compiler in anything from vb to assembler, depending on what you want.. and it just works as an assembler, and linker to convert your source code of your new language to the pe structure to be executed the same as all the other .exe files.. if that makes sense..

also, you can find peid at http://peid.has.it

Devine Right [RET]

sniffysnif
09-02-2004, 03:47 PM
and it just works as an assembler, and linker to convert your source code of your new language to the pe structure to be executed the same as all the other .exe files

helps very much.

you guys ever think of coding in C#? i got some friends who started working with that and they said that there is a sequence in C, that takes about a 1000 lines of code, and you can sum it all up in C# with 1 line :P

any thoughts?

rous
09-02-2004, 04:01 PM
It is very possible, and sometimes necessary, to code in multiple languages in an executable. OS X utilizes two principle types of object file formats, Mach-O and PEF. Mach-O, along with BSD, comprise the core of OS X's microkernel, called XNU. The PEF binary was the native executable format for PowerPC Mac OS systems before Mac OS X. With some work, PEF executables can run on Mac OS X as well as some earlier systems, consequently, a great many programs still use it. Apple has made it very clear that it's on its way out...although I am not so sure about this anymore, Carbon is a very useful API. Anyway, Apple is pushing Cocoa, an object-oriented API for developing applications written in Objective-C and Java. Cocoa consists of a great many "frameworks", which are a type of bundle (kind of like a folder) containing shared resources such as dynamic shared libraries, header files, icons and images, documentation, etc.

Incidentally, many apps exist as bundles, making installation and uninstallation a snap because everything is contained within...when one clicks on the icon, it traverses down the bundle directory to the executable and launches. Of course it is easy to open a bundle and view it's contents, but they are normally closed so folks who actually USE applications can't fuck them up.

My point is that there are a great deal of APIs on OS X (I haven't mentioned them all), but instead of working seperately from each other it is very common to see Carbon (ANSI C) functions calling Cocoa functions, Java utilizing Cocoa, etc. all within the same executable.

rous

sniffysnif
09-03-2004, 06:24 PM
a simple yes would have sufficed.

i am officially .00000000000000004% more knowledgeable after reading your post.

thanks! <3

Devine9
09-03-2004, 07:11 PM
sniffysnif: I enjoyed the reply.. it wasn't necessarily for you ;)

thanks rous,

Devine Right [RET]

sniffysnif
09-03-2004, 07:40 PM
err. sorry Devine9, rous' post was the one that made me more knowledgable :/

but it's okay that you tried to take the credit. your post was very informative, but it only made me .00000000000000003% smarter =(

Devine9
09-03-2004, 07:44 PM
I see ;) well i'll try to be much more informative next time for you.

Devine Right [RET]

sniffysnif
09-03-2004, 08:24 PM
a simple yes would suffice...

rous
09-04-2004, 02:20 AM
That was pretty long winded huh?

rous

kw
09-05-2004, 03:55 PM
Long answers are usually a good thing, I'd say. Better too much info than not enough ;)
The information might be useful for someone other than the one who asked the original question.
Anyway, once I start talking/writing, I usually have trouble stopping.. So my posts are generally 'too' long.

I'll stop now.

-kw