Google “ open source elf packer ”。

另外，有些壳的保护强度还不如 obfuscator-llvm。

大部分加密壳都会去掉多余的符号信息，你就不用单独 strip 了。UPX 是压缩壳，安全性本来就不是它的主要考虑。

把 core dump 扔到 IDA 里面分析。没有函数名，可以和原来有函数名的可执行文件进行比较，手工或写个脚本自动把函数名映射回来。

可能和楼主想法相关的一种加密方法：Format-transforming encryption。可以看看这篇论文 https://eprint.iacr.org/2012/494.pdf

PatchCleaner: http://www.homedev.com.au/free/patchcleaner

@Baymaxbowen 楼主留个邮箱，我来联系你。

“已提交内存”会涨到多少？ Unusable virtual memory size 又是多少？听上去好像是因为内存泄漏（提交内存大小不减少） + 堆内存碎片（大量的 unusable virtual memory ）。建议用 WinDbg 调试 ctfmon.exe ，在虚拟内存分配函数（ VirtualAlloc*）上下个断点，看看调用栈都有哪些。

Unusable virtual memory: http://blogs.microsoft.co.il/sasha/2014/07/22/tracking-unusable-virtual-memory-vmmap/

"The feature is designed to speed up DNS resolution on a device running Windows 8 or newer by sending DNS requests across all available network adapters. Microsoft refined the feature in Windows 10 as it selects the information that is returned the fastest automatically."

来源： https://www.ghacks.net/2017/08/14/turn-off-smart-multi-homed-name-resolution-in-windows/

这个漏洞好像是在 speculative execution 中的一个 timing side-channel。Intel 表示不是他们的问题，我认为是有一定道理的。Intel 在设计时可能压根没考虑到 speculative execution 中会有 side-channel 漏洞，因此也就没做相应的 verification。

VuSec 的一个人做了 PoC: https://twitter.com/brainsmoke/status/948561799875502080

Intel 的声明: https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

供参考。

需要设置一下。参见文档： https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html

@shijunyi 楼主留个邮箱，我可以帮你远程解决。

楼主试一下把 -w、1000、-n、5 分成四个参数，而不是两个参数传给 Popen ？

反汇编的结果是汇编。反编译的结果是接近源代码的表示。最常用的反编译工具是 Hex-rays decompiler。

这锅估计是显卡驱动程序背吧。你可以存一个 kernel dump，然后用 WinDbg 分析下。

蓝屏时的 STOP code 是什么？