Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I've been looking for a simple key/license system for our users. Its partly to stop piracy (avoid users from sharing the application around) and the other half to track the number of 'licensed users' we have. I have already read a few good suggestions on SO but I'm curious as to how people have implemented the 30 day evaluation criteria.
Do you generate a key that stores the date somewhere and do a comparison each time or is it a little more complicated - deleting the file/removing the registry shouldn't deactivate.
Are there any example implementations out there that can give me a head start? The irony is that our PM doesn't want to license a third-party system to do it for us.
This is for a Windows Forms application.
Have you checked out the Rhino-Licensing project by Ayende Rahien. You can also see his blog post about licensing a commercial product which led him to develop this solution.
There are two separate challenges: i. How do you prevent a copied app from running. ii. How to prevent users from ripping out/bypassing your prevention scheme. The first one is usually done by taking a hard to copy signature of the user's system (e.g. Hard Drive ID + Processor ID + RAM, etc) and using it as the seed/key AND activating it on-line by calling "home".
The Second issue is harder to do in .Net since the source code can be in someway extracted and recompiled to exclude your protection system. The key here is to make it cheaper to buy the license than to remove the protection at the user's end. You may find that for most products, the suggestion to use a customized engine to encrypt your product libraries that also contain your copy-protect and decrypt it at initial run-time, might be enough.
I am not sure you can actually protect a .NET - There may be commercial solutions that do the trick. The reason is .NET code can be seen through Lutz Roeder (Thanks Jasonh for the heads up) Red Gate's Reflector (It was formerly by the named guy above). The best way to deal with it is to look for code obfuscation which makes reflecting more trickier, I can point you to one place I know of that does this for free - Phoenix - NtCore.Com.
The more esoteric solution would be to create a .NET hosting environment in C++, load the binary image (which could be encrypted) and the hosting environment than undecrypt it in memory - have heard of that theory but not sure how that would be done in practice. Please do not use your own protection scheme as there could be a weakness.
Someone once said - "Security through obscurity"....
Hope this helps,
Best regards,
Tom.
I worked on a project that handled this by putting some critical functionality (for example data storage, reporting, or payments) on an external server we ran, and requiring the user to log in to this server to get the functionality.
Customers can make backups, share, or run the application locally, but to access this critical function they have to type a password in to our application and connect to our server. Customers knew the password allowed changing their data, so they would not want to share the password with other people.
This was handy because we do not care how many copes of the application are out in the wild, we only track server connections. We included machine-identifying data like MAC address in the connection data, so we can track which machines are connecting.
I'm not just saying this because my company sells the OffByZero Cobalt software licensing solution for .NET: your PM should know that software licensing is very hard to get right, and if you roll your own, you'll be supporting it for the foreseeable future.
Take a look at the article Developing for Software Protection and Licensing; it explains how to choose a solution, why you should obfuscate your application and gives a number of tips for structuring your code to be harder to crack.
In particular it makes the point that the vast majority of companies should outsource their software licensing, as it makes no sense to spend developer time on building and maintaining a complex system that isn't your core business.
What is more important to your company: adding an important new feature to your product, or tracking down a peculiar permission behaviour on an ancient version of Windows that's clobbering your licensing system?
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I have written a c# program to monitor what my daughter is doing on her computer during her online lessons (due to COVID lockdown).
She has a habit of going onto Discord to chat with her friends instead of following the lesson. She also plays Minecraft during lesson time.
I don’t have the time to keep checking up on her so my wife urged me to write this software.
But the software is detected by Windows Defender as a Trojan as shown below;
Detected: Trojan:Script/Wacatac.B!ml
This program is dangerous and executes commands from an attacker
I can see that it is a Trojan of sorts but it is not being used in that vein. I am simply using TCP SOCKETS to allow myself or my wife to keep an eye on our daughter and to message her and if need be to close down the offending application remotely.
The way that MS Defender keeps quarantining each new compilation as I fine tune the exe to do what I need it to do is a real bind.
I am hoping that somebody might know a way around this.
After all I am using an API (System.Net.Sockets) that is part of the Microsoft DotNet library.
It is as if Microsoft were banning the use of an API that it provides.
My daughter is back at school on the 8th March 2021 so it will be redundant after that (hopefully) but as a developer I would still like to know how to solve this.
... close down the offending application remotely.
To some extent, this indeed makes your program "execute commands from an attacker." It seems like the issue does not lie in whatever API you use - but instead, what the program actually does.
You may try obfuscating your program with something like ConfuserEx, though it is possible that Windows Defender flags the obfuscated build as well, because this is what some real malwares do to hide themselves. The easiest solution is to place the program in a separate directory and add that directory to Windows Defender's exclude list.
We run up against this kind of problem frequently, and realistically there's not a lot you can do about it. False positives are just a part of what we have to deal with, and the only way to deal with them for low-distribution items like personal remote administration tools - or my own common case, custom AV upgrade scripts - is to add exceptions for your own programs when you install them on a computer, and every time you update the code.
It is as if Microsoft were banning the use of an API that it provides.
Unfortunately malware uses those same APIs. AV vendors are constantly upgrading their definitions to catch as many threats as possible and common techniques used by malware are also present in remote administration tools.
From a quick search it looks like Wacatac.B!ml is a particularly problematic detection that has struck all sorts of legitimate applications, including an open-source launcher for Blender recently and several other items.
From experience the !ml tag means that the definition was derived via machine learning which means it most likely is a deep heuristic rather than a code fingerprint.
Possible Solutions
The most general way to get around this type of heuristic detection is with extended validation code signing. Since this requires a relatively expensive certification process it's unlikely to be a useful solution for your in-house child monitoring tools.
In your case perhaps a path or file exclusion would allow you to continue to refine your tool without having to worry about it constantly being detected and blocked. I wouldn't recommend this for production systems, but for home use only it's simple, althout occasionally unreliable.
Finally, you could radically change the code. If you can't find a way to avoid detection using your current code base then consider using a different technique altogether. Enable powershell remoting and run a collector script on another machine on the network. Build a web-based agent that polls a web service (on the local network of course) to get commands to run. Use a popular library that will handle the actual communications for you rather than accessing the sockets yourself. Not as efficient maybe, but sometimes all it takes is one change to get the false positives to leave you the hell alone.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Preface: I'm new to developing for secure commercial applications, and I understand that I may be too sensitive.
I'm working with a supervisor as a freelancer on a project that uses very truncated version of Forms Authentication and an SHA1 hash sans salt. The project uses no other security, and I've been explicitly ordered not to use any built in security that would ordinarily come with an MVC application, along with a few of the rendering/scripting libraries and the built in methods for role authentication or data annotation.
To the best of my knowledge, the application will not be interacting with legacy code, and the choice to use these methods does not lie in backwards compatibility with any already existing code bases.
The project uses a home brew method for encryption, roles, and security that uses a version of SHA1 and overrides or does not make use of many of the Forms Authentication methods.
Data stored by the application will include financial and personal records for a variety of entities and individuals ranging from small businesses to government entities.
I have mentioned several times that I am uncomfortable with the fact that the application does not use most MVC security tools, urged my boss to let me use more security, and have documented my issues with the project.
I have also spent hours reading on Asp.Net Identity and other tools in preparation for customizing them according to the project requirements while maintaining things I consider necessary, but was refused permission to do so.
Despite my worries, I want to finish the project if at all possible, preferably in a way that does not expose the users too badly or myself to legal ramifications for the kind of data that could be exposed here.
Given the following conditions, I would like to know if there are any specific ways to increase the security of this project:
Can't use OWIN/OAuth or Asp.Net Identity.
Initial authentication must be performed against the same table where sensitive user and financial information is stored in plain text. All subsequent authentication and roles management is performed against the home brew code, which stores session variables.
No salt may be used with passwords.
Password length is the only requirement for creating passwords, and the required length is very short.
Can't track or limit how many times a user can try to access or log into the system.
Can't use two-factor authentication.
Can't set the authentication ticket or security cookie to expire promptly.
Can't use data annotations for roles, authorization, and to some degree for validation on incoming data (some things have been nixed, others not).
Can't use anyone else's tools for security.
Can't create or limit roles using any of the built in classes/must use home brew method for limiting roles only.
Can't use the User.Identity object or methods.
In general, because of the nature of the data being stored, I am worried that the home brew security, coupled with the absence of current security tools, has created a situation in which it is extraordinarily difficult for sensitive information not to be exposed.
My communication with my supervisor is very poor. I'm hoping that any responses will give me more/better ways to communicate the vulnerabilities I'm seeing. No doubt I'm being annoying to my boss at this point, likely a contributing factor in our communication break down, but I'm very, very worried about all this.
And again, I am prepared to hear I'm being over-sensitive or that I am in the wrong. I am keenly aware that as a new developer, I have yet to develop a full understanding of the field. The vast majority of my experience has been academic, and I know that the classroom is not necessarily a good model for the actual practice of software development.
I'm also prepared to hear I should just finish the project and leave my boss alone.
But to the best of my knowledge, whatever that can be said to be, what I'm creating will be trivially easy to break, and I feel obliged to try and do something to make it a little harder for all the reasons above.
From what you've written here this sounds like the kind of project you would not want to be involved in. The constraints you listed sound like they are building a web app from the 90s. It sounds like they have covered all the bases as far as things you don't want to to if you plan to make you application secure go.
The only thing I can think of to say is that you should make sure they use https. Also, Captchas haven't been listed here explicitly, but they probably fall under 3rd party tools.
You should probably revise the homebrew codebase to see if you can strengthen it?
And you should probably have a long hard think about whether this job is worth the trouble or not...
I recently launched my desktop application and it got cracked after a few days. I posted a question on stack overflow and people said that i cannot stop that. In the start of the software i cannot allow this to happen and i want a solution. So, following is what i am thinking.
Currently, I have desktop application that communicates with the web server to verify the user. Once the user is verified it saves the values in Registry. The hacker has bypassed the communication code and added fake values in registry and he can use my software now.
Now, i am planning to take some of my code from MAIN features of the software to a WEB SERVICE hosted somewhere else on a web server. Whenever the software needs to run that feature the software will give a call to the WEB SERVICE with the values in REGISTRY. I will verify those values and return the results. But if the values will not match my database then i will reject the call.
So, my questions is:
1- Do you think this solution is feasible ?
2- According to my thinking, it will make the software useless to the hacker. What do you think ?
3- Any flaws in this solution ?
You don't have to get cracked. Jeez, everybody thinks there's no solutions available to prevent piracy, but there are. Disclaimer: I work for a company (Wibu Systems) that prevents software piracy and provides license management solutions.
Here's the thing: this (like all security issues) is a highly specialized area of focus and the crackers are smarter at this than you are. They are already familiar with the different home-grown solutions people roll themselves and can crack those quickly.
Commercial solutions (ours is CodeMeter; in all fairness other companies make good solutions too like SafeNet and KeyLoc) rely on strong encryption with multiple layers of protection against key discovery. These companies have spent years developing, improving, and testing their solutions; it's unlikely you will be able to come close to the robustness and quality of such a solution on your own. I can almost guarantee you that any solution you create on your own will get cracked very quickly, unless your product is uninteresting to the crackers.
I'm not trying to create an ad here; I just want to set the record straight. Companies that traditionally got cracked constantly who switched to CodeMeter stopped getting cracked. Check out Propellerhead's Record product for a good example.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We are planning to develop a client server application using C# and MySQL. We plan to sell the product on the shelf like any other software utility. We are worried about the decompilation of our product which does have some sort of edge over our competitors in terms of usability and bundled functionality.
How can we prevent our software from decompilation, so the business logic of the product remains intact?
We have heard about Reflector and other decompilers which makes our code very much vulnerable for copying.
Our customer base is not Corporates but medical practitioners who themselves may not do it but our competitors may want to copy/disable licensing or even replicate the code/functionality so the value of our product goes down in the market.
Any suggestion to prevent this is most welcome.
If you deploy .NET assemblies to your client machines, some kind of decompilation will always be possible using reflector and similar tools.
However, this situation isn't materially different to what you'd encounter if you wrote the application in native C++. It is always possible to decompile things - if it were impossible, the processor couldn't understand it either.
You're never going to defeat the expert cracker - they'll treat your security as an intellectual puzzle to be solved for the challenge alone.
The question revolves around how hard it is to defeat your licensing practices and the return on investment.
Sit down with a spreadsheet and look through the possible scenarios - the danger is probably less than you think.
Factors like "ease of use" are visible in your software for any user to observe - so you'd think it easy to copy. But, good User experience is rare (and seldom copied well), because most developers (myself included) are nothing like typical users.
I'd suggest you concentrate on making the job of a cracker harder, cause you can never make it impossible, just non-profitable.
One possibility to try: It's possible to pre-compile assemblies into native code as a part of the installation process. Paint.NET does this for performance reasons. I believe that once you've done this, you can discard the original assemblies and use the optimised, native code editions.
If it were me, I wouldn't be attempt to obfuscate; I would:
Not worry about it and aim to continually improve and stay in front
But secondly
Consider providing the 'secret' services over the Web. It's up to you to decide how critical and possible this is; but it does "prevent" decompilation, because the end user doesn't even have the code.
Google for .NET Obfuscator. You will find a lot of products that will help in this. Also there are related questions already asked in Stack Overflow.
Here are some:
Dotfuscator
Secure Team
EDIT: While searching for De-Obfuscating tools, I came across an open source tool De4Dot. This tool supports decompiling obfucated dlls created by most commercial tools and does a pretty good job too.
Intellilock has served our purpose well in terms of obfuscation as well as licensing. But I would not recommend the product as the support is not upto the mark. We never got replies in time for the problem we were facing. We had to search and research on our own or even change the business requirement to achieve some goals.
Via this answer I am not intending to promote or demote any software but just want make people aware about the product we are using so they can make wise decision.
The last time I looked into this, Spices.Net Obfuscator looked like the best thing on the market.
No, I don't work for them. :)
I use smartassembly. It is simple to use and also has the ability to send crash reports back too you built in.
The obfuscators others have mentioned are likely very good.
An alternative approach you might not have considered is to code some of the core business logic using a language that is fully compiled to machine code, such as C++.
The benefit of doing this is that it makes it far more difficult for someone to decompile your code. A drawback to this is that you have code in two languages to maintain. This might not be the best approach for your situation, but is useful in cases where only a small part of the code needs to be obfuscated while the remainder of the code is UI fluff.
As an example, your medical software package might be performing edge detection of say, certain glands for the purpose of telling a doctor the size of said gland. The algorithm for calculating the size of the gland from a bitmap image would be contained in a DLL written in C++.
to answer your question about the C++ wrapper around the .net code; I dont think it would work, because when you deploy the application the final c++ dll and .net dll containing the business logic code will be separate entities and the ones who want to get to your business logic would still be able to just pick out the .net dll and peek inside.
you might want to consider Remotesoft Salamander Protector
this is much better than anything else in that it makes it impossible to decompile to the high level language.
Of course, anybody who is an expert can spend enough time with your software and figure it out because it does decompile some,but it hides all the set and get methods
So, they can get a peak,but that is about it. they have to figure out the rest which lowers the probability of anybody just cracking it.
hope this helps
Writing on this thread after a long time. We have purchased a software called Intellilock which is helpful in preventing decompilation, obfuscation and also has a strong licencing module.
We did not go for .Net Reactor even though it has more prevention controls as Intellilock was serving our purpose well enough.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What's the best approach to Licensing Custom .NET Components or applications for selling ?
Closed Source
2 licensing mode :
Trial limited features license (free)
Full featured
As for a "Closed Source" scenario consider using obfuscation. I've been using SmartAssembly and very satisfied with results.
As for licensing modes. You are speaking about .net components so the target audience are developers. I don't think they will deal with free limited trials. If you are going to sell something valuable to developer community get ready to see a "Full Featured" version on Rapidshare or torrents.
I would recommend concentrating on support and frequent updates/enhancements rather than protection. In most cases "business" buys support rather than binaries.
If you need some tool titles why don't you just google for that? ".net licensing" query will give you tones of links.
Hope that helps.
There is a lot of missing detail here.
Are you licensing from someone or trying to create a license?
Open source, closed source, selling? If selling, do you provide source?
What is the final usage of the component / application? Are you hosting it (like a multi-tenant site) or is it more COTS?
What are your competitors doing with their sales model? Does it appear to be working for them? e.g. does it sound reasonable? <- emulate that.
As you answer those questions, you'll find the license that fits your needs.
GPL. Or declaring it public domain. Or a 24-page EULA that restricts the ability of users to shave while using the component. Or something like that.
Why don't you tell us what you are trying to do, what the intended uses are, and what you'd like to have happen?
When you're giving out trials of your software that are upgradeable to full versions (in other words assemblies that contain all features), there's not a whole lot you can do to prevent someone from hacking it in the end. (with .net it's even easier then with native assemblies).
Signing & Obfuscation is the only way to prevent it from being reverse engineered in a very readable form but just using something like reflector will basically give you the complete.
One of the simplest ways to keep up the appearance of licensing is to:
use public/private key encryption to save licensing information (expiration date, enabled features, etc) into a file
include the public key in the assembly
decode the encrypted information on the start of your application to check if someone is licensed to use your application.
generate licenses when necessary with your private key and distribute those files (or keys if the data is small enough)
As an alternative you can include the licensing information in clear text with a hash code (this is the licensing key, algorithm should also support public/private key) in clear text with the application, and only check if the licensing information matches the hash code.