Random text obfuscation algorithm crashes

Question

I experimented with a simple XOR-based text obfuscation algorithm. Presumably, when the algorithm runs twice in a series, I should return the original input, but in my implementation this only happens sometimes. Here is 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 really is its own inverse? Any suggestions for improving obfuscation?

Answer 1

Here I see two problems:

• Operation + 0xfe not its own inverse. If you delete it and leave only XOR, each byte will be restored to its original value, as expected.

• More subtle problem. Text encryption can create a null byte that truncates the text because you use null-character strings. The best solution is probably to save the length of the text separately instead of zero ending the ciphertext.

Answer 2

You do more than just XOR here (if you leave it at text[i] = text[i] ^ (char)0x41 , this will work, you can even go to ^ p if you want, but + 0xfe will break it).

Why do you want to use this type of text obfuscation? Common methods for unsafe obfuscation are Base64 (requires separate encoding and decoding) and Rot13 (apply a second time for the opposite).

Answer 3

Firstly, for decoding

 text[i] = (text[i] ^ (char)0x41 ^ p) + 0xfe; 

you need its inverse function which will

 text[i] = (text[i] - 0xfe) ^ (char)0x41 ^ p; 

Secondly, char i can only work with short strings, use int .

And the last (and most important!) Is that after such "obfuscation" the string can get zero to the end of its end, so you should also check its original length or make sure you cannot get zeros in the middle.

Answer 4

Why "add + 0xfe"? This is (at least one) the source of your irreversibility.

I see that you are confusing it using the XOR of the previous text value p , which means that duplicate letters will cause a back and forth bounce between the values.