LeeGibling
02-07-2006, 12:29 AM
Admittedly during the last 15 months I constantly made a fundamental mistake
when interpreting data sent to the card after receiving the ATR_DM.
The UART of the SLE66P has two modes of handling ISO-7816 data:
direct when returning the ATR_DM (start of EEPROM) and
when injecting bytes after receivng the ATR_DM.
inverse when returning the regular ATR
when sending and receivng the results of regular Videoguard packets
(48 INS P1 P2 LEN ...)
when receiving the "Dtag4Tbz" string within a 64 byte block of dumped data
Most unlooper firmware like UL4S, HUFF or M6.2 converts sent and received
data from direct to inverse. So after receiving ATR_DM, for instance the command C0 00 actually sends byte FF to the card.
C2 01 02 13 actually sends the bytes 7F BF 37 to the card.
when interpreting data sent to the card after receiving the ATR_DM.
The UART of the SLE66P has two modes of handling ISO-7816 data:
direct when returning the ATR_DM (start of EEPROM) and
when injecting bytes after receivng the ATR_DM.
inverse when returning the regular ATR
when sending and receivng the results of regular Videoguard packets
(48 INS P1 P2 LEN ...)
when receiving the "Dtag4Tbz" string within a 64 byte block of dumped data
Most unlooper firmware like UL4S, HUFF or M6.2 converts sent and received
data from direct to inverse. So after receiving ATR_DM, for instance the command C0 00 actually sends byte FF to the card.
C2 01 02 13 actually sends the bytes 7F BF 37 to the card.