Since the new linker was failing on our crypto/aes shenanigans until the
recent commit to remove it for literal obfuscation.
Building Go does take about two minutes on the CI machine, but that's
fast enough. One can see the exact version that was used via the 'go
version' line.
Implement a literal obfuscator interface,
to allow the easy addition of new encodings.
Add literal obfuscation for byte literals.
Choose a random obfuscator on literal obfuscation,
useful when multiple obfuscators are implemented.
Fixes#62
Injected functions were mistaken for functions implemented outside go.
Asm functions:
obj.Scope().Pos() == 0
obj.Scope().End() == 0
Injected functions:
obj.Scope().Pos() == 0
obj.Scope().End() == 1
We now check for the End instead of the Pos.
This requires a bit of extra magic to replace one constant in
runtime/internal/sys, but that was simple enough given that we can reuse
a lot of the code to parse the files and write them to a temporary dir.
We can also drop the -X flags, as runtime.buildVersion is based on the
constant that we replace here.
Fixes#44, again.
Generating DWARF in the compiler object files could take as much as 10%
extra CPU time, while we ignore it entirely at the link stage.
Speeds up 'go test -short' from ~19.5s to ~18.5s on my laptop.
I now implemented and tested hex encoded strings, binary literals, and fmt.Sprintf("%q", data).
In the case of garble all produce the exact same binary size.
I decided to use %q because it is the simplest, leads to the smallest garbled code file size size
of the three, and is faster at compile time than binary literals.
It looks like:
var ztN0xdMLL = garbleDecrypt([]byte("\xaf\xbd\x01\\&\x14\xab\xeb\x94\x10Q\xf2H#\xde\x17\a\x8f\x89MmZs\u0088\xcfw\xba?\x9e\xe1\x81\x1eպD\xe1@\xf2\x8d\xe3Ije\xca\bB\xbey\x8b"))
From the fmt docs:
String and slice of bytes (treated equivalently with these verbs):
[...]
%q a double-quoted string safely escaped with Go syntax
Fixes#40.
Whilst it may not be particularly common, it is legal to embed fields
where the type has universe scope (e.g. int, error, etc). This can
cause a panic in 2 difference places:
- When embedding `error`, a named type is resolved but the package is
nil. The call to `pkg.Name()` results in a panic
- When embedding a basic type such as `int`, no named type is resolved
at all. The call to `namedType(obj.Type()).Obj()` results in a panic
I'm assuming it is OK to return early when a named type cannot be
resolved.. we could let it continue but I think `pkg` should be set to
nil to be correct, so it'd end up returning straight away anyway.
Since we introduced $GARBLE_DIR, we stopped recommending the use of
toolexec directly. It's still possible to set up the right flags and env
vars, but that will be a moving target.
In particular, string obfuscation in #16 will require using $GARBLE_DIR
in more scenarios. A work-in-progress patch for string obfuscation
triggered this test script to start failing for the reason above.
While at it, we don't care about what the second build contains, since
we already compare it with the previous build.
In the added test, the unexported field used to be garbled.
Reflection can only reach exported methods, exported fields, and
unexported fields. Exported methods and fields are currently never
garbled, so unexported fields was the only missing piece.
pagran
lu4p
Daniel Martí
Andrew LeFevre
Nicholas Jones