runtime error when running ObfuscateStrings
hamstah opened this issue · comments
Hi
I get the following runtime panic when running on any file (shell, binary etc).
It happens on both the version downloaded with go get and one build manually from the source.
→ Obfuscating Launcher Stub...panic: runtime error: slice bounds out of range [-1:]
goroutine 1 [running]:
github.com/89luca89/pakkero/internal/pakkero.ObfuscateStrings(0xc0000b8e54, 0x3, 0xc0000b8e54, 0x3)
/home/xxx/go/pkg/mod/github.com/89luca89/pakkero@v0.0.0-20201116083101-db939131b0b5/internal/pakkero/obfuscation.go:251 +0x88f
I think the issue is that the return value of strings.Index is not checked here https://github.com/89luca89/pakkero/blob/0.7.0/internal/pakkero/obfuscation.go#L254
It returns -1 which fails on the next slice.
I'm not familiar with the code much yet so I'm not sure why this would fail
Happy idea?
Thanks
Hi @hamstah
I can reproduce this issue by compiling pakkero simply using go build
As you can see here: https://github.com/89luca89/pakkero#install
After downloading the source either using git or go get
, you have to compile in a specific way
cd $GOPATH/src/github.com/89luca89/pakkero;
make
and the resulting binary will be in dist
This is needed because during compilation time (excluding things like upx and strip) a foundamental step is that the Launcher.go
has to be injected inside the pakkero binary at compilation time.
It is done using -ldflags="-X github.com/89luca89/pakkero/internal/pakkero.LauncherStub=$$(base64 -w0 data/launcher.go) -s"
inside the compilation flags.
As you can see, compiling with go build
alone (or using the binary that go get
builds itself`) your issue is reproduced:
Following the README:
Let me know if you resolved :)
Bye
Hey,
So what I did was using go get which gave me a binary in $GOPATH/bin/pakkero
and this one has the issue.
I then followed the install instruction and built with make, then tried and had the same error.
I just tried again now and it worked, I think I probably didn't properly set my path or something and was still using the old binary in $GOPATH
instead as I just double checked now and the one I built and put in my path actually works.
Sorry for the hassle, late night brain messed up somewhere but don't have the log anymore :)
All good now though, thanks for the help anyway, really appreciate it.
No problem! Glad it worked out, if you have any suggestion or improvements to suggest don't hesitate to open new issues!
Bye!