so I was wondering if I could simply use some identification passages in my application to identify the origin of a copyright infringement (not yet implemented, just a thought). But then I figured, probably it's possible to simply cut the respective passages in my code or edit them to make identification impossible with the help of a hex editor or thelike. Is this possible? Let's assume for example I would put a hidden comment into the code which could be accessed in a certain secret way (e.g. by clicking somewhere). Now if someone possessed two program units (i.e. which were sold to two different people) would he be able to delete/edit the ''difference'' in a hex editor?
You can calculate a hash of (the important parts of) the executable, sign it cryptographically, and embed the hash and signature in the executable. If the executable is modified, the hash will change. If the hash is modified, the signature won't match.
If you'd prefer to prevent infringement, rather than just detecting it, then each time the executable runs, it can validate the hash and the signature, refusing to run if they've been modified.
To identify the source of an application you need to be able to uniquely identify the application.
This is usually done by providing each customer with a unique key that must be present for the application to run. On start-up the application checks the key is present and is valid.
You can prevent simple editing of the key by using cryptographic means of encoding the key. Thus modifying the key with a hex editor will not produce a new key but an invalid key. Just make the program refuse to run when there is an invalid key.
Related
I am currently developping a windows application who test railroad equipments to find any defaults.
Utility A => OK
Utility B => NOK
...
This application will check the given equipment and generate a report.
This report needs to be written once, and no further modifications are allowed since this file can be used as working proof for the equipment.
My first idea was ta use pdf files (haru lib looks great), but pdf can also be modified.
I told myself that I could obsfuscate the report, and implement a homemade reader inside my application, but whatever way I store it, the file would always be possibly accessed and modified right?
So I'm running out of ideas.
Sorry if my approach and my problem appear naive but it's an intership.
Thanks for any help.
Edit: I could also add checksums for files after I generated them, and keep a "checksums record file", and implement a checksums comparison tool for verification? just thought about this.
I believe the answer to your question is to use any format whatosever, and use a digital signature anybody can verify, e.g., create a gnupg, get that key signed by the people who require to check your documents, upload it to one of the key servers, and use it to sign the documents. You can publish the documents, and have a link to your public key available for verification; for critical cases someone verifying must be trust your signature (i.e., trust somebody who signed your key).
People's lives depend on the state of train inspections. Therefore, I find it hard to believe that someone expects you to solve this problem only using free-as-in-beer components.
Adobe supports a strong digital signature model. If you buy into their technology base, you can create PDF's that are digitally signed, and are therefore tamper-evident, as the consumer can check for the signature.
You can, as someone else pointed out, use GNUpg, or for that matter OpenSSL, to implement your own signature scheme, but railroad regulators are somewhat less likely to figure out how to work with it.
I would store reports in an encrypted/protected datastore.
When a user accesses a report (requests a copy, the original is of course always in the database and cannot be modified), it includes the text "Report #XXXXX". If you want to validate the report, retrive a new copy from the system using the Report ID.
I would like to know some tips how to secure DLL (Win32, dynamic) file from injecting and how to increase security of compiled code.
There's a SQL password in DDL source code which is used to connect to MySQL. Is it secure enough to leave it?
Is there any way how to prevent 'users' modifying HEX code? I mean to secure more from source code.
Which options in project properties would be optimal for optimizing and maybe securing DLL?
Im using MVSC++ 2010 Express and source code to users won't be available.
In order for the DLL to be usable it needs to be readable. That means that if you encrypt your file you also need do decrypt it before using it. Also, you can sign your DLL so that you know it has not been modified, but still that doesn't hide the symbols in the file itself. Another approach would be to obfuscate the code so that it is harder for users to understand but the OS can still easily execute it - think of that as a weak form of encryption.
Specific answers:
If you have a password in any binary file then it is not secure. It is a simple matter of looking through the strings of the binary file to find it.
Users can always modify the file, but the file can be signed using some cryptographic scheme which ensures that you will know if it has been tampered with.
I don't use that particular tool but I'm sure that it will not provide you with any real security.
Tip: Instead of having an SQL DB password in your source code you could instead make it send commands to a server which would authenticate and process them. That way you don't need an explicit password in your file.
Any and every literal string in your DLL is readable unless you encrypt the entire file. Do NOT store passwords as literal strings in your dll. Period. Also, you have to remember that assembly code is just data, and if the file is writable, anyone with an Intel reference sheet and a hex editor, or a disassembler and a an assembler can change it if they have access to the file. You can always obfuscate your source, which will make the assembly slightly less readable, but still completely modifiable.
In short, nothing you do will completly secure your DLL.
I have written a small app in C++ consisting of a single EXE file.
I want to put in its "about" dialog the md5sum of the executable itself. It should be embedded statically into the executable (so that can be seen from hex editor), rather than computed on the fly.
As both #Shi & #matthewdaniel have already said, this can't be done directly.
However a couple of workarounds are possible:
Calculating MD5 of your application, and packaging your executable inside a container app that will simply extract it and check it's MD5
Compiling your code and hashing only the code segments or other segments (except the Data), and than adding the MD5 check code. This will work as the MD5 string will be stored in the Data segment keeping the validity of the precalculated hash of any other memory segment valid.
This is not possible.
If you enter the md5 hash into the binary, the binary will change, so the md5 hash changes as well. If you create a new one, and try to add it to the binary, the binary will change again.
So best is to put the hash into a file, and read that file and display its content.
Another way could be to create the md5 hash of the binary, and then append it to the executable. In order to fetch the value, you read the last 32 byte of the binary and display it as md5. Of course, if you create a hash of the complete executable, it won't match the hash - you have to create the hash of the executable excluding the last 32 byte.
If you store the 128 bit md5 hash in a raw format (base 256 instead of base 16), you only need 16 byte.
As soon as you add the md5 to the file the file will have a different md5. There is no way to get the md5 in the file itself.
The typical method is a signature. A signature is a hash that is further signed by a public/private key. The application can use the public key to verify the hash contained within.
However, this needs to be separate from the executable. As the other answers state, it is impossible to do this with one file. You can merge the signature and the binary and provide instructions to use tools to separate them to compute the verification.
However, this does not stop in-memory attacks against the application. Ie, you have a buffer overflow and an attacker can re-write code in memory.
You might not need the hash of the public key. You need to encrypt the hash of the binary so it can not be altered. You might use the hash of the public key to verify instructions to user, etc. The distribution of the public key and verification instruction can not be bundled. Otherwise an attacker can just re-create with an alternate key pair. Including the hash of the public key can prevent some other attack against instruction. Ie, the signature has some verification that the advertised public key is matching what the binary was signed with.
Using established methods is probably better as users can have alternate tools to verify the integrity. Also, this only makes the public key needed to distribute through some other channel.
Reference: Digital signature with OpenSSL
The above fixes another attack. Given that what you said was possible, what would stop someone else from doing the same thing, but with a trojan horse binary. Distribution of the public key is an authentication of the source (legitimate developer). None of the other answers addressed this.
I want to verify if the text log files created by my program being run at my customer's site have been tampered with. How do you suggest I go about doing this? I searched a bunch here and google but couldn't find my answer. Thanks!
Edit: After reading all the suggestions so far here are my thoughts. I want to keep it simple, and since the customer isn't that computer savy, I think it is safe to embed the salt in the binary. I'll continue to search for a simple solution using the keywords "salt checksum hash" etc and post back here once I find one.
Obligatory preamble: How much is at stake here? You must assume that tampering will be possible, but that you can make it very difficult if you spend enough time and money. So: how much is it worth to you?
That said:
Since it's your code writing the file, you can write it out encrypted. If you need it to be human readable, you can keep a second encrypted copy, or a second file containing only a hash, or write a hash value for every entry. (The hash must contain a "secret" key, of course.) If this is too risky, consider transmitting hashes or checksums or the log itself to other servers. And so forth.
This is a quite difficult thing to do, unless you can somehow protect the keypair used to sign the data. Signing the data requires a private key, and if that key is on a machine, a person can simply alter the data or create new data, and use that private key to sign the data. You can keep the private key on a "secure" machine, but then how do you guarantee that the data hadn't been tampered with before it left the original machine?
Of course, if you are protecting only data in motion, things get a lot easier.
Signing data is easy, if you can protect the private key.
Once you've worked out the higher-level theory that ensures security, take a look at GPGME to do the signing.
You may put a checksum as a prefix to each of your file lines, using an algorithm like adler-32 or something.
If you do not want to put binary code in your log files, use an encode64 method to convert the checksum to non binary data. So, you may discard only the lines that have been tampered.
It really depends on what you are trying to achieve, what is at stakes and what are the constraints.
Fundamentally: what you are asking for is just plain impossible (in isolation).
Now, it's a matter of complicating the life of the persons trying to modify the file so that it'll cost them more to modify it than what they could earn by doing the modification. Of course it means that hackers motivated by the sole goal of cracking in your measures of protection will not be deterred that much...
Assuming it should work on a standalone computer (no network), it is, as I said, impossible. Whatever the process you use, whatever the key / algorithm, this is ultimately embedded in the binary, which is exposed to the scrutiny of the would-be hacker. It's possible to deassemble it, it's possible to examine it with hex-readers, it's possible to probe it with different inputs, plug in a debugger etc... Your only option is thus to make debugging / examination a pain by breaking down the logic, using debug detection to change the paths, and if you are very good using self-modifying code. It does not mean it'll become impossible to tamper with the process, it barely means it should become difficult enough that any attacker will abandon.
If you have a network at your disposal, you can store a hash on a distant (under your control) drive, and then compare the hash. 2 difficulties here:
Storing (how to ensure it is your binary ?)
Retrieving (how to ensure you are talking to the right server ?)
And of course, in both cases, beware of the man in the middle syndroms...
One last bit of advice: if you need security, you'll need to consult a real expert, don't rely on some strange guys (like myself) talking on a forum. We're amateurs.
It's your file and your program which is allowed to modify it. When this being the case, there is one simple solution. (If you can afford to put your log file into a seperate folder)
Note:
You can have all your log files placed into a seperate folder. For eg, in my appplication, we have lot of DLLs, each having it's own log files and ofcourse application has its own.
So have a seperate process running in the background and monitors the folder for any changes notifications like
change in file size
attempt to rename the file or folder
delete the file
etc...
Based on this notification, you can certify whether the file is changed or not!
(As you and others may be guessing, even your process & dlls will change these files that can also lead to a notification. You need to synchronize this action smartly. That's it)
Window API to monitor folder in given below:
HANDLE FindFirstChangeNotification(
LPCTSTR lpPathName,
BOOL bWatchSubtree,
DWORD dwNotifyFilter
);
lpPathName:
Path to the log directory.
bWatchSubtree:
Watch subfolder or not (0 or 1)
dwNotifyFilter:
Filter conditions that satisfy a change notification wait. This parameter can be one or more of the following values.
FILE_NOTIFY_CHANGE_FILE_NAME
FILE_NOTIFY_CHANGE_DIR_NAME
FILE_NOTIFY_CHANGE_SIZE
FILE_NOTIFY_CHANGE_SECURITY
etc...
(Check MSDN)
How to make it work?
Suspect A: Our process
Suspect X: Other process or user
Inspector: The process that we created to monitor the folder.
Inpector sees a change in the folder. Queries with Suspect A whether he did any change to it.
if so,
change is taken as VALID.
if not
clear indication that change is done by *Suspect X*. So NOT VALID!
File is certified to be TAMPERED.
Other than that, below are some of the techniques that may (or may not :)) help you!
Store the time stamp whenever an application close the file along with file-size.
The next time you open the file, check for the last modified time of the time and its size. If both are same, then it means file remains not tampered.
Change the file privilege to read-only after you write logs into it. In some program or someone want to tamper it, they attempt to change the read-only property. This action changes the date/time modified for a file.
Write to your log file only encrypted data. If someone tampers it, when we decrypt the data, we may find some text not decrypted properly.
Using compress and un-compress mechanism (compress may help you to protect the file using a password)
Each way may have its own pros and cons. Strength the logic based on your need. You can even try the combination of the techniques proposed.
I have a Qt application written in C++ that uses a SSL-connection (QSslSocket) with another application for extra security. However, the application has a private key embedded in it.
With applications like Process Explorer it's really easy to fish out the private key. (Properties of file -> Strings)
Security is not very important for my application but it would be nice to make a little bit more difficult getting the private key from my application. Is there any way?
"strings" only finds blocks that are actual Ascii/UTF8/Unicode strings. If you keep your key around as a binary buffer then there is nothing that discriminates it from random binary data which strings usually ignores.
Other than that, There are much more clever programs out there such as IDA and OllyDebug which enable the user to fully disassemble or even decompile your program and get a hold of the key no matter what you try.
You may need of solutions to your problem from a different angle.
I agree with Shoosh's answer in that no matter what you do a person with the right tools and knowledge will be able to break your code and figure out your private key.
What you need to do is either externalize the data or mitigate the risks if your private keys are found.
The best way to externalize any private data is to encrypt it with a user supplied password that must be entered by the user to be used. Unfortunately this is not really reasonable for most applications.
To mitigate the risks I normally try to ensure that only the one 'install' is compromised if the security is broken.
For example, randomly generate the private key data on install.
For client/server applications you could follow the https model and use public/private key communication to exchange a randomly generated encryption key.
If each client install has there own public/private key set, then the server can tell what clients are connecting and also if there is a problem they can outlaw clients.
Hope that helps.
Crypt it with some simple symmetric algorithm. For example define arrays cryptedData and cryptedDataKey so that n-th byte of your private key can be get by cryptedData[cryptedDataKey[n]]. It will save you from someone who looks to your binary executable with text editor but won't help against more or less experienced person.
Also if you have persistent connections with QSslSocket a runtime it's most likely that private key is stored in memory as is. So only modifying QT library is a way to mangle key presentation in memory.
Another common technique is to put the secret data into a binary resource such as an icon image.