随机文本混淆算法失败
我一直在尝试一种简单的基于XOR的文本混淆算法。据推测，当算法在系列中两次运行时，我应该恢复原始输入 - 但是在我的实现中，有时才会发生。这是我的代码，并带有一些随机文本来证明问题：
#include <stdio.h>
void obfuscate(char *text) {
char i = 0, p = 0;
while (text[i] != 0) {
text[i] = (text[i] ^ (char)0x41 ^ p) + 0xfe;
p = i++;
}
}
int main(int argc, char **argv) {
char text[] = "Letpy,Mprm` Nssl'w$:0==!";
printf("%s\n", text);
obfuscate(text);
printf("%s\n", text);
obfuscate(text);
printf("%s\n", text);
return 0;
}
如何修复此算法，以便它确实是其自己的倒数？有什么提高混淆程度的建议吗？
I have been experimenting with a simple XOR-based text obfuscation algorithm. Supposedly, when the algorithm is run twice in a series, I should get back the original input - yet in my implementation that only happens sometimes. Here's my code, with some random text to demonstrate the problem:
#include <stdio.h>
void obfuscate(char *text) {
char i = 0, p = 0;
while (text[i] != 0) {
text[i] = (text[i] ^ (char)0x41 ^ p) + 0xfe;
p = i++;
}
}
int main(int argc, char **argv) {
char text[] = "Letpy,Mprm` Nssl'w$:0==!";
printf("%s\n", text);
obfuscate(text);
printf("%s\n", text);
obfuscate(text);
printf("%s\n", text);
return 0;
}
How can I fix this algorithm so that it is indeed its own inverse? Any suggestions to improve the level of obfuscation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我在这里看到两个问题：
操作
+ 0xfe不是它自己的逆。如果将其删除并仅保留 XOR，则每个字节将按预期恢复为其原始值。一个更微妙的问题：加密文本可能会创建一个零字节，这会截断文本，因为您使用以 null 结尾的字符串。最好的解决方案可能是单独存储文本长度，而不是以 null 结尾的加密文本。
I see two problems here:
The operation
+ 0xfeis not its own inverse. If you remove it and leave only XORs, each byte will be restored to its original value as expected.A more subtle problem: Encrypting the text could create a zero byte, which will truncate the text because you use null-terminated strings. The best solution is probably to store the text length separately instead of null-terminating the encrypted text.
您在这里所做的不仅仅是简单的 XOR（如果您将其保留在
text[i] = text[i] ^ (char)0x41处，它会起作用；您甚至可以将其保留在>^ p如果你愿意的话，但是+ 0xfe会破坏它）。为什么要使用这种文本混淆呢？常见的非安全混淆方法有Base64（需要单独编码和解码）和Rot13（应用第二次逆向）。
You're doing more than just a simple XOR here (if you left it at
text[i] = text[i] ^ (char)0x41it would work; you could even leave in the^ pif you want, but the+ 0xfebreaks it).Why do you want to use this kind of text obfuscation? Common methods of non-secure obfuscation are Base64 (needs separate encode and decode) and Rot13 (apply a second time to reverse).
首先，要解码，
您需要它的反函数，即
第二，
char i只能处理短字符串，请使用int。最后（也是最重要的！），经过这样的“混淆”后，字符串可能会在其原始结尾之前以零结尾，因此您还应该检查其原始长度或确保中间不能得到零。
First, to decode
you need its inverse function, that would be
Second,
char iwill be able to work only with short strings, useint.And last (and most important!), is that after such an "obfuscation" the string could get zero terminated before its original end, so you should also check its original length or ensure that you cannot get zeroes in the middle.
为什么要“添加+0xfe”？这是（至少一个）不可逆性的根源。
我发现您通过使用前一个文本值
p的异或来对其进行混淆，这意味着重复的字母将导致值之间来回跳动。Why "add +0xfe"? That is (at least one) source of your non-reversibility.
I see that you obfuscate it by using XOR of the previous text value
p, which means that repeated letters will cause bouncing back and forth between the values.