Reverse Engineering RET Homepage RET Members Reverse Engineering Projects Reverse Engineering Papers Reversing Challenges Reverser Tools RET Re-Search Engine Reverse Engineering Forum Reverse Engineering Links

Go Back   Reverse Engineering Team Board > Reverse Engineering Board > Reverse Code Engineering
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Display Modes
  #1  
Old 08-31-2004, 05:28 PM
sniffysnif sniffysnif is offline
Member
 
Join Date: Aug 2004
Posts: 8
Default detecting source language

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
Reply With Quote
  #2  
Old 08-31-2004, 06:53 PM
rous rous is offline
Member
 
Join Date: Jan 2004
Posts: 38
Default

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
Reply With Quote
  #3  
Old 09-01-2004, 06:32 PM
Crudd Crudd is offline
Administrator
 
Join Date: Dec 2002
Posts: 22
Default

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]
__________________
Just another freak, in the freak kingdom.
Reply With Quote
  #4  
Old 09-01-2004, 06:36 PM
Crudd Crudd is offline
Administrator
 
Join Date: Dec 2002
Posts: 22
Default

Is today tuesday?
__________________
Just another freak, in the freak kingdom.
Reply With Quote
  #5  
Old 09-01-2004, 11:05 PM
sniffysnif sniffysnif is offline
Member
 
Join Date: Aug 2004
Posts: 8
Default

Quote:
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! )
Reply With Quote
  #6  
Old 09-02-2004, 01:27 PM
Devine9 Devine9 is offline
Administrator
 
Join Date: Dec 2002
Posts: 180
Default

peid does some detection.. you might try looking there.

Devine Right [RET]
Reply With Quote
  #7  
Old 09-02-2004, 01:30 PM
Devine9 Devine9 is offline
Administrator
 
Join Date: Dec 2002
Posts: 180
Default

"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]
Reply With Quote
  #8  
Old 09-02-2004, 03:47 PM
sniffysnif sniffysnif is offline
Member
 
Join Date: Aug 2004
Posts: 8
Default

Quote:
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?
Reply With Quote
  #9  
Old 09-02-2004, 04:01 PM
rous rous is offline
Member
 
Join Date: Jan 2004
Posts: 38
Default

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
Reply With Quote
  #10  
Old 09-03-2004, 06:24 PM
sniffysnif sniffysnif is offline
Member
 
Join Date: Aug 2004
Posts: 8
Default

a simple yes would have sufficed.

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

thanks! <3
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump





Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.