SPI command format.

JTAG on dct2500/dct700
Post Reply
usbbdm
Junior Member
Posts: 8962
Joined: Mon Jul 18, 2005 9:33 pm

SPI command format.

Post by usbbdm »

As I am analyzing the SPI command, I think it would be of some fun to post what I have found.
There are two types of XC chip. The older one is in DCT2224 and older DCT700. In DCT700, if you open the shield cap, you will find a chip on the corner. If the chip is a smaller one with bigger pads around it, it is the newer chip. I have only seen one older version of DCT700 that uses older version. The difference in command for these chips is the length field. Older chip (DCT2000 also) uses one byte as length field. The newer chip uses two bytes as length field.

Code: Select all

IDCODE 41C5501D
DCT700 Found
IMPCODE 40404000
EJTAG V1, V2.0
DMA not supoorted
PLAT0358 Found
 <-13:38:42
05 

 <-13:38:42
D4 

 <-13:38:42
47 

 <-13:38:42
06 

 <-13:38:42
02 

->13:38:44
8C 01 

->13:38:44
8C 00 

->13:38:44
8B DD 
These are initialization.

Code: Select all

 <-13:38:44
81 00 0A FF 

 <-13:38:44
08 01 00 03 40 C0 00 01 32 CD CD 
This is typical read data (response) from XC chip.

The first line is always four bytes (new XC chip).
81 field or tag.
00 0a length of the field.
FF 08 01 00 03 40 C0 00 01 32 field data.

CD is the checksum of the field. 81 Xor 00 Xor 0A Xor FF Xor 08 Xor 01 Xor 00 Xor 03 Xor 40 Xor C0 Xor 00 Xor 01 Xor 32 = cd

If the response is single line like there is only one checksum byte. For multiple line response, there is a duplication of check sum byte. (This should be a bug of the XC chip).

Code: Select all

->17:28:04
80 07 00 01 00 06 
This is a single line command.

80 is command.
07 is field.
00 01 is length. (one byte of data).
00 data (length is in the length field).
06 checksum (07 xor 00 xor 01 xor 00)

Code: Select all

->17:24:47
80 1D 00 0E 01 00 00 00 00 01 71 02 40 19 AA 40 

->17:24:47
81 19 A8 62 

This is muti-line command
80 command.
1D field.
00 0E length (14 bytes).
01 00 00 00 00 01 71 02 40 19 AA 40 19 A8 (data). 81 in the second line is the command continuation. Not part of the data.
62 checksum (1D Xor ..... 40 xor 19 xor A8).
There is no duplication of check some in the XC send data.

For each command starts with 80 there will be a response.

Code: Select all

->17:24:43
80 05 00 00 05 

 <-17:24:43
21 

 <-17:24:43
21 

 <-17:24:43
05 00 0D FF 

 <-17:24:43
FF 08 01 00 03 00 xx xx xx xx 20 00 AE AE 

80 05 00 00 05
My interpretation would be query field 05 data.

21 means the data is ready. (22 is not).

The response

05 00 0D FF

FF 08 01 00 03 00 xx xx xx xx 20 00 AE AE

This is the response with unit ID (XX) in it.

When you switch to a channel.

Code: Select all

->17:28:41
80 1D 00 0E 01 00 00 00 00 01 7F 02 40 12 4D 40 

->17:28:41
81 12 4C 6F 
This is query the channel status.

Code: Select all


 <-17:28:41
1D 00 03 01 

 <-17:28:41
00 00 1F 1F 

 <-17:28:41
21 

 <-17:28:41
87 00 19 00 

 <-17:28:42
A8 51 8A A0 A1 80 12 00 00 00 00 00 00 00 00 00 

 <-17:28:42
00 00 00 00 00 00 00 20 5E 5E

This is when channel is authed. The same channel which is not authed gets the response

Code: Select all

 <-16:26:17
1D 00 03 01 

 <-16:26:17
00 00 1F 1F 

 <-16:26:17
21 

 <-16:26:17
87 00 19 00 

 <-16:26:17
A8 51 8A A0 A1 00 04 00 00 00 00 00 00 00 00 00 

 <-16:26:17
00 00 00 00 00 00 00 20 C8 C8 
Another field that is related to channel auth is 07.
Authed.

Code: Select all

->17:28:43
80 07 00 01 00 06 

 <-17:28:43
21 

 <-17:28:43
21 

 <-17:28:43
07 00 19 00 

 <-17:28:43
A8 51 8A A0 A1 80 12 00 00 00 00 00 00 00 00 00 

 <-17:28:43
00 00 00 00 00 00 00 20 DE DE 
Non-authed

Code: Select all

->16:26:18
80 07 00 01 00 06 

 <-16:26:18
21 

 <-16:26:18
21 

 <-16:26:19
07 00 19 00 

 <-16:26:19
A8 51 8A A0 A1 00 04 00 00 00 00 00 00 00 00 00 

 <-16:26:19
00 00 00 00 00 00 00 20 48 48 
So if we modify the response command from 00 04 to 80 12 we might be able to have the channel unlocked. (just a theory).
afterhoursalex
Junior Member
Posts: 71
Joined: Sat Jan 12, 2008 7:03 pm

xc

Post by afterhoursalex »

we must excute this xc chip. thank U usb for working hard!
usbbdm
Junior Member
Posts: 8962
Joined: Mon Jul 18, 2005 9:33 pm

Post by usbbdm »

I am doing some experiment. In any case I now made the SPI log much faster and usable when logging. No more lock ups.
merkin
Junior Member
Posts: 246
Joined: Thu Jun 28, 2007 8:49 pm

Post by merkin »

usbbdm wrote: So if we modify the response command from 00 04 to 80 12 we might be able to have the channel unlocked. (just a theory).
If I understand correctly you are changing bytes in "response" from xc.

This may take away "Not Authorized" pop-up menu when you tune a blocked channel, but if old keys are stored in xc the video will still be scrambled, correct?
usbbdm
Junior Member
Posts: 8962
Joined: Mon Jul 18, 2005 9:33 pm

Post by usbbdm »

merkin wrote:If I understand correctly you are changing bytes in "response" from xc.

This may take away "Not Authorized" pop-up menu when you tune a blocked channel, but if old keys are stored in xc the video will still be scrambled, correct?
I am not sure if the keys will pass back to CPU and fed into decoder(DSP). If it is we might be able to get video that way.
stomperz
Junior Member
Posts: 321
Joined: Sun Nov 11, 2007 7:07 am
Location: Chicago

What importance is last line?

Post by stomperz »

Originally Posted by usbbdm Image
So if we modify the response command from 00 04 to 80 12 we might be able to have the channel unlocked. (just a theory).
What about the last line?

<-17:28:43 00 00 00 00 00 00 00 20 DE DE
<-17:28:43 00 00 00 00 00 00 00 20 48 48
Sorry for my poor English, it is my primary language.:rolleyes:
usbbdm
Junior Member
Posts: 8962
Joined: Mon Jul 18, 2005 9:33 pm

Post by usbbdm »

stomperz wrote:What about the last line?

<-17:28:43 00 00 00 00 00 00 00 20 DE DE
<-17:28:43 00 00 00 00 00 00 00 20 48 48
The bold characters are checksum.
merkin
Junior Member
Posts: 246
Joined: Thu Jun 28, 2007 8:49 pm

Post by merkin »

usbbdm wrote:I am not sure if the keys will pass back to CPU and fed into decoder(DSP). If it is we might be able to get video that way.
In dct-700, qam demodulator sends serial mpeg transport stream (clk, sync, data) to XC for decryption and XC outputs decrypted serial transport streams back to decoder.
PAPAUKA
Junior Member
Posts: 105
Joined: Tue Mar 31, 2009 10:25 am

Post by PAPAUKA »

clk sync data ??? 6 pin close to xc chips....
usbbdm
Junior Member
Posts: 8962
Joined: Mon Jul 18, 2005 9:33 pm

Post by usbbdm »

merkin wrote:In dct-700, qam demodulator sends serial mpeg transport stream (clk, sync, data) to XC for decryption and XC outputs decrypted serial transport streams back to decoder.
Maybe we need to do longer enough capture to let CC hit the box and analyze the auth command. If we can decode the auth command then we can auth the xc chip. (Assume we have the play feature working for DCT700).
Killswitch
Junior Member
Posts: 439
Joined: Tue Mar 23, 2010 6:12 am

Post by Killswitch »

That six (6) SIP connection point is where the Magicians connect to do their magic with Linux to interface with the XC. This is a Dark Art and there isn't going to be a lot of info coming out of this hole. That IS the answer and the answer is a closely guarded secret.
nando29
Junior Member
Posts: 376
Joined: Sat Dec 23, 2006 7:10 am

Post by nando29 »

I have a lot of hits from my CC. This hits are from DCT2000. I have auth channels. If this hits is usefull please PM to send your.
Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber.

[Albert Einstein (1879-1955)]
Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests