Remote Controll - Realisierung über C#?

Hallo Community,

ich wurde von meiner Firma vor ein neues Projekt gestellt, was mir persönlich ein paar Fragen aufwirft. Ich hoffe ihr könnt mir helfen, bin für jede Hilfe dankbar 🙂

Zum Projekt:
Es ist geplant in unsere Software eine RemoteControll ala Windows XP Remote Desktop einzubauen. Da wir ziemlich zukunftsorientiert programmieren möchten wäre es naheliegend eine .Net Programmiersprache (mein Favourit C#) zu verwenden. Dieses RemoteAddin soll über FileTransfer, Screen-Streaming zum Admin, Remote Maus- und Tastatursteuerung, sowie einen Chat mit dem Anwender am Zielhost verfügen. Soviel zu den Minimalanforderungen. Das Programm muss im Hintergrund, vollkommen unsichtbar und nicht deaktivierbar für den Anwender ablaufen, man möchte ihn ja nicht überfordern/verunsichern/zum ausprobieren ermutigen.

Fragen:
Ist es möglich dies in C# zu entwickeln?
Ist es sinnvoll oder wäre dann doch C++ oder Delphi geeigneter?
Gäbe es Hindernisse wie eingeschränkte Funktionalität unter nicht Admin-accounts?

Im Prinzip kannst du große Teile davon in C# implementieren, doch das Capturing/Streaming des Screens werdet ihr wohl Teilweise in C++ implementieren müssen, da du eine Art Device-Driver schreiben musst, der den Grafikdatenstrom abfängt und mit kopiert und vor allem reduziert. Da dies an die Windows interna geht, bleibt dir hier nicht viel anders übrig!

Mit der Maus ist das wohl leichter, da du die Positionierung über P/Invoke durchführen kannst. Mit der Tastatur ist das ähnlich: System.Windows.Forms.Sendkeys() oder über P/Invoke

Eine Frage stellt sich mir hier aber doch... ich nehme an, dass ihr keine XP Rechner habt, weil sich so eine Frage mir sich sonst nicht erschließen würde und verweise dich hier mal auf RealVNC. Das ist ein Tool, dass im Prinzip die Funktionalität von RemoteDesktop implementiert und unter verschidenen OS-Systemen läuft.

Allerdings finde ich, dass es ein sehr ergeiziges Projekt ist und wäre gespannt wie ihr euch entscheidet und es löst und implementiert!

Gruß, CyberSAP

Erstmal vielen Dank für deine schnelle und vor allem professionelle Hilfe, sie hat mich meiner Entscheidung ein Stück näher gebracht. Würdest du prinzipiell sagen dass es sinnvoll ist diese Software in .NET zu realisieren?

Es soll eigentlich für jedes Windows OS ausgelegt sein, ala Symantec PC Anywhere. RealVNC war auch mein erster Gedanke, aber der Kunde möchte dieses "Remote Controll Center" komplett in seine Softwaresuite integriert haben.
Der Projektleiter meinte es seie ja angeblich nicht schwer zu realisieren da bereits seiner Aussage nach "minderintelligente" Jugendliche in der Lage wären einen Trojaner zu schreiben, was ja im eigentlichen Sinne ja auf einer erweiterten/spezialiserten RemoteControll basiert. Mit der Basis gebe ich ihm auch Recht, bloß bei der Realisierung bin ich mir da noch ziemlich unschlüßig, zum Glück ließ er mir die Realiserung und Implementierung zur freien Wahl.

Meine persönliche Lösung wäre auch VNC, RDP oder PC Anywhere gewesen, aber Kundenwunsch ist ja bekanntlich Kundenwunsch und Chefewünscht sich natürlich auch mehr zu fakturieren als nur eine Softwarevermittlung. Das mit dem DeviceTreiber wird ja anscheinend dann schon ne größere Sache. Ich dachte durch die Wahl von C# könnte ich es plattformunabhängig (auf jedenfall im Winbereich) halten und mithilfe bereits definierter Klassen wie deine Beispiele System.Windows.Forms.Sendkeys() oder über P/Invoke lösen, Filetransfer der XML, SOAP Kommunikation ist ja in C# auch einfach realisierbar. Ich erinnere mich ich hätte mal einen Quellcode für irgendeinen Win98 Admin Remote Controll gesehen, da wurde bereits alles gelöst, bis auf das ScreenCapturing/Screening. Diese Lösung basierte aber auf C++ wenn ich mich nicht recht insinne und funktionierte eben nur zugeschnitten auf Windows 98. Eine unschöne Massnahme des Screencapturing wäre ja das sekundenhafte Screenshot erstellen, jpg komprimieren und über einen xmldatenstrom in binärcode des screens oder direkte Kommunikation übers netzwerk.

Ich habe gerade mal ein bisschen gegoogelt und kam zu folgendem genialgeilem Ergebnis -> [link]

Ich denke das bietet dir schon mal einen guten Ansatz. In wie weit der Code auch unter Win9x läuft weiß ich nicht. Da müsste man mal die Win98 APIs konsultieren, die denke ich im Archiv der MSDN-Library vorhanden sein müssten. Ansonsten anpassen und mit nem Wrapper arbeiten bzw. Interfaces ... ach das weißt du bestimmt eh genauso gut...

Auf der Capturing-Seite müsste man dann bei jedem Capturing-Vorgang das vorherige Bild zwischenspeichern - vor dem senden mit dem neuen capture vergleichen und den geänderten Bereich großzügig ausschneiden und als Änderung übermitteln - für max performance halt. Gelegentlich alle 10 oder 20 Udates sollte man dann eine volles Capture schicken. Müsste man mal ausprobieren wie viele Captures pro Sekunde erträglich sind. 🙂 Leider kenne ich mich mit Bildvergleichsroutinen nicht so gut aus, da müsstes du mal schauen. Eine Reduzierung der Bilddaten auf 256bit Farbtiefe sollte für eine solche Anwendung reichen. Ob man die Daten dann noch mit z.b. Zip [für .NET 1.x -> link] reduziert müsste man mal wegen der Performance austesten.

Ich hoffe das hilft dir weiter! .NET Rulez! 🙂

Gruß, CyberSAP

Hallo zusammen,

was den Screencapture anbelangt denke ich, dass "normale" Remoting-Tools nicht auf Bitmap-/Bildvergleichsbasis arbeiten, sondern den GDI-Datenstrom (wnter UNIX resprektive den X-Datenstrom) an den entfernten Rechner senden. Dabei macht wohl "nur" die Übertragung von Spielen und Kommandozeilenfenstern Probleme. Diese werden über das von Euch beschriebene Verfahren übertragen.

Soweit ich weiß, biete zumindest neuere Windowse OS-seitig Unterstützung für Desktop-Remoting.

Trotzdem halte ich das auch für ein sehr engaiertes Projekt. Ich würde einen großzügigen Sicherheitspuffer einplanen, denn ich denke, selbst wenn die Basis steht, dauert es bestimmt noch richtig lange, bis so ein Programm rund läuft. Da wird es eine Masse Details geben, die man gesondert behandeln muss.

herbivore

Original von Azrael Masters
Der Projektleiter meinte es seie ja angeblich nicht schwer zu realisieren da bereits seiner Aussage nach "minderintelligente" Jugendliche in der Lage wären einen Trojaner zu schreiben, was ja im eigentlichen Sinne ja auf einer erweiterten/spezialiserten RemoteControll basiert.

Zitat aus Dilbert
Chef:
"Ich gehe davon aus, das alles was ich nicht verstehe leicht zu implementieren ist.
Bauen Sie eine Client-Server Applikation die alle Datenbanken unseres Unternehmens vernetzt. Zeit: 6 Minuten."

Mein erster Gedanke:
Dein Projektleiter ist ne Pappnase, Betriebswirt oder beides. In allen Fällen hat er dem Kunden schon erzählt das es in 4 Wochen fertig ist.
Hätte ich ihn in einer Planungssitzung sowas sagen hören, dann wäre er schon mal derjenige erste, dessen Meinung mir total am Arsch vorbeigeht. Sprich selbst ohne deinen Leiter mit dem Kunden. Ich denke, der will es etwas anderes als dein Projektleiter verstanden hat.......

Also das Ding soll:

• plattformübergreifend
• eventuell für den User unsichtbar
• einen Desktop simulieren
• als Service
• Wahrscheinlich übers Internet funktionieren (Firewalls?)
• Volle Kontrolle geben
• in ein bestehendes Projekt eingebunden werden.

Fragen dazu:

• definiere Plattformübergriefend.
  Wie Plattformübergreifend ist denn die Applikation in die das eingepflegt werden soll?
  Das ist dann der Level, an den es passen muss. Alles andere ist Blödsinn. Windows-OS ist ziemlich wage in der Aussage. Dazu gehört 95, 98, ME, MT4, 2000, XP, 2003, und alle nebst alles Service-Packs. Irgendwo sollte man da Grenzen ziehen....

• für den User unsichtbar: Heisst das, ich kann mit dem Rechner zur gleichen Zeit arbeiten, während der User das auch tut?
  Dazu müsstest du dann den Desktop nachbauen, da es ansonsten nicht geht.
  Das ist aber zusätzlich zu dem Capturing, wo du was mit dem User zusammen machen kannst (was er sieht).

• Service:
  Mit welchen Rechten muss das laufen? Zugriff als Admin übers Netz ist immer ein Sicherheitsrisiko!

• Internet:
  Weiss nicht genau wie das bei Remoting ist, aber ich gehe von einem ziemlichen Overhead aus. Also TCP/IP bzw. UDP. WElche Problem sind mit Netzwerkadmis zu erwarten? Wenn das Ding hinter einem Router hängt und mehr als ein Rechner ist, muss sich der Client an den Server verbinden, weil es ansonsnten nicht durch die NAT geht. Wie soll das geschehen? In diesem Fall muss der Client dch eingreifen, oder ihr müsst einen Client als Zwischenserver konfigurieren der das Management im LAN des Clients übernimmt.
  Welche Verschlüsselung (Sicherheit!), was für ein Datenprotokoll? Gibts da schon eines, oder musst du selbst entwicklen? Wie gross sind die Dateien die übertragen werden sollen?

• Volle Kontrolle:
  Und unsichtbar. Übers Netz. SEHR übel. Da musst du schon eine hohe Sicherheit einbauen, was natürlich auch heisst das ihr das richtig gegen Eindringlinge testen müsst!! Das wird ne Fleissaufgabe, und ziemlich knifflig.....

• In ein Projekt einbinden:
  Was für ein Projekt? Eure Entwicklung? Wenn nein, gibt es Sourcen, Doku, Unterstützung?

Zusammengefasst würde ich sagen: VNC ist für den Kunden die billigere Wahl. Weil ich den Entwicklungs und Testaufwand ziemlich hoch ansetze.
Ich gehe mal von einem 2-Mann-Team aus:
Für grobe Planung und Konzeption denke ich 1 Woche.
Verbindung mit Verschlüsselung, Backend, Client und Serverseite zusammen schätze ich bei ca. 3 Wochen.
Den Rest dann noch mal ca. 2 Wochen, mit Oberfläche, Userverwaltung, Schlüsselverwaltung (wie macht ihr das?).
Restarbeiten an der Oberfläche: 2 Wochen.
Optimierung: 4 Wochen.
Ausgiebiges Testen und debuggen auf verschiedenen Rechnern: 2 Wochen.

Macht 12 Wochen, mal den üblichen Faktor 2:
24 Wochen. Das ist einigermassen realistisch. Wobei mir das doch sehr gering vorkommt..... ich denke, eher noch mehr, aber das kann man erst sagen wenn man alle Rahmenbedingungen kennt.

Und dann will der Kunde bestimmt noch Änderungen haben......

Original von Azrael Masters
Der Projektleiter meinte es seie ja angeblich nicht schwer zu realisieren da bereits seiner Aussage nach "minderintelligente" Jugendliche in der Lage wären einen Trojaner zu schreiben, was ja im eigentlichen Sinne ja auf einer erweiterten/spezialiserten RemoteControll basiert.

Austeigen! Firma wechseln! 🙂

So ein Projekt überhaupt zu beauftragen ist Harakiri. Die Kosten werden nicht unter 100.000€ liegen. Wie ist das wirtschaftlich zu vertreten, wenn es gute Lösungen am Markt gibt. Hier sieht es so aus, als hätten BWLer Anforderungen definiert und festgezurrt ohne ein Gefühl für die dahinterstehenden Aufwände zu haben.

Geiles Schleudersitz-Projekt.... mein Beileid 😉

noch einmal zur umsetzung...

VNC ist meines wissens Open-source, und es ist vor allem in Java - also solltest du dir dort alle notwendigen anregungen holen können.

grüsse
cord

Last but not Least dürfe das UNSICHTBAR auch noch einen Konflikt mit dem Gesetz auslösen.....

Je nach Land ist es sehr problematisch einen User ohne dessen Wissen zu überwachen.... und daraufhin läufts ja hinaus

Uebrigens ULTRAVNC ist noch schneller als die anderen VNC-Varianten...

--> Projektleiter auf den Mond kicken oder Firma wechseln

Original von Programmierhans
Uebrigens ULTRAVNC ist noch schneller als die anderen VNC-Varianten...

NOCH schneller? Das Teil ist im Vergleich zur MS-Lösung grottenlahm! Gefühlte Performance ist bei VNC um 2-3 niedriger als das Desktop Remoting von Windows-Server.

Zugegegebenermaßen ist aber VNC die einzige Freeware-Lösung die plattformübergreifend geht und auch mit dem Standard-Windows arbeitet, also für Endnutzer-Clients geeignet ist.

Aber dann gibts ja PCAnywhere & Co., allerdings nicht kostenfrei.

VNC und dessen Derivate sind aus meiner Sicht die einzig brauchbaren Teile....

Nur diese sind Plattformübergreifend und laufen auch z.B: im Browser (sogar unter BEOS)

Jegliche Möglichkeit der Arbeitsplatzüberwachung ist übrigens tatsächlich seitens des Betriebsrates einer Firma zustimmungspflichtig. Bei uns darf der IT-Service nur auf den Arbeitsplatz zugreifen, wenn zuvor auf dem Rechner eine Dialog-Box erscheint, welche die Fernwartung ankündigt. Diese muss dann vom Nutzer bestätigt werden. Erst dann kann zugegriffen werden.

Ich hatte mal ein ähnliches Projekt, da wurde eine ähnliche Lösung beauftragt und erst mittem im Projekt kam auf einmal der Betriebsrat an und verlangte die Entfernung der Funktion. Gut für uns, weil es trotzdem bezahlt werden musste. 🙂

Hmmm....

wenn ich mir die oben gestellten Fragen noch mal anschaue, ist hier nicht nach einer Grundsatzdiskussion gefragt, sondern mehr die Frage der "technischen Natur der Umsetzung". Hat hier jemand etwas dazu konstruktives beizutragen? Mich würde das nämlich auch interessieren!

Gruß, CyberSAP

OK, mal nen technischen Vorschlag, nur bezüglich der Bildschirmübertragungen. Nihct fundiert, nur ein paar Ideen wie es ressourcenschonend gehen könnte.

Wie das Bild zu bekommen ist, habe ich keine Ahnung. Grafikbuffer auslesen, etc. irgendwie so.

1.) Bild nur in 256 Farben, und angepasste Map der benutzten Farben um einen brauchbaren Kompromiss zwischen Aussehen und Performance zu haben.

2.) Bild in einzelne Kacheln unterteilen. Kacheln nebst Hashwert zwichenspeichern.

3.) Wenn Hash einer neueren Kachel anders ist, Diff der alten und neuen Kachel erstellen und diesen (gepackt?) übertragen.

4.) Der Mauszeiger muss immer rausgerechnet werden, und seperat an Hand der Position die er hat übertragen werden.

5.) Ich würde die Verbindungsherstellung über TCP/IP machen, und die Daten über UDP rausblasen. Remoting würde ich nicht machen. Wer weiss auf welchem System dsa funktioniert oder nicht.

Grösse der Kacheln kann man in Experimenten herausbekommen, eventuell muss man die dynamisch ändern.

Das Berechnen sollte man besser in C++ oder unmanaged machen, da es mit Pointern direkt auf die Pixel erheblich schneller geht. Zur Bildmanipulation selbst gibts was bei Codeproject.

Für alles andere muss der Threadstarter erstmal Infos und Bedingungen nachliefern, da man da sonst nichts weiter sagen kann.

Warum nicht einfach VNC ausschlachten? Würde ich machen....

@svenson:
Darfst du bloss nicht, weil GPL.

@Efftee

Das mit den Kacheln und den Hashes finde ich ne gute Idee! Die Berechnung denke ich ist in managed code auch ausreichend schnell genug!

Nice!

Gruß, CyberSAP

@CyberSAP
Ne, ist nicht schnell genug 🙂
Ich habs selbst ausprobiert, und der Zugriff über GetPixel/SetPixel ist schnarchlahmarschig.
Aber sooooo wild ist das auch nicht. Dann schreibt man halt "unsafe" vor der Deklaration der Berechnungsroutine, und kann wunderbar mit Pointern durchiterieren 🙂

Hier ist das ansonsten mal Image-Processing mit C# sehr ausführlich beschrieben. Absolut lesenswert!!
http://www.codeproject.com/cs/media/csharpgraphicfilters11.asp

Hallo zusammen,

normale Remoting-Tools arbeiten nicht pixel-/bitmap-orientiert, sondern schicken die GDI-Befehle zum Zeichnen über die Leitung.

herbivore

@Efftee
Hmm oder so... aber bietet einem ein Bitmap oder Image Object nicht GetHashCode()? Worauf basieren die Hashes die hier erzeugt werden? Das müsste doch gehen? Ansonsten ... haste wohl recht!

@herbivore

Original von herbivore
Hallo zusammen,

normale Remoting-Tools arbeiten nicht pixel-/bitmap-orientiert, sondern schicken die GDI-Befehle zum Zeichnen über die Leitung.

herbivore

Bitte, was?!? Und was sollen die da denn Zeichnen?

Gruß, CyberSAP

Der Hash eines jeden Objektes bezieht sich nicht auf den Inhalt, sondern nur auf das refenrenzierte Objekt! Das taugt garnicht im identifizieren.

Das mit den gdi-Befehlen ist schon nicht schlecht. Allerdings weiss ich nicht wie sich das mit Buttons und anderen Userobjekten verhält....

Wie captured man diese Befehle?

VNC arbeitet z.b. mit dem RFB (Remote Frame Buffer), und das ist definitiv pixelorientiert.
was wohl auch der hauptgrund für seine geringe geschwindigkeit ist.

grüsse

...aber auch natürlich der Grund für seine Plattformunabhängigkeit.

Man kann halt nicht alles haben.

Hallo CyberSAP,

Bitte, was?!? Und was sollen die da denn Zeichnen?

Wenn ein Fenser von Windows gezeichnet wird, werden dazu Befehle benutzt wie DrawLine, DrawRectangle u.ä. (siehe Doku zu Graphics-Klasse). Es ist nun wesentlich bandbreitenparender diese Befehle samt Parametern zu übertragen, als das Ergebnis der Zeichenbefehle als Bitmap.

Wie man die Befehl abgreifen kann, weiß ich leider nicht. Vielleicht gibt es ein (Win32?-)API dafür oder vielleicht kann reicht es auch, sich in WndProc einzuklicken.

herbivore

Du brauchst nen Kernel-Treiber....