just like in topic - is there any software to open (what?) and here I don't even know what to open - file with object code or exe?
My today's questions (if only todays ;)) may seem bit odd but I'm going through excersises in "The C++ Programming Language" by B.S. and sometimes I'm just stuck on particular question. I'm sometimes bit irritated by style of this book (excellent in many aspects) that he (B.S.) asks some questions which you won't find answer in his book on how to do it or even where to start.
Like this one for example:
Run some tests to see if your compiler really generates equivalent code for iteration using pointers and iteration using indexing. If different degrees of opimization can be requested, see if and how that affects the quality of the generated code.
Thats from chapter 5 question 8. Up to this point nowhere in this book is even mentioning testing and analyzing code generated by compiler.
Anyway, if someone could help me with this I'll be greatful.
Thank you.
The debugger will help you. Most debuggers let you halt the program and look into disassembly. The nice thing is they point you right to disassembly of the line you set the breakpoint to, not to just all the compilation result.
Once in a while I do that in Visual Studio - compile the program, put a breakpoint onto the beginning of code of interest, start the program, then when it is halted I open the disassembly and immediately see the code corresponding to that C++ code.
If you're using g++, you can do g++ -S main.cpp. This will output the assembly in a file called main.s. However, if the functions you're interested in are spread across different .cpp files, it might be more convenient to do an objdump on the final executable.
There's also a nice tool called embroider that pretty-prints the objdump output for you as HTML, crosslinking the various function calls and jumps.
Many compilers can generate "listing" files of the assembly code they are generating during compilation, interspersed with the statements from the C source code. Also, there are tools which disassemble object and executable files.
How these tools are actually activated is depending on your toolchain, obviously.
Related
Every so often I (re)compile some C (or C++) file I am working on -- which by the way succeeds without any warnings -- and then I execute my program only to realize that nothing has changed since my previous compilation. To keep things simple, let's assume that I added an instruction to my source to print out some debugging information onto the screen, so that I have a visual evidence of trouble: indeed, I compile, execute, and unexpectedly nothing is printed onto the screen.
This happened me once when I had a buggy code (I ran out of the bounds of a static array). Of course, if your code has some kind of hidden bug (What are all the common undefined behaviours that a C++ programmer should know about?) the compiled code can be pretty much anything.
This happened me twice when I used some ridiculously slow network hard drive which -- I guess -- simply did not update my executable file after compilation, and I kept running-and-running the old version, despite the updated source. I just speculate here, and feel free to correct me, if such a phenomenon is impossible, but I suspect it has had to do something with certain processes waiting for IO.
Well, such things could of course happen (and they indeed do), when you execute an old version in the wrong directory (that is: you execute something similar, but actually completely unrelated to your source).
It is happening again, and it annoys me enough to ask: how do you make sure that your executable is matching the source you are working on? Should I compare the date strings of the source and the executable in the main function? Should I delete the executable prior compilation? I guess people might do something similar by means of version control.
Note: I was warned that this might be a subjective topic likely doomed to be closed.
Just use ol' good version control possibilities
In easy case you can just add (any) visible version-id in the code and check it (hash, revision-id, timestamp)
If your project have a lot of dependent files and you suspect older version, than "latest", in produced code, you can (except, obvioulsly, good makefile-rules) monitor also version of every file, used for building code (VCS-dependent, but not so heavy trick)
Check the timestamp of your executable. That should give you a hint regarding whether or not it is recent/up-to-date.
Alternatively, calculate a checksum for your executable and display it on startup, then you have a clue that if the csum is the same the executable was not updated.
Unfortunately I am not working with open code right now, so please consider this a question of pure theoretical nature.
The C++ project I am working with seems to be definitely crippled by the following options and at least GCC 4.3 - 4.8 are causing the same problems, didn't notice any trouble with 3.x series (these options might have not been existed or worked differently there), affected are the platforms Linux x86 and Linux ARM. The options itself are automatically set with O1 or O2 level, so I had to find out first what options are causing it:
tree-dominator-opts
tree-dse
tree-fre
tree-pre
gcse
cse-follow-jumps
Its not my own code, but I have to maintain it, so how could I possibly find the sources of the trouble these options are making. Once I disabled the optimizations above with "-fno" the code works.
On a side note, the project does work flawlessly with Visual Studio 2008,2010 and 2013 without any noticeable problems or specific compiler options. Granted, the code is not 100% cross platform, so some parts are Windows/Linux specific but even then I'd like to know what's happening here.
It's no vital question, since I can make the code run flawlessly, but I am still interested how to track down such problems.
So to make it short: How to identify and find the affected code?
I doubt it's a giant GCC bug and maybe there is not even a real fix for the code I am working with, but it's of real interest for me.
I take it that most of these options are eliminations of some kind and I also read the explanations for these, still I have no idea how I would start here.
First of all: try using debugger. If the program crashes, check the backtrace for places to look for the faulty function. If the program misbehaves (wrong outputs), you should be able to tell where it occurs by carefully placing breakpoints.
If it didn't help and the project is small, you could try compiling a subset of your project with the "-fno" options that stop your program from misbehaving. You could brute-force your way to finding the smallest subset of faulty .cpp files and work your way from there. Note: finding a search algorithm with good complexity could save you a lot of time.
If, by any chance, there is a single faulty .cpp file, then you could further factor its contents into several .cpp files to see which functions are the cause of misbehavior.
Is it possible to decompile C++ Builder exe?
Is C++ Builder safe programming tools or anyone can decompile it and see the code?
The short answer, yes, it can be decompiled, and it's not "safe". Anything ran on a computer can be disassembled and from that inspected by reading the disassembly. Decompiling would mean restoring even some of the original compiled source code - which indeed is possible, to some extent. After all, it is "just" about writing a program which can translate assembly to the desired language. If a human can do that, then a program can do that too, because it is only about applying known rules and logic to translate the program from different representation/language to another. However, it is not just that simple...
Lots of information (like source files, variable names, some unused code, comments etc.) gets lost in the compilation process. This is further worsened by compiler optimizations which usually make the resulting disassembly near unreadable in some cases. As such, the decompiled source code can only give mere clues about the implementation details and mainly just the logic, not the actual source code used to build the project.
Please note that this has near nothing to do with any form of "safety" or security of a program itself. Any program can be disassembled in a way or another, any logic behind a working program can be inspected and reverse-engineered. There can be no secrets inside a program, nothing can be hidden if it can be run.
It is often much easier to disassemble a piece of executable and work through its logic in assembly, than trying to rely on very vague and usually broken reconstruct in high-level language such as C which many such decompilers still produce. Sometimes though, tools can produce readable and very clear high-level representations by disassembling, but they are often the simple cases and short excerpts of code.
The bottom line is, that you don't need a decompiler to inspect, reverse-engineer and understand a target program. All one needs is the access to the executable, a disassembler and understanding of assembly language. There is no way to avoid this fact, and it is very rarely a real problem.
I want to print the code of a function in a DLL.
I loaded the dll, I have the name of the desired function, what's next?
Thank you!
Realistically, next is getting the code. What you have in the DLL is object code -- binary code in the form ready for the processor to execute, not ready to be printed.
You can disassemble what's in the DLL. If you're comfortable working with assembly language, that may be useful, but it's definitely not the original source code (nor probably anything very close to it either). If you want to disassemble it, loading it in your program isn't (usually) a very good starting point. Try opening a VS command line and using dumpbin /disasm yourfile.dll. Be prepared for a lot of output unless the DLL in question is really tiny.
Your only option to retrieve hints about the actual implemented functionality of said function inside the DLL is to reverse engineer whatever the binary representation of assembly happens to be. What this means is that you pretty much have to use a disassembler(IDA Pro, or debugger, e.g. OllyDbg) to translate the opcodes to actual assembly mnemonics and then just work your way through it and try to understand the details of how it functions.
Note, that since it is compiled from C/C++ there is lots and lots of data lost in the process due to optimization and the nature of the process; the resulting assembly can(and probably will) seem cryptic and senseless, but it still does it's job the exact same way as the programmer programmed it in higher level language. It won't be easy. It will take time. You will need luck and nerves. But it IS doable. :)
Nothing. A DLL is compiled binary code; you can't get the source just by downloading it and knowing the name of the function.
If this was a .NET assembly, you might be able to get the source using reflection. However, you mentioned C++, so this is doubtful.
Check out this http://www.cprogramming.com/challenges/solutions/self_print.html and this Program that prints its own code? and this http://en.wikipedia.org/wiki/Quine_%28computing%29
I am not sure if it will do what you want, but i guess it may help you.
I have a project that I am trying to fix from a guy that left (let go) from my company. He has violated every fundamental principle of software engineering, not using source control, not backing up the source before you make more changes, etc. etc.
I need to make changes to an application that is in the field and I don't have the original source code, but I have an executable. What I need is a decompiler that will decompile a Visual Studio 6 C++ application and provide me with some type of source code. Anyone got any ideas.....
Well there's the Decompiler from Hex-Rays: https://www.hex-rays.com/products/decompiler/
It is pretty good for the fact that it is creating C code from Assembler but it works pretty good. It's also pretty expensive
Edit: Additional note it is combined with IDA Pro the pretty well-known disassembler from them. That already can show you a lot of information in the combination with the decompiler it is even easier to reverse code.
I've used RecStudio (rec22) and IDAPro to try and decompile a C++ project, together they probably wouldn't have been enough to do the job I had except that I worked out the demo project the program was based on so they gave just enough info that I could make something like the same project again.
In the end one other thing I was doing was compiling code that I thought matched and checking that I got the same result in the decompiler.
Good Luck.
Decompile to what - assembler?
There isn't anything that is going to give you meaningfull C from an exe.