learned english as a second lang, sorry for the mistakes & awkwardness
I have given a peculiar project to work on. The company has lost the source code for the app, and I have to make changes to it. Now, reverse engineering the whole thing is impossible for one man, its just too huge, however patching individual functions would be feasible, since the changes are not that monumental.
So, one possible solution would be compiling C code and somehow -after rewriting addresses- patching it into the actual binary, ideally, replacing the code the CALL instruction jumps to, or inserting a JMP to my code.
Is there any way to accomplish this using MingW32? If it is, can you provide a simple example? I'm also interested in books which could help me accomplishing the task.
Thanks for your help
I use OllyDBG for this kind of things. It allows you to see the disassembly and debug it, you can place breakpoints etc, and you can also edit the binary. So, you could edit the PE header of that program adding a code section with your (compiled) code inside, then call it from the original program.
I can't give you any advice since I've never tried, although I thought about it many times. You know, lazyness.. :)
I would disassemble the program with a high-quality disassembler that produces something that can be assembled back into a runnable app, and then replace the parts you need to modify with C code.
Something like this will let you reverse the machine code into source. It won't be pretty but it does work.
http://www.hex-rays.com/idapro/
There are also tools for runtime patching http://www.dyninst.org/ for instance. They really aren't made for patching but they can do the trick.
And of course the last choice is to just use an assembler and write machine code :)
Related
This is probably a strange question. My project involves a few other people that need to work on the code too. I'm not sure how careful they would be with it and I don't want it to leak. For this reason I split it into 2 parts, one is in the form of a library, the rest just plain source code. There is one other guy that needs everything so he also has the source to the library. I don't want this guy to make any changes to the library. I put in a version number that gets printed when everything is running but I have no way of knowing (from looking at logs) if the library was authentic (from me only).
I was hoping there is some way I can use a public-private-key signature or something like this but against what? I probably can't just calculate an MD5 hash either because the linker probably puts the library function in different places all the time.
I realize it's probably not feasible to sign and verify source code but I would be curious to hear if anybody has any ideas.
You can use one of the VCS (version control systems) listed here.
By my experience you can use Github, it is easy to work with.
In C++ I can achieve the same results by using a shell script where I write all the compilation instructions. So my question is:
Are there any good reasons in using a makefile?
Do you have any examples to demonstrate this?
One of the main reasons to use a makefile is that it will recompile only the source files which have changed since the last time you built your project. Writing a shell script to do this will take much more work than writing the makefile.
Wear and tear on the keyboard.
Preventing it taking ages to compile everything
Easier to change between compiling for debugging and production
As to examples - See most GNU projects wrote in C/C++
You might want to take a look on autotools. The will make a Makefile for you while they can help with code portebility as well. However, you have to make some relatively simple template files that the auto tools will use to construct configure file and a end user can run ./configure [options]; make. They provide many features to your makefile that a end user might expect. For a good introduction see : http://www.freesoftwaremagazine.com/articles/brief_introduction_to_gnu_autotools
Let's say you do write a shell script. It will work and you will be happy. You will keep using it every chance you get. You will add parameters to it to allow you to specify options. You will also notice that it re-compiles everything, all the time. So you will then try and make it smarter so it only re-compiles the files that have changed. What you will be doing, in effect, is writing your own make system.
That's fine as long as you had a good reason to do it. For example: Existing make solutions don't do X well, so you wrote one to solve that problem.
You, however, don't have a problem that cannot be solved by an existing make system (or at least, it sounds like you don't :) ). The problem you're trying to solve has already been solved. Just read up and use the solution - a make file :)
So, to answer your question, yes, there are a lot - most of which you won't be aware of until you need the functionality. When you do, you will be grateful it already does what you want.
It's the same logic you apply to using libraries in code.
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.