So I’m trying to understand what the process is of encrypting a program I wrote. How does it work. When you encrypt something can that executable be ran without a key? Is there a key that is used?
If you can explain this or add some links that would be great.
There are many different approaches to protecting code. They all fall under the category of DRM (Digital Rights Management).
These are what come to mind for me:
Encryption, actually modifying the byte codes in such a way that they can only be executed if a key or password is provided.
Obfuscation, rearranging code into a way that is still fully executable as is, but reversing by hand is tedious because the code is purposely arranged into a non-standard/confusing order.
Shield, protecting active code that has been loaded into runtime memory. This can be done either with another process that is performing real-time memory checking with checksums. Or it can be done via in memory code encryption with the key stored somewhere in memory that only the application knows where to find it.
There are so many options for DRM, that I'd have trouble picking any implementations that stand out to list here. A simple google search should help point you in the direction of actual implementations.
Related
I'm using an Instant Messaging software, and I suspect that the software is retaing a lot of information about my machine (such as my MAC address) and possibly leaks it. I decided I want to check the local DBs of the software and see what it saves locally.
I have been able to locate, using the software's own log dump and Procmon, the interesting DBs. However, they are SQLite DBs that are key-protected.
Do I have any way to know what will be the format and size of the key? Will it be hex?
How can I efficiantly continue my research? I looked, using procmon, and been able to detect the first time that the software uses a key-protected DB from the first time it is being opened. However, I couldn't detect any 'interesting' local file that the software uses and could hint about the key's location - apart from several Windows Registries values that are being used - but I'm not so sure on how to approach that.
Sorry if I have mistakes in English, and thank in advance.
Do I have any way to know what will be the format and size of the key? Will it be hex?
The key is just in plaintext (just like normal passwords) and the size is (also like passwords) defined by the creator of the database.
How can I efficiantly continue my research?
I would recommend reverse engineering the application and look for the part, where the connection to the database gets initiated. For that, you can use dynamic analysis (with a debugger) or static analysis (analyse the binary with a disassembler).
Can anyone help me out with this issue? When I run my decryption code, it asks for passphrase every time and fails if not entered. I want to automate this so that the passphrase is not asked every time. I'm using kleopatra to import/export public/secret keys with GPG4win installed.
I can understand your frustration, however, I believe that functionality is intended. If the private key were kept open for a time period or the passphrase cached, that would pose a security hole where either one could possibly leak.
While OSs have security measures in place to prevent other processes from reading memory that doesn't belong to them, there are still ways around this. The ways that come to mind first are more likely to be done in a research lab than real life, but security experts would still throw up red flags.
It is possible to use a command line to decrypt multiple files all at once, see how-to-use-gpg-to-decrypt-multiple-files-to-a-different-directory. Hope that helps.
I have developed a tool that loads in an configuration file at runtime. Some of the values are encrypted with an AES key.
The tool will be scheduled to run on a regular basis from a remote machine. What is an acceptable way to provide the decryption key to the program. It has a command line interface which I can pass it through. I can currently see three options
Provide the full key via CLI, meaning the key is available in the clear at OS config level (i.e. CronJob)
Hardcode the key into the binary via source code. Not a good idea for a number of reasons. (Decompiling and less portable)
Use a combination of 1 and 2 i.e. Have a base key in exe and then accept partial key via CLI. This way I can use the same build for multiple machines, but it doesn't solve the problem of decompiling the exe.
It is worth noting that I am not too worried about decompiling the exe to get key. If i'm sure there are ways I could address via obfuscation etc.
Ultimately if I was really conscious I wouldn't be storing the password anywhere.
I'd like to hear what is considered best practice. Thanks.
I have added the Go tag because the tool is written in Go, just in case there is a magical Go package that might help, other than that, this question is not specific to a technology really.
UPDATE:: I am trying to protect the key from external attackers. Not the regular physical user of the machine.
Best practice for this kind of system is one of two things:
A sysadmin authenticates during startup, providing a password at the console. This is often extremely inconvenient, but is pretty easy to implement.
A hardware device is used to hold the credential. The most common and effective are called HSMs (Hardware Security Modules). They come in all kinds of formats, from USB keys to plug-in boards to external rack-mounted devices. HSMs come with their own API that you would need to interface with. The main feature of an HSM is that it never divulges its key, and it has physical safeguards to protect against it being extracted. Your app sends it some data and it signs the data and returns it. That proves that that the hardware module was connected to this machine.
For specific OSes, you can make use of the local secure credential storage, which can provide some reasonable protection. Windows and OS X in particular have these, generally keyed to some credential the admin is required to type at startup. I'm not aware of a particularly effective one for Linux, and in general this is pretty inconvenient in a server setting (because of manual sysadmin intervention).
In every case that I've worked on, an HSM was the best solution in the end. For simple uses (like starting an application), you can get them for a few hundred bucks. For a little more "roll-your-own," I've seen them as cheap as $50. (I'm not reviewing these particularly. I've mostly worked with a bit more expensive ones, but the basic idea is the same.)
I have developed a Client/Server application for IM with Qt. So far messages are sent and displayed at the client side, but when the program is closed the messages are no longer available since a proper storage is missing.
I would like to keep the messages on the client devices and avoid to store everything on the server. I don't want to use a DB either since it needs to be installed and I would like to keep everything quite easy.
Therefore I was thinking of simply storing everything in an encrypted file, but I couldn't think of a proper format to do that.
Has anyone experience with that or any suggestions how to save the messages from different clients?
You do have a concern with data integrity in face of unplanned termination of your software, due to bugs in your code, transient hardware errors, power outages, etc. That's the problem that everyone using "plain files" usually ignores, as it's a hard problem to solve and requires extensive testing and know-how.
That's why you should use an embedded database. It will solve that, and many other problems as well. SQLite is a de-facto standard for applications such as yours. You can add any encryption you wish, as SQLite provides hooks that let you implement writing and reading of the pages. You'd do the encryption there.
One little-appreciated aspect of SQLite specifically is the amount of testing it gets during development. The test harness, most of it non-public, is probably worth way more than the published SQLite code (>1M USD). SQLite is used in aerospace applications, e.g. IIRC in code classified as DAL-B under DO-178B.
Go/Golang in general at the moment is a hard thing to search for, nor did I find what I was looking for here. I know there some level of encryption that can be done during compilation of an app in several languages. Can anyone give me a quick rundown of the security of Go source code after being compile to an exe? If it can be read, at least in part, is there anything out there to increase security of the source code?
Distribute only the binary (per platform/architecture). That's the best you can get with any language. There's no way how to distribute a program while being safe of reverse engineering it. Anyone telling you something different is probably just trying to sell you a "protection" scheme. No such thing really exists.
On the other hand: 99.9% of your potential users probably have no idea how to reverse engineer your program.
On the yet another hand: It's enough if 0.01 of your potential users have the ability to reverse engineer your program and you're doomed.
IOW, try to find out a business model which relies on anything else but security by obscurity. Actually, even open source code can generate profit - if the value of it is not only in having access to the source code per se.