matro7sh / 221b Goto Github PK

to prevent the packer from being overflagged, flags should be added to modify the final result slightly
for example, the possibility of modifying the duration of sleep
or store shellcode in .text instead of .data, or even another section

The variable names in the templates should be changed randomly, so that different signatures can be obtained each time

this option should also be a flag

in fact, when a payload has a correct icon and signature, it reduces its chances of being triggered.

Ex : https://github.com/paranoidninja/CarbonCopy

it could be fun and useful to implement a system like this one

package main

import (
	"bytes"
	"compress/zlib"
	"crypto/rand"
	"io"
	"os"
)

func polymorph() {
}

func main() {
	// part of the code that will not change 
	code := []byte(`
		package main

		import "fmt"

		func main() {
			fmt.Println("pwn")
		}
	`)

	polymorph()
	var compressedCode bytes.Buffer
	writer := zlib.NewWriter(&compressedCode)
	writer.Write(code)
	writer.Close()

	key := make([]byte, 32)
	rand.Read(key)

	file, _ := os.Create("packed_binary")

	defer file.Close()
	file.Write(key)
	file.Write(compressedCode.Bytes())
}

As you can see below, some functions appear in plain text inside the binary :

to hide this, here's a technique (example in cpp ):

// sVirtualAllocEx  = xor of string "VirtualAlloc" with key (outside of the packer)
unsigned char sVirtualAllocEx[] = { 0x3b, 0x10, 0x1, 0x11, 0x16, 0xa, 0x6, 0x28, 0x1};

// xor second time to obtain the plain text string 
XOR((char *) sVirtualAllocEx, sizeof(sVirtualAllocEx), key, sizeof(key));

// call the fonction
pVirtualAllocEx = GetProcAddress(GetModuleHandle("kernel32.dll"), sVirtualAllocEx);

in the end, we add an abstraction layer, so that if we run the "strings" command again, we won't see our function appear.

Currently it is possible to specify a shellcode and a key,
but the binary is stored in the folder where the binary is located.
It might be nice to be able to choose the final name and destination path

This tool need a proper CI/CD with:

• A linter that run in Ga
• Unit test that run in GA
• A release process

We can use dagger to do so, this only require Docker to run in local.

Another amazing feature would be to create dynamic container that can execute an example of binary to verify if it can be correctly executed. However, It's complex to do so we can stick to a simple CI/CD for now!

It would be good to add a check against sandboxes, in case we're in them, then we mustn't execute the malicious load.
there are several methods, many of the techniques are listed here: https://evasions.checkpoint.com/

I am getting this error below. Kindly help with the approach to get it fixed.

`/home/iprimes3c/go/pkg/mod/golang.org/x/[email protected]/windows/zsyscall_windows.go:4352:30: error: too many arguments
4352 | r1, _, e1 := syscall.Syscall(procWTSQueryUserToken.Addr(), 2, uintptr(session), uintptr(unsafe.Pointer(token)), 0)
| ^
[!] failed to compile
[!] exit status 2

`

At present, the XOR method works correctly,
but it would be interesting to implement one part for AES and another for ChaCha20.

useful implementation links :
https://pkg.go.dev/golang.org/x/crypto/chacha20
https://github.com/CMEPW/myph/blob/main/loader/aes.go

The user should be given the option of either grafting onto an existing process or launching the payload as a process.

./221b bake -m aes -k "0123456789ABCDEF1123345611111111" -s /PathToShellcode.bin -o sherlock_aes.exe -p msteams.exe

if the user doesn't specify the -p flag, this will create a simple process