I want to do a one-month-free-trial-version of my software (windows 32 bit). What
would be the best way to do it? The sofware is expected to connect to internet so
maybe it could fetch a key from dedicated server.

I am looking for pointer & ideas.

John Smith wrote:
There is no "best way".
All these protections are crackable in a few minutes...

jeff wrote:


Booting up a VM from a snapshot merely takes seconds, so does turning back
to the snapshot's state.

Use Registry to put Begin Time with DateTime value or some value like 100k
after that decrease it when application run until that value -1
Register Key : You can make couble of key, one for code and one for decode,
sometime i use ID of CPU or HDD to general Register Key

AnsiString __fastcall TfMainForm::GetMyID()
{
UINT errMode;
TCHAR szVolName[256];
DWORD dwMaxComSize;
DWORD lpVolumeSerialNumber;
DWORD dwFlags;
TCHAR szFS[256];
BOOL bRet;

errMode = SetErrorMode(SEM_FAILCRITICALERRORS);

bRet = GetVolumeInformation("C:\\", szVolName, sizeof(szVolName),
&lpVolumeSerialNumber, &dwMaxComSize, &dwFlags,
szFS, sizeof(szFS));
SetErrorMode(errMode);
if (bRet) {
return AnsiString(IntToHex(int(lpVolumeSerialNumber),8));
}

return 0;
}

This fuction will get ID of HDD so u can make Regiskey from it, aslo you
will make a website to get Active Key to active that software
"John Smith" <do_not_use@invalid.address.com> wrote in message
news:2esb241e813dbph4jj4li23cdnclc1bef9@4ax.com...

hel@40th.com wrote:


There is no need to. A VM allows you to restore your virtual computer to any
previous state.

Neither is reverse engineering needed. Someone who wans to rip it off can
simply run the entire program as a big subroutine, feeding it with input and
getting fed with its output.

Not to mention that "cracking" as probably easy. Depending on definitions,
not trivially crackable software is either impossible or infeasible to
create (and even then there's no way to decide if it actually is infeasible
or still trivial, and most of the work has to be done by humans, since it
requires non-computable functions).


The latter doesn't work. The former is something you want to actively fight
by fucking up your product with useless mechanisms.


Actually the most reasonable people will do so, to remove the offending shit.


Bullshit, since if done correctly, it's not dangerous at all. Just apply it
inside a virtual machine, copy out the modified files, compare them against
the original, and understand the usually small differences.

For some software, this is even a necessity to make it work in first place.
Exactly due to horribly stupid ideas of "protection".

"John Smith" <do_not_use@invalid.address.com> wrote in message
news:2esb241e813dbph4jj4li23cdnclc1bef9@4ax.com...
your software stop working 60 days after it was built. If you have 30 day
trial, you'll only need to publish new version every 30 days. This is
relativly bullet-proof - unless some user decides to change time on his box
(which not too many people will do, I think).

Boris

boris wrote:


Unless you don't install VMware tools or Virtual Machine Additions, they
won't sync the guest machine time to the host machine's time. Even if you
install them, you can still disable syncing.
Now every time your load from a snapshot, the time as well as the rest of
the machine state will be reset.

D'Oh, your idea didn't withstand even 5 seconds of someone thinking about it...

"Sebastian G." <seppi@seppig.de> wrote in message
news:68q4slF2utd68U2@mid.dfncis.de...
talking about - it's just b.s., unless the software in question costs many
thousands of dollars.

Boris

boris <someone@nospam.net> wrote...
It depends on the target user for the software. If the software is
intended for use by developers, the very idea of a time-limited fully-
functional trial is doomed to failure. (When your users have a debugger
and know how to use it, game over.)

For the average consumer, they have little to no idea what a VM is.
They barely have any concept of the registry. Storing a hidden value
someplace (registry, filesystem, etc) or making a custom time-limited
build for each user / time-block is usually sufficient. Yes, a certain
small number of users will be able to work around it, but depending on
the intended user base, that may be an acceptable loss.

Instead of making the trial version time-limited, perhaps you should
make it feature-limited with no time limit. It's fairly easy and more
robust in the face of malicious users, including those that know how to
use a VM.

http://discuss.joelonsoftware.com/de...iz.5.606974.20
http://kalzumeus.com/2006/08/16/to-l...-not-to-limit/

David

"David Jones" <ncic@tadmas.com> wrote in message
news:MPG.22920e30e98035709896e7@news.suddenlink.ne t...

Let's take as example of hypothetical word processor app that's time-limited
and was installed on VM.

Problems:

When rolling back VM to previous state, any new files would be lost. So any
documents user created/modified using that word processor would have to be
saved somewhere before rolling back VM. Another possibility: storing
documents on network share on main system (not on VM). Please note, that
these documents will have wrong timestamps, because they were created by VM
(where current time's screwed up). Also note: cost-conscious user wouldn't
install anti-virus software on VM - so it could get infected without user
knowing. So the documents created by that word processor could also get
infected - if e-mailed, they would spread virus.

Nothing of the above would prevent user from using word processor on VM (in
order to break time-lock on the word processor). It's just inconvenient
enough to prevent such approach unless the software in question's real
expensive.



Boris

David Jones wrote:


I've seen a lot of software trying to that with HKLM or
%CommonProgramFiles%. This made their shut not run as an unprivileged user,
and typically had to be explicitly cracked in order to make it run. Not a
fine idea to fuck with legitimate customers.


D'Oh, then they will simply rip off the unlimited version. Most of the users
do so just for getting the "Pro" or "Premium" version even though they won't
need ay of the additional functionality.

No, there's only one real solution: Don't make your software worse, but
better than the pirated version. For example, sell some limited support
options or release parts of the source code for inspections. Or provide
access to a repository of plugins.

Sebastian G. <seppi@seppig.de> wrote...
Normal users typically have read access to HKLM and system directories,
don't they? To time limit, you record the install time during
installation and then compare at run time, which is only a read. And,
it's expected that you'd have administrator rights during an
installation.

You're probably thinking of software that attempts to enforce only X
uses without registration. That's a big difference.


There is only one sure-fire way of preventing piracy: distribute
hardware (eg, a dongle). If you look at this issue from strictly a
technical standpoint, you can't win with any software-only solution.
Pointing out holes in a software-only solution is simply a case of
restating the obvious. You can't make water not wet.

Even with a repository of plugins (which itself can be copied) or with
releasing part of the source code (and I fail to see how that even
remotely makes any difference in quality), that doesn't make a bit of
difference from a technical perspective.

People who make money selling software also have to consider the
business angle. For 99%+ of software, some level of piracy is
tolerable, and attempting to lock it down beyond that level is overkill.
If this weren't true, every single software package would either be
free/open-source or come with hardware keys.

It is quite possible to make money from software that is more limited
than the cracked/pirated full version. Software companies have been
doing this for decades.

David

David Jones wrote:

Failing the assertion that it will be there.


This and many wrong assertions in the installer are typically worked around
by using a VM, recording the installation procedure, and removing all
garbage. The install time most likely is garbage.


You can't win with hardware either. After all, you can record all state
information in the software, and the entire communication protocol. This
allows for patching the software to always send the same request, you send
it back the expected reply, and there you go.


For some kinds of software, piracy is even desired, since it increases
exposure. Better if they rip off your software and tell others about it than
not ipping it off and not buying it anyway.


Lacking a comparison to how much better it would have sold without highly
artificial restrictions.

Sebastian G. <seppi@seppig.de> wrote...
Normal users should *NOT* be installing software, so having admin rights
is a perfectly reasonable assumption. Ask any system administrator.
Heck, what's the point of having system-wide settings if nothing can
ever set them? I can't believe I had to say that.


http://hackvan.com/pub/stig/articles...ople-register-
shareware.html

Time-limiting features had over 5x more registrations, and thus 5x more
revenue, than just putting up a nag screen. And it doesn't necessarily
follow that requiring up-front payment for all features (normal shrink-
wrap software) therefore maximizes revenue.

Consider MPLAB: time-limited only for advanced functionality, but the
basic software continues to work after the time expires. The software
exists merely to help sales of their microprocessors, so it doesn't
matter that a lot of users end up not paying for it. But companies that
do a lot of embedded work will end up buying it for the extra features.
Microchip ends up capturing some of the consumer surplus this way,
making more money overall than they would with either direction by
itself.

My point is that business decisions can overrule purely technical
decisions, and in some cases using time-limiting, while not completely
bulletproof, shouldn't be dismissed out of hand as a worthless endeavor.

David

David Jones wrote:



Nonsense. Installing software might be an administrative task, but rarely
requires any special privileges. That's why non-privileged administrator
accounts exist.


Administrators can set them. Software may do so as well, but should never
require such a behavior, because it might be actually intended to be
available to only one user. Not every IT environment is a company.

Especially for software you don't want system-wide settings, but rather
settings only applying to all users except administrators, and this is
typically handled by the administrator scheduling application of these
settings for a user-group in the context of explicit approval.

"David Jones" <ncic@tadmas.com> wrote in message
news:MPG.2292a9ea4bdd487a9896e8@news.suddenlink.ne t...
Actually I believe that 3dMax (animation program) shipped with a dongle. And
the pirates developed a special program that would scan the exe and disable
the dongle checks. Of course, the program was both desirable and expensive.

M

"Sebastian G." <seppi@seppig.de> wrote in message
news:68pfjaF2th9laU2@mid.dfncis.de...

Who the hell is going to run an app from a VM though? It's slower to load,
it's
slower to run the app, it's slower to restore the state.

Quicker just to install "Deep Freeze" and run the app after that, so that
after
a reboot the app's Registry data is gone again -- a constant fresh install.

"John" <someone@somewhere.com> wrote in message
news:4840e2e6$1@dnews.tpgi.com.au...
I compile and runs lots of apps through various VM's.

"Chris Thomasson" <cristom@comcast.net> wrote in message
newsNCdnZ7xQI5Jl9zVnZ2dnUVZ_tXinZ2d@comcast.com. ..

I don't mean developers.

"John" <someone@somewhere.com> wrote in message
news:48415e04$1@dnews.tpgi.com.au...
;^)