• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

Malachi

hex editors and c++

16 posts in this topic

How can I use my hex editor(winhex)to show me the sourcecode for compiled C++ applications?
0

Share this post


Link to post
Share on other sites
I don''t know what your trying to hack ... but the short answer is ... you can''t!

FIRST
a HEX EDITOR .. is exactly that ... it displays the contents of a file in HEX (hexidecimal) notation - and then it lets you edit those values and save the file again. There is absolutely NO connection between a hex editor and source code.

SECOND
a DISASSEMBLER can be used to convert a compiled file (com, exe, lib, obj, etc ...) into ASSEMBLY language ... ALL executable code can be viewed no matter what the creator wrote it in - but you CANNOT get back to the source code they used, not in C, not C++, not VB, not anything but assembly (some converter convert assembly to C .. but not the ORIGINAL C the author wrote) ... and even the assembly with be useless in general ... because the variable names, comments, stack organization, etc .. will be unknown to you ... it is NOT contained in the code.

THIRD
if YOU are the author of the code ... and compiling it ... then the closest thing to what you desire is to use a SOURCE LEVEL DEBUGGER ... which will usually be available with your compiler ... you compile in DEBUG MODE .. which means the executable code contains extra symbols and such which allow it to show you which lines of you C++ program you are at when you run it in debug mode ... you can execute each line or function and watch the effect on your variables and such.

people that crack things use either HEX EDITORS ... to replace data with different values which benifit them (beefed up stats in games or such) ... or DISSASEMBLERS to find the code they wish to circumvent and the change it ... but all of that require a level of talent and understanding BEYOND that of normal programming ... from your questions naivety I would guess you do not possess such expertise.
0

Share this post


Link to post
Share on other sites
That question actually doesn''t make sense:
quote:

How can I use my hex editor(winhex)to show me the >sourcecode< for >compiled< C++ applications?



If it''s compiled it''s not sourcecode, and if it''s sourcecode it''s not compile. Think about it! And about what you are actually trying to get at....might be worth it.

Cheers
- Sleepwalker

Born to code! - or coded to be born? I still wonder...

0

Share this post


Link to post
Share on other sites
GGRR....What I am trying to achieve is getting back my sourcecode off my compiled exe. After my sourcecode was corrupted by a hard drive crash. Yeah I know you need disassemblers to get the code but I read somewhere on the interent people used hex editors to get sourcecodes out of exes aswell.
0

Share this post


Link to post
Share on other sites
You might find this interesting.

Of course, decompilation is a sketchy process at best, and I wouldn''t exactly rely on it.

~~~~~~~~~~
Martee
0

Share this post


Link to post
Share on other sites
Sorry Malachi, as others have said, your compiled exe doesn''t contain source code. A disassembler can give you the assembly code (because assembly has a 1-to-1 relationship to machine code) but your actual code listings are gone forever. Martee''s link to a decompiler might help if you have a simple C program, but even in the best case, you''re not going to get your variable names, function names, or comments back.

If the analogy helps, trying to get source code from an executable is like trying to get a recipe by picking through your meal.

However, I will offer you some help which may or may not be of use: hit F9 in Winhex, and get the Disk Editor up. Pick your corrupted disk, which hopefully you have not done a lot with since then, and use the Find tool to search the entire disk for your variable names. If you''re lucky, you can pull the whole project off there. (As I did, once... 150 files from a dead hard disk... ouch.) If you''ve been writing to the disk though, some of it may have been overwritten. And note that some of your files may be fragmented. Good luck.
0

Share this post


Link to post
Share on other sites
This is also not in direct answer to your question, but if you''ve got a crashed hard drive, there are companies which will retrieve data from wrecked disks. For example, the people at www.datarecoverygroup.com specialize in this sort of thing (as well as recovering evidence for both civil and criminal courts!)

Mind you, it''s very expensive and may set you back upwards of $1000, you only pay if you get the data back though. If they get your data back, they send it to you on a CD, a new hard disk or your old hard disk (if they can repair it).

Just let this be a lesson to make regular backups


War Worlds - A 3D Real-Time Strategy game in development.
0

Share this post


Link to post
Share on other sites
I''m a normal programmer and I crack a protected library using MSVC''s dissassembler and hex editor... it really wasn''t all that hard either.
0

Share this post


Link to post
Share on other sites
I''m a normal programmer and I cracked a protected library using MSVC''s dissassembler and hex editor... it really wasn''t all that hard either.
0

Share this post


Link to post
Share on other sites
I''m a normal programmer and I cracked a static library using MSVC''s dissassembler and hex editor... it really wasn''t all that hard either.
0

Share this post


Link to post
Share on other sites
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?)
0

Share this post


Link to post
Share on other sites
MSVC comes with a built in disassembler. You just click on the disassembly window when debugging something.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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:

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.
0

Share this post


Link to post
Share on other sites