Programs written in Golang have no secrets

[bruxis]

> This tool is only for legitimate programs only. It is strictly forbidden to use it for any malicious programs.

I'm sure the authors of malicious software will be certain to respect this clause

[slooonz]

It’s a way of saying "I decline any responsibility if anyone uses this tool for malicious purposes".

[golergka]

What about legitimate programs that are created to help legitimate penetration testers? And are forbidden from being used by people with malicious intent.

[harikb]

Just for the record, OP is talking about the "obfuscation" tool and not about the "decompiler".

[jetti]

I would imagine that it is there in order to protect themselves if someone uses their tool for malicious purposes as they can point to that statement and say they were not complicit.

[michaelcampbell]

This reminds me of the once-often used phrase on CraigsList: "No scammers"

I mean, why even put that there?

[userbinator]

Even if this program was not obfuscated by garble, compiled in the traditional way, it will still be flagged as malicious by many antivirus engines, regardless of whether it is signed or not.

IMHO these days it's far more about whether your binary is "known" than what it actually does. AV is a protection racket. I realised that long ago when "hello world" executables compiled with MSVC passed, but the same source code ran through GCC was deemed malicious and quickly deleted.

[jchw]

FYI, you have a small typo in the gopacker.dev URL in the docs here: https://gopacker.dev/docs/#how-to-use

> Download gopacker from https://gopcker.dev

[reportgunner]

Also right below that in title of step 3. - says pakcing instead of packing

3. Pakcing the programs with gopacker

[ivanjermakov]

I adore that obfuscated binaries are often treated as malicious by antiviruses. If you obfuscate there is something to hide.

[jonathanstrange]

I don't see how a small company with actual know how can protect their trade secrets otherwise. Software patents and other legal means seem much worse to me than trying to obfuscate trade secrets. Going open source is not a viable solution for most companies either.

[sliken]

If anyone can't read it in chrome, firefox makes it readable. In chrome it hides the title and about 20% of the left most text behind the navigation column. I tried playing with the font sizes and it didn't help.

[pepa65]

"need to purchase our product to get the license,the packed app is only valid for 7 days without license." and thats USD 299 per year.

[formerly_proven]

Where do all the symbols come from if the binary has been stripped? Does go add its own proprietary symbol table sections to go binaries?

[yencabulator]

I don't see the author stripping any binaries.

(And features of Go assume the binary is not stripped, too. The symbol table is useful!)

[bean-weevil]

So this lets you circumvent AV detection. How long until they add detections for this too?

[marcus0x62]

Since this article leans on screenshots from Virustotal detecting/not detecting something as malware, it is worth pointing out that just because the engine vendor x uses as part of their participation in Virustotal detected something as malicious, that doesn't mean their commercial products will do the same thing[0]. 1) The vendors all want to participate in Virustotal as marketing, and to get access to the raw samples (it is a reliable high-volume source of commodity malware.) 2) There is pressure to over-detect[1], so your competitors don't send out screenshots of your engine, which they imply to be your product, not detecting some novel malware sample, which of course they only do if their engine, which they also imply to be their product, detects it correctly. 3) Almost all vendors have additional detection mechanisms that don't make it into their Virus Total engines for various reasons.

So, anyway, if you want to get a sense of if, in general, your binary is likely to trip “AV,” then, by all means, submit it to VT. If, however, you want to know if a specific AV detects it, submitting it (or worse, some other binary processed with the same packer) to VT is dumb.

0 - https://docs.virustotal.com/docs/antivirus-differs

1 - interestingly, some researchers found lower detection rates on VT, which they attributed to the vendors not using their cloud-based analysis modules. https://www.researchgate.net/publication/364073462_A_Compara...

[pif]

Please, let me be that guy...

If you chose to write your program in Go, it is likely not worth to copy. ;-)

[djbusby]

I thought this was gonna be about how it's hard to keep secrets out of memory in a GC language. I had a friend working with Go and was surprised that on some heap-dump there was some secret-key they did not want exposed. So you have to set some ENV var (GOGC) so it clears faster.

[planede]

Reducing the time a secret lingers in memory is at best a mitigation. Linux has MADV_DONTDUMP for the madvise system call to exclude certain pages from core dumps. I'm not sure if something like this could be available in golang, preferably wrapped in some platform-agnostic way.

[Thaxll]

I don't see a difference between GC languages and others, so your secret is in a rust heap then what?

Every language have their memory exposed, GC has nothing to do with it.

[65a]

Go has a clear() function now, but I haven't checked to see how it actually behaves in terms of secret abatement in memory. https://tip.golang.org/ref/spec#Clear

[jonathanstrange]

There is memguard [1] but I don't know how secure it is.

[1] https://github.com/awnumar/memguard