Archiv verlassen und diese Seite im Standarddesign anzeigen : Meine Erfahrungen mit der Decoder-Performance
Hallo zusammen,
nachdem das Thema schonmal diskutiert wurde und die Aussage, dass I/O die entscheidende Rolle bei der Dekodier-Geschwindigkeit spielt, im Raum stehen gelassen wurde, möchte ich meine Erfahrungen zum Besten geben:
Gestern Abend habe mich mit ca. 1,5 MB/sec dekodiert (System 12 Stunden up and running).
Nach einem Reboot heute Morgen waren es ca. 8MB/sec.
Heute Abend (ohne Reboot) waren es wieder 1,5MB/sec.
Nach einem Reboot vor ca. 5 Minuten sind es noch immer 1,5MB/sec.
Die Leitung war jeweils frei und der Rechner idle-te vor sich hin (kein P2P, keine CPU- oder I/O-intensiven Progs).
Meine Schlussfolgerung (und man möge mich korrigieren...) ist, dass es eine Abhängigkeit zum Server von onlinetvrecorder.com gibt (Morgens: fast modus; Abends: slow modus oder so etwas in der Richtung).
Meine Decoder-Version ist 0.52. Der Decoder von Mr. S liess sich leider nicht erfolgreich installieren.
Viele Grüße
calypso
Die Decodiergeschwindigkeit hat mit dem Server von OTR absolut nix zu tun.
Der Decoder holt sich den Schlüssel und legt dann mit der Entschlüsselung los. Der Rest passiert ausschließlich auf deinem PC. Es gibt keine weitere Online-Aktivität des Decoders.
forestfriend
11.09.2006, 18:50
Kann das Problem nur bestätigen. Aber woran mag's liegen...
@calypso:
Es liegt nicht am Server, weil der heruntergeladene Key gerade mal aus 32 Bytes besteht - danach ist die Kommunikation mit dem Server beendet.
Der Decoder hingegen ist so langsam, weil:
1) unnütz aufwendiger Algorithmus
2) schlecht programmiert
3) der MS-Compiler miesen Code erzeugt
Um nicht nur ein paar Fetzen in den Raum zu werfen, hier die Erläuterung:
1) Der Algorithmus bläht obigen Key auf 4KB auf, ohne dass dadurch die Knackbarkeit erschwert würde. Mit dem großen Key werden dann viele aufwendige Operationen durchgeführt, als ob man einen guten Key hätte.
2) Dieser Punkt lässt sich schwer allgemeinverständlich erklären und bleibt daher erstmal im Raum.
3) Viele Operationen könnten zu einer einzigen vereint werden, hätte der Compiler den Code etwas genauer analysiert - das hängt z.T. aber auch mit 2) zusammen. Des Weiteren enthält der Code sogar komplett unnütze Operationen - analoges Bsp.: ein Programm, welches eine Datei einliest und komplett den gleichen Inhalt zurückschreibt.
Alles in allem bleibt eigentlich nur dem Autor zu raten, mal entsprechende Lehrgebäude (Schule, Uni, ...) auch von innen zu besuchen, anstatt nur vor dem Fernseher/Computer zu hängen.
Mich stört die Geschwindigkeit/Fehleranfälligkeit/Funktionslosigkeit (Stichwort: Proxy)/... nämlich auch und hätte ich zu viel Zeit, hätte ich schon einen besseren Decoder geschrieben. Vielleicht hat Bjoern Olausson ja zu viel Zeit und möchte mich mal kontaktieren...
Also V1.0.0.8 ist doch allerhöchstens eine Weiterentwick... na ja, ein weiteres Programm eben, welches dieselben Probleme teilt.
Von der Performance her soll dieser Decoder wesentlich besser sein.
Und wart ersma auf die 1.0.0.9, die in Kürze kommen soll. =)
Für Verbesserungsvorschläge kannst ja auch ma Mr. S kontakten. ;)
@Mr. S:
Würdest du den Teil deines Codes, der den Dekodieralgo darstellt, veröffentlichen oder wenigstens mir schicken? Das würde Leuten mit zu viel Zeit die Möglichkeit geben, eigene Programme zu schreiben. Disassemblieren ist zwar möglich, kostet aber unnötig Zeit.
Original von JustMe
1) Der Algorithmus bläht obigen Key auf 4KB auf, ohne dass dadurch die Knackbarkeit erschwert würde. Mit dem großen Key werden dann viele aufwendige Operationen durchgeführt, als ob man einen guten Key hätte.
Das werde ich mal prüfen, aber es ist nicht die Hauptursache. Die Hauptursache ist nämlich die Festplatte. Wie bereits in zig Beiträgen erklärt ist die Datei in Blöcken verschlüsselt und alle Blöcke sind nach einem bestimmten Muster durcheinander gewürfelt. Nun muss der Decoder für jeden Block (256 Byte) an eine andere Festplattenposition springen. Sinnvoller wäre es die Daten der Reihe nach hintereinander zu schreiben. Einfach mal die Dateigröße durch 256 teilen und das Ergebnis mit der Festplattenzugriffszeit multiplizieren. Dann kommt die maximale Zeit heraus welche im schlechtesten Fall von der Festplatte verbraten wird. Um die Geschwindigkeit zu erhöhen gibt es ein recht einfaches Mittel. Einfach die OTRKEY-Datei vor dem Decodieren auf einen schnellen Flash-Speicher (z. B. USB-Stick) kopieren. Natürlich muss der Datendurchsatz da auch stimmen.
Original von JustMe
2) Dieser Punkt lässt sich schwer allgemeinverständlich erklären und bleibt daher erstmal im Raum.
Gute Idee! Klugscheisser haben wir schon genug! :P
Original von JustMe
3) Viele Operationen könnten zu einer einzigen vereint werden, hätte der Compiler den Code etwas genauer analysiert - das hängt z.T. aber auch mit 2) zusammen. Des Weiteren enthält der Code sogar komplett unnütze Operationen - analoges Bsp.: ein Programm, welches eine Datei einliest und komplett den gleichen Inhalt zurückschreibt.
Welche Operationen denn?
Original von JustMe
Alles in allem bleibt eigentlich nur dem Autor zu raten, mal entsprechende Lehrgebäude (Schule, Uni, ...) auch von innen zu besuchen, anstatt nur vor dem Fernseher/Computer zu hängen.
Mich stört die Geschwindigkeit/Fehleranfälligkeit/Funktionslosigkeit (Stichwort: Proxy)/... nämlich auch und hätte ich zu viel Zeit, hätte ich schon einen besseren Decoder geschrieben. Vielleicht hat Bjoern Olausson ja zu viel Zeit und möchte mich mal kontaktieren...
Alles in allem bleibt eigentlich nur dem Poster zu raten, mal die eingebildete Klappe zu halten oder mehr Höflichkeit an den Tag zu legen! :evil: Hier gab es schon mal eine Person die gerne andere Forenmitglieder persönlich angegriffen hat und ein unerträglicher Klugscheisser war der groß mit seinen Kenntnissen angegeben hat!
Original von JustMe
Also V1.0.0.8 ist doch allerhöchstens eine Weiterentwick... na ja, ein weiteres Programm eben, welches dieselben Probleme teilt.
Welche Probleme meinst du konkret? Den Algorithmus kann ich nicht ändern, der ist von OTR vorgegeben! Ansonsten sind meine Decoder freie Entwicklungen von mir und basieren zu 0% auf OTR-Software! 1.0.0.9 läuft mittlerweile ohne MFC und ohne libcurl, also ohne externe Biliotheken (außer C++-Runtime).
Original von JustMe
@Mr. S:
Würdest du den Teil deines Codes, der den Dekodieralgo darstellt, veröffentlichen oder wenigstens mir schicken? Das würde Leuten mit zu viel Zeit die Möglichkeit geben, eigene Programme zu schreiben. Disassemblieren ist zwar möglich, kostet aber unnötig Zeit.
Benutz mal die Suche, es steht hier alles im Forum drin!
Original von Mr. S
Benutz mal die Suche, es steht hier alles im Forum drin!
Hab ich, aber außer den Hinweisen auf Blowfish und Little Endian ist nichts (mehr?) zu finden. Ich würde daher eine klare Aussage deinerseits begrüßen, ob du zumindest den innersten Teil veröffentlichst (und sei es Pseudocode), damit jeder für seine Plattform (oder aus welchen Gründen auch immer) eigenen Decoder programmieren kann. Dafür wär dir die Gemeinde hier sicher dankbar.
Springe zu Block x
Lese 256 Bytes ein
Decodiere gelesene Daten
Schreibe Daten in Ausgabedatei
Aber das nützt dir eh nix, da OTR sein Verschlüsselungsverfahren offenbar demnächst ändern will ( Hashing der Aufnahmen (http://otrforumde.h774788.serverkompetenz.net/thread.php?threadid=7184) ). Ich bezweifel allerdings immer noch das die Änderungen nützlich sind. Bisher gehe ich von Augenwischerei aus, mit der man vielleicht das Problem um die Dateinamen lösen kann aber sonst nichts anderes.
@Mr. S: Schade, du willst anderen also nicht helfen, um einen Decoder schreiben zu können. Deine Anleitung ist so hilfreich als würde ich einen Autoknacker fragen, wie verfährt und er antwortet: sich dem Auto annähern, Auto knacken, losfahren - ahh, danke! Kann ich ja sofort loslegen. Ob und vor allem wann OTR etwas ändert steht ja wie gesagt in den Sternen. Ich halte es daher noch durchaus für sinnvoll, damit noch anzufangen.
@JustMe
Du bist auf dem falschen Dampfer! Die fehlt eigentlich nur noch die Blockverschiebung. Dieses Detail poste ich aber nicht. Es soll ja nicht jeder einen Decoder bauen können. Wenn das jeder kann gibt es bestimmt bald Offline-Decoder oder Decoder, die die Schlüssel austauschen. Dann ist OTR aber illegal und dafür gebe ich keine Hilfe hier im Forum!
Hallo zusammen,
ich habe noch ein paar Tests gemacht und mich schliesslich vom alten Decoder verabschieden können, weil die o.g. Beta von Mr. S nun bei mir funktioniert. Mit diesem Decoder erreiche ich einen Durchsatz von etwa 50MB pro Sekunden (i+o).
Allerdings perform-t der Decoder nur bis etwa 300MB. Ein Beispiel von vor 10 Minuten: Eine OTRKEY-Datei ist 312 MB groß. Bis etwa 96% Fortschritt habe ich einen Durchsatz von ca. 50MB. Dann verlangsamt sich der Decodierungsprozess um etwa Faktor 70 auf ca. 0,7MB pro Sekunde bis zum vollständigen Decodieren.
Weiß jemand Rat?
Danke und Grüße
calypso
Original von calypso
Weiß jemand Rat?
Wart einfach, bis fertich decodiert iss. :P
Tja, ich würd ja nen besseren Decoder programmieren. Nur jetzt noch Reversing-Arbeit für den bald nicht mehr verwendeten Algo zu stecken, bringt ja nichts. Mein Decoder würde dann wenigstens auch mit Proxy funktionieren - muss wahrlich schwer für manche sein, dass hinzubekommen.
Calypso: Kannst dich also bei Mr. S bedanken, dass er weder öffentlich noch per PM Details zum Algo herausrückt. Sehr schade.
Original von JustMe
Mein Decoder würde dann wenigstens auch mit Proxy funktionieren - muss wahrlich schwer für manche sein, dass hinzubekommen.
Wenn die Proxy-Funktion funktionieren würde, wäre es ein leichtes die Keys zwischen Usern zu tauschen ein ernstes Sicherheitsrisiko das einem Offline-Decoder Hand und Tür öffnet ! !
@MRS
Also blos nicht zum laufen bringen !
Also dazu muss ich jetzt auch mal meinen Senf schreiben...
JustME: Du solltest nicht so schroff an die ganze Sache rangehen. Mr.S scheint seine Sourcen (oder Teile davon) nicht offenlegen zu wollen.
Das musst du akzeptieren. Denn die Legalität von OTR steht dabei im Vordergrund. Soll ja nicht jeder Hans und Franz wissen wie das hier alles funktionukkelt.
Doch ich denke auch dass es einiger Änderungen, und dabei meine ich nicht den OTR eigenen Decoder, nein ich meine Mr.S's decoder, bedarf. Auf meinem Rechner ist der Decoder von Mr.S nicht nutzbar, es existieren Speicherlecks u.s.w.!
von den fehlerhaften fuktionen wie die erkennung des festplattenspeichers, und dem Proxy mal abgesehen (das kann doch nicht so schwer sein, dass schreib ich beides in nichtmal 10 sekunden.)
Gruß
Bumsi
P.S. der OTR eigene Decoder ist natürlich noch ein vielfaches schlimmer :-)
mal auf dem teppic bleiben, was willst du denn wissen?
Original von Bumsi
mal auf dem teppic bleiben, was willst du denn wissen?
Ist das denn so schwer zu verstehen? Ich würde gern einen weniger fehleranfälligen Decoder programmieren. Da ich aber keine Lust habe, Stunden mit der Algo-Analyse zu verbringen (gerade jetzt, wo er demnächst abgelöst werden soll), hätte ich gerne entsprechende Infos.
mr.s hat doch schon eigentlich alles geschrieben...die datei wird in blöcke geteilt...diese sind nach einem muster verschoben...du liest byteweise ein , decodierst per 128 bit blowfish mit otr key und setzt dann zusammen...
Falls es dir hilft, den Key kann man mit
...
abholen...
Das kann man aber nur zweimal machen, danach
Bad Request
Und natürlich nur mit Files die der User auch programmiert hat...
Original von f48as4
Falls es dir hilft, den Key kann man mit ... abholen...
Da ich mit meinem Mod inzw. sogar offline decoden kann, weiß ich das natürlich. Das Ergebnis dieses Aufrufs ist ja der Originalschlüssel.
ja genau...dann solltest du weiter wissen, dass immer 256 bytes gelesen werden... du kannst also die ersten 256 bytes decodieren, dann machst du ab 512 weiter...u.s.w. mehr erzähl ich dir aber nicht...man muss das schon selber rausfinden.
ein stichwort dazu heißt: (CTS) ciphertex stealing.
der eigentliche key besteht aus einer ascii/hex-encoded 128 bit nummer.
das blowfish verfahren sollte das blowfish compact ecb verfahren sein.
wir basteln dir hier sicher keine copy-paste function...wenn du aber was netter wärst hätte ich dir ne function von mir zum decodieren zukommen lassen...die im ürbigen fast 40% schneller ist als die von mr.s!
und ja man kann das verfahren ganz leicht umgehen, ist ja kein geheimnis! jeder der etwas ahnung hat könnte seine files so oft decodieren wie er möchte ohne eine software zu modifizieren!
gruß
bumsi
@Bumsi
Hui du könntest du deinen Decoder veröffentlichen ?
40% schneller das wäre doch mal ein grandioser Fortschrit =)
Puffert der die Datei in den Arbeitsspeicher ? Das fehlt mir beim MRS ;)
ich selber werde den nicht veröffentlichen...habe aber vor ein paar tagen schon gesagt das ich gerne die sourcen meiner programme/projekte bereitstelle.
Original von Bumsi
ich selber werde den nicht veröffentlichen...habe aber vor ein paar tagen schon gesagt das ich gerne die sourcen meiner programme/projekte bereitstelle.
Komm schon =) mache einen Werbebanner rein und das rentiert sich für beide Seiten =)
leider keine zeit ne vernünftige gui zu bauen...wenn jedoch jemand anderes lust dazu hat einfach per pm bei mir melden....
Original von Bumsi
leider keine zeit ne vernünftige gui zu bauen...wenn jedoch jemand anderes lust dazu hat einfach per pm bei mir melden....
Du meinst wohl eher betteln... nett gefragt hatte ich bereits vor ein paar Tagen. Darauf kamen, wenn überhaupt, nur immer gleiche Antworten, die keinem helfen, sondern nur Zeit kosten.
Ich fragte auch nicht nach Source-Code für Copy-Paste, sondern lediglich nach dem formalen Algorithmus, der _alle_ Informationen enthält, um einem Programmierer zu ermöglichen, einen Decoder zu bauen. Ob die Übergabe nicht-öffentlich oder oder öffentlich geschieht, ist mir dabei egal.
Eine Community lebt nun mal vom Mitmachen. Dieser Thread zeigt aber bisher keine Bereitschaft von denen, die könnten (da Wissen um den Algo vorhanden).
ich habe ein oder zwei threads vorher doch geschrieben wie du genau vorgehen musst...
Original von Bumsi
ja genau...dann solltest du weiter wissen, dass immer 256 bytes gelesen werden... du kannst also die ersten 256 bytes decodieren, dann machst du ab 512 weiter...u.s.w. mehr erzähl ich dir aber nicht...man muss das schon selber rausfinden.
Ja. Danke. Ich gebs auf. Die, die helfen könnten wollen nicht. Und die, die wollen dürfen nicht.
Da mein größtes Problem mittels Offline Decoding bereits gelöst ist, soll mir der Rest egal. Anscheinend soll sich hier jeder mit dem, was ihm vorgeworfen wird (u.a. schlechte Decoder) leben. So sei es. X(
Offline Decoding? Speicherst du pöhser Pursche etwa den Key ab? *tztztz*
Was fürn Problem?
Kontrollierst du die Dateigröße vor dem decoden nicht? Hast du dauernd fehlerhafte Downloads? Ist deine Festplatte ständig voll und du bekommst Runtime Error?
Original von Menno
Was fürn Problem?
Kontrollierst du die Dateigröße vor dem decoden nicht? Hast du dauernd fehlerhafte Downloads? Ist deine Festplatte ständig voll und du bekommst Runtime Error?
Kein Problem mehr, was mich am decoden hindert. Dennoch besteht berechtigte Kritik. Wenn man die Originaldecoder beiseite lässt, so zeigen auch die Decoder von Mr. S, dass er vielleicht die eine oder andere Code-Zeile aneinanderreihen kann, aber programmieren würde ich das nicht nennen.
Bsp1: Der cmddecoder funktioniert wegen mehrerer Fehler nicht. Beim Einlesen des Passwort-Parameters setzt er den Benutzernamen wieder auf leer (welcher zuvor eingelesen wurde), womit sich das Programm beendet, als wäre keinsolcher angegeben. Selbst ohne diesen Fehler scheitert das Programm an der Prüfung des freien Plattenspeichers. usw usf.
Bsp2: Das Menü des GUI-Decoder wurde wohl programmierte, als das Gehirn schon schlief, denn das ist oft enabled, auch wenn's eigentlich nicht so sein sollte. Die Proxyeinstellungen sind ein Witz, da nicht mal ansatzweise versucht wird, diese zu berücksichtigen. So zu tun, als ob das eigene Programm eine Funktion unterstützt, obwohl diese noch nicht einmal funktioniert hat ist schon der Hammer.
Weitere Beispiele gibt es zu Hauf, würden aber sowohl mich beim Schreiben als auch evtl. Mitleser hier nur langweilen.
Die OTR-Webseiten verhalten sich da entsprechend, so dass ich sogar vermute, dass Mr. S mit zum OTR-Team gehört (wird natürlich sofort verneint, klar).
Alles in allem kann man eigentlich nur sagen: OTR ist eine wunderbare Idee, die Umsetzung ist mehr als mangelhaft, Innovation ist nicht erwünscht. Aber wer guckt schon einem geschenkten Gaul ins Maul... ich plädiere also dafür diesen Thread zu schließen. Letztlich bleibt hier eh jeder wo der Pfeffer wächst.
ich verstehe das ganze auch nicht, du hast alle infos...du musst nur mal ein wenig gehirnmasse anstrengen...
@Bumsi
Wie liegt dein Decoder den derzeit vor ? Eine Comandline-Version ?
Ich kann nämlich kein Delphi aber für eine ComandLine könnte ich ne Gui bauen ;)
das einzige was wirklich vor liegt ist der code um den schlüssel zu holen und der code zum decoden...beides in pascal und/oder asm geschrieben.
Bumsi
Bin nur zufällig in diesen interessanten Informatiker-Thread (oder Disput?) hineingerutscht und hab nich so viel ahnung vom Proggen aber ich bin ein Mensch
und seh das so
jemand geht zur Bankxy und sagt ich kann deine Kredietkarte sicherer machen
und die Bankxy sagt, wende dich an den Programierer
der giebt aber nich die Schlüssel raus(mit recht)
und die Bankxy sagt dazu nix
wer hat hier den Nachteil?
@Mr. S: Bitte mach den Thread jetzt zu. Ich sehe deinen Willen zu helfen nicht und damit ist dieser Thread nutzlos. Mach's gut und danke für den Fisch.
PS: Ich habe übrigens etwas anderes als Informatik studiert (nein, es ist nicht BWL).
CTVSupporter
16.10.2006, 14:21
Also laut OTR-team sieht das so aus:
Neuer Decoder/Encoder ist fertig und wird gerade getestet.
Der Übergang erfolgt mit dem nächsten Newsletter. Da wird es dann einige neue Projekte geben, sobald die fertig sind, kommt der Newsletter.
OTR als wenig innovativ darzustellen halte ich für falsch.
Andere bemängeln, daß es zuviele Änderungen gibt, anderen ist es zuwenig. Ja wie denn nu?
Wenn der alte decoder soooo schlimm wäre, frag ich mich, wie all die hundertausende Files bislang dekodiert wurden.
Der decoder hat selbstverständlich ne ganze Menge Mängel (allein schon nicht den freien Speicherplatz abzutesten tss tss) , aber es gab bislang eben wichtigere Projekte zu erledigen und dieses sensible Teil kann man nur schwer an andere abgeben.
Es mag zwar viel Gefrickel sein, aber bei mir gibt's keine Abstürze mehr mit MrS, wenn ich Drag&Drop sowie Ordnerdekodierung benutze. Nur das Abspeichern von Änderungen erfordert einen Absturz :D, aber es wird gespeichert und das mach ich genau einmal beim Installieren und fertig. Mit externer Platte könnte man die Dekodierspeed erhöhen, aber da ich wenig RAM habe, lasse ich den Datendurchsatz von interner zu externer Platte ruhen, sondern nutze nur die externe Platte. Dafür kann ich in Ruhe am PC arbeiten und dank MrS genügen 1-2 Klicks, um mir binnen 30-60min oder so den ganzen Ordner zu dekodieren, ohne dass ich mich um was kümmern brauch. Was will man mehr? Und ein Offline-Decoder ist dann auch mehr als überflüssig und schadet OTR allenfalls nur (juristisch).
Randfrage: Warum ist eigentlich Bumsi gesperrt? Gab's ne Kritik an OTR oder hat er sich selbst sperren lassen?...(Und wieso sagt Bumsi, er sei eine Frau und nun is da ein Symbol für m im Profil?)...Da bin ich ja recht froh, meine Login-Daten nicht an irgendwen's Programm rausgerückt zu haben, welcher sie ja laut Forum auf sich umleitet (Bumsi). Das wär mir nun etwas zu heikel. :P
MrS: Ich kenn sogar Informatiker, die nutzen keine Closes Source, aus Paranoia. Sicher nicht ganz unberechtigt, aber man kann's auch übertreiben und ins Kloster gehn...
Soll heißen: Danle für deinen Decoder. Der originale war echt nervig. Da graute es einem schon, einen Stapel dekodieren zu müssen und bei deinem freut man sich richtig drauf, so als ob man eine Dominoreihe anstupsen würde. ;) Und das ist die Leistung, die MrS hier erbracht hat. Nicht mehr und nicht weniger. Kritik hin oder her. Und man muß nebst den Leistungen (und Fehlern im Code) auch mal den Menschen dahinter sehn, der sowas in seiner Freizeit produziert. Etwas Spaß und Lob sollte man ihnen doch gönnen. Sicher macht's auch Spaß, sich um inhaltliches zu zoffen, aber übertreibt es nicht und habt euch wieder lieb. *g* :D ;)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.