Protecting VB.NET application...

[Bobby C.]

My company is in the process of getting ready (well actually QTR 2 2004) to
roll out a rewritten version of a vertical market application for the
municipal market (small and medium sized cities). Software protection
(keeping the honest people honest) hasn't ever been a problem but in this
roll out we are going to be distributing the product through several firms
in Asia. I would like to find an effective solution that would limit our
losses in Asia but also not tick off our customers in the US. The Asian
firms I am dealing with have requested using hardware keys (dongles?) but
the more I read it seems like they are really despised and could hurt sales
here un the US.

Does anyone have some advice or an opinions that could help a novice at this
type of stuff? Any help would be greatly appreciated...!

--

Bobby C.
Proper reply address is without the text -REMOVE-

[Shawn B.]

Provide a way so you can have automatic updates (if you don't already) but
only via an active subscription account. So at the least, after they figure
out how to bypass all other protections, if they don't have an active
subscription account they can't get any updates. But all valid users won't
have a problem with this because they will be active subscribers. If you
see too many updates from the same subscription account, then you can simply
deny the updates. This seems to be quite effective, it's not easy to hack
this scheme, although they can capture what gets updated and do a diff, it
should still be effective.

Hardware keys are despictable, but I prefer them over the current
"Activation" scheme that MS uses. With "activation" per se, after you
upgrade your PC and pull your hard drive out and plop it in the new Unit, or
change a number of peripherials or system components, you no longer can use
your product, besides, it is hardlocked to your installation unit. At least
with hardware keys, you can install on as many machines as you want but can
only simultaneously use the project on whatever machine has the key plugged
in. eHelp Robot uses a scheme where if multiple installations use the same
product key and are running simultaneously and exceed the number of licenses
for that key, they all lock out and you actually have to go find a registry
key and remove it so you can ever use the product again on some of the
machines.

You should use a licensing scheme, www.xheo.com comes to mind (I have no
experience with it). You should use an obfuscation utility to make it
harder to reverse the IL. I despise activation and except for MS products,
refuse to purchase any product that uses similar activation schemes
(increasingly, less and less commercial software finds its way into my
machines these days because of that) and I suspect I'm increasingly not
alone on this.

One activation scheme I am in support of, is www.libronix.com (it's an ebook
reader for religous texts). Their products require being activated and each
collection of texts you acquire are hardlocked to that particular activation
(the activation of the initial ebook reader install -- which is personally
identifyable). But, you can "backup" a special unlock key it generates (and
re-back-it-up each subsequent ebook addition). Then, each time you wish to
install the the books on any other system (they intend for it to be the same
system) you just use the key but it doesn't seem to care how many system
components change or how many times you install as long as it isn't
thousands of times (indicitive of an internet sharer). This certainly blows
away the treat-you-like-a-criminal approach that MS takes and that others
are starting to take.

Others issue product keys that are only active for certain lengths of time
or until they are leaked to the Internet. If the program is modified in
anyway then none of the updates will update or the key will be deactivated.

Combine all these techniques and you'll find yourself able to minimimze the
effect of piracy but you can't eliminate it, especially in an Asian market.
The key is to make sure it is not intrusive to the end user. And to not
make them feel like "gee, I purchased this for $xxxx dolllars and now
because I got a new network card, modem, video card, and cd-burner I can't
use the product anymore." That's a good way of making sure you're customers
never return. That is why I don't use Norton AV anymore, Turbo Tax, (I
can't avoid MS products), and a few others. I refuse to keep paying for
something I should have perpetually (considering I am always and constantly
changing hardware to keep up-to-date) or have to keep renewing every year or
so (unless it is worth it, like Virus updates and OS's) (but it isn't worth
it for a dev tool and photo editing applications and email clients and
such). Open source isn't much of an alternative, either. I just find other
commercial alternatives and I know many people who do the same so you must
at least keep it non-intrusive.

Hardware keys problems aren't unreasonable but require a heftier investment
because of costs. Often this is passed on to the consumer. Remember, tho,
everyone says that all these anti-piracy measures are necessary and
ultimately will cause some savings to be passed on the the consumer. In
reality, prices only go up with more elaborate protection schemes. Whether
the schemes work or not, companies rarely lower their prices. And, these
scheme cost and will drive prices up. What can the Asian market offord to
pay? Probly not as much as the US market and the US market will suffer more
for the cost of "protection". Most vendors say it makes the software easier
to use. That's crap. I avoid them because it's too intrusive and
noticable.

In the end, Rational software uses www.globetrotter.com for their protection
schemes (problem not a very cheap solution to licence) but, they have a
license server installed locall and you can get "floating" licences where
you can install as many times as you want but during use, each user consume
1 license. That is reasonable, IMO. But the server is hardlocked tot he
server machine.

Hope this helps.

Thanks,
Shawn

"Bobby C." <cl***@dixon-REMOVE-creek.com> wrote in message
news:Os****************@TK2MSFTNGP11.phx.gbl...

My company is in the process of getting ready (well actually QTR 2 2004) to roll out a rewritten version of a vertical market application for the
municipal market (small and medium sized cities). Software protection
(keeping the honest people honest) hasn't ever been a problem but in this
roll out we are going to be distributing the product through several firms
in Asia. I would like to find an effective solution that would limit our
losses in Asia but also not tick off our customers in the US. The Asian
firms I am dealing with have requested using hardware keys (dongles?) but
the more I read it seems like they are really despised and could hurt sales here un the US.

Does anyone have some advice or an opinions that could help a novice at this type of stuff? Any help would be greatly appreciated...!

--

Bobby C.
Proper reply address is without the text -REMOVE-

[Bobby C.]

Shawn,

Thanks for the great information. You covered the topic nicely for me,
although I'm not sure how you feel about activiation schemes (just kidding).
As far as activiation is concerned, Infragistics (after their merger)
applied an activation scheme that was a nightmare. After a lot of yelling
and lost sales they changed their mind and dropped that madness.

It seems pretty clear that the Asian market will just have to work with
hardware keys. I can isolate the code and versions so this wouldn't be a
problem. It's the US market that makes me wonder. I would like to have
some sort of license control but, as you said, the costs are pretty
significant for some of the software solutions. One other concern with this
approach also is that it requires a server install. Some of the
installations I will be working with only have some peer-to-peer networks
and I'm not certain if these schemes work in that environment.

Thank you very, very much for the info.

--

Bobby C.
Proper reply address is without the text -REMOVE-
Shawn B. wrote:

Provide a way so you can have automatic updates (if you don't
already) but only via an active subscription account. So at the
least, after they figure out how to bypass all other protections, if
they don't have an active subscription account they can't get any
updates. But all valid users won't have a problem with this because
they will be active subscribers. If you see too many updates from
the same subscription account, then you can simply deny the updates.
This seems to be quite effective, it's not easy to hack this scheme,
although they can capture what gets updated and do a diff, it should
still be effective.

Hardware keys are despictable, but I prefer them over the current
"Activation" scheme that MS uses. With "activation" per se, after you
upgrade your PC and pull your hard drive out and plop it in the new
Unit, or change a number of peripherials or system components, you no
longer can use your product, besides, it is hardlocked to your
installation unit. At least with hardware keys, you can install on
as many machines as you want but can only simultaneously use the
project on whatever machine has the key plugged in. eHelp Robot uses
a scheme where if multiple installations use the same product key and
are running simultaneously and exceed the number of licenses for that
key, they all lock out and you actually have to go find a registry
key and remove it so you can ever use the product again on some of
the machines.

You should use a licensing scheme, www.xheo.com comes to mind (I have
no experience with it). You should use an obfuscation utility to
make it harder to reverse the IL. I despise activation and except
for MS products, refuse to purchase any product that uses similar
activation schemes (increasingly, less and less commercial software
finds its way into my machines these days because of that) and I
suspect I'm increasingly not alone on this.

One activation scheme I am in support of, is www.libronix.com (it's
an ebook reader for religous texts). Their products require being
activated and each collection of texts you acquire are hardlocked to
that particular activation (the activation of the initial ebook
reader install -- which is personally identifyable). But, you can
"backup" a special unlock key it generates (and re-back-it-up each
subsequent ebook addition). Then, each time you wish to install the
the books on any other system (they intend for it to be the same
system) you just use the key but it doesn't seem to care how many
system components change or how many times you install as long as it
isn't thousands of times (indicitive of an internet sharer). This
certainly blows away the treat-you-like-a-criminal approach that MS
takes and that others are starting to take.

Others issue product keys that are only active for certain lengths of
time or until they are leaked to the Internet. If the program is
modified in anyway then none of the updates will update or the key
will be deactivated.

Combine all these techniques and you'll find yourself able to
minimimze the effect of piracy but you can't eliminate it, especially
in an Asian market. The key is to make sure it is not intrusive to
the end user. And to not make them feel like "gee, I purchased this
for $xxxx dolllars and now because I got a new network card, modem,
video card, and cd-burner I can't use the product anymore." That's a
good way of making sure you're customers never return. That is why I
don't use Norton AV anymore, Turbo Tax, (I can't avoid MS products),
and a few others. I refuse to keep paying for something I should
have perpetually (considering I am always and constantly changing
hardware to keep up-to-date) or have to keep renewing every year or
so (unless it is worth it, like Virus updates and OS's) (but it isn't
worth it for a dev tool and photo editing applications and email
clients and such). Open source isn't much of an alternative, either.
I just find other commercial alternatives and I know many people who
do the same so you must at least keep it non-intrusive.

Hardware keys problems aren't unreasonable but require a heftier
investment because of costs. Often this is passed on to the
consumer. Remember, tho, everyone says that all these anti-piracy
measures are necessary and ultimately will cause some savings to be
passed on the the consumer. In reality, prices only go up with more
elaborate protection schemes. Whether the schemes work or not,
companies rarely lower their prices. And, these scheme cost and will
drive prices up. What can the Asian market offord to pay? Probly
not as much as the US market and the US market will suffer more for
the cost of "protection". Most vendors say it makes the software
easier to use. That's crap. I avoid them because it's too intrusive
and noticable.

In the end, Rational software uses www.globetrotter.com for their
protection schemes (problem not a very cheap solution to licence)
but, they have a license server installed locall and you can get
"floating" licences where you can install as many times as you want
but during use, each user consume 1 license. That is reasonable,
IMO. But the server is hardlocked tot he server machine.

Hope this helps.

Thanks,
Shawn

"Bobby C." <cl***@dixon-REMOVE-creek.com> wrote in message
news:Os****************@TK2MSFTNGP11.phx.gbl...

My company is in the process of getting ready (well actually QTR 2
2004) to roll out a rewritten version of a vertical market
application for the municipal market (small and medium sized
cities). Software protection (keeping the honest people honest)
hasn't ever been a problem but in this roll out we are going to be
distributing the product through several firms in Asia. I would
like to find an effective solution that would limit our losses in
Asia but also not tick off our customers in the US. The Asian firms
I am dealing with have requested using hardware keys (dongles?) but
the more I read it seems like they are really despised and could
hurt sales here un the US.

Does anyone have some advice or an opinions that could help a novice
at this type of stuff? Any help would be greatly appreciated...!

--

Bobby C.
Proper reply address is without the text -REMOVE-

[Shawn B.]

I forgot to mention that certain kinds of locking you to a machine for 3rd
parties (why I don't own any .NET 3rd party controls -- I do exclusivley
ASP.NET these days) is they mostly lock you to a server and I can't handle
that. I'd rather pay per developer, or per site, or per company, or
something that. But not per deployment server, because I change domain
names like madness or might want to leverage a piece of code that may
*depend* on a 3rd party control but have to pay up for another domain. That
is why I haven't purchased any 3rd party controls. I can handle 1 year
*update and upgrade* subscription so long as I can deploy without royalties
or licencing, perpetually. That's another thing to concider. I think 3rd
parties do okay, for now.

But just wait until all software requires constant re-payment and activation
schemes and anything that threatens to hinder perpetuality and people's
pocket books will start to dry up. Personally, I have well over $60k of
software I lave legally purchased personally, as a hobbyist, over the last 8
years. This include updates and upgrades on the same. This includes
hardware and books (I have a personal library of over 400 programming
books). It works well because, at home, I have a network of 3 computers and
multiple removable hard disks (primary and secondary). There is only ever 1
person simultaneously using any program. My wife may use IE or Word but I'm
licensed for that (I have a Universal MSDN subscription which allows 10
installs but I think 1 user. Each year for 4 years I have a new licence --
I never renew). I also have VirtualPC for testing different things quickly
and need to install some software in the guests OS.

If I was all of the sudden forced to have to keep repaying to use everything
that I use, all of the sudden, I won't use anything. I'll stick with the
MSDN but I wouldn't purchase all the other developer stuff because it only
indirectly pays for itself but not quite directly. I work for a living, I'm
good at what I do, but what I do at home doesn't reflect what I do at work.

Imagine everyone else having to pay up for everything they use and take for
granted? People won't. Businesses will start reconsidering what is
important to them and stick with a few packages the need and disreqard the
rest. Then, all of the sudden, the IT sector takes another devastating hit.
But in this case, as the last (over investment), they did it to them selves
with their greed.

Anyway, just thought I'd throw that in there. Just something to consider.
That activation and hardlocking schemes work for the little guys until
everyone is doing it then people start to think twice about where there
money goes and there's a good chance, in a saturated market, that it won't
go to you.

When I release my software (if I ever charge for it) I will stick with the
product key model. Then an active subscription model for updates. I also
will provide my first major verseion number release for free for all, but
then people have to subscribe to get updates. But I won't use activation or
hardware keys or domain locking or anthing like that. Then my server can
just reject overused keys and any modified app. I think that will be fair.
I think that is fair.

Thanks,
Shawn


"Bobby C." <cl***@dixon-REMOVE-creek.com> wrote in message
news:eC**************@TK2MSFTNGP12.phx.gbl...

Shawn,

Thanks for the great information. You covered the topic nicely for me,
although I'm not sure how you feel about activiation schemes (just kidding). As far as activiation is concerned, Infragistics (after their merger)
applied an activation scheme that was a nightmare. After a lot of yelling
and lost sales they changed their mind and dropped that madness.

It seems pretty clear that the Asian market will just have to work with
hardware keys. I can isolate the code and versions so this wouldn't be a
problem. It's the US market that makes me wonder. I would like to have
some sort of license control but, as you said, the costs are pretty
significant for some of the software solutions. One other concern with this approach also is that it requires a server install. Some of the
installations I will be working with only have some peer-to-peer networks
and I'm not certain if these schemes work in that environment.

Thank you very, very much for the info.

--

Bobby C.
Proper reply address is without the text -REMOVE-
Shawn B. wrote:

Provide a way so you can have automatic updates (if you don't
already) but only via an active subscription account. So at the
least, after they figure out how to bypass all other protections, if
they don't have an active subscription account they can't get any
updates. But all valid users won't have a problem with this because
they will be active subscribers. If you see too many updates from
the same subscription account, then you can simply deny the updates.
This seems to be quite effective, it's not easy to hack this scheme,
although they can capture what gets updated and do a diff, it should
still be effective.

Hardware keys are despictable, but I prefer them over the current
"Activation" scheme that MS uses. With "activation" per se, after you
upgrade your PC and pull your hard drive out and plop it in the new
Unit, or change a number of peripherials or system components, you no
longer can use your product, besides, it is hardlocked to your
installation unit. At least with hardware keys, you can install on
as many machines as you want but can only simultaneously use the
project on whatever machine has the key plugged in. eHelp Robot uses
a scheme where if multiple installations use the same product key and
are running simultaneously and exceed the number of licenses for that
key, they all lock out and you actually have to go find a registry
key and remove it so you can ever use the product again on some of
the machines.

You should use a licensing scheme, www.xheo.com comes to mind (I have
no experience with it). You should use an obfuscation utility to
make it harder to reverse the IL. I despise activation and except
for MS products, refuse to purchase any product that uses similar
activation schemes (increasingly, less and less commercial software
finds its way into my machines these days because of that) and I
suspect I'm increasingly not alone on this.

One activation scheme I am in support of, is www.libronix.com (it's
an ebook reader for religous texts). Their products require being
activated and each collection of texts you acquire are hardlocked to
that particular activation (the activation of the initial ebook
reader install -- which is personally identifyable). But, you can
"backup" a special unlock key it generates (and re-back-it-up each
subsequent ebook addition). Then, each time you wish to install the
the books on any other system (they intend for it to be the same
system) you just use the key but it doesn't seem to care how many
system components change or how many times you install as long as it
isn't thousands of times (indicitive of an internet sharer). This
certainly blows away the treat-you-like-a-criminal approach that MS
takes and that others are starting to take.

Others issue product keys that are only active for certain lengths of
time or until they are leaked to the Internet. If the program is
modified in anyway then none of the updates will update or the key
will be deactivated.

Combine all these techniques and you'll find yourself able to
minimimze the effect of piracy but you can't eliminate it, especially
in an Asian market. The key is to make sure it is not intrusive to
the end user. And to not make them feel like "gee, I purchased this
for $xxxx dolllars and now because I got a new network card, modem,
video card, and cd-burner I can't use the product anymore." That's a
good way of making sure you're customers never return. That is why I
don't use Norton AV anymore, Turbo Tax, (I can't avoid MS products),
and a few others. I refuse to keep paying for something I should
have perpetually (considering I am always and constantly changing
hardware to keep up-to-date) or have to keep renewing every year or
so (unless it is worth it, like Virus updates and OS's) (but it isn't
worth it for a dev tool and photo editing applications and email
clients and such). Open source isn't much of an alternative, either.
I just find other commercial alternatives and I know many people who
do the same so you must at least keep it non-intrusive.

Hardware keys problems aren't unreasonable but require a heftier
investment because of costs. Often this is passed on to the
consumer. Remember, tho, everyone says that all these anti-piracy
measures are necessary and ultimately will cause some savings to be
passed on the the consumer. In reality, prices only go up with more
elaborate protection schemes. Whether the schemes work or not,
companies rarely lower their prices. And, these scheme cost and will
drive prices up. What can the Asian market offord to pay? Probly
not as much as the US market and the US market will suffer more for
the cost of "protection". Most vendors say it makes the software
easier to use. That's crap. I avoid them because it's too intrusive
and noticable.

In the end, Rational software uses www.globetrotter.com for their
protection schemes (problem not a very cheap solution to licence)
but, they have a license server installed locall and you can get
"floating" licences where you can install as many times as you want
but during use, each user consume 1 license. That is reasonable,
IMO. But the server is hardlocked tot he server machine.

Hope this helps.

Thanks,
Shawn

"Bobby C." <cl***@dixon-REMOVE-creek.com> wrote in message
news:Os****************@TK2MSFTNGP11.phx.gbl...

My company is in the process of getting ready (well actually QTR 2
2004) to roll out a rewritten version of a vertical market
application for the municipal market (small and medium sized
cities). Software protection (keeping the honest people honest)
hasn't ever been a problem but in this roll out we are going to be
distributing the product through several firms in Asia. I would
like to find an effective solution that would limit our losses in
Asia but also not tick off our customers in the US. The Asian firms
I am dealing with have requested using hardware keys (dongles?) but
the more I read it seems like they are really despised and could
hurt sales here un the US.

Does anyone have some advice or an opinions that could help a novice
at this type of stuff? Any help would be greatly appreciated...!

--

Bobby C.
Proper reply address is without the text -REMOVE-

[Huihong]

http://www.remotesoft.com/salamander/protector.html
http://www.remotesoft.com/linker/index.html

Besides licensing protection, you may also consider
protection against reverse engineering, so people can not
decompile your executables.

We offer a series of products to guanrantee that your .NET
apps will have at least the same level of protection as
traditional C/C++ executables. It stops decompilation,
rather than just making it a bit more difficult (such as
what obfuscators are doing).

The best stragetegy is link, obfuscate, and then protect.
In this way, the final executable contains fewer symbols,
and all decompilable MSIL code are replaced with native
x86 code. There is no chance people can still read your
source code.

Here is more info:

(1) salamander .net protector
http://www.remotesoft.com/salamander/protector.html
(2) salamander .net obfuscator,
http://www.remotesoft.com/salamander/obfuscator.html
(3) salamander .net linker,
http://www.remotesoft.com/linker/

To the best of my knowledge, if you using the above 3
products, your app will be secure as good as native C/C++
code, or even better.

Native C/C++ code is considered to be safe against reverse
engineering because, to my understanding,

(1) it turns all symbols into memory locations, this is
similiar to what a .NET obfuscator is doing
(2) it has much much fewer entry points, whereas .NET
assemblies expose all classes and methods to the public.
This is, on the other hand, the beauty of the java/.net
platforms, sincee the rich metadata provides many benefits
to developers.
(3) native code instructions are register transfer
languages, while .NET IL is strictly stack based. Stack
based instructions are easier to convert into expressions.

These are the main reasons why I think native code is
safe. If we could convert .NET assemblies into similar
format, then it has the same level of protection against
reverse engineering.

Now let me explain how our products try to achieve that,

(1) the obfuscator performs task (1) by converting symbols
to meaningless ones, similiar to memory locations

(2) the protector converts IL code into native code, so
the instructions can not be decompiled. I have yet to see
a good c/C++ decompiler. None really works.

(3) the linker can be used to link assemblies together,
and thus can be used to remove those public entrypoints.
This performs task (2). The fewer entry points, the better
against reverse engineering.

I believe, this gives the best protection as of today, and
you can relax with a guarantee that no one will be able to
decompile your code, same level of confidence as your old
c/c++ native code.

Huihong
Remotesoft
The Best Protection for .NET Apps

-----Original Message-----
My company is in the process of getting ready (well actually QTR 2 2004) toroll out a rewritten version of a vertical market application for themunicipal market (small and medium sized cities). Software protection(keeping the honest people honest) hasn't ever been a problem but in thisroll out we are going to be distributing the product through several firmsin Asia. I would like to find an effective solution that would limit ourlosses in Asia but also not tick off our customers in the US. The Asianfirms I am dealing with have requested using hardware keys (dongles?) butthe more I read it seems like they are really despised and could hurt saleshere un the US.

Does anyone have some advice or an opinions that could help a novice at thistype of stuff? Any help would be greatly appreciated...!

--

Bobby C.
Proper reply address is without the text -REMOVE-

.

[Shawn B.]

The pricing isn't reasonable though, for people like me, hobbyists, who
don't make programs generally as a primary source of business. Of course,
it might be for someone like the original poster who has more to loose.
Combine the price of all those products from remotesoft and ouch ouch ouch.
Not for me, not unless I intend on every making that money back.
Thanks,
Shawn
"Huihong" <an*******@discussions.microsoft.com> wrote in message
news:cb****************************@phx.gbl...

http://www.remotesoft.com/salamander/protector.html
http://www.remotesoft.com/linker/index.html

Besides licensing protection, you may also consider
protection against reverse engineering, so people can not
decompile your executables.

We offer a series of products to guanrantee that your .NET
apps will have at least the same level of protection as
traditional C/C++ executables. It stops decompilation,
rather than just making it a bit more difficult (such as
what obfuscators are doing).

The best stragetegy is link, obfuscate, and then protect.
In this way, the final executable contains fewer symbols,
and all decompilable MSIL code are replaced with native
x86 code. There is no chance people can still read your
source code.

Here is more info:

(1) salamander .net protector
http://www.remotesoft.com/salamander/protector.html
(2) salamander .net obfuscator,
http://www.remotesoft.com/salamander/obfuscator.html
(3) salamander .net linker,
http://www.remotesoft.com/linker/

To the best of my knowledge, if you using the above 3
products, your app will be secure as good as native C/C++
code, or even better.

Native C/C++ code is considered to be safe against reverse
engineering because, to my understanding,

(1) it turns all symbols into memory locations, this is
similiar to what a .NET obfuscator is doing
(2) it has much much fewer entry points, whereas .NET
assemblies expose all classes and methods to the public.
This is, on the other hand, the beauty of the java/.net
platforms, sincee the rich metadata provides many benefits
to developers.
(3) native code instructions are register transfer
languages, while .NET IL is strictly stack based. Stack
based instructions are easier to convert into expressions.

These are the main reasons why I think native code is
safe. If we could convert .NET assemblies into similar
format, then it has the same level of protection against
reverse engineering.

Now let me explain how our products try to achieve that,

(1) the obfuscator performs task (1) by converting symbols
to meaningless ones, similiar to memory locations

(2) the protector converts IL code into native code, so
the instructions can not be decompiled. I have yet to see
a good c/C++ decompiler. None really works.

(3) the linker can be used to link assemblies together,
and thus can be used to remove those public entrypoints.
This performs task (2). The fewer entry points, the better
against reverse engineering.

I believe, this gives the best protection as of today, and
you can relax with a guarantee that no one will be able to
decompile your code, same level of confidence as your old
c/c++ native code.

Huihong
Remotesoft
The Best Protection for .NET Apps

-----Original Message-----
My company is in the process of getting ready (well

actually QTR 2 2004) to

roll out a rewritten version of a vertical market

application for the

municipal market (small and medium sized cities).

Software protection

(keeping the honest people honest) hasn't ever been a

problem but in this

roll out we are going to be distributing the product

through several firms

in Asia. I would like to find an effective solution that

would limit our

losses in Asia but also not tick off our customers in the

US. The Asian

firms I am dealing with have requested using hardware

keys (dongles?) but

the more I read it seems like they are really despised

and could hurt sales

here un the US.

Does anyone have some advice or an opinions that could

help a novice at this

type of stuff? Any help would be greatly appreciated...!

--

Bobby C.
Proper reply address is without the text -REMOVE-

.

[Huihong]

The total price for all of the 3 products (linker,
obfusactor and protector) is $2388, which can be used by 5
developers with unlimited distribution of the protected
code. Consider this tool is for production use by a
release team in a company, it is reasonable (since the
number of license required will be much fewer than other
regular development tool).

Thanks for the feedback,

Huihong

-----Original Message-----
The pricing isn't reasonable though, for people like me, hobbyists, whodon't make programs generally as a primary source of business. Of course,it might be for someone like the original poster who has more to loose.Combine the price of all those products from remotesoft and ouch ouch ouch.Not for me, not unless I intend on every making that money back.

Thanks,
Shawn
"Huihong" <an*******@discussions.microsoft.com> wrote in messagenews:cb****************************@phx.gbl...

http://www.remotesoft.com/salamander/protector.html
http://www.remotesoft.com/linker/index.html

Besides licensing protection, you may also consider
protection against reverse engineering, so people can not decompile your executables.

We offer a series of products to guanrantee that your .NET apps will have at least the same level of protection as
traditional C/C++ executables. It stops decompilation,
rather than just making it a bit more difficult (such as
what obfuscators are doing).

The best stragetegy is link, obfuscate, and then protect. In this way, the final executable contains fewer symbols, and all decompilable MSIL code are replaced with native
x86 code. There is no chance people can still read your
source code.

Here is more info:

(1) salamander .net protector
http://www.remotesoft.com/salamander/protector.html
(2) salamander .net obfuscator,
http://www.remotesoft.com/salamander/obfuscator.html
(3) salamander .net linker,
http://www.remotesoft.com/linker/

To the best of my knowledge, if you using the above 3
products, your app will be secure as good as native C/C++ code, or even better.

Native C/C++ code is considered to be safe against reverse engineering because, to my understanding,

(1) it turns all symbols into memory locations, this is
similiar to what a .NET obfuscator is doing
(2) it has much much fewer entry points, whereas .NET
assemblies expose all classes and methods to the public.
This is, on the other hand, the beauty of the java/.net
platforms, sincee the rich metadata provides many benefits to developers.
(3) native code instructions are register transfer
languages, while .NET IL is strictly stack based. Stack
based instructions are easier to convert into expressions.
These are the main reasons why I think native code is
safe. If we could convert .NET assemblies into similar
format, then it has the same level of protection against
reverse engineering.

Now let me explain how our products try to achieve that,

(1) the obfuscator performs task (1) by converting symbols to meaningless ones, similiar to memory locations

(2) the protector converts IL code into native code, so
the instructions can not be decompiled. I have yet to see a good c/C++ decompiler. None really works.

(3) the linker can be used to link assemblies together,
and thus can be used to remove those public entrypoints.
This performs task (2). The fewer entry points, the better against reverse engineering.

I believe, this gives the best protection as of today, and you can relax with a guarantee that no one will be able to decompile your code, same level of confidence as your old c/c++ native code.

Huihong
Remotesoft
The Best Protection for .NET Apps

>-----Original Message-----
>My company is in the process of getting ready (well

actually QTR 2 2004) to

>roll out a rewritten version of a vertical market

application for the

>municipal market (small and medium sized cities).

Software protection

>(keeping the honest people honest) hasn't ever been a

problem but in this

>roll out we are going to be distributing the product

through several firms

>in Asia. I would like to find an effective solution that

would limit our

>losses in Asia but also not tick off our customers in

the US. The Asian

>firms I am dealing with have requested using hardware

keys (dongles?) but

>the more I read it seems like they are really despised

and could hurt sales

>here un the US.
>
>Does anyone have some advice or an opinions that could

help a novice at this

>type of stuff? Any help would be greatly

appreciated...! >
>--
>
>Bobby C.
>Proper reply address is without the text -REMOVE-
>
>
>
>.
>

.

[SStory]

The pricing is ridiculous.
If I were a big company maybe.

They need a small shop price that is very reasonable. Say I am starting out
and have a product I hope, "hope" to sell at $50 a copy. It is steep enough
to by vs.net for $600+ upgrade, but then to have to spend $2k more to have
the stupid thing protect the code is ridiculous!

I can't believe that Microsoft ever considered something some dumb and
didn't include a solution for it. Maybe .NET isn't so great. Seems to be
alot more work in many ways and wide open code seems to be like the last
straw.

So what if you can do tons of things, if everyone can steal it easily...!

I agree with the sentiments of Shawn... I have spent days looking for a
better solution--only have having made my app..... Should have made it in
vb6 or even vb5 and wouldn't have had this issue.

Microsoft should cough up an excellent free or darn cheap solution to this
mess they've made.

Shane

"Huihong" <an*******@discussions.microsoft.com> wrote in message
news:d8****************************@phx.gbl...

The total price for all of the 3 products (linker,
obfusactor and protector) is $2388, which can be used by 5
developers with unlimited distribution of the protected
code. Consider this tool is for production use by a
release team in a company, it is reasonable (since the
number of license required will be much fewer than other
regular development tool).

Thanks for the feedback,

Huihong

-----Original Message-----
The pricing isn't reasonable though, for people like me,

hobbyists, who

don't make programs generally as a primary source of

business. Of course,

it might be for someone like the original poster who has

more to loose.

Combine the price of all those products from remotesoft

and ouch ouch ouch.

Not for me, not unless I intend on every making that

money back.

Thanks,
Shawn
"Huihong" <an*******@discussions.microsoft.com> wrote in

message

news:cb****************************@phx.gbl...

http://www.remotesoft.com/salamander/protector.html
http://www.remotesoft.com/linker/index.html

Besides licensing protection, you may also consider
protection against reverse engineering, so people can not decompile your executables.

We offer a series of products to guanrantee that your .NET apps will have at least the same level of protection as
traditional C/C++ executables. It stops decompilation,
rather than just making it a bit more difficult (such as
what obfuscators are doing).

The best stragetegy is link, obfuscate, and then protect. In this way, the final executable contains fewer symbols, and all decompilable MSIL code are replaced with native
x86 code. There is no chance people can still read your
source code.

Here is more info:

(1) salamander .net protector
http://www.remotesoft.com/salamander/protector.html
(2) salamander .net obfuscator,
http://www.remotesoft.com/salamander/obfuscator.html
(3) salamander .net linker,
http://www.remotesoft.com/linker/

To the best of my knowledge, if you using the above 3
products, your app will be secure as good as native C/C++ code, or even better.

Native C/C++ code is considered to be safe against reverse engineering because, to my understanding,

(1) it turns all symbols into memory locations, this is
similiar to what a .NET obfuscator is doing
(2) it has much much fewer entry points, whereas .NET
assemblies expose all classes and methods to the public.
This is, on the other hand, the beauty of the java/.net
platforms, sincee the rich metadata provides many benefits to developers.
(3) native code instructions are register transfer
languages, while .NET IL is strictly stack based. Stack
based instructions are easier to convert into expressions.
These are the main reasons why I think native code is
safe. If we could convert .NET assemblies into similar
format, then it has the same level of protection against
reverse engineering.

Now let me explain how our products try to achieve that,

(1) the obfuscator performs task (1) by converting symbols to meaningless ones, similiar to memory locations

(2) the protector converts IL code into native code, so
the instructions can not be decompiled. I have yet to see a good c/C++ decompiler. None really works.

(3) the linker can be used to link assemblies together,
and thus can be used to remove those public entrypoints.
This performs task (2). The fewer entry points, the better against reverse engineering.

I believe, this gives the best protection as of today, and you can relax with a guarantee that no one will be able to decompile your code, same level of confidence as your old c/c++ native code.

Huihong
Remotesoft
The Best Protection for .NET Apps
>-----Original Message-----
>My company is in the process of getting ready (well
actually QTR 2 2004) to
>roll out a rewritten version of a vertical market
application for the
>municipal market (small and medium sized cities).
Software protection
>(keeping the honest people honest) hasn't ever been a
problem but in this
>roll out we are going to be distributing the product
through several firms
>in Asia. I would like to find an effective solution that would limit our
>losses in Asia but also not tick off our customers in the US. The Asian
>firms I am dealing with have requested using hardware
keys (dongles?) but
>the more I read it seems like they are really despised
and could hurt sales
>here un the US.
>
>Does anyone have some advice or an opinions that could
help a novice at this
>type of stuff? Any help would be greatly appreciated...! >
>--
>
>Bobby C.
>Proper reply address is without the text -REMOVE-
>
>
>
>.
>

.