spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hm, ich würd auch sagen, dass Zwischenablage löschen schlecht is. Kann ja sein, das man etwas wichtiges drinne hat !

moment, wenn man n programmspezifisches format benutzt, berührt das doch gar nciht, was der benutzer in der zwischenablage hat, oder lieg ich da grad falsch?

Zitat von »PCShadow«

moment, wenn man n programmspezifisches format benutzt, berührt das doch gar nciht, was der benutzer in der zwischenablage hat, oder lieg ich da grad falsch?

Nein da liegst du richtig, ich finde aber auch dass die Zwischenablage eigentlich vom User kontrolliert werden sollte und hier nicht angebracht wäre (unsauber, würde aus einigen Gründen eher in die Kategorie "Hack" fallen)

Zitat von »Helmut«

Also ich verstehe dieses Forum irgendwie nicht.
Wenn man mal Ansifunktionen, Makros, using namespace std oder irgendeinen Firlefranz benutzt wird man hier gleich gesteinigt, aber wenn jemand dem Benutzer die Zwischenablage löscht sagt kein Schwein etwas! Sowas gehört sich wirklich nicht!

Wenn du mich fragst sind das zwei verschiedene Paar Schuhe. Nur weil man manchmal eben plattformspezifische Hacks braucht um plattformspeizifische Dinge zu tun (wenn du ein Betriebssystem schreibst wirst du auch kaum ohne einen reinterpret_cast auskommen) bedeutet das noch nicht dass man generell einfach gleich alle Grundsätze für sauberes Programmieren ignorieren sollte. Anyway, auch wenn es sicher keine saubere (und auch nicht umsonst eine eher nur beiläufig erwähnte) Lösung wäre, vom Löschen der Zwischenablage war, wie PCShadow ja schon aufgezeigt hat, nie die Rede.

Zitat von »Helmut«

Benutz VirtualAllocEx()+WriteProcessMemory()+Google. Das ist sauber und effizient, auch wenn hier etwas anderes behauptet wurde.

Das seh ich nicht so. Ich hab die Variante wie einige andere auch eigentlich nur der Vollständigkeit halber erwähnt. Wer kümmert sich darum den allokierten Speicher wieder freizugeben? Außerdem erfordert dies bestimmte Zugriffsrechte über die man vor allem in Zeiten der UAC nicht notwendigerweise verfügen muss was zumindest zu nervenden UAC Dialogen führen kann. Abgesehen davon kann man darüber streiten wie effizient es ist 4KB zu allokieren nur um der anderen Anwendung eine Nachricht zu schicken. Gut, natürlich könnte man das Allokieren des Buffers auch der anderen Anwendung überlassen und diese einfach die Adresse per Message verschicken lassen. Das würde zwar einige Probleme lösen, das ganze meiner Meinung nach aber nicht wesentlich sauberer machen. Ich würde wie schon gesagt in erster Linie zu WM_COPYDATA oder Pipes/Mailslots tendieren. Letztere haben den Vorteil dass sie named Objects sind und daher die Sucherei nach dem Fenster entfällt. Und wenn es wirklich performancekritisch sein sollte würde ich shared Memory einem direkten rumschreiben in fremden Adressräumen jederzeit vorziehen...

Hi dot,
doch, PCShadow liegt da sehr wohl falsch. Man kann die Zwischenablage erst nach einem Aufruf von OpenClipboard und EmptyClipboard ändern. Als Autor eines Clipboardmanagers bin ich wohl zu Unrecht davon ausgegangen, dass das jeder weiß...
Ich finde, dass es einem Entwickler am Wichtigsten sein sollte, was am Ende dabei rauskommt. Und ein Programm mit guter Usability und schlechtem Code ist besser als umgekehrt. (was nicht heißt, dass beides nicht zusammenhängt)


Wenn man den Code von beiden Prozessen steuert ist die VirtualAlloc Variante schon sauber. Das Aufräumen schafft die C# Anwendung, und bei unterschiedlichen Rechten der Prozesse wird schon das Versenden der Nachricht fehlschlagen. Die anderen von dir erwähnten Varianten gehen natürlich auch, sind aber etwas aufwändiger zu implementieren.

Ciao

Zitat von »Helmut«

und bei unterschiedlichen Rechten der Prozesse wird schon das Versenden der Nachricht fehlschlagen.

Da wär ich mir ncith so sicher, das bei glecihen rechten WriteProcessMemory klappt, logischerweise bräuchte man Admin rechte, wenn man den Speicher eines anderen programms ändern will, auch wenn das nur mit benutzerrechten läuft. Sonst könnte man ja als hacker z.B. passwörter einfach von nem versteckten prozess aus vor dem versenden aus dem speicher eines programms wie firefox lesen, und damit wäre die UAC wesentlich weniger sinnvoll. Deren zweck ist es ja unter anderem, das Schadcode explizit bestätigte Adminrechte braucht, um irgendwas ernsthaftes anstellen zu können...

Sorry, ich glaube da muss ich dich wieder enttäuschen. Ein Programm, das ohne Adminrechten läuft, kann sehr wohl Firefox ausspähen. Es kann sogar den kompletten Benutzerordner löschen und wenn man unter Win7 nicht den UAC Regler ganz hoch geregelt hat, kann es auch mit ein paar kleinen Tricks Adminprogramme ausführen, ohne eine Elevation zu zeigen.

Was sich die MS Leute dabei gedacht haben, frage ich mich auch. Jedenfalls ist das alles so by Design. Sobald Schadcode ausgeführt wird, gibt MS für garnichts mehr Garantie.

Ciao

Zitat von »Helmut«

Hi dot,
doch, PCShadow liegt da sehr wohl falsch. Man kann die Zwischenablage erst nach einem Aufruf von OpenClipboard und EmptyClipboard ändern.

Ok, da hast du recht, das habe ich in der MSDN dann doch glatt überlesen. Ich muss auch zugeben dass ich das Clipboard noch nie für andere Zwecke als einfachen Copy&Paste Support benutzt habe. Allerdings möchte ich drauf hinweisen dass ich das Clipboard auch nicht wirklich als Lösung empfohlen habe (einfach weil es für sowas natürlich keine gute Lösung ist, der Grund warum ich es überhaupt erwähnt habe war dass es in dem von mir verlinkten MSDN Artikel genannt wurde. Zugegebenerweise tat ich das in dem Fall ohne mir wirklich Gedanken darüber zu machen).

Zitat von »Helmut«

Ich finde, dass es einem Entwickler am Wichtigsten sein sollte, was am Ende dabei rauskommt. Und ein Programm mit guter Usability und schlechtem Code ist besser als umgekehrt. (was nicht heißt, dass beides nicht zusammenhängt)

Natürlich ist Usability für den Benutzer erstmal das wichtigste, allerdings schließt die sauberen Code nicht aus, im Gegenteil, wie du auch schon gesagt hast. Und für mich als Entwickler ist sauberer Code einer der wichtigsten Punkte auf der Liste überhaupt. Denn unsauberer Code wird in der Regel buggy und schlecht wart- und erweiterbar sein, was ultimativ dann auch wieder zu ner schlechteren Software führt, sollte sie anfangs auch noch so usable sein...

Zitat von »Helmut«

Wenn man den Code von beiden Prozessen steuert ist die VirtualAlloc Variante schon sauber. Das Aufräumen schafft die C# Anwendung, und bei unterschiedlichen Rechten der Prozesse wird schon das Versenden der Nachricht fehlschlagen. Die anderen von dir erwähnten Varianten gehen natürlich auch, sind aber etwas aufwändiger zu implementieren.

Ich würde sagen wenn er schon Messageloops etc. hat ist WM_COPYDATA bei weitem einfacher als alles andere. Bei WriteProcessMemory() oder shared Memory müsste er sich selbst erst einen Mechanismus bauen der dafür sorgt dass die Prozesse über eingetroffene Nachrichten informiert werden etc. Was die Rechte angeht: Stimmt die UIPI wird die Nachrichten wegschmeißen, damit hätten also sowohl WriteProcessMemory() als auch WM_COPYDATA Probleme die mit Pipes/Mailslots/Sockets und shared Memory nicht auftreten.
Abgesehen davon sollte man bedenken (was ich um ehrlich zu sein auch schon fast vergessen habe) dass es sich um C# handelt, d.h. um das alles überhaupt zu verwenden wird er PInvokes und Marshalling brauchen, deswegen wären Pipes oder Sockets evtl. weniger Aufwand da er dazu auf das .NET Framework zurückgreifen kann. Außerdem würde dabei (und bei shared Memory) die windige Prozessidentifikation über Fenstertitel entfallen.


@Helmut btw: Nettes Tool was du da hast. Rein aus Interesse (ohne jetzt google bemüht zu haben), wie genau funktionieren diese Gadets eigentlich? Sind das COM Objekte?

Na dann sind wir uns doch einig

Gadgets basieren leider komplett auf Javascript. Um auf nativen Code zugreifen zu können erstelle ich da in JS ein ActiveX Objekt, um auf die Registry zugreifen zu können. Dort wiederum registriere ich per Hand ein managed COM Object, welches wiederum ein Wrapper auf meine native DLL darstellt. In C++ kann ich dann das Fenster des Gadgets suchen und hooken... Kommt einem vor, als würde man nen Exploit schreiben, ist bei Gadgets aber Gang und Gebe..

Ciao

Zitat von »Helmut«

Na dann sind wir uns doch einig

Naja, ich fände eine Lösung über shared Memory immer noch sauberer als diesen WriteProcessMemory() Hack
Abgesehen davon würd ich hier aber sowieso zu Pipes raten da mir das für das konkrete Problem am geeignetsten scheint.

Zitat von »Helmut«

Gadgets basieren leider komplett auf Javascript. Um auf nativen Code zugreifen zu können erstelle ich da in JS ein ActiveX Objekt, um auf die Registry zugreifen zu können. Dort wiederum registriere ich per Hand ein managed COM Object, welches wiederum ein Wrapper auf meine native DLL darstellt. In C++ kann ich dann das Fenster des Gadgets suchen und hooken... Kommt einem vor, als würde man nen Exploit schreiben, ist bei Gadgets aber Gang und Gebe..

WTF?
Jo, das liest sich wirklich wie ein Exploit xD