Today i got this reader from local shop. Earlier i worked with Wiegand type readers with no problem. So anyway, when i try to read EM type card with 0009177233 ID (written on card) i should get at least 9177233 with start and stop chars expected. But instead i get 50008C0891
ASCII 50008C0891
HEX 02 35 30 30 30 38 43 30 38 39 31 0D 0A 03
BIN 00000010 00110101 00110000 00110000 00110000 00111000 01000011 00110000
00111000 00111001 00110001 00001101 00001010 00000011
I use USB-RS232 converter and RealTerm software.
Does anyone has any ideas why?
Are there 2 ID's?
The decimal 9177233 equals HEX 8C0891, so the software gives you the serialnumber in hexadecimal notation. I think, the full number 50008C0891 is the 5 Bytes (40bit) from the UID of the EM-type chip.
Regards
Related
I am trying to write some code to communicate with an old device over serial that uses the Siemens 3964r protocol. This includes a checksum, or more accurately a BCC (block check character) at the end of the transmission. A single char after the ETX. The docs define the BCC as this:
With the 3964R transfer protocol, data security is enhanced by sending an additional block
check character (BCC = Block Check Character).
The block check character is the even longitudinal parity (EXOR logic operation of all data
bytes) of a sent or received block. Its calculation begins with the first byte of user data (first
byte of the frame) after the connection establishment, and ends after the DLE ETX character
at connection termination.
Here is some sample data in hex.
53 54 41 54 55 53 10 03 07
07 is the BCC in this one.
4d 45 41 53 4d 50 54 45 53 54 41 4e 41 50 52 47 30 30 30 55 78 30 31 31 2e 30 30 5a 30 31 31 31 30 10 03 61
61 is the BCC in this one.
I know in general how to do XOR operations, but I haven't been able to figure out any combination of things that gives me a proper BCC. I think I am interpreting the definition wrong.
My preferred language for this is javascript as it's for a node.js electron app. I can read the buffer and get the hex values. And I can construct propoer messages back. But it won't work correctly until I can include a proper BCC. So just looking for someone smarter than me that knows exactly how to produce a valid BCC.
thanks!
The document that was posted as the first comment had the right structure to calculate the 3964r BCC. That document is here:
https://support.industry.siemens.com/cs/attachments/1117397/s7300_cp341_manual_en_en-US.pdf?download=true
Here is a simple javascript function. The hexarray would be passed in, not hardcoded like here, but this accurately calculates the BCC for this particular protocol. If anyone cares or needs it. I just wrote out the bcc as a hex string to the console in this, but you can make it a function and actually return something useable.
var hexarr = ['4d', 45, 41, 53, '4d', 50, 30, 30, 10, 03];
var bcc = 0;
var xor = 0;
for(var i= 0; i< hexarr.length; i++){
var hexint = parseInt(hexarr[i],16);
if(i==0){ xor = hexint; }
else {
bcc = xor ^ hexint;
xor = bcc;
}
}
console.log(bcc.toString(16));
I have to import a list of badge codes for a customer from an old software to the new one. Codes refer to 125Khz readonly rfid badges (most likely, not 100% shure about that).
If I read a given badge, the resulting hex string in the new software is "27000052B4", but in the old it is stored as "30 30 30 30 30 32 31 31 37 32 0D 0A".
I can't understand the transformation applied, and how to obtain "my" code from the stored one.
It's possible that some kind of "encryption" has been applied to the code, or that the stored code it's not the actual mifare tag uid but some other kind of value stored in memory, but I would like to ask if anyone can guess how to, if possibile at all, get the "normal" hex codes from the old values.
As a reference, I paste here a couple of old/new pairs:
badge n. 27000052B4, stored as: 30 30 30 30 30 32 31 31 37 32 0D 0A
badge n. 5B006E82AA, stored as: 30 30 30 37 32 34 32 34 31 30 0D 0A
To recap, I need to obtain the badge number in hex string starting from the stored value, in order to be able to recognize the badge/customer when i read it with the new software.
As an additional note, the trailing part "0D 0A" seems to be just a CRLF and it's the same for all the stored badges.
I'm not sure about the first 2 digits of the badge number, but the stored value is a US-ASCII encoded string that contains the decimal representation of the trailing 4(?) bytes of the badge number (and a carriage return + line feed):
30 30 30 30 30 32 31 31 37 32 0D 0A
is the string
"0000021172\r\n"
21172 in decimal is 0x52B4 in hexadecimal (i.e. the last part of 27000052B4). Similarly, 7242410 in decimal is 0x6E82AA in hexadecimal (i.e. the last part of 5B006E82AA).
I'm trying to interpret the communication between an ISO 7816 type card and the card reader. I've connected inline between the card and the reader when i dump the ouput to console i'm getting data that that im not expecting, see below:
Action: Card inserted to reader, expect an ATR only
Expected output:
3B 65 00 00 B0 40 40 22 00
Actual Output:
E0 3B 65 00 B0 40 40 22 00 90 00 80 9B 80 E0 E2
The 90 00 is the standard for OK that it reset, but why i am still logging additional data both before the ATR (E0) as well as data after
The communication line is documented in ISO 7816-3 (electrical interface and transmission protocols), look for the respective chapters of T=0 or T=1 protocol. T=1 is a block oriented protocol involving a prolog containing node addresses and an epilog containing a CRC/LRC.
For the ATR however, no protocol is running yet, since here the information is contained, which protocols the card supports, for the terminal to choose. Surely so early 90 00 is no SW1/SW2.
I don't understand this question:
Consider a system that has a byte-addressable memory organized in 32-bit words according to the big-endian scheme. A program reads 2 integers into an array and stores them in successive locations, starting at location at address 0x00001000. The 2 integers are 1025 and 287,454,020.
Show the contents of the two memory words at locations 0x00001000 and 0x00001004 after the two integers have been stored.
Can anyone explain how to do this? This is like a new language to me.
Big endian just means that the bytes are ordered from most significant to least significant at increasing memory addresses, so:
0x00001000 00 04 00 01 ; 1024 (decimal) = 00040001 (hex)
0x00001004 11 22 33 44 ; 287454020 (decimal) = 11223344 (hex)
Just for completeness, if this were a little endian system then memory would look like this:
0x00001000 01 00 04 00 ; 1024 (decimal) = 00040001 (hex)
0x00001004 44 33 22 11 ; 287454020 (decimal) = 11223344 (hex)
I had a long time decoding IR codes with optimum's Ken Shirriff Arduino Library. I modified the code a bit so that I was able to dump a Samsung air conditioner (MH026FB) 56-bit signals.
The results of my work is located in Google Docs document Samsung MH026FB AirCon IR Codes Dump.
It is a spreasheet with all dumped values and the interpretation of results. AFAIK, air conditioner unit sends out two or three "bursts" of 56 bit data, depending on command. I was able to decode bits properly, figuring out where air conditioner temperature, fan, function and other options are located.
The problem I have is related to the checksum. In all those 7-byte codes, the second one is computed somehow from the latter 5 bytes, for example:
BF B2 0F FF FF FF F0 (lead-in code)
7F B8 8A 71 F6 4F F0 (auto mode - 25 degrees)
7F B2 80 71 7A 4F F0 (auto mode - 26 degrees)
7F B4 80 71 FA 7D F0 (heat mode - 26 degrees - fan auto)
Since I re-create the IR codes at runtime, I need to be able to compute checksum for these codes.
I tried with many standard checksum algorithms, none of them gave meaningful results. The checksum seems to be related to number of zeroes in the rest of code (bytes from 3 to 7), but I really can't figure it how.
Is there a solution to this problem?
Ken Shirriff sorted this out. Algorithm is as follow:
Count the number of 1 bits in all the bytes except #2 (checksum)
Compute count mod 15. If the value is 0, use 15 instead.
Take the value from 2, flip the 4 bits, and reverse the 4 bits.
The checksum is Bn where n is the value from the previous step.
Congraturations to him for his smartness and sharpness.
When bit order in bytes/packets and 0/1 are interpreted properly (from the algorithm it appears that both are reversed), the algorithm would be just sum of 0 bits modulo 15.
It is nearly correct.
Count the 0's / 1's (You can call them what you like, but it is the short signals).
Do not count 2. byte and first/last bit of 3.byte (depending if you are seeing it as big or little indian).
Take the result and -30 (29-30 = 15, only looking af 4 bits!)
Reverse result
Checksum = 0x4 "reverse resultesult", if short signals = 0, and 0xB "reverse resultesult" if long signal = 0.
i used Ken's method but mod 15 didnt work for me.
Count the number of 1 bits in all the bytes except #2 (checksum)
Compute count mod 17. if value is 16, use first byte of mode result(0).
Take the value , flip the 4 bits.
The checksum is 0xn9 where n is the value from the previous step.