gomobile and tinygo

[gedw99]

anyone know if this in theory should work with gomobile and tinygo ?

[mvdan]

In theory it should be possible for them to work, as we mainly manipulate Go code.

In practice they very likely don't work with garble right now, and it would depend on each particular implementation's go build alternative - it should support:

• An alternative to go list -json -export -deps, which we need for inspecting the entire dependency tree
• The above go list should also include build IDs, which we require for the purpose of hashing and caching
• A go build -toolexec flag to insert garble at each asm/compile/link step

[mvdan]

Some more thoughts:

I don't think it's worth it to make garble work with gomobile directly. As long as we support cgo (we do) and -buildmode=c-archive/c-shared (I think we do, but it's not tested), then it should be possible to do obfuscated builds of mobile apps in Go.

tinygo is more interesting because it has no alternative via plain go build. Unfortunately, being based on LLVM, it doesn't really work the same way that go build does, so it would take some work to adapt garble for it.

tinygo calls go list -json -deps to obtain the source code to compile, so perhaps we could replace that to instead feed the obfuscated source code. However, note that this could mean no caching of the obfuscation process, which could be costly.

Another alternative would be to use an LLVM IR obfuscator, which could in theory work directly with tinygo. That's out of scope for garble, but I seem to understand there are such obfuscators out there already.

[mvdan]

-buildmode=c-archive/c-shared (I think we do, but it's not tested)

That's https://github.com/burrowers/garble/issues/297 now.

[aykevl]

tinygo calls go list -json -deps to obtain the source code to compile, so perhaps we could replace that to instead feed the obfuscated source code. However, note that this could mean no caching of the obfuscation process, which could be costly.

Note that this should be possible to made to work with caching, and perhaps even better than with the Go tooling. You can basically construct an alternative package tree and cache that for later builds, needing a single go list that you would need to run anyway. (That said, TinyGo is only now starting to implement build caching so the no-caching overhead will probably be small for now).

[gedw99]

Thanks all !

I will try about the above

[mvdan]

tinygo calls go list -json -deps to obtain the source code to compile, so perhaps we could replace that to instead feed the obfuscated source code.

I've opened https://github.com/burrowers/garble/issues/298 to track a garble list feature request. I'm closing this issue for now, as it's too broad and has been superseded by the two issues linked above. Thanks all!

[sintanial]

So, anybody understand how to use garble with go mobile ? How to run "gomobile bind" command )?

[pfarcasanu]

@mvdan @sintanial Any hints as to how to obfuscate gomobile output? Is it currently possible using garble (perhaps with extra work / workaround)?

[mvdan]

I'd suggest following https://github.com/burrowers/garble/issues/298 or leaving a comment there. That solution should work with tinygo in principle, as per https://github.com/burrowers/garble/issues/296#issuecomment-813099109. I honestly don't know how gomobile builds work, but I imagine it might be similar.

[cxcel]