Ich habe diesen Code in C, den ich nach C # portieren muss:
%Vor%Ich habe es versucht:
%Vor%Aber das Ergebnis stimmt nicht mit dem erwarteten überein.
Nach dem Beispiel:
%Vor%sollte dies werden:
%Vor%Es sagt auch, das erste Byte ist nicht verschlüsselt, deshalb bleibt A5 gleich.
Zur Klärung BEARBEITEN : Die Spezifikation sagt nur, dass Sie das erste Byte überspringen sollten, es geht nicht ins Detail, also schätze ich, dass Sie nur die Sequenz von Position 1 bis zur letzten Position übergeben Überspringen des ersten Bytes.
Aber mein Ergebnis mit diesem C # -Port ist:
%Vor%Ist dieser Port korrekt oder fehlt mir etwas?
BEARBEITEN 2 : Für weitere Erläuterungen ist dies ein geschlossenes Protokoll, daher kann ich nicht ins Detail gehen. Aus diesem Grund habe ich gerade genug Informationen bereitgestellt, um den Code, den C-Code, zu portieren dasjenige, das mir gegeben wurde, und genau das hat die Spezifikation gesagt. Das eigentliche Problem war, dass die "0xAA" in der Spezifikation falsch war, deshalb war die Ausgabe nicht die erwartete. Der hier bereitgestellte C # -Code und die akzeptierte Antwort sind schließlich korrekt.
Lasst es uns brechen, Schritt für Schritt.
%Vor%Unabhängig von einigen anderen Bemerkungen ist dies wie Sie normalerweise diese Dinge in C / C ++ tun. Es gibt nichts Besonderes an diesem Code, und es ist nicht allzu kompliziert, aber ich denke, es ist gut, es zu brechen, um Ihnen zu zeigen, was passiert.
Zu beachten:
Das einzige "schwierige" Ding hier ist der Buffer ++. Details können in dem Buch "Exceptional C ++" von Sutter gelesen werden, aber ein kleines Beispiel erklärt das auch. Und zum Glück haben wir ein perfektes Beispiel dafür. Eine literale Übersetzung des obigen Codes lautet:
%Vor%In diesem Fall kann die Temperaturvariable trivial gelöst werden, was uns zu folgendem führt:
%Vor%Das Ändern dieses Codes in C # ist jetzt ziemlich einfach:
%Vor%Das ist im Grunde genommen dasselbe wie Ihr portierter Code. Das bedeutet, dass irgendwo auf der Straße etwas anderes schief gelaufen ist ... Also lasst uns den Cryptobuffer hacken, oder? : -)
Wenn wir annehmen, dass das erste Byte nicht verwendet wird (wie Sie sagten) und dass "0xAA" und / oder "0xC9" falsch sind, können wir einfach alle Kombinationen ausprobieren:
%Vor%Da gehen wir: oops gibt es keine Lösungen. Das bedeutet, dass der Cryptobuffer nicht das tut, was er zu tun glaubt, oder ein Teil des C-Codes fehlt hier. F.ex. übergeben sie wirklich "Buffer" an die CryptoBuffer-Methode oder haben sie den Zeiger vorher geändert?
Abschließend denke ich, die einzige gute Antwort hier ist, dass kritische Informationen zur Lösung dieser Frage fehlen.
Die Portierung sieht richtig aus; Kannst du erklären, warum 03 zu 6F werden sollte? Die Tatsache, dass das Ergebnis bis 03 um den "erwarteten" Wert zu sein scheint, ist für mich etwas verdächtig.
Der Port sieht richtig aus.
Was ich in dieser Situation tun würde, ist ein Stück Papier und einen Stift herauszunehmen, die Bytes in Binärform auszugeben, den XOR zu machen und dann die Addition. Vergleichen Sie dies nun mit den C- und C # -Codes.
Bei der ursprünglichen Methode in C nehmen wir zuerst an, dass die Sequenz auf eine symmetrische Weise mit dem Aufruf von CryptoBuffer
ruft zunächst a5 03 18 01 ...
dann auf d8 72 7b 74 ...
ruft zunächst a5 6f 93 8b ...
dann auf d8 8e 02 ea ...
und wir wissen, dass es nicht machbar ist.
Natürlich haben Sie möglicherweise eine asymmetrische Entschlüsselungsmethode; aber zuerst müssten wir entweder a5 03 18 01 ... => a5 6f 93 8b ... oder die Umkehrung der Richtung mit irgendeiner möglichen magischen Zahl beweisen. Der Code einer Analyse mit einem Brute-Force-Ansatz wird hinter dem Post eingefügt.
Ich machte die magische Zahl eine Variable zum Testen. Mit Reproduzierbarkeitsanalyse fanden wir heraus, dass die ursprüngliche Sequenz alle 256 Aufrufe auf kontinuierlich variierten magischen Zahlen reproduziert werden kann. Okay, mit dem, was wir durchgemacht haben, ist es hier noch möglich.
Die Machbarkeitsanalyse testet jedoch alle 256*256=65536 Fälle mit beiden Richtungen, von original => expected und expected => original , und keine macht es.
Und jetzt wissen wir, dass es keine Möglichkeit gibt, die verschlüsselte Sequenz zu dem erwarteten Ergebnis zu entschlüsseln.
Somit können wir nur sagen, dass das erwartete Verhalten beider Sprachen oder Ihres Codes identisch ist , aber das erwartete Ergebnis ist nicht möglich , weil die Annahme gebrochen ist .
Code für die Analyse
%Vor%Hier ist eine Demonstration
zeigt, dass der ursprüngliche Code bei einer Eingabe von A5 03 18 01 D8 72 7B 01 erzeugt; also
Regel, dass das erste Byte nicht decodiert wird, kann nur korrekt sein, wenn der Puffer ab dem 2. gesendet wird (zeigen Sie uns den Aufruf)
stimmt die Ausgabe nicht überein (Vermissen Sie andere Anrufe?)
Ihre Übersetzung ist also korrekt, aber Ihre Erwartungen an den ursprünglichen Code sind nicht richtig.
Tags und Links c c# encryption