编写安全的 Cocoa 代码
我在 cocoa 中制作了一个应用程序，想看看其中的某些字符串是否可以轻松访问，所以我在它上面运行了 OTX，遗憾的是我的所有代码都被发现了。有没有一种方法可以使我的代码更加“安全”或至少加密/隐藏字符串？我想加密该字符串的原因是它是服务器的密码。我不需要它非常安全，我只是不希望密码那么容易找到。
感谢您的帮助
Im making an application in cocoa and wanted to see if some strings in it were easily accessible so I ran OTX on it and sadly all of my code was found. Is there a method I can use to make my code more "secure" or at least encrypt/hide the strings? The reason I want to encrypt the string is it's a password for a server. I don'd need it really secure I just don't want the password to be so easy to find.
Thanks for any help
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不应该永远将密码放入可执行文件中。
这就像将密码放在显示器旁边的便利贴上一样。如果恶意黑客拥有您的应用程序，无论您使用什么语言或 API 编写密码，他们最终都可以提取密码。
例如，如果我知道您的应用程序连接到受密码保护的服务器，但该应用程序从不要求输入密码，那么我就知道您犯了包含密码的错误。为了找到密码，我只需要监视程序的运行，看看在它连接到服务器时哪些代码区域是活动的。这将告诉我在哪里集中搜索密码，无论您的应用程序有多大。那么我找到密码只是时间问题。加密密码没有什么好处，因为加密算法也必须在应用程序中，我也可以解开它。
请记住，有很多人可以仅使用原始机器代码来解析您的代码。对于这些人来说，使用什么语言或 API 并不重要，因为它们最终都会提取为机器代码。这些人是可怕的、熟练的编程之神，他们嘲笑像你我这样的凡人。不幸的是，他们中的一些人是邪恶的。
我是否提到过您永远不要将密码放入可执行文件中？如果没有，请允许我重复一遍，您永远不要将密码放入可执行文件中。
在您的特定情况下，作为新手程序员，您不可能向比您更有经验的人隐藏密码。这是您永远不要将密码放入可执行文件的另一个很好的理由。
You should never put a password into an executable.
This is like putting the password on a sticky note next to the monitor. If a malicious hacker has your application they can eventually extract the password regardless of what language or API you use to write it.
For example, if I know that your application connects to a password protected server but the application never ask for a password, then I know you've made the mistake of including the password. To find the password, I need only monitor the operation of the program to see what areas of code are active around the time it connects to the server. This will tell me where to focus the search for the password regardless of how big your application is. Then it is only a matter of time until I track the password down. Encrypting the password does no good because the encryption algorithm must also be in the app and I can unravel that as well.
Remember that there are many people out there who can unravel your code using only the raw machine code. For those people it doesn't matter what language or API you use because they all distill to machine code in the end. Those people are the scary skilled gods of programming and they laugh at mere mortals such as you or I. Unfortunately, some of them are evil.
Did I mention that you should never put a password into an executable? If I didn't, let me repeat that you should never put a password into an executable.
In your particular case, as novice programmer, you have no hope of hiding of the password from someone with even a little bit more experience than yourself. This is yet another good reason why you should never put a password into an executable.
1.避免在安全代码中使用 ObjC。
由于 ObjC 的类系统严重依赖于运行时反射，因此整个接口需要与可执行文件一起包含在内。这使得像 class-dump 这样的工具可以轻松恢复二进制文件的源@interface。
因此，安全代码函数应编写为 C 函数，而不是 ObjC 方法。
2.使用
strip。默认情况下，编译器将保留所有私有符号（这使得堆栈跟踪更具可读性）。您可以使用
strip删除所有这些符号。3.混淆。
以上步骤只能隐藏代码逻辑。但如果密码是常量字符串，则可以使用
strings实用程序立即看到它。您可以通过在运行时构建密码来混淆它（例如，将 ROT-13 编码的密码存储在文件中。）4。或者只是改变你的设计。
无论你的保护系统有多好，因为黑客完全控制他们的机器，只要有足够的时间，他们总是会赢。最好修改一下你的设计，比如为什么密码必须与可执行文件一起提供？或者为什么需要全局密码？
1. Avoid ObjC in secure code.
Because ObjC's class system depends heavily on runtime reflection, the whole interface needs to be included alongside the executable. This allows tools like
class-dumpto easily recover the source @interface of the binary.Therefore, the secure code functions should be written as a C function, not an ObjC method.
2. Use
strip.By default the compiler will keep all the private symbols (which allows stack trace to be more readable). You can use
stripto delete all these symbols.3. Obfuscation.
The above steps can only hide the code logic. But if the password is a constant string, it is immediately visible using the
stringsutility. You may obfuscate this by constructing the password in runtime (e.g. store the password encoded in ROT-13 in the file.)4. Or just change your design.
No matter how good your protection system is, as the hacker have total control on their machine, given enough time, they always win. It's better to revise your design, like why the password must come with the executable? Or why a global password even needed?