I like the name Backdoor Factory for this tool because in a real factory, you can see all the tiny moving parts that work together to create the final product produced by the factory. When you first fire up BDF, you may be taken aback by the options available to you at the command line. Although we won't be covering all of these options in detail, I want to get us familiar with the tool. For our purposes in this chapter, we won't try everything; and in a given assessment, you may not need more than just a few parameters to get the job done. However, part of the job is understanding the capability of your tool set so that you'll effectively recognize solutions to problems. We'll do that, but before we review BDF's features, let's deepen our understanding of injecting shellcode into executables (also called "patching"). One of the core concepts for any dynamic injector is code caves. A code cave is a block of process memory composed of just null bytes (0x00). We call them code caves because they're dark, scary, empty, bears live in them, and they're a great place to stash our malicious code. (I lied about the bears.) These structures of nothingness are important for us because they allow us to add code without changing anything that's already there.

In this example, I've highlighted a code cave within a Windows installer:

Running BDF without any flags set will just display these options (as well as a fun ASCII banner). Let's take a look at what this thing can do. Note, there are a few options here that are out of scope or self-explanatory, so I've skipped them. (In fact, one option is for OnionDuke, and you won't see too many legitimate white-hat contexts for that one.) You can start the tool with this simple command:

# backdoor-factory

Without any parameters, BDF will let you know what options are available to you:

• --file= identifies the binary that you'll be patching with your code.
• --shell= identifies the payloads that are available for use. You'd use --shell=show after defining an executable with --file= to see a listing of compatible payloads.
• --hostip= and --port= are your standard options for either your connect-back or local bind, depending on the payload.
• --cave_jumping allows us to spread our shellcode over multiple code caves; some code in one cave, then a jump to the next cave, then to the next.
• --add_new_section adds a new section in the executable for our shellcode. This isn't a stealthy option, but may be necessary with some executables depending on their structure.
• --user_shellcode= lets us provide our own shellcode (instead of using the built-in payloads). I prefer to have a more personal relationship with my shellcode, so I will almost exclusively use my own.
• --cave and --shell_length= are used to hunt for code caves inside a binary. While --cave can find them all and list them, --shell_length= is used to define caves of a particular size.
• --output-file= is where our finished product will go.
• --section= is used when we're naming our new section created with --add_new_section.
• --directory= is a delightful option that makes BDF especially powerful; this allows us to backdoor an entire directory of binaries. Keep in mind that the default behavior is hunting for code caves, which means each individual executable needs to be processed. By combining this option with --add_new_section, BDF won't need to hunt for caves and this process is a lot faster. Remember the rule of thumb that adding sections is not stealthy.
• --change_access is default behavior; you will only change this in certain situations. This option makes the code cave where our payload lies writable and executable.
• --injector, --suffix=, and --delete_original are part of the injector module and are Windows-only, so we won't play with them here. I didn't skip them because they're interesting and dangerous. They're very aggressive and potentially destructive so I advise caution. They will hunt the system for patchable executables, inject them, and save the original file according to the suffix parameter. With --delete_original, the original untouched executable goes away, leaving behind the injected copy. The --injector module will even check to see whether the target is running and if so, shut it down, inject it, then attempt to restart it.
• --support_check allows BDF to determine whether the target can be injected without attempting to do so. This check is done when you try to inject a file anyway, so this can be useful for research.
• --cave-miner is for adapting our shellcode generation to fit the target executable rather than the other way around—it helps us to find the smallest possible payload that can fit into one of the available caves.
• --verbose is for debugging the injection process.
• --image-type= lets you identify the binaries to be patched as x86 or x64 (or both). The default is both.
• --beacon= is for payloads that can send out beacons or heartbeats. This option takes an interval in seconds as the argument.
• --xp_mode enables your creation to run on Windows XP. That's right: by default, a BDF Trojan will crash on XP. This is a sandbox countermeasure: as XP is becoming less and less popular as an actual home (or production) operating system, it's still finding use in VMs and other environments where you can detonate digital explosives without fear of damaging something valuable. Of course, modern sandboxing takes place in any operating system you please, so this option won't make an enormous difference. Be aware of it in the event that you're explicitly targeting XP—plenty of production environments still use XP for application compatibility reasons.
• --code_sign is very useful in the case of secure environments that only trust signed code. This allows you to sign your creation with your own signing certificate and private key. Naturally, you won't possess legitimate ones for some major software maker (right?), but if the check is for the simple fact that the code is signed with any certificate, then this option is very handy. If you aren't signing your file, then you need to pass --zero_cert.

This tool gives us quite a bit of control over the injection process. With this kind of low-level control, we can understand our projects more intimately and fine-tune our Trojans according to our needs. Let's go ahead and pick an executable that will become our infected program, and do some low-level analysis.