XOR_Crypter | XOR encryption , malware crypter | Encryption library

First of all, remember that if an attacker can attach a debugger to your process and your process has to be the one in charge of the decryption, you have already lost by definition; the best you can get is "security through obscurity". More secure approaches generally require offloading part of the work to an actor that the attacker cannot access - be it an external, tamper-proof cryptographical device or a remote service.

But most importantly, any method is vulnerable to being dumped, as sooner or later you'll need to access the plaintext, and it'll be there in memory ready for anyone with a debugger to be read.

That being said, you can mitigate this last problem by decrypting your string only on demand, and wiping it away immediately after; this shrinks the window of opportunity for the attacker. So, you don't want a function that decrypts a static buffer, but a function that fills a client-provided buffer with the needed secrets (and make sure that the clients actually zero out the content of such buffer before deallocating it - use a memset-like which takes a volatile pointer to make sure that the wiping isn't optimized out).

As for actually storing the keys into the executable, you can use a variety of methods to create confusion. Initializing a global with a plain initializer puts the relevant data in the .rodata section of the executable, which is the first place where I'd look; any string with high enough entropy would be a dead giveaway to investigate further where it is used (the IDA disassembler makes this particularly easy). A possibility that comes to mind is to actually initialize the buffer one byte at time from a function (possibly making the pointer to the buffer volatile, to make sure the compiler doesn't pull strange tricks); this should put your data straight into the code section, which is a bit less suspect, and where the entropy should be kept lower thanks to the interleaving with opcodes.

This data could have been further encrypted by using some simple trick - say, XORed with the output of a simple XorShift PRNG; this again adds to the confusion, but a XorShift is implemented in a handful of instructions, so you don't have extra dependencies or "suspect" code.

Another important point, if you are hiding decryption keys, is not to use cryptographic primitives provided by your operating system, but link statically your implementation, and possibly one that doesn't use AES-NI or other obvious giveaways. If I were trying to extract decryption keys first thing I'd hook into a debugger all the relevant CryptoAPIs, and look into the executable for cryptographic instructions to locate the most interesting zones.