Why The BackdoorFactory
Yes. I've questioned myself on the name: Backdoor Factory. Early on in it's release, the Google search for my own tool comes up with some interesting results. I don't have the courage to click the "Willy Wonka and the Backdoor Factory" link that ends up in the results:
Alas, I probably could have picked a better name.
No matter, time to sleep in the bed I made.
Backdoor Factory (BdF or BDF) is the result of taking the Cracking the Perimeter from Offensive Security. During the CTP, you learn to patch PE files by hand, among other awesome things. However, I like automation. Although it's taken a lot of time to write BDF, the ability to patch both PE and ELF file formats has taught me a lot about how windows and linux OS'es work as far as loading each format into memory and linking.
Now I'm working on BDFProxy, patching binaries over HTTP(S) via a transparent proxy MITM style. I have have a full working demo using a wifi pineapple as a wireless AP with a VM running BDFProxy with two NICs. It's fast, multi-threaded, and will support archive files (zip, tar). Release timeline will depend on Con acceptance. :)
Here, I made a diagram:
<Internet>---<BDFPROXY>----<Evil AP>
Also, I'm looking into the Mach-o format. Similar to ELF, but not. Like the 90's version of the Red Hot Chilli Peppers compared to the 00's version. Once Mach-o is supported, I'll be moving on to ARM chipsets.
But before ARM, I want to dive into import address table (IAT) patching. Not hooking. Patching. Let's think about this. There has been plenty of writing about hooking the IAT and let's face it, if it's on CodeProject or Infosec Institute, it's been out there a long time. Patching the IAT would include adding thunks for each API call that you need to complete the functionality of your shellcode. I think by adding the necessary thunks to a BDF target binary, we could take a 380 byte shellcode (reverse tcp) and shorten it to less than 200 bytes by removing Steven Fewer's API lookup shellcode. Yes, it's not position independent, but if you are patching a binary, you don't need to be position independent; you should know where you are in memory at any given instruction before even running your executable. I have a feeling this will defeatmost all AVs as you will be making legitimate API calls. As a bonus this should defeat the EMET's caller protection (ROP protection, which works only on 32 bit anyway). I hope to have this done by Fall 2014.
So why BDF?
To learn binary executable formats, to show everyone that HTTPS should be everywhere and whitelisting should be easy to implement/come standard on OS'es, and to show that AVs really don't work.
Alas, I probably could have picked a better name.
No matter, time to sleep in the bed I made.
Backdoor Factory (BdF or BDF) is the result of taking the Cracking the Perimeter from Offensive Security. During the CTP, you learn to patch PE files by hand, among other awesome things. However, I like automation. Although it's taken a lot of time to write BDF, the ability to patch both PE and ELF file formats has taught me a lot about how windows and linux OS'es work as far as loading each format into memory and linking.
Now I'm working on BDFProxy, patching binaries over HTTP(S) via a transparent proxy MITM style. I have have a full working demo using a wifi pineapple as a wireless AP with a VM running BDFProxy with two NICs. It's fast, multi-threaded, and will support archive files (zip, tar). Release timeline will depend on Con acceptance. :)
Here, I made a diagram:
<Internet>---<BDFPROXY>----<Evil AP>
Also, I'm looking into the Mach-o format. Similar to ELF, but not. Like the 90's version of the Red Hot Chilli Peppers compared to the 00's version. Once Mach-o is supported, I'll be moving on to ARM chipsets.
But before ARM, I want to dive into import address table (IAT) patching. Not hooking. Patching. Let's think about this. There has been plenty of writing about hooking the IAT and let's face it, if it's on CodeProject or Infosec Institute, it's been out there a long time. Patching the IAT would include adding thunks for each API call that you need to complete the functionality of your shellcode. I think by adding the necessary thunks to a BDF target binary, we could take a 380 byte shellcode (reverse tcp) and shorten it to less than 200 bytes by removing Steven Fewer's API lookup shellcode. Yes, it's not position independent, but if you are patching a binary, you don't need to be position independent; you should know where you are in memory at any given instruction before even running your executable. I have a feeling this will defeat
So why BDF?
To learn binary executable formats, to show everyone that HTTPS should be everywhere and whitelisting should be easy to implement/come standard on OS'es, and to show that AVs really don't work.
Comments
Post a Comment