suckit utilise des processus cachés. Essaye un truc genre
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,
$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
suckit utilise des processus cachés. Essaye un truc genre
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,
$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
suckit utilise des processus cachés. Essaye un truc genre
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,
$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
Bonjour
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED
/sbin/init est un lien symbolique
-> /lib/systemd/systemd
Bonjour
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED
/sbin/init est un lien symbolique
-> /lib/systemd/systemd
Bonjour
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED
/sbin/init est un lien symbolique
-> /lib/systemd/systemd
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED
/sbin/init est un lien symbolique
-> /lib/systemd/systemd
suckit utilise des processus cachés. Essaye un truc genre
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
qui devrait ne pas afficher d'erreurs
équivalent genre unhide.
François Boisson
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED
/sbin/init est un lien symbolique
-> /lib/systemd/systemd
suckit utilise des processus cachés. Essaye un truc genre
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
qui devrait ne pas afficher d'erreurs
équivalent genre unhide.
François Boisson
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED
/sbin/init est un lien symbolique
-> /lib/systemd/systemd
suckit utilise des processus cachés. Essaye un truc genre
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
qui devrait ne pas afficher d'erreurs
équivalent genre unhide.
François Boisson
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh
J'ai donc exécuté la commande suivante :
find /proc/ -regex '/proc/[0-9]*/cmdline' 2>/dev/null | sed
'1,$s|^/proc/([0-9]*)/cmdline$|ps -p 1|g' | sh
et j'ai 3 lignes
PID TTY TIME CMD
qui se suivent !
J'ai donc exécuté la commande suivante :
find /proc/ -regex '/proc/[0-9]*/cmdline' 2>/dev/null | sed
'1,$s|^/proc/([0-9]*)/cmdline$|ps -p 1|g' | sh
et j'ai 3 lignes
PID TTY TIME CMD
qui se suivent !
J'ai donc exécuté la commande suivante :
find /proc/ -regex '/proc/[0-9]*/cmdline' 2>/dev/null | sed
'1,$s|^/proc/([0-9]*)/cmdline$|ps -p 1|g' | sh
et j'ai 3 lignes
PID TTY TIME CMD
qui se suivent !
[⦠find /proc | sed | sh â¦]
Et c'est curieux, alors que je cherchais à trouver les PID,
elles ont finis par disparaître...
Serions-nous à ce point surveillé :)
[⦠find /proc | sed | sh â¦]
Et c'est curieux, alors que je cherchais à trouver les PID,
elles ont finis par disparaître...
Serions-nous à ce point surveillé :)
[⦠find /proc | sed | sh â¦]
Et c'est curieux, alors que je cherchais à trouver les PID,
elles ont finis par disparaître...
Serions-nous à ce point surveillé :)
Le jeudi 18 septembre 2014, 16:06:28 Serge SMEESTERS a écrit :
>[… find /proc | sed | sh …]
> Et c'est curieux, alors que je cherchais à trouver les PID,
> elles ont finis par disparaître...
> Serions-nous à ce point surveillé :)
Ce qui serait bien avant d’exécuter (et d’« optimiser ») une
commande donnée, ce serait d’essayer de la comprendre et, aussi,
d’en comprendre les limites.
Techniquement, la commande de François (qui doit être exécutée
depuis /proc) :
— liste tous les fichiers cmdline (for + ls) ;
— récupère le pid et crée une commande ps avec celui-ci (sed) ;
— exécute ces commandes.
Déjà, effectivement, le seq n’est pas des plus rapides (c’est
même très très lent un seq). Le find est sans doute un peu
mieux. Un simple
cd /proc && ls -d [0-9]*
donne directement la liste des pids des processus en cours, sans
la lenteur d’un seq (ou d’un find).
D’ailleurs, on peut éviter le sed et le sh final :
cd /proc && ls -d [0-9]* | while read i; ps -p $i >/dev/null
|| echo $i ; done
Le jeudi 18 septembre 2014, 16:06:28 Serge SMEESTERS a écrit :
>[… find /proc | sed | sh …]
> Et c'est curieux, alors que je cherchais à trouver les PID,
> elles ont finis par disparaître...
> Serions-nous à ce point surveillé :)
Ce qui serait bien avant d’exécuter (et d’« optimiser ») une
commande donnée, ce serait d’essayer de la comprendre et, aussi,
d’en comprendre les limites.
Techniquement, la commande de François (qui doit être exécutée
depuis /proc) :
— liste tous les fichiers cmdline (for + ls) ;
— récupère le pid et crée une commande ps avec celui-ci (sed) ;
— exécute ces commandes.
Déjà, effectivement, le seq n’est pas des plus rapides (c’est
même très très lent un seq). Le find est sans doute un peu
mieux. Un simple
cd /proc && ls -d [0-9]*
donne directement la liste des pids des processus en cours, sans
la lenteur d’un seq (ou d’un find).
D’ailleurs, on peut éviter le sed et le sh final :
cd /proc && ls -d [0-9]* | while read i; ps -p $i >/dev/null
|| echo $i ; done
Le jeudi 18 septembre 2014, 16:06:28 Serge SMEESTERS a écrit :
>[… find /proc | sed | sh …]
> Et c'est curieux, alors que je cherchais à trouver les PID,
> elles ont finis par disparaître...
> Serions-nous à ce point surveillé :)
Ce qui serait bien avant d’exécuter (et d’« optimiser ») une
commande donnée, ce serait d’essayer de la comprendre et, aussi,
d’en comprendre les limites.
Techniquement, la commande de François (qui doit être exécutée
depuis /proc) :
— liste tous les fichiers cmdline (for + ls) ;
— récupère le pid et crée une commande ps avec celui-ci (sed) ;
— exécute ces commandes.
Déjà, effectivement, le seq n’est pas des plus rapides (c’est
même très très lent un seq). Le find est sans doute un peu
mieux. Un simple
cd /proc && ls -d [0-9]*
donne directement la liste des pids des processus en cours, sans
la lenteur d’un seq (ou d’un find).
D’ailleurs, on peut éviter le sed et le sh final :
cd /proc && ls -d [0-9]* | while read i; ps -p $i >/dev/null
|| echo $i ; done
[â¦]
En clair
ls /proc/123
donne que dalle
mais
ls /proc/123/cmdline
donne un résultat.
ps se base sur les processus apparaissant dans /proc. Donc un
processus PID tel que /proc/$PID/cmdline existe mais non
montré par ps -p $PID est caché. C'est le fonctionnement de
Suckit. Le $(seq 1 65535) est donc indispensable.
[â¦]
En regardant mieux, il existe unhide qui liste les processus
cachés.
[â¦]
En clair
ls /proc/123
donne que dalle
mais
ls /proc/123/cmdline
donne un résultat.
ps se base sur les processus apparaissant dans /proc. Donc un
processus PID tel que /proc/$PID/cmdline existe mais non
montré par ps -p $PID est caché. C'est le fonctionnement de
Suckit. Le $(seq 1 65535) est donc indispensable.
[â¦]
En regardant mieux, il existe unhide qui liste les processus
cachés.
[â¦]
En clair
ls /proc/123
donne que dalle
mais
ls /proc/123/cmdline
donne un résultat.
ps se base sur les processus apparaissant dans /proc. Donc un
processus PID tel que /proc/$PID/cmdline existe mais non
montré par ps -p $PID est caché. C'est le fonctionnement de
Suckit. Le $(seq 1 65535) est donc indispensable.
[â¦]
En regardant mieux, il existe unhide qui liste les processus
cachés.