Limites

Le projet couvre les fonctionnalités prévues, mais plusieurs choix restent volontairement simples.

Limites kernel

Limite	Détail
Hooks ftrace fragiles	dépendent des symboles __x64_sys_*, des options noyau et de FTRACE_OPS_FL_IPMODIFY
Hooks de lecture ciblés	filtrent surtout les chemins de persistance du projet
Hooks d'accès ciblés	protègent les chemins connus du projet, pas tous les chemins possibles du système
Masquage par nom	les règles ciblent wlkom, wlkom_data, .wlkom et artefacts connus
Unload difficile	le module masqué peut être pénible à retirer sans reboot
Helpers userland	dépend de /bin/sh, base64, tar, dd, outils screenshot

Pour comprendre les limites kernel une par une, voir ftrace, Kprobes et symboles, Mémoire userland et uaccess, Résolution de chemins kernel, Masquage du module et call_usermodehelper.

Limites réseau

Limite	Détail
IP attaquant fixe	192.168.100.1 par défaut, modifiable par paramètre
Une session active	une nouvelle connexion remplace la précédente
Pas de multiplexing	une commande à la fois sous lock backend
Pas de heartbeat applicatif	l'état se met à jour sur événements/erreurs
Crypto simple	XOR/FNV-1a, pas TLS ni intégrité

Limites transferts

Élément	Côté frontend	Côté backend/rootkit	Pourquoi
Upload	Le navigateur envoie le fichier entier au backend avec FormData.	Le backend découpe ensuite vers le rootkit: 120 KiB maximum de base64 par upload-append, soit environ 90 KiB bruts.	La limite vient du canal C2 et de /bin/sh -c, pas du formulaire HTTP.
Download fichier	Le frontend demande un fichier et affiche une progression NDJSON.	Le backend récupère le fichier par download-chunk de 256 KiB, puis renvoie le résultat au navigateur.	Le chunking protège le canal kernel. Côté navigateur, on veut surtout une action simple avec progression.
Download dossier	Le frontend demande une archive de dossier.	Le backend crée /opt/wlkom_data/.download-dir.tar.gz, puis télécharge cette archive avec les chunks fichier.	Un dossier est d'abord transformé en fichier unique, sinon le protocole download-chunk ne sait pas quoi lire.
Preview	Le frontend affiche seulement les aperçus raisonnables.	Le backend refuse l'aperçu au-dessus de 512 KiB.	L'aperçu doit rester interactif. Les gros fichiers passent par Download.
Réponse C2	Le frontend ne voit que la réponse HTTP finale ou les événements NDJSON.	Le rootkit a WLKOM_TX_SIZE=4 MiB, le backend coupe à MAX_RESPONSE_BYTES=6 MiB.	Ces limites protègent la socket C2 et la mémoire backend, pas directement l'UI.

Limites screenshot

La capture dépend de la session graphique et des outils:

gnome-screenshot
scrot
import
xwd + convert

Wayland, X11, permissions, session inactive ou absence d'outil peuvent provoquer un échec.

Limites persistance

La persistance repose sur:

/lib/modules/$(uname -r)/kernel/drivers/wlkom.ko
/etc/modules-load.d/wlkom.conf
/etc/modprobe.d/wlkom.conf

Limites:

• le mot de passe doit être dans modprobe.d pour survivre au reboot
• si le module n'est pas chargé, le hook read ne masque rien
• si le noyau change, le chemin /lib/modules/$(uname -r) change
• si depmod n'est pas exécuté, modprobe wlkom peut échouer
• inspection offline ou rescue mode voit les fichiers.

Limites du loader victime

freecloude.py est le point d'entrée victime. Il attend un noyau compatible avec le scénario d'élévation de privilèges, puis lance freecloude.sh.

freecloude.sh reste l'installateur réel et attend:

• accès HTTP à 192.168.100.1:8080
• sudo fonctionnel
• noyau compatible avec le .ko
• curl, modinfo, depmod, insmod
• mot de passe dans [A-Za-z0-9._-].

Le helper ~/install-demo-rootkit.sh peut encore lancer directement freecloude.sh comme chemin de diagnostic, mais le parcours principal passe par freecloude.py.

Points de diagnostic

Si un upload échoue, la cause probable est une commande upload-append trop grande pour le canal C2. Vérifier WLKOM_RX_SIZE, le plafond 120 KiB de base64 par chunk et la longueur du chemin distant.

Si un download dossier échoue, la cause probable est l'étape d'archive temporaire. Le backend crée d'abord /opt/wlkom_data/.download-dir.tar.gz, puis télécharge cette archive en mode chunké. Vérifier tar, l'espace disque et le download de l'archive.

Si un screenshot échoue, la cause probable est la session graphique. Vérifier qu'une session est active et qu'au moins un outil de capture est disponible: gnome-screenshot, scrot, import ou xwd + convert.

Si insmod échoue, la cause probable est une incompatibilité module/noyau ou un blocage des hooks. Comparer uname -r, modinfo -F vermagic et les derniers messages dmesg.

Si la session ne revient pas après reboot, la cause probable est soit le listener 4444 absent côté attaquant, soit la persistance qui n'a pas rechargé le module. Vérifier le dashboard, /etc/modules-load.d/wlkom.conf, /etc/modprobe.d/wlkom.conf et dmesg.

Pour les raisons techniques derrière ces limites, voir Références techniques.