-
-
使用壳sdk来保护程序[推荐]
-
发表于: 2006-1-12 13:28
-
作者：又见春风[359235708]
一般我们自己写程序时，为了方便起见，都是在自己的程序完成后再使用aspack、upx、asprotect等压缩壳或者加密壳程序来进行程序的加密和保护，这样在一定程度上增加了自己的程序的防破解能力。但这样有个问题，普通常见的壳因为被高手们研究得很透，破解教程也大量发表，所以，采用这种方式加密保护自己的程序，完全取决于所采用的壳程序的强度了。当然也有牛人自己开发了一些私人壳来保护自己的程序。但那是极少数的人才行的。
我们没有能力自己写壳，那该怎么办呢？
为了解决这个问题，即：既要提高程序的防破解能力，又要尽量降低自己写壳带来的技术问题，一些加密壳程序引入了sdk的概念来帮助我们既能快速增强程序的防破解能力，又能大大降低自己写壳程序带来的技术问题。简单地说，使用sdk方式编写程序，可以在单纯外壳加密保护的基础上提升程序的防破解能力，这种方式写的程序的加密强度比单纯的外壳加密程序的强度要高许多。
常见带有sdk的加密壳有如下一些：ACProtector，asprotoct，epe等。
各种加密壳的sdk的使用方式类似，都是在自己的源代码中需要加密和保护的地方按照壳sdk提供的使用方式加入壳提供的inc语句，形成某些固定标记，从而可以加密壳在对程序进行外壳加密处理时能将这些标记之间的语句进行某种处理，比如动态加密和解密语句，变换某些代码段等。
下面以acprotector1.41（下面简称acp）为例来介绍如何在自己的程序中利用sdk来保护程序。安装acprotector1.41后，安装目录如下图示：
其中的example就是acp带的sdk的范例，其中有acp带有的delphi和vc两种编程语言中利用sdk编程的范例和sdk函数包。
如图是acp中delphi的sdk编程范例和sdk函数包。在vc中也是如此两个目录。下面就一起来看看delphi的sdk范例。Vc的自己参考范例。
先来看include文件夹中的文件，不要改动这个里边的任何文件。
看到命名规则没有？begin和end，前面的相同，两两配对哦，估计每两个文件是配对实现某种保护的。Critic_begin.inc和critic_end.inc实现动态代码加密；protect_begin.inc和protect_end.inc实现内嵌代码保护；regonly_begin.inc和regonly_end.inc实现rsa密码锁定保护功能。我们打开其中的critic_begin.inc和critic_end.inc看看
看到没有？里边就是嵌入汇编语句，没有其他什么内容。原来壳的sdk的作用就是在程序中插入某些特殊标记，然后加壳处理时壳程序能对加了这些标记的代码段进行相关处理。巧妙吧？这样就轻松实现了比单纯外壳加密保护更高的保护强度，大大降低了我们编程的难度。而且每种sdk函数不仅能单独使用，也可以在程序中混合并且嵌套使用。
具体看一个范例吧。
打开example下的范例，这个acp提供了每种sdk函数的单独使用范例和综合使用范例。我们就只介绍一个范例吧，其他的范例可以自己仔细研究的。
我们就以damynic code protect这个范例来解释一下如何利用sdk编程并进行程序保护。
看名字就知道这个范例是介绍代码动态加密解密的sdk使用范例。
先看看程序源代码。如下：
procedure TForm1.Button1Click(Sender: TObject);
begin
//example of dynamic code lock
//the code between the dynamic lock begin and end flag will be crypted,when running,the code will be decrypted first,then run,after the running ,
//it will be encrypted again to prevent dumpping and static analysis.
{$I ..\..\include\critic_begin.inc} //dynamic lock begin
showmessage('dynamic lock code example:'+char($0d)+char($0a)+'first decrypt this code,then run ,it will be encrypted again after run!');
{$I ..\..\include\critic_end.inc} //dynamic lock end
end;
注意：这个程序代码就只在原来的程序中加入了sdk函数文件的配对引用。{$I ..\..\include\critic_begin.inc}是表示从这里开始进行代码动态加密和解密，{$I ..\..\include\critic_end.inc}是表示代码动态加密和解密到此结束，下面的代码不用动态加密和解密了。里边是sdk函数文件的位置，范例中这个delphi的代码和sdk分别在不同的文件夹里，所以加入了引用路径。一般可以将sdk文件放在delphi程序源码文件夹里，引用就不用路径了。在源码编译后运行时，每次sdk函数引用配对之间的程序将随机加密和解密，即每次代码在内存中的状态、地址和值都是不确定的，这样就增加了破解的难度。
但只是这样处理后的源码编译后的程序没有经过外壳程序的处理，在运行时是没有代码动态加密和解密的过程的，和没加sdk的情况一样。要想这个sdk生效，必须要经过外壳加密处理，处理过程和普通程序的加密处理操作一样，不带来额外的学习和操作成本。
我们来一起看看如何进行外壳加密处理吧。作为对比，我先屏蔽掉sdk的引用。编译一个文件，命名为project1（no sdk）.exe，然后加上sdk引用，编译文件后命名为project1（with sdk）.exe。看看acp是如何在加壳时对加入的sdk标记进行处理的。
先用acp载入project1（no sdk）.exe，看看没有sdk的情况下acp的工作状态，如图：
在acp中处理sdk的地方就是在“特色分析”里进行标记处理，看下图：
目前还没对程序进行处理，外壳程序不知道我们是否引用了sdk中的函数进行特色处理。点击“分析”按钮，如图：
看来外壳程序分析到了我们没有引用sdk函数，所以加壳时就不会进行我们期望的特殊加密处理。这样加壳后的程序就是单纯的外壳加密保护。
我们来看看在“保护”选项里进行程序加壳处理的提示信息：
保护开始
程序压缩....................................................OK
Compress: 282Kb/376Kb (93Kb saved) Ratio:75%
保护完成
再来看我们引用了sdk的函数的程序在acp中是如何进行特殊处理的。
同样在特色分析里分析我们的程序是否采用了sdk函数。
看到没有，我们的程序里引用了动态加密解密函数，这里被外壳程序分析到了，看看他最后处理时能不能对此进行相应处理呢？
到“保护”选项里，进行程序加壳处理，注意看提示信息。如下所示：
保护开始
代码动态加密保护............................................OK
程序压缩....................................................OK
Compress: 283Kb/377Kb (93Kb saved) Ratio:75%
保护完成
对比两种情况下的提示信息，引用sdk进行了动态代码加密保护的程序在用外壳程序处理时，外壳程序自动对加了sdk函数的代码段内的代码进行了相关处理。这时的程序在运行时那个sdk代码动态加密函数段内的代码将是动态加密和解密的。每次运行在内存中的状态和数据都是动态生成的。破解这个程序就比不加sdk函数的程序难得多了。
总结：使用sdk来保护自己的程序，只是在源程序中适当的位置加入固定的sdk函数对，然后经过外壳程序处理，就能在不增加自己编写代码难度的情况下，借助外壳程序轻易实现程序防破解能力的大幅度提升。因此我们可以在自己的程序中合适的位置加入sdk，轻松实现程序防破解能力的大幅度提升。
这就是sdk的力量。但愿大家都采用这种方法来保护自己的程序。
BTW：个人使用体验后，觉得acp的sdk对于程序员的技术要求最简单，容易上手和实现。而且sdk处理后的程序强度也非常高，兼容性也最好。建议大家都采用。Epe的sdk强度比不含sdk的程序是提升不少，但epe的程序报病毒情况严重。Aspr的sdk使用上比较麻烦，但强度更高。可以多花时间来研究使用。其他的没有体验，不好评价，有待于大家自己去体验。
朋友写给我的，发给大家共同学习
一般我们自己写程序时，为了方便起见，都是在自己的程序完成后再使用aspack、upx、asprotect等压缩壳或者加密壳程序来进行程序的加密和保护，这样在一定程度上增加了自己的程序的防破解能力。但这样有个问题，普通常见的壳因为被高手们研究得很透，破解教程也大量发表，所以，采用这种方式加密保护自己的程序，完全取决于所采用的壳程序的强度了。当然也有牛人自己开发了一些私人壳来保护自己的程序。但那是极少数的人才行的。
我们没有能力自己写壳，那该怎么办呢？
为了解决这个问题，即：既要提高程序的防破解能力，又要尽量降低自己写壳带来的技术问题，一些加密壳程序引入了sdk的概念来帮助我们既能快速增强程序的防破解能力，又能大大降低自己写壳程序带来的技术问题。简单地说，使用sdk方式编写程序，可以在单纯外壳加密保护的基础上提升程序的防破解能力，这种方式写的程序的加密强度比单纯的外壳加密程序的强度要高许多。
常见带有sdk的加密壳有如下一些：ACProtector，asprotoct，epe等。
各种加密壳的sdk的使用方式类似，都是在自己的源代码中需要加密和保护的地方按照壳sdk提供的使用方式加入壳提供的inc语句，形成某些固定标记，从而可以加密壳在对程序进行外壳加密处理时能将这些标记之间的语句进行某种处理，比如动态加密和解密语句，变换某些代码段等。
下面以acprotector1.41（下面简称acp）为例来介绍如何在自己的程序中利用sdk来保护程序。安装acprotector1.41后，安装目录如下图示：
其中的example就是acp带的sdk的范例，其中有acp带有的delphi和vc两种编程语言中利用sdk编程的范例和sdk函数包。
如图是acp中delphi的sdk编程范例和sdk函数包。在vc中也是如此两个目录。下面就一起来看看delphi的sdk范例。Vc的自己参考范例。
先来看include文件夹中的文件，不要改动这个里边的任何文件。
看到命名规则没有？begin和end，前面的相同，两两配对哦，估计每两个文件是配对实现某种保护的。Critic_begin.inc和critic_end.inc实现动态代码加密；protect_begin.inc和protect_end.inc实现内嵌代码保护；regonly_begin.inc和regonly_end.inc实现rsa密码锁定保护功能。我们打开其中的critic_begin.inc和critic_end.inc看看
看到没有？里边就是嵌入汇编语句，没有其他什么内容。原来壳的sdk的作用就是在程序中插入某些特殊标记，然后加壳处理时壳程序能对加了这些标记的代码段进行相关处理。巧妙吧？这样就轻松实现了比单纯外壳加密保护更高的保护强度，大大降低了我们编程的难度。而且每种sdk函数不仅能单独使用，也可以在程序中混合并且嵌套使用。
具体看一个范例吧。
打开example下的范例，这个acp提供了每种sdk函数的单独使用范例和综合使用范例。我们就只介绍一个范例吧，其他的范例可以自己仔细研究的。
我们就以damynic code protect这个范例来解释一下如何利用sdk编程并进行程序保护。
看名字就知道这个范例是介绍代码动态加密解密的sdk使用范例。
先看看程序源代码。如下：
procedure TForm1.Button1Click(Sender: TObject);
begin
//example of dynamic code lock
//the code between the dynamic lock begin and end flag will be crypted,when running,the code will be decrypted first,then run,after the running ,
//it will be encrypted again to prevent dumpping and static analysis.
{$I ..\..\include\critic_begin.inc} //dynamic lock begin
showmessage('dynamic lock code example:'+char($0d)+char($0a)+'first decrypt this code,then run ,it will be encrypted again after run!');
{$I ..\..\include\critic_end.inc} //dynamic lock end
end;
注意：这个程序代码就只在原来的程序中加入了sdk函数文件的配对引用。{$I ..\..\include\critic_begin.inc}是表示从这里开始进行代码动态加密和解密，{$I ..\..\include\critic_end.inc}是表示代码动态加密和解密到此结束，下面的代码不用动态加密和解密了。里边是sdk函数文件的位置，范例中这个delphi的代码和sdk分别在不同的文件夹里，所以加入了引用路径。一般可以将sdk文件放在delphi程序源码文件夹里，引用就不用路径了。在源码编译后运行时，每次sdk函数引用配对之间的程序将随机加密和解密，即每次代码在内存中的状态、地址和值都是不确定的，这样就增加了破解的难度。
但只是这样处理后的源码编译后的程序没有经过外壳程序的处理，在运行时是没有代码动态加密和解密的过程的，和没加sdk的情况一样。要想这个sdk生效，必须要经过外壳加密处理，处理过程和普通程序的加密处理操作一样，不带来额外的学习和操作成本。
我们来一起看看如何进行外壳加密处理吧。作为对比，我先屏蔽掉sdk的引用。编译一个文件，命名为project1（no sdk）.exe，然后加上sdk引用，编译文件后命名为project1（with sdk）.exe。看看acp是如何在加壳时对加入的sdk标记进行处理的。
先用acp载入project1（no sdk）.exe，看看没有sdk的情况下acp的工作状态，如图：
在acp中处理sdk的地方就是在“特色分析”里进行标记处理，看下图：
目前还没对程序进行处理，外壳程序不知道我们是否引用了sdk中的函数进行特色处理。点击“分析”按钮，如图：
看来外壳程序分析到了我们没有引用sdk函数，所以加壳时就不会进行我们期望的特殊加密处理。这样加壳后的程序就是单纯的外壳加密保护。
我们来看看在“保护”选项里进行程序加壳处理的提示信息：
保护开始
程序压缩....................................................OK
Compress: 282Kb/376Kb (93Kb saved) Ratio:75%
保护完成
再来看我们引用了sdk的函数的程序在acp中是如何进行特殊处理的。
同样在特色分析里分析我们的程序是否采用了sdk函数。
看到没有，我们的程序里引用了动态加密解密函数，这里被外壳程序分析到了，看看他最后处理时能不能对此进行相应处理呢？
到“保护”选项里，进行程序加壳处理，注意看提示信息。如下所示：
保护开始
代码动态加密保护............................................OK
程序压缩....................................................OK
Compress: 283Kb/377Kb (93Kb saved) Ratio:75%
保护完成
对比两种情况下的提示信息，引用sdk进行了动态代码加密保护的程序在用外壳程序处理时，外壳程序自动对加了sdk函数的代码段内的代码进行了相关处理。这时的程序在运行时那个sdk代码动态加密函数段内的代码将是动态加密和解密的。每次运行在内存中的状态和数据都是动态生成的。破解这个程序就比不加sdk函数的程序难得多了。
总结：使用sdk来保护自己的程序，只是在源程序中适当的位置加入固定的sdk函数对，然后经过外壳程序处理，就能在不增加自己编写代码难度的情况下，借助外壳程序轻易实现程序防破解能力的大幅度提升。因此我们可以在自己的程序中合适的位置加入sdk，轻松实现程序防破解能力的大幅度提升。
这就是sdk的力量。但愿大家都采用这种方法来保护自己的程序。
BTW：个人使用体验后，觉得acp的sdk对于程序员的技术要求最简单，容易上手和实现。而且sdk处理后的程序强度也非常高，兼容性也最好。建议大家都采用。Epe的sdk强度比不含sdk的程序是提升不少，但epe的程序报病毒情况严重。Aspr的sdk使用上比较麻烦，但强度更高。可以多花时间来研究使用。其他的没有体验，不好评价，有待于大家自己去体验。
朋友写给我的，发给大家共同学习
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
