I have a process that will have some important values in the memory. I don't want anyone to be able to read the memory of my process and obtain those values. So I tried to create a program that would look at the list of programs running and determine if any of them were "debuggers", etc. But I realized that someone could just write a quick program to dump the memory of my process. I know several process on my system have their memory protected. How could I also obtain this? (ps: I'm using C#)
Any application that runs under an user with enough privileged (eg. local administrator) can call ReadProcessMemory and read your process at will, any time, without being attached to your process debugging port, and without your processing being able to prevent, or even detect this. And I'm not even going into what is possible for a system kernel driver to do...
Ultimately, all solutions available to do this are either snake oil, or just a way to obfuscate the problem by raising the bar to make it harder. Some do make it really hard, but none make it bullet-proof. But ultimately, one cannot hide anything from a user that has physical access to the machine and has sufficiently elevated privileges.
If you don't want users to read something, simply don't have on the user machine. Use a service model where your IP is on a server and users access it via internet (ie. web services).
First of all, there will always be a way to dump the memory image of your program. Your program can only make it harder, never impossible. That said, there may be ways to 'hide' the values. It is generally considered hard to do and not worth the trouble, but there are programs which encrypt those values in memory. However, to be able to use them, they need to decrypt them temporarily and re-encrypt (or discard) them afterwards.
While encryption is easy with the .Net framework, discarding the decrypted value is not an easy thing to do in C#. In C, you would allocate a chunk of memory to store the decrypted values and clear that (by writing zero's or random data to it) before freeing it. In C#, there is no guarantee that your data won't be stored somewhere (caching, garbage collection) and you won't be able to clear it. However, as eulerfx noted in a comment, in .Net 4.0 SecureString may be used. How safe that is, I don't know.
As you may see, there will always be a short time where the value lies in memory unencrypted, and that is the vulnerability here.
I think the best way to do it is employ a commercial solution such as in this PDF brochure, this is their website. You may be better off going down this route if you really care about protecting the application from sniffing, IP theft etc instead of rolling up your own solution...
Edit: I would not go down the route in kidding myself that the solution I shall craft up will be tamper proof, crack proof, idiot proof. Leave that to a company like Arxan I mentioned (I aint a sales rep - I'm just giving an example), sure it might be costly, but you can sleep better at night knowing it is much harder for a cracker to break than having no solution at all...
Related
I am writing a service that saves files and may potentially fill up one storage and may have a secondary storage to fall back to. I'd like to monitor the amount of free space on the primary storage and quit even trying to write to it if it's running low on free space. To do this, I was thinking of calling GetDiskFreeSpaceEx somewhat frequently - maybe once every few seconds. Is GetDiskFreeSpaceEx expensive - is there a reason not to do this? OR, is there a better pattern to accomplish what I'm trying to do?
[EDIT]
The kind of answer I was hoping for might come from either
A)someone who has an idea of what GetDiskFreeSpaceEx actually does behind the scenes who might say either "don't do that, the system does all the expensive operations when you ask for the free disk space" or "that's fine to do; the system keeps a count of that in memory and just has to retrieve it for you" or
B)someone who has written an application with a similar requirement, and already been down this road and down the research
I am going to create an application which will run in the client's computer. The program will allow the client to use the software N times, and then for the client to be able to use the software again he/she will need to buy an X amount of times to use the software. It would be like buying a license or token (i don't know if they're the same or not, since my english isn't that good).
I was thinking about creating a .lic or .txt or anything else, which would be encrypted, and when updated with the new .lic or .txt, etc, it would change the number fo times the client would be able to use the software.
The thing is that I don't think that method is very reliable, since, even if encrypted, the client somehow could be able to crack and understand this file.
Could anybody help me in figurnig out a solution for this?
PS: The software can't be validated via internet, the client must be able to use the software offline, if it wasn't I'd validate the software's usage via internet and wouldn't be having this problem.
First I must agree with the commentary that simply says, this will not be secure. Even though they are correct, it will be easy for a developer to work around, there still may be a valid need/desire to prevent the other 99% of the population. This is the same battle that DRM faces, there are always those 1%'ers that are willing to put in the time to decipher what you're doing and work around it. But let's move on to how you would achieve this...
Step 1 - You need a 'counter' to know how many times your application has been run. This, unfortunately, will only be obfuscated from the user since your application must be able to read this value. Often this obfuscation is achieved by hiding values in several places both in the registry and file system. Occasionally you will find this information is 'encrypted' (actually it's obfuscated by an encryption algorithm) using information available on host, the bios, cpu type, hdd id, etc.
Ultimately this storage and obfuscation of the execution counter is your 'secret sauce', and the only thing that makes it difficult to reverse is by keeping what you are doing a closely guarded secret (as most forms of obfuscation rely on secrecy). Due to this there is not really a value I could provide in offering you a solution, once posted here it's no longer a secret :)
Step 2 - Once you've got this counter working you will need to provide a 'license' to the user. This is actually the easy part and where PKI cryptography can serve you well. What you want is a private key only you control, while your client software has the public key hard-coded somewhere. Then you use you're private key to 'digitally sign' a license file for a client. When your client loads the license file it verifies the signature to ensure that this license file was signed by the related private key, which in theory since only you have access to this key, means that you authorized this license.
Step 3 - Now you need to provide a way to verify that this counter has not exceeded the licensed number of uses. This should be straight forward.
Problems and Solutions
The most obvious attack on such a solution will be reverse engineering the code. You will need to address this with a .NET obfuscation library or by writing unmanaged code.
The next most likely attack is using a debugger to skip past this verification. There are lots of anti-debugging articles out there. The most complete I've found is titled "An Anti-Reverse Engineering Guide".
Another attack that should be considered is modification of you're executable. Sign you're executable and verify it's signature just as you will for the license to prevent the code from being directly edited.
Your storage of the execution counter will be an obvious target, make sure you store it in multiple places and if any of them have been tampered with you can take an appropriate action.
Lastly, All of this will be insufficient to prevent a determined individual from successfully defeating you're licensing strategy. Accept that now and implement only as much as you feel is required based on both the level of computer competency of your average user and the amount of lost revenue versus the cost of implementation. In other words say you implement something really silly and basic and expect that 20% of your users could figure it out. Based on your clients you believe that of that 20% of your users less than a quarter of those would actually circumvent you're DRM rather than paying for the license. So you expect to loose out on 5% of your possible revenue, say you make 1 million a year, that mean you loose 50k in revenue. Now ask yourself if I spend X dollars of my time making this harder for someone to circumvent, at what point does it become a negative return? Certainly at an expected loss of 50k you wouldn't want to spend a year working on DRM.
Honestly speaking I think most applications that employ a DRM could do with a great deal less effort. If you're application is priced right people will pay for it. For the people that will circumvent your DRM, they probably wouldn't buy your application anyway so you haven't really lost anything. If I where you I'd set aside a fixed amount of time to spend on this problem, (a week?) and do only what you can within that time limit.
I'm working on a copy protection software and I'm trying to create a wrapper around any kind of executables (managed and unmanaged). This wrapper will then try to execute the wrapped executable without writing it to the disc like normal, and execute it with Process.Start().
I used .Net 4.0 Assembly and Appdomain to get it working, but as I've read and tested, it will only work with .Net executables. How would I go around and execute any kind of executable without writing it "naked" to the drive?
Can I execute it from within an encrypted compressed file for example?
or MemoryMappedFile?
Really you are wasting your time. You CANNOT stop someone from copying your executable, getting your code, or anything else. Even if you can perfectly protect the executable file on disk, the moment it starts running, someone can use a debugger to make a dump of the executable, even from a memory mapped file. This is how products like Xenocode, or .NET Reactor, or any other packer for that matter, are defeated.
The better option for you is to stop and think about what it is that you are really trying to achieve. Are you concerned about people violating a license agreement? Are you worried about your software appearing on The Pirate Bay? If you make useful software, both of these things are eventualities, not possibilities. Protect your software with copyright, and your algorithms with patents, if appropriate. Then you have legal recourse to go after violators.
Sorry to burst your bubble, but there is no technical solution that cannot be defeated. Dongles can be emulated, web services can be patched around, encryption keys can be sniffed, etc. Spend your time making your software great, not trying to protect what cannot be protected.
See this SuperUser question. To summarize, VM software lets you save state of arbitrary applications (by saving the whole VM image).
Would it be possible to write some software for Windows that allows you to save and reload arbitrary application state? If so (and presumably so), what would it entail?
I would be looking to implement this, if possible, in a high-level language like C#. I presume if I used something else, I would need to dump memory registers (or maybe dump the entire application memory block) to a file somewhere and load it back somewhere to refresh state.
So how do I build this thing?
Well, it's unlikely that this is going to happen, especially not in C# - addressing the low level requirements in managed code would hardly be possible. Saving the state of a whole virtual machine is actually easier than just saving single processes, all you have to do is dump the whole machine memory and ensure a consistent disk image, which, given the capabilities of Virtualization software, is rather straightforward.
Restoring a single process would imply loading all shared objects that the process refers to, including whatever objects the process refers to in kernel space, i.e. file/memory/mutex/whatever handles, and without the whole machine / operating system being virtual, this would mean poking deep down in the internals of Windows...
All I'm saying is: while it is possible, the effort would be tremendous and probably not worth it.
I have a C# .NET app. This application is tightly coupled to a piece of hardware. Think ATM, drive up kiosk kinda thing. I want a way for my application to assure it is being run on our hardware. Our initial plan was to get the serial number of the CPU, OS, HD, or other hardware with WMI, digitally sign that, and ship that signature with the software. The application would then have the public key in it to verify the signature. Is there a better way to do this?
Update 1
We dont want a dongle or a hasp. Nothing external to the system.
Yes, you would have a semi-safe system. It can prevent running on different hardware. It will also prevent some forms of maintenance of that hardware.
It will, as usual, not prevent anyone from decompiling and changing your software.
We do something similar for software licensing by signing an XML file, although ours isn't tied to any hardware. The same concept applies. It works well.
You will also need to protect your .NET code using some kind of obfuscation tool, we use {smartassembly} but there are several others out there.
Keep in mind that no matter what you do, given enough time and resources, someone can bypass it.
That doesn't mean you should not protect your intellectual property, but there is a point where you get diminishing returns and cause more trouble to you and your customers that it's worth.