Develop demo application



  • Hi all,
    I have a Qt application that I need to provide to a customer.
    The costumer need to decide if it will buy the application or not .
    This is why I need to provide him a "demo" version of the application but I'm not sure on how to do that.

    The first solution should be to hard code a date and time on witch the application stop forever but this can be avoided by changing the system time.

    I need a demo application that is very difficult to "crack"...

    What solution can you suggest me?


  • Moderators

    Since it is a demo I would demo it to the client myself. Upon agreement you can hand it over.



  • Hehe if your app work with some data, you can limited it.

    For example I did app, which check some webpage, parse results and add it to csv file. I limited count of lines in csv file for demo version



  • My "demo" app was [hardcoded] for single user, when the actual app was meant to be for milti users.. :)



  • I must provide a "full function" demo application so I'd like to implement some way to block the application after some days...



  • Well... you can check some page in web, where you keep actual date of trial limit.
    However, you also should block app if internet connection disabled or your page unavailable :)



  • or you store some date anywhere hidden (in a file, memory wherever) and if time is over, it does not work anymore. To disable the switch back feature, if the system time is before last run --> disable it.



  • About the limitation date it is a good way to check date remotely anyway. As my experience if a appliacion don't need a remote connection to start, it can be cracked. This limitation can be applied only in the demo version. This means that to crack the demo it is not so simple because there is not a simple data somewhere but an enritre part of the code that won't work.

    Suggestion I have done:

    When the application starts creates a randon number i.e. between 1 and 15 minutes used to set a timer always running.

    The core functions of the application (simple and repetitive to set using #ifdef ... #endif or similar) will check if the timer is running else stop working.

    Everythime the timer stops fire a signal and restart.

    The signal check for connectivity and internet date.

    User shouls register on the next (optional)

    It is almost very difficult to crach a set of checks like this "intruded" in all the application. When you want simply #undef the value and the applicaiton will work in non-demo mode.

    Note that this undef can be a real variable so you can do it dynamically at runtime (e.g. after the user pays) enabling it by remote.

    The unblocking of the installation can be done "by defect": every new installation and / or computer reset the user is asked for the registration code to unclock the application. If the remote server see that the user is already registered this operation is automatic. I avoid these methods because if for any reason you should sto to give the service the application never run in non-demo mode.



  • [quote author="Vass" date="1316723339"]Well... you can check some page in web, where you keep actual date of trial limit.
    However, you also should block app if internet connection disabled or your page unavailable :)[/quote]

    This should be a good solution but the application should run in off-line PC.

    [quote author="Gerolf" date="1316730547"]or you store some date anywhere hidden (in a file, memory wherever) and if time is over, it does not work anymore. To disable the switch back feature, if the system time is before last run --> disable it.[/quote]

    I didn't thought to disable the application if time is before last run. This should be my solution.



  • [quote author="Luca" date="1316718066"]What solution can you suggest me?[/quote]

    A reasonable price for your product and a real added value for paying customers (extended support, cloud features, etc.). Time beeing spent in improving your product instead of protecting it.

    From the technical point of view there are a few things that should be taken into account to force at least the average customer to respect your restriction - you can't force anyone else anyways.

    • Always encrypt and sign your data.
      When storing data locally always encrypt and sign and do some sanity checks - otherwise it is edited in a minute. If it is encrypted and signed properly it doesn't matter where the data is stored (file, registry, etc.). It can be as simple as XOR - but you have to prevent recreation of valid data. If you rely on an active internet connection always use https and weave the servers public key into your application.
    • Rely on valid data.
      If there is no data or invalid data do not start up. The installer is responsible for creating inital data, not the application.
    • Do not rely on system calls.
      Especially when retrieving dates (this includes QDateTime and platform specific calls like GetSystemTime()). You can download application loaders and hypervisors around every corner nowadays which just hook into those system calls and annul your protection. The better way is to retrieve timestamps from system files which are accessed often (the pagefile or system log files).

    Keep in mind that your protection should always correlate with the value of your application. The cost and amount of work for protection will "rise exponentially":http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf to its efficiency and the amount of people it protects from - and is cracked in the end anyways. Software protection is science on its own, which includes anti-debugging and anti-reversing, encryption, hypervisor detection and a lot of other subjects.

    There are a lot of ready-made software protection solutions out there (including time-based restriction). Probably they are feasible for you.

    There is one more thing I want to add: Whatever you do - the software protection should be as invisible as possible to the end user. A demo is a showcase for your product and should convince people to spend money on it - which is pretty difficult if they are annoyed of the software protection. Nagware or Ubisoft's always-on copy protection is a prime example for this.



  • I don't like this kind of demo, but I don't want to start a flame on licensing.
    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...
    Remember that any kind of data written/read in a file can be intercepted by a malicious user, and having the application to go on the net just to check the license is awkward (in my opinion).
    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).
    It all depends on how much malicious are your clients...



  • @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 author="Alicemirror" date="1316759750"]About the limitation date it is a good way to check date remotely anyway. As my experience if a appliacion don't need a remote connection to start, it can be cracked. This limitation can be applied only in the demo version. This means that to crack the demo it is not so simple because there is not a simple data somewhere but an enritre part of the code that won't work.

    Suggestion I have done:

    When the application starts creates a randon number i.e. between 1 and 15 minutes used to set a timer always running.

    The core functions of the application (simple and repetitive to set using #ifdef ... #endif or similar) will check if the timer is running else stop working.

    Everythime the timer stops fire a signal and restart.

    The signal check for connectivity and internet date.

    User shouls register on the next (optional)

    It is almost very difficult to crach a set of checks like this "intruded" in all the application. When you want simply #undef the value and the applicaiton will work in non-demo mode.

    Note that this undef can be a real variable so you can do it dynamically at runtime (e.g. after the user pays) enabling it by remote.

    The unblocking of the installation can be done "by defect": every new installation and / or computer reset the user is asked for the registration code to unclock the application. If the remote server see that the user is already registered this operation is automatic. I avoid these methods because if for any reason you should sto to give the service the application never run in non-demo mode.[/quote]

    I don't understand very well how do you use the timer... Can you explain me better?



  • 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).


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.