Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Names inside generated lambdas are not obfuscated #649

Open
pagran opened this issue Jan 18, 2023 · 3 comments
Open

Names inside generated lambdas are not obfuscated #649

pagran opened this issue Jan 18, 2023 · 3 comments

Comments

@pagran
Copy link
Member

pagran commented Jan 18, 2023

What version of Garble and Go are you using?

$ garble version
mvdan.cc/garble v0.0.0-20230118152751-d9e74dabbb96

Build settings:
       -compiler gc     
     CGO_ENABLED 1      
          GOARCH amd64  
            GOOS windows
         GOAMD64 v1     
             vcs git
    vcs.revision d9e74dabbb96656f2387827c490cd188f4f70393
        vcs.time 2023-01-18T15:27:51Z
    vcs.modified true

$ go version
go version go1.19.4 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\User\AppData\Local\go-build
set GOENV=C:\Users\User\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\User\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\User\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19.4
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=Y:.code\go\garble_fork\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 -mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\User\AppData\Local\Temp\go-build352046228=/tmp/go-build -gno-record-gcc-switches

What did you do?

Build "hello world":

package main

func main() {
	println("hello world")
}

Command:

garble -debugdir debug_src -literals build

What did you expect to see?

All local variable names inside the generated lambda (for "hello world" string) must be obfuscated

What did you see instead?

data/fullData not obfuscated:

//line :1
package main

func main() {
	 /*line I0azaxjtKOC.go:1*/ println(func()  /*line TOq982OeQ9Ai.go:1*/ string {
		fullData := [] /*line TOq982OeQ9Ai.go:1*/ byte("\ue997.\x92A\xf3t\xd1)\xfb$\x1a\x7f\rz&\bqU\tA")
		data :=  /*line TOq982OeQ9Ai.go:1*/ make([]byte, 0, 12)
		data =  /*line TOq982OeQ9Ai.go:1*/ append(data, fullData[0]+fullData[15], fullData[11]^fullData[5], fullData[10]+fullData[18], fullData[4]-fullData[16], fullData[19]+fullData[12], fullData[9]-fullData[20], fullData[8]^fullData[1], fullData[3]+fullData[21], fullData[14]^fullData[13], fullData[7]-fullData[17], fullData[2]^fullData[6])
		return  /*line TOq982OeQ9Ai.go:1*/ string(data)
	}())
}

var garbleActionID = "FEIsMmxNgjqmdxF7TlXn"

In current version of garble this bug does not affect anything, but it blocks implementation of literals benchmark.
To implement a benchmark, it needs a reference to an external dependency and without renaming inside generated lambda, it will cause error

@lu4p
Copy link
Member

lu4p commented Aug 27, 2023

This is an easy fix just need to typecheck after literal obfuscation, this does add some overhead so I don't know if it's worth it.

@mvdan
Copy link
Member

mvdan commented Nov 12, 2023

Copying my response from #790:

Personally I don't think typechecking again from scratch is the right approach - it's far too expensive. Typechecking once is already slow enough :)

We could consider having the literals code update the type information as it changes the syntax tree. I'm not sure if that's feasible with go/types, and it might be a bit complex, but it would be faster for sure.

An alternative would be for the literal obfuscation to happen with the syntax tree alone - before we have typechecked. This would be the simplest fix, but it might also make literal obfuscation less useful in cases like "foo" + "bar".

I just realised we have another option, which might be the simplest: have the literal obfuscator generate its code with obfuscated identifiers directly, rather than normal identifiers like data and fullData. This will probably require some integration between the literal obfuscator package and the root package to share the logic to obfuscate Go names, but that is probably a lot easier than trying to typecheck a second time or updating the typechecking information with the inserted identifiers.

@lu4p
Copy link
Member

lu4p commented Nov 17, 2023

Right, sometimes the easiest solution is overlooked....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants