Skip to content

Commit 90dfc5d

Browse files
committed
Updated with some core functions
1 parent cf3fc13 commit 90dfc5d

File tree

4 files changed

+186
-2
lines changed

4 files changed

+186
-2
lines changed

CONTRIBUTING.md

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
# CONTRIBUTING
2+
How to write modules for TitanFall
3+
4+
## Writing Payloads
5+
Please make sure all of the following guidelines are implemented into the payload:
6+
1. The first line in your file must be a comment with a very brief description of what the payload
7+
does.
8+
2. The second line of the file should list all the function dependancies of the
9+
payload.
10+
2. No output (stdin or stderr) should be created unless it is with the "LOG" command
11+
3. All payloads should run in both SH and BASH
12+
4. Payloads must follow the naming convention. See [Naming conventions](#naming-conventions)
13+
5. Each payload needs a function that is named the _payload name_ in order to be
14+
called by the dropper. This function should be considered the _main_ of your payload.
15+
6. Payloads should handle error checking on their own and should not hold up the main program
16+
7. Payloads should NEVER exit the program. Instead return out of the main function.
17+
18+
### Naming Conventions
19+
1. The _payload name_ and _filename_ are different
20+
2. Each payload name must be unique to the other payloads
21+
3. Payload names should be lowercase
22+
4. Each payload name must be one word with letters only. No spaces, underscores, or other characters.
23+
5. The filename will be the payload name with at most __one__ file extension
24+
25+
### Directory Layout
26+
Sub groups of payloads may be made within the "payloads" directory for organization
27+
Folder names do not matter and are solely for the authors.
28+
29+
## Tips and Tricks
30+
### Ordering Payloads
31+
Each payload can be assigned a weight. The default weight is 50. The higher the weight, the higher the priority.
32+
Payloads are run from greatest weight to least weight.
33+
To specify the weight, add a comment to the top of the payload like so
34+
```
35+
# WEIGHT 99
36+
```
37+
38+
### Suppressing output
39+
If you suspect a command will generate output, prefix the command with `QUIET`.
40+
Example
41+
```
42+
QUIET echo hi; # No output printed
43+
```
44+
45+
Avoid using `&>/dev/null` as that will not work in SH
46+
47+
### Validating Commands
48+
Avoid using `which` as it is system dependent.
49+
To check if a program is on the system, try the following
50+
```
51+
QUIET command -v ncat;
52+
if [ "$?" != "0" ]; then
53+
LOG 2 "ncat doesn't exist!";
54+
return 1;
55+
fi
56+
```
57+
### If statements
58+
In order to comply with SH if statements, use the following rules:
59+
1. You __cannot__ have double brackets. e.g. `[[ 1 = 1 ]]`
60+
2. You __cannot__ have double equal signs. e.g. `[ 1 == 1 ]`
61+
3. A space must be left on the inside of the brackets. This is __invalid__ `[1 = 1]`
62+
4. Always surround both sides of the operator in quotes. e.g `[ "1" = "$foo" ]`
63+
5. If you need to compare two numbers, make sure you use the following Bourne comparisons rather
64+
than traditional programming operators
65+
66+
67+
| Operator | Bourne Operator | Example |
68+
|----------|-----------------|----------------------|
69+
|`==` |`=` | `[ "1" = "$foo" ]` |
70+
|`!=` |`!=` | `[ "1" != "$foo" ]` |
71+
|`>=` |`-ge` | `[ "1" -ge "$foo" ]` |
72+
|`<` |`-lt` | `[ "1" -lt "$foo" ]` |
73+
|`>` |`-gt` | `[ "1" -gt "$foo" ]` |
74+
|`<=` |`-le` | `[ "1" -le "$foo" ]` |
75+
|`>=` |`-ge` | `[ "1" -ge "$foo" ]` |
76+
77+
A valid if statement should look like this:
78+
```
79+
foo="hello";
80+
if [ "$foo" = "hi" ]; then
81+
LOG "hi foo!";
82+
elif [ "$foo" = "hello" ]; then
83+
LOG "hello foo!";
84+
else
85+
LOG "foo?";
86+
fi
87+
```
88+
89+
__Ternary Statements__ can be done in the following way
90+
```
91+
[ "$foo" = "$bar" ] && LOG 0 "TRUE" || LOG 2 "FALSE";
92+
```
93+
94+
### Logging output
95+
TitanFall will handle all the printing. When the dropper is generated, the program can either log
96+
all message in color, without color, or no messages at all.
97+
98+
> If the dropper is generated with no output, LOG will display nothing. Do not try to circumvent
99+
this
100+
101+
A successful message will be green if color is enabled
102+
A pending message will be blue if color is enabled
103+
An error message will be red if color is enabled
104+
A warning message will be yellow
105+
All other messages will be without color
106+
107+
To print success/in progress/error messages, use the LOG function in the following way:
108+
```
109+
> LOG 0 "Payload dropped!"
110+
[+] Payload dropped
111+
112+
> LOG 1 "Uploading files..."
113+
[*] Uploading files...
114+
115+
> LOG 2 "Error in program"
116+
[-] Error in program
117+
118+
> LOG warn "This is a warning"
119+
[!] This is a warning
120+
121+
> LOG "Plain old message"
122+
Plain old message
123+
```

README.md

Lines changed: 13 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,15 @@
11
# TrainingWheelsProtocol
2-
TitanFall modules for adding low hanging fruit on a system.
2+
Payloads and functions for the [TitanFall](https://github.com/micahjmartin/TitanFall) dropper system.
3+
These modules are for adding low hanging fruit on a system and are things that are meant to be found by the blueteam
34

4-
These are things that are meant to be found by the blueteam
5+
6+
## Payload files vs Function files
7+
* Payload files are one or more functions that get called directly by the
8+
dropper.
9+
10+
* Function files contain a single function that will not get run unless it is
11+
called by a payload.
12+
13+
14+
All payload files will be found in the `payloads` folder. Function files should
15+
be placed in the `functions` folder.

functions/CORE.sh

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# CORE functions that TitanFall depends on
2+
# Suppress the output of a command and return the result
3+
QUIET (){
4+
eval $@ 2>/dev/null >/dev/null
5+
return $?
6+
}
7+
8+
# Destroys a file and returns the status
9+
DESTROY() {
10+
[ "$1" = "" ] && return 1
11+
OPENFILE $1
12+
# Try to shred the file
13+
QUIET command -v shred
14+
[ $? = 0 ] && shred $1
15+
# Try to remove the file
16+
rm -f $1
17+
if [ "$?" != 0 ]; then
18+
# If you cant remove it, overwrite it
19+
head -n 100 /dev/urandom > $1
20+
fi
21+
res=$?
22+
}
23+
24+
INIT() {
25+
LOG 1 "Standbye for TitanFall"
26+
TRAP
27+
}
28+
29+
FINISH() {
30+
LOG warn "Deleting self..."
31+
QUIET shred $0;
32+
rm -fr $0 && exit;
33+
}
34+

functions/GET_FILE.sh

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
# Provides the functionality of wget
2+
GET_FILE() {
3+
# If no argument is given, return
4+
[ "$1" = "" ] && return 1;
5+
[ "$2" = "" ] && return 1;
6+
QUIET command -v "wget";
7+
get_w="$?";
8+
# Check if any methods exist
9+
if [ "$get_w" != "0" ]; then
10+
LOG 2 "No downloads available";
11+
return 1;
12+
fi;
13+
QUIET wget -qO $2 $1;
14+
return $?;
15+
};
16+

0 commit comments

Comments
 (0)