WARNUNG

Dies ist eine fehlerhafte RAT, unvollständig, instabil. Sie ist immer noch eine "Work in Progress"-Anwendung.

Einführung

Projekt erstellt, um etwas von meiner Freizeit zu vertreiben. Es wird nicht aktiv gepflegt. Es gibt viele Dinge zu verbessern/beheben, und es wird Zeit brauchen, um bei diesem Projekt Stabilität zu erreichen.

Funktionen

• Reverse Shell
• Prozesse auflisten
• Desktop-Streaming
• Dateisystem
• Datei herunterladen

Das Projekt verstehen

IThreadChannels sind Mittel, um zwei Threads auf synchrone Weise miteinander kommunizieren zu lassen. Ich verwende sie als das atomare Objekt, das von zwei Threads zur Kommunikation geteilt wird. In dieser App möchte ich eine Zwei-Wege-Kommunikation, also brauche ich zwei Kanäle; deshalb habe ich IDoubleThreadChannel erstellt. Synchron bedeutet, dass sie von den kommunizierenden Threads aufgerufen werden müssen, um Ereignisse bei Bedarf zu empfangen. Beispiel: Der UI-Thread ruft getFromApp() auf und blockiert dort, um App-Ereignisse zu empfangen.

Communicators hingegen verwalten ihr eigenes Threading und lösen Callbacks asynchron aus. Du rufst sie nicht auf, sie rufen dich.

Richtlinien

• Packet-Objekte sollten vom NetServerService gelöscht werden.
• Client-Zeiger sollten von der Application gelöscht werden.

Makros

• SHOW_CONSOLE Ob eine Konsole zu Debug-Zwecken angezeigt werden soll.
• MANUAL_MEMORY_MANAGEMENT Wenn true, versuche ich, den von mir zugewiesenen Speicher zu verwalten (zum Lernen). Wenn false, dann verwende ich stattdessen shared_ptr, um die Speicherverwaltung erheblich zu vereinfachen.

TODOS

• Desktop-Streaming-Funktion nicht fertig (aus Endlosschleife ausbrechen).
• Fehler beseitigen, hauptsächlich Konvertierungsprobleme
• Der Paket-Header muss 8 Bytes für die Paketlänge senden, nicht int32_t, also ändere es auf uint64_t
• Read/Write-Locks verwenden https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-acquiresrwlockexclusive
• Das Feld dataLength in der Buffer-Klasse ist falsch und sollte verbessert werden
• Das Problem, dass Event-Objekte ein void* haben, das nicht über delete void* gelöscht werden sollte, kann entweder so gelöst werden, wie ich es getan habe – der Konsument des Ereignisses übernimmt das Casting auf den erwarteten Wert und das Löschen – oder mithilfe von Klassen-Templates wie new AppEvent, sodass das Löschen dann über delete object* erfolgen kann.
• Die Buffer-Klasse sollte bei unzulässigen Operationen Ausnahmen werfen.
• Verschlüsselung
• Kamera-Streaming
• Fehlerbehandlung .... überall.