zeebo / goof

Goof (Go Object Finder) is a package that does the unthinkable to your binary

Goof

Goof lets you call functions in your binary with just the string of their name. How?

var troop goof.Troop
out, err := troop.Call("fmt.Fprintf", os.Stdout, "hello %s", []interface{}{"world"})
if err != nil { // some error calling the function
	return err
}
n, err := out[0].(int), out[1].(error)
if err != nil {
	return err
}
fmt.Printf("wrote %d bytes\n", n)

Caveat: you have to have called fmt.Fprintf elsewhere in your binary.

Goof lets you get access to globals in your binary with just the string of their name. How?

var troop goof.Troop
rv, err := troop.Global("net/http.DefaultServeMux")
if err != nil { // couldn't find it
	return err
}
// rv contains an addressable reflect.Value of the default ServeMux!

Caveat: the global must be used elsewhere in the binary somehow.

Goof lets you get access to all of the reflect.Types in your binary. How?

var troop goof.Troop
types, err := troop.Types()
if err != nil { // something went wrong getting them
	return err
}
for _, typ := range types {
	fmt.Println(typ)
}

Caveat: the types must be possible outputs to reflect.TypeOf(val) in your binary.

Usage

You should probably just make a single Troop in your binary and use that everywhere since it does a lot of caching and work on first use.

How?

It loads up the dwarf information of any binary it's loaded in and then does a bunch of unsafe tom foolery to perform these dirty deeds. How unsafe is it?

• Reusing needles unsafe.
• Jumping into a shark tank with a steak swimming suit unsafe.
• Carnival ride unsafe.
• Driving on the wrong side of the highway blindfolded unsafe.

Should I use this?

Do you really have to ask? OF COURSE! If you do, please let me know what terrible idea this enabled. I'm very interested.

Testimonials

"I can't wait to get some goof in my manhole!" - @jtolds

"README is hilarious 😂"

"Now I just need to come up with something horrendously risky to use this for..."

goof's Issues

windows support

microsoft shouldn't be immune to these shenanigans.

call fmt.Printf: unknown or uncallable function

I run the simple demo on Mac osx but it can't run

package main

import (
	"fmt"

	"github.com/zeebo/goof"
)

func main() {
	var troop goof.Troop
	out, err := troop.Call("fmt.Printf", "hello %s", []interface{}{"world"})
	if err != nil { // some error calling the function
		panic(err)
	}
	n, err := out[0].(int), out[1].(error)
	if err != nil {
		panic(err)
	}
	fmt.Println("wrote", n, "bytes")

}

go env:

go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/yuepan/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gq/jd9v5dd95p570hkztblb8ht40000gn/T/go-build786720216=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

go version:

go version go1.8.1 darwin/amd64

wildly unsafe

There's no way this package should be used by anyone the way it's written. Please consider other ways the accomplish the goals.

Working on v1.11.5?

I tried this on v1.11.5 and I get the following:

decoding dwarf section info at offset 0x0: too short

Is this because the internal props have changed? Code:

    func main() {
	var troop goof.Troop
	_, err := troop.Call("fmt.Println", "hello %s", []interface{}{"world"})
	if err != nil { // some error calling the function
	fmt.Println(err)
		return
	}

remote attach to a process

how cool would it be to goof up an already running process? like a crappy debugger or something.

maybe we can use some simple stuff to just inject ourselves and launch a manhole in a new goroutine to run async with the process.