AVERTISSEMENT
Ceci est un RAT bogué, pas terminé, pas stable. C'est encore une application "en cours de développement".
Introduction
Projet créé pour tuer un peu de mon temps libre, il n'est pas activement maintenu.
Il y a beaucoup de choses à améliorer/corriger, et il faudra du temps pour atteindre une stabilité sur ce projet.
Fonctionnalités
- Shell inversé
- Lister les processus
- Streaming du bureau
- Système de fichiers
- Télécharger un fichier
Comprendre le projet
Les IThreadChannels sont des moyens de faire communiquer deux threads de manière synchrone.
Je les utilise comme l'objet atomique partagé par deux threads pour la communication, dans cette application
je veux une communication bidirectionnelle donc j'ai besoin de deux canaux, c'est pourquoi j'ai créé l'IDoubleThreadChannel.
Synchrone signifie qu'ils doivent être appelés par les threads communicants pour recevoir les événements si nécessaire.
Exemple, le thread de l'interface utilisateur appellera getFromApp() et se bloquera là pour recevoir les événements de l'application.
Les communicateurs, en revanche, gèrent leur propre threading et déclenchent des rappels de manière asynchrone.
Vous ne les appelez pas, ils vous appellent.
Directives
- Les objets Packet doivent être supprimés par NetServerService
- Les pointeurs Client doivent être supprimés par Application.
Macros
- SHOW_CONSOLE Si une console doit être affichée à des fins de débogage.
- MANUAL_MEMORY_MANAGEMENT Si vrai, j'essaie de gérer la mémoire que j'alloue (pour apprendre), si faux, alors
j'utiliserai shared_ptr à la place pour rendre la gestion de la mémoire beaucoup plus facile.
À FAIRE
- La fonctionnalité de streaming du bureau n'est pas terminée (sortir de la boucle infinie).
- Se débarrasser des erreurs, surtout des problèmes de conversion.
- L'en-tête du paquet doit envoyer 8 octets pour la longueur du paquet, pas int32_t, donc le changer en uint64_t.
- Utiliser des verrous de lecture/écriture https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-acquiresrwlockexclusive
- Le champ dataLength dans la classe Buffer est incorrect, doit être amélioré.
- Le problème des objets Event ayant un void* qui ne devrait pas être supprimé via delete void*
peut être résolu soit comme je l'ai fait, le consommateur de l'événement prend en charge le cast vers la valeur attendue
et le supprime, soit en utilisant des templates de classe comme new AppEvent puis delete object*.
- La classe Buffer devrait lever des exceptions pour les opérations illégales.
- Chiffrement
- Streaming de la caméra
- Gestion des erreurs ... partout.