justan0th3rstud3nt
/
garble
mirror of https://github.com/burrowers/garble
1
0
Fork 0
Code Issues 1 Projects Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
master
ci-test
literalRecheck
v0.14.1
v0.14.0
v0.13.0
v0.12.1
v0.12.0
v0.11.0
v0.10.1
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.0
v0.7.2
v0.7.1
v0.7.0
v0.6.0
v0.5.1
v0.5.0
v0.4.0
v0.3.0
v0.2.0
v0.1.0
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8ee4c91196'
${ noResults }
garble/testdata/script/asm.txtar

157 lines
3.5 KiB
Plaintext
Raw Normal View History Unescape Escape

obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
# Note that it doesn't really matter if the assembly below is badly written.
# We just care enough to see that it obfuscates and keeps the same behavior.
CI: test on GOARCH=386 Note that this cross-compilation disables cgo by default, and so the cgo.txt test script isn't run on GOARCH=386. That seems fine for now, as the test isn't arch-specific. This testing uncovered one build failure in internal/literals; the comparison between int and math.MaxUint32 is invalid on 32-bit. To fix that build failure, use int64 consistently. One test also incorrectly assumed amd64; it now supports 386 too. For any other architecture, it's being skipped for now. I also had to increase the -race test timeout, as it usually takes 8-9m on GitHub Actions, and the timeout would sometimes trigger. Finally, use "go env" rather than "go version" on CI, which gives us much more useful information, and also includes Go's own version now via GOVERSION. Fixes #426.
3 years ago
# TODO: support arm64, at least
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
[!amd64] skip 'the assembly is only written for amd64'
CI: test on GOARCH=386 Note that this cross-compilation disables cgo by default, and so the cgo.txt test script isn't run on GOARCH=386. That seems fine for now, as the test isn't arch-specific. This testing uncovered one build failure in internal/literals; the comparison between int and math.MaxUint32 is invalid on 32-bit. To fix that build failure, use int64 consistently. One test also incorrectly assumed amd64; it now supports 386 too. For any other architecture, it's being skipped for now. I also had to increase the -race test timeout, as it usually takes 8-9m on GitHub Actions, and the timeout would sometimes trigger. Finally, use "go env" rather than "go version" on CI, which gives us much more useful information, and also includes Go's own version now via GOVERSION. Fixes #426.
3 years ago
set testscript's RequireExplicitExec and RequireUniqueNames The first makes our test scripts more consistent, as all external program executions happen via "exec" and are not as easily confused with custom builtin commands like our "generate-literals". The second catches mistakes if any of our txtar files have duplicate files, where all but one of the contents would be ignored before.
2 years ago
exec garble build
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
exec ./main
reduce unnecessary std imports in tests Since we have to recompile all dependencies, this reduces a substantial amount of work, reducing 'go test -short' time from ~16s to ~12s on my laptop.
5 years ago
cmp stderr main.stderr
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
! binsubstr main$exe 'test/main' 'addJmp' 'AddImpl' 'garble_'
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
fail on user packages with build errors early The added test case would panic, because we would try to hash a name with a broken package's GarbleActionID, which was empty. We skipped over all package errors in appendListedPackages because two kinds of errors were OK in the standard library. However, this also meant we ignored real errors we should stop at, because obfuscating those user packages is pointless. Add more assertions, check for the OK errors explicitly, and fail on any other error immediately. Note that, in the process, I also found a bug in cmd/go. Uncovered by github.com/bytedance/sonic, whose internal/loader package fails to build on Go 1.20.
2 years ago
# We used to panic on broken packages with assembly.
set testscript's RequireExplicitExec and RequireUniqueNames The first makes our test scripts more consistent, as all external program executions happen via "exec" and are not as easily confused with custom builtin commands like our "generate-literals". The second catches mistakes if any of our txtar files have duplicate files, where all but one of the contents would be ignored before.
2 years ago
! exec garble build ./broken/...
fail on user packages with build errors early The added test case would panic, because we would try to hash a name with a broken package's GarbleActionID, which was empty. We skipped over all package errors in appendListedPackages because two kinds of errors were OK in the standard library. However, this also meant we ignored real errors we should stop at, because obfuscating those user packages is pointless. Add more assertions, check for the OK errors explicitly, and fail on any other error immediately. Note that, in the process, I also found a bug in cmd/go. Uncovered by github.com/bytedance/sonic, whose internal/loader package fails to build on Go 1.20.
2 years ago
stderr -count=1 'broken[/\\]asm[/\\].*MissingType'
stderr -count=1 'broken[/\\]syntax[/\\].*unexpected newline'
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
[short] stop # no need to verify this with -short
work around cmd/go issue relating to CompiledGoFiles See https://golang.org/issue/28749. The improved asm test would fail: go parse: $WORK/imported/imported_amd64.s:1:1: expected 'package', found TEXT (and 2 more errors) because we would incorrectly parse a non-Go file as a Go file. Add a workaround. The original reporter's reproducer with go-ethereum works now, as this was the last hiccup. Fixes #555.
3 years ago
# Ensure that reversing doesn't error with assembly files.
# It should fail, as there is nothing to reverse, but without any parse error.
stdin empty-reverse.txt
set testscript's RequireExplicitExec and RequireUniqueNames The first makes our test scripts more consistent, as all external program executions happen via "exec" and are not as easily confused with custom builtin commands like our "generate-literals". The second catches mistakes if any of our txtar files have duplicate files, where all but one of the contents would be ignored before.
2 years ago
! exec garble reverse .
work around cmd/go issue relating to CompiledGoFiles See https://golang.org/issue/28749. The improved asm test would fail: go parse: $WORK/imported/imported_amd64.s:1:1: expected 'package', found TEXT (and 2 more errors) because we would incorrectly parse a non-Go file as a Go file. Add a workaround. The original reporter's reproducer with go-ethereum works now, as this was the last hiccup. Fixes #555.
3 years ago
! stderr .
set testscript's RequireExplicitExec and RequireUniqueNames The first makes our test scripts more consistent, as all external program executions happen via "exec" and are not as easily confused with custom builtin commands like our "generate-literals". The second catches mistakes if any of our txtar files have duplicate files, where all but one of the contents would be ignored before.
2 years ago
exec garble -tiny build
Strip all filename and position info when -tiny is passed (#128) Co-authored-by: pagran <pagran@protonmail.com> Co-authored-by: lu4p <lu4p@pm.me>
5 years ago
exec ./main
cmp stderr main.stderr
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
! binsubstr main$exe 'addJmp' 'AddImpl'
Strip all filename and position info when -tiny is passed (#128) Co-authored-by: pagran <pagran@protonmail.com> Co-authored-by: lu4p <lu4p@pm.me>
5 years ago
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
go build
exec ./main
reduce unnecessary std imports in tests Since we have to recompile all dependencies, this reduces a substantial amount of work, reducing 'go test -short' time from ~16s to ~12s on my laptop.
5 years ago
cmp stderr main.stderr
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
binsubstr main$exe 'addJmp' 'AddImpl'
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
-- go.mod --
support referencing package paths with periods in assembly The test case is lifted from github.com/bytedance/sonic/internal/native, which had the following line: JMP github·com∕bytedance∕sonic∕internal∕native∕avx2·__quote(SB) Updates #621.
2 years ago
module test/with.many.dots/main
testdata: don't let tests rely on rewriting mod files In Go 1.15, if a dependency is required but not listed in go.mod/go.sum, it's resolved and added automatically. This is changing in 1.16. From that release, one will have to explicitly update the mod files via 'go mod tidy' or 'go get'. To get ahead of the curve, start using -mod=readonly to get the same behavior in 1.15, and fix all existing tests. The only tests that failed were imports.txt and syntax.txt, the only ones to require other modules. But since we're here, let's add the 'go' line to all go.mod files as well.
4 years ago
drop Go 1.22 and require Go 1.23.0 or later (#876) This lets us start taking advantage of featurs from Go 1.23, particularly tracking aliases in go/types and iterators. Note that we need to add code to properly handle or skip over the new *types.Alias type which go/types produces for Go type aliases. Also note that we actually turn this mode off entirely for now, due to the bug reported at https://go.dev/issue/70394. We don't yet remove our own alias tracking code yet due to the above. We hope to be able to remove it very soon.
5 months ago
go 1.23
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
-- main.go --
package main
import (
support referencing package paths with periods in assembly The test case is lifted from github.com/bytedance/sonic/internal/native, which had the following line: JMP github·com∕bytedance∕sonic∕internal∕native∕avx2·__quote(SB) Updates #621.
2 years ago
"test/with.many.dots/main/imported"
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
)
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
func addJmpPkgPath(x, y int32) int32
func addJmpPkgName(x, y int32) int32
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
// goData is used from both assembly and header files.
var goData = [4]uint64{1, 2, 3, 4}
func modifyGoData()
func modifyGoData2()
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
func main() {
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
println(addJmpPkgPath(1, 2))
println(addJmpPkgName(1, 2))
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
println(goData[0], goData[1])
modifyGoData()
println(goData[0], goData[1])
modifyGoData2()
println(goData[0], goData[1])
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
println(imported.AddImpl(3, 4))
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
}
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
-- garble_main_amd64.s --
#include "garble_define_amd64.h"
support inline comments in asm #include lines That is, the assembly line #include "foo.h" // bar would make garble run into an error, as we would try to parse the #include directive before we stripped comments, effectively trying to unquote the string "foo.h" // bar rather than just the included filename "foo.h" Add test cases for asm but also cgo, while at it. Fixes #812.
1 year ago
#include "extra/garble_define2_amd64.h" // Inline: many·special∕asm·runes.
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
skip over comments when obfuscating assembly github.com/bytedance/sonic has many comments in its assembly files, and one in particular caused us trouble: internal/rt/asm_amd64.s:2:// Code generated by asm2asm, DO NOT EDIT· Since we looked for "middle dot" characters anywhere, we would try to load the package "EDIT", which clearly does not exist. To fix that, start skipping over comments. Thankfully, Go's assembly syntax only supports "//" line comments, so it's enough to read one line at a time and skip them quickly. We also longer need a regular expression to find #include lines. While here, two other minor bits of cleanup. First, rename transformGo to transformGoFile, for clarity. Second, use ".s" extensions for obfuscated assembly filenames, just like we do with the comiler and ".go" files. Updates #621.
2 years ago
// A comment may include many·special∕asm·runes and it's okay.
support inline and non-spaced comments in assembly Go contains such inline comments, like: crypto/aes/gcm_ppc64x.s:129: VPMSUMD IN, HL, XL // H.lo·H.lo We didn't notice since these comments were somewhat rare. While here, "//" does not need to be followed by a space. The code turns out to be pretty easy with strings.Cut. Fixes #672.
2 years ago
//No space: many·special∕asm·runes.
// Indented: many·special∕asm·runes.
DATA bar+0(SB)/8, $0 // Inline: many·special∕asm·runes.
skip over comments when obfuscating assembly github.com/bytedance/sonic has many comments in its assembly files, and one in particular caused us trouble: internal/rt/asm_amd64.s:2:// Code generated by asm2asm, DO NOT EDIT· Since we looked for "middle dot" characters anywhere, we would try to load the package "EDIT", which clearly does not exist. To fix that, start skipping over comments. Thankfully, Go's assembly syntax only supports "//" line comments, so it's enough to read one line at a time and skip them quickly. We also longer need a regular expression to find #include lines. While here, two other minor bits of cleanup. First, rename transformGo to transformGoFile, for clarity. Second, use ".s" extensions for obfuscated assembly filenames, just like we do with the comiler and ".go" files. Updates #621.
2 years ago
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
// Reference an imported package by its package path.
TEXT ·addJmpPkgPath(SB),$0-16
JMP test∕with·many·dots∕main∕imported·AddImpl(SB)
// Reference the current package by its package name.
TEXT ·addJmpPkgName(SB),$0-16
JMP main·addJmpPkgPath(SB)
support referencing package paths with periods in assembly The test case is lifted from github.com/bytedance/sonic/internal/native, which had the following line: JMP github·com∕bytedance∕sonic∕internal∕native∕avx2·__quote(SB) Updates #621.
2 years ago
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
TEXT ·modifyGoData(SB),$0-16
addGoDataTo($12)
ADDL $34, ·goData+8(SB)
RET
TEXT ·modifyGoData2(SB),$0-16
addGoDataTo2($12)
ADDL $34,·goData+8(SB) // note the lack of a space
RET
-- garble_define_amd64.h --
#define addGoDataTo(arg) \
ADDL arg, ·goData+0(SB)
-- extra/garble_define2_amd64.h --
#define addGoDataTo2(arg) \
ADDL arg, ·goData+0(SB)
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
-- imported/imported.go --
package imported
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
func AddImpl(x, y int32) int32
// Reference the current package by its package path.
func addJmpPkgPath(x, y int32) int32
// Reference the current package by its package path.
func addJmpPkgName(x, y int32) int32
CI: test on GOARCH=386 Note that this cross-compilation disables cgo by default, and so the cgo.txt test script isn't run on GOARCH=386. That seems fine for now, as the test isn't arch-specific. This testing uncovered one build failure in internal/literals; the comparison between int and math.MaxUint32 is invalid on 32-bit. To fix that build failure, use int64 consistently. One test also incorrectly assumed amd64; it now supports 386 too. For any other architecture, it's being skipped for now. I also had to increase the -race test timeout, as it usually takes 8-9m on GitHub Actions, and the timeout would sometimes trigger. Finally, use "go env" rather than "go version" on CI, which gives us much more useful information, and also includes Go's own version now via GOVERSION. Fixes #426.
3 years ago
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
-- imported/imported_amd64.s --
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
TEXT ·AddImpl(SB),$0-16
fail on user packages with build errors early The added test case would panic, because we would try to hash a name with a broken package's GarbleActionID, which was empty. We skipped over all package errors in appendListedPackages because two kinds of errors were OK in the standard library. However, this also meant we ignored real errors we should stop at, because obfuscating those user packages is pointless. Add more assertions, check for the OK errors explicitly, and fail on any other error immediately. Note that, in the process, I also found a bug in cmd/go. Uncovered by github.com/bytedance/sonic, whose internal/loader package fails to build on Go 1.20.
2 years ago
MOVL x+0(FP), BX
MOVL y+4(FP), BP
ADDL BP, BX
MOVL BX, ret+8(FP)
RET
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
TEXT ·addJmpPkgPath(SB),$0-16
JMP test∕with·many·dots∕main∕imported·AddImpl(SB)
TEXT ·addJmpPkgName(SB),$0-16
JMP imported·AddImpl(SB)
fail on user packages with build errors early The added test case would panic, because we would try to hash a name with a broken package's GarbleActionID, which was empty. We skipped over all package errors in appendListedPackages because two kinds of errors were OK in the standard library. However, this also meant we ignored real errors we should stop at, because obfuscating those user packages is pointless. Add more assertions, check for the OK errors explicitly, and fail on any other error immediately. Note that, in the process, I also found a bug in cmd/go. Uncovered by github.com/bytedance/sonic, whose internal/loader package fails to build on Go 1.20.
2 years ago
-- broken/syntax/broken.go --
package broken
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
func AddImpl
fail on user packages with build errors early The added test case would panic, because we would try to hash a name with a broken package's GarbleActionID, which was empty. We skipped over all package errors in appendListedPackages because two kinds of errors were OK in the standard library. However, this also meant we ignored real errors we should stop at, because obfuscating those user packages is pointless. Add more assertions, check for the OK errors explicitly, and fail on any other error immediately. Note that, in the process, I also found a bug in cmd/go. Uncovered by github.com/bytedance/sonic, whose internal/loader package fails to build on Go 1.20.
2 years ago
-- broken/asm/imported_amd64.s --
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
TEXT ·AddImpl(SB),$0-16
fail on user packages with build errors early The added test case would panic, because we would try to hash a name with a broken package's GarbleActionID, which was empty. We skipped over all package errors in appendListedPackages because two kinds of errors were OK in the standard library. However, this also meant we ignored real errors we should stop at, because obfuscating those user packages is pointless. Add more assertions, check for the OK errors explicitly, and fail on any other error immediately. Note that, in the process, I also found a bug in cmd/go. Uncovered by github.com/bytedance/sonic, whose internal/loader package fails to build on Go 1.20.
2 years ago
MOVL x+0(FP), BX
MOVL y+4(FP), BP
ADDL BP, BX
MOVL BX, ret+8(FP)
RET
-- broken/asm/broken.go --
package broken
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
func AddImpl(x, y int32) MissingType
fail on user packages with build errors early The added test case would panic, because we would try to hash a name with a broken package's GarbleActionID, which was empty. We skipped over all package errors in appendListedPackages because two kinds of errors were OK in the standard library. However, this also meant we ignored real errors we should stop at, because obfuscating those user packages is pointless. Add more assertions, check for the OK errors explicitly, and fail on any other error immediately. Note that, in the process, I also found a bug in cmd/go. Uncovered by github.com/bytedance/sonic, whose internal/loader package fails to build on Go 1.20.
2 years ago
-- broken/imported_amd64.s --
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
TEXT ·AddImpl(SB),$0-16
CI: test on GOARCH=386 Note that this cross-compilation disables cgo by default, and so the cgo.txt test script isn't run on GOARCH=386. That seems fine for now, as the test isn't arch-specific. This testing uncovered one build failure in internal/literals; the comparison between int and math.MaxUint32 is invalid on 32-bit. To fix that build failure, use int64 consistently. One test also incorrectly assumed amd64; it now supports 386 too. For any other architecture, it's being skipped for now. I also had to increase the -race test timeout, as it usually takes 8-9m on GitHub Actions, and the timeout would sometimes trigger. Finally, use "go env" rather than "go version" on CI, which gives us much more useful information, and also includes Go's own version now via GOVERSION. Fixes #426.
3 years ago
MOVL x+0(FP), BX
MOVL y+4(FP), BP
ADDL BP, BX
MOVL BX, ret+8(FP)
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
RET
reduce unnecessary std imports in tests Since we have to recompile all dependencies, this reduces a substantial amount of work, reducing 'go test -short' time from ~16s to ~12s on my laptop.
5 years ago
-- main.stderr --
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
3
support assembly references to package names Go's package runtime/internal/atomic contains references to functions which refer to the current package by its package name alone: src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_loong64.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) src/runtime/internal/atomic/atomic_mips64x.s: JMP atomic·Load64(SB) We could only handle unqualified or fully qualified references, like: JMP ·Load64(SB) JMP runtime∕internal∕atomic·Load64(SB) Apparently, all three forms are equally valid. Add a test case and fix it. I checked whether referencing an imported package by its name worked; it does not seem to be the case. This feature appears to be restricted to the current package alone. While here, we only need goPkgPath when we need to call listPackage. Fixes #619.
2 years ago
3
obfuscate Go names in asm header files Assembly files can include header files within the same Go module, and those header files can include "defines" which refer to Go names. Since those Go names are likely being obfuscated, we need to replace them just like we do in assembly files. The added mechanism is rather basic; we add two TODOs to improve it. This should help when building projects like go-ethereum. Fixes #553.
3 years ago
1 2
13 36
25 70
start supporting asm functions better Spotted while trying to link a program using unix.Syscall, since its implementation is assembly. Telling if a function couldn't be garbled isn't trivial. If that function belongs to an imported package, we only load its export data instead of type-checking from source, so we don't have all the information needed. Instead, use the gc export data importer to import two versions of each dependency: its original version, for the initial type-checking, and its garbled version, to check if any of its exported names weren't garbled. Updates #9.
5 years ago
7
work around cmd/go issue relating to CompiledGoFiles See https://golang.org/issue/28749. The improved asm test would fail: go parse: $WORK/imported/imported_amd64.s:1:1: expected 'package', found TEXT (and 2 more errors) because we would incorrectly parse a non-Go file as a Go file. Add a workaround. The original reporter's reproducer with go-ethereum works now, as this was the last hiccup. Fixes #555.
3 years ago
-- empty-reverse.txt --