|
|
|
// Copyright (c) 2020, The Garble Authors.
|
|
|
|
// See LICENSE for licensing information.
|
|
|
|
|
|
|
|
package literals
|
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"go/ast"
|
|
|
|
"go/token"
|
|
|
|
mathrand "math/rand"
|
|
|
|
)
|
|
|
|
|
|
|
|
// obfuscator takes a byte slice and converts it to a ast.BlockStmt
|
|
|
|
type obfuscator interface {
|
avoid using math/rand's global funcs like Seed and Intn
Go 1.20 is starting to deprecate the use of math/rand's global state,
per https://go.dev/issue/56319 and https://go.dev/issue/20661.
The reasoning is sound:
Deprecated: Programs that call Seed and then expect a specific sequence
of results from the global random source (using functions such as Int)
can be broken when a dependency changes how much it consumes from the
global random source. To avoid such breakages, programs that need a
specific result sequence should use NewRand(NewSource(seed)) to obtain a
random generator that other packages cannot access.
Aside from the tests, we used math/rand only for obfuscating literals,
which caused a deterministic series of calls like Intn. Our call to Seed
was also deterministic, per either GarbleActionID or the -seed flag.
However, our determinism was fragile. If any of our dependencies or
other packages made any calls to math/rand's global funcs, then our
determinism could be broken entirely, and it's hard to notice.
Start using separate math/rand.Rand objects for each use case.
Also make uses of crypto/rand use "cryptorand" for consistency.
Note that this requires a bit of a refactor in internal/literals
to start passing around Rand objects. We also do away with unnecessary
short funcs, especially since math/rand's Read never errors,
and we can obtain a byte via math/rand's Uint32.
2 years ago
|
|
|
obfuscate(obfRand *mathrand.Rand, data []byte) *ast.BlockStmt
|
|
|
|
}
|
|
|
|
|
|
|
|
var (
|
|
|
|
simpleObfuscator = simple{}
|
|
|
|
|
|
|
|
// Obfuscators contains all types which implement the obfuscator Interface
|
|
|
|
Obfuscators = []obfuscator{
|
|
|
|
simpleObfuscator,
|
|
|
|
swap{},
|
|
|
|
split{},
|
|
|
|
shuffle{},
|
|
|
|
seed{},
|
|
|
|
}
|
|
|
|
|
|
|
|
// LinearTimeObfuscators contains all types which implement the obfuscator Interface and can safely be used on large literals
|
|
|
|
LinearTimeObfuscators = []obfuscator{
|
|
|
|
simpleObfuscator,
|
|
|
|
}
|
|
|
|
|
|
|
|
TestObfuscator string
|
|
|
|
testPkgToObfuscatorMap map[string]obfuscator
|
|
|
|
)
|
|
|
|
|
avoid using math/rand's global funcs like Seed and Intn
Go 1.20 is starting to deprecate the use of math/rand's global state,
per https://go.dev/issue/56319 and https://go.dev/issue/20661.
The reasoning is sound:
Deprecated: Programs that call Seed and then expect a specific sequence
of results from the global random source (using functions such as Int)
can be broken when a dependency changes how much it consumes from the
global random source. To avoid such breakages, programs that need a
specific result sequence should use NewRand(NewSource(seed)) to obtain a
random generator that other packages cannot access.
Aside from the tests, we used math/rand only for obfuscating literals,
which caused a deterministic series of calls like Intn. Our call to Seed
was also deterministic, per either GarbleActionID or the -seed flag.
However, our determinism was fragile. If any of our dependencies or
other packages made any calls to math/rand's global funcs, then our
determinism could be broken entirely, and it's hard to notice.
Start using separate math/rand.Rand objects for each use case.
Also make uses of crypto/rand use "cryptorand" for consistency.
Note that this requires a bit of a refactor in internal/literals
to start passing around Rand objects. We also do away with unnecessary
short funcs, especially since math/rand's Read never errors,
and we can obtain a byte via math/rand's Uint32.
2 years ago
|
|
|
func genRandIntSlice(obfRand *mathrand.Rand, max, count int) []int {
|
|
|
|
indexes := make([]int, count)
|
|
|
|
for i := 0; i < count; i++ {
|
avoid using math/rand's global funcs like Seed and Intn
Go 1.20 is starting to deprecate the use of math/rand's global state,
per https://go.dev/issue/56319 and https://go.dev/issue/20661.
The reasoning is sound:
Deprecated: Programs that call Seed and then expect a specific sequence
of results from the global random source (using functions such as Int)
can be broken when a dependency changes how much it consumes from the
global random source. To avoid such breakages, programs that need a
specific result sequence should use NewRand(NewSource(seed)) to obtain a
random generator that other packages cannot access.
Aside from the tests, we used math/rand only for obfuscating literals,
which caused a deterministic series of calls like Intn. Our call to Seed
was also deterministic, per either GarbleActionID or the -seed flag.
However, our determinism was fragile. If any of our dependencies or
other packages made any calls to math/rand's global funcs, then our
determinism could be broken entirely, and it's hard to notice.
Start using separate math/rand.Rand objects for each use case.
Also make uses of crypto/rand use "cryptorand" for consistency.
Note that this requires a bit of a refactor in internal/literals
to start passing around Rand objects. We also do away with unnecessary
short funcs, especially since math/rand's Read never errors,
and we can obtain a byte via math/rand's Uint32.
2 years ago
|
|
|
indexes[i] = obfRand.Intn(max)
|
|
|
|
}
|
|
|
|
return indexes
|
|
|
|
}
|
|
|
|
|
avoid using math/rand's global funcs like Seed and Intn
Go 1.20 is starting to deprecate the use of math/rand's global state,
per https://go.dev/issue/56319 and https://go.dev/issue/20661.
The reasoning is sound:
Deprecated: Programs that call Seed and then expect a specific sequence
of results from the global random source (using functions such as Int)
can be broken when a dependency changes how much it consumes from the
global random source. To avoid such breakages, programs that need a
specific result sequence should use NewRand(NewSource(seed)) to obtain a
random generator that other packages cannot access.
Aside from the tests, we used math/rand only for obfuscating literals,
which caused a deterministic series of calls like Intn. Our call to Seed
was also deterministic, per either GarbleActionID or the -seed flag.
However, our determinism was fragile. If any of our dependencies or
other packages made any calls to math/rand's global funcs, then our
determinism could be broken entirely, and it's hard to notice.
Start using separate math/rand.Rand objects for each use case.
Also make uses of crypto/rand use "cryptorand" for consistency.
Note that this requires a bit of a refactor in internal/literals
to start passing around Rand objects. We also do away with unnecessary
short funcs, especially since math/rand's Read never errors,
and we can obtain a byte via math/rand's Uint32.
2 years ago
|
|
|
func randOperator(obfRand *mathrand.Rand) token.Token {
|
|
|
|
operatorTokens := [...]token.Token{token.XOR, token.ADD, token.SUB}
|
avoid using math/rand's global funcs like Seed and Intn
Go 1.20 is starting to deprecate the use of math/rand's global state,
per https://go.dev/issue/56319 and https://go.dev/issue/20661.
The reasoning is sound:
Deprecated: Programs that call Seed and then expect a specific sequence
of results from the global random source (using functions such as Int)
can be broken when a dependency changes how much it consumes from the
global random source. To avoid such breakages, programs that need a
specific result sequence should use NewRand(NewSource(seed)) to obtain a
random generator that other packages cannot access.
Aside from the tests, we used math/rand only for obfuscating literals,
which caused a deterministic series of calls like Intn. Our call to Seed
was also deterministic, per either GarbleActionID or the -seed flag.
However, our determinism was fragile. If any of our dependencies or
other packages made any calls to math/rand's global funcs, then our
determinism could be broken entirely, and it's hard to notice.
Start using separate math/rand.Rand objects for each use case.
Also make uses of crypto/rand use "cryptorand" for consistency.
Note that this requires a bit of a refactor in internal/literals
to start passing around Rand objects. We also do away with unnecessary
short funcs, especially since math/rand's Read never errors,
and we can obtain a byte via math/rand's Uint32.
2 years ago
|
|
|
return operatorTokens[obfRand.Intn(len(operatorTokens))]
|
|
|
|
}
|
|
|
|
|
|
|
|
func evalOperator(t token.Token, x, y byte) byte {
|
|
|
|
switch t {
|
|
|
|
case token.XOR:
|
|
|
|
return x ^ y
|
|
|
|
case token.ADD:
|
|
|
|
return x + y
|
|
|
|
case token.SUB:
|
|
|
|
return x - y
|
|
|
|
default:
|
|
|
|
panic(fmt.Sprintf("unknown operator: %s", t))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func operatorToReversedBinaryExpr(t token.Token, x, y ast.Expr) *ast.BinaryExpr {
|
|
|
|
expr := &ast.BinaryExpr{X: x, Y: y}
|
|
|
|
|
|
|
|
switch t {
|
|
|
|
case token.XOR:
|
|
|
|
expr.Op = token.XOR
|
|
|
|
case token.ADD:
|
|
|
|
expr.Op = token.SUB
|
|
|
|
case token.SUB:
|
|
|
|
expr.Op = token.ADD
|
|
|
|
default:
|
|
|
|
panic(fmt.Sprintf("unknown operator: %s", t))
|
|
|
|
}
|
|
|
|
|
|
|
|
return expr
|
|
|
|
}
|
|
|
|
|
|
|
|
type obfRand struct {
|
|
|
|
*mathrand.Rand
|
|
|
|
testObfuscator obfuscator
|
|
|
|
}
|
|
|
|
|
|
|
|
func (r *obfRand) nextObfuscator() obfuscator {
|
|
|
|
if r.testObfuscator != nil {
|
|
|
|
return r.testObfuscator
|
|
|
|
}
|
|
|
|
return Obfuscators[r.Intn(len(Obfuscators))]
|
|
|
|
}
|
|
|
|
|
|
|
|
func (r *obfRand) nextLinearTimeObfuscator() obfuscator {
|
|
|
|
if r.testObfuscator != nil {
|
|
|
|
return r.testObfuscator
|
|
|
|
}
|
|
|
|
return Obfuscators[r.Intn(len(LinearTimeObfuscators))]
|
|
|
|
}
|
|
|
|
|
|
|
|
func newObfRand(rand *mathrand.Rand, file *ast.File) *obfRand {
|
|
|
|
testObf := testPkgToObfuscatorMap[file.Name.Name]
|
|
|
|
return &obfRand{rand, testObf}
|
|
|
|
}
|