Trojan project

Greetings /prog/, I'm from a neighboring board.

I'm on the last phases of a trojan project. I'm having a hard time finding the best way of hiding my malicious executable within another executable. I assume the best way of doing that would involve assembly? "Code caves" seem to be what I'm looking for, though there doesn't seem to be much tutorials for it. Any advice? Thanks in advance.

>>26
in the office of a senior FBI agent's office.
I just noticed the redundancy of such a statement. I'm going to use the, "English wasn't my first language" excuse. That should work.

I'm not too knowledgeable about this stuff, but your claim sounds preposterous.
You're suspisions are probably true, but that won't stop my youthful bravado. It would probably be a good idea to get some more input on the safety of this trojan. First I'll explain how it works, then you guys will hopefully explain why this wouldn't work. The following assumes the reader has a decent understanding of AES (Advanced Encryption Standard) and CBC (Cipher Block Chaining). CBC needs an IV (initiation vector) to work, preferably, a random one. So the trojan uses a fairly decent random-number generator at runtime to initiate it. Consequently, when the trojan first connects to a remote server, not even the malicious owner can read its messages. Only after the IV has been determined can the malicious user send/read encrypted messages. As for the (AES) 256 bit password, it is set with a default password that can be changed at run time. What that basically means is, even if I was in the same room with, say, an IRC admin he/she wouldn't be able to know what is being sent/read.

Also please elaborate on
Small factors such as time, username, OS, and hardware info determine when (and where) it connects to. Since it's always changing channels, it makes it harder to monitor.