2224 Component - XC420061

[cipher]

Hi Phredog,

After reading the patent carefully. I believe the seed keys are never transmitted over the wire and are also not known by the CC, the DAC will use the XC device to protect the seed keys from the CC employee. These seed keys only exist in the XC chip and are implanted at the time of manufacturing in the DCT or DAC. They do allow for expansion using an external smart card etc. but those are out of scope here. Are they unique to the CC? I cannot say yet, but I'm guessing no. There are verified instances of external DCT's that were added to a DAC database and enabled for that new system. This may indicate that the UID addressing scheme is not encrypted by the DAC but this is wishfull thinking they probably use the same XC seed keys. There will be patterns that expose the behavior. We just need to know what to look for. It will most likely be a method that allows for sequence independance. That way they can randomize the events so the pattern is not easilly spotted in the data. I believe the command and control patterns are the part that will solve the puzzle. Is it possible to crack the encryption? If they used DES and 56 Bit keys. Sure can, but no way if they are using DES3 and 2048 Bit keys, I won't live that long. That part remains to be discovered.

I agree with you on the GI Serial Number, it is probably a database reference to the UID which allows them to define what the feature capabilities of the DCT are. Is it a 5100 6208 etc. But the real address is the UID label and it is stored in both the XC device and external nvram. I believe the UID is the high address/low address ref that they illustrate in the cipher diagrams. So it is a major element in this puzzle.

[patsfan]

I also think the real unit ID is in a database. The serial number off the bottom of the box is the key to locating the real unit ID in the database. I think that when they scan the barcode, an SQL script is generated, that locates the unit ID. The unit ID is used to build the message, and then it is sent to init the box. The operator never sees the actual unit ID, only the quasi-unit ID that is located on the sticker.

i highly doubt this part is true. these boxes come straight form motorola to the CC's warehouse and then they are scanned into inventory, loaded with the firmware, guide etc., tested and then packaged for customers. there is no delay in adding them to a database first so the boxes can be controlled by the DAC. also with the method you described there would be no need for a unit id as the CC's could create their own using a database that links to serial number (gi#).

[Phredog]

Thank you all for the critique. I am not as well versed in encryption as you guys are. Every time I think I know DES, I learn some more, and maybe forget some.

Patsfan?. I was thinking the database might contain all the units, and would get updated periodically. But, with what cypher said about the seed keys, I think the database would be unnecessary.

Gentlemen, we need to know more about he seed keys. I am not sure I understand how that works. I know nothing of them with reference to DES. That must be unique to the XC applicaion.

What do you think?

[tester5]

i am 100%sure the keys can be sniffed from the stream with the right tool afther we find out how are generated specificaly for the box most of the boxes are cold when isp sends hits the box receives that xc data....its just like downloading the tvguide app or firmware just faster

[Phredog]

adrian.... I hope you are right, but I am not so sure.

I work in secure communications. We use seed keys. But, I don't know if they are used in the same context as the XC does.

The seed keys are never sent. They are stored in the processor when it is installed. There are 16.

It works somthing like this:

0E 04 //Select key number 04
31 10 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx //Hash the key wit this value
0D 01 //Save this value is key #1

0E 09 //Select key number 09
31 10 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx //Hash the key wit this value
0D 02 //Save this value is key #2

27 02 zz //Use key 02 to decrypt the next zz bytes

[cipher]

I agree with Phredog sending the seed keys over the wire is like handing out candy I just can't see that happening. There are other keys that are sent on the wire but they are not the seed keys. PPV non-repudiation keys would be a good example of them. The DCT uploads this transaction back to the CC which is the creation of a one way hash and can only be generated by your UID and CC issued key. This is how they can be sure that your DCT has made the PPV purchase on their system.

[tester5]

i dont have coding knoledge but anything is possyble. as long someone finds out how to generate this xc command for auth if there is a will there is a way

[cipher]

I have discovered a most interesting event. When you spoof an authorized UID the spoofing unit will recieve the true UID's authorization commands. The spoofing UID will not be able to use the command. Since the UID must match inside the XC chip for the decryption to work. This leads me to believe that it is possible to eavesdrop on all command data on the wire by locating the code that matches incomming data to UID addressing. This will speed things up on the command anaylysis side.

Also there are some simple patterns which I am starting to see in SPI logs which show dependancies on multicast data. Here is what I found.

This command is constantly sent to all units notice the bolded byte.

80 0E 05 30 1A 19 35 85 88
55 00 00 00 00 00 00 00 00

00
55

00 00
0E 02

01
55

00 00 00
30 00 3C

Here is a partial auth stream, the bolded byte always follows the multicasted data of 1A.

80 3C B8 70 00 00 00 96 A0 00 1A 00 00 80 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 02 04

The 1A value is incremented montly. I now have a log which shows it with 1B.

[Phredog]

Perhaps the 1A is part of a timestamp. Ok, well maybe that is not likley.

[cipher]

Phredog,

I think your right, it looks like an epoch value or maybe an epoch version of some kind. It is another puzzle piece and each one reveals more info about the control command structure which is the best way to unfold it's secrets. The best part about the DCT receiving a command on a spoofed UID is that there is no dependancy on decryption or hashing. I recieved it on a UID that has no keys at all.(E11 errors and FC on the seeds) Once I find the data stream input buffer I/O address I will have a signifcant amount of data to find patterns with.

[usbbdm]

cipher, you have done great job!

[twistedps]

awesome find cipher!

[Phredog]

Cy....

Post some hex values of, say the next five messages you capture. Perhaps a pattern will show itself. Have you created a spreadsheet, or something with samples? I would like to see it.

I'd like to see of a byte changes daily, hourly, etc. No it will not mean much yet, but that is just a few more bytes we know.

In my experience, the timestamp is used to make sure each packet will have a unique checksum even if the same packet is sent twice. In this case, it appears that the time-stamp is not encrypted. Or is it? I find it unlikely that the digit would increment by one if it was encrypted.. Some analysis of surrounding numbers may give us a clue.

Well, I gotta go, before the wife unpluggs my computer. Later

[cipher]

Phredog,

I am planning to code a parser for the logger that usbbdm created. I will use it to generate a database of command/data collections that can then be queried/reported on. It will take a while. My highest priority right now is to find the code that compares the trasmitted UID to the local UID. My wife will unplug the computer soon as well.

usbbdm could you code the parser to open the log file without exclusive write. I think its OF_SHARE_EXCLUSIVE = &H10 not sure something like that. It's not a real issue but it would be nice to read it while it logs.

[usbbdm]

I put a JTAG to the DCT2500, it only shows one part. The XC chip is not in the jtag chain. Carefully study the chip it does not use JTAG to program. The three pin (INFOXXX) should be used as to program the unit address. If you open a * choice box, it has a unit address label beside the 6 pin connector which is the same 6 pin in PH boxes. On DCT 2500, there is no 6 pin connector but three pin beside the XC chip marks the same INFO label. It is sure the protocol is somewhat BDM/JTAG like serial data with clock.