du521521521 2016-09-15 21:27
浏览 78
已采纳

Golang二进制文件如何以及为什么显示关于错误的文件和行信息[重复]

This question already has an answer here:

i was playing around with go sync groups and i just tried what happens if i add more groups than i mark done . and i get the runtime error i posted below. So the question here is if go is compiled into true machine code unlike java or c# how come my file even line info can be shown in runtime errors .If file info is kept in the binary i think it can be easily decompiled . Am i doing something wrong do i need to add some kinda env variable for prod builds or its just like c# theres no true way to hide your code

</div>
  • 写回答

1条回答 默认 最新

  • doupu5941 2016-09-15 22:57
    关注

    So for fun, I wrote a trivial Go program that just panic()s and tried farting around with objdump and objcopy to see where this information is. On Linux (perhaps others), Go sticks the relevant info in the ELF section .gopclntab. If you remove it, the reference to the actual program source disappears, but the runtime crashes. And there are references to a ton more runtime.* things in that section (presumably for linkage and introspection). I'm thinking it's unlikely that you can realistically run a Go program with this information totally gone.

    You can remove the DWARF info for some security as mentioned elsewhere on SO and a bunch of ELF sections vanish, but your best bet if you're really worried would probably be to preprocess your sources to obfuscate identifiers and filenames before compile. But there doesn't appear to be a ready-made tool to do so.

    I'm not one of the Go designers, but I'm guessing going much farther is impractical due to things like introspection (something which e.g. C can't do). Compressors like upx will obfuscate the file at rest slightly (and seem to work OK with compiled Go--maybe a caveat or two in there), but it's trivial to undo if you know it's there (to the point that any security type would take away my developer's licence for my having even mentioned it).

    The reality is that the best you can realistically do is speedbump people who are really interested in messing with your code. Obfuscating sources, if you're really that motivated to do it, would be your best bet (though ultimately still futile with sufficiently determined attackers).

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥100 set_link_state
  • ¥15 虚幻5 UE美术毛发渲染
  • ¥15 CVRP 图论 物流运输优化
  • ¥15 Tableau online 嵌入ppt失败
  • ¥100 支付宝网页转账系统不识别账号
  • ¥15 基于单片机的靶位控制系统
  • ¥15 真我手机蓝牙传输进度消息被关闭了,怎么打开?(关键词-消息通知)
  • ¥15 装 pytorch 的时候出了好多问题,遇到这种情况怎么处理?
  • ¥20 IOS游览器某宝手机网页版自动立即购买JavaScript脚本
  • ¥15 手机接入宽带网线,如何释放宽带全部速度