delphi exe的内部密码是否安全？
如果我需要用户输入密码来打开Delphi生成的exe,我使用这样的代码而不是简单的密码,如下所示:
if password='1234' then begin
form2.show
end;
pax*_*blo 10
不,这几乎肯定会在可执行文件中以明文形式存储.
实际上,由于检查是在本地完成的,因此无需任何努力就可以确保可执行文件的安全 - 攻击者需要做的就是编辑可执行文件以修改条件跳转,并绕过您的测试.这些东西通常被保护的方式是将这种力量从攻击者身上移开.例如,将用户输入的密码发送到您控制的中央服务器,并在那里进行检查,只有在检查成功时才发回所需的内容(并且不能由替换服务器伪造).
然而,这可能是不必要的努力.如果您要做的就是避开随意的破解程序,您可能只需要进行一些混淆,例如使用关键短语对密码进行异或,这样在可执行文件中就不那么明显了.使用用户输入的密码执行相同操作,然后比较这些密码,意味着明文密码将不可见.
像这样的计划不会阻止一个坚定的破解者,但它会使绝大多数人更难.安全性(IT,家庭或任何其他类型)的想法并不总是让它失败,只是为了让它变得不那么值得.
这真的取决于谁你想失利-这将决定你的方案应该多么复杂.
或者,您可能需要考虑hvd在评论中提出的选项.让可执行文件只是一个存根,它将实际的可执行文件作为加密数据.这将使用用户输入的密钥解密并写入文件系统,检查其有效性,然后运行.
由于密码不在存根本身内,因此不容易受到攻击.密码仅存在于创建者(在制作存根时使用)和用户(希望仅在他们的头脑中).只获得存根的人没有简单的方法来运行加密的可执行文件.
同样,有办法解决这个问题,但它们都涉及获取没有可执行文件的密码(暴力,社会工程等).
- 它不仅可行,而且非常简单. (5认同)
- @RemyLebeau如果解密密钥基于输入的密码,并且用户没有密码,您如何做到这一点？ (3认同)
- 使用服务器的另一个缺点是可以使用返回虚假成功回复的本地服务器绕过它.我自己曾经使用过这种技术几次. (2认同)
- 可以非常容易地提取存储在exe本身中的任何内容.即使您对数据进行加密,仍然可以使用ICE或IDA等工具轻松获取,这些工具只需等待exe将数据解密到内存中,然后再将其解压缩.所以简短的回答是,没有办法保护你的exe文件本身.任何拥有合适工具,时间和精力的人如果真的想要,都可以闯入它. (2认同)
- @paxdiablo:是的,它可以,如果你可以计算出用于与主服务器通信的协议,并找出它需要什么输入以及它产生什么输出.就像我说的,我以前自己使用过这种技术,所以我知道这是可能的.要保护该连接,您需要使用SSL/TLS以及经过验证的证书来保护连接,甚至是MITM攻击. (2认同)
- @hvd:显然,如果解密是基于用户输入,那么您需要输入正确的值.如果你有时间和耐心,这就是蛮力工具发挥作用的地方,而且应用程序不够智能,可以蛮力攻击.但并非所有软件都是那么聪明.我见过使用私钥来加密/解密来自exe的内部数据的应用程序,假设在编译时加密数据是安全的.它不是.ICE/IDA可以简单地等待应用程序使用自己的私钥来解密数据,然后在丢弃之前从内存中获取解密数据. (2认同)
- 密码的密码和哈希值根本不应存储在exe本身中. (2认同)
- @RemyLebeau这很有趣,这实际上是Delphi自己的安装程序有效地做的,使用他们的7zip密码保护文件:) (2认同)
Sve*_*sli 10
只是为了证明它是如何不安全,考虑这个小型控制台应用程序:
program Project1;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils;
procedure StartProgram;
begin
writeln('You entered the correct password. Welcome to this awesome program!');
end;
procedure EndProgram;
begin
writeln('That is not the correct password. Goodbye.');
end;
var
PW : string;
begin
write('Enter password: ');
readln(PW);
if PW = 'SuperSecretPassword' //See if you can spot this in the image
then StartProgram
else EndProgram;
readln;
end.
编译它,并在十六进制编辑器中打开exe文件.截图来自XVI32,但我想任何十六进制编辑器看起来都有点类似:
毕竟不是那么超级秘密.