Aber das nützt dir eh nix, da OTR sein Verschlüsselungsverfahren offenbar demnächst ändern will ( Hashing der Aufnahmen ). 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.Code:Springe zu Block x Lese 256 Bytes ein Decodiere gelesene Daten Schreibe Daten in Ausgabedatei
@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
Wart einfach, bis fertich decodiert iss. :POriginal von calypso
Weiß jemand Rat?
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.
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 ! !Original von JustMe
Mein Decoder würde dann wenigstens auch mit Proxy funktionieren - muss wahrlich schwer für manche sein, dass hinzubekommen.
@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?
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.Original von Bumsi
mal auf dem teppic bleiben, was willst du denn wissen?
Berechtigungen
