Mitigate string encryption deobfuscation

[pagran]

Here are two ideas to make string deobfuscation more challenging:

1. Random Constants as Function Parameters

Move some random constants into the parameters of the deobfuscation function. This will force analysts to examine the function's call sites and extract all the necessary parameters, making deobfuscation significantly harder:

package main

func main() {
	println(string(func(c1 byte, c2 byte) string {
		data := []byte("ၯ\x88\x8f\xf1\xfcorld")
		positions := [...]byte{4, 1, 5, 2, 6, 2, 3, 1, 0, 6, c1, 1}
		for i := 0; i < 12; i += 2 {
			localKey := byte(i) + byte(positions[i]^positions[i+1]) + c2
			data[positions[i]], data[positions[i+1]] = data[positions[i+1]]+localKey, data[positions[i]]+localKey
		}
		return string(data)
	}(4, 104)))
}

2. Proxying string(data) Calls

The string(data) call is a key marker used for string deobfuscation. By introducing a proxy function for this operation, we can obscure the decryption mechanism and complicate automatic deobfuscation attempts.

package main

func main() {
	println(string(func() string {
		type proxy struct {
			a func([]byte) float64
			b func([]byte) float64
			c func([]byte, int, int, int) string
			d func([]byte) float64
		}
		x := proxy{c: func(bytes []byte, a int, b int, c int) string {
			return string(bytes)
		}}

		data := []byte("ၯ\x88\x8f\xf1\xfcorld")
		positions := [...]byte{4, 1, 5, 2, 6, 2, 3, 1, 0, 6, 4, 1}
		for i := 0; i < 12; i += 2 {
			localKey := byte(i) + byte(positions[i]^positions[i+1]) + 104
			data[positions[i]], data[positions[i+1]] = data[positions[i+1]]+localKey, data[positions[i]]+localKey
		}
		return x.c(data, 9, 9, 9)
	}()))
}

Interested in your opinions @mvdan @lu4p, does it make sense to implement something like this

[lu4p]

@pagran I'm in full support of breaking deobfuscation.

Although in the end it can always be deobfuscated I would like to learn some more obfuscation and deobfuscation techniques.

mandiant/gostringungarbler#1

[pagran]

first try:

package main

import "fmt"

func main() {
	fmt.Println(func(_ek_0 uint64, _ek_1 uint8, _ek_2 uint32, _ek_3 uint64, _ek_4 uint8, _ek_5 uint8, _ek_6 uint64, _ek_7 uint16) string {
		key := []byte("\xf2M\xb1\xc0\xe2-\x9a\x84\xc1!y^\xb7\x9b\xba^\x99\xc2;w\xb5+\xfa\x8b\x8be,\xd9\r\xbc\xcc\xdb\x00\x0e\xd55\xd6\xf0.奝\xd3C\xaae\x18ҝ\x9b\x8c\xfe:")
		data := []byte("v\x18\xbb\xac\x8d\xf3\x1c\b\xb1K8ªƧ\x03\xc8\xe1&\x91\xac6gֺ\xfc5\x88T\xa5\x95\x86aS\x8cp\x8b*3|\xbcĎ\x1e\xb7\xfcI\x8f\xc4\xc6\xd5c'")
		{
			key[17] = key[17] ^ byte(_ek_2)
			key[10] = key[10] + byte(_ek_1)
			key[24] = key[24] ^ byte(_ek_0)
		}
		for i, b := range key {
			data[i] = data[i] + b
		}
		{
			data[19] = data[19] + byte(_ek_7)
			data[6] = data[6] - byte(_ek_6)
			data[35] = data[35] ^ byte(_ek_5)
			data[37] = data[37] ^ byte(_ek_4)
			data[7] = data[7] + byte(_ek_3)
		}
		return string(data)
	}(15167845609759427372, 179, 1099948866, 14512909065460794083, 123, 196, 17667013852476592959, 13657))
}

but I don't yet understand why ast generates incorrect code

[lu4p]

I think we should avoid string(data) completely by implementing our own version of slicebytetostring, maybe also throw some amount of control flow obfuscation in to make it harder to pattern match.
https://github.com/golang/go/blob/577bb3d0ce576b2ca311e58dd942f189838b80fc/src/runtime/string.go#L131

Just a thought maybe we could also make string deobfuscation dependent on order of execution, if we know a will always execute before b we can insert an incorrect/ incomplete state into b, which is only set to the correct state after a is executed (we can also make this transient a -> b -> c -> d).

This could be done for global variables (they're always executed in the same order). And in a function where we can flag all deobfuscation functions which will definitely run and use them to build the state for others (we can also require that these functions only return the correct strings after all global variables are deobfuscated).

[lu4p]

but I don't yet understand why ast generates incorrect code

@pagran Feel free to share a link to a branch. I can take a look at what's happening.

[pagran]

@lu4p https://github.com/pagran/garble/tree/string-pattern-fix

It is PoC and only simple obfuscator is adapted for external keys (the others I turned off) - 2be2233#diff-32ec1c48ba61ccb25e0669c1523e873fd1902b38b39f314671cf9178ccb12a4cR20

[pagran]

I think we should avoid string(data) completely by implementing our own version of slicebytetostring,

This is a good idea, but it would require importing unsafe everywhere. In addition, with unsafe you can make mutable strings and do very fun things :)

[lu4p]

@pagran You're using fmt.Sprintln here , should be fmt.Sprint.

[pagran]

compiler is smart, sometimes it can inline all parameters

[eybisi]

Sometimes, even runs decryption function to help analysts :)

But, main headache for automatic analysis comes from compiler optimization, it inlines most of the string decryption functions.