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