Thread: Problems with Xor encryption

Hey guys, I'm trying to develop a Xor ecnryption function but I'm having some problems...

Here's what I've so far:

Code:

#include <stdio.h>

int main(int argc, char *argv[])
{
    char string[] = "This is a test!!!";
    char key[] = "123";

    XorEncrypt (&string, &key);
    
    printf("%s", string); 
    getch();
    return 0;
}

int XorEncrypt (char *string, char *key)
{
    int cnt = 0, i, j, r, mod;
    
    int StringLen = strlen(string); // 20
    int KeyLen = strlen(key); // 6
    
    r = StringLen / KeyLen;
    
    for (i = 0; i < r; i++)
    {
        for (j = 0; j < KeyLen; j++)
        {
            string[i*KeyLen + j] = string[i*KeyLen + j] ^ key[j];
        }
    }
    
    mod = StringLen % KeyLen;
    
    if ( mod != 0)
    {
         for (i = 0; i < mod; i++)
         {
             string[-mod + i] = string[-mod + i] ^ key[i];
         }
    }
    
    return 0;
}

Output: eZZB↕ZB↕R◄FVBF↕!!


The function is not working tough, if I take that output and pass it again to the function I get this:

a♫test♀!!

I don't know if I made a mistake regarding pointers or if there's something wrong in the function itself... Please help =)

Originally Posted by lala123

The function is not working tough, if I take that output and pass it again to the function I get this:

How are you passing the input back? Copy and paste? If so, the copy/paste is probably screwing up the values. I don't see anything wrong with the encryption code itself, so I think you are having some other issue here.

Also, you can't use printf() to display the result. The XOR encryption might have caused a byte to become zero, which in C indicates "end of string." You need to remember how long the string was before you encrypted it, and print exactly that many characters.

Printing encrypted data to a terminal is usually a bad idea, since it may contain control characters that confuse the terminal. I bet if you change your program to read/write its data from files instead of the console, it will suddenly work much better.

Thank you for your quick response buck. I tried doing as you said, but for some reason the text at the file remains unchanged...

Here's what I'm using:

Code:

#include <stdio.h>

int main(int argc, char *argv[])
{
    FILE *fp;
    long fSize;
    size_t result;
    char key[] = "123", *buffer;

    fp = fopen ("xor.txt", "rb+");
    
    if (fp == NULL)
       {fputs("File error",stderr); exit(1);}
       
    fseek (fp, 0, SEEK_END);
    fSize = ftell (fp);
    rewind (fp);
    
    buffer = (char*) malloc (sizeof(char)*fSize);
    
    if (buffer == NULL)
       {fputs ("Memory error",stderr); exit (2);}
       
    result = fread (buffer, 1, fSize, fp);
    
    if (result != fSize)
       {fputs ("Reading error",stderr); exit (3);}
       
    XorEncrypt(buffer, &key);
    
    fwrite (buffer, 1, fSize, fp);
    
    fclose(fp);
    free(buffer);
   // getch();
    return 0;
}

int XorEncrypt (char *string, char *key)
{
    int i, j, mod;
    
    int StringLen = strlen(string); // 20
    int KeyLen = strlen(key); // 6
    
    for (i = 0; i < (StringLen / KeyLen); i++)
    {
        for (j = 0; j < KeyLen; j++)
        {
            string[i*KeyLen + j] ^= key[j];
        }
    }
    
    mod = StringLen % KeyLen;
    
    if (!mod)
    {
         for (i = 0; i < mod; i++)
         {
             string[-mod + i] ^= key[i];
         }
    }
    
    return 0;
}

string[-mod + i] = string[-mod + i] ^ key[i];

The above highlighted items can evaluate to a negative number which is probably trashing your key variable making your encryption questionable at best.

I did, but couldn't notice any difference.

Just a point to bring up --- you have your "XorEncrypt" returning an int. My question is why? What do you do with the returned value --- nothing. So why not make it's return type "void". Not an error, but why make it return a value never used again?

Originally Posted by matsp

[1] Well, technically, I think the C language defines this as "undefined behaviour", meaning anything can happen - mushrooms popping out of the keyboard, computer catches fire, program crashes, or whatever else you can imagine, but for most compilers I've used, it works the way it's described above, and it CAN be used sometimes, as long as the compiler is known to support this trick.

Well, since a[b] is defined as *(a+b), then a[x] is valid for any x so long as (a+x) is a valid pointer value. So this is valid:

Code:

char string[6] = "Hello";
char *endstring = string + 5;
char lastchar = endstring[-1];

Because endstring == string + 5, endstring[-1] <=> *(endstring - 1) <=> *(string + 5 - 1) <=> *(string + 4) which is valid.

Originally Posted by matsp

Hmm. I must be confusing negative offsets with some other stuff that is UB then...

--
Mats

Technically, you may not even possess, let alone dereference, a pointer to unallocated memory (whether it is automatic, global, static, or dynamic memory). The exception is that you can hold a pointer which points exactly one past the end of an allocated block.

But array accesses devolve to pointer dereferences. If the equivalent pointer dereference would be valid, then the array access is valid too.

So.... Does anyone know why my code ain't working? The executable runs fine but the file remains unchanged.