如果我getenv()
用来禁用我的程序的某些验证(例如许可证检查),黑客是否能够轻松发现相关的环境变量(使用 strace 或其他?)
代码示例:
if (! getenv("my_secret_env_variable")) checkLicense();
(另一方面,如果我检查了特定文件的存在,黑客会立即使用 strace 看到它)
如果我getenv()
用来禁用我的程序的某些验证(例如许可证检查),黑客是否能够轻松发现相关的环境变量(使用 strace 或其他?)
代码示例:
if (! getenv("my_secret_env_variable")) checkLicense();
(另一方面,如果我检查了特定文件的存在,黑客会立即使用 strace 看到它)
让我补充现有的答案,让您对软件保护有更广泛的了解。
黑客不会只使用strace
,他们会使用他们工具箱中的任何工具,但为了增加复杂性,也许只是从大多数情况下最简单的东西开始strings
。我认识的大多数黑客天生就是懒惰的,因此会选择阻力最小的道路。(注意:我所说的黑客是指技术上非常熟练的人,而不是破解者——后者通常具有相同的技能组合,但具有不同的道德规范)。
一般来说,从逆向工程师的角度来看,几乎任何东西都可以“破解”或解决。问题是攻击者有多少时间和/或决心。考虑到一些学生可能只是为了搞笑而这样做,而一些“发布组”这样做是为了在他们的“场景”中成名。
让我们考虑一下硬件加密狗例如。大多数软件作者/公司认为他们在授权某些加密狗时会以某种方式神奇地“购买”安全性。但是,如果他们对系统的实施不小心,那么解决方法就像您的尝试一样简单。即使他们足够小心,通常仍然可以模拟加密狗,尽管提取加密狗上的信息需要一些技巧。一些加密狗(我不会对你隐瞒这个事实)因此是“智能的”,这意味着它们包含一个 CPU 甚至是一个成熟的嵌入式系统。如果软件产品的重要部分在加密狗上执行,并且所有进入加密狗的都是输入,而所有离开加密狗的都是输出,那么这就提供了很好的保护。但是,它在很大程度上同样会惹恼诚实的客户和攻击者。
或者让我们将加密作为另一个例子。许多开发人员似乎没有掌握公共密钥和密钥的概念,并认为将密钥“隐藏”在代码中会使其更安全。好吧,它没有。代码现在包含算法和密钥,这对攻击者来说有多方便?
大多数情况下的普遍问题是,一方面您信任用户(因为您向他们销售产品),但另一方面您不信任他们(因为您试图以某种方式保护您的软件)。当您以这种方式看待它时,您会发现它实际上是多么徒劳。大多数情况下,您会激怒诚实的客户,而只是稍微延迟攻击者(软件保护是二进制的:要么提供保护,要么不提供保护,即它已经被破解)。
相反,请考虑 IDA Pro 的制造商所走的道路。他们在用户获取所有二进制文件之前为其添加水印。然后,如果这些二进制文件被泄露,可以采取法律措施。即使不考虑采取法律措施,他们也可以羞辱(并且已经羞辱)那些公开泄露其产品的人。此外,如果您对泄漏负责,您将不会被出售任何软件升级,IDA 的制造商也不会与您的雇主开展业务。这是保护您的 IDA 副本安全的一个很大的动力。现在,我明白了,IDA 在某种程度上是一种利基产品,但该方法仍然有根本的不同,并且与保护软件的传统尝试没有相同的问题。
另一种选择当然是提供服务而不是软件。所以你可以给用户一个令牌,软件发送到你的服务器。然后,服务器基于解码令牌(我们假设它是加密消息)和检查有效性提供更新(或任何服务)。在这种情况下,用户只会收到令牌,而不会收到解密它的密钥,另一方面,您的服务器必须验证令牌。称其为产品密钥或其他任何名称,人们可以想象出几十种方式。关键是您不会同时陷入信任和不信任用户的矛盾中。您只会不信任用户,例如,如果她的令牌被滥用,您可以将其列入黑名单。
是的。在已编译的二进制文件中很容易发现任何硬编码的字符串。库调用也很容易看到。也可以将二进制文件中的字符串更改为其他内容。
我们也可以LD_PRELOAD
用getenv
函数来显示参数receive
是的 - 容易。他们只是使用字符串来找出要尝试的内容。
黑客会立即用 strace 看到它——也许你也应该看看ltrace
?
虽然您可能无法隐藏变量名称,但为什么不要求一个值呢?特别是,您可以使用整数作为有效值 ( atoi
),因为它们在代码中更难发现,甚至是整数和单个字符的组合。但是请记住,环境块是内存中很容易找到的部分,尤其是在核心转储中。