It sounds like you have a traditional data-hiding job: you have information (a list of filenames) that you want to protect from prying eyes. Presumably the information needs to be available to people you don't trust (otherwise why hide it?) but it still needs to be available to your program.
Presumably you don't want to put your data into a file named "important-file-names.txt"; you've probably embedded it in your program. That isn't enough, because bad guys can run strings
and find the filenames. There are lots of ways to encode the data, but if your program needs to use the data, then it needs to have a way to decode the data (and the decoding key). It doesn't really matter how you encode/decode the data -- eventually your program will have the real filenames in memory, and will want to do something with the filenames (presumably open them, read/write them, maybe delete them) -- at which point you're screwed. The techniques differ by OS, but it is always possible to examine the resources being used by a given program, be it files, network connections, or even RAM. A sufficiently determined person WILL find your information.
Yes, you can hide the data, but the real question is: how long do you expect the data to stay hidden?
If all you expect to do is prevent the casual user from prying, then a simple XOR with a key that isn't a text string will probably do the trick. Beyond that, all you're doing is trying to slow down an expert, who is probably better at this than you are.
[Added more explanation of 'simple]
The simplest cipher is a substitution cipher, where every plain text letter maps to a different cipher text letter. The oldest of these is the so-called Caesar cipher, where the cipher text was just the plain text with the letters shifted by two characters (A->C, B->D, C->E), such that HELLO becomes IGNNP when enciphered. The problem with a substitution cipher is that not all letters are used uniformly in words, and not all words are used uniformly in sentences. By analyzing the patterns of letters and words in a given piece of cipher text, you can deduce the plain text. (The daily cryptogram works this way.) If you were to XOR every single letter in the plain text with a single byte (0x80 or 0x96) it has the exact same effect as the simple cipher.
So the next better cipher is one where you use lots of different ciphers, instead of just one. By using a key and encoding the first letter of the plain text with the first letter of the key, the second letter of plain text with the key's second letter, and wrapping the key if it's longer than the message, you get a slightly more difficult cipher.
plain text => THIS IS A TEST OF THE EMERGENCY BROADCAST SYSTEM
message key => JUBI LE E JUBI LE EJU BILEEJUBI LEEJUBILE EJUBIL
cipher text => EDLC VY G EAVD BL ZSA HWRXMPJFI OXULZFKFZ YJOWOZ
I'm using a simple letter rotation scheme and skipping spaces to make this easy to understand. In practice, you wouldn't skip spaces, you'd use a longer non-alphabetic key, and you'd use a more complicated coding function. XOR is a popular coding function because it's symmetrical. You want to use a non-ASCII key, because you want something that blends in to the background in a binary executable. It will also have a higher chance of generating a cipher text that is not a simple text string. As I wrote earlier, a truly determined attacker won't need to break your cipher -- he'll break your program; this is just to keep the amateurs out.