|
1 | 1 | # ldrgen |
2 | 2 |
|
3 | | -ldrgen is a golang cli tool for rapid generation of shellcode loaders using pre-defined templates. |
| 3 | +**ldrgen** allows operators to generate shellcode loaders from a set of pre-defined templates and profiles with the aim of hopefully streamlining development and reducing the time it takes to get a new loader out the door. |
4 | 4 |
|
5 | | -> ⚠️ this tool is meant to help with running beacon from disk, this does **not** help with evasion for memory scans or post-exploitation- OPSEC considerations are up to the discretion of the operator. |
| 5 | +> Also, because encrypting raw shellcode, then parsing it into a stageless loader is a _pain_ |
6 | 6 |
|
7 | 7 | ## Getting Started |
8 | 8 | There are available binaries on the [releases](https://github.com/gatariee/ldrgen/releases) page, or you can build from source for the latest version. |
9 | 9 |
|
10 | | -### Releases |
11 | | -Standalone binaries are available, however you will need a `templates` directory to be ingested by the generator. You can find the latest templates from source [here](./templates/) or it should be included as a zip file in the release. |
| 10 | +### Usage |
| 11 | +```bash |
| 12 | +ldrgen profile --profile [path_to_profile] --shellcode [path_to_shellcode] |
| 13 | +``` |
| 14 | + |
| 15 | + |
| 16 | +### How does it work? |
| 17 | +* Source files (`*.c`) or loaders are saved as templates in the `templates` directory, placeholders are also supported to be templated during generation. |
| 18 | +* The template configuration is saved as [`config.yaml`](./templates/config.yaml) in the `templates` directory, this contains information about the loader, what source files it requires and whether any substitutions are required. |
| 19 | +* Profiles are saved in the `profiles` directory, these can be used and customized to your personal preference to utilize the templates you've created. |
| 20 | + |
| 21 | +#### Source |
| 22 | +These are your loaders, most of the time these are the artifacts that get caught by AV. Put some effort into making some of these in your own time, and you'll have a nice collection of loaders to use! |
| 23 | + |
| 24 | +[CreateThread_Xor.c](./templates/Source/CreateThread_Xor.c) is a good example of a simple loader that uses `CreateThread` to execute shellcode. It also has a `xorShellcode` function that will decrypt the shellcode before execution. |
| 25 | +```c |
| 26 | +... |
| 27 | + |
| 28 | + xorShellcode( shellcode, shellcode_size, "${KEY}" ); |
| 29 | + |
| 30 | +... |
| 31 | +``` |
12 | 32 |
|
13 | | -Templates are expected to be in the same directory as where the binary is executed, but you can specify with the `--template` flag. |
| 33 | +#### Templates |
| 34 | +The ${KEY} placeholder is explicitly defined in the `config.yaml` file, and is used to substitute the key used to decrypt the shellcode. This is a simple example of how to use placeholders in your templates. |
| 35 | +```yaml |
| 36 | + - token: "createthread_xor" |
| 37 | + key_required: true |
| 38 | + enc_type: "xor" |
| 39 | + method: "VirtualAlloc, xorShellcode, memcpy, CreateThread, WaitForSingleObject" |
| 40 | + files: |
| 41 | + - sourcePath: "Source/CreateThread_Xor.c" |
| 42 | + outputPath: "Main.c" |
| 43 | + substitutions: |
| 44 | + key: "${KEY}" |
| 45 | +
|
| 46 | + - sourcePath: "Source/Xor.c" |
| 47 | + outputPath: "Xor.c" |
| 48 | + |
| 49 | + - sourcePath: "Include/Xor.h" |
| 50 | + outputPath: "Xor.h" |
| 51 | +
|
| 52 | + - sourcePath: "makefile" |
| 53 | + outputPath: "makefile" |
| 54 | +``` |
| 55 | + |
| 56 | +#### Profiles |
| 57 | +These are malleable configurations that can be used to generate a loader from a template. |
| 58 | +```json |
| 59 | +{ |
| 60 | + "name": "Default Loader, but with XOR (CreateThread)", |
| 61 | + "author": "@gatari", |
| 62 | + "description": "A simple shellcode loader that uses CreateThread with XOR encrypted shellcode.", |
| 63 | + "template": { |
| 64 | + "path": "/opt/tools/ldrgen/templates/config.yaml", |
| 65 | + "token": "CreateThread_Xor", |
| 66 | + "enc_type": "xor", |
| 67 | + "substitutions": { |
| 68 | + "key": "as@&(!L@J#JKsn" |
| 69 | + } |
| 70 | + }, |
| 71 | + "arch": "x64", |
| 72 | + "compile": { |
| 73 | + "automatic": true, |
| 74 | + "make": "make", |
| 75 | + "gcc": { |
| 76 | + "x64": "x86_64-w64-mingw32-gcc", |
| 77 | + "x86": "i686-w64-mingw32-gcc" |
| 78 | + }, |
| 79 | + "strip": { |
| 80 | + "i686": "strip", |
| 81 | + "x86_64": "strip" |
| 82 | + } |
| 83 | + }, |
| 84 | + "output_dir": "./createthreadxor" |
| 85 | +} |
| 86 | +``` |
| 87 | + |
| 88 | +### Releases |
| 89 | +Standalone binaries are available, however `templates` and `profiles` will be ingested by `ldrgen`. The latest release should have these included. |
14 | 90 |
|
15 | 91 | ### Building from Source |
16 | 92 | ```bash |
17 | | -cd ldrgen/src |
| 93 | +cd ldrgen |
18 | 94 | make build |
| 95 | +``` |
| 96 | + |
| 97 | +### Design Principles |
| 98 | +This tool is **not** designed to be turing complete by any means, it's designed to **streamline** the process of developing loaders- it is ultimately up to the operator to develop their own loaders and templates should they wish to do so. |
| 99 | + |
| 100 | +`ldrgen` started as a personal project for encrypting beacon shellcode, then parsing it into a header file for use in a stageless loader. It was a pain to do this manually, so I decided to automate it- and it built from there. |
19 | 101 |
|
20 | | -cd bin |
21 | | -ldrgen --help |
22 | | -``` |
| 102 | +### Contributing |
| 103 | +If you'd like to contribute, feel free to open a PR or an issue. I'm always open to suggestions and improvements. However, before you make an issue, do remember that the objective of this tool is to streamline the process of developing loaders, not to be provide a cheat code for bypassing AV. |
0 commit comments