I am trying to secure an application to only run from a specific USB disk.
I have code to get the serial number from the device, but the only way I can make this work the way I want to is to manually code the serial number into the binary.
Is there a way I could make a stub application that would modify the existing binary to insert the serial number into it after it's compiled?
I've seen this done in C++ in the past, but that was a long time ago and I cant quite remember how we did it back then.
Storing it in the assembly is a bad idea. Here is what I would do (and have done similar in the past):
Be sure you are signing your assemblies.
Create an XML document that contains your licensing data - in your case the serial number of the USB device.
Utilize the SignedXml library in .NET (implements XMLDSIG) to sign the licensing XML document that contains the serial number. You will use the same private key that is used to sign the assembly.
When your app starts up, it verifies that the signature of the XML file is valid using the public key that it was signed with (and is embedded in the assembly).
Obviously you don't ship your private key, so if the app needs to generate the XML config file itself (rather than it be a file you ship to the user) you will need to implement a web service.
I don't know, but that hasn't stopped me from answering before.
Maybe figure out where you want to store the SN in the executable (it should be only one place, right?) and just treat the executable as a giant binary blob, and use the stub program to insert it where it needs to go?
Perhaps you want to get a separate USB license key like these ones:
http://www.bhphotovideo.com/c/buy/USB-License-Keys/ci/12454/N/4294550039
???
Why would anybody want to save anything inside an executable. If you're planning to sign the executable for distribution changing the executable in some way would break the signing and saving something in binary to the executable won't prevent someone from taking the value out the executable.
Best thing you can do is store the serial number to a file, registry, or other place then encrypt the value so it can't be modified without breaking it. I use a library that ships with License Vault from a fairly new company called SpearmanTech. You can use their library to store encrypted values to the .NET machine.config file in an encrypted form so it can't be tampered with. This way you can pull the information from the .config file when your application starts.
Are you writing a .NET application in C++ or native C++ well either way you should be able to communicate with the .NET framework so this solution would work.
I would check out their product at http://www.spearmantech.com. Hope it works for you.
Related
In the sake of this game I'm modding at the moment, which has archives ending in ".rpf" (which is short for 'rage engine package file')
How exactly is it that programmers, can find ways to open these types of files/archives, without having access to the rage engine?
What would one need to know in order to even begin trying to open a foreign file extension? The files can be opened thanks to the OpenIV Team who created the program necessary for opening the files, but how exactly does a developer, figure out or even know where to start when it comes to developing an application that is to fulfill the task of opening another file?
It's called Reverse engineering
You look into file with hex editor, notice some texts, or numbers that look like offsets. You apply your own experience writing similar stuff, make some assumptions and check if it is correct for multiple entries, and so on and so forth.
There many ways to open such files.
First you can use specific programs to open them like OpenIV for RPF archive.
If you would try to Mod or write a cheat for example, most people disassemble the program or open them with a Hex-Editor.
Programs like HexEdit change the binary values of a program into hexadecimal numbers, for example the byte 10100101 into Hex 0xA5h (A5).
Another way is to disassemble the program. Programs like ollyDbg, IDA Pro or other disassemble the binary values into assembly-code. Now you're able to search for some offsets, adresses and texts and you can remove or edit them to let the program do what you want.
Some programs are able to generate a pseudocode to C or C# e.g. (.NET Reflector) which helps you to understand what the program do.
After you read for example some memory adresses and their offsets, you can change them in the disassemble program itself (JNZ (Jump if not Zero) to JMP (Jump) for example to jump directly in every case) and write these code on the executable or you can implement them in a own program which changes them or patch them.
That is the princip you looking up for to understand how the program does work and then you add some features of your own or write a complete new application to fulfill the task of opening any file. Like Vlad said thats simply called reverse engineering.
we have created an application like adobe reader to read a special encrypted document file format which does recognize only by our application.
what we want to do is to let user buy the application using his/her account from a website & after that we'll let him/her download that document using this program and start reading it.
here is our concerns:
1) document files should not be read in another user computer which means if user1 gives the raw downloaded file to user2 which has our application in his/her own computer the second user must not be able to read that file
2) after users download their files, they can just read those file offline (not constantly be online to be able to read)
3) this security must not break down easily because these document data are vital & the user information & application must not be hacked and cracked !
4) maybe later we want to have our android/IOS version so the solution must be cross platform
5) solution like providing login mechanism for each document won't work because users are able to give the copy of their own files together with their username & password to other users.
6) file encrypting mechanism must not break down by crackers so that they just decrypt the document & post the free version all around the internet
Do you have any programming method, security mechanism or suggestion ?
You could use public-key (or asymmetric) cryptography. You encrypt the document with the public key of the user. Then only people with access to the private key (ideally: only the user) can decrypt it.
However if the user has access to his own key (and he should), nothing can keep the user from decrypting the document and sharing it with others (or sharing his private key with others).
In the end: if a user, or the program needs access to the unencrypted product and the user has no interest in keeping the document secure, confidentiality can and - if the product is interesting enough - will be broken.
This is the problem with .NET it's easily reversed, because of the executables having a lot of meta data stored and that it does not compile to native (asm), but to IL. Your best bet would be to use an obfuscator and something like .NET Seal (However if I am correct it requires the users to be on the net) http://forum.elitevs.net/
Again you want to go cross platform and for C# to do that you'll have to use something like Mono:
http://www.mono-project.com/Main_Page
Although that would require the end user to also have mono.
Now to answer your "points".
1) Make each file and application share some sort of encryption that is unique to each file and application, making sure that the file only matches for the application one user have ex.
User X downloads the application.
User Y downloads the application.
Both downloads are unique with some sort of encryption algorithm or encryption key.
User X downloads Document A.
Document A will be sharing the same algorithm / key as User X's application which makes it unique to him only.
User X gives Document A to User Y.
As User Y's application does not share the same algorithm / key as User X then the Document is not readable.
2) I will referre to what I said first in my answer.
3) I will referre to what I said first in my answer.
4) I will referre to what I said first in my answer. However I want to point out that it's not entirely a bad idea, but it's something that should be taken into consideration if C# really is the language of choice for this.
5) I will reffere to answer #1 here.
6) I will reffere to answer #1 here.
If you are going to allow the user to download the file, then there is going to be no way to 100% secure it. The reason is, there must be a way to decrypt it so that the user can read it. This decryption process must occur on the user's machine, since the program to read it will have to decrypt it and open it on their machine.
Once the program to decrypt it is running on the user's machine, he can reverse engineer it and hack it (assuming he's clever enough).
That being said, there are many way to make it difficult to crack your decryption. Now if you take away the ability to read offline, you have more control. A hacker cannot run a disassembler or decompiler on your remote server.
Hope this info helps
I want to write a program that will encrypt an entire folder and it's sub-folders, I have no problem doing this but I would like to make the entire encryption process rather transparent by letting a user double click it and have it open as if it weren't encrypted, say if it were a picture or a word document and it'd open in it's respective application.
How can a running program of mine become notified about the opening of a target file, stop the file from opening, do what it needs to do (decrypt), followed by running the resulting decrypted file.
How can I watch a file and do this in C#? Can I watch for other interactions like the user copying a watched file (since it won't be in a watched folder, it should be decrypted i.e. it's dragged to a USB device), or for deleting a watched file (say if I want to shred a file before deletion)?
P.S. The FileSystemWatcher doesn't quite meet my needs. EDIT: What I mean is that FileSystemWatcher will tell me when a file is being opened, deleted and all those events, but it won't let me step in real quick, decrypt the file, and hand it back to the process that normally opens that file.
You can rename files, add them your own extension, like thepicture.jpg.encrypted. Set your program as a default program for this extension and handle opening them
It's impossible in C#. the bare minimum would need you to use user-mode hooks on NtCreateFile, NtOpenFile, etc. You can't achieve that in C#. That wouldn't even work properly due to kernel-mode code which may try to access your files. The proper way of doing this would be to write a I/O minifilter (in C of course).
EDIT: If you're really desperate, try EasyHook - it allows you to hook functions from C#. I haven't tried it though, and it does seem risky hooking vital functions like NtCreateFile. Plus you need a fair bit of Native API knowledge.
Are you using Windows? If so, why not use the built-in BitLocker?
See this link:
BitLocker drive encryption
If you are thinking about a competitive application to BitLocker, add a comment, as I can point you in that direction as well.
Instead of trying to reinvent the wheel, use NTFS file encryption. You can encrypt single files or entire folders or drives. Plus it's completely transparent to the user and does exactly what you asks (e.g. automatically decrypt when copying to a UBS drive, etc). Just use System.IO.File.Encrypt(string) - there couldn't be anything easier.
You can't do this from usermode.
Unfortunately the only way to do this is to write a minifilter driver. Minifilter drivers allow you to intercept IO requests to files, you can then encrypt/decrypt the files you care about on the fly.
It sounds simple, but encryption minifilter drivers are very, very, difficult to get right. You will have to end up shadowing file objects which is a real challenge. Check with www.osr.com, they have a ton of information on doing exactly what you want to do.
If you choose to go this route I would recommend getting a copy of VMWare Workstation and download VirtualKD. It will let you debug at near fire-wire speeds into a VM. I would start with x64 Win7 and get remote shares working first.
I'm writing an application using windows form and c# 3.0. I was wondering if there is a recommended way of persist data across time. However, i do not want to touch the machine it is running on, as a result, i would like to store the data in the binary executable (preferably, due to the need not clutter up the user's folder with random config files).
So if anyone have any ideas of how to do this, it would be much appreciated!
Jason
If you're looking to store configuration information - app.config or a settings file is probably the way to go.
If you are storing user data - you should really allow the user to control where it is saved - and prefer the \User\Username folder on the machine.
As for what format to store it in ... you can certainly use something like SQLLite - but there's nothing wrong with XML either, if you're not storing true binary data. .NET offers a number of APIs to transform object graphs into XML representations - which you may want to look into.
If you don't want to store anything on the local user's machine, you probably want a network database - or a webservice - to which you upload the users data. Just make sure your users understand this - many don't like their private data being sent somewhere on the web without their consent.
You really don't want to go about modifying the executable file. Many virus scanners quarantine executables that are constantly changing in content or size - as a way to proactively prevent viruses and malware from infecting the machine. You don't want to go there.
Do not modify the executable. Adding a single SQLite database is a much better solution.
Isolated storage is another alternative.
Doesn't clutter install directory
Doesn't cause issues with AnitVirus software
Part of the OS including .Net objects, don't need to install anything else
Already works with the Windows security model
Exists on a per user basis, so saved settings are separated for each user
Can serialize/deserialize obects directly into it
SQLite is what your looking for and is compatible with c#
If you dont want to store data in a SQLite db on the end users PC you could call out to a web service on another server which stores it's data in SQL Server or something else.
I don't believe a windows form project can modify itself like that (I've tried to find a way to do this myself some time ago). Some form of hosted application such as a silverlight application (where the application is essentially a zip file) may be the way to go. Silverlight applications would require the silverlight plugin though (and I'm still not sure if a silverlight application is allowed to modify itself).
I would think that one config file of some sort would be prefereable, and not leave much clutter.
One way to ensure that your applicaiton is entirely self contained would be to use a program like ThinStall after you have compiled the project. This virtualises the application and could give it it's own file system or registry internally to the .exe file.
One way for an executable to change itself would be to put another executable inside it, (embed as a resource then extract it to a file when needed). This executable could then modify the first, however I don't think ther'es any framework for it to do that, so it would require knowing excatly what to change and where.
What's the smartest way to prevent a textfile (e.g. xml) from being edited by a user?
I need to make sure that the file in which I store the usernames and there privileges for the desktop application can't be simply edited.
Maybe I can generate a certificate of the file and the desktop applications checks this?
I'm using C# in a WinForms app.
You could use File system permissions to prevent editing.
You could use encryption to make editing difficult
You could get a hash value for the file to detect editing.
I think encrypting the file, then decrypting it will be easiest. Though users might still be able to read the contents of the file if they're smart enough. e.g. reading the plain-text from memory
The simplest way is probably to use a database with username and password authentication.
The smartest is to encrypt it so that the data is not available to them.
However, if a user truly wants access to a file on their machine, they will get it. You can make it so that they cannot read anything useful or make useful edits, but if they want to, they will be able to edit the file.
Since your aim is to store users' privileges directly in an XML file, you need a level of security beyond just preventing users from editing the file. Even if you could (hypothetically) impose some restriction at the operating system level against editing the file, any administrative user could just edit the file on a different computer and then overwrite your protected version.
Thus, you have to assume that users can edit the file. The only recourse you have is to be able to identify when they have, and ignore their edits.
The approach you suggest of creating a certificate sounds exactly right. You could either compute a hash for the entire file, or could do so on a user-by-user basis (whichever makes most sense in your context), in either case using a private or secret key to ensure that someone editing the file cannot simply recompute the hash.
IMHO you can not guarantee no one can edit it, but you can encrypt the file to secure the information.
you can not guarantee as any one can boot the machine using disk start up for example and edit the text file simply.
Personally I don't think XML is the appropriate format for storing secure information in this case. The whole point of XML, compared to binary formats, is that it is human readable/editable. Use some kind of encrypted binary format with a known hash/crc that tells you if it's been interfered with if you want total security.
You can use cryptography, but use the DPAPI built into Windows as you will also have to store the encryption key safely, which again is another hassle.
The benefit of using DPAPI is that it uses a key unique to the user or computer, and is never disclosed, even to the programmer! But if you move the file onto another user's profile or computer, it will be unreadable.
If you MUST keep that data in a XML textfile you could consider digitally signing it by your application every time it is modified and checking the digital signature when you read the file.
More details on how to sign XML file and how to verify signature.
But I think it's better to just keep that kind of data in different formats - database, encrypted file, application properties...