很多安全人员在做二进制审计或逆向分析时，会发现某个程序里没有调用 libc 的 printf、strcpy 这类常见函数，但程序照样能打印日志、处理字符串——这往往是因为它链接了静态库函数。
静态库函数不是“自带的”，是“塞进去的”
动态链接时，程序运行依赖系统里的 libc.so 或 msvcrt.dll；而静态链接，是把 .a（Linux）或 .lib（Windows）文件里的函数代码直接复制进最终的可执行文件。比如你用 gcc -static hello.c -o hello 编译，glibc 里的一堆函数（如 malloc、memcpy、strlen）就全被“焊死”在 hello 里了。
这意味着：漏洞不会随系统更新修复。2017 年的 OpenSSL 静态链接旧版本，哪怕系统已升级到 1.1.1w，只要程序没重编译，Heartbleed 的变种逻辑仍可能潜伏其中。
安全审计中容易被忽略的点
IDA 或 Ghidra 反编译时，静态库函数常显示为“sub_4012A0”这类无名函数，不像动态调用那样标着 call strlen。尤其像 memcpy、memcmp 这类底层函数，如果原始库版本存在整数溢出或边界检查缺陷，攻击者可能通过精心构造输入触发栈溢出或信息泄露。
举个真实例子：某工控设备固件使用了 2013 年版的 zlib 静态库，其中 inflate_fast 函数对长度字段校验不严。红队在发送畸形压缩数据包后，成功绕过 ASLR 触发任意地址读取。
怎么快速识别？
Linux 下用 file 命令看是否含 “statically linked”；再用 readelf -d binary | grep NEEDED，如果输出为空，基本就是全静态。Windows 下可用 dumpbin /imports binary.exe，若只看到 KERNEL32.dll、ntdll.dll 等极少数系统 DLL，其余逻辑都在 PE 体内，大概率混入了静态 CRT 或自研库函数。
更进一步，用 strings binary | grep -i "zlib\|openssl\|curl"，能快速定位嵌入了哪些第三方静态库，再比对已知 CVE 影响范围。
开发侧的建议
别为了“部署方便”盲目加 -static。若必须静态链接，至少做到三点：一、锁定开源库 commit hash，写进构建脚本；二、启用编译器防护（-fstack-protector-strong -D_FORTIFY_SOURCE=2）；三、对关键静态函数（如内存操作类）做 wrapper 检查，例如自己实现一个带长度断言的 my_memcpy 替代原版。
void* my_memcpy(void* dst, const void* src, size_t n) {
if (n > 0x100000) return NULL; // 防超大拷贝
return memcpy(dst, src, n);
}静态库函数本身不是坏东西，但它把“不确定性”从运行时搬进了二进制里——看不见的代码，才是最该盯紧的那部分。