Obfuscate Go code by wrapping the Go toolchain

Overview

garble

GO111MODULE=on go get mvdan.cc/garble

Obfuscate Go code by wrapping the Go toolchain. Requires Go 1.16 or later.

garble build [build flags] [packages]

The tool also supports garble test to run tests with obfuscated code, and garble reverse to de-obfuscate text such as stack traces. See garble -h for up to date usage information.

Purpose

Produce a binary that works as well as a regular build, but that has as little information about the original source code as possible.

The tool is designed to be:

  • Coupled with cmd/go, to support modules and build caching
  • Deterministic and reproducible, given the same initial source code
  • Reversible given the original source, to de-obfuscate panic stack traces

Mechanism

The tool wraps calls to the Go compiler and linker to transform the Go build, in order to:

  • Replace as many useful identifiers as possible with short base64 hashes
  • Replace package paths with short base64 hashes
  • Remove all build and module information
  • Strip filenames and shuffle position information
  • Strip debugging information and symbol tables via -ldflags="-w -s"
  • Obfuscate literals, if the -literals flag is given
  • Remove extra information, if the -tiny flag is given

By default, the tool obfuscates the packages under the current module. If not running in module mode, then only the main package is obfuscated. To specify what packages to obfuscate, set GOPRIVATE, documented at go help private.

Note that commands like garble build will use the go version found in your $PATH. To use different versions of Go, you can install them and set up $PATH with them. For example, for Go 1.16.1:

$ go get golang.org/dl/go1.16.1
$ go1.16.1 download
$ PATH=$(go1.16.1 env GOROOT)/bin:${PATH} garble build

Literal obfuscation

Using the -literals flag causes literal expressions such as strings to be replaced with more complex variants, resolving to the same value at run-time. This feature is opt-in, as it can cause slow-downs depending on the input code.

Literal expressions used as constants cannot be obfuscated, since they are resolved at compile time. This includes any expressions part of a const declaration.

Tiny mode

When the -tiny flag is passed, extra information is stripped from the resulting Go binary. This includes line numbers, filenames, and code in the runtime that prints panics, fatal errors, and trace/debug info. All in all this can make binaries 2-5% smaller in our testing.

Note: if -tiny is passed, no panics or fatal errors will ever be printed, but they can still be handled internally with recover as normal. In addition, the GODEBUG environmental variable will be ignored.

Speed

garble build should take about twice as long as go build, as it needs to complete two builds. The original build, to be able to load and type-check the input code, and finally the obfuscated build.

Go's build cache is fully supported; if a first garble build run is slow, a second run should be significantly faster. This should offset the cost of the double builds, as incremental builds in Go are fast.

Determinism and seeds

Just like Go, garble builds are deterministic and reproducible if the inputs remain the same: the version of Go, the version of Garble, and the input code. This has significant benefits, such as caching builds or being able to use garble reverse to de-obfuscate stack traces.

However, it also means that an input package will be obfuscated in exactly the same way if none of those inputs change. If you want two builds of your program to be entirely different, you can use -seed to provide a new seed for the entire build, which will cause a full rebuild.

If any open source packages are being obfuscated, providing a custom seed can also provide extra protection. It could be possible to guess the versions of Go and garble given how a public package was obfuscated without a seed.

Caveats

Most of these can improve with time and effort. The purpose of this section is to document the current shortcomings of this tool.

  • Exported methods are never obfuscated at the moment, since they could be required by interfaces and reflection. This area is a work in progress.

  • It can be hard for garble to know what types will be used with reflection, including JSON encoding or decoding. If your program breaks because a type's names are obfuscated when they should not be, you can add an explicit hint:

     type Message struct {
     	Command string
     	Args    string
     }
    
     // Never obfuscate the Message type.
     var _ = reflect.TypeOf(Message{})
  • Go plugins are not currently supported; see #87.

Contributing

We welcome new contributors. If you would like to contribute, see CONTRIBUTING.md as a starting point.

Comments
  • Error during garble build

    Error during garble build

    I'm trying to build my go app binary on MacOs, but build fails with error:

    /usr/local/Cellar/go/1.15.5/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
    Undefined symbols for architecture x86_64:
      "_type.path/to/package/types.ZfUYm", referenced from:
          _z09qX.B.func3.2 in go.o
          _z09qX.D.func2.2 in go.o
      "_type.path/to/package/types.ZmSSZ", referenced from:
          _z9sT0.E in go.o
          _z09qX.B.func3.2 in go.o
          _z09qX.D.func2.2 in go.o
      "_type.path/to/package/types.Zn3Fp", referenced from:
          _z9sT0.C in go.o
          _zdZv7.ZEW_L.func1 in go.o
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    
    exit status 2
    exit status 2
    

    I tried to build it with GOARCH=arm GOOS=linux envs, but build failed with another error:

    path/to/package is my package. Sorry, can't write it here)

    zdzCF.B: relocation target type.path/to/package/types.ZU31i not defined
    zdzCF.F: relocation target type.path/to/package/types.ZHdpV not defined
    zHIRS.ZCZ_Z.func1: relocation target type.path/to/package/types.ZHdpV not defined
    z3hTq.C.func1.2: relocation target type.path/to/package/types.Z8uvN not defined
    z3hTq.C.func1.2: relocation target type.path/to/package/types.ZU31i not defined
    z3hTq.B.func1.2: relocation target type.path/to/package/types.Z8uvN not defined
    z3hTq.B.func1.2: relocation target type.path/to/package/types.ZU31i not defined
    exit status 2
    exit status 2
    

    It is the same project as in this issue: https://github.com/burrowers/garble/issues/202

    Error in https://github.com/burrowers/garble/issues/202 issue seems like fixed, but as you can see new one appeared.

    I'm using currently lates revision: https://github.com/burrowers/garble/commit/e014f480f99974a2976166fe5252fc41676a598a

    needs info 
    opened by metalrex100 26
  • Strengthen literal obfuscation

    Strengthen literal obfuscation

    Some ideas:

    • add some light obfuscation to the panic literals of garbleDecrypt
    • randomize function signature of garbleDecrypt e.g. include additional parameters such as ints
    • different locations of the key, as a global variable, inside garbleDecrypt, as a parameter
    • different encodings for the key, string, base64, XOR spread across multiple variables
    • multiple decrypt functions in a single package to make finding the/ all decrypt functions not as easy as analyzing which function is called with all literals
    • have a slice/map with all literals of the package, where the decrypt function then recieves a position number or a slice element to decrypt

    Many of these will add more complexity (more to test, we maybe need additional flags to test specific combinations), some of it might not be worth the extra burden to maintain.

    Note: "random" is always pseudo-random (deterministic), expect when -random is passed then it can be true random (crypto/rand).

    opened by lu4p 25
  • buildmode plugin issue of package not found

    buildmode plugin issue of package not found

    The files as follows:

    go.mod

    module test.com/plugin
    
    go 1.14
    

    dll/dll.go

    package dll
    
    import (
    	"fmt"
    )
    
    type DllInfo struct {
    	Name string `json:"name"`
    	Id   int32  `json:"id"`
    }
    
    func TestDll(name string, id int32) {
    	fmt.Printf("check : %v\n", &DllInfo{name, id})
    }
    

    main.go

    package main
    
    import (
    	"test.com/plugin/dll"
    )
    
    var TestDll = dll.TestDll
    
    func main() {
    	TestDll("asdasfas %v", 111)
    }
    

    Then run command:

    garble build -buildmode=plugin -o dll.so main.go

    Get the errors:

    # command-line-arguments
    main.go:7:15: undefined: dll.TestDll
    exit status 2
    exit status 2
    

    It really weird... Seems can not find the package.

    opened by cytown 24
  • Obfuscate literals such as strings

    Obfuscate literals such as strings

    Other projects like gobfuscate do this, and it seems like a feature that's generally useful to many users.

    For example, this is what they do:

    Strings are obfuscated by replacing them with functions. A string will be turned into an expression like the following:

    (func() string {
    	mask := []byte{33, 15, 199}
    	maskedStr := []byte{73, 106, 190}
    	res := make([]byte, 3)
    	for i, m := range mask {
    		res[i] = m ^ maskedStr[i]
    	}
    	return string(res)
    }())
    

    Reasons to do this:

    • More obfuscation takes place. The decompiled source code is less useful.
    • It's harder to locate strings in binaries via grep, or extract them easily.

    Reasons not to do this:

    • No information is lost. When one runs the program, all literals are available in memory anyway. All other kinds of obfuscation we do don't have this flaw, as they remove information entirely.
    • There could be a significant performance penalty if we replace every single literal with a function to generate it. For example, if a string is used as part of a hot loop that's executed tens of thousands of times per second.

    So far, I have only implemented the "remove information" kind of obfuscation, such as replacing variable names and file names, and removing module information.

    As much as I like not having flags, I think that any obfuscation that has a significant performance penalty should have a flag, even if it's enabled by default. I would prefer for the flag to be disabled by default, since it should be the developer who decides whether or not the tradeoff is worth it for them.

    opened by mvdan 23
  • Error when adding hardware inspection library to existing project using garble

    Error when adding hardware inspection library to existing project using garble

    Hi All,

    Very new to garble and the docs are very sparse, so I thought I would open an issue to see if someone could help. I am currently adding hardware info collection to a tool called ToRat

    For some reason, garble is scrambling the calls being made to ghw. For example, the error below should be calling cpu.Processors. How would I go about preventing garble from changing these calls?

    Here is the branch I'm working from: https://github.com/JustinTimperio/ToRat/tree/feature-hw-collector The module I'm adding: https://github.com/jaypipes/ghw The error I get is:

    Step 17/21 : RUN cd ./cmd/client && garble -literals -tiny -seed=random build -ldflags="-extldflags=-static" -tags "osusergo,netgo,tor" -o /dist/client/client_linux && upx /dist/client/client_linux
     ---> Running in ccc44745863e
    # github.com/ghodss/yaml
    parsing archive member "_go_.o": error resolving path of objfile gopkg.in/yaml%2ev2: exit status 1
    # github.com/lu4p/ToRat/torat_client
    :28: cpu.ZvD5G undefined (type *"github.com/jaypipes/ghw/pkg/cpu".ZGVzt has no field or method ZvD5G)
    :44: cpu.ZFUUP undefined (type *"github.com/jaypipes/ghw/pkg/cpu".ZGVzt has no field or method ZFUUP)
    unexpected EOF
    exit status 2
    exit status 2
    The command '/bin/sh -c cd ./cmd/client && garble -literals -tiny -seed=random build -ldflags="-extldflags=-static" -tags "osusergo,netgo,tor" -o /dist/client/client_linux && upx /dist/client/client_linux' returned a non-zero code: 1
    
    opened by JustinTimperio 22
  • Strengthen literal obfuscation (Use XOR instead of AES for literal obfuscation.)

    Strengthen literal obfuscation (Use XOR instead of AES for literal obfuscation.)

    Implement a literal obfuscator interface, to allow the easy addition of new encodings.

    Add literal obfuscation for byte literals, integers, booleans.

    Choose a random obfuscator on literal obfuscation, useful when multiple obfuscators are implemented.

    opened by lu4p 17
  • Ability to un-garble code, filename positions, and ultimately stack traces given a source package

    Ability to un-garble code, filename positions, and ultimately stack traces given a source package

    For example, right now a garbled panic looks something like:

    panic: here
    
    goroutine 1 [running]:
    main.znh2yNUH9(0x0)
    	z0.go:82 +0x47
    main.main()
    	z0.go:44 +0x22
    

    Its non-garbled version is:

    panic: here
    
    goroutine 1 [running]:
    main.main1(0x0)
    	/home/mvdan/src/garble/main.go:92 +0x47
    main.main()
    	/home/mvdan/src/garble/main.go:47 +0x22
    

    We should make this possible and automate it.

    enhancement 
    opened by mvdan 16
  • -ldflags=-X with quotes not working when -literals is also used

    -ldflags=-X with quotes not working when -literals is also used

    What version of Garble and Go are you using?

    $ garble version
    v0.5.1
    
    $ go version
    go version go1.17.5 linux/amd64
    

    What environment are you running Garble on?

    go env Output
    $ go env
    GO111MODULE=""
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/home/rastley/.cache/go-build"
    GOENV="/home/rastley/.config/go/env"
    GOEXE=""
    GOEXPERIMENT=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOINSECURE=""
    GOMODCACHE="/home/rastley/go/pkg/mod"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="linux"
    GOPATH="/home/rastley/go"
    GOPRIVATE=""
    GOPROXY="https://proxy.golang.org,direct"
    GOROOT="/home/rastley/sdk/go1.17.5"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/home/rastley/sdk/go1.17.5/pkg/tool/linux_amd64"
    GOVCS=""
    GOVERSION="go1.17.5"
    GCCGO="gccgo"
    AR="ar"
    CC="gcc"
    CXX="g++"
    CGO_ENABLED="1"
    GOMOD="/tmp/merlin/Payload_Type/merlin/agent_code/go.mod"
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2615366059=/tmp/go-build -gno-record-gcc-switches"
    

    What did you do?

    I compiled Merlin using Garble with the -literals argument and attempted to set verbose variable through the go build ldflags argument. When I ran the agent, there was no output to STDOUT but there should have been if the verbose variable was set.

    [email protected]:/tmp$ garble version
    v0.5.1
    [email protected]:/tmp$ git clone https://github.com/MythicAgents/merlin
    <SNIP>
    [email protected]:/tmp$ cd merlin/Payload_Type/merlin/agent_code/
    [email protected]:/tmp/merlin/Payload_Type/merlin/agent_code$ garble -tiny -literals build -o merlin.bin -ldflags '-X "main.verbose=True"' main.go
    [email protected]:/tmp/merlin/Payload_Type/merlin/agent_code$ ./merlin.bin 
    [email protected]:/tmp/merlin/Payload_Type/merlin/agent_code$
    

    What did you expect to see?

    I expected to see verbose output to STDOUT because the verbose variable was set to True. The output would look like:

    [email protected]:/tmp/merlin/Payload_Type/merlin/agent_code$ ./merlin.bin 
    [i]Host Information:
    [i]	Agent UUID: 1e1c41d6-8511-403b-9f83-0ec9b0a4d71e
    [i]	Platform: linux
    [i]	Architecture: amd64
    [i]	User Name: rastley
    [i]	User GUID: 1000
    [i]	Integrity Level: 3
    [i]	Hostname: ubuntu
    [i]	Process: /tmp/merlin/Payload_Type/merlin/agent_code/merlin.bin
    [i]	PID: 480365
    

    What did you see instead?

    I saw no output, indicating that the verbose variable was not set.

    Misc.

    I opened main.go and added func init(){ fmt.Printf("Verbose: %s\n", verbose) } to assist with debugging:

    [email protected]:/tmp/merlin/Payload_Type/merlin/agent_code$ garble -tiny -literals build -o merlin.bin -ldflags '-X "main.verbose=True"' main.go
    [email protected]:/tmp/merlin/Payload_Type/merlin/agent_code$ ./merlin.bin 
    Verbose: false
    

    Potentially related to #323

    opened by Ne0nd0g 15
  • Go list error

    Go list error

    Hey, first of all thanks for creating such a useful tool !

    I'm having issues with running garble inside Docker container, while it works flawless outside of container. This is the command I'm running:

    RUN --mount=type=cache,target=/go/pkg/mod \
        go get mvdan.cc/garble
    RUN --mount=type=cache,target=/go/pkg/mod \
        --mount=type=cache,target=/root/.cache/go-build \
        GIT_TERMINAL_PROMPT=1 \
        CGO_ENABLED=0 \
        GOPRIVATE=none \
        garble -tiny -literals -seed=random build -trimpath -ldflags="-s -w" -o ./bin/my-program ./cmd/my-program/main.go
    

    or

    RUN --mount=type=cache,target=/go/pkg/mod \
        go get mvdan.cc/garble
    RUN --mount=type=cache,target=/root/.cache/go-build \
        GIT_TERMINAL_PROMPT=1 \
        CGO_ENABLED=0 \
        GOPRIVATE=none \
        garble -tiny -literals -seed=random build -trimpath -ldflags="-s -w" -o ./bin/my-program ./cmd/my-program/main.go
    

    And this is error output I'm getting:

    #20 1.002 go list error: exit status 1: /go/pkg/mod/github.com/fsnotify/[email protected]/inotify.go:19:2: missing go.sum entry for module providing package golang.org/x/sys/unix; to add:
    #20 1.002 	go mod download golang.org/x/sys
    #20 1.002 /go/pkg/mod/github.com/spf13/[email protected]/util.go:28:2: missing go.sum entry for module providing package golang.org/x/text/transform; to add:
    #20 1.002 	go mod download golang.org/x/text
    #20 1.002 /go/pkg/mod/github.com/spf13/[email protected]/util.go:29:2: missing go.sum entry for module providing package golang.org/x/text/unicode/norm; to add:
    #20 1.002 	go mod download golang.org/x/text
    #20 1.002 go build golang.org/x/sys/unix: no Go files in
    #20 1.002 go build golang.org/x/text/transform: no Go files in
    #20 1.002 go build golang.org/x/text/unicode/norm: no Go files in
    

    And this is my go.mod file

    module my-program
    
    go 1.16
    
    require (
    	github.com/alecthomas/chroma v0.9.1
    	github.com/gorilla/mux v1.8.0
    	github.com/machinebox/graphql v0.2.2
    	github.com/matryer/is v1.4.0 // indirect
    	github.com/opentracing/opentracing-go v1.2.0
    	github.com/openzipkin-contrib/zipkin-go-opentracing v0.4.5
    	github.com/openzipkin/zipkin-go v0.2.5
    	github.com/pkg/errors v0.9.1
    	github.com/rs/zerolog v1.20.0
    	github.com/spf13/cobra v1.1.1
    	github.com/spf13/viper v1.7.1
    	github.com/stoewer/go-strcase v1.2.0
    	github.com/stretchr/testify v1.7.0
    	github.com/valyala/quicktemplate v1.6.3
    	gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 // indirect
    )
    

    I'm using Go 1.16.4 on Darwin, I ran go mod tidy but it didn't help to solve the issue. Issue persists only inside container. I think the issue isn't related to garble but to go list command itself

    opened by bejaneps 14
  • GOPRIVATE=* not work with staticcheck

    GOPRIVATE=* not work with staticcheck

    Command:

    git clone https://github.com/golang/tools
    cd tools
    GOPRIVATE=* garble build build ./cmd/staticcheck
    

    Output:

    # runtime/debug
    c:\go\src\runtime\debug\garbage.go:15:17: undefined: time.Time
    c:\go\src\runtime\debug\garbage.go:17:17: undefined: time.Duration
    c:\go\src\runtime\debug\garbage.go:18:19: undefined: time.Duration
    c:\go\src\runtime\debug\garbage.go:19:19: undefined: time.Time
    c:\go\src\runtime\debug\garbage.go:20:19: undefined: time.Duration
    c:\go\src\runtime\debug\garbage.go:39:24: undefined: time.Duration
    c:\go\src\runtime\debug\garbage.go:50:17: undefined: time.Unix
    c:\go\src\runtime\debug\garbage.go:57:27: undefined: time.Time
    c:\go\src\runtime\debug\garbage.go:61:43: undefined: time.Unix
    c:\go\src\runtime\debug\stubs.go:12:21: undefined: time.Duration
    c:\go\src\runtime\debug\garbage.go:61:43: too many errors
    exit status 2
    # runtime/trace
    c:\go\src\runtime\trace\annotation.go:34:19: undefined: context.Context
    c:\go\src\runtime\trace\annotation.go:39:9: undefined: context.WithValue
    c:\go\src\runtime\trace\annotation.go:61:22: undefined: context.Context
    c:\go\src\runtime\trace\annotation.go:91:14: undefined: context.Context
    c:\go\src\runtime\trace\annotation.go:97:15: undefined: context.Context
    c:\go\src\runtime\trace\annotation.go:102:25: undefined: fmt.Sprintf
    c:\go\src\runtime\trace\annotation.go:118:21: undefined: context.Context
    c:\go\src\runtime\trace\annotation.go:149:22: undefined: context.Context
    c:\go\src\runtime\trace\trace.go:120:14: undefined: io.Writer
    c:\go\src\runtime\trace\trace.go:151:2: undefined: sync.Mutex
    c:\go\src\runtime\trace\trace.go:151:2: too many errors
    exit status 2
    # net
    typecheck error: c:\go\src\net\dnsclient.go:11:2: could not import golang.org/x/net/dns/dnsmessage (path not found in listed packages: golang.org/x/net/dns/dnsmessage)
    # vendor/golang.org/x/text/unicode/norm
    typecheck error: c:\go\src\vendor\golang.org\x\text\unicode\norm\normalize.go:15:2: could not import golang.org/x/text/transform (path not found in listed packages: golang.org/x/text/transform)
    # runtime/pprof
    c:\go\src\runtime\pprof\label.go:27:21: undefined: context.Context
    c:\go\src\runtime\pprof\label.go:59:21: undefined: context.Context
    c:\go\src\runtime\pprof\label.go:93:16: undefined: context.Context
    c:\go\src\runtime\pprof\label.go:101:20: undefined: context.Context
    c:\go\src\runtime\pprof\pprof.go:135:8: undefined: sync.Mutex
    c:\go\src\runtime\pprof\pprof.go:138:13: undefined: io.Writer
    c:\go\src\runtime\pprof\pprof.go:326:29: undefined: io.Writer
    c:\go\src\runtime\pprof\pprof.go:377:31: undefined: io.Writer
    c:\go\src\runtime\pprof\pprof.go:404:26: undefined: io.Writer
    c:\go\src\runtime\pprof\pprof.go:492:25: undefined: io.Writer
    c:\go\src\runtime\pprof\pprof.go:492:25: too many errors
    exit status 2
    # vendor/golang.org/x/text/secure/bidirule
    typecheck error: c:\go\src\vendor\golang.org\x\text\secure\bidirule\bidirule.go:15:2: could not import golang.org/x/text/transform (path not found in listed packages: golang.org/x/text/transform)
    # vendor/golang.org/x/crypto/cryptobyte
    typecheck error: c:\go\src\vendor\golang.org\x\crypto\cryptobyte\asn1.go:14:2: could not import golang.org/x/crypto/cryptobyte/asn1 (path not found in listed packages: golang.org/x/crypto/cryptobyte/asn1)
    exit status 2
    

    Tested on lasted commit and 30df5e9bbd677fa31f6562d3ab7a43edd203982b

    bug 
    opened by pagran 14
  • Using `embed` inside go program results in TOOLEXEC_IMPORTPATH not found in listed packages: embed

    Using `embed` inside go program results in TOOLEXEC_IMPORTPATH not found in listed packages: embed

    What version of Garble and Go are you using?

    $ garble version
    v0.4.0
    
    $ go version
    go version go1.16.3 darwin/amd64
    

    What environment are you running Garble on?

    go env Output
    $ go env
    GO111MODULE="auto"
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/Users/User/Library/Caches/go-build"
    GOENV="/Users/User/Library/Application Support/go/env"
    GOEXE=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="darwin"
    GOINSECURE=""
    GOMODCACHE="/Users/User/Documents/Go/pkg/mod"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="darwin"
    GOPATH="/Users/User/Documents/Go"
    GOPRIVATE=""
    GOPROXY="https://proxy.golang.org,direct"
    GOROOT="/usr/local/Cellar/go/1.16.3/libexec"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/usr/local/Cellar/go/1.16.3/libexec/pkg/tool/darwin_amd64"
    GOVCS=""
    GOVERSION="go1.16.3"
    GCCGO="gccgo"
    AR="ar"
    CC="clang"
    CXX="clang++"
    CGO_ENABLED="1"
    GOMOD=""
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dv/4yby4nt54ng769mywc0vqbn00000gn/T/go-build898330407=/tmp/go-build -gno-record-gcc-switches -fno-common"
    

    What did you do?

    I'm creating a program that uses the embed package to import static resources, this is done with the following lines:

    //go:embed static/*
    var static embed.FS
    

    These are then later used like so:

    func getData(dir string) ([]string, error) {
    	result := []string{}
    	files, err := static.ReadDir(dir)
    
    	if err != nil {
    		return nil, err
    	}
    
    	for _, file := range files {
    		data, _ := static.ReadFile(dir + "/" + file.Name())
    		result = append(result, string(data))
    	}
    
    	return result, nil
    }
    

    What did you expect to see?

    When I compile the program normally, all goes well, as expected.

    What did you see instead?

    $ garble -debugdir=../dist/obfuscated build -o progam.elf -s -w ./program/
    # embed
    TOOLEXEC_IMPORTPATH not found in listed packages: embed
    
    bug 
    opened by Paradoxis 13
  • garble.exe: The filename or extension is too long

    garble.exe: The filename or extension is too long

    What version of Garble and Go are you using?

    $ garble version
    mvdan.cc/garble v0.7.0
    
    Build settings:
           -compiler gc
         CGO_ENABLED 0
              GOARCH amd64
                GOOS windows
             GOAMD64 v1
    $ go version
    go version go1.18.2 windows/amd64
    

    What environment are you running Garble on?

    go env Output
    $ go env
    set GO111MODULE=on
    set GOARCH=amd64
    set GOBIN=
    set GOCACHE=C:\Users\Administrator\AppData\Local\go-build
    set GOENV=C:\Users\Administrator\AppData\Roaming\go\env
    set GOEXE=.exe
    set GOEXPERIMENT=
    set GOFLAGS=
    set GOHOSTARCH=amd64
    set GOHOSTOS=windows
    set GOINSECURE=
    set GOMODCACHE=D:\Storage\Caches\gopath\pkg\mod
    set GONOPROXY=
    set GONOSUMDB=
    set GOOS=windows
    set GOPATH=D:\Storage\Caches\gopath
    set GOPRIVATE=
    set GOPROXY=https://goproxy.cn,direct
    set GOROOT=D:\Storage\Go-1.18.2\go1.18.2
    set GOSUMDB=sum.golang.org
    set GOTMPDIR=
    set GOTOOLDIR=D:\Storage\Go-1.18.2\go1.18.2\pkg\tool\windows_amd64
    set GOVCS=
    set GOVERSION=go1.18.2
    set GCCGO=gccgo
    set GOAMD64=v1
    set AR=ar
    set CC=gcc
    set CXX=g++
    set CGO_ENABLED=0
    set GOMOD=D:\GoProject\Test\go.mod
    set GOWORK=
    set CGO_CFLAGS=-g -O2
    set CGO_CPPFLAGS=
    set CGO_CXXFLAGS=-g -O2
    set CGO_FFLAGS=-g -O2
    set CGO_LDFLAGS=-g -O2
    set PKG_CONFIG=pkg-config
    set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\ADMINI~1\AppData\Local\Temp\go-build464808010=/tmp/go-build -gno-record-gcc-switches
    

    What did you do?

    I tried to complie a project with lib github.com/gotd/td but there is a error occure.

    go build github.com/gotd/td/tg: D:\Storage\Caches\gopath\bin\garble.exe: fork/exec D:\Storage\Caches\gopath\bin\garble.exe: The filename or extension is too long.
    

    What did you expect to see?

    Compile successfully

    What did you see instead?

    Error above

    I notice that the command works fine in Linux. Then I found out that the error The filename or extension is too long will be throw when a command has more than 32k byte exec in Windows. This probably is Windows' fault but I still want to post this here and try to find solution together!

    Any help would be much appreciated! English is not my first language, sorry for that.

    opened by SaigyoujiYuyuko233 3
  • Reverse issue on go-ethereum:  undeclared name: max_path_size

    Reverse issue on go-ethereum: undeclared name: max_path_size

    What version of Garble and Go are you using?

    Custom, forked from master, to add a blacklist argument.

    $ garble version
    https://github.com/zcrypt0/garble/tree/72792ae964f200c6741036ef38b08f13c23ec16a
    
    $ go version v1.18.3
    
    

    What environment are you running Garble on?

    go env Output
    $ go env
    GO111MODULE=""
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/home/user/.cache/go-build"
    GOENV="/home/user/.config/go/env"
    GOEXE=""
    GOEXPERIMENT=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOINSECURE=""
    GOMODCACHE="/go/pkg/mod"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="linux"
    GOPATH="/go"
    GOPRIVATE=""
    GOPROXY="https://proxy.golang.org,direct"
    GOROOT="/usr/local/go"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
    GOVCS=""
    GOVERSION="go1.18.3"
    GCCGO="gccgo"
    GOAMD64="v1"
    AR="ar"
    CC="gcc"
    CXX="g++"
    CGO_ENABLED="1"
    GOMOD="/go-ethereum/go.mod"
    GOWORK=""
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3469986570=/tmp/go-build -gno-record-gcc-switches"
    

    What did you do?

    See below for comments on the custom -blacklist argument.

    $ go install github.com/zcrypt0/[email protected]
    $ git clone https://github.com/ethereum/go-ethereum
    $ cd go-ethereum
    $ touch ./panic-output.txt
    $ garble -blacklist github.com/ethereum/go-ethereum/crypto/bn256/cloudflare build -trimpath -v -o ./build/bin/geth ./cmd/geth
    $ garble -blacklist github.com/ethereum/go-ethereum/crypto/bn256/cloudflare reverse ./cmd/geth ./panic-output.txt
    

    What did you expect to see?

    Successfully reverse an obfuscated panic trace.

    What did you see instead?

    Reversing fails on the rpc subpackage (github.com/ethereum/go-ethereum/rpc), no actual panic output is required.

    typecheck error: /go-ethereum/rpc/ipc_unix.go:34:25: undeclared name: max_path_size
    

    Comments

    The blacklist on the custom version simply ensures that pkg.ToObfuscate is false for an obfuscated package and can be replicated without using my fork of garble by simply making a build that adds the blacklisted package to the cannotObfuscate map.

    The blacklisted package is necessary to avoid #553

    The var max_path_size is a package level var declared in another file and reverse (not build) seems to have some issue with it. Looks like it makes a call out to C for its value.

    https://github.com/ethereum/go-ethereum/blob/master/rpc/ipc_unix.go#L34 https://github.com/ethereum/go-ethereum/blob/master/rpc/constants_unix.go#L33

    opened by zcrypt0 1
  • using GORM results in obfuscated table names due to its indirect use of reflection

    using GORM results in obfuscated table names due to its indirect use of reflection

    What version of Garble and Go are you using?

    $ garble version v0.7.0
    $ go version v1.18.3
    

    What did you do?

    garble build -v -a -ldflags "-s -w" -trimpath -buildmode=pie
    

    What did you see instead?

    build Correct but gorm err

    2022/06/17 12:00:00 sqggj5IQ.go:1 Error 1146: Table 'v2_v2.v2_co3i34_y3' doesn't exist
    SELECT sum(u+d) as n,u,d,user,record,updated,server FROM `v2_co3i34_y3`.....
    
    opened by as1543100166 12
  • obfuscated names in header files included from assembly fail at link time

    obfuscated names in header files included from assembly fail at link time

    What version of Garble and Go are you using?

    $ garble version v0.7.0
    
    $ go version v1.18.3
    
    

    What environment are you running Garble on?

    go env Output
    $ go env
    GO111MODULE=""
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/home/user/.cache/go-build"
    GOENV="/home/user/.config/go/env"
    GOEXE=""
    GOEXPERIMENT=""
    GOFLAGS=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOINSECURE=""
    GOMODCACHE="/go/pkg/mod"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="linux"
    GOPATH="/go"
    GOPRIVATE=""
    GOPROXY="https://proxy.golang.org,direct"
    GOROOT="/usr/local/go"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
    GOVCS=""
    GOVERSION="go1.18.3"
    GCCGO="gccgo"
    GOAMD64="v1"
    AR="ar"
    CC="gcc"
    CXX="g++"
    CGO_ENABLED="1"
    GOMOD="/go-ethereum/go.mod"
    GOWORK=""
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3469986570=/tmp/go-build -gno-record-gcc-switches"
    

    What did you do?

    $ git clone https://github.com/ethereum/go-ethereum
    $ cd go-ethereum
    $ garble build -trimpath -v -o ./build/bin/geth ./cmd/geth
    

    What did you expect to see?

    Successfully compiling go-ethereum.

    What did you see instead?

    Lots of undefined references during linking, similar to the below.

    /usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
    
    ...
    
    /usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: go.go:(.text+0x539c15): undefined reference to `qlz7tY23.p2'
    /usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: go.go:(.text+0x539c2b): undefined reference to `qlz7tY23.p2'
    /usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: go.go:(.text+0x539c41): undefined reference to `qlz7tY23.p2'
    /usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: go.go:(.text+0x539c73): undefined reference to `qlz7tY23.p2'
    /usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/go-link-1607869154/go.o:go.go:(.text+0x539c85): more undefined references to `qlz7tY23.p2' 
    

    Comments

    I dug in a little bit and with a whitelist, select packages can be obfuscated just fine.

    Running with -debug I can see the package with undefined references:

    [garble] import path "github.com/ethereum/go-ethereum/crypto/bn256/cloudflare" hashed with 5afaf34cfd103d0ff82a7f16d49c61 to "qlz7tY23"
    
    

    Seeing the same result on tip of master.

    EDIT: I blacklisted that particular module from being obfuscated, and the rest of go-ethereum obfuscated just fine.

    EDIT2: Reversing also fails on the rpc subpackage (github.com/ethereum/go-ethereum), no actual panic output is required.

    $ garble reverse ./cmd/geth ./out/panic-output.txt
    typecheck error: /go-ethereum/rpc/ipc_unix.go:34:25: undeclared name: max_path_size
    

    Additionally blacklisting this package and reverse works as expected.

    opened by zcrypt0 3
  • better ensure that garble's build cache entries have the same lifetime as their original counterparts

    better ensure that garble's build cache entries have the same lifetime as their original counterparts

    @Ne0nd0g reports the following error on an incremental garble build:

    [email protected]:/tmp/a/merlin-agent$ /tmp/a/garble-fork/garble449 -tiny -literals -seed d0d03a0ae4722535a0e1d5d0c8385ce42015511e68d960fadef4b4eaf5942feb build -o merlin-agent.bin main.go
    # github.com/Ne0nd0g/merlin/pkg/core
    open /home/rastley/.cache/go-build/a0/a08feb304633e65c955bc6a857c606d6221ba1d580d4914675b3d616c64fb196-garble-MbtD0Gsf9IcYT1C5sdQI-d: no such file or directory
    # go.dedis.ch/kyber/v3/pairing/bn256
    open /home/rastley/.cache/go-build/12/12b6c95746471c9ebb58a17d90bedacb27431abb6ad95d3a6a4a5a3fb0753487-garble-ad-nISVYjikpVwTeeS1X-d: no such file or directory
    # github.com/lucas-clemente/quic-go
    open /home/rastley/.cache/go-build/7e/7e93199b31ef880403fb28327ecc5a0aa7f1ed23221fac52d2e50fc6a62abb0a-garble-lPvcFMg4pAep3AUPeloG-d: no such file or directory
    exit status 2
    

    It's unclear what caused this edge case, and we don't have a reliable way to reproduce this for now. However, we can theorize about scenarios where we can end up with garble's extra build cache files being missing when their original cache entry is present.

    For example, Go regularly trims the caches. Right now, the logic is to delete files not used within the last five days up to once per day. It keeps the "last used" information by bumping the modified time of each cache entry file whenever it's used, up to once per hour:

    https://cs.opensource.google/go/go/+/refs/tags/go1.17.8:src/cmd/go/internal/cache/cache.go;l=284-287

    We don't do this, so we can end up in a scenario like:

    • Run garble build on day 1; Go's and Garble's cache files have an mtime of day 1
    • Wait three days, taking us to day 4
    • Run an incremental garble build; Go's cache files get their mtime changed to day 4
    • Wait another three days, taking us to day 7
    • Have Go's automatic cache trimming take place; keeps Go's cache files, just 3 days old, but deletes garble's cache files, now 6 days old
    • Run an incremental garble build again; now our extra cache entry files are missing, and we can run into the error above

    I don't think this is the situation that the user above ran into, because they were using a new version of garble, meaning that all cache entries should be less than a day old. Still, this situation is possible with at least one scenario, but likely at least two, given the user's report.

    opened by mvdan 3
Releases(v0.7.1)
  • v0.7.1(Aug 2, 2022)

    This bugfix release finishes support for Go 1.19 and features:

    • Obfuscate all cgo filenames to not leak import paths
    • Support obfuscating net and runtime/debug
    • Don't leak temporary directories after obfuscating
    • Fix an edge case resulting in broken import declarations
    • Reduce allocations involved in obfuscating code
    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Jun 10, 2022)

    This release drops support for Go 1.17, continues support for Go 1.18, and adds initial support for the upcoming Go 1.19.

    Noteworthy changes include:

    • Initial support for obfuscating generic code - #414
    • Remove unused imports in -literals more reliably - #481
    • Support obfuscating package paths ending with .go - #539
    • Support installing garble in paths containing spaces - #544
    • Avoid a panic when obfuscating variadic functions - #524
    • Avoid a "refusing to list package" panic in garble test - #522
    • Some module builds are now used as regression tests - #240

    Thanks to @lu4p, @pagran, and @shellhazard for their contributions in this release!

    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Mar 22, 2022)

    This release adds support for Go 1.18 while continuing support for Go 1.17.x. Note that building generic code isn't supported just yet.

    Noteworthy changes include:

    • Obfuscation is now fully deterministic with a fixed -seed - #449
    • Improve support for type aliases to fix some build failures - #466
    • Add support for quotes in -ldflags as per go help build - #492
    • Fail if the current Go version is newer than what built garble - #269
    • Various optimizations resulting in builds being up to 5% faster - #456

    Thanks to @lu4p and @capnspacehook for their contributions in this release!

    Source code(tar.gz)
    Source code(zip)
  • v0.5.1(Jan 18, 2022)

    This bugfix release features:

    • Obfuscate exported names in main packages
    • Fix build errors when using -literals with GOGARBLE=*
    • Avoid breaking -ldflags=-X when -literals is used
    • Avoid link errors when using -debugdir
    • Speed up obfuscating the runtime package
    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Jan 6, 2022)

    This release of Garble adds initial support for the upcoming Go 1.18, continues support for Go 1.17.x, and drops support for Go 1.16.x. Note that building generic code isn't supported just yet.

    Two breaking changes are introduced:

    • Deprecate the use of GOPRIVATE in favor of GOGARBLE (see https://github.com/burrowers/garble/issues/276)
    • garble reverse now requires a main package argument

    Noteworthy changes include:

    • Improve detection of reflect usage even further
    • Support obfuscating some more standard library packages
    • Improve literal obfuscation by using constant folding
    • Add the -debug flag to log details of the obfuscated build
    • Ensure the runtime package is built in a reproducible way
    • Obfuscate local variable names to prevent shadowing bugs
    • Fix and test support for using garble on 32-bit hosts
    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Aug 26, 2021)

    This release of Garble adds support for Go 1.17.x while maintaining support for Go 1.16.x. A few other noteworthy changes are included:

    • Support obfuscating literals in more edge cases with -literals
    • Improve detection of reflect usage with standard library APIs
    • Names exported for cgo are no longer obfuscated
    • Avoid breaking consts using iota with -literals

    Known bugs:

    • obfuscating the entire standard library with GOPRIVATE=* is not well supported yet
    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(May 31, 2021)

    This release of Garble fixes a number of bugs and improves existing features, while maintaining support for Go 1.16.x. Notably:

    • Make builds reproducible even when cleaning GOCACHE
    • Detecting types used with reflection is more reliable
    • Cross builds with GOPRIVATE=* are now supported
    • Support conversion between struct types from different packages
    • Improve support for type aliases
    • Function names used with go:linkname are now obfuscated
    • garble reverse can now reverse field names and lone filenames

    Known bugs:

    • obfuscating the entire standard library with GOPRIVATE=* is not well supported yet

    Consider becoming a sponsor if you benefit from the work that went into this release!

    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Apr 8, 2021)

    This release of Garble drops support for Go 1.15.x, which is necessary for some of the enhancements below:

    • New: garble test allows running Go tests built with obfuscation
    • New: garble reverse allows de-obfuscating output like stack traces
    • Names of functions implemented in assembly are now obfuscated
    • GOPRIVATE=* now works with packages like crypto/tls and embed
    • garble build can now be used with many main packages at once
    • -literals is more robust and now works on all of std

    The README is also overhauled to be more helpful to first-time users.

    Known bugs:

    • obfuscating the entire standard library with GOPRIVATE=* is not well supported yet
    Source code(tar.gz)
    Source code(zip)
  • v0.1.0(Mar 5, 2021)

    This is the first release of Garble. It supports Go 1.15.x and 1.16.x.

    It ships all the major features that have worked for the past year, including:

    • Obfuscation of all names, except methods and reflect targets
    • Obfuscation of package import paths and position information
    • Stripping of build and module information
    • Support for Go modules
    • Reproducible and cacheable builds
    • Stripping of extra information via -tiny
    • Literal obfuscation via -literals

    Known bugs:

    • obfuscating the standard library with GOPRIVATE=* is not well supported yet
    • garble test is temporarily disabled, as it is currently broken
    Source code(tar.gz)
    Source code(zip)
Owner
Gophers working on tools to hide treasure
null
Secret management toolchain

Harp TL;DR. Why harp? Use cases How does it work? Like a Data pipeline but for secret Immutable transformation What can I do? FAQ License Homebrew ins

elastic 131 Sep 18, 2022
SPIRE is a toolchain of APIs for establishing trust between software systems across a wide variety of hosting platforms

SPIRE (the SPIFFE Runtime Environment) is a toolchain of APIs for establishing trust between software systems across a wide variety of hosting platforms

SPIFFE 1.2k Sep 25, 2022
🔎 Help find Trojan Source vulnerability in code 👀 . Useful for code review in project with multiple collaborators

TrojanSourceFinder TrojanSourceFinder helps developers detect "Trojan Source" vulnerability in source code. Trojan Source vulnerability allows an atta

Ariary 43 Sep 19, 2022
Go-sec-code is a project for learning Go vulnerability code.

Welcome to go-sec-code ?? Go-sec-code is a project for learning Go vulnerability code. ?? Homepage Introduction 用beego作为后端框架开发的go语言靶场,目前已经完成 commandIn

null 5 Sep 9, 2022
Lightweight static analysis for many languages. Find bug variants with patterns that look like source code.

Lightweight static analysis for many languages. Find bugs and enforce code standards. Semgrep is a fast, open-source, static analysis tool that finds

r2c 7.1k Sep 23, 2022
Ah shhgit! Find secrets in your code. Secrets detection for your GitHub, GitLab and Bitbucket repositories: www.shhgit.com

shhgit helps secure forward-thinking development, operations, and security teams by finding secrets across their code before it leads to a security br

Paul 3.5k Sep 19, 2022
EarlyBird is a sensitive data detection tool capable of scanning source code repositories for clear text password violations, PII, outdated cryptography methods, key files and more.

EarlyBird is a sensitive data detection tool capable of scanning source code repositories for clear text password violations, PII, outdated cryptograp

American Express 513 Sep 20, 2022
PHP functions implementation to Golang. This package is for the Go beginners who have developed PHP code before. You can use PHP like functions in your app, module etc. when you add this module to your project.

PHP Functions for Golang - phpfuncs PHP functions implementation to Golang. This package is for the Go beginners who have developed PHP code before. Y

Serkan Algur 52 Aug 26, 2022
Exploitation of CVE-2018-18925 a Remote Code Execution against the Git self hosted tool: Gogs.

CVE-2018-18925 Exploitation of CVE-2018-18925 a Remote Code Execution against the Git self hosted tool: Gogs. Gogs is based on the Macaron framework.

Jakom 7 Feb 2, 2022
WIP. Converts Azure Container Scan Action output to SARIF, for an easier integration with GitHub Code Scanning

container-scan-to-sarif container-scan-to-sarif converts Azure Container Scan Action output to Static Analysis Results Interchange Format (SARIF), for

Armel Soro 2 Jan 25, 2022
PoC for CVE-2015-1635 / MS15-034 - HTTP.sys Allows Remote Code Execution / Check & DOS

CVE-2015-1635 PoC for CVE-2015-1635 / MS15-034 - HTTP.sys Allows Remote Code Execution / Check & DOS ./MS15-034 <URL> <RESOURCE> <FLAG [0 or 18]> Note

Nikola Kipariz Stamov 0 Nov 3, 2021
If I were a malicious actor, how would I sneak my code in?

go-error-hijack-poc This repo demonstrates a hypothetical use of sentinel errors and horizontally off-screen code as attack vectors. How to Run Run th

Chris S. Kim 0 Jan 15, 2022
A drop-in replacement for Go errors, with some added sugar! Unwrap user-friendly messages, HTTP status code, easy wrapping with multiple error types.

Errors Errors package is a drop-in replacement of the built-in Go errors package with no external dependencies. It lets you create errors of 11 differ

Kamaleshwar 43 Aug 29, 2022
Parametrized JSON logging library in Golang which lets you obfuscate sensitive data and marshal any kind of content.

Noodlog Summary Noodlog is a Golang JSON parametrized and highly configurable logging library. It allows you to: print go structs as JSON messages; pr

Gyoza Tech 38 Sep 16, 2022
Monmind - obfuscate multiple strings & hide text from binary searching

Monmind - obfuscate multiple strings & hide text from binary searching Obfuscation strings in golang code INSTALL You can install monmind by running:

null 12 Aug 28, 2022
Jacket of google/wire: advanced DI approach wrapping google/wire for cloud.

Wire-Jacket: IoC Container of google/wire for cloud-native Jacket of google/wire: advanced DI approach wrapping google/wire for cloud. google/wire : h

Youngtak Han 4 Dec 16, 2021
Wrap contains a method for wrapping one Go error with another.

Note: this code is still in alpha stage. It works but it may change subtly in the near future, depending on what comes out of golang/go#52607. Wrap.Wi

Nate Finch 4 Jun 27, 2022
Go package exposing a simple interface for executing commands, enabling easy mocking and wrapping of executed commands.

go-runner Go package exposing a simple interface for executing commands, enabling easy mocking and wrapping of executed commands. The Runner interface

Krystal 6 Jun 15, 2022
Stackie enables developers to configure their local environment/toolchain with ease.

Stackie enables developers to configure their local environment/toolchain with ease. Made for Pulumi CLI, Google Cloud Platform (gcloud), and Amazon Web Services (aws-cli).

Bjerk AS 6 Sep 10, 2021