I have a bunch of AES256-encrypted ZIP containers (using DotNetZip), and I am writing a program to help the user understand what is inside them. I would ship the "Launcher" program with XML doc which I am also encrypting the "metadata" so to speak in AES256 as well. I was considering encrypting the password to the various (1-10+ zip files) in a strong AES256 string within the XML document for convenience (so the user only has to enter it once). It unsettles me, but what little "usability" tests we have done has shown people don't want to enter a password 7 times.
So, assuming the string is fully encrypted within the XML/dat/whatever file, how much do I detour the other "factors" within my program? I would have to hard-code the decryption/IV/salt/etc (or at least pass it to a deypcrtion method) no?
I've been trying to understand what things like DotNetCrack (http://www.dotnetcrack.com/) can easily get from my program. I know that nothing is perfect and memory dumping is a huge problem, but I want to at least detour the really easy "script kiddie" sort of stuff.
I've looked at secure-string, but it seems like a silly solution in-so-far you have to decrypt eventually anyways.
EDIT for clarity -- The ZIP files are self-extractors, e.g. just zip files wrapped into the EXE. They may be zips, either way it doesn't matter. My program is just to help somebody extract all the contents without having to click each one AND help them navigate through the ZIPs which may be confusing to a novice user.
All my program is doing is reading the XML file with "data" about each zip (e.g. zip001 is "information from john smith etc etc" -- but the zip file name is something like BOBSMITH_INFO_001.EXE (.zip).
how much do I detour ?! that's the question. when we talk about obfuscation e battle between cracker and programer never ends so basically as much as you can. to stop a script kiddie the basic technics like hardcoding an encrypted version of key and decrypting it before use should work but then again that depends on how motivated your script kiddie is!
that said you can check Reflector and ILDASM (in vs tools) to see that any hardcoded string is found in few seconds! you should also know that the .net is compiled to IL which is a very high level and hence easy to read intermidiate language. so a very simple obfuscation like XOR ing the key and hardcoding it is easy to track even by a script kidie.
As for the solution, use multi levels of encryption. keep the key splited in multiple places encrypted. and even better try write an algorithm that generates the key in runtime. after you did all that, Use an Obfuscator to complicate the thing even further.
Good luck.
Related
I'm developing an application in c# which uses an .xml file to obtain information that is used inside the logic of the app. When a new version of the app is launched, a setup is created (using Inno Setup Compiler) and after successfully installing the setup, the .xml is placed inside the setup files of the app. This .xml file contains about 200 objects with 4 properties each of sensitive data.
I got asked to launch a customer version of the app, and a requirement for this version is to remove the access or manipulation of this .xml file, since it contains sensitive data that the customer should not be able to see or manipulate.
My senior engineer told me to simply implement the information inside a list in the source code, so that the use of the .xml file is removed and the customer can't manipulate this info once installed the app, as it would be hidden inside the source code, but this seems really inefficient for me and i would need to change a lot of logic about the use of the .xml file inside the app for this to work.
Is there a way to create a setup of the app and hiding this file in the setup files so it cant be manipulated by the customer?
If there isn't, what approach could you suggest me to do? Or do i have no options but to do this the hard way?
If you want to make it harder for the end user to modify the information, while still keeping a separate configuration file that won't require code change of the application itself, you can sign the file and have the application verify the signature.
A simplest way is to to calculate a hash of a file and "secret" value. Of course it is hardly tamperproof. But in the end, there's no tamperproof way to prevent a user from manipulating data on his/hers own computer. It's only about how hard you want to make it.
A better way would be to use a proper certificate for the signature. The application will know only the public key and will use it to verify a signature created with a private key, which will never leave the development team.
From a theoretical standpoint, if your program can get hold of the data, then a user with full control of the computer on which the program is running can also get hold of the data if they try hard enough. That means you can make it difficult for them, but you can't make it impossible. So if that's what you're trying to achieve, you need to be quite clear about the limitations of the approach.
How difficult should you make it? Well, if it's purely a commercial risk, you should make it hard enough that the cost of getting the data is greater than the benefit. If the risk can't be measured in that way, for example if there are legal requirements for you to protect the data, then that isn't going to be good enough.
For some situations, it's probably enough to encrypt the XML file, and bury the decryption key deep within the logic of a compiled program written in a language that doesn't allow easy decompilation. That's likely to be better than simply burying the XML data within the compiled program, which is what your senior engineer is suggesting. But her suggestion may be OK too. It really shouldn't be too difficult to change the program logic from reading an external file to reading a string constant within the program.
I have a WinForms application which reads data from a sensitive file and performs calculations using that data. In order to keep the sensitive information from people's PCs, we decided to move the calculations to a web service, where the file will hide in a protected folder and only is accessible by the web service program itself.
Due to some complications it looks like it may not be possible to secure the server space in the required timeframe, so what we are now looking to do is use encryption to protect the file so that it can be safely distributed to people's PCs.
My question is this. Is is possible to encrypt a file (once, so a pre-encrypted file will be attached to the project) and then decrypt the file for use by the application without revealing
The sensitive information inside the file
The Encryption key used to decrypt the file
I know it is possible to generate source code from a .exe file so I would be looking for a solution that bears this in mind. I am new to this kind of app development so please excuse me if this is a stupid question and that what I am trying to do is not actually possible.
Cheers
No, it is not possible, you can only make it hard to do those two things. You can not make it impossible. All you can do is just make it hard enough it is not worth the effort to try, and that takes money to do (via specialized obfuscation software and paying experts in the field to look at your code and make it more secure)
I am creating an application with the purpose of receiving an encrypted string, decrypting it and passing the clear text string as arguments to a PowerShell script.
The executable has to be self contained, cannot connect to things like a SQL DB or anything alike. The cipher will always be the same, which means that the password/salt can't really be random either.
I know that hardcoding the password/salt is not really a good idea, but I'm struggling with how store a password/salt that doesn't change in a secure way in a self-contained executable.
Right now what I'm doing is rather than having a static string as the password/hash, I create a password and salt based on the modified date of the executable itself (with a few more things done to it). If the executable changes I'll have to recreate the cipher as the previous one cannot be decoded anymore, but at least I'm not really hardcoding a password and/or salt.
Still, I'm not sure just how secure this is and am sure there has to be a better way.
Any suggestions?
EDIT
The only place where this will be used is inside a task sequence running inside SCCM, which means that users won't be able to interact with the computer at all during the time that the task sequence is running (assuming that debug mode is not enabled, else there's also far worse things to worry about).
So I could potentially pass it in clear text to the script as no one would be able to read it since they can't interact with the PC, but then SCCM would automatically output it to logs, which obviously I don't want. I could write it on the script which would avoid having it on the logs, but if someone gets a hold of the script, bearing in mind it's a script and not compiled code, they'd know the password.
Remember the password/salt are not actually hardcoded strings as it is, they are generated during runtime, so they will not be visible using a disassembler.
This article can help you to decide how you need to design password storage
http://flagdefenders.blogspot.in/2012/12/how-to-save-password-securely.html
Lets say my program is an Anti-Virus.
Lets also say I have a file, called "Signatures.dat". It contains a list of viruses to scan.
I would like to encrypt that file in a way that it can be opened my by anti-virus on any computer but the users wont able to see the content of that file.
How would I accomplish that task ?
I was looking at thigs like DPAPI, but I dont think that would work in my case because it's based on User's setting. I need my solution to be universal.
I've got a method to encrypt it, but then I am not sure how to store the keys.
I know that storing it in my code is really unsecure, so I am really not sure what to do at this point.
You want the computers of the users to be able to read the file, and you want the computers of the users to be unable to read the file. As you see, this is a contradiction, and it cannot be solved.
What you are implementing is basically a DRM scheme. Short of using TPM (no, that doesn't work in reality, don't even think about it), you simply cannot make it secure. You can just use obfuscation to make it as difficult as possible to reverse-engineer it and retrieve the key. You can store parts of the key on a server and retrieve it online (basically doing what EA did with their games) etc., but you probably will only make your product difficult to use for legitimate users, and anyone who really wants to will still be able to get the key, and thus the file.
In your example are you trying to verify the integrity of the file (to ensure it hasn't been modified), or hide the contents?
If you are trying to hide the contents then as has been stated ultimately you can't.
If you want to verify the file hasn't been modified than you can do this via hashes. You don't appear to have confused the two use-cases but sometimes people assume you use encryption to ensure a file hasn't been tampered with.
Your best bet might be to use both methods - encrypt the file to deter casual browsers, but know that this is not really going to deter anyone with enough time. Then verify the hash of the file with your server (use https, and ensure you validate the certificates thumbprints). This will ensure the file hasn't been modified even if someone has cracked your encryption.
I'm working on a solution and one of the features is to check that some files have not been tampered in other words hacked. I was planning on using the MD5 sum with a mixture of created and modified dates, but wanted to see if anybody has done something like this before. I'm using C# at the moment but you could suggest any other language. I just want to hear the technique part of it or architecture.
We have an application that checks file validity for safety reasons. The CRC32 checksums are stored in a separate file using a simple dictionary lookup. Which of CRC32, MD5, or any other hashing/checksumming feature is purely choice: you simply need to know if the file has changed (at least that's what you've said). As each byte of the file is included in the calculation, any changes will be picked up, including simple swapping of bytes.
Don't use file dates: too unreliable and can be easily changed.