En esta nota, aprenderemos cómo obtener el código de máquina de una función Go directamente en tiempo de ejecución, imprimirlo usando un desensamblador, y en el camino descubriremos varios trucos como obtener la dirección de una función sin llamarla.

Advertencia : este mini artículo no le enseñará nada útil.

Valor de función en Go

Primero, determinemos qué es una función Go y por qué necesitamos el concepto de valor de función .

Esto se explica mejor con el documento Go 1.1 Function Calls . El documento no es nuevo, pero la mayor parte de la información en él sigue siendo relevante.

En el nivel más bajo, siempre es un puntero al código ejecutable, pero cuando usamos funciones / cierres anónimos o pasamos una función como interface{} , este puntero está oculto dentro de alguna estructura.

El nombre de la función en sí no es una expresión, por lo tanto, dicho código no funciona:

 // https://play.golang.org/p/wXeVLU7nLPs package main func add1(x int) int { return 1 } func main() { addr := &add1 println(addr) } 

compile: cannot take the address of add1

Pero al mismo tiempo, podemos obtener el function value la function value través del mismo nombre de función:

 // https://play.golang.org/p/oWqv_FQq4hy package main func add1(x int) int { return 1 } func main() { f := add1 // <-------- addr := &f println(addr) } 

Este código se inicia, pero imprimirá la dirección de una variable local en la pila, que no es exactamente lo que queríamos. Pero, como se mencionó anteriormente, la dirección de la función todavía está allí, solo necesita saber cómo acceder a ella.

El paquete reflect.Value.Call() depende de este detalle de implementación para ejecutar exitosamente reflect.Value.Call() . Allí (reflect / makefunc.go) puede espiar el siguiente paso para obtener la dirección de la función:

 dummy := makeFuncStub code := **(**uintptr)(unsafe.Pointer(&dummy)) 

El código anterior muestra una idea básica que puede refinar a una función:

 // funcAddr returns function value fn executable code address. func funcAddr(fn interface{}) uintptr { // emptyInterface is the header for an interface{} value. type emptyInterface struct { typ uintptr value *uintptr } e := (*emptyInterface)(unsafe.Pointer(&fn)) return *e.value } 

La add1 función add1 se puede add1 llamando a funcAddr(add1) .

Obtener un bloque de código de función de máquina

Ahora que tenemos la dirección del comienzo del código de función de la máquina, nos gustaría obtener el código completo de la función. Aquí debe poder determinar dónde termina el código de la función actual.

Si la arquitectura x86 tuviera instrucciones de longitud fija, no sería tan difícil y varias heurísticas podrían ayudarnos, entre las cuales:

• Como regla, al final del código de función hay una paliza de INT3 instrucciones INT3 . Este es un buen marcador para el final del código de función, pero puede faltar.
• Las funciones con un marco distinto de cero para la pila tienen un prólogo que verifica si esta pila necesita expandirse. En caso afirmativo, se realiza un salto al código inmediatamente después del código de la función, y luego un salto al inicio de la función. El código que nos interesa estará en el medio.

Pero deberá decodificar honestamente las instrucciones, porque un byte by-pass puede encontrar el byte INT3 dentro de otra instrucción. Calcular la longitud de una instrucción para omitir tampoco es tan fácil, porque es x86, bebé .

La dirección de una función en el contexto del paquete de runtime de runtime veces se denomina PC , para enfatizar la capacidad de usar la dirección en algún lugar dentro de la función, y no solo el punto de entrada de la función. El resultado de funcAddr puede usarse como argumento para la función runtime.FuncForPC() para obtener runtime.Func sin llamar a la función en sí. A través de transformaciones inseguras de Año Nuevo, podemos acceder a runtime._func , que es informativo, pero no muy útil: no hay información sobre el tamaño del bloque de código de función.

Parece que sin la ayuda de los ELF no podemos hacer frente.

Para las plataformas donde los ejecutables tienen un formato diferente, la mayor parte del artículo seguirá siendo relevante, pero deberá usar no debug/elf , sino otro paquete de debug .

El ELF que se esconde en tu programa

La información que necesitamos ya está contenida en los metadatos del archivo ELF .

A través de os.Args[0] podemos acceder al archivo ejecutable en sí, y ya obtener la tabla de símbolos.

 func readELF() (*elf.File, error) { f, err := os.Open(os.Args[0]) if err != nil { return nil, fmt.Errorf("open argv[0]: %w", err) } return elf.NewFile(f) } 

Busca un personaje dentro de elf.File

Todos los caracteres se pueden File.Symbols() utilizando el método File.Symbols() . Este método devuelve []elf.Symbol , que contiene el campo Symbol.Size : este es el "tamaño de la función" que estamos Symbol.Size . El campo Symbol.Value debe coincidir con el valor devuelto por funcAddr .

Puede buscar el símbolo deseado por dirección ( Symbol.Value ) o por nombre ( Symbol.Name ). Si los caracteres se ordenaran por nombre, sería posible usar sort.Search() , pero esto no es así:

Los símbolos se enumerarán en el orden en que aparecen en el archivo.

Si a menudo necesita encontrar caracteres en la tabla, debe crear un índice adicional, por ejemplo, a través de map[string]*elf.Symbol o map[uintptr]*elf.Symbol .

Como ya sabemos cómo obtener la dirección de una función por su valor, la buscaremos:

 func elfLookup(f *elf.File, value uint64) *elf.Symbol { symbols, err := f.Symbols() if err != nil { return nil } for _, sym := range symbols { if sym.Value == value { return &sym } } return nil } 

Nota : para que este enfoque funcione, necesitamos una tabla de caracteres. Si el binario está construido con ` -ldflags "-s" ', entonces elfLookup() siempre devolverá nil . Si ejecuta el programa a través de go run , puede encontrar el mismo problema. Para ver ejemplos del artículo, se recomienda hacer ' go build ' o ' go install ' para obtener archivos ejecutables.

Obtener el código de función de la máquina

Conociendo el rango de direcciones en las que se encuentra el código ejecutable, solo queda extraerlo en forma de []byte para un procesamiento conveniente.

 func funcCode(addr uintptr) ([]byte, error) { elffile, err := readELF() if err != nil { return nil, fmt.Errorf("read elf: %w", err) } sym := elfLookup(elffile, uint64(addr)) if sym == nil { return nil, fmt.Errorf("can't lookup symbol for %x", addr) } code := *(*[]byte)(unsafe.Pointer(&reflect.SliceHeader{ Data: addr, Len: int(sym.Size), Cap: int(sym.Size), })) return code, nil } 

Este código se simplifica intencionalmente para la demostración. No debe leer ELF cada vez y hacer una búsqueda lineal en su tabla.

El resultado de la función funcCode() es un segmento con bytes del código de función de la máquina. Debería funcAddr() resultado de llamar a funcAddr() .

 code, err := funcCode(funcAddr(add1)) if err != nil { log.Panicf("can't get function code: %v", err) } fmt.Printf("% x\n", code) // => 48 8b 44 24 08 48 ff c0 48 89 44 24 10 c3 

Desmontaje del código de máquina

Para facilitar la lectura del código de la máquina, utilizaremos un desensamblador.

Estoy más familiarizado con los proyectos zydis e Intel XED , por lo que, en primer lugar, mi elección recae en ellos.

Para Go, puede utilizar el enlace go-zydis , que es lo suficientemente bueno y fácil de instalar para nuestra tarea.

Describamos la abstracción de "omitir las instrucciones de la máquina", con la ayuda de la cual puede implementar otras operaciones:

 func walkDisasm(code []byte, visit func(*zydis.DecodedInstruction) error) error { dec := zydis.NewDecoder(zydis.MachineMode64, zydis.AddressWidth64) buf := code for len(buf) > 0 { instr, err := dec.Decode(buf) if err != nil { return err } if err := visit(instr); err != nil { return err } buf = buf[int(instr.Length):] } return nil } 

Esta función toma un segmento de código de máquina como entrada y llama a una función de devolución de llamada para cada instrucción decodificada.

En base a esto, podemos escribir el printDisasm que printDisasm :

 func printDisasm(code []byte) error { const ZYDIS_RUNTIME_ADDRESS_NONE = math.MaxUint64 formatter, err := zydis.NewFormatter(zydis.FormatterStyleIntel) if err != nil { return err } return walkDisasm(code, func(instr *zydis.DecodedInstruction) error { s, err := formatter.FormatInstruction(instr, ZYDIS_RUNTIME_ADDRESS_NONE) if err != nil { return err } fmt.Println(s) return nil }) } 

Si ejecutamos printDisasm en el add1 función add1 , obtenemos el resultado esperado:

 mov rax, [rsp+0x08] inc rax mov [rsp+0x10], rax ret 

Validación de resultados

Ahora intentaremos asegurarnos de que el código de ensamblador obtenido en la sección anterior sea correcto.

Como ya tenemos un binario compilado, puede usar el objdump suministrado con Go:

 $ go tool objdump -s 'add1' exe TEXT main.add1(SB) example.go example.go:15 0x4bb760 488b442408 MOVQ 0x8(SP), AX example.go:15 0x4bb765 48ffc0 INCQ AX example.go:15 0x4bb768 4889442410 MOVQ AX, 0x10(SP) example.go:15 0x4bb76d c3 RET 

Todo converge, solo la sintaxis es ligeramente diferente, lo que se espera.

Expresiones del método

Si necesitamos hacer lo mismo con los métodos, entonces, en lugar del nombre de la función, usaremos la expresión del método .

Digamos que nuestro add1 no es realmente una función, sino un método de tipo adder :

 type adder struct{} func (adder) add1(x int) int { return x + 2 } 

Luego, la llamada para obtener la dirección de la función se verá como funcAddr(adder.add1) .

Conclusión

Llegué a estas cosas no por casualidad y, tal vez, en uno de los siguientes artículos le diré cómo se planeó utilizar todos estos mecanismos. Mientras tanto, propongo tratar este artículo como una descripción superficial de cómo el runtime de runtime y el reflect miran nuestras funciones Go a través del valor de la función.

Lista de recursos utilizados:

• Ir 1.1 Llamadas de función
• Analizando ejecutables de Golang
• Ir diseño "ABI interno"