Is there anyway for a program to know if it has been modified since it was compiled and built?
I'd like to prevent the .exe from being modified after I build it.
You could use a private key to sign the EXE, and public key to check that signature. I haven't worked with the EXE file format in nearly 20 years, but as I recall there are spaces where you could store such a signature. Of course, the portion of the file that you're checking would have to exclude the signature itself.
However, if you're trying to do this to prevent cracking your EXE, you're out of luck: the cracker will simply patch out the code that validates the signature.
even if you know.. the person who knows you had such a prevent, will change computer time to your build time than modify this exe..
so it can not be a prevention..
Is it possible for a program to know if it has been modified since it was built?
Yes. A checksum of the rest of the program can be stored in an isolated resource string.
Is it possible for a program to know if it was maliciously modified since it was built?
No. The checksum, or even the function that executes and compares it, could be modified as well.
Are you talking about Tamper Aware and Self Healing Code?
The article demonstrates detecting
hardware faults or unauthorized
patches; back patching the executable
to embed the expected hash value of
the .text section; and demonstrates
the process of repairing the effects
of hostile code (for example, an
unauthorized binary patcher). The
ideas presented in the article work
equally well whether the executable
was patched on disk or in-memory.
However, the self repair occurs in
memory.
Most popular compilers have a switch to fill in the "Checksum" field of the PE header, or, you can leave it blank and supply your own custom vale. At any rate this is the 'standard' place to store such data.
Unfortunately there's no real way to stop someone tampering with a binary, because you'll have to put checks inside the exe itself to detect it, at which point they can be patched out.
One solution to this problem is to encrypt certain functions and use the checksum of some known data as the key (for example the checksum of another function). Then, when you leave the function you reencrypt it. Obviously you'll need to come up with your own prologue/epilogue code to handle this. This is not really suitable if your program is heavily multi-threaded, but if you're single-threaded or only lightly threaded (and can serizalize access to the functions and control all entry points) then this will 'raise the bar' if you will.
That is a step above most 'packers' which simply encrypt the .text/.data/.rdata/etc sections and decrypt it all at runtime. These are very easy to 'dump', as all you have to do is run the program, suspend all its threads, then dump the memory to a file. This attack works against Themida for example (one of the most aggressive packers). From there all you need to do is rebuild the IAT, fix up some relocs, etc.
Of course it's still possible for the attacker to use a debugger to dump out the unencrypted code and hence 'unpack' the exe, but obviously nothing is foolproof.
Related
I am creating an archive which contains HTML/CSS/JS files for my C++ application, and I don't want users to have access to these files. So, i decided to encrypt archive with password.
My first thought was to store a password inside a program via preprocessor macro (through CMake). But, is it safe?
Can you access the password back from compiled application? (exe, in my case)
And if you can, how to protect from it? Is it technically possible or i should give up and leave it as is?
If the macro is actually used in the application then yes, it's accessible in the executable file -- it has to be for the program to use it.
Any credential you embed in your program can be recovered by a sufficiently-motivated attacker. There is no encryption mechanism you can use to prevent this, as you would need to provide the decryption key for the program to function.
The proof is very simple: if the program itself can obtain the credential without any user input, then the executable file must contain the key, or all of the information needed to produce/derive the key. Therefore, it must be possible for anyone (with the requisite expertise) to produce the credential with only the information in the executable file.
This could be done by inspecting the executable. It could also be done by running the executable under the supervision of a debugger and watching what it is doing.
This is the same reason DRM schemes are pointless -- the consumer must be in possession of a key to use the material, and if they can get their hands on the key (they must be able to in order for them to consume the content) then they scheme doesn't work. (Of course, in newer DRM schemes the key is buried in a chip that is designed to destroy the key if it is opened, but that just means it's difficult to get the key, not impossible.)
tl;dr: It's never a question of whether it's possible to recover an embedded key. It's always possible. It's a question of how much effort it will take to recover that key.
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.
I need to provide my users the ability to write mathematical computations into the program. I plan to have a simple text interface with a few buttons including those to validate the script grammar, save etc.
Here's where it gets interesting. These functions the user is writing need to execute at multi-megabyte line speeds in a communications application. So I need the speed of a compiled language, but the usage of a script. A fully interpreted language just won't cut it.
My idea is to precompile the saved user modules into objects at initialization of the C++ application. I could then use these objects to execute the code when called upon. Here are the workflows I have in mind:
1) Testing(initial writing) of script: Write code in editor, save, compile into object (testing grammar), run with test I/O, Edit Code
2) Use of Code (Normal operation of application): Load script from file, compile script into object, Run object code, Run object code, Run object code, etc.
I've looked into several off the shelf interpreters, but can't find what I'm looking for. I considered JAVA, as it is pretty fast, but I would need to load the JAVA virtual machine, which means passing objects between C and the virtual machine... The interface is the bottleneck here. I really need to create a native C++ object running C++ code if possible. I also need to be able to run the code on multiple processors effectively in a controlled manner.
I'm not looking for the whole explanation on how to pull this off, as I can do my own research. I've been stalled for a couple days here now, however, and I really need a place to start looking.
As a last resort, I will create my own scripting language to fulfill the need, but that seems a waste with all the great interpreters out there. I've also considered taking an existing open source complier and slicing it up for the functionality I need... just not saving the compiled results to disk... I don't know. I would prefer to use a mainline language if possible... but that's not required.
Any help would be appreciated. I know this is not your run of the mill idea I have here, but someone has to have done it before.
Thanks!
P.S.
One thought that just occurred to me while writing this was this: what about using a true C compiler to create object code, save it to disk as a dll library, then reload and run it inside "my" code? Can you do that with MS Visual Studio? I need to look at the licensing of the compiler... how to reload the library dynamically while the main application continues to run... hmmmmm I could then just group the "functions" created by the user into library groups. Ok that's enough of this particular brain dump...
A possible solution could be use gcc (MingW since you are on windows) and build a DLL out of your user defined code. The DLL should export just one function. You can use the win32 API to handle the DLL (LoadLibrary/GetProcAddress etc.) At the end of this job you have a C style function pointer. The problem now are arguments. If your computation has just one parameter you can fo a cast to double (*funct)(double), but if you have many parameters you need to match them.
I think I've found a way to do this using standard C.
1) Standard C needs to be used because when it is compiled into a dll, the resulting interface is cross compatible with multiple compilers. I plan to do my primary development with MS Visual Studio and compile objects in my application using gcc (windows version)
2) I will expose certain variables to the user (inputs and outputs) and standardize them across units. This allows multiple units to be developed with the same interface.
3) The user will only create the inside of the function using standard C syntax and grammar. I will then wrap that function with text to fully define the function and it's environment (remember those variables I intend to expose?) I can also group multiple functions under a single executable unit (dll) using name parameters.
4) When the user wishes to test their function, I dump the dll from memory, compile their code with my wrappers in gcc, and then reload the dll into memory and run it. I would let them define inputs and outputs for testing.
5) Once the test/create step was complete, I have a compiled library created which can be loaded at run time and handled via pointers. The inputs and outputs would be standardized, so I would always know what my I/O was.
6) The only problem with standardized I/O is that some of the inputs and outputs are likely to not be used. I need to see if I can put default values in or something.
So, to sum up:
Think of an app with a text box and a few buttons. You are told that your inputs are named A, B, and C and that your outputs are X, Y, and Z of specified types. You then write a function using standard C code, and with functions from the specified libraries (I'm thinking math etc.)
So now your done... you see a few boxes below to define your input. You fill them in and hit the TEST button. This would wrap your code in a function context, dump the existing dll from memory (if it exists) and compile your code along with any other functions in the same group (another parameter you could define, basically just a name to the user.) It then runs the function using a functional pointer, using the inputs defined in the UI. The outputs are sent to the user so they can determine if their function works. If there are any compilation errors, that would also be outputted to the user.
Now it's time to run for real. Of course I kept track of what functions are where, so I dynamically open the dll, and load all the functions into memory with functional pointers. I start shoving data into one side and the functions give me the answers I need. There would be some overhead to track I/O and to make sure the functions are called in the right order, but the execution would be at compiled machine code speeds... which is my primary requirement.
Now... I have explained what I think will work in two different ways. Can you think of anything that would keep this from working, or perhaps any advice/gotchas/lessons learned that would help me out? Anything from the type of interface to tips on dynamically loading dll's in this manner to using the gcc compiler this way... etc would be most helpful.
Thanks!
How can I see the source code of an executable compiled by Delphi or C++?
Please help me.
After Edit:
I have a program. When I start this program, it shows a dialog and asks for a password. This password is saved in source code. I want to take this password quickly and easily.
You can't.
An enormous amount of information is thrown away when the compiler reduces human readable text source code down to machine executable code. Local variables don't need names in machine code, for example, they're just register bits in the instruction opcode.
This is why debugging a compiled executable to step through the original source files line by line can only be done if you have the compiler debug symbols to go with the executable.
There are utilities that attempt to reverse engineer machine code into source code, but the result is less readable to humans than the original machine code, in my opinion. Machine generated function names, machine generated local variables and arguments, and many times the utility has to guess as to the exact data types of arguments and local vars. (is this arg a signed int or an unsigned int? Hard to tell when it's just a stack slot or machine register)
Compiling to an intermediate representation, as is done in Java and .NET, provides for much more reversibility because the types and symbol names of much of the original code are retained. Reflector, for example, can emit C# source code that is very close to the original human written source code.
You can't. The compiler takes the source code and turns it into machine instructions leaving 'no trace' of the original source code behind.
There are programs called de-compilers, but they just basically automate reverse-engineering, they can't actually access the original source code because that's long gone.
by using a disassembler or decompiler. You can't ever get the original source code back from a binary though. That information is lost.
How Can I See a Source Code of Executive File Compiled By Delphi or C++?
You can't, because source code does not exist in compiled Delphi/C++ program.
I Have a Program.When I Start This Program,Show a Dialog And Ask a Password.This Password Saved in Source Code.I Want take This Password Quickly And Easily.
Trying to crack something, huh?
It is quite possible that password is not saved in source code. Hash function can be used on a password to check if it is valid without storing password in a source code. Even if you find a hash, it won't be easy to get a password from it.
You can get an assembler listing from program using a disassembler (Ida Pro, OllyDBG, or similar tool). And you could debug your program even without source code, although you'll see pure assembly. AFAIK, "decompilers" exist, but I haven't ever used one of them, and doubt that they will be useful for C++/Delphi code (the one that compiles into native application).
There are a few simple techniques that would allow to hack program and bypass password check (if some conditions are met, program author wasn't into security, protection is easy, etc), but I'm not sure if this is allowed discussion topic on stackoverflow.
Anyway, if you're interested in reverse engineering for legal purposes, you could try a book called "Reversing: Secrets of Reverse Engineering".
When you say "executive" do you mean "executable"? If so, decompiling will only get you assembly. Some decompilers will try to turn the assembly into a more readable form, but there's no general way to get the source code from an exe unless you actually compile the source code into the file.
First off, the password is not saved in the source code. The compilation process is one-way only; the finished product isn't going to go altering its source. (Or its binary, for that matter, in most cases at least.) The password is most likely saved in a data file someplace. And if the program's author is at all competent, the password is hashed or encrypted in some way. Decompiling the program won't help you much.
Also, as InsertNickHere mentioned, we're not a hacking site here. We're honorable coders helping each other out with the complexities involved in building legitimate software. Please take your shady questions elsewhere.
I want to have a few strings in my c++ app and I want to be able to edit them later in the deployed applications (the compiled exe), Is there a way to make the exe edit itself or it resources so I can update the strings value?
The app checks for updates on start, so I'm thinking about using that to algo send the command when I need to edit the strings (for example the string that contains the url used to check for updates).
I don't want to use anything external to the exe, I could simply use the registry but I prefer to keep everything inside the exe.
I am using visual studio 2010 c++ (or any other version of ms visual c++).
I know you said you don't want to use anything external to the program, but I think what you really want in this case is a resource-only DLL. The executable can load whichever DLL has the strings that you need in a given invocation.
Another idea is to move the strings into a "configuration" file, such as in XML or INI format.
Modifying the EXE without compilation is hacking and highly discouraged. You could use a hex editor, find the string and modify it. The new text must be have a length less than or equal to the original EXE.
Note, some virus checkers perform CRCs or checksums on the executables. Altering the executables is a red flag to these virus checkers.
It is impossible, unless your strings won't change in position & length.
So to make it possible: make your "size" of the, in your example, URL that is used to get updates pretty big (think of: 512 characters, null-filled at the end). This way, you have got some space to update the String.
Why is it impossible to use variable-sized strings? Well I can explain this with a small x86 Assembler snippet:
PUSH OFFSET test.004024F0
Let's say; at the offset of test.004024F0 is your variable-sized string. Now consider the change:
I want to insert a string, which is longer than the original string, which is stored before the string at 004024F0: This makes 004024F0 to a new value, let's say: 004024F5 (the new string, before this entry, is 5 characters longer than it's original).
You think it's simple: search for all 004024F0 and replace it with 004024F5? Wrong. 004024F0 can also be a regular "instruction" (to be precise: ADD BYTE PTR DS:[EAX+24],AL; LOCK ...). If this instruction happens to be in your code, it'll be replaced by something wrong.
Well, you might think, what about searching for that PUSH instruction? Wrong: there are virtually unlimited ways to "PUSH". For instance, MOV EAX, 004024F0; MOV ESP, EAX; ADD ESP, 4. There is also the possibility that the field is calculated: MOV EAX, 00402000; ADD EAX, 4F0; .... So this makes it "virtually unlimited".
However, if you use statically sized fields; you don't have to change the code refering to Strings. If you reserve enough space of a specific field, then you can easily write a "longer" string than original, because the size of a string is calculated by finding the first "null-byte"; pad the rest of the field with nulls.
If you use statically sized fields, it's, however, very hard to find the "position in the file", at compile-time. Considering a lot of time spending hacking your own app; you can write code that modifies the .exe, and stores a new String value at a specified offset. This file-offset isn't known at compile time, and you can patch this file-offset yourself later, using a tool like OllyDbg. This enables the executable to patch itsself :-)
Creating a self-editing exe is a very ill-advised approach to solving this problem. You are much better off storing and reading the strings from an external file. Maybe if you provide some background as to why you don't want to use anything but an exe, we can address those issues?
In theory, BeginUpdateResource, UpdateResource and EndUpdateResource are intended for this purpose. In reality, getting these to work at all is pretty tricky. I'm not at all sure they'll work for updating resources in a running executable.
Not wanting to chastise, but this doesn't sound like a great idea. Having the URL for checking for updates baked inside the program makes it inflexible.
You're trying to mitigate the inflexibility by rewriting the strings in your exe. This is really asking for trouble:
are you sure users that run your program have write permission to be able to update the exe? Default users have no write access to files installed in the program folder.
If the program is run by multiple users or simply multiple times by the same user, the exe will be locked and unmodifiable
Systems administrators will have a hard time tweaking the URL.
There is a real risk you will corrupt your exe. The rewrite process is likely to be complex, especially if you want to make the URL longer than is presently allocated.
By modifying your exe, you remove the possiblity of using code signing, which can be useful in a networked environment.
The registry (despite all it's weaknesses) is really where this kind of configuration data should go. You can put a default value in your EXE, but if you need to make changes, put them in the registry. This makes the changes transparent, saving you a lot of grief later.
Yyour algorithm that wants to write a new URL for updates should do this by writing it to the registry. Alternatively, have a config file that ships alongsite with your exe, and update that. (But bear in mind user permissions - you may not have write access to that file, but you can always write to the user hive of the registry.)