# Thread: Encrypted strings and Encrypt Project

1. Originally Posted by jpan05
This is step encryption I have XOR that does a better job so clam your tits
XOR is also not a real encryption. Xor is a bit Operator. Its just called Xor Encryption, cause you primary use just Xor to xor two values. if u use the same second value on the new value, you get the first value back.

Or to explain it in binary:

11011010
^
01101101
=
10110111

and backwards:
10110111
^
01101101
=
11011010

So if u find out the "key" (second operator) you can simple reverse the string.

you now understand Xor, b***h (5\$ he will ignore or rage answer)

2. ## The Following User Says Thank You to kotentopf For This Useful Post:

[MPGH]Flengo (08-03-2012)

3. Nice, thank you that you clear that.
All who know a bit ASM should know this since there's the same fucking name for a method ("XOR")...

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

5. Originally Posted by Password77
XOR for life
Xor will be detected soon enough.

6. Originally Posted by LilGho\$t
Xor will be detected soon enough.

7. ## The Following User Says Thank You to kotentopf For This Useful Post:

arun823 (08-06-2012)

8. Originally Posted by 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:
Code:
```"\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.

9. Originally Posted by 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:
Code:
```"\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:
Code:
`/*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.

10. Originally Posted by 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:
Code:
```"\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:

11. ## The Following User Says Thank You to kotentopf For This Useful Post:

12. Originally Posted by Ch40zz-C0d3r
You know what your saying is completely shit?
Example:
Code:
`/*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.

13. Originally Posted by LilGho\$t
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".

14. Originally Posted by Shadow`
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

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

16. Originally Posted by de.bug
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[])

17. Originally Posted by Broderick

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.

18. 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.

Page 2 of 3 First 123 Last