Im vorherigen Blogbeitrag haben wir die abstrakte Datenebene der passiven Callback-Schnittstelle vorgestellt und eine effiziente Grundfunktion zur Konvertierung von Entitäten in XML implementiert. Aufmerksame Entwickler finden bei der ersten Änderung der Grundkonfiguration des offiziellen Kontos eine Option namens „Message Encryption and Decryption Method“. Die nach der Erweiterung wählbaren Werte sind: „Klartextmodus“ (Standard), „Kompatibilitätsmodus“ und „Abgesicherter Modus (empfohlen)“. Was ist also dieser abgesicherte Modus? Wie kann ich mich an den abgesicherten Modus anpassen? Mit diesen Fragen im Hinterkopf beginnen wir die dritte Erkundungsreise des WeChat-Zugriffs.
Abscheuliche Verkehrsentführung: Zu Beginn des Artikels zeige ich Ihnen zwei Screenshots von Mobiltelefonen im normalen Gebrauch:
Auf der rechten Seite Auf dem Bildschirm sehen Sie in der unteren Ecke einen grünen Wasserballon, der nicht mit dem anzuzeigenden Bild kompatibel ist und offensichtlich nicht vom Designer erstellt wurde. Klicken Sie auf die Wasserblase, um die verbleibenden Verkehrsdetails im aktuellen Kommunikationspaket anzuzeigen.
Vom Heim-LAN über das Internet bis zum IDC-Computerraum-Intranet sind unsere Datenverbindungen voller Weiterleitungsprozesse. Unsere Daten können bei der Weiterleitung durch ein beliebiges Gerät bestehen bleiben und gespeichert werden. Ist Ihr Büro-Intranet sicher? Um Sie herum lauernde Hacker können eine Kopie aller Daten im LAN erhalten, indem sie eine bestimmte Netzwerkkarte im LAN in den Promiscuous-Modus versetzen. Vielleicht können Sie nichts finden, aber Ihre privaten Daten wurden von anderen gestohlen.
Verwenden Sie den abgesicherten Modus, um die Privatsphäre der Benutzer zu schützen
Wenn der abgesicherte Modus aktiviert ist, ändern sich die von der passiven Rückrufschnittstelle empfangenen Nachrichten stark, wie unten gezeigt:
<xml> <ToUserName><![CDATA[gh_38a2de904e09]]></ToUserName> <Encrypt><![CDATA[i7b8ccNA9OWDhau/F26aUWKFJ6Jd0imsDQIFPSdSfAg8mHT7rL0kIWSVpcqf6/dVSoOQOQK4T/CS3w96j4k3qcg89M6xn2RGZBs+9JkrsdRig5yhcia1B59akWb1t9QdutXqnl4edAqtXEh8SIs+N2HkOTTVldtOUHpdwLqRYuC4F6ejUoXui4xKuc3oyODR9edfL+xzZ7JfMJ1KUNF/YBJMj/Ba9y/CLLYmdFYOtCMH7tMUz8h+S0XKkHKN6r0ELLCIZJ9+PPlHZcfSGhwMLUeRF1nMIjXGEKHkI0uMcruh7wD96lMU/RFgJDjAk26xbmUYfa3l+34p+txw4R8iD3Q58S8Yekiy3lUsbk+C6eDeefGs1ck23BQ8xWU3AReWH2dEsY6SYIkb3ANeyJmcoIKZfpc/31njp0KcHAxL1Lk=]]></Encrypt> </xml>
It Es ist ersichtlich, dass der Klartextteil die ursprüngliche ID des öffentlichen Kontos der Nachricht behält: gh_38a2de904e09, und der Rest ist verschlüsselter Text (diese Struktur ermöglicht es demselben Backend-System, auf mehrere öffentliche Konten zuzugreifen und dann die Nummerneinstellungen jedes öffentlichen Kontos zu verwenden). zur separaten Entschlüsselung). Da die Verschlüsselungsstruktur im offiziellen Dokument (http://qydev.weixin.qq.com/wiki/index.php?title=Encryption and Decryption Library Download and Return Code) nicht klar erläutert wird, werde ich Ihnen eine detaillierte Erklärung geben Hier. .
Wenn der Leser bereits Netzwerkprotokolle entwickelt hat, sollte diese Struktur, eine typische Nachricht variabler Länge, leicht zu verstehen sein. Es muss eine Markierung vorhanden sein, die die Länge des Bereichs mit variabler Länge angibt. Beim Lesen muss dieser Wert maßgebend sein, und nach den Daten mit fester Länge wird eine bestimmte Anzahl von Bytes gelesen. Am Anfang der Struktur steht eine 16-Byte-Zufallszahl. Dieser Teil der Daten hat keine praktische Bedeutung und kann später als Zufallszahlen-Auffülldaten für die Rückgabe verschlüsselter Nachrichten verwendet werden.
Signaturüberprüfungsmethode im abgesicherten Modus
Die passive Rückrufschnittstelle von WeChat ist eigentlich eine HTTP-POST-Anfrage. Wir alle wissen, dass HTTP-Anfragen in Anforderungsheader und Anforderungstexte unterteilt sind. WeChat fügt die verschlüsselten XML-Daten geschickt in den Anfragetext ein und fügt die bei der Überprüfung der Signatur verwendeten Parameter in den Anfrageheader ein.
POST /cgi-bin/wxpush? msg_signature=477715d11cdb4164915debcba66cb864d751f3e6×tamp=1409659813&nonce=1372623149 HTTP/1.1 Host: qy.weixin.qq.com Content-Length: 613 <xml> <ToUserName><![CDATA[wx5823bf96d3bd56c7]]></ToUserName> <Encrypt><![CDATA[RypEvHKD8QQKFhvQ6QleEB4J58tiPdvo+rtK1I9qca6aM/wvqnLSV5zEPeusUiX5L5X/0lWfrf0QADHHhGd3QczcdCUpj911L3vg3W/sYYvuJTs3TUUkSUXxaccAS0qhxchrRYt66wiSpGLYL42aM6A8dTT+6k4aSknmPj48kzJs8qLjvd4Xgpue06DOdnLxAUHzM6+kDZ+HMZfJYuR+LtwGc2hgf5gsijff0ekUNXZiqATP7PF5mZxZ3Izoun1s4zG4LUMnvw2r+KqCKIw+3IQH03v+BCA9nMELNqbSf6tiWSrXJB3LAVGUcallcrw8V2t9EL4EhzJWrQUax5wLVMNS0+rUPA3k22Ncx4XXZS9o0MBH27Bo6BpNelZpS+/uh9KsNlY6bHCmJU9p8g7m3fVKn28H3KDYA5Pl/T8Z1ptDAVe0lXdQ2YoyyH2uyPIGHBZZIs2pDBS8R07+qN+E7Q==]]></Encrypt> </xml>
Der Prozess der Signaturgenerierung:
Durch die obige Berechnung wird nun die Signatur berechnetes_Zeichen der aktuellen verschlüsselten Nachricht erhalten und dann erhalten Aus dem Anforderungsheader-Parameter msg_signature: Wenn berechnetes_sign und msg_signature gleich sind, bedeutet dies, dass die Nachricht nicht manipuliert wurde. Die von dieser Signaturstrategie verwendeten mathematischen Probleme sind:
1. Der SHA1-Digest-Algorithmus berechnet alle Daten und alle Änderungen führen dazu, dass sich der endgültige Digest ändert.
2 Das Token wird im Voraus festgelegt und verarbeitet Der Übertragungsprozess ist nicht in der AES-Verschlüsselung enthalten und kann nicht geknackt werden.
3 🎜>Signaturüberprüfung erfolgreich. Anschließend können Sie den entschlüsselten Klartext sicher verwenden. Das Format des Klartextes stimmt mit dem im vorherigen Artikel eingeführten Format überein, sodass die entschlüsselte Geschäftsverarbeitungslogik wiederverwendet werden kann.
Als Reaktion auf den abgesicherten Modus sollte auch das zurückgegebene XML-Format verschlüsselt werden. Der gesamte Verschlüsselungsprozess verläuft in entgegengesetzter Richtung zum Entschlüsselungsprozess, daher werde ich hier nicht auf Details eingehen.
Weitere Artikel zur WeChat-Zugriffserkundung – verschlüsselte Nachrichtenverarbeitung finden Sie auf der chinesischen PHP-Website!