[原创]KCTF从入门到实战（七）- A long way to go

5天前 562

[原创]KCTF从入门到实战（七）- A long way to go

上集《主动防御》既是存活系列笔记的最后一篇，也是实战系列笔记的第一篇。
所谓存活，是希望能在比赛中胜出。
所谓实战，是希望能够向实际软件保护迈进一步。

在实战商业环境中，软件供应商想保护自己的产品，不受非法盗版，自己能够合理合法地牟取商业利益。
用一个序列号把自己的软件加密起来，不允许未授权者使用该软件，是一种常用手段。
但是实际应用时，供应商不太可能只卖出去一份copy。而一旦卖出去了一份license，就会面临如下问题：
1）买了这个license的使用者，将license转售/转让他人，使得原版供应商的利益受到伤害；
2）买了这个license的使用者，通过分析license的工作机制，找出KeyGen，产生出其它license，然后销售/转让他人。

在上述2种情形下，要想保护原版的利益
1）主要靠“追溯市场上盗版的license”，然后利用法律手段来保护原版的利益。这种方法理论上是可行的，同时也还需要一些技术手段来防止软件摆脱license而独立运行。这件事情，我们以后再讨论。
2）需要尝试在软件中建立起一种保护机制，使得攻击者即便得到了一组（或者多组）合法用户名和序列号，也不能推导出更多用户名和序列号使得软件运行达到相同的结果。这一点，就是现在笔者想挑战的实战场景。

假设攻击者不会去修改软件，如何设计软件保护方案，使得即使攻击者获得了一组（或多组）用户名和序列号，依然不能找出更多组用户名和序列号？（而软件的原版作者却可以生成任意多组用户名和序列号）

（可能有人会迫不及待地来攻击这个条件：“假设攻击者不会去修改软件”，认为这在实战中是不成立的。关于这一点，我们以后再讨论。这里，我们暂且先接受这个条件）

这个问题的答案很简单：IBC
基于IBC算法，原版作者掌握着一个系统私钥。他能够为任意用户名（用户公钥）生成一个序列号（用户私钥），把序列号发给此用户。
用户运行软件时，提供自己的用户名和序列号，软件验证它们之间的对应关系（验证算法是可以公开的），验证成功了才能正常执行后续功能。

对于IBC保护方案，可能的攻击有：
1）攻击者对任意用户公钥，寻找对应的用户私钥。
应对：这个企图会被IBC算法所阻止。没有系统私钥是无法完成这个计算的（详情请问度娘）
2）攻击者跳过验证算法，直接执行后续指令。
应对：前面说了，假设攻击者不修改软件。这里面也包括了：在运行时动态修改IP指针等。总之，我们现在假设攻击者不会干扰软件的执行。
3）攻击者在正常的序列号验证通过之后，在软件正常运行过程中，留下系统快照，将来重现快照，就能在不需要序列号的情况下直接运行软件。
应对：前面说了，假设有技术手段防止攻击者摆脱license而独立运行软件。至于这是一种什么技术手段，我们以后再讨论，OK？

所以，IBC方案是有效的。

但就算是上述所有攻击手段都能被阻止，这种保护方式也不能用于KCTF比赛。因为解题方法中使用到了一个攻击者所不拥有的系统私钥。
所以，为了满足KCTF的规则，以便于与雪友们切磋技术，我们需要另找其它保护方案。

所以，我们的目标是：
在软件不被干扰的情况下，给攻击者若干组用户名和序列号，以引导攻击者了解软件的正确运行路径，然后考验攻击者能否找出新用户名及其对应序列号，以重现正确运行路径。
我们把这种挑战称为：引导模式。

《部落冲突》是对引导模式的第一次尝试。
虽然此题在比赛时间内无人破解，算是存活成功，但是却不算是赢得了引导模式。其原因很简单：此题只能为“狂场”和“你”，这2个用户名提供正确序列号，却不能对任意用户名生成序列号。
ccfer慧眼，早在比赛期间就指出了这个问题，在赛后还公布了一个”水浒版“的crackme，给出了108将的序列号，还指明了”not only 108“，表示还可以设计更多个序列号，显然对此题的序列号设计机制已经完全了解并运用自如了。然而，这种机制必须是在”首先确定了用户名列表“的前提下，才能嵌入各用户名的序列号。要想支持更多的用户名，就必须修改软件。
如果是在软件保护的场景下，往往软件作者难以在发行软件之前就能获得完整的用户名列表。一旦有新的用户前来购买License，那么此方案将迫不得已修改软件。这样不太合理。
因此，我们进一步规范了一下挑战规则。

为证明防守方有能力在软件CM确定之后，对任意用户名生成序列号，防守方在发布CM时，应公布一组”以CM的hash值为用户名“的序列号。然后，考验攻击方是否能找出KeyGen算法。

其中，hash值的生成算法应是国际公开安全摘要算法。例如：SHA3-512
用户名可以取hash结果的前缀部分，但最短不应少于64bit。
如果CM不止一个文件的话，计算hash时应包含CM的所有文件（第三方共享库除外）。
参考hash计算工具：http://www.atool9.com/file_hash.php

判胜条件

1）若攻击方找出特定用户名（KCTF2019Q4）的序列号，将认定攻击方获胜；
2）若攻击方找出任何一组其它用户名及序列号，将认定攻击方获胜，但不算此题多解。（原KCTF系统并不支持这种验证模式，技术上如何实现？需要请大家提讨论）
3）若攻击方找出任何一个用户名的第二个序列号，将认定攻击方获胜，且此题多解；

规则限制

1）保留KCTF大部分原有限制

1.1）干净环境中，10秒内出提示且不能虚假提示；
1.2）KeyGen算法不能基于“未在CM中公开的秘密信息”。如果需要穷举，则穷举时间必须小于5分钟；
1.3）不能依赖网络、不能依赖硬件；
1.4）禁止使用第三方保护工具、禁止恶意破坏机器；
1.5）不超过1M；
1.6）同一用户名不应有多个序列号，否则罚分。

2）放宽技术手段限制

2.1）不限制使用套娃。可以使用任何数据和代码变换；
2.2）不限制线索隐藏方式。可以将线索以任何形式置于CM的任何位置。

[公告]LV6级以上的看雪会员可以免费获得《2019安全开发者峰会》门票一张！！

最后于 4小时前 被看场雪编辑 ，原因： 进一步明晰“判胜条件”和“规则限制”