How to Code an FUD Crypter

Bth

TheBth.org
Introduction

I’ve read lots of threads, books, and tutorials on making FUD crypters. The fact is, most
of these tutorials require you to do lots of unnecessary work. Here, I give a step-by-step
process that will make your crypter 100% FUD. Over the course of the next twenty or so
minutes you will learn EVERTHING you need to know in order to make a fully working
FUD crypter. So, why would someone want to make their own FUD crypter in the first
place? Whether you’re a pentester or black hat hacker, there are a number of reasons…

For pentesters:

1.) Most companies that hire you will expect you to use open source tools, trusted third
party tools (i.e., Core Impact), and tools you code yourself. If you code your own crypter,
you have nothing to worry about.

2.) Most paid crypters can not be verified as trusted, third party programs, so you won’t
be able to use them in your work.

3.) If you are targeting a system with a specific antivirus it’s easy to quickly code a
crypter that’s just undetectable by that antivirus, whereas with third party crypters you
have to wait for the latest stub to end up in your inbox, wasting valuable time.

4.) It happens: “companies” that make crypters sometimes go out of business. If you find
yourself without a crypter in the middle of a job, then what?

For all you black hats:

1.) Lots of people use paid crypters, which causes them to become detected by antiviruses
more quickly. Do you really want your massive carding operation to come to a grinding
halt because some n00b scanned a stub on Virustotal?

2.) In hacking, time is crucial. If a paid crypter becomes detected, do you really want to
wait for an update while you could be getting thousands of new victims?

3.) With paid crypters especially, the source code of the crypter will eventually become
leaked. This is good for coders, but for you it means that overnight your crypted files will
become detected by every antivirus under the sun. Your bots will drop like (dead) flies…

Crypters have been around ever since the first computer antivirus emerged (if you would
like to look at some of the first crypters, go to vx.netlux.org). The idea behind a crypter is
very simple. The program being crypted is “stripped down” to its raw data/instructions
and then is encrypted block by block (oh noes…“cryptography terminology”) with some
sort of cypher, usually a public one. This encrypted set of instructions is now written to
the end of a file called a stub to form the completed product (the crypted file). When this
crypted file is executed, the stub will load the encrypted data into memory and then
decrypt it and execute it (usually instruction-by-instruction or block-by-block).
 Figure 1 – The operation of a basic crypter.

Almost all crypters start their life being undetectable from all antiviruses.
However, this un-detection is usually short lived, and there is nothing you, me, or anyone
else can do about it. Because most crypted files end up running on thousands of
computers, the antivirus companies will eventually get to it. I guarantee it. Unbeknownst
to most people, most antivirus companies regularly upload exe files from their user’s
computers for analysis.

Step One: Before you make your crypter FUD…

The first step to making an FUD crypter is to first make an actual crypter in the
first place*. You can either code one yourself or download a source code. It’s up to you.
This tutorial is geared towards making a crypter FUD, not coding one. Just remember one
thing: make/download a crypter without extra features like “AV Kill”, “Add to Startup”,
“Anti VM”, etc. These features are not hard to FUD, but if the program you’re crypting

*Please note: Most crypters are coded in VB, but the methods shown here will work for any language.
doesn’t support these options and you find yourself in need of them, you’re a fail. A
crypter is intended to make files undetectable from antiviruses, not to add features…

Step Two: Changing your crypter’s flow of operation…

Antivirus companies detect crypters based on their behavior. By altering that behavior,
our crypter becomes that much harder to detect. In this step we will be changing how our
stub executes by changing the “flow” of its functions. The idea here is to take the code
that is in a given function, break it down, put bits and pieces of it into separate functions,
and then call those functions instead of using the code (see figure 2 and figure 3).
Remember to move around your variables so that all the “bits and pieces” of the code you
put in the new functions still have access to them.

Figure 2 – How the code looks before step two.

Figure 3 - How the code looks after step two. Notice how 1) the string that was in the main function is now declared at
the top, 2) how the code in the main function has been split up into separate functions which are then called in the main
function, and 3) how the commands are being executed in the same order (command one is executed before command
two in both figures 2 and 3)

Step Three: Rename everything…

This is by far the most important step. In this step, we will be renaming every variable
and function in the stub (I like to not change the name of the main function, but that’s a
personal thing). Remember: If you change a variable that is in the stub and the builder,
make sure to change it in both places. This renaming confuses antivirus software.

Figure 4 – How the code looks after step three.

Step Four: Junk Code

Junk code is code that serves no function. Usually junk code is just a series of functions
that declare variables, execute pointless if-then statements, etc. In this step we will be
adding junk code functions to our code. Junk code is truly an art, and you will have to
master it on your own. Adding just the right amount of junk code in just the right place
takes skill. However, there are many programs out there that generate junk code, so that
at least saves you some work. If applied correctly, junk code can be the difference
between FUD and, say, a detection rate of 10/30. It’s very powerful yet very tricky.

Figure 5 – Code after step four. Usually junk code functions have random names, but in this case the one shown
doesn’t for demonstrational purposes. Also, there is usually more than one junk code function.
Step Five – Assembly Information

Every time you compile your stub, remember to change your assembly information (i.e.,
version number, icon, company, etc.). Our goal is to make our stub have nothing unique
about it at all. If all of the stubs we make are version 1.8.09 from Hax Inc., the antivirus
companies will catch on quickly. Believe me…

Step Six – “The Secret Key”

All crypters have an encryption key. It’s good to change it every once and a while. Most
crypters are detected because of their stubs, but if your file is encrypted with “password”
as the XOR key your encrypted file will be detected regardless of the stub. Be aware that
in order to change the key you may have to recompile the stub and the actual crypter
itself.

What do I do if my stub doesn’t turn out FUD?

The fact is, even if you follow this process word by word, there is a chance that your file
won’t come out FUD. So what do you do if this happens? Try, try again. Try adding more
junk code. Try changing the assembly information. Try changing the flow of operation.
In some cases the problem might be that the crypter itself is so old it just can’t be FUD
(yes, it’s possible and has happened to me). You will eventually get an FUD crypter. It’s
taken me as much as eight hours, and you should expect to spend an equal amount of
time on your first attempt.

Making it all add up…

Whether you’re a pentester or a black hat, you have some sort of life outside of the world
of computers (I sure hope so, anyhow). I know that I don’t have eight hours to set aside
for coding every time I need a new stub, and no one expects you to, either. Using a
magical tool called a USG (unique stub generator) it is possible to produce a fresh, new,
FUD stub in seconds. All a USG does is go in to your source code and randomize the
variables/functions, randomly add junk code, etc. A good Python script should do the
trick. Just remember, in order to make a good USG, you must start with an FUD stub (or
one that’s very close to FUD) to apply the USG to. As it turns out, USGs don’t do much
for stubs with detection rates of 28/30. USGs don’t turn detectable stubs FUD, but they
do provide a way to keep FUD stubs useable for an extended period of time. If you use a
USG you will only have to code a brand new stub every once and a while (every year or
so if you’re lucky). That’s better than coding a new stub every time you stub becomes the
slightest bit detected, right?
Figure 6 – A USG takes an FUD stub that has a couple detections (left) and with a few minor alterations makes a new,
FUD stub (right).

Conclusion

Whoever you are, and whatever you stand for, I hope these methods have helped you.
They’ve worked for me, and I hope they work for you. I personally use a CODOM USG
crypter (that I coded myself) and my stub is always undetectable from most major
antiviruses. I haven’t even added a USG yet. Stay creative and you’ll have no problem
creating an FUD crypter. Happy hacking! Stay smart and stay safe.