Hallo an alle, ich habe folgendes Szenario: einen fiktiven rfid-transponder (mglw.EM410x) mit der hex-UID: 0102b0c1fd diese möchte ich umwandeln in eine 20 stellige ZK-Nummer. Hierfür wird jedes einzelne hex-Symbol in eine vierstelligen binärzahl umgewandelt. 00000001 00000010 10110000 11000001 11111101 Danach werden die einzelnen Gruppen gespiegelt: 1000 0000 0100 0000 0000 1101 1000 0011 1011 1111 Abschließend werden diese Werte nach ihrer binären Wertigkeit in dezimale Werte umgerechnet. 0800 0400 0000 1308 0311 15 08000400001308031115 Die Frage die sich mir nur stellt: Wieso werden die Bits gespiegelt? Ist dafür ein Protokoll/ Norm zuständig? Ich kann dazu leider absolut keine Informationen finden. Vielen Dank für eure Hilfe. Beste Grüße Eyk
Bits werden meist gespiegelt, wenn das Zielsystem eine andere Endianess hat (vgl. Littel und Big Endian). -> vgl. https://de.wikipedia.org/wiki/Byte-Reihenfolge Dabei verwenden manche Systeme das höchstwertige Bit links und machne rechts. Schau dir den Wikiartikel an.
Benjamin S. schrieb: > Dabei verwenden manche Systeme das höchstwertige Bit links und machne > rechts. Unabhängig von der Endianess ist das niederwertigste Bit eines Bytes bei allen gängigen CPUs immer rechts. Nur die Reihenfolge der Bytes im Speicher bzw. die Wertigkeit von aufeinander folgenden Bytes ist abhängig von der Endianess. Eric P. schrieb: > Die Frage die sich mir nur stellt: Wieso werden die Bits gespiegelt? Mir stellt sich die Frage: warum wird die Information so unnötig aufgebläht? Man könnte das ganze ja noch vorlesen und als WAV-Datei speichern...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Benjamin S. schrieb: >> Dabei verwenden manche Systeme das höchstwertige Bit links und machne >> rechts. > Unabhängig von der Endianess ist das niederwertigste Bit eines /Bytes/ > bei allen gängigen CPUs immer rechts. > > Nur die Reihenfolge der Bytes im Speicher bzw. die Wertigkeit von > aufeinander folgenden Bytes ist abhängig von der Endianess. > Vielen Dank erstmal für die Info. > Eric P. schrieb: >> Die Frage die sich mir nur stellt: Wieso werden die Bits gespiegelt? > Mir stellt sich die Frage: warum wird die Information so unnötig > aufgebläht? Man könnte das ganze ja noch vorlesen und als WAV-Datei > speichern... Ich habe einen RFID-Reader (parralax 28142) und mehrere Transponder(mglw. EM410x). Auf denen ist die 20-stellige ZK-Nummer aufgebracht. Um diese abzugleichen, musste ich die hex-Nummer umrechnen. Mir ist nur nicht bewusst, warum die Bits gespiegelt werden müssen. Mfg Eyk
Du bist dir sicher, dass die Daten richtig herum eingelesen werden? Dein spiegeln würde darauf deuten, einfach immer nach links shiften. Gruß Sven
Wenn die Daten seriell eingelesen werden, ist das möglicherweise schon die Ursache: LSB first statt MSB first (oder anders herum). Mit Big- oder Little-Endian hat das jedenfalls nichts zu tun.
Markus F. schrieb: > Wenn die Daten seriell eingelesen werden, ist das möglicherweise schon > die Ursache: LSB first statt MSB first (oder anders herum). > > Mit Big- oder Little-Endian hat das jedenfalls nichts zu tun. Ist mir so beim seriellen einlesen noch nie aufgefallen, aber ja die Daten werden seriell eingelesen.
Eric P. schrieb: > Mir ist nur nicht bewusst, warum die Bits gespiegelt werden müssen. Für mich sieht das aus, wie wenn einer ernsthafte Probleme mit der Zahlendarstellung hatte. Wer eine einstellige Hex-Zahl in eine zweistellige Dezimalzahl umrechnet und die mit ASCII-Zeichen darstellt, dem ist nicht zu helfen. Oder es ist simple Obfuscation von Geheimniskrämern...
Lothar M. schrieb: > Eric P. schrieb: >> Mir ist nur nicht bewusst, warum die Bits gespiegelt werden müssen. > Für mich sieht das aus, wie wenn einer ernsthafte Probleme mit der > Zahlendarstellung hatte. Wer eine einstellige Hex-Zahl in eine > zweistellige Dezimalzahl umrechnet und die mit ASCII-Zeichen darstellt, > dem ist nicht zu helfen. > > Oder es ist simple Obfuscation von Geheimniskrämern... habe hier noch eine pdf zu dem Thema gefunden (Seite 3). http://www.easyident.de/PDF%20Files/Umrechnung%20easyident%20Ausgabe%20in%20diverse%20Codes.pdf Leider wird dort auch nicht erklärt wieso, noch finde ich irgendwelche Informationen zu einem "ZK-Code"
:
Bearbeitet durch User
Eric P. schrieb: > Leider wird dort auch nicht erklärt wieso, noch finde ich irgendwelche > Informationen zu einem "ZK-Code" Das wird (wahrscheinlich) so gemacht damit es komplizierter aussieht. Transponder-ID wird werksseitig festgelegt, mit Header und Paritybits ergibt das 64 bit. Das wird immer auf gleiche Art und Weise eingelesen und ergibt immer 9 Header bits, 40 Data bits, 9 line parity bits und 4 column parity bits. Also besteht nutzbare Info aus einem Array von 40 bits. Ob du jetzt dieses Array von links nach rechts liest, ob Little- oder Big-Endian, ob Nibbles oder Bytes oder sonstwas, das bleibt dir überlassen - aber die Transponder-ID ist immer 40 bits lang und immer unique bzw. einmalig. P.S. Natürlich nur bis 1,099,511,627,775 Transponder. P.P.S. Ob du 1000 0000 0000 0000 0000 0000 0000 0000 0000 0000 als 549,755,813,888 dekodierst, oder als 1 bleibt dir überlassen.
:
Bearbeitet durch User
bitte nicht falsch verstehen, aber eine sichere Aussage kann mir keiner geben oder?
Eric P. schrieb: > bitte nicht falsch verstehen, aber eine sichere Aussage kann mir keiner > geben oder? Was ausser "Ist halt so!" willst Du hören? Genau wie die anderen gängigen Schreibweisen hat sich das mal jemand so ausgedacht, müsste Honeywell gewesen sein. Wenn Du die Gedankengänge der Verantwortlichen kennen willst, kannst Du Dich ja dort erkundigen oder es einfach so hinnehmen.
Eric P. schrieb: > bitte nicht falsch verstehen, aber eine sichere Aussage kann mir keiner > geben oder? Ja, ich kann es. Da die Spielerei mit rumspiegeln und Platzwechsel absolut keinen Einfluss, weder auf Sicherheit noch auf sonst etwas hat, ist es unnötig und dient nur dazu, Leute wie dich zu beeindrucken.
Hmmm schrieb: > Eric P. schrieb: >> bitte nicht falsch verstehen, aber eine sichere Aussage kann mir keiner >> geben oder? > > Was ausser "Ist halt so!" willst Du hören? Ist halt so, ist für mich leider etwas mager als Antwort. Es hätte ja sein können das jmd schreibt, ja ist in Norm/ Standard XY beschrieben. > Genau wie die anderen gängigen Schreibweisen hat sich das mal jemand so > ausgedacht, müsste Honeywell gewesen sein. Das ist doch schon mal eine brauchbare Information. Marc V. schrieb: > Ja, ich kann es. > > Da die Spielerei mit rumspiegeln und Platzwechsel absolut keinen > Einfluss, weder auf Sicherheit noch auf sonst etwas hat, ist es > unnötig und dient nur dazu, Leute wie dich zu beeindrucken. Ja richtig, ich bin schwer beeindruckt. Ich wollte einfach nur wissen, ob dahinter ein tieferer Sinn steckt. Aber trotzdem Danke für deinen Beitrag...
:
Bearbeitet durch User
... zumal die UID nur der Kollisionserkennung beim lesen der Karte(n) dient und nicht mit einer echten Unique ID wie z.B. MAC adresse verwechselt werden sollte.
Eric P. schrieb: > Ist halt so, ist für mich leider etwas mager als Antwort. Es hätte ja > sein können das jmd schreibt, ja ist in Norm/ Standard XY beschrieben. Wirklich wissen tue ich auch nichts, aber ich würde auch vermuten, dass sich da einfach jede Firma ihre eigene Darstellung ausdenkt, und es für die von Dir beschriebene Darstellung keine Norm/keinen Standard gibt. Für meinen 125kHz-RFID-Reader habe ich bspw. auch mal ein kleines Skript geschrieben und auf GitHub veröffentlicht, das die RFID in unterschiedlichen Darstellungen ausgeben kann: https://github.com/oyooyo/record-stream-decoder#rfid_125khz (Da findest Du am Ende auch Links zu zwei Webseiten, auf denen ein paar Darstellungen aufgelistet/beschrieben werden.) Der Witz ist: Bei meinem Skript kann man alleine zwischen 13 verschiedenen Darstellungen wählen, die ich irgendwo im Internet beschrieben gefunden habe - darunter ist aber keine einzige, bei der die Bits gespiegelt werden, es gibt also offenbar noch etliche mehr, als ich bislang dachte. Was in dem von Dir verlinkten PDF "IK-2" genannt wird, könnte das sein, was ich irgendwo als "10H>13D" beschrieben gefunden habe. Was in dem PDF "Acticon GmbH-Code" genannt wird, könnte wiederum das Format sein, das bei mir "08H>10D(int)" genannt wird. Mein Eindruck war übrigens bislang, dass die einzige einigermassen standardisierte Darstellung bei 125kHz-Tags die 10-stellige Dezimalzahl ist, die auf ausnahmslos allen 125kHz-Tags aufgedruckt ist, die ich bislang (aus unterschiedlichen Quellen) gekauft habe. Diese Darstellung wird bei meinem Script "08H>10D" genannt, und müsste die gleiche Darstellung sein wie die in Deinem Dokument "Acticon GmbH-Code" genannte Darstellung - nur mit vorangestellten Nullen, um immer auf 10 Dezimalstellen zu kommen. Selbst das ist aber offensichtlich keineswegs bei allen Tags so, wenn Du sagst, dass auf Deinen Tags stattdessen eine 20-stellige Zahl aufgedruckt ist...
Eric P. schrieb: > Ja richtig, ich bin schwer beeindruckt. Ich wollte einfach nur wissen, > ob dahinter ein tieferer Sinn steckt. Mit Sicherheit nicht. Die Karten-ID ist 5 Bytes lang und es wird garantiert (immer noch), dass diese ID einmalig ist. Da kannst du spiegeln, drehen, vertauschen oder sonstwas tun - es wird weder sicherer noch unsicherer dadurch. Auf der Karte selbst sind nur die 3 niederwertigsten Bytes aufgedruckt. Falls für die Karten-ID folgendes gelesen wird: 0x34-0x00-0xC2-0xC4-0x69 Auf der Karte wird dann folgendes aufgedruckt: 0012764265 194,50281 ^ ^ ^ ^ | | | | 10 Stellen 0xC2 0xC469 Dezimal 0xC2C469
:
Bearbeitet durch User
Marc V. schrieb: > Auf der Karte selbst sind nur die 3 niederwertigsten Bytes aufgedruckt. > > Falls für die Karten-ID folgendes gelesen wird: > 0x34-0x00-0xC2-0xC4-0x69 > > Auf der Karte wird dann folgendes aufgedruckt: > 0012764265 194,50281 > ^ ^ ^ ^ > | | | | > 10 Stellen 0xC2 0xC469 > Dezimal > 0xC2C469 Genau, das ist auch die Darstellung, die auch ich von allen meinen RFID-Karten im Kreditkarten-Format kenne. Auf den kleineren, runden Tags hingegen steht bei mir nur die erste Darstellung, als zehnstellige Dezimalzahl. Allerdings bin ich recht sicher, dass nicht die drei, sondern die vier niederwertigsten Bytes aufgedruckt sind. Das macht imo auch deshalb Sinn, weil - der maximale Wert einer 4*8=32-Bit-Zahl in Dezimaldarstellung eben 10-stellig ist, während bei 3 Bytes ja 8 Dezimalziffern genügen würden - m.W.n. die unteren vier Bytes die "ID" darstellen, während im obersten/fünften Byte "Revision" und "Vendor" kodiert sind
Damit die Sicherheitstechnik schön kompliziert und nicht gleich auf andere Systeme übertragen werden kann ist immer alles schön kompliziert oder abgeschottet. Im Klartext: Die UID ist fest eingebrand im Transponder, aber jeder Hersteller hat u.U. sein eigenes Leseverfahren bzw. seine eigene Interpretation/Darstellung dieser UID. Daher gibt es mehrere Möglichkeiten eine UID auszulesen, einzugeben und zu benutzen. Bsp. einer UID eines UNI-, EM42xx- 125KHz-.... Transponders: UID (Hex10): AF34781265 IK2: 0752499561061 IK3/IS-Code: 1053007169702 ZK-Code/Codierung: 15050212011404081006 COMLock (Hex8): 34781265 Dorma XS: 1787093442 TelenotX, Acticon, Wiegand 34: 0880284261 Wiegand 32: 1343204709 Wiegand 26: 12004709 ELV TimeMaster: 7869029 Oben stehende Nummern sind alles Darstellungen der ein und selben Transponder UID, umgerechnet in das Format des jeweiligen Zielsystems, welches auch noch abhängig vom jeweiligen Leser ist. Um es noch verwirrender zu machen: Eine Einbruchmeldeanlage arbeitet mit dem (d.h. liest zwar den) IK3-Code, stellt aber in der Programmiersoftware den IK2 dar. Informationen dazu findet man im Internet sehr wenig bis keine. Wem es etwas hilft, auf meiner Homepege kann ein Programm zur Umrechnung aller hier genannten Codes heruntergeladen werden: www.schneeer.npage.de
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.