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

imported and not used error when use literals #481

Closed
fexli opened this issue Feb 21, 2022 · 3 comments · Fixed by #512
Closed

imported and not used error when use literals #481

fexli opened this issue Feb 21, 2022 · 3 comments · Fixed by #512
Milestone

Comments

@fexli
Copy link

fexli commented Feb 21, 2022

What version of Garble and Go are you using?

$ garble version v0.5.1

$ go version go1.17.5 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\admin\AppData\Local\go-build
set GOENV=C:\Users\admin\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\admin\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\admin\go
set GOPRIVATE=
set GOPROXY=https://goproxy.io,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.17.5
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\GOPROJECT\ARS\go.mod
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 -fmessage-length=0 -fdebug-prefix-map=C:\Users\admin\AppData\Local\Temp\go-build3746895135=/tmp/go-build -gno-record-gcc-switches

What did you do?

when I build the following go with garble

package main

import (
	"github.com/gofiber/fiber/v2"
)

var FiberVer = fiber.Version

func main() {
	println("Fiber v" + FiberVer)
}

What did you see instead?

when I run garble -literals -debug build ARS it will handle an exception as follow:

[garble] 157 cached output files loaded in 16.61ms
[garble] variable "FiberVer" hashed with 23bb5a37… to "IKAy1x44"
[garble] transformed args for compile in 31.77ms: -o $WORK\b001\_pkg_.a -trimpath C:\Users\admin\AppData\Local\Temp\garble-shared1063768626=>;D:\GOPROJECT\ARS=>ARS;C:\Users\admin\AppData\Local\Temp\go-build1598836508\b001=> -p main -lang=go1.17 -complete -buildid V86icXf3-FwLYd3tdtzi/V86icXf3-FwLYd3tdtzi -goversion go1.17.5 -importcfg C:\Users\admin\AppData\Local\Temp\garble-shared1063768626\importcfg2140450807 -pack -c=4 -dwarf=false C:\Users\admin\AppData\Local\Temp\garble-shared1063768626\ArkHost\main.go
:4: imported and not used: "github.com/gofiber/fiber/v2" as fiber
exit status 2
exit status 2

but with go build it work properly

$ go build ARS
$ ARS.exe
>> Fiber v2.26.0

more importantly, it run properly with non-literals encrypt mode
but with go build it work properly

$ garble build ARS
$ ARS.exe
>> Fiber v2.26.0
@mvdan
Copy link
Member

mvdan commented Feb 21, 2022

Nicely spotted. This is likely because of #360; -literals now replaces fiber.Version with its actual constant string before obfuscating that literal, so then the fiber package stops being imported entirely.

The easiest fix is probably to appease the "imported and not used" check in some way, such as by removing unused imports after literal obfuscation. cc @lu4p

@lu4p
Copy link
Member

lu4p commented Feb 21, 2022

Because of the /v2 suffix of the import path the package name and path can't be easily matched by only looking at the ast.

We could just ignore version suffixes, however package names can be entirely independent from their path, therefore we should somehow do the same analysis as the compiler.

Related Todo: https://github.com/burrowers/garble/blob/master/internal/literals/literals.go#L145

@mvdan
Copy link
Member

mvdan commented Feb 21, 2022

Yeah, we definitely need type information to resolve this, because with syntax alone, Go imports aren't clear. Luckily, we do already have type information.

lu4p added a commit that referenced this issue Mar 23, 2022
to determine if it still needs to be  imported after literal obfuscation

Fixes #481
lu4p added a commit that referenced this issue Mar 23, 2022
lu4p added a commit that referenced this issue Mar 23, 2022
lu4p added a commit that referenced this issue Mar 24, 2022
lu4p added a commit that referenced this issue Mar 24, 2022
lu4p added a commit that referenced this issue Mar 24, 2022
lu4p added a commit that referenced this issue Mar 24, 2022
lu4p added a commit that referenced this issue Mar 24, 2022
lu4p added a commit that referenced this issue Mar 24, 2022
@lu4p lu4p closed this as completed in #512 Mar 24, 2022
lu4p added a commit that referenced this issue Mar 24, 2022
@mvdan mvdan added this to the v0.6.0 milestone May 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants