软件保护和许可问题 [英] software protection and licensing question

查看:72
本文介绍了软件保护和许可问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在查看可用于

软件保护的各种软件包。我有一个特别的问题,我会欢迎您的反馈。


背景信息:

我为一个工作开发软件的公司,通常会发布

软件SDK。使用MS Visual C ++进行C ++开发。我们需要

应用软件加密/保护来实现:


1)限时版本(例如软件在X天后过期)

2)机器锁定(一旦输入激活密钥,软件只会在安装它的机器上运行


3)反调试/反向 - 工程保护


我们一直在使用PCGuard,它可以涵盖所有这些方面。但是,

由于我们的软件是作为SDK发布的
,我们遇到了一个特殊的问题。


第三方使用我们的SDK的开发人员使用

提供的dll访问核心功能,并且它是需要保护的DLL。我们不希望
希望他们能够调试我们提供的dll,但是我们*希望他们需要他们

才能调试他们编写的代码!


PCGuard采用的加密/反调试意味着它们无法调试自己的代码,这是一个主要问题。


我的问题是:是否可以(使用另一个套餐)申请

保护,涵盖上述所有3个方面但仍然允许第三方

使用我们的SDK调试自己代码的开发人员?


我的感觉是保护选项1 + 2(限时版本,

机器锁定)可以在不阻止调试

第三方代码的情况下实现,但我不确定保护选项3是否也可以包含
而不会阻止所有调试。


任何关于此的想法或信息都非常感谢。关于

各种保护套餐的优缺点的评论也欢迎!


(请回复新闻组*不*通过电子邮件发送)


非常感谢,


Howard Wright

I am currently looking at the various packages that are available for
software protection. I have a particular question that I''d welcome
your feedback on.

Background info:
I work for a company that develops software, and typically releases
software SDKs. Development is in C++ using MS Visual C++. We need to
apply software encryption/protection to achieve:

1) Time-limited versions (e.g software expires after X days)
2) Machine-locking (once activation key entered, software will only
run on the machine it was installed on)
3) Anti-debugging/reverse-engineering protection

We had been using PCGuard, which can cover all these aspects. However,
we have a particular problem due to the fact that our software is
released as an SDK.

3rd party developers using our SDKs access the core functions using a
supplied dll, and it is the dll which needs to be protected. We do not
want them to be able to debug the dll we supply, but we *do* want them
to be able to debug the code that they write!

The encryption/anti-debugging employed by PCGuard means that they are
not able to debug their own code, which is a major problem.

My question is: is it possible (using another package) to apply
protection which covers all 3 aspects above yet still allows 3rd-party
developers who use our SDK to debug their own code?

My feeling is that protection options 1+2 (time limited versions,
machine locking) can be achieved without blocking the debugging of
3rd-party code, but I''m not sure if protection option 3 can also be
included without blocking all debugging.

Any thoughts or info on this greatly appreciated. Comments on the
pros/cons of the various protection packages available also welcome!

(please post replies to newsgroup *not* via email)

many thanks,

Howard Wright

推荐答案



2004年1月9日星期五,Howard写道:

On Fri, 9 Jan 2004, Howard wrote:

我目前正在查看可用于软件保护的各种软件包。我有一个特别的问题,我会欢迎您的反馈意见。


您的问题与C ++语言无关,并且在comp.lang.c ++中是关于主题的


我们需要应用软件加密/保护来实现:

1)限时版本(例如软件在X天后过期)


由控制系统时钟的用户琐碎地规避

(与大多数Microsoft OS用户一样)。

2)机器锁定(一旦输入激活密钥,软件将只
在安装它的机器上运行)


由控制硬件的用户琐事规避

(遗憾的是很少有用户,IME ,特别是在

台式机大众市场中。

3)反调试/逆向工程保护


琐事规避由具有读取访问权限的用户(例如,Microsoft操作系统上的大多数用户,以及管理员或

)支持该类型的操作系统的道德等效物的用户的事) 。


使用我们的SDK的第三方开发人员使用
提供的dll访问核心功能,这是需要保护的DLL。我们不希望他们能够调试我们提供的DLL,但我们*希望他们能够调试他们编写的代码!


上帝保佑任何人都应该尝试调试*你的* DLL!调试是魔鬼的工作,应该不惜一切代价进行调整。

PCGuard采用的加密/反调试意味着他们无法进行调试自己的代码,这是一个主要问题。


是的,我可以看到。但是你确定程序员无法调试他们自己的代码源于他们使用PCGuard,

或者这是一个更根深蒂固的问题,也许是因为缺乏

教育或实践?我知道有些人无法调试他们自己的代码,他们甚至不会*使用* PCGuard。

我的问题是:是否有可能(使用另一个软件包)应用
保护,涵盖上述所有3个方面,但仍然允许使用我们的SDK的第三方开发人员调试他们自己的代码?


一份好的许可协议会有所帮助。例如,你可以

插入一个基本上说的条款,除非得到许可,否则你不应该尝试对这个DLL的内容进行反向工程。 >
由其创作者提供。这将使所有遵纪守法的入侵者保持原样。然后你甚至可以压缩或加密代码,从而保持不那么持久的调试器



这应该足够了 - 你永远不会停止执着,

智能调试员,无论如何都不关心法律。 CPU

知道代码的作用,程序员可以和CPU通信。

这就是总结一下,不是吗?


我的感觉是保护选项1 + 2(限时版本,机器锁定)可以实现而不会阻止第三方代码的调试,但我''我不确定是否也可以包含保护选项3而不阻止所有调试。

I am currently looking at the various packages that are available for
software protection. I have a particular question that I''d welcome
your feedback on.
Your question has nothing to do with the C++ language, and is
off-topic in comp.lang.c++.

We need to apply software encryption/protection to achieve:

1) Time-limited versions (e.g software expires after X days)
Trivially circumvented by a user who controls the system clock
(as most Microsoft OS users do).
2) Machine-locking (once activation key entered, software will only
run on the machine it was installed on)
Trivially circumvented by a user who controls his hardware
(which unfortunately very few users do, IME, especially in the
desktop mass-market).
3) Anti-debugging/reverse-engineering protection
Trivially circumvented by a user who has read access to the code
in question (e.g., most users on Microsoft OSes, and admins or
the moral equivalent thereof on OSes that support that kind of thing).

3rd party developers using our SDKs access the core functions using a
supplied dll, and it is the dll which needs to be protected. We do not
want them to be able to debug the dll we supply, but we *do* want them
to be able to debug the code that they write!
God forbid anyone should try to debug *your* DLL! Debugging is
the work of the devil and should be prevented at all costs.
The encryption/anti-debugging employed by PCGuard means that they are
not able to debug their own code, which is a major problem.
Yes, I can see that. But are you sure that the programmers''
inability to debug their own code stems from their use of PCGuard,
or is it a more deeply-rooted problem, perhaps due to lack of
education or practice? I know a few people who can''t debug their
own code, and they don''t even *use* PCGuard.
My question is: is it possible (using another package) to apply
protection which covers all 3 aspects above yet still allows 3rd-party
developers who use our SDK to debug their own code?
A good license agreement would help. For example, you could
insert a clause that said essentially, "Thou shalt not attempt to
reverse-engineer the contents of this DLL, unless given permission
by the creators thereof." That would keep all law-abiding intruders
out. Then you could even compress or encrypt the code, thus keeping
out the less-persistent debuggers.
That should be enough -- you''re never going to stop the persistent,
intelligent debuggers who don''t care about laws, anyway. The CPU
knows what the code does, and the programmer can talk to the CPU.
That just about sums it up, doesn''t it?

My feeling is that protection options 1+2 (time limited versions,
machine locking) can be achieved without blocking the debugging of
3rd-party code, but I''m not sure if protection option 3 can also be
included without blocking all debugging.




如果您允许程序员,我认为这将是一个很好的姿态br />
来查找代码中的错误以及他自己的错误。当然它会让你的生活变得简单得多。


-Arthur



I think it would be a nice gesture if you allowed the programmer
to find bugs in your code, as well as in his own. Certainly it
would make your life a hell of a lot simpler.

-Arthur

在文章< 5c ************************** @ posting.google.com> ;, 做******************* ***@hotmail.com (Howard)写道:
In article <5c**************************@posting.google.com >, do**********************@hotmail.com (Howard) wrote:
我目前正在查看可用于软件保护的各种软件包。我有一个特别的问题,我会欢迎您的反馈意见。

背景信息:
我在一家开发软件的公司工作,通常会发布
软件SDK。使用MS Visual C ++进行C ++开发。我们需要应用软件加密/保护来实现:

1)限时版本(例如软件在X天后过期)
2)机器锁定(一次激活密钥)输入后,软件只会在安装的机器上运行。
3)反调试/逆向工程保护


我建议你带一个从
www.siliconrealms.com 查看Armadillo。我知道它有一些与

调试和DLL有关的限制,但我怀疑它可以适当配置。您可以下载试用版并查看它。

使用我们的SDK的第三方开发人员使用
提供的dll访问核心功能,它是需要保护的DLL。我们不希望他们能够调试我们提供的DLL,但是我们*希望他们能够调试他们编写的代码!

PCGuard采用的加密/反调试意味着他们无法调试自己的代码,这是一个主要问题。
I am currently looking at the various packages that are available for
software protection. I have a particular question that I''d welcome
your feedback on.

Background info:
I work for a company that develops software, and typically releases
software SDKs. Development is in C++ using MS Visual C++. We need to
apply software encryption/protection to achieve:

1) Time-limited versions (e.g software expires after X days)
2) Machine-locking (once activation key entered, software will only
run on the machine it was installed on)
3) Anti-debugging/reverse-engineering protection
I would recommend you take a look at Armadillo from
www.siliconrealms.com . I know it has some restrictions relating to
debugging and DLLs, but I suspect it can be configured suitably. You
can download a trial version and check it out.
3rd party developers using our SDKs access the core functions using a
supplied dll, and it is the dll which needs to be protected. We do not
want them to be able to debug the dll we supply, but we *do* want them
to be able to debug the code that they write!

The encryption/anti-debugging employed by PCGuard means that they are
not able to debug their own code, which is a major problem.




如果一切都失败了,您可能考虑的另一种选择是发出两个独立的DLL,具有相同的一般功能。一个是可分发的DLL,受保护但不可调试的

。另一个是可调试的,但会有不良行为阻止它在分布式程序中使用
。当然,必须小心使用

才能使其难以破解。


- Gerry Quinn



在文章< Tz **************** @ news.indigo.ie>中, ge **** @ indigo.ie 说...
In article <Tz****************@news.indigo.ie>, ge****@indigo.ie says...
如果其他所有方法都失败了,您可以考虑另一种选择发布两个独立的DLL,具有相同的通用功能。一个是可分发的DLL,受保护但不可调试。另一个是可调试的,但会有不良行为阻止它在分布式程序中使用。当然,必须注意使其难以破解。
If all else fails, an alternative option you might consider is to issue
two separate DLLs, with the same general functionality. One would be
the distributable DLL, protected but not debuggable. The other would be
debuggable, but would have undesirable behaviours that prevent it being
used in a distributed program. Of course, care would have to be taken
to make this hard to crack.




为什么要调试不是客户所需的代码是

使用?你假设行为的变化(未指明)将不会影响错误,比赛或添加新的错误或掩盖

生产DLL中的错误。


-

兰迪霍华德

2只是删除FOOBAR



Why would you want to debug code that is NOT what your customer will be
using? You''re assuming that the changes in behavior (unspecified) will
not impact bugs, races, or add new bugs or mask off those in the
production DLL.

--
Randy Howard
2reply remove FOOBAR


这篇关于软件保护和许可问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆