Back to General and Gameplay Programming

decompiling: is it possible?

General and Gameplay Programming Programming

Started by goodfella412 November 05, 2002 08:13 PM

17 comments, last by goodfella412 21 years, 5 months ago

Oluseyi

2,123

November 06, 2002 05:59 AM

quote:Original post by Kippesoep
Actually, there is. How else would typeid (...).name () be getting the name?

I''m sorry, but this was so funny to me. You state the first part authoritatively, and then resort to a "How else..." argument to substantiate your previous statement.

I don''t know, for the record. And lots of people don''t use RTTI because they view it as slow.

SabreMan

504

November 06, 2002 06:07 AM

quote:Original post by Kippesoep
Actually, there is.

No there isn''t. From section 18.5.1 of the C++ Standard (my emphasis):

quote:The class type_info describes information generated by the implementation. Objects of this class effectively store a pointer to a name for the type, and an encoded value suitable for comparing two types for equality or collating order. The names, encoding rule, and collating sequences for types are all unspecified and may differ between programs.

quote:
How else would typeid (...).name () be getting the name?

I''m telling you it doesn''t get *the name*, it gets *a name*, which might be different from the name as it appears in the source.

Anonymous

November 06, 2002 09:06 AM

To answer the RTTI/debug info question:

I don''t kow if there are decompilers that will use them, but there is at least one disassembler that will. IDA Pro [ http://www.datarescue.com ]

It will recognize most formats for both of them (borland, msvc, gcc and lots of stuff I''ve never heard about)

Since it also recognizes the common library functions (for most compiler systems) statically linked into the code, I''d say it''s the best way to get a grip of some "foreign" compiled code. Way better than all decompilers I have seen.

(no, I don''t work there

)

Kippesoep

892

November 06, 2002 09:25 AM

quote:Original post by SabreMan
I''m telling you it doesn''t get *the name*, it gets *a name*, which might be different from the name as it appears in the source.

As you may recall: I specifically mentioned MSVC. There, it gets the name.

Also, even though the standard may allow it, how many compilers will actually show you something that is different from the name used in the source code? It would be pretty much useless to the programmer to have something like "abcjda" when the actual class is "CPenguin". Decoration might be used, of course (and in MSVC, it is: the stored symbol is the decorated name, accessed through type_info::raw_name, type_info::name is slower because it undecorates), but even that is human-readable.

The C++ standard is, BTW, completely irrelevant when it comes to decompiling. The only standard that matters is the layout of the executable.

Kippesoep

892

November 06, 2002 09:34 AM

quote:Original post by Oluseyi
I''m sorry, but this was so funny to me. You state the first part authoritatively, and then resort to a "How else..." argument to substantiate your previous statement.

Hmmm, the "how else" is indeed a poor choice of words. Probably due to the fact that English isn''t my first language.

The point still stands, though: the type_info::name function does (at least in MSVC, most likely in most other compilers as well) return the name used in the source code.

Kippesoep

SabreMan

504

November 06, 2002 11:43 AM

quote:Original post by Kippesoep
The C++ standard is, BTW, completely irrelevant when it comes to decompiling.

That''s true. Particularly as it''s not possible to reconstitute the original source from the binary, which renders the RTTI issue largely irrelevant anyway.

Kippesoep

892

November 06, 2002 01:20 PM

It could help in making the reconstituted source more readable. That is, assuming that the person who programmed it originally chose some sensible names. But then again, I doubt anyone would choose CChicken as a class for a texture manager and derive CPenguin from CTelevision to wrap around joystick input.

Still, I find reading any such "rebuilt" code almost impossible in many cases, just like it can take (me) ages to actually understand what''s going on from a standard disassembly.

Kippesoep

solson16

122

November 06, 2002 09:24 PM

quote:Original post by SabreMan
You won't get back the original source from Java bytecode either - there's no direct mapping. You have more "metainformation" than you do in a C++ binary, but not enough to get the original source.

ever done it? there's little difference between the original source code and a decompiled version. origial type information, identifier names, everything.
i've done it to programs of mine for the heck of it,and to others for educational purposes. I was pretty suprised. it really makes obfuscation necessary for commercial products

heck, I just opened a .class file in notepad and I could more or less see all the identifiers in plaintext.

[edited by - solson16 on November 6, 2002 10:25:27 PM]

Cyberdrek

100

November 07, 2002 07:01 AM

quote:Original post by prh99
Original post by goodfella412
if i have an executable, is it possible to ''decompile'' it so i end up with the source code? if it is possible how do i do it? can it be done with msvs6.0?? any help is greatly appreciated.

You won''t get back the original high level source code. Decompilers will go from executable to assembly.

Actually, you''re completely wrong. Alot of disassembler will decompile an exe to the sources of your choice. The only problem is that the code usually has alot of gotos since decompiler have problems recreating functions.

[Cyberdrek | the last true sorcerer | Spirit Mage - mutedfaith.com]

[Cyberdrek | ]

decompiling: is it possible?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

decompiling: is it possible?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines