My Card Reader is reading the wrong number!
Often card numbers may present at a customer site the differs from the number stored in the accounting software. You may get calls from resellers / technicians saying the reader is "reading the wrong sector" or "wrong string" This may be because they have tried converting the HEX output into Decimal and still not gotten the correct number. Generally we only use the CSN (Card Serial Number) which is a UID(unique Identifier)
UID is an umbrella term for the Unique number that identifies that card. CSN is a MiFare specific term. Some people transpose the terms. This is not a major issue.
A "Sector" refers to a block on a card (usually MiFare) the CSN is stored in Sector 0
Sector 0 cannot be changed or locked
In almost all cases where a reseller says the card reader is reading the "wrong sector" or the "wrong string" the issue is in fact just the CSN being read in a different way.
There are multiple ways to interpret a HEX number. For example from a real support issue:
There are the numbers we are getting
These are the numbers stored within PaperCut.
The first card number << 0E39B0CD >> for example in Decimal reads as 238661837 (not the number stored in PaperCut)
The immediate check is "Reverse Decimal" by reversing the HEX number to DC0B93E0 and converting to Decimal we get 3691746272 (still wrong!)
The HEX value in DECIMAL is actually Reverse Decimal! Hex values are represented as BYTE and NIBBLE (see: https://en.wikipedia.org/wiki/Hexadecimal for more information)
In the Card Number 0E39B0CD the digits 0E represent a complete BYTE. Therefore the reverse card read is CDB0390E
Here you can see the complete BYTE is reverse... note the coloured BYTES
TIP! Using the Calculator in Windows in Programmer mode you can convert the number easily.
- Copy (Crtl + C) the desired number (3450878222) and paste (Ctrl + P) into calculator
- Look at the HEX result
- Look for the pattern!
- Note, it is a good idea to test multiple card numbers to confirm your theory - just in case the HEX result has the same BYTEs in the string
- Use the appropriate script / configuration to modify the output of the card reader.
Why wouldn't this work?
- Sometimes the order may be different - example is Reverse LSB-MSB which might reverse the front and end BYTEs, but the middle BYTEs remain in same position. This can really be trial and error to figure out what the pattern is - this is why it is really important to get 3 sample card reads.
- There are other output formats like ASCII which might appear like Decimal - but are not.
- Cards have multiple sectors, and areas - in rare instances the desired card number could be from a locked or other sector.