Well, aren''t you a genius?
War Worlds - A 3D Real-Time Strategy game in development.
hex editors and c++
If the functions were all small, and the library was compiled in debug mode, then it would be easy. What about a 3 page function compiled in release mode? That''s a fair challenge.
(But why would anyone use a hex editor to read plain text?)
(But why would anyone use a hex editor to read plain text?)
MSVC comes with a built in disassembler. You just click on the disassembly window when debugging something.
Actually... you could get your sourcecode back. But you would have to write a program to convert assembly to C++ or whatever your using. So you''d disassemble it then convert it with your program. Only problem would be all your variables would be like a001, a002, etc. And it would be easier just to rewrite your sourcecode.
PaladinGLT
PaladinGLT
PaladinGLT
Yeah, that is what a decompiler is. But you can''t get ''your'' source code back for several reasons. Partly because of lost identifier names as you said. Partly because all comments are stripped out. And partly because information is lost in the transition from high-level language to low level. If you compile something like this:
A decompiler will probably give you:
Even worse when you start using the STL:
will probably come back as:
due to the way stuff gets optimised. (Note that the s[10] is also a simplification... that is likely to in fact be a few function calls or something to resolve that first.)
And any instantiations of templates would probably get returned as several different versions of the same sort of procedure.
Basically, a lot of the semantic info is gone forever.
This is partly why nobody''s managed to do a good decompiler yet... because it would have to fill in the blanks.
typedef long uint32;uint32 x;
A decompiler will probably give you:
int x;
Even worse when you start using the STL:
for (std::string::iterator si = myString.begin(); std::string::iterator si != myString.end(); ++si){ // do something }
will probably come back as:
for (char* x = &s[0]; x != s[10]; ++x){ // do something }
due to the way stuff gets optimised. (Note that the s[10] is also a simplification... that is likely to in fact be a few function calls or something to resolve that first.)
And any instantiations of templates would probably get returned as several different versions of the same sort of procedure.
Basically, a lot of the semantic info is gone forever.
This is partly why nobody''s managed to do a good decompiler yet... because it would have to fill in the blanks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement