sockets são uma API do kernel para comunicação. Usando a API de soquete, você pode trocar dados entre dois terminais por conexões TCP / IP, associações SCTP, datagramas UDP ou entre dois processos (datagrama ou conexão) usando soquetes de domínio Unix ...
Sendo uma API do kernel, qualquer interação com um soquete é feita por meio de chamadas do sistema ( socket , bind , connect , listen , accept , sendmsg , send , recv , write/read ...).
Normalmente, strace será capaz de rastreá-los porque strace rastreia as chamadas do sistema. O único mecanismo de comunicação que strace não consegue rastrear é o IPC sobre a memória compartilhada (porque a leitura / gravação de algo na memória obviamente não envolve uma chamada de sistema).
Provavelmente, no seu caso, é outra coisa. Minha aposta seria que o aplicativo é multi-threaded e você não está traçando o thread certo. Ou pode ser que o aplicativo seja setuid / setgid e não seja iniciado como superusuário.
Se você deseja rastrear o que está sendo substituído nos soquetes de domínio Unix, as opções são:
-
stracee outro depuradorptrace(rastreie o servidor ou os clientes) - O sistema de auditoria (
auditd/auditctl), que rastreia novamente as chamadas do sistema - use um truque de
LD_PRELOADpara agrupar as chamadas do sistema que interagem com o soquete - instrumentar o código do aplicativo para adicionar o registro lá.
- systemtap e outros sistemas de rastreamento / depuração de kernel de baixo nível como já mencionado
- insira um homem no meio.
Para o MITM, você poderia, por exemplo, usar socat . Aqui para um soquete de domínio Unix orientado a conexão, como para o X11:
socat -x unix-listen:/tmp/.X11-unix/X42,fork unix:/tmp/.X11-unix/X0
DISPLAY=:42 xlogo
Então, você vê o tráfego X11 que xlogo e o servidor X trocam.