how to protect the program
Sam
I know this might be a laughable question. But still, I would like to know
if some guru here have some ways to protect their programs. I wrote my
programs in VB 6. I would like to protect my program from being copied after
they are deployed.
Any input would be greatly appreciated!
Sam
Phill W.
Whatever you get in response to this, I'd make the most of it.
There's *already* an open source decompiler for .Net (and yes,
I really do mean "decompiler").
Regards,
Phill W.
Sam <sa...@etrials.com> wrote in article <upwqu5JrAHA.1912@tkmsftngp04>...
CurtC125
--
Curt
Soft...@NOSPAM.Darkfalz.Com
(Remove NOSPAM for E-Mail Replies)
http://www.Darkfalz.com
---------------------------------------------------------------
** And The Geek Shall Inherit The Earth
---------------------------------------------------------------
"Phill W." <P.A....@open.ac.uk> wrote in message
news:01c0aca0$7e6d21c0$0fa9...@pcms248.open.ac.uk...
Sam
program from being copied, I have no way to protect the code either, right?
Thanks!
Sam
"Phill W." <P.A....@open.ac.uk> wrote in message
news:01c0aca0$7e6d21c0$0fa9...@pcms248.open.ac.uk...
Timothy Casey
news:01c0aca0$7e6d21c0$0fa9...@pcms248.open.ac.uk...
>
> Whatever you get in response to this, I'd make the most of it.
> There's *already* an open source decompiler for .Net (and yes,
> I really do mean "decompiler").
>
How about VB3-6? Where are such things found?
--
Timothy Casey
South Australia
wor...@iprimus.com.au
Formerly
ca...@smart.net.au
(1997-2000 AD
Alexander Rodigin
If it isn't useful-just distribute some keys and ask a user to enter it
during installiation/first start. Then store it somewhere in depths of
registry. That all.
"Sam" <sa...@etrials.com> wrote in message
news:upwqu5JrAHA.1912@tkmsftngp04...
Phill W.
I believe it was possible to do this with VB3, but you'd have to rummage
around [the Web] to find it.
With VB4 things got better (i.e. more secure), then with VB5 & 6, we got
the ability to compile to "Native Code", so the best you can do with them
is disassemble them. You can't get any usable source back (well, at least
nothing you'd recognise as VB!!)
As far as I can tell, Dot Net seems to be going completely the other way.
HTH,
Phill W.
Timothy Casey <wor...@iprimus.com.au> wrote in article
<3aaf9ba2$1...@news.iprimus.com.au>...
Phill W.
http://www.mvps.org/vb/rants/vfred.htm
specifically the section titled "Open Sores?"
Regards,
Phill W.
CurtC125 <Soft...@NOSPAM.Darkfalz.Com> wrote in article
<OCgrXFKrAHA.1580@tkmsftngp04>...
Sam
By using 'cracked', you mean they will get the code, or just be able to copy
the program and use it anywhere?
Thanks again!
Sam
"Alexander Rodigin" <rod...@eti.co.ru> wrote in message
news:eGsxgMKrAHA.2132@tkmsftngp05...
Alexander Rodigin
analog.
"Sam" <sa...@etrials.com> wrote in message
news:O1scfnKrAHA.1408@tkmsftngp05...
Timothy Casey
depends on the success of your program, and you have others working for you,
do a dummy final release without telling them its a dud. Take your time,
leaving it lying around prior to the release date, and see if anything turns
up. If it does, you have a leak. Insiders can be nasty business - Especially
when the pirates get the final version well distributed before the release
date.
I think the best protection after trustworthy staff, is good customer
service and after sales support. These things cannot be copied, even by the
most determined reverse engineer.
Also, competitive pricing and a good quality manual that comes bundled
with the software is also another good technique. It is hard for pirates to
undercut a competitive price on original software enough to make it worth
the while of their customers. People may well use pirate copies to try out
your software, but if they really like it, they may well want the real
thing - Especially if the above factors are implimented.
The manual is not just a set of instructions in ITlish. It needs to be
written in English, and include enough background to offer the customer a
feel for the atmosphere of what your program does. The idea is to make your
program more than a meagre tool. It should be a coveted collectable in the
eyes of someone in the market for the line of software your program
addresses. This means pretty coloured pictures in appropriate places, nice
background textures and clearly legible fonts that are altered slightly to
offer the atmosphere of your application. The manual should be entertaining
and give prestige as well as added functionality to your program.
The incomplete junk offered by pirates does not cut it unless the
software manufacturer fails to provide adequate documentation and free after
sales support (like a certain large corporation whose executives can't seem
figure out why they are such an attractive target to pirates and the
customers of pirates). ID Software are very good at servicing their clients
beyond the boundaries of the CD. Their manuals are well presented, and if
you need any help, it does not cost $34 up front.
If the customer realises that s/he may want the genuine version of your
program in future, then s/he will be all the more reluctant to fork out
money on a pirate copy that may ultimately wind up being used as a coaster.
This means offering quality attractive documentation, service, etc. that is
not included on the CD. If you print the text of the manual from a second
generation copy, the serifs should be sufficiently damaged to upset any
attempts to scan your manual, without offering any deterioration in print
quality that would be noticed by your average computer user.
Don't offer trial versions. Anyone with a working knowledge of Assembler
or machine code will easily crack the typical lazy security that is applied
to most trial programs. A couple of pointers for making security numbers do
their job:
1) The program should be built around the security shell and not vice-versa.
It is better to build your security references into your program as you
develop it. This way, you can build in hundreds of security checkpoints,
without it being a major weeks long drama later. The idea is to avoid having
a single security reference that takes five minutes to crack once located.
If the pirate is required to do some real work to break your security, this
is a big deterant. Diligence is not a virtue of criminals.
2) Obfuscate, Obfuscate, Obfuscate! Write code to assemble at least some of
your security routines from fragments plucked from non-security routines
within your code - Which assembled routines are then run and disassembled.
Do the same with a couple of non-security routines that are vital but need
not run fast.
3) There should be _major_ structural differences between the trial version
and the full version, between CD releases and full program downloads. In
each case, a different security structure should be built into each type of
release, and there should be more obfuscation. Namely, each version should
contain redundant routines that look like routines that are present and
working in the other versions. The quick and nasty way to do this is to
comment all redundant code instead of deleting - until you finish your
program. Immediately prior to final compilation, uncomment all commented
redundant code, and ensure that it can't be triggered by isolating it in
unused routines, or setting goto commands to skip it. Aim for twice as much
redundant code as usable code.
4) Offer free fixes and upgrades in return for valid serial numbers. Set up
your download site so that if an individual applies to download an upgrade
or fix using a serial number registered to someone else, they are challenged
to explain the situation and await investigation (IE: The last owner of the
serial number is contacted to verify that the transfer of ownership has gone
ahead with consent) before the contender is registered as the new owner of
the contested serial number or allowed any downloads. Make sure your
customer is forced to agree to this with an appropriate clause in the EULA.
No registration of serial number should be accepted before you write
to/email the customer asking her/him to reply in confirmation of contact
details - And recieve said confirmation.
5) New versions should include major improvements, and be hardly
recognisable WRT the original product. This gives you a good platform to
dump previous versions on the internet for no charge - And that gives you
some ammunition to hit the pirates in the hip pocket if you are in a really
bad mood one day - not to mention, much of your competition.
Think bottlenecks. Does your security go through a single element? This
is the greatest vulnerability. Unless it is solved, it is better to rely on
the customer service/documentation angle. These are things that require too
much *work* for the common criminal to dare contemplating.
Remember, the pirates haven't even dented Microsoft - Other more diligent
individuals have been much more effective at doing that!
Anyway, that's just my 2c worth
--
Timothy Casey
South Australia
wor...@iprimus.com.au
Formerly
ca...@smart.net.au
(1997-2000 AD)
"Sam" <sa...@etrials.com> wrote in message
news:upwqu5JrAHA.1912@tkmsftngp04...
Timothy Casey
the DSD spooks and other national security types If I understand correctly,
the spooks don't copyright or patent anything, so they don't count from the
commercial perspective. Anyway, if a new version of VB6 does not come out
that offers any tangible overall improvement, I'll just switch to the latest
Borland C++ Builder when my needs outgrow VB6. This Borland product also has
a good visual interface, and reasonable autocoding. I haven't seen the help
files or the debugging utilities, so I don't know how these measure up.
I guess I will have to plan for the bleeding edge factor
when the time comes! :^)
--
Timothy Casey
South Australia
wor...@iprimus.com.au
Formerly
ca...@smart.net.au
(1997-2000 AD)
"Phill W." <P.A....@open.ac.uk> wrote in message
news:01c0aca4$9e341000$0fa9...@pcms248.open.ac.uk...
Sam
Sam
"Timothy Casey" <wor...@iprimus.com.au> wrote in message
news:3aaf...@news.iprimus.com.au...