Develop demo application
-
Timer is used to check periodically and randomly at every startup that the device is already connected to the net (e.g. exchange a very small confirmation package on the server). This is very difficult to hack in the compiled application and grant you that the demo works as demo. Without the effort creating two different versions.
-
[quote author="Alicemirror" date="1316761702"]@Lukas: just a note. As I think fluca1978 is developing something for an Italian client. This means that the ethic logics you thing about a product are not applicable at all to this market. Unfortunately[/quote]
A little mess here, I'm not developing a demo application, Luca is...
Anyway, I agree with Lukas: it is worth spending time to improve the product than to protect against malicious users. That is also why I believe that preparing a virtual machine could be simpler, since you can totally control the full execution environment and can get to streets in a very short time. You could also offer a cloud machine, so that it is your client to decide if he wants to push his data to a remote machine that will be (?) erased after the demo time. -
[quote author="fluca1978" date="1316761236"]Limiting the data an application can handle is, in my opinion, the simplest and most effective way of producing a demo. However, I would be in doubt to buy an application that performs well on 10kB of data when I have to handle some GB...[/quote]
Yes.
[quote author="fluca1978" date="1316761236"]Remember that any kind of data written/read in a file can be intercepted by a malicious user[/quote]
The data should be already encrypted and signed when passed to the operating system (and a possible hook), and should be decryptde and verified after it has been retrieved from operating system (and a possible hook).But this is the crux of software protection. It has to be executed on the (malicious) clients machine and therefore it has to be at the clients machine and therefore it can be modified (operating system code and application code). The difference of an unprotected application and a protected application is just the amount of hard time you give to the malicious client.
Even if your application is fully encrypted and secured against modifications it has to be decrypted right before it is executed and passed to the (possibility emulated and recording) processor.
[quote author="fluca1978" date="1316761236"]... and having the application to go on the net just to check the license is awkward (in my opinion).[/quote]
Yes.
[quote author="fluca1978" date="1316761236"]Maybe with a virtual machine you will have much more opportunities to limit the user. I mean, after all, breaking a whole virtual machine is much more complex than breaking an application. And after the time has expired, you virtual machine can simply delete the database (or the data).[/quote]This is how modern software protection platforms usually work (at least some of them).
-
[quote author="Alicemirror" date="1316761702"]@Lukas: just a note. As I think fluca1978 is developing something for an Italian client. This means that the ethic logics you thing about a product are not applicable at all to this market. Unfortunately[/quote]
I think this is not an unique Italian feature.
But keep in mind that you want that your application is used and bought and that the additional licenses sold have to justify the additional amount of money spent to implement a software protection mechanism.
[IMHO] There are four groups of people:
People who will pay for your product anyways.
People who will pay for your product if there is no simple way to circumvent the protection.
People who won't pay for your product if there is no way to circumvent the protection (they simply just do not use it or use another product).
People who won't pay for your application because they crack it.
There is just a single group which is influenced by your software protection, #2. However, this group is usually way smaller then group #3, especially for non-niche products. Not every license not sold due to an unlicensed copy is a license not sold!
bq. I'm definitely not saying that it is pointless to protect your work, but don't overestimate its [the applications] importance.
-
[quote author="Alicemirror" date="1316764534"]Timer is used to check periodically and randomly at every startup that the device is already connected to the net (e.g. exchange a very small confirmation package on the server). This is very difficult to hack in the compiled application and grant you that the demo works as demo. Without the effort creating two different versions.[/quote]
Ok thanks.
-
[quote author="Lukas Geyer" date="1316765564"]
The data should be already encrypted and signed when passed to the operating system (and a possible hook), and should be decryptde and verified after it has been retrieved from operating system (and a possible hook).
[/quote]I don't agree with this statement. While there is sensible data that must be always encrypted, like the user password or alike, not all the data can and must be encrypted.
Beside the cpu time spent to do the encryption/verification, if you don't trust your operating system at all then maybe you should not develop a desktop application. Until you are developing an application for the FBI, retrieving an encrypted item price from a database in an intranet environment is too much. Set up an SSL to the database instead, or use a VPN, or something else.
-
[quote author="fluca1978" date="1316768049"]I don't agree with this statement. While there is sensible data that must be always encrypted, like the user password or alike, not all the data can and must be encrypted.[/quote]
Not all data concerning the application has to be encryted - but all data concerning the software protection has to (no exceptions), independent of its location (memory or disk). That's what we are talking about here, aren't we? ;-)
Unencrytped (or non obfuscated data) is extremely easy to spot, especially if the structure is known (for date strings, SYSTEMTIME structures or QDateTime objects). And as soon as I have found out where in memory or on disk your software protection data resides it is again extremely easy to change it if it is not encrypted or signed.
[quote author="fluca1978" date="1316768049"]... if you don't trust your operating system at all then maybe you should not develop a desktop application.[/quote]
It's all about domains here. The application domain is something I do control, the operating system domain is something that I do not control. I cannot influence or foresee what happens to data as soon as it passes the domain border.
If I pass any unecrypted data (for example the installation date) to the operating system it can be tapped and modified easily. All the attacker has to do is to install a simple hook. If the data is encrypted inside the (well defended) application the attack has to break into the application first and then deal with the encryption. That's a huge difference. And that's the difference between cracked and non-cracked software.
You cannot trust something you do not control.
[quote author="fluca1978" date="1316768049"]Beside the cpu time spent to do the encryption/verification,...[/quote]
That's a non-issue. When doing disk-to-memory encryption/decryption the disk will always be the bottleneck, when doing memory-to-memory encryption/decryption using the right algorithm it is measurable at best, but usually not noticeable - especially when encryption/decryption is done in hardware (Intel Westmere and AMD Bulldozer upwards, increasing number of SoCs).
[quote author="fluca1978" date="1316768049"]Until you are developing an application for the FBI, retrieving an encrypted item price from a database in an intranet environment is too much. Set up an SSL to the database instead, or use a VPN, or something else. [/quote]
If we buy into statistics up to 80% of the attacks on the IT infrastructure are done by people inside the company. So if you are handling business critical data (internal price lists are business critical data) or individual-related data you are (legally) obligated to protect them. We have had an "example":http://www.rechargenews.com/energy/wind/article278112.ece recently what a single person can do to a multi-million dollar company.
-
Well, security is often associated with paranoia, and I'm not trying to convince anyone here.
My opinion is that your application should not try to encrypt data that is going to store where other encryption is available. For a typical database example, even an item price does not have to be encrypted in the database. You application must talk with SSL to the database, the database can store it in encrypted columns, but your application does not have to. Other scenarios of course could require a stronger environment.
Another point is that you are an application developer, so you have to trust the execution environment you are running on. This does not mean that you don't have to verify data, but verifying is much more different than encrypting them. And that is why I proposed to use a virtual machine, that can easily be configured to be a trusted environment. I don't believe virtualization adds security, but for a demo it will surely make things simpler than developing a protection mechanism at the application level. But hey, this is my opinion.
This discussion reminds me the DRM battle.... -
[quote author="fluca1978" date="1316774989"]Well, security is often associated with paranoia.[/quote]
Well, you should probably tell that those 70 million people whose credit card numbers were stolen from the PSN because they were stored unencrypted in a database ;-) -
This is not a strict problem of the application, but of the database. Again, there is data that must be stored encrypted, but encrypting it in the application when it can be in the storage does not sound good to me.
-
[quote author="fluca1978" date="1316779404"]This is not a strict problem of the application, but of the database. Again, there is data that must be stored encrypted, but encrypting it in the application when it can be in the storage does not sound good to me. [/quote]
We are still talking about data related to the software protection here, not data in general, aren't we?
[quote author="Lukas Geyer" date="1316772273"]Not all data concerning the application has to be encryted - but all data concerning the software protection has to (no exceptions), independent of its location (memory or disk).[/quote]
-
[quote author="Lukas Geyer" date="1316780193"]
We are still talking about data related to the software protection here, not data in general, aren't we?
[/quote]
Not sure what you are talking about, since I guess your example is about data protection, not application protection.
Anyway, this thread demonstrates again that it is difficult even to talk about this kind of software protection (I mean demo locks).