Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am looking a tool for protect and licensing my commercial software, Ideally must provide an SDK compatible with Delphi 7-2010, support AES encryption, Keys generator and capacity to create trial editions of my application.
I am currently evaluating ICE License. Someone has experience with this software?
Here's my list of software protection solutions. I'm looking at switching from ASProtect to another protection so I'm also in the process of analyzing most of these programs:
Themida (Oreans)
http://www.oreans.com/products.php
There are unpacking tutorials for all the versions of Themida. There is however the possibility of requesting "custom" builds which might help avoid this.
Code Virtualizer (Oreans)
http://www.oreans.com/products.php
Allows to protect specific parts of the application with a Virtual Machine. A cracker on a forum said he "made a CodeUnvirtualizer to fully convert Virtual Opcodes to Assembler Language".
EXECryptor
Very difficult to unpack. GUI does not work under Vista. Appears to no longer be developed.
ASProtect
Small protection overhead. Appears to no longer be developed.
TTProtect - $179 / $259
13 MB download. Chinese developer. Adds about xxx overhead to the exe.
http://www.ttprotect.com/en/index.htm
VMProtect - $159 / $319 (now $199/$399)
http://www.vmprotect.ru/
10 MB download. Russian developer. Seems to be updated frequently. Supports 32 and 64-bit. Uncrackable according with one exetools post, but there seems to be an unpacking tutorial already.
Enigma Protect - $149
http://enigmaprotector.com/en/home.html
7 MB download. Russian developer. Regarded as very difficult to crack. Adds about xxx overhead to the exe.
NoobyProtect - $289
http://www.safengine.com/
10.5 MB download. Chinese developer. Regarded as very difficult to crack. Adds about 1.5 MB overhead to the exe.
ZProtect - $179
http://www.peguard.com
RLPack
http://www.reversinglabs.com/products/RLPack.php
KeyGen already available.
One thing to note is that the more protection options you enable on the software protector, the bigger the possibility of the protected file being flagged by an anti-virus as a false-positive. For example, on Themida, checking the option to encrypt the file, will most likely create a few false-positives by a few anti-virus programs.
I'll update this answer once I get more replies from a hackers forum where I asked some questions about these tools.
And finally, don't use the build-in serial number/license management of these tools. Although they might be more secure than using your own, you will be tied up to that specific tool. If you decide to change software protection in the future, you will also have to manage all the customer keys transfer to a new system.
Don't bother. It's not worth the hassle. Only a perfect licensing system would actually do you any good, and there's no such thing. And in the age of the Internet, if your system isn't perfect, all it takes is for one person anywhere in the world to produce a crack and upload it somewhere, and anyone who wants a free copy of your program can get it. (And using a pre-existing library just gives them a head start on cracking it.)
If you want people to pay for your software instead of just downloading it, the one and only way to do so is to make your software good enough that people are willing to pay money for it. Anyone who tells you otherwise is lying.
I have used OnGuard (using the Delphi 2009/2010 source from SongBeamer) along with Lockbox to handle encryption with success. Both are commercial quality libraries and are free to use with full source.
I did once also use IceLicense, but switched to OnGuard/Lockbox which allowed me greater control over the key generation process which we embedded directly into our CRM system.
Of course there is no %100 bullet-proof protection suite, but having some type of protection is better than having nothing.
I worked with WinLicense in Delphi 2009 and Delphi 2010 on Windows XP and Vista. It is a good product with lots of protection options, and customizations. It provides a SDK for developers, and has nice documentation and samples. It also provides a license manager for you. They provide trial download too.
As far as I remember, they offer some customer specific versions too; that means they are willing to provide a custom-built product which is customized according to your needs, but of course that will cost more.
Since WinLicense is a well-known and popular protection suit, many crackers are after it. As you know, the more famous a tool is, the more appealing it is to crackers. But the good thing about Oreans is that they actively monitor underground forums, and provide frequent updates to their products.
So IMHO, if you are supposed to buy a prebuilt protection suite, then you'd better go for WinLicense.
A little late to the post, but check out Marx Software Security (http://www.cryptotech.com) they have a USB device with RSA & AES on chip, with network based license management.
I bought a license for ICE License in 2007. Unfortunatly (as far as I know) the component haven't been updated since June 2007. Back then a Vista compatible version was in the work but never came out of beta. I don't think they updated the component for Delphi 2009 and 2010 yet.
Ionworx is an one man company which might explain the lack of updates and lack of answer to support questions (emailed them 2-3 times since 2007 and never got back to me). They also removed their support forum from their site.
ICE License is better than nothing but I would stay away from this product because the lack of updates & support.
I investigated this a few years ago, and came to the following conclusions:
All copy protection can be broken
Nag screens on load irritate people to the point where they may stop using the product
Random nag screens can interrupt the users work flow to the point where they perceive it to be a reduction in the speed of the application
Set up compiler options, so that you have a version as a demo (perhaps with save functions removed), reduce multi user versions so that only one client can connect at a time (not using, for ex:
if connection=1 then reject
but reducing the viability for multiple connections in code)
Themida has good protection, and I think it built with Delphi too ;-)
if you have a better budget, you can look at winLicense and other tools from same company.
Have a look at this question which is pretty similar, and includes many of the tools.
Take a look at InstallShield. We've been using it for a while ourselves, and it has a lot of capabilities for trial support, licensing, and others. I don't know about key generation off the top of my head as our use doesn't require keys, but there's a lot available to you from them.
AppProtect wraps an EXE or APP file with computer unique password or Serial Number based online activation. QuickLicense is a more comprehensive tool that support all license types (trial, product, subscription, floating, etc.) and support both a wrapping approach or API to apply the license to any kind of software. Both are available from Excel Software at www.excelsoftware.com.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm having some trouble recently with the open source licenses. I started to feel like if they are somehow tricky! So, I'm just asking about the rights, attribution and so on..
Know, if I for example used a Ruby Gem, licensed under GPL, I install the gem, use it, my web app works! But there is no referring to the Gem, how is behind it, its license. I can't just believe that I have to include those for every gem I'm using. Do I have to? Or can I just use it silently?
So, a website with Rails (MIT), some GPL ruby gems, and so on, what should I include publicly? I think I'm not going to modify the source code of any of those gems.. Yeah, and if I have to attribute in my web pages, do I have to link to the licenses or even worse distribute my source code under the same license?
Also, if I found a tutorial or something like that that is licensed under Creative Commons BY-NC, should I distribute my whole work or put it under the same license, if I wasn't going to run them outside my own server? What if I wanted to distribute my software, which used ideas (and modified code) from the tutorial?
What about using formulas, which are more general than being owned? One-liner commands from stackoverflow when a gem doesn't install - Should I attribute that I used that to install the gem?! I think of course not, but just asking to make sure of the whole thing..
A website is normally the output of a program. Like you save a text-document with your word processor in disk, the document itself does not fall under the reciprocal license of the proprietary word processor (MS Word) or the reciprocal and permissive licenses of the free software word processor (Open or Libre Office Writer).
Only in case you create and distribute derivative or combined works (e.g. packaging multiple programs together in one package) you need to care about the licenses.
That for sure always depends on the concrete things you do. You need to document these concrete things, then go to your lawyer and then find out for the stuff you exactly do if and how copyright is in effect and based on the licenses used and if in effect, which steps you need to do.
Here on SO we are all only software developers (or if lawyers, not your lawyer) so we can not give you any legal support.
Usually stuff about licences can be a little confusing with open source software being released under different licences and usually the license documentation is usually written in lawyer jargon which proves difficult to understand for a lot of people.
Luckily this kind of question has been asked alot of times in SO. Just look at the licensing tag and order the questions by votes and you should find a few questions that pretty much answer your questions. In particular look at this question.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We currently have a large business-critical application written in COBOL, running on OpenVMS (Integrity/Itanium).
As the months pass, there is more and more speculation about the lifetime of the Itanium architecture. Nothing is said out in the open, of course, but articles like this and this paint a worrying picture. Although I can find nothing official to support this, there are even murmurings in the corridors of our company of HP ditching OpenVMS and HP COBOL along with it.
I cannot believe that we are alone in this.
The way I see it, there are a few options:
Emulate some old hardware and run the application on that using a product like CHARON-VAX or CHARON-AXP. The way I see it, the pros are that the process should be relatively painless, especially if the 64-bit (AXP) option is used. Potential cons are a degradation in performance (although this should be offset by faster and faster hardware);
Port the HP COBOL-based application to a more modern dialect of COBOL, such as Visual COBOL. The pros, then, are the fact that the porting effort is relatively low (it's still COBOL) and the fact that one can run the application on a Unix or Windows platform. The cons are that although you're porting COBOL, the fact that you're porting to a different operating system could make things tricky (esp. if there are OpenVMS-specific dependencies);
Automatically translate the COBOL into a more modern language like Java. This has the obvious benefit of immediately freeing one from all the legacy issues in one fell swoop: hardware support, operating system support, and especially finding administrators and programmers. Apart from this being a big job, an obvious downside is the fact that one will end up with non-idiomatic Java (or whatever target language is ultimately chosen); arguably, this is something that can be ameliorated over time.
A rewrite, from the ground up (naturally, using modern technologies). Anyone who has done this knows how expensive and time-consuming it is. I've only included it to make the list complete :)
Note that there is no dependency on a proprietary DBMS; the database is ISAM file-based.
So ... my question is:
What are others faced with the imminent obsolescence of Itanium doing to maintain business continuity when their platform of choice is OpenVMS and COBOL?
UPDATE:
We have had an official assurance from our local HP representative that Integrity/Itanium/OpenVMS will be supported at least up until 2022. I guess this means that this whole issue is less about the platform, and more about the language (COBOL).
The main problem with this effort will be the portions of the code that are OpenVMS specific. Most applications developed on OpenVMS typically use routines and procedures that are not easily ported to another platform. Rather that worry about specific language compatibility, I would initially focus on the runtime routines and command procedures used by the application.
An alternative approach may be to continue to use the current application while developing a new one or modifying a commercially available application to suit your needs. While the long term status of Itanium is in question, history indicates that OpenVMS will remain viable for some time to come. There are still VAX machines being used today for business critical applications. The fact that OpenVMS and its hardware is stable is the main reason for its longevity.
Dan
Looks like COBOL is the main dependency that keeps you worried. I undrestand Itanium+OpenVMS in this picture is just a platform.
You're definitely not alone running mission-critical stuff on OpenVMS. HP site has OpenVMS roadmap (both Alpha and Integrity), support currently stretches to 2015. Oracle seems trying to leverage it's SUN asset in different domains recently.
In any case, if your worries are substantial (sure we all worried about COMPAQ, then HP, vax>>alpha>>Itanium transitions in the past), there's time to un-tie the COBOL dependency.
So I would look now into charting out migration path from COBOL onto more portable language of choice (eg. C/C++ ANSII without platform extensions). Perhaps Java isn't the frendliest choice, given Oracle's activity. Re-write, how unpleasant it is, will be more progressive and likely will streamline the whole process. The sooner one starts, the sooner one completes.
Also, in addition to emulators, there're still plenty of second-hand hardware. Ironically, one company I know just now phases-in Integrity platforms to supplant misson-critical Alphas -- I guess, it's "corporate testing requirements"...
Do-nothing is an option as well, though obviously riskier: OpenVMS platforms are proven to be dependable, so alternatively, finding a reliable third-party support company may extend your future hardware contingency.
This summer's Rolling Roadmap makes porting off OpenVMS look like an excellent idea.
Given how much COBOL exists in the world finding people to support COBOL will not be a problem for the foreseeable future. As noted above there are COBOL compilers on other platforms. The problem lies in the OpenVMS system service calls and DEC language extensions your application uses. You do not mention where your data is stored, so worst case your COBOL uses RMS. There is a company that provides an implementation of many OpenVMS system services on Linux and the Unixes. Not needing to replace those services while porting to another operating system may reduce the complexity. Check out Sector7.com.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm trying to figure out the licensing consequences of using Grails as the base for closed-source non-free software. This would be a server product that is downloaded and installed. Users would not have the right to redistribute it or run it as a hosted service.
Grails and Groovy themselves are cool: they're licensed under ASF 2.0 which is great. However, Grails has a billion dependencies and I'm going crazy tracking them all down.
Grails can generate a list of software that your project depends on by running grails dependency-report. I'm going through that list of dependencies, BUT:
Many of the libraries do not list their licenses. So I'm going to each and every library and figuring out its license.
I'm guessing dependency-report doesn't list all the transitive dependencies (libraries that THOSE libraries include, and so on) because they aren't fully specified in Ivy.
Has anyone gone through this exercise before? Just knowing the end result would be a HUGE help. Actually having a list of all the dependencies and their licenses would be a MASSIVE help.
Thanks!
I spent a day tracking down all the Grails 1.3.7 dependencies. Here's the gist:
Grails itself has the nice friendly ASF license
Some subcomponents use more restrictive licenses
However, none of the subcomponents use what I'd call a "showstopper" license like GPL
However, some people WOULD consider a few of the licenses to be showstoppers, most notably the LGPL used by Hibernate.
Lawyers are scared to death of LGPL because it's easy for developers to make a mistake that forces the entire system to become open source. Things that would trigger this are: modifying any little bit of the LGPL source code, copying any little bit of the source code into your product, or linked to the GPL software "statically" rather than "dynamically" (that's a long discussion).
Because of this, some software companies and purchasing departments have rules forbidding its use.
Here's the subcomponents with more restrictive licensing than ASF. LGPL's the worst:
Hibernate (LGPL)
A bunch of javax stuff (like activation and mail) under CDDL 1.0
org.beanshell BSH is SPL
javassist is MPL
Everything else is licensed BSD, MIT or ASF. Those are fine.
I should think that all of the Grails dependencies will be fine for use with commercial software since SpringSource sells commercial support for it. You could try asking them about licensing issues as they probably have it all figured out.
Can I use Grails in proprietary software?
Ask Oracle, Grails is running on Java. It might be restricted through higher rights so you might need to get a license from Oracle first to create your specific software with it. Better ask the vendor of the platform first.
[...] Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses.
See Apache foundation resigns from Java community
Next to that it depends on the license of the Grails package. It's released under ASF 2.0 as you write. I would furthermost assume that this license applies to the whole package as the website suggest, but you must check the whole source code on your own if you really want to rely on this, because the software comes with no warranty. In case the Grails folks made a mistake in licensing it falls back to you in a larger share if the information they provided was wrong.
Keep in mind that you are asking about creating your own proprietary software. That's a job on it's own, your business, and you need to take care for anything legal then on your very own.
You can never rely to any comment unless it's one of a lawyer that is acting behalf of yourself for real.
There is one plugin that might be helpful to check upfront visible licensing terms: http://www.grails.org/License+Plugin
The ASF 2.0 license is a free software license, so even if you consider it "friendly" with all the attitude you show, keep in mind that it has termination clauses as well as the GPL / LGPL. Those are to protect the freedom of the software.
The license at the Grails web site will surely have an answer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm writing a new project, and I have a choice between using a library that only exists in OSX 10.5 and later (We're on 10.6 now), but makes my life much easier, and using a library from earlier versions, but I have to a lot more of the work myself.
How does one make this decision? How do you balance new/better technology vs customers on old systems?
ETA: does anyone know of a site that compares market share by precentage of a specific OS? Since this is a consumer product, if only 2% of mac users are still on 10.4, that sort of makes my life easy. Similarly, if 25% are still on 10.4... (I know, it's almost guaranteed to be somewhere between...)
Ask your clients - how many are on older versions of the OS?
Can you afford to lose them?
Edit: (following comment)
If you don't know what your target audience is using, you have a problem. You need to get an idea of the magnitude of how many potential customers you will not be able to serve if you go with your new library.
Having said that, shipping is a feature, so if you get the product out much quicker, you can always refactor the code to use the old libraries if you think it will gain many sales.
In general you should base your decisions like that around the interests of your paying customers. You should present the issues to them and the risks involved in each alternative and let them make the decision.
Depending upon your particular application and requirements, I would personally ship this as a major update (i.e. version 2 compared to version 1) and explicitly state that a minimum of OSX 10.5 is required.
You could still support your previous version with bug fixes, just not new features that depend on library X.
Another way to think about it is that if someone is on 10.4, then they likely haven't been an active upgrader / software purchaser for the last 3 years. So the likelihood that they will want to spend money on your software is low.
Additionally, if they really want your software, they'll upgrade to 10.5 or 10.6 and gain loads of other advantages at the same time. While that OS upgrade won't be free, it will come with so many other advantages to the customer, they might not mind.
It's also important to consider how much time and effort it will take to develop your software. If these newer libraries mean that you ship the product months earlier, or with better features, that will also pay off.
As others have said, this really boils down to whether you can afford to lose customers who aren't on 10.5 yet. That said, lots of companies seem to support the two most recent versions of OS X in their new major releases, although older versions are often available for people with older systems.
If software ownership is stable and software vendor is not pushing too hard in phasing out their own obsolete software, then there are no reasons to not support.
The problem is much worse, when vendor is passively aggressive or committed the phasing out: dead download links, dead 3rd party companies, who made the hardware/drivers/compilers/libraries, unobtainable documentation, incompatible media/installer to recover/reinstall the product.
My example: pre-2000 vs 2005, it is nearly impossible to reconstruct say.. the build process of 1 mln lines of 100% saved and mothballed Visual Studio 6.0 projects from year 1999-2001, obtain all 3rd party libraries from the era, prepare proper SDK, platform itself, all patches, make results binary identical. No way.
But it pretty much works for Studio 2005.
You need to talk to both sales and support, and let them judge what the impact will be.
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 9 years ago.
Improve this question
BE AWARE! Creating spyware, computer viruses and similar nasties can be illegal where you live and is considered extremely unethical by almost everyone. Still, I need to ask this to raise awareness about how easy it is to create one. I am asking this after the W32/Induc-A was introduced to this world by someone who came up with a nasty way to spread one. So I want to know how a virus can be created so I will be able to recognise them in the future!
Recently a new virus was discovered which spreads itself by replacing the developers' copies of library code. Actually, through the source code of Delphi 4 through 7. What happened is that there's a virus in the wild which searches the computer for a file called SYSCONST.PAS, to which it will add itself as source code. This file happens to be a source file for the runtime libraries of Delphi. (This runtime source code is available for Delphi developers.) As a result, after being infected a programmer would create lots of new versions of this virus without even knowing it. Since virus scanners sometimes generate false positives many developers might thus decide to ignore the warnings of the scanner and maybe they'll even disable their scanner while building their project. To make it worse, their project might even trigger the scanners of their customers so it's likely that those programmers won't check their source code but will just try to fool the scanner somehow. That is, if a virus scanner is even able to recognise the virus, which isn't very likely. Thus, we software developers might be creating viruses without realizing what we're doing!
So, how to create a virus? Simple: get your source code infected by a virus and you're done!
Okay, so the source code of Delphi 4 through 7 might be infected. All Delphi developers, please check your source files! The case is just a proof-of-concept and apparently it can be very successful. Besides, most virus scanners won't check source code but just focus on executables. This virus could stay undetected for quite a while.
This virus also was successful because it misused source code. Delphi is a commercial project and the source code is available. But who is sure that these hackers won't be attacking open-source projects in similar ways? There are lots of open-source projects out there and who is going to check them all making sure they're all behaving in a decent way? And if someone is checking the code, will he be able to recognise if something is malicious code?
So, to make sure we can recognize malicious source code, I have to ask: How do I create a virus? How do I recognise the code that will create a virus? What is it that most malware will want to do?
There is a bit of discussion about the Delphi runtime source code, about this code being open-source or not. Borland uses a dual-license for their source code from the moment when they started to support Linux with Kylix. As a result, the source code has a "GPL" symbol declared which indicates if the libraries are compiled as GPL code or not. As GPL, the source code would be open-source. This also happens to be the source version that was attacked by the virus. Anyway, to avoid discussions here, I've asked this question here so we can focus more on the virus problem and less on Delphi. Basically, we're talking about a virus that attacks source code. Technically, all source code could be at risk but open source code is a likely candidate since hackers know it's structure and can target those files that are rarely modified, thus rarely checked. (And if they can hack their way into a CVS system, they could even erase the traces of their modifications, thus no one might notice the modiifications!)
While this does not really answer your question, I think a really interesting paper to read is Reflections on Trusting Trust by Ken Thompson. It raises a fascinating point that even if your source code is free of defects (viruses, trojans, etc.), you might still be producing defective executables if your compiler is defective. And even if you rebuild the compiler from clean source code, you can still have the same problem.
Unless you're building your computer from the ground up with your own microchips, hand-assembling your own BIOS, writing your own operating system, compiler, and software, you have to draw the line somewhere and trust that the hardware and software upon which you're building your systems are correct.
You could check for the Evil Bit on incoming packets... http://en.wikipedia.org/wiki/Evil_bit
If you want to recognize malware, you must know how it works. This means researching malware and aquirering the skill to produce malware.
search for 29A - they wrote papers on virus
read about rootkits (there are even books on it)
read about reverse engineering
read source code of malware - there's plenty of it in the web.
learn assembler
learn about your OS
reverse the os-kernel
get clam-av, check the source
I won't provide links here. They are easily found though.
If you really want to learn, and are willing to put in the time, your time is probably better spent on google to find then participate in a greyhat community. this topic is highly complex.
if your question is as simple as "what's an easy way to recognize a virus from its source code", well, it probably won't be easy, because there's infinite ways to go about it.
You ask "What is it that most malware will want to do?".
An excellent source for this sort of information is The Hacker Quarterly, which is so mainstream, you may find it at your local bookstore, or you can subscribe online to get it mailed to you.
It was started to help hackers and phreakers share information. It is still very popular with hackers today and is considered by many to be controversial in nature.
Contents of the Current Issue include:
Not The Enemy
Regaining Privacy in a Digital World
The Security-Conscious Uncle
Why the "No-Fly List" is a Fraud
TELECOM INFORMER
Finding Information in the Library of Congress
Hacking the DI-524 Interface
Simple How-to on Wireless and Windows Cracking
If You Can't Stand the Heat, Hack the Computers!
Security: Truth Versus Fiction
Hacking the Beamz
HACKER PERSPECTIVE: Jason Scott
iTunes Stored Credit Card Vulnerability
Zipcar's Information Infrastructure
The How and Why of Hacking the U.N.
Listen to Radio Hackers!
HACKER SPACES - EUROPE
Abusing Metadata
Verizon FIOS Wireless Insecurities
TRANSMISSIONS
Using Network Recon to Solve a Problem
Suing Telemarketers for Fun and Profit
HACKER HAPPENINGS
Plus LETTERS and MARKETPLACE
There is also an excellent series of articles on Hacking at Wikipedia and on Computer Viruses.
... And yes, it is important for programmers to understand how hacking and code breaking works, so they can do the best they can to circumvent it in their programs.
There is no difference between malicious code and an unintentional security bug.
You might as well be asking "How can I write a useful program that has no bugs and is impossible to exploit".
As we all learn in CS its impossible to even write debuggers to catch infinite loops let alone intelligent malevolence.
My advice for security conscious applications is an ex(p|t)ensive code review and use of commercially available static analysis software.