anchor.diff:  pgrep -x "crond" | xargs -I '{}' ls -la "/proc/{}/exe"
   ----
   
  -Anything looking like `/tmp/ ` (with a space) in the output is very
  +Anything looking like +"/tmp/&nbsp;"+ (with a space) in the output is very
   suspicious.
   
  -`pgrep` requires the `procps` package. Replace `pgrep -x crond` with `ps -ef |
  -grep crond | grep -v grep | awk '{print $2}'` if you can't install `pgrep`.
  -
  +`pgrep` requires the `procps` package. If you can't install the package,
  +replace:
  +
  +----
  +pgrep -x crond
  +----
  +
  +with
  +
  +----
  +ps -ef | grep crond | grep -v grep | awk '{print $2}'
  +----
   
   == Network-based Indicators
   
  
positive.code: 0x00000000 0          root      644        80         2
  0x00000000 32769      root      644        16384      2
  0x00000000 65538      root      644        280        2
  0x000010e0 465272836  root      666        3282312    0
  ....
  
  Then to look for the process that created the shared memory segment, use:
  
negative.code: 
  NOTE: This technique is ineffective if your distribution applied the patches
        for http://roumenpetrov.info/openssh/[X.509 certificate support] in
        OpenSSH. Gentoo with the `X509` USE flag is one such distribution. Use
        the shared memory inspection technique in that case.
  
  The command `ssh -G` has a different behavior on a system with
  