Doesn’t a different structure as per the Go FAQ imply a specialized loader /runtime linker? I just assumed it did.
> On Aug 23, 2022, at 1:47 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Tue, Aug 23, 2022 at 9:29 AM Robert Engels <reng...@ix.netcom.com> wrote: >> >> I did not read the analysis - just the thread here and earlier threads on >> this subject. My understanding that even though Go is statically linked the >> loader does relocations that confuse virus scanners. > > I'm not sure precisely what you mean, but I don't think that's > accurate. There is no Go loader. The statically linked binary > produced for a pure Go executable has no run-time relocations at all. > > My assumption--and it is just an assumption--is roughly the reverse: > because pure Go programs are statically linked, and because the symbol > table does not use the same names as a default C symbol table, a virus > scanner has a harder time seeing which system calls are being used. > Of course the same would be true for a statically linked C program, > but perhaps malware writers tend to steer clear of those. > > Obviously anything that Go is doing can also be done in C, but the > malware authors do have to work a bit harder to do that. > > Ian > > >> On Aug 23, 2022, at 11:05 AM, Brian Candler <b.cand...@pobox.com> wrote: >> >> >>> On Tuesday, 23 August 2022 at 16:49:57 UTC+1 ren...@ix.netcom.com wrote: >>> >>> I think what is being suggested that if the sec team bans all applications >>> that exhibit dynamic code loading behavior they’d be safer - which would >>> catch a lot of apps in the net. >> >> >> But the article quoted makes the opposite point: "Go binaries are often >> statically linked—meaning that all necessary libraries are included in the >> compiled binary" >> >> It also says: "Go’s large binary size causes analysis issues for some AV >> vendors since several security products struggle to handle larger files and >> have been known to just stop scanning and pass a binary if it is above a >> specific size." >> >> ROFL! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/73a6a242-ce44-4a48-8794-6f67a4b78167n%40googlegroups.com. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/DD066646-3624-4DF3-8634-44229425CF87%40ix.netcom.com. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW4kJbMswGH18fRrX66-Ty3nGrYRDpnWQcf9H56Wrnsew%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/687EFECB-6A7F-4EF0-BF7F-B974BFE9CD01%40ix.netcom.com.
