Encrypted strings and Encrypt Project

[Broderick]

This isn't encryption; it's a cipher, and not a very good one at that :/

[LilGho$t]

XOR for life

Xor will be detected soon enough.

[kotentopf]

Xor will be detected soon enough.

[LilGho$t]

/).- nexon is using xor on a new game of theirs (sudden attack been out for a few months). Don't you think by now they know about xor and they know what to scan for. We used xor not only to prevent hex-editors but it also helped conceal strings from nexons scanning system with xor having been so mass released and massively used it will soon be patched because they'll throw in their scanner to scan for:

"\x8E\xB4\xA7\xB3\xBD\xB7\xB0\xB2\xF7\x93\xB0\xB6\xB7"
"\xD1\xE6\xF0\xF1\xEF\xE9\xEF\xFA"
"\x2C\xE1\xF7\xE7\xA3\xC9\xE0\xE8\xF2"
"\xBD\x84\x96\xD6\xB8\xA8\xB2"

etc.

So, make your own encryption and dodge their scanner.

[Ch40zz-C0d3r]

/).- nexon is using xor on a new game of theirs (sudden attack been out for a few months). Don't you think by now they know about xor and they know what to scan for. We used xor not only to prevent hex-editors but it also helped conceal strings from nexons scanning system with xor having been so mass released and massively used it will soon be patched because they'll throw in their scanner to scan for:

"\x8E\xB4\xA7\xB3\xBD\xB7\xB0\xB2\xF7\x93\xB0\xB6\xB7"
"\xD1\xE6\xF0\xF1\xEF\xE9\xEF\xFA"
"\x2C\xE1\xF7\xE7\xA3\xC9\xE0\xE8\xF2"
"\xBD\x84\x96\xD6\xB8\xA8\xB2"

etc.

So, make your own encryption and dodge their scanner.

You know what your saying is completely shit?
Example:

/*Remote Kill*/XorStr<0x36,12,0xD7548B3F>("\x64\x52\x55\x56\x4E\x5E\x1C\x76\x57\x53\x2C"+0xD7548B3F).s

We are adding an offset to the byte string. We can change the offset, we can also use bytes instead of a bytestring. If you dont know what your saying, dont say it.

[kotentopf]

/).- nexon is using xor on a new game of theirs (sudden attack been out for a few months). Don't you think by now they know about xor and they know what to scan for. We used xor not only to prevent hex-editors but it also helped conceal strings from nexons scanning system with xor having been so mass released and massively used it will soon be patched because they'll throw in their scanner to scan for:

"\x8E\xB4\xA7\xB3\xBD\xB7\xB0\xB2\xF7\x93\xB0\xB6\xB7"
"\xD1\xE6\xF0\xF1\xEF\xE9\xEF\xFA"
"\x2C\xE1\xF7\xE7\xA3\xC9\xE0\xE8\xF2"
"\xBD\x84\x96\xD6\xB8\xA8\xB2"

etc.

So, make your own encryption and dodge their scanner.

i already told, that you can use any key for xor (except one key)
nexon can try to search in a loaded module for the position of a xorcompiled string and the location of xorkey. and if this matches a string like "Aimbot" the game will crash.
but this is inperfomant as hell (scan a complette module, logical combine of maybe a key and maybe a xorcompiled string and check if the string is matching). scan would need for a simple hotkeyhack about 1 minute. scanning a complex multihack with alot of string a lot of functions alot of pointer should need about 7 minutes to scan and analyse. then logical thinking for the game. low FPS. fucked player. CA is going down.

i'm saying it again:

[LilGho$t]

You know what your saying is completely shit?
Example:

/*Remote Kill*/XorStr<0x36,12,0xD7548B3F>("\x64\x52\x55\x56\x4E\x5E\x1C\x76\x57\x53\x2C"+0xD7548B3F).s

We are adding an offset to the byte string. We can change the offset, we can also use bytes instead of a bytestring. If you dont know what your saying, dont say it.

Talk to pwnage about it (coder at a different site) he's the one who brought it to my attention. I for one see what he's saying if you disagree, hit him up.

[Shadow`]

Talk to pwnage about it (coder at a different site) he's the one who brought it to my opinion. I for one see what he's saying if you disagree, hit him up.

I think kotentopf is more experienced in this subject that "pwnage".

[Password77]

I think kotentopf is more experienced in this subject that "pwnage".

Lol it might have been just a thought, like kotentopf said, its not that hard to figure out how xor works :P Maybe nexon will work its way around xor

[de.bug]

@Password77:
Calling new char[] means you should also call delete [] to release the memory. Also returning a pointer to a local variable that is not static is a very bad idea as it's only guaranteed to be valid within the scope of the function. You should pass a buffer for the output as an argument to function and let function return pointer to the buffer you passed to prevent issues. I pointed this out on a previous post to similar code I saw here as well so just tossing it out there again...

Look at doing it via a class with members you can store your strings in.

Greets

[Broderick]

@Password77:
Also returning a pointer to a local variable that is not static is a very bad idea as it's only guaranteed to be valid within the scope of the function.

Not so with heap allocation in C++; there is no garbage collector (thought even a GC wouldn't clean it up as it's still referenced...but I digress). As you said in the earlier part of your post, you must call delete [] to free the allocated memory, until then it's just sitting there, hogging memory. This is the cause of many nightmares and memory leaks in applications that haven't properly free'd dynamically allocated memory. Returning the pointer to the heap allocation is completely valid from within a function.

While it's true that you can't and shouldn't return some local variables (ones that aren't primitive such as int/long/bool etc), this is simply because they're allocated on the stack (local structs and fixed-size arrays as an example). After the function returns (or just before, depending on the calling convention), the stack pointer is reset, invalidating all locals that were allocated on the stack (subsequent functions can now overwrite the data on the stack without limitation.

So from that post there is really only one valid point; you should be properly freeing dynamically allocated memory after you've used it so that the OS can reuse it. Do this by calling delete or delete[] depending on which version of new you called (new or new[])

[de.bug]

Not so with heap allocation in C++; there is no garbage collector (thought even a GC wouldn't clean it up as it's still referenced...but I digress). As you said in the earlier part of your post, you must call delete [] to free the allocated memory, until then it's just sitting there, hogging memory. This is the cause of many nightmares and memory leaks in applications that haven't properly free'd dynamically allocated memory. Returning the pointer to the heap allocation is completely valid from within a function.

While it's true that you can't and shouldn't return some local variables (ones that aren't primitive such as int/long/bool etc), this is simply because they're allocated on the stack (local structs and fixed-size arrays as an example). After the function returns (or just before, depending on the calling convention), the stack pointer is reset, invalidating all locals that were allocated on the stack (subsequent functions can now overwrite the data on the stack without limitation.

So from that post there is really only one valid point; you should be properly freeing dynamically allocated memory after you've used it so that the OS can reuse it. Do this by calling delete or delete[] depending on which version of new you called (new or new[])

You made some valid points but I'll stand by what I said about the scope of a variable. Just because garbage collection is broken or may not happen it's not good coding practice to return a pointer to a variable declared inside a function unless you define it as static. Either way this code is broken due to the massive memory leak it creates.

[Password77]

so @de.bug you mean instead of returning the char what i should have done is #define blah blah blah? Because i thought returning from a method is efficient coding practice. I guess i was wrong.

[de.bug]

The problem is your allocating new memory on every call and not calling delete [] to free it. Next problem is if you free it you can't return it which is why I suggested passing a buffer to hold the output. This is better suited to be a class though.

Something like this

char* Decrypt( char* pIn, char* pOut, int BufSize)
{
    int length = strlen(pIn);
    if (length > BufSize) return 0;

    //do your encode/decode and write output into pOut

    return pOut;
}

char* pDecoded = new char[64];

if ( Decrypt( "encodedstring", pDecoded, 64) )
{
    
}

// free the memory when done
// note the [] used with delete, this is because you used new char[]
delete [] pDecoded;

A better solution is to use the pre-build event in VS and write a script using python, perl whatever to generate a header file with encoded strings. The advantage here is the script knows how many strings there are, the max length and can make a random key on each new build. I do this but use a class to access them, the class keeps track if a string is already decoded or not, allows you to have a valid pointer to a given string at all times etc.

This is basically how i access do mine using a class and pre-build event to create the header file.

// to retrieve or decode a string
char* pStr = g_pStringManager->GetChar( STR_SOME_STRING );

// End of render frame secure them
g_pStringManager->SecureAll();

//In header file I simply generate defines
#define STR_SOME_STRING "encoded_string_data"

Think on the class based solution and build events would make a nice project for you to tinker with.

[Password77]

Thank you for clearing it up

The problem is your allocating new memory on every call and not calling delete [] to free it. Next problem is if you free it you can't return it which is why I suggested passing a buffer to hold the output. This is better suited to be a class though.

Something like this

char* Decrypt( char* pIn, char* pOut, int BufSize)
{
    int length = strlen(pIn);
    if (length > BufSize) return 0;

    //do your encode/decode and write output into pOut

    return pOut;
}

char* pDecoded = new char[64];

if ( Decrypt( "encodedstring", pDecoded, 64) )
{
    
}

// free the memory when done
// note the [] used with delete, this is because you used new char[]
delete [] pDecoded;

A better solution is to use the pre-build event in VS and write a script using python, perl whatever to generate a header file with encoded strings. The advantage here is the script knows how many strings there are, the max length and can make a random key on each new build. I do this but use a class to access them, the class keeps track if a string is already decoded or not, allows you to have a valid pointer to a given string at all times etc.

This is basically how i access do mine using a class and pre-build event to create the header file.

// to retrieve or decode a string
char* pStr = g_pStringManager->GetChar( STR_SOME_STRING );

// End of render frame secure them
g_pStringManager->SecureAll();

//In header file I simply generate defines
#define STR_SOME_STRING "encoded_string_data"

Think on the class based solution and build events would make a nice project for you to tinker with.