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.
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.
Is it possible for someone to 'watch' how your variables/etc are assigned at runtime after you've deployed your executable and dependency files? More specifically, can someone 'watch' how you are managing your internal data if they have your executable?
I don't want to know how to do this, I just want to know if it is possible. Whether it is or isn't will determine how I structure my code.
Sure, but there are varying levels of difficulty. If you give them a debug build, it could be pretty easy for them to launch your executable in a debugger and then just use their debugging tools to watch the execution (just like programmers do when they develop).
If you give them a stripped but not optimized build, then they don't have all the debug symbol names but they can still load your program in a debugger and watch it execute, instruction by instruction and map out what memory is being used and how. It's more difficult, but still possible.
If you give them a stripped, optimized build, it's a bit harder (as the optimizer can produce some complex and hard to follow assembly) but still not impossible.
It's always possible, in the end. Whether or not it's worth someone's time and effort, though, is a different story.
Yes, it's entirely possible. Any decent debugger can follow your code.
And no, this should not determine how you structure your code, because I can guarantee that no matter what you do will affect whether someone else can understand/follow your code. It may slow someone not so clever down, but there are some REALLY clever people out there, whose entire life revolves around understanding other people's compiled code.
I know that you cannot have a C++ dll and expect to have it as a source code, am I right? But at the same time, when I revert a C++ dll to raw data, using DUMPBIN, then there are some stuff which can be done to interpret it, right? For example, we know basic mappings for most popular operators and all.
Is there a tool that can roughly interpret that raw machine data to something that looks more to a code or instruction? The issue is that I do not have enough time to write it myself to scratch! so I am looking for a tool or something to do it.
You need a disassembler, which is a tool that takes a binary object (like a compiled file, a library, or even an executable) and tries to reinterpret its content as assembly.
With a tool like that you can usually retrieve the names of the internal symbols (unless of course the binary image is stripped, but this is not the case for dynamically liked libraries).
Also for C++ this is a bit difficult because of name mangling.
Try to give a glance to Objdump.
YOu can disassemble the code sections of the DUMPBIN /DISASS - but if you want "code" like C++, then you need a decompiler. However, they are far from great, and often make quite unreadable code - yes, it's something that you can feed into a compiler, but it's hardly what I'd call "human readable".
In my biased opinion, the best disassembler out there is IDA (Interactive Disassembler). It is somewhat expensive since it's targeted towards professional use, but there's a freeware (older) version you can try:
http://www.hex-rays.com/products/ida/support/download_freeware.shtml
The Hex-Rays Decompiler (an add-on for IDA) can produce C pseudocode from the disassembly, which can in many cases be recompiled again.
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.
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 :)