View Full Version : garbled bits or real memory content
LeeGibling
03-27-2006, 12:05 AM
This is a suggestion for a possible backdoor to the cards memory, it could be
a weak light at the end of the tunnel or just some garbled bits. Who knows ?
The following works with all SLE66P based cards (P4, D1, D2) alike:
2a ; packet length
10 ; set baud rate to 9600
01 ; power up
28 00 00 ; delay
01 ; power up again to enter the "before returning from ATR hole"
20 03 b0 ; wait for ATR_DM (= start of EEPROM)
80 ; receive byte 0x33
28 00 00 ; delay
8c ; receive remainder of ATR_DM
;---------------------------
c0 00 ; send 0xFF to the card
21 aa 00 ; delay (you may increase this interval a little bit
c5 00 00 00 00 00 00 ; send 0xFF FF FF FF FF FF to the card
2b 00 00 ; delay
c1 xx yy ; send 2 bytes to the card,
; vary this value to get different results
20 00 00 ; short delay
;---------------------------
10 ; set baud rate to 9600 again
80 ; receive first byte of ATR(_DM)
28 00 00 ; delay
8c ; receive remainder of ATR(_DM)
00 ; packet end
R10
In the following examples the results consisting of one byte are marked red.
Example 1
TX Data : 2A 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 21 AA 00 C5 00 00 00 00 00 00 2B 00 00 C1 00
00 20 00 00 10 80 28 00 00 8C 00
RX Data : 29 18 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
Flushed : 2C 03 40 B0 20 FF FF 4A 50 00
Example 2
TX Data : 2A 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 21 AA 00 C5 00 00 00 00 00 00 2B 00 00 C1 F8
E0 20 00 00 10 80 28 00 00 8C 00
RX Data : 29 18 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
Flushed : C0 03 40 B0 20 FF FF 4A 50 00
Example 3
TX Data : 2A 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 21 AA 00 C5 00 00 00 00 00 00 2B 00 00 C1 FF
FF 20 00 00 10 80 28 00 00 8C 00
RX Data : 29 19 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
Flushed : F8 25 03 40 B0 20 FF FF 4A 50 00
LeeGibling
03-29-2006, 12:50 PM
If you modify the .xpl script from above a little bit, you'll get 3 new bytes
instead of 1.
2a ; packet length
10 ; set baud rate to 9600
01 ; power up
28 00 00 ; pause
01 ; power up again to enable ATR_DM
20 03 b0 ; wait for ATR_DM
80 ; receive byte 0x33
28 00 00 ; delay
8c ; receive remainder of ATR_DM
;---------------------------
c0 00
22 60 00
c7 ff ff ff ff ff ff ff ff
20 00 00
c2 ff ff ff
;---------------------------
10
82 ; get the 3 bytes which are marked red in the examples below
28 00 00
8c
00 ; packet end
R10
you will get u something like
2A 1E 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
C6 79 78 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71from a P4 and
2A 1E 33 99 FF BF E1 00 3B FE CB B7 A7 97 71 CF
C6 F7 F0 33 99 FF BF E1 00 3B FE CB B7 A7 97 71 from a D1 or a D2 (rethink tv).
If we reduce the interval of 22 60 00 at the beginning to 21 70 00 and change some
bytes sent to the card, the result looks different, but it varies strongly from card to card.
In some cases even not 3 but only 1 new byte appears.
TX Data : 2A 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 21 70 00 C7 FF FF FF FF FF FF 00 00 20 00 00
C2 00 00 00 10 82 28 00 00 8C 00
RX Data : 29 16 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
Flushed : DF BE 32 9B D7 71 2F 2F
LeeGibling
04-01-2006, 07:02 AM
This is preliminary. All I can say for now is that its possible to get up to 4 extra
bytes from all types of SLE66P based cards (P4, D1, rethink tv).
2c ; packet length
10 ; set baud rate to 9600
01 ; power up
28 00 00 ; pause
01 ; power up again to enable ATR_DM
20 03 b0 ; wait for ATR_DM
80 ; receive byte 0x33
28 00 00 ; delay
8c ; receive remainder of ATR_DM
;---------------------------
c0 00
22 10 00 ; vary this interval to get different results
c4 ff ff ff ff ff
20 00 00
c4 ff ff ff ff ff
20 00 00
;---------------------------
10
83 ; try to get 4 extra bytes marked red in the examples below
28 00 00
8c
00
R10
Example 1: 00'd P4 of the 0008 series
TX Data : 2C 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 22 10 00 C4 FF FF FF FF FF 20 00 00 C4 FF FF
FF FF FF 20 00 00 10 83 28 00 00 8C 00
RX Data : 2B 13 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
Flushed : 73 B3 7A A5 2F
Example 2: D1 of the 0013 series
TX Data : 2C 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 22 10 00 C4 FF FF FF FF FF 20 00 00 C4 FF FF
FF FF FF 20 00 00 10 83 28 00 00 8C 00
RX Data : 2B 13 33 99 FF BF E1 00 3B FE CB B7 A7 97 71 CF
Flushed : BD 39 72 B9 CF
Example 3: D2 of the 0017 series
TX Data : 2C 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 22 10 00 C4 FF FF FF FF FF 20 00 00 C4 FF FF
FF FF FF 20 00 00 10 83 28 00 00 8C 00
RX Data : 2B 13 33 99 FF BF E1 00 5B 17 08 67 5F 57 71 CF
Flushed : 9C 7E 5C C6 CF
LeeGibling
04-09-2006, 02:07 PM
Assumption:
The 4 extra bytes from my previous .xpl script could be contents of intermediate
S-boxes of bytes from the beginning of EEPROM (ATR_DM). The fact that
nibbles are swapped and bit orders are permuted suggests the prescence of
S-boxes. Maybe there are some uninitialized bytes, left over from routines
whose HU equivalents were once named:
Trap0-DecryptEeprom
Trap4-DecryptEeprom&MovtoRAM
They are: Temporarily written into the (X)RAM or into the registers.
If I/O is set to high now, those temporary values are sent to the card reader.
Replaced by its final values (some unencrypted bytes from
the start of EEPROM) after a certain amount of cycles marked
orange in the .xpl script below.
If I/O is set to high now, only those final values are read out.
25 ; packet length
10 ; set baud rate to 9600
01 ; power up
28 00 00 ; pause
01 ; power up again to enable ATR_DM
20 03 b0 ; wait for ATR_DM
80 ; receive byte 0x33 (first byte of ATR_DM)
28 00 00 ; delay
8c ; receive remainder of ATR_DM
;---------------------------
c0 00 ; send 0xFF to the card
22 60 00 ; delay, the mecessary value for this interval
; P4 versions may vary between various
c7 00 ff ff ff ff ff ff ff ; send "ff 00 00 00 00 00 00 00" to the card
20 tt tt ; interval where wiping of the 4 extra bytes
; is likely to take place
84 ; get the 4 bytes which are marked red in the
; example(s) below if modified + byte 0x2F (0x0B)
22 80 00 ; wait for the 2nd ATR_DM if there is any
8c ; get 2nd ATR_DM if there is any
00 ; packet end
R10
R05
Example 1: tt tt = 0x0000. Data fields remain uninitialized --> 4 extra bytes are returned.
TX Data : 25 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 22 60 00 C7 00 FF FF FF FF FF FF FF 20 00 00
84 22 80 00 8C 00
RX Data : 25 20 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
RX Data : 73 B3 7A A5 2F
Flushed : 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71
Example 2: tt tt = 0x0800. Data fields are only partly initialized --> 2 extra
bytes are returned.
TX Data : 25 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 22 60 00 C7 00 FF FF FF FF FF FF FF 20 08 00
84 22 80 00 8C 00
RX Data : 25 20 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
RX Data : CC 9D 71 2F 2F
Flushed : 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71
Example 3: tt tt = 0x1000. Data fields are properly
initialized ---> No extra bytes are returned.
TX Data : 25 10 01 28 00 00 01 20 03 B0 80 28 00 00 8C C0
00 22 60 00 C7 00 FF FF FF FF FF FF FF 20 10 00
84 22 80 00 8C 00
RX Data : 25 20 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71 2F
RX Data : 9B D7 71 2F 2F
Flushed : 33 99 FF 7F 31 00 BB F5 F1 97 9B D7 71
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.