如何在 Flash 或 Java 中隐藏 salt 代码？
我需要能够将数据从 Flash 浏览器应用程序传输到 Web 服务器上的 PHP 文件，保护和验证数据，同时尝试防止未经授权创建消息。 （我想尝试确保消息来自应用程序，而不是用户通过其他方式发送消息）。
在 C++ 应用程序中，我会对数据加盐，并随其发送数据的哈希值，然后根据数据验证哈希值以确保完整性和来源。
然而，在Flash（和Java）中，应用程序可以被反编译，以便可以查看源代码。因此，如果我使用这种方法，有人可以（相对）轻松地找到盐，然后创建自己的“有效”消息以发送到应用程序外部。
有什么方法可以“隐藏”这个盐代码以帮助保护传输？是的，我知道有代码混淆器，但它们并没有完全隐藏代码，只是添加另一层。
或者是否有另一种完全可以用来传输数据并验证源和数据的方法？ PHP 端的内容？
I need to be able to transmit data from a Flash browser application to a PHP file on a web server, both securing and validating the data whilst and at the same time trying to prevent unauthorised creation of the message. (I want to try and ensure that the message comes from the application, not a user sending a message via another means).
In a C++ application I would Salt the data, and send the hash of the data along with it, and then validate the hash against the data to ensure integrity and source.
However, in Flash (& Java), applications can be decompiled so that the source code is viewable. So if I used this method, someone could (relatively) easily find the salt, and then create a 'valid' message of their own to send outside of the application.
Is there any way I can 'hide' this salt code to help secure the transmission? Yes, I know there are code obfuscators, but they don't fully hide the code, just add another layer.
Or is there another method entirely that could be used to transmit data and validate the source & content at the PHP end?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
无论你做什么，执行它的代码都会在客户端中，你所能做的就是混淆。正如 Tomasz 所说，如果您要让客户端通过服务器进行身份验证，然后接收盐（或来自非对称密钥对的密钥），您仍然需要在客户端中拥有连接到该服务器所需的所有代码。因此，根据设计，无论您做什么，执行此操作的所有要素都必须位于客户端中，因此也位于您的“黑客”计算机上。这只是黑客理解它的难度要大得多的问题。
对于所有类型的客户端来说都是一样的，无论它们是用什么语言编写的。如果 DVD 播放器可以在电视上显示解密的 DVD 光盘，则它必须在内存中拥有解密密钥，您可以找到该密钥。这就是为什么没有人做出完美的复制保护:)
编辑：
正如其他人所说。现成的混淆器可能是最好的方法，你也可以让客户端先跳过一些额外的障碍。
编辑2：
事实证明我没有正确理解托马斯。如果用户本身拥有向服务器进行身份验证以获取哈希值的密钥，那么确实会验证该消息是从用户发送的，但仍然不是从应用程序发送的。如果这是为了避免作弊，那么黑客可能已经是客户（购买产品或创建帐户）。如果您想要的是对用户进行身份验证，那么这是完全不同的事情，而且这是很有可能的。 （当然也有它自己的问题）
No matter what you do, the code to do it will be there in the client, and all you can do is obfuscate. If you, as Tomasz says, were to have the client authenticate with the server and then receive a salt (or a key from a asymmetric key-pair) you still need to have all the code necessary to connect to that server in the client. So by design, no matter what you do, all the ingredients to do so has to be in the client, and thus on your "hackers" computer. It's just a question of much harder it would be for a hacker to understand it.
It's the same for all kinds of clients, no matter what language they're written in. If a DVD player can show a decrypted DVD disc on your TV, it has to have the key to decrypt it in memory, which you can find. This is why no-one has made perfect copy-protection :)
EDIT:
As all the others are saying. Off-the-shelf obfuscator is probably the best way to go, and you could make the client jump through some extra hoops first aswell.
EDIT2:
Turns out I didn't understand Tomasz correctly. If the user himself has the key to authenticate to the server in order to get the hash, that will indeed authenticate that the message was sent from the user, but still not from the application. If this is a matter of avoiding cheating then the hacker is probably already a customer (buying a product or making an account). If what you want is to authenticate the user, then it's a completely different matter, and that is quite possible. (with it's own problems of-course)
没有真正安全的方法来保护在客户端上运行的程序。 （顺便说一下，C++ 也可以反编译。）用户总是有可能运行被黑客攻击的客户端，并且任何加密密钥都必须以某种形式出现在代码中。您也许可以让普通黑客变得更加困难，但仅此而已。无论你实施什么，都会造成另一种形式的混淆；你也可以看看现成的混淆器。
There's no truly secure way to protect programs that run on the client. (C++ can also be decompiled by the way.) It's always going to be possible for users to run clients that have been hacked, and any encryption key will have to be present in the code in some form. You may be able to make it more difficult for casual hackers but that's it. Whatever you implement will amount to another form of obfuscation; you may as well look at the off-the-shelf obfuscators.
也许首先与服务器进行身份验证，从服务器获取盐密钥，然后使用它？这样，即使能够反编译应用程序，想要伪造消息的用户也必须进行身份验证。
除此之外 - 有时您总是需要应用程序可用的密码、哈希值、密钥（或加密或验证数据所需的任何内容），您可以先从服务器获取它，也可以嵌入到应用程序中，这将是可识别的通过反编译。
编辑
正如其他人指出的那样，没有 100% 的安全性，一切都可能被黑客攻击，关键是要让它不那么容易，防止偶然的黑客，仅此而已。因此，正如吉姆所说，现成的混淆器可能是最好的折衷方案。
Perhaps first authenticate with the server, get a salt key from the server, then use it? This way users wanting to fake messages even if capable of decompiling the app would have to authenticate also.
Other than that - at some time you always need the password, hash, key (or whatever is needed to encrypt or validate data) available to the application and either you get it first from your server or embed in the application, which would be recognizable by decompilation.
EDIT
As others have pointed there is no 100% security, everything can be hacked, the point is to make it not too easy, to prevent casual hackers, that's all. So as Jim stated an off-the-shell obfuscator may be the best compromise.