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.
hello im fairX the haxxor join my community of hackers if you payme enough i will give you access to a private area of haxx ;) http://forum.curse-x.com/index.php
``Code Caves'' won't do you any good. It'll make your code more conspicuous. You'll need to give more details on what you're trying to accomplish. Are you trying to hide it from a skilled reverse engineer? Doubtful you'll be able to, your code will stand out, and if you do manage to integrate it with the application, there are dynamic means for detecting it, unless your code isn't malicious by itself, and yet it can end up compromising someone's machine (you'd be surprised by the vulnerabilities found in common software - is there a difference between a (security) bug the author knows about, but doesn't disclose it and one they have no knowledge of?). Are you trying to hide it from automatic tools? You'll have a much higher chance of success then.
>>14 Are you trying to hide it from a skilled reverse engineer?
That will be an exercise for another time. For now I'm just trying to inject my code into a carrier in such a way that allows both the carrier's code and my injected code to be executed.
The executable I'm injecting it into does not have any type of integrity check as far as I know.
Also, I'm not trying to hide it from anti-virus software. I just want to get an idea of how executable injection works. This a learning exercise, not an actual attempt at compromising someone's security.
>>15
Just inject a piece of code which does what you want and then have your code jump back to the entrypoint (adjust the entrypoint to point to your code). A more clever way could be using tls-callbacks (that may be too evil as it will also fool some reverse-engineering tools, like the code would be executed before the application even loads in a debugger). How you're loading the executable or dll in memory, or the layout of the code in general is up to you, I won't give such specifics as they can be just about anything.
>>16
Do you plan on running your code within the same address space as your application? Do you want to create a new process? If so, do you want the process to be created from scratch and without a physical copy or are you fine with a dumb "dump the executable and run it"? If not, some minor modifications to the injected code will be needed to accomodate your needs.
>>17 Just inject a piece of code which does what you want and then have your code jump back to the entrypoint
I've never had the time to get into assembly. If the operation will be a simple JMP and RET operation, there are a few questions that need to be addressed.
-Which lines of code from my malicious executable need to be injected into the carrier executable?
-Where should I inject the code? I assume this is where ``code caves" come into play.
-Are there any header files or meta data in the 'exe' file format that I also need to insert?
It would probably be useful to know the exe file format.
>>18 "dump the executable and run it"
For this project I'm staying within my means. In other words, the most simple operation will suffice (for now).
>>20
The could be anything, but you'd probably want to make sure the registers are preserved, so something along the lines of:
entrypoint:
pushad
call your_main
popad
jmp original_entrypoint
As for the actual code, I have no idea the shape of your code. If it's a DLL, I'd imagine you'd relocate it at the end of the real executable and just run it directly. If it's an executable, you'd have some stub which dumps the executable and runs it. If not, things get a bit more complicated.
I can't imagine you could do this without knowledge of assembly and the PE file format (I'm assuming you're on Win32, if not, learn ELF or w/e format you're working with). The reason I'm saying this is because while it's perfectly possible to write it all in C, your stub will look pretty bloated if you were to just relocate your executable at the end of the host and keep all the libc bloat that comes with the territory, a real "stub" written in assembly can be made in such a way as to not require any data and is just a small stream of bytes which can be copies anywhere and if coded in a certain way, it doesn't even require relocations.
Just in case anybody is curious. The features for this trojan include (but are not limited to) the following:
-Reverse connection by way of an IRC channel.
-Offline/online keylogging.
-Desktop screencapure.
-Twofish/AES encryption for all command & control operations sent/read to the trojan--because safety for the users of this trojan comes first. (Fun fact: The CBC used with this implementation of AES uses a (pseudo) random-number generator for each instance of the executable.)
-A login/register system for guest who use this trojan.
-Limited RAT functionality, because I don't really have much time to mess around with the Windows API.
In other words, a bare bones, backdoor trojan with a little encryption added for paranoia. Also, when executed this trojan leaves virtually no trace to the user (or author) of the trojan. The random server and channels it connects to are determined at run-time with the help of a little entropy. And all inbound and outbound messages are encrypted. I'd feel secure running this type of trojan in the office of a senior FBI agent's office.
>>21 The reason I'm saying this is because while it's perfectly possible to write it all in C, your stub will look pretty bloated if you were to just relocate your executable at the end of the host and keep all the libc bloat that comes with the territory
With my current level of skill, I'd be lucky if I could accomplish that.
>>24
unless you suck hundreds of dicks. just look at VIPPER.
Name:
Anonymous2011-03-20 14:56
>>23 I'd feel secure running this type of trojan in the office of a senior FBI agent's office. I'm not too knowledgeable about this stuff, but your claim sounds preposterous.
Also please elaborate on The random server and channels it connects to are determined at run-time with the help of a little entropy.
>>26
I do think his claim does indeed sound unlikely. He does not seem to know enough about Win32 internals which make me think his trojan doesn't hide itself at all (not a rootkit), which would mean it's trivial for it to be detected by anyone who can just fire up task manager.
with the help of a little entropy. Entropy is a thermodynamic property that is a measure of the energy not available for useful work in a thermodynamic process
Obviously, he's talking either about infinite energy or bullshit.
>>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.
So you basically encrypt what you say in the irc channel?
How would this stop someone simply greping the readable characters in your executeable; and using this info find where your irc server is located and shut it down?
Wouldn't a wiser approach be to 'r00t' someone else's server and run a ircd off that?
>>34 So you basically encrypt what you say in the irc channel?
Pretty much.
How would this stop someone simply greping the readable characters in your executeable; and using this info find where your irc server is located and shut it down?
The trojan connects to several different servers, each of which don't belong to me. Simply knowing that it connects to random servers is not enough information to endanger it. What's more important is the channels it joins. If those were capable of being traced it would be problematic, hence the reason why this trojan uses several factors to determine which channels to join (and when to join them).
Also, there's no plain text sitting around in the code. All of the text is encrypted at compile-time and decrypted during run-time. In addition to some basic obfuscation, the executable is stripped of symbol tables. The words, fuck crackers; however, doesn't appear to be obfuscated. I'll have to patch this error in a future release.
>>35
It could still be easily reverse engineered by anyone bored enough to try. I don't doubt I could do it if you were to provide me with a copy of the binary. What you should be fearing is having your identity discovered (unless you use a proxy when connecting to the IRC server). There are much safer and foolproof methods of doing this without any risks (not your method). Surely if you spend enough time on the Internet, you'll think of some.
>>37
You kids and your next generation HTTP botnets. Back in my days we used floppies.
Name:
Anonymous2011-03-22 1:06
fun fact: there is little difference between "malware" like this and adware/spyware which is actually legal. Look up how many installations one of the many "toolbars" has which make the largest omfg the internet is going to die malware such as conficker look extremely tiny. instead of keylogging they log websites visited and show pop-ups and sell your computing activity to advertisers, sorta like what google does. in fact, google has their own toolbar with hundreds of millions of installations. BTW know what the difference is? "Hi we're installing this with your kewl smiley screensaver, click I accept" - no need to hide from antivirus/fbi/etc.
have every infected comp scan the front page of every world4ch board for a special sequence
and then execute the message that follows
tadah
Name:
Anonymous2013-08-31 7:22
Protein shakes are a good source of protein, which is important to get after a workout. You should always make an effort to at least try to eat some protein after a workout. But it could be in a shake format, a snack format, a meal format — anything you want to eat. Some people swear by shakes, but it doesn't really matter as long as you get it somehow.
Name:
Anonymous2013-08-31 8:07
So I'm getting a urine test at the lab in the hospital. Chick was processing me, but the chick next to her smiled at me, she was staring too. I smiled back and kind of giggled because I was happy. Then she started mumbling, I was like "hmmm?" but I finally picked up on what she was saying and she said "that’s the dr that falls in love with her". I was so confused. I turned back and there was a TV behind me. She smiled at the TV and was talking about it. I was invisible. I felt so embarrassed.
Name:
Anonymous2013-08-31 8:53
I had a Russian BF once and he was hung like a dang elephant! I love anal, but with him it was a real challenge getting it done without a good amount of lube