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.
Related
Is there a way/system to debug/monitor code without stopping execution?
In industrial automation control programming (PLC/PAC/DCS) it is possible to connect the debugger while the program is running, and see in the code editor the value of variables and expressions, without setting breakpoints or tracepoints.
As an example, let's have a F# multithreaded application, where code is executed in a continuous loop or triggered by timers. Is there a way to attach a debugger like Visual studio Debugger and see the values of variables and expressions (in the code editor or in a watch pane) WITHOUT interrupting the execution?
It doesn't matter if it's not synchronous, it's acceptable if the debugger/monitor does not capture all the code scans.
I am tasked to create an high level controller for a process plant and I would like to use C# or F# or even C++ with a managed or native application, instead of a PAC system. But being forced to interrupt execution to debug is a huge disadvantage in this kind of application.
UPDATE
First of all thanks to all for their answer.
Based on those answers, though, I realized that probably I need to reformulate my question as follows:
Is anyone aware of any library/framework/package/extension that allows to work with a native or managed application in windows or linux (C#, F# or C++) the exact same way as a PAC development platform, specifically:
1) Put the dev platform in "status" mode, where it shows automatically the runtime value for variables and expressions present in the code exceprt currently visible, without interrupting execution?
2) Create watch windows that show the runtime value of variables and expressions, again without interrupting execution?
Also, what I am looking for is something that (like any PAC platform) offers these features OUT OF THE BOX, without requiring any change in the application code (like adding log instructions).
Thank you in advance
UPDATE 2
It looks like there is something (see http://vsdevaids.webs.com/); does anyone know whether they are still available somewhere?
UPDATE 3
For those interested, I managed to download the last available release of VSDEVAIDS. I installed it and looks working, but it's pointless without a licence and couldn't find information on how to reach the author.
http://www.mediafire.com/file/vvdk2e0g6091r4h/VSDevAidsInstaller.msi
If somebody has better luck, please let me know.
this is a normal requirement - needing instrumentation / diagnostic data from a production system. Its not really a debugger. Its usually one of the first things you should establish in your system design.
Not knowing your system at all its hard to say what you need but generally they fall into 2 categories
human readable trace - something like log4net is what I would recommend
machine readable counters etc. Say 'number of widget shaving in last pass',..... This one is harder to generalize, you could layer it onto log4net too. Or invent your own pipe
With regards to your edited question, I can almost guarantee you that what you are looking for does not exist. Consequence-free debugging/monitoring of even moderate usefulness for production code with no prior effort? I'd have heard of it. Consider that both C++ and C# are extremely cross-platform. There are a few caveats:
There are almost certainly C++ compilers built for very specific hardware that do what you require. This hardware is likely to have very limited capabilities, and the compilers are likely to otherwise be inferior to their larger counterparts, such as gcc, clang, MSVC, to name a few.
Compile-time instrumentation can do what you require, although it affects speed and memory usage, and even stability, in my experience.
There ARE also frameworks that do what you require, but not without affecting your code. For example, if you are using WPF as your UI, it's possible to monitor anything directly related to the UI of your application. But...that's hardly a better solution than log4net.
Lastly, there are tools that can monitor EVERY system call your application makes for both Windows (procmon.exe/"Process Monitor" from SysInternals) and Linux (strace). There's very little you can't find out using these. That said, the ease of use is hardly what you're looking for, and strictly internal variables are still not going to be visible. Still might be something to consider if you know you'll be making system calls with the variables you're interested in and can set up adequate filtering.
Also, you should reconsider your "No impact on the code" requirement. There are .NET frameworks that can allow you to monitor an entire class merely by making a single function call during construction, or by deriving from a class in the framework. Many modern UIs are predicated on the UIs being able to be notified of any change to the data they are monitoring. Extensive effort has gone into making this as powerful and easy as possible. But it does require you to at least consider it when writing your code.
Many years ago (think 8 bit 6502/6809 days) you could buy (or usually rent, I seem to remember a figure of £40K to purchase one in the late 80s) a processor simulator, that would allow you replace the processor in your design with a pin compatible device that had a flying lead to the simulator box. this would allow things like capturing instructions/data leading up to a processor interrupt, or some other way of stopping the processor (even a 'push button to stop code' was possible). You could even step-backwards allowing you to see why an instruction or branch happened.
In these days of multi-core, nm-technology, I doubt there is such a thing.
I have been searching for this kind of features since quite a long time with no luck, unfortunately. Submitting the question to the StackOverflow community was sort of a "last resort", so now I'm ready to conclude that it doesn't exist.
VSDevAids (as #zzxyz pointed out) is not a solution, as it requires significant support from the application itself.
Pod cpu emulators (mentioned by #Neil) aka in-circuit emulators (ICE) and their evolutions are designed to thoroughly test the interaction between firmware and hardware, not so useful in high level programming (especially if managed like .NET).
Thanks for all contributions.
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.
My company needs to internally test infrastructure. Our organization is rapidly moving from a very small development environment to a larger more scalable production environment. Specifically we want to flood some of our new request routers from the inside. We need to write the tool ourselves, and it has to be automatable. We can't use third-party tools because, to be frank, they're written by less than scrupulous hats and are virtually all are chock full of malware.
To be more specific, the tool is to be written in C# and the first obstacle we have to get past is overcoming kernel imposed restrictions on half-open outbound requests (we're clearly a Windows shop...I wouldn't be posting if we were all Linux). We would be dealing with Vista.
Any tips on anything are greatly appreciated. Where to get started, open source tools (so they can be verified to not be malware), anything. Thanks in advance.
And no, I'm not a hat or a script kiddie.
EDIT: The main goal here is not the actual generation of the traffic (I can do that), but rather programmatically overcoming the OS imposed "10 half-open outbound requests" restriction. Theoretically a single system should be able to spawn 255 of these half-open requests at a time, but the OS artificially locks this down.
Upgrade to Vista SP2 (you say you're specifically dealing with Vista, although the title suggests differently) - the connection limit is removed in Vista SP2.
http://technet.microsoft.com/en-us/library/dd335036(WS.10).aspx?ppud=4
Notably, it's the last bullet point under Operating System Experience updates
And for added value...
How to turn it on again if you wanted...
http://support.microsoft.com/kb/969710
Your best bet is going to be the winpcap driver. Note that many of these "kernel-imposed restrictions" are also imposed in hardware, in which case you are S.O.L. until you buy new hardware.
Is running mono on linux a possibility? You might need to write/use some third party unmanaged code I would imagine, but you would not have that restriction to deal with.
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...