Das funktioniert nicht.

[Eve666]

Egal wie man es dreht und wendet... ich habe immer den Stream und den Schlüssel, damit ich das Video(oder was auch immer) selbst angucken kann. Es gibt nach dem entschlüsseln lokal keinen Grund mehr den Stream nicht in eine Datei umzuleiten.

Allein die Überlegung DRM so umsetzen zu wollen ist Zeitverschwendung. Von daher mach ich mir auch keine Sorgen. Das gesamte Konzept ist "Broken By Design".

[dudida]

Gilt das nicht auch schon jetzt für alle Lösungen? OK, dort ist es schwieriger direkt eigenen Code auszuführen, aber der Schlüssel muss ja bei Flash- oder Silverlight Playern ja auch irgendwo im RAM liegen...



1 mal bearbeitet, zuletzt am 22.02.12 18:27 durch dudida.

[Trockenobst]

Eve666 schrieb:
--------------------------------------------------------------------------------
> Es gibt nach dem entschlüsseln lokal keinen Grund mehr den Stream nicht in
> eine Datei umzuleiten.

Dann bist Du scheinbar besser als alle Leute die sich am DRM von Silverlight
ihre Finger verknoten. Die vieler Linuxer, die alle den DRM-Teil von Silverlight
nicht im Mono "finden", würden auch gerne von deiner "Lösung" hören.

Hier werden keine fertige Streams übertragen. Da sind z.T. ziemlich komplexe
"Zerhacker" für Ton und Bild am Werk. Und die werden dynamisch mit dem Player
hoch geladen. D.h. für jeden *einzelnen* Film wird man erst mal den Player und
den "Zerhacker" durch debuggen, um dann potentiell mit einer eigenen
"Entschlüsselungsroutine" zu kommen. Viel Aufwand den wohl das Netz bisher
scheut.

Das einzige was aktuell hilft, ist eine externe Lösung (die das Aufnehmen per
Design erlaubt) oder eine Screenaufnahme - die aber u.U. eine sehr teure
Maschine und entsprechende Spezialtools verlangt. Und dann macht man
ja ein Re-Encoding eines bereits enkodierten Inhalts.

[Eve666]

Das mit dem Zerhacken ist natürlich wahr und ich habe auch nicht behauptet, dass es einfach ist. Aber um den Inhalt (egal was es ist) anzuzeigen oder abzuspielen muss es wieder in ein abspielbares Formart gebracht werden... genau dort setzt man an, um das "umzuleiten". Dass das ohne aufwändiges ReverseEngineering nicht geht sollte klar sein.

Das Konzept an sich bleibt jedoch Broken By Design solange man keine TrustetComputingModule in alle Geräte verbaut und selbst die kann man knacken. Allerdings oft nur mit erheblich höherem Aufwand.

[zweistecken]

naja, screencapture. einfacher gehts wohl kaum. ausser das signal wird wirklich von anfang bis ende (also bis auf der graka & soundkarte) verschlüsselt (hdmi z.b.).

[nille02]

zweistecken schrieb:
--------------------------------------------------------------------------------
> naja, screencapture. einfacher gehts wohl kaum. ausser das signal wird
> wirklich von anfang bis ende (also bis auf der graka & soundkarte)
> verschlüsselt (hdmi z.b.).

Also HDCP ist kein Hindernis mehr. Es gibt sogar schon Hardware die es einem aus dem Signal raus nimmt um es dann z.B. mit einer Capture Card wieder aufzunehmen.

[bloody.albatross]

Ohne mir das Design hier genauer angeschaut zu haben, aber ich glaub kaum dass das übertragene Decodung Modul auch das Rendern übernimmt. Muss ja fürs Web OS unabhängig sein. D.h. es muss den dekotierten Stream an den Browser weiterreichen. Und wie die Browserseite zu implementieren ist, ist ja spezifiziert. Da implementiere ich halt einen Browser, der es statt darzustellen in eine Datei speichert. Btw. wenn das in Chromium implementiert ist patche ich den.