Screenshot verhindern

[Olli]

Der Normaluser nimmt UltraVNC mit einer Loopback-Verbindung und macht fröhlich Screenshots.

Vergiß es doch einfach. Es ist unsinnig, es ist nicht machbar, warum diskutiert ihr noch?

Wenn wir irgendwann mal ein "DRM-System" auf Pro-Fenster-Basis bekommen, können wir ja weiterdiskutieren ...

[Phoenix]

Zitat von Olli:

Vergiß es doch einfach. Es ist unsinnig, es ist nicht machbar, warum diskutiert ihr noch?

Ich hätte zu dem 'nicht machbar' bitte den mathematischen Beweis.

Ich bin eher der Meinung das es machbar sein müsste, aber nur mit erheblichem Aufwand. Du müsstest einen Treiber schreiben der die Ausgabe auf dem Bildschirm selber übernimmt und mit Deiner Software ausschliesslich diesen Treiber ansteuern. Da dann Dein Treiber direkt den physikalischen Output erzeugt kann das nicht so einfach mit Hausmitteln gegrabbt werden. Der Treiber kann auch so geschrieben sein dass er seinen Dienst in einer VM versagt. Damit hast Du ein Hemmnis das der Normaluser nicht mit 'Ich suche mit Google einen Screengrabber, lade den Runter und verwende den' umgehen kann. Allerdings ist Dein Aufwand auch entsprechend hoch - fraglich ob sich das lohnt, aber durchaus machbar.

[turboPASCAL]

Alles was auf dem Bildschirm dargestellt wird kann man "Grappen". (Und wenn ich dazu nen' Fotoapperat auspacken muss)

Fine.

[Olli]

Zitat von Phoenix:

Ich bin eher der Meinung das es machbar sein müsste,

Es dürfte auch machbar sein, daß du rein zufällig von mehreren herunterstürzenden Balkonen getroffen wirst, wenn du auf die Straße gehst. Geh mal lieber nicht auf die Straße.

Zitat von Phoenix:

aber nur mit erheblichem Aufwand. Du müsstest einen Treiber schreiben der die Ausgabe auf dem Bildschirm selber übernimmt und mit Deiner Software ausschliesslich diesen Treiber ansteuern.

Und nebenbei müßte man den Kernel on-the-fly umprogrammieren, damit der das mitmacht. Und dann müßte man noch rein zufällig eine Menge Funktionsprototypen ermitteln, die bisher niemandem außerhalb von MS bekannt sind. Abgesehen davon wäre der Spaß schonmal nicht mehr unabhängig von der Hardware, würde den TS-Support kippen und nebenbei noch die Kompatibilität zu allerhand Software wegwerfen.
So gesehen, ja, es ist rein prinzipiell möglich.

Zitat von Phoenix:

Da dann Dein Treiber direkt den physikalischen Output erzeugt kann das nicht so einfach mit Hausmitteln gegrabbt werden. Der Treiber kann auch so geschrieben sein dass er seinen Dienst in einer VM versagt.

Wie willst du das denn tun? Du kannst nicht herausfinden ob du in einer VM bist! Nur bei aktuellen Versionen von VPC und VMWare geht dies (aber auch nur, weil diese Software eben jede Menge Opcodes nativ ausführt und deshalb bestimmte Sonderbedingungen innerhalb der VM gelten). Echte Emulatoren sind auch VMs und bei denen wirst du es einfach nicht hinbekommen das zu detektieren.

Zitat von Phoenix:

Damit hast Du ein Hemmnis das der Normaluser nicht mit 'Ich suche mit Google einen Screengrabber, lade den Runter und verwende den' umgehen kann. Allerdings ist Dein Aufwand auch entsprechend hoch - fraglich ob sich das lohnt, aber durchaus machbar.

Also unter "durchaus machbar" würde das bei mir nicht mehr laufen. Wenn ein Lottogewinn mit 6 Richtigen bei einem Jackpot von 50 Mio EUR als einziger Gewinner für dich machbar ist, dann dürfte dein Vorschlag sowas wie der Lottogewinn eines Lottogewinn eines Lottogewinns sein.

Abgesehen von allem Gesagten ist es müßig darüber zu diskutieren ob es überhaupt geht, denn in diesem Forum reden wir über Delphiprogramme im Usermode und höchstwahrscheinlich sogar festgelegt auf das Win32-Subsystem. Und sorry, in dieser Umgebung geht es nunmal nicht das zu verhindern.

[Tubos]

Zitat:

Du kannst nicht herausfinden ob du in einer VM bist!

Wenn ich ein OS in VMWare laufen lasse, dann heißt die Festplatte beispielsweise: "VMWare ...". Anhand dessen müsste es schon möglich sein, das zu erkennen.

[Olli]

Zitat von Tubos:

Zitat:

Du kannst nicht herausfinden ob du in einer VM bist!

Wenn ich ein OS in VMWare laufen lasse, dann heißt die Festplatte beispielsweise: "VMWare ...". Anhand dessen müsste es schon möglich sein, das zu erkennen.

Aua, bei soviel "Bauernschläue" weiß ich wirklich nichts mehr zu entgegnen ... ... als ob man dies nicht ändern könnte ...

[Christian Seehase]

Moin Olli,

ein spezieller Treiber müsste sich doch auch durch einen dazwischengeschalteten Filtertreiber aushebeln lassen der die Ausgabe dann grabbt

[Olli]

Moin Christian,

Zitat von Christian Seehase:

ein spezieller Treiber müsste sich doch auch durch einen dazwischengeschalteten Filtertreiber aushebeln lassen der die Ausgabe dann grabbt

Dokumentiert ist das nur für den Fall wo der zu filternde Treiber ein DeviceObject hat. Wenn dies nicht der Fall ist, gibt es IMO keinen dokumentierten Weg sich an den Treiber zu heften. Wenn ich den nur noch nicht kenne, dann bin ich gespannt auf eine aufklärende Antwort deinerseits

Bei dem vorgeschlagenen Treiber dürfte das aber sowieso müßig sein, weil so ein Treiber gegen so ziemlich alles verstößt, was in der Treiberentwicklung Usus ist. So ein Treiber würde nämlich quasi "ein Flickenteppich aus schmutzigen Tricks" sein
Für die Entwicklung eines stabilen Prototypen "from scratch" würde ich mal mindestens 5 Mannjahre veranschlagen. Allein zum Filtern der ganzen win32k.sys-Funktionen

[jim_raynor]

Man man man. Die Grafiken müssen ja wirklich höchst Geheim sein. Wenn ich die wirklich haben will dann bekomme ich die auch. Und wenn ich einen Debugger einschalte und mir die Bilddaten direkt aus dem Speicher holen möchte ...

Wozu der Aufwand? Nur Teile des Bildes anzeigen lassen und so schnell, dass es das Auge nicht wahrnimmt? Dann musst du schon extrem hohe Framerate erreichen, die kein Monitor darstellen kann. Bei einem stehenden Bild fällt selbst bei 60 Bildern pro Sekunde noch ein Flimmern auf. Da das Bild in mehere Teile aufteilen müsstest, müsstest du pro Bildteil die 60 Frames einrechnen. Bei 4 Teilen wären es also schon 240 Frames pro Sekunde. Und bei vier Teilen sollte es unproblematisch sein, sich das Bild selbst zusammen bauen ...


Einen Treiber ins System einhängen? Wenn das jede Software macht dann schönen dank. Zu dem du auch dann noch die Daten aus dem Speicher holen kannst.

Was du brauchst lässt sich NUR mit dem geforderten Schutz aus Hollywood von HDTV erreichen. Jeder Hardware- und Software-Kanal vom Eingabegerät bis hin zum Ausgabegerät muss verschlüsselt sein. Ansonsten findest du immer einen Angriffspunkt. Ach ja zum Thema abfilmen. Auch hier ist man dran, dass durch bestimmte Störsignale vom Ausgabegerät ein Abfilmen erschwert werden soll. (Fangt jetzt bloß keine Diskussion über HDTV und HDCP und ... an).

Denk mal drüber nach, ob sich der Aufwand und die Einschränkung für den Nutzer lohnen ...