My google search has led me to here: How to create a virtual file?
In that article, people suggested the author to extract the file to a temp directory and work with it from there.
Actually, what I would like to do, is something similar to what the author was originally asking - create a "virtual" file and assign a "path" to it, such that would be understandable by other applications calling standard windows filesystem API. The purpose of this is to prevent copying and unauthorized use.
A concept of what I would like to do:
In our company, we have developed a program - but it's not a standard EXE application, it has an internal format (let's assume the 'application' format's extension is .MDL) and is executed by runtime environment, so the runtime must be installed on the client machine. This concept is similar to Java (although this is not java; just comparing, so that you can better understand). What I want to do now, is to encrypt this .MDL file and include it as a resource in a regular .exe file. This .exe file would check if it's okey to run (check license conditions, keys, authorization etc...) and then, if authenticated, decrypt and extract the .MDL file, exec the runtime and pass the virtual path of the .MDL file as an argument to the runtime.
For obvious reasons, i don't want to write the decrypted .mdl file somewhere on the disk, because somebody could just start the application, wait for the decrypter to write .MDL to temp, copy it from the temp and distribute it.
So, any idea how to do this?
PS: I've got inspired from EA Games' games... when you run them and look into your process table, you see a regular game's exe, and, after certain time, it spawns a new process with name like ~A003.tmp
You should use boxedapp packer. It must help.
I am not aware of any method to have a virtual file associated with a path without using some kind of driver component; that is hard work.
Why don't you have the runtime do the decryption? Then you don't have to worry about decrypting the file on disk. Or you could create an unnamed inheritable section object to which to decrypt the item and pass the handle value to the runtime as a command line parameter.
Whatever you do, people will still be able to bypass it so it seems like a waste of time to me. Every EA game ever made has been cracked; people will either think your product is useful and worth the money or they won't. I don't think it is worth the time or effort to implement schemes more complicated than a very simple registration key check (just to make it look like you did something).
Related
I'm looking for a feature similar to CreateNamedPipe on Windows, which would allow programmatically generating file contents on demand. However, it would need to support seek operation as well, so plain named piped will not work, I think. Or does it?
Some details: The file will be read by other existing program, and changing that is not possible in this case. The two specific uses are: 1. the actual data is in a compressed binary blob. 2. the actual data is behind a network connection, accessed with a custom protocol. In both cases, the "virtual" file would give access to date as if it were a local regular file.
I'm sure this would be possible at least by creating a custom file system device driver, or using existing network file system and creating custom server program. But this sounds like very complex (is it?) and not worth the effort.
So, any practical efficient solution, other than just storing the data to regular temp file?
You need to write a kernel device driver, or take advantage of one of the existing user mode device driver frameworks, such as UMDF. You can start reading up on that on Wikipedia.
I can tell you where non-admin's aren't allowed to write to:
Environment::GetFolderPath(Environment::SpecialFolder::ApplicationData) + "\\Config.ini";
Environment::GetFolderPath(Environment::SpecialFolder::CommonApplicationData) + "\\monitorService\\Config.ini";
Environment::GetFolderPath(Environment::SpecialFolder::ProgramFiles) + "\\monitorService\\Config.ini";
I had high hopes for Environment::SpecialFolder::CommonApplicationData but sadly that one's off limits for ordinary limited users also. I need a common, easy to, err, know & find, directory where I can load configuration data from and save it to. I suppose I could countenance per-user config files, but I'd rather keep things as simple as possible.
Could I perhaps have my installer set aside some area of the registry or filesystem for universal access? I use Innosetup and .NET code to install. I've noticed (IRC) firefox fills up "Application Data" folders for named and default users so I guess that's another possibility. As the config data is needed by the service it might be too much trouble to store a couple of short strings and ints in anything other than the registry.
Since no one has answered I may as well posit my solution while I go about the implementation.
Limited users only have write access to HKCU. This is the same as using the file system- some user specific branches will be writable. It is hassle to have to check for write access to the global config file at the right time the user logs on and then delegate to user-local config if it throws, but that is what must be done. Being easier to defrag and less of a performance hit I will attempt using the FS before HKCU.
Im making an application in cocoa and wanted to see if some strings in it were easily accessible so I ran OTX on it and sadly all of my code was found. Is there a method I can use to make my code more "secure" or at least encrypt/hide the strings? The reason I want to encrypt the string is it's a password for a server. I don'd need it really secure I just don't want the password to be so easy to find.
Thanks for any help
You should never put a password into an executable.
This is like putting the password on a sticky note next to the monitor. If a malicious hacker has your application they can eventually extract the password regardless of what language or API you use to write it.
For example, if I know that your application connects to a password protected server but the application never ask for a password, then I know you've made the mistake of including the password. To find the password, I need only monitor the operation of the program to see what areas of code are active around the time it connects to the server. This will tell me where to focus the search for the password regardless of how big your application is. Then it is only a matter of time until I track the password down. Encrypting the password does no good because the encryption algorithm must also be in the app and I can unravel that as well.
Remember that there are many people out there who can unravel your code using only the raw machine code. For those people it doesn't matter what language or API you use because they all distill to machine code in the end. Those people are the scary skilled gods of programming and they laugh at mere mortals such as you or I. Unfortunately, some of them are evil.
Did I mention that you should never put a password into an executable? If I didn't, let me repeat that you should never put a password into an executable.
In your particular case, as novice programmer, you have no hope of hiding of the password from someone with even a little bit more experience than yourself. This is yet another good reason why you should never put a password into an executable.
1. Avoid ObjC in secure code.
Because ObjC's class system depends heavily on runtime reflection, the whole interface needs to be included alongside the executable. This allows tools like class-dump to easily recover the source #interface of the binary.
Therefore, the secure code functions should be written as a C function, not an ObjC method.
2. Use strip.
By default the compiler will keep all the private symbols (which allows stack trace to be more readable). You can use strip to delete all these symbols.
3. Obfuscation.
The above steps can only hide the code logic. But if the password is a constant string, it is immediately visible using the strings utility. You may obfuscate this by constructing the password in runtime (e.g. store the password encoded in ROT-13 in the file.)
4. Or just change your design.
No matter how good your protection system is, as the hacker have total control on their machine, given enough time, they always win. It's better to revise your design, like why the password must come with the executable? Or why a global password even needed?
In what way is the Windows registry meant to be used? I know it's alright to store a small amount of user preferences, but is it considered bad practice to store all your users data there? I would think it would depend on the data set, so how about for small amounts of data, say, less than 2KB, in 100 or so different key/value pairs. Is this bad practice? Would a flat file or SQLite db be a better practice?
I'm going to take a contrarian view.
The registry is a fine place to put configuration data of all types. In general it is faster than most configuration files and more reliable (individual operations on the registry are transacted so if your app crashes during a write the registry isn't corrupted - in general that isn't the case with ini files).
Marcelo MD is totally right: Storing things like operation percentage complete in the registry (or any other non volitile storage) is a horrible idea. On the other hand storing data like the most recently used files is just fine - the registry was built for just that kind of problem.
A number of the other commenters on this post talking about the MRU list have discussed the problem of what happens when the MRU list gets out of sync due to application crashes. I'm wondering why storing the MRU list in a flat file in per-user storage is any better?
I'm also not sure what the "security implications" of storing your data in the registry are. The registry is just as secure as the filesystem - the registry and the filesystem use the same ACL mechanism to protect their data.
If you ARE going to store your user data in a file, you should absolutely put your data in %APPDATA%\CompanyName\ApplicationName at least - that way if two different developers create an application with the same name (how many "Media Manager" applications are there out there?) you won't have collisions.
For me, simple user configuration items and user data is better to be stored in either a simple XML configuration file, a SQLLite db, or a MS SQL Server Compact db. The exact storage medium depends on the specifics of the implementation.
I only use the registry for things that I need to set infrequently and that users don't need to be able to change/see. For example, I have stored encrypted license information in the registry before to avoid accidental user removal of the data.
Using the registry to store data has mainly one problem: It's not very user-friendly. Users have virtually no chance of backing up their settings, copying them to another computer, troubleshooting them (or resetting them) if they get corrupted, or generally just see what their software is doing.
My rule of thumb is to use the registry only to communicate with the OS. Filetype associations, uninstaller entries, processes to run at startup, those things obviously have to be in the registry.
But data that is for use in your application only belongs in a file in your App Data folder. (whiever one of the 3+ App Data folders Microsoft currently wants you to use, anyway)
As each user has directory space in Windows already dedicated to storing application user data, I use it to store the user-level data (preferences, for instance) there.
In C#, I would get it by doing something like this:
Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData);
Typically, I'll store SQLite files there or whatever is appropriate for the application.
If your app is going to be deployed "in the enterprise", keep in mind that administrators can tweak the registry using group policy tools. For example, if firefox used the registry for things like the proxy server, it would make deployment a snap because an admin can use the standard tools in active directory to set it up. If you use anything else, I dont think such things can be done very easily.
So don't dismiss the registry all together. If there is a chance an admin might want to standardize parts of your configuration across a network, put the setting in the registry.
I think Microsoft is encouraging use of isolated storage instead of the Windows registry.
Here's an article that explains how to use it in .Net.
You can find those files in Windows XP under Documents & Settings\\Local Settings\ App Data\Isolated Storage. The data is in .dat files
I would differentiate:
On the one hand there is application specific configuration data that is needed for the app to run, e.g. IP addresses to connect to, which folders to use for what sort of files etc, and non trivial per user settings.
Those I put in a config file, ini format for simple stuff, xml if it gets more complex.
On the other hand there is trivial per user settings (best example: window positions and layout). To avoid cluttering the config files (which some users will want to edit themselves, so few and clearly arranged entries are a must), I like to put those in the registry (with conservative defaults being set in the app if no settings in the registry can be found).
I mainly do it like istmatt sais: I store config files inside the %APPDATA% folder. Usually in %APPDATA%\ApplicationName, I don't like the .NET default of APPDATA%\CompanyName\ApplicationName\Version, that level of detail and complexity is counterproductive for most small to medium sized applications.
I disagree with the example of Marcelo MD of not storing recently used files in the registry. IMO this is exactly the volatile sort of user specific information that can be stored there.
(His example of what not to do is very good, though!)
To me it seems easier to think of what you should NOT put there.
e.g: dynamic data, such as an editor's "last file opened" and per project options. It is really annoying when your app loses sync with the registry (file deletion, system crash, etc) and retrieves information that is not valid anymore, possibly deadlocking the user.
At an earlier job I saw a guy that stored a data transfer completness percentage there, Writing the new values at every 10k or so and having the GUI retrieve this value every second so it could show on the titlebar.
Simple question, but I can't seem to find the answer anywhere. Is there a way in Windows, or via a third-party utility, to enforce file naming conventions within a Windows network share?
I'm sure this is easy in Sharepoint, but I want to be able to limit users to the file name format they save into a folder. I could create a post-save program to go and look for exceptions after the fact, but I want to try and force the user to name the files according to our standards when they save.
If something is not available/configurable on the server-side, could this be accomplished via VBA in Excel or Word in the save-file dialogue?
Thanks for your help.
A
There is nothing, to my knowledge, that can restrict file names.
Nothing unless you write it yourself.
How about monitoring the folder for changes and as soon as a file with the "wrong" file name is created you alert the user in some way?
Idealy you'd want a "hook" of some sort on the file system level that will also let you fail the file operation if the filename is wrong; but I don't think there's anything at user (not kernel) level that does this.
You will have to write a program to act as a gateway to the share to enforce this. You'll also have to restrict access to the share so users cannot circumvent the program.