TORUM.txt


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

This is the beginning of a series of coding tutorials.

The goal is that I may teach some (grey|black|shit)heads about
useless stuff and vice versa.

I took this whole sample from my first exec crypter solution which is outdated.
So C&P might raise the AV alarms. However I was quite surprised how bad the
detection ratio was. But more on it later.

[b]Caution[/b]:
Before you start copy and pasting my stuff you should be aware that I'm using
well-known malware (mirai in this case) to show that the crypter is working.
It is highly advised to use a [b]VM[/b] without network access to test this repo or
use at least the inoffensive payload
aka exec_payload. Mirai detects if it gets executed in a [b]VM[/b] but it is enough
to show that the crypter works. Although all mirai CNC servers are shutdown afaik.

[b]Get the repo[/b]:
The source is located at Tochka's (ty for your git service <3) github like GOGS onion page which
you can access here:
[code]http://qxklmrhx7qkzais6.onion/segfault/Torum-Tutorial-00[/code]

[b]Build it[/b]:
[code]
make # default build using unoffensive exec_payload
make USE_MIRAI=y # use mirai as payload
make USE_PAYLOAD # use custom payload
make DEBUG=y # disable symbol/section stripping and produce dbg syms
[/code]

[b]Run it[/b]:
[b][i]Do this at your own risk if USE_MIRAI=y ![/i][/b]
You can now run the crypter:
[code]./exec_crypter[/code]
The first run detects that the payload is not encrypted and encrypt it.
The second will recognize that the payload is already encrypted, decrypt and run it.

[b]How it works[/b] (assuming a successful run):
[list=1]
[*] open the crypter executable and create a file for temp storage
[*] copy the crypter executable into the temp file using sendfile
[*] memory map the temp file into memory
[*] search for the unique marker which marks the beginning of our payload trailer struct
[*] Encryption:
[*] if xor key contains only NUL bytes, assume that the payload is stored as plain text
[*] if payload is stored as plain text, generate a xor key and encrypt the payload in out mmap'd buffer
[*] Decryption:
[*] if payload is encrypted (at least one not NUL byte in xor key), open a new temp file, copy the payload there using sendfile
[*] run the payload and at try to unlink the file after execution
[/list]

[b]Remarks[/b]:
The payload is stored in a section named [b].payload[/b] which means that you can't change the size of the payload after it
is linked in the resulting executable (well it is possible but needs a lot more work to achieve this). The payload itself gets
included by nasm (see [b]include_payload.asm[/b]) which also sets up the initial trailer struct.
The used encryption mechanism is all but [b]not secure[/b] since it uses a simple XOR ECB algorithm (no IVs, no block chaining).
But still enough to bypass all AV solutions, lol...

[b]Result[/b]:
I was actually quite surprised that this old and very basic crypter results in a zero detection ratio for well-known malware e.g. mirai.
There are probably two reasons why no linux/ELF AV scanner detects it:
[list=2]
[*] they don't use behavioral analysis e.g. a sandboxed execution environment
[*] they don't hook execve/execveat
[/list]

Feel free to comment and improve this crappy old source..
I will upload new tutorials in the upcoming weeks .. e.g. code injection/polymorphic code obfuscation/direct syscall invocation/whatsoever

(*segfault)